Re: [Pdns-users] DNAME randomly failing on Linux clients
On 06/04/2022 10:44, Adam Cecile wrote: If at all possible, I'd suggest you simply run auth and recursor bound to separate IP addresses - whether that be on the same host, or in VMs or containers. Then you point your clients at your recursor IP(s), your NS records at your auth server hostname(s), and dnsdist isn't required. Well that'd make things more complicated because the server running authoritative do need to use recursor facilities too :D That's not an issue. If the server needs to *use* recursor facilities, then you point its resolv.conf to whatever IP address your recursor is bound to - whether this is on the same host, or a different host makes no difference. Normally you'd dedicate a server to auth (or VM or container), and point to a separate recursor - well, two recursors for redundancy. But if you run both auth and recursor on the same server/VM, but bound to different IPs, that will work too. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
On 4/6/22 11:28, Brian Candler wrote: On 06/04/2022 10:25, Adam Cecile via Pdns-users wrote: I need some recursion / logging facilities so I added on top of them (same machine) pdns-recursor or dnsdist. I first went for recursor but ended up thinking dnsdist was more flexible (especially on filtering updates / axfr, you're right). If at all possible, I'd suggest you simply run auth and recursor bound to separate IP addresses - whether that be on the same host, or in VMs or containers. Then you point your clients at your recursor IP(s), your NS records at your auth server hostname(s), and dnsdist isn't required. Well that'd make things more complicated because the server running authoritative do need to use recursor facilities too :D___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
On 06/04/2022 10:25, Adam Cecile via Pdns-users wrote: I need some recursion / logging facilities so I added on top of them (same machine) pdns-recursor or dnsdist. I first went for recursor but ended up thinking dnsdist was more flexible (especially on filtering updates / axfr, you're right). If at all possible, I'd suggest you simply run auth and recursor bound to separate IP addresses - whether that be on the same host, or in VMs or containers. Then you point your clients at your recursor IP(s), your NS records at your auth server hostname(s), and dnsdist isn't required. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
On 4/6/22 11:18, Brian Candler wrote: If I understand that right: you have dnsdist and auth running on the local server, and recursor is on a remote server? If your requirements are simple, for basic DNS querying you may not need dnsdist at all. Just run the recursor on port 53, and use forward-zones / forward-zones-recurse as you do today. Looking at your config though, maybe it's to do with AXFR/IXFR requirements though. Any idea ? I can definitely make TCPDumps at some point but I'm not sure to able to understand them ;-) If the above statement is true, you'll need two simultaneously, in separate windows: tcpdump -i lo -nn -s0 -v port 53 or port 5353 tcpdump -i eth0 -nn -s0 -v port 53 It should decode the packets for you, so it should be clear. (Except port 5353. New version of tcpdump have "-T domain" to force decoding as DNS, but you'll need a very recent version; Ubuntu 20.04 is not new enough) The tcpdumps will show: - queries from dig to dnsdist (53) and dnsdist to auth (5353) - queries from dnsdist to recursor No I have actually three identical servers shared a MySQL cluster used as PowerDNS backend for authoritative zones I need some recursion / logging facilities so I added on top of them (same machine) pdns-recursor or dnsdist. I first went for recursor but ended up thinking dnsdist was more flexible (especially on filtering updates / axfr, you're right). That's why I basically have both of them available on each server and can very easily switch between them for testing purpose. I'll check the tcpdump thinggy, should be trivial task to backport Debian's version to stable. Adam. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
If I understand that right: you have dnsdist and auth running on the local server, and recursor is on a remote server? If your requirements are simple, for basic DNS querying you may not need dnsdist at all. Just run the recursor on port 53, and use forward-zones / forward-zones-recurse as you do today. Looking at your config though, maybe it's to do with AXFR/IXFR requirements though. Any idea ? I can definitely make TCPDumps at some point but I'm not sure to able to understand them ;-) If the above statement is true, you'll need two simultaneously, in separate windows: tcpdump -i lo -nn -s0 -v port 53 or port 5353 tcpdump -i eth0 -nn -s0 -v port 53 It should decode the packets for you, so it should be clear. (Except port 5353. New version of tcpdump have "-T domain" to force decoding as DNS, but you'll need a very recent version; Ubuntu 20.04 is not new enough) The tcpdumps will show: - queries from dig to dnsdist (53) and dnsdist to auth (5353) - queries from dnsdist to recursor ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
On 4/6/22 10:46, Adam Cecile wrote:
On 4/6/22 10:44, Brian Candler wrote:
On 06/04/2022 09:36, Adam Cecile via Pdns-users wrote:
Any idea what's going on here, I'm completely lost. I guess my DNAME
usage is somehow incorrect but I don't understand why it's working
intermittently (and always with pure DNS call using dig...)
Just a thought, but does your system use systemd-resolved? (Clue:
/etc/resolv.conf points to nameserver 127.0.0.53). For example, it
may treat ".local" differently, given that domain is reserved for
multicast DNS (as dig output informs you); or there may be some
DNSSEC issue. "systemd-resolve --status" may give you some clue.
Apart from that, I suggest you look at the raw queries and responses
on the wire, and see how this differs between using direct dig and
gethostbyname:
tcpdump -i eth0 -nn -s0 -v port 53
(replace "eth0" with whatever your external interace is)
Hello,
No regular resolv.conf pointing to 127.0.0.1 (local DNSDist -> local
PowerDNS), nsswitch mdns stuff is also removed.
Just find out something interesting, it works with PowerDNS recursor but
not DNSDist:
Recursor config:
local-address=0.0.0.0, ::
local-port=53
forward-zones=domain.internal=127.0.0.1:5300
forward-zones+=in-addr.arpa=127.0.0.1:5300
forward-zones+=domain.local=127.0.0.1:5300
forward-zones+=another.domain=127.0.0.1:5300
forward-zones+=another.domain2=127.0.0.1:5300
forward-zones+=another.domain3=127.0.0.1:5300
forward-zones+=another.domain4=127.0.0.1:5300
forward-zones-recurse=.=10.10.10.10
serve-rfc1918=no
loglevel=6
quiet=no
lua-config-file=/etc/powerdns/local-protobuf-forwarder-recursor.lua
DNSDist config:
setSecurityPollSuffix("")
addLocal('0.0.0.0:53', {reusePort=true})
newServer({address="127.0.0.1:5300", pool="authoritative"})
newServer({address="10.10.10.10:53", pool="recursor"})
setACL({'127.0.0.0/8'})
addACL('10.1.0.0/16')
addACL('192.168.69.33/27')
addAction(AndRule({OrRule({OpcodeRule(DNSOpcode.Notify),
OpcodeRule(DNSOpcode.Update), QTypeRule(DNSQType.AXFR),
QTypeRule(DNSQType.IXFR)}), NotRule(makeRule({"127.0.0.1/8",
"10.x.x.x/32", "10.x.x.x/32", "10.x.x.x/32"}))}),
RCodeAction(dnsdist.REFUSED))
addAction(OrRule({QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}),
RCodeAction(DNSRCode.REFUSED))
addAction({'in-addr.arpa'}, PoolAction("authoritative"))
addAction({'domain.local'}, PoolAction("authoritative"))
addAction({'domain.internal'}, PoolAction("authoritative"))
addAction({'another.domain'}, PoolAction("authoritative"))
addAction({'another.domain2'}, PoolAction("authoritative"))
addAction({'another.domain3'}, PoolAction("authoritative"))
addAction({'another.domain4'}, PoolAction("authoritative"))
addAction(AllRule(), PoolAction('recursor'))
rl = newRemoteLogger("127.0.0.1:50001")
addAction(AllRule(),RemoteLogAction(rl))
Any idea ? I can definitely make TCPDumps at some point but I'm not sure
to able to understand them ;-)
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
On 4/6/22 10:44, Brian Candler wrote: On 06/04/2022 09:36, Adam Cecile via Pdns-users wrote: Any idea what's going on here, I'm completely lost. I guess my DNAME usage is somehow incorrect but I don't understand why it's working intermittently (and always with pure DNS call using dig...) Just a thought, but does your system use systemd-resolved? (Clue: /etc/resolv.conf points to nameserver 127.0.0.53). For example, it may treat ".local" differently, given that domain is reserved for multicast DNS (as dig output informs you); or there may be some DNSSEC issue. "systemd-resolve --status" may give you some clue. Apart from that, I suggest you look at the raw queries and responses on the wire, and see how this differs between using direct dig and gethostbyname: tcpdump -i eth0 -nn -s0 -v port 53 (replace "eth0" with whatever your external interace is) Hello, No regular resolv.conf pointing to 127.0.0.1 (local DNSDist -> local PowerDNS), nsswitch mdns stuff is also removed. ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] DNAME randomly failing on Linux clients
On 06/04/2022 09:36, Adam Cecile via Pdns-users wrote: Any idea what's going on here, I'm completely lost. I guess my DNAME usage is somehow incorrect but I don't understand why it's working intermittently (and always with pure DNS call using dig...) Just a thought, but does your system use systemd-resolved? (Clue: /etc/resolv.conf points to nameserver 127.0.0.53). For example, it may treat ".local" differently, given that domain is reserved for multicast DNS (as dig output informs you); or there may be some DNSSEC issue. "systemd-resolve --status" may give you some clue. Apart from that, I suggest you look at the raw queries and responses on the wire, and see how this differs between using direct dig and gethostbyname: tcpdump -i eth0 -nn -s0 -v port 53 (replace "eth0" with whatever your external interace is) ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] DNAME randomly failing on Linux clients
Hello,
I'm trying to setup a domain migration using DNAME zones to keep compat
with previous domain name but I ended up with a solution that works
everytime with dig but seems to be randomly failing using Linux GLIBC
resolver.
Setup is PowerDNS running native *.domain.internal zones and
*.domain.local zones using DNAME to redirect to .internal. In front of
the PowerDNS server we're running DNSDist to route internal
authoritative zones and external ones to forwarders.
Here is that DIG finds out:
dig api.domain.local
; <<>> DiG 9.16.27-Debian <<>> api.domain.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked
to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58530
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.domain.local. IN A
;; ANSWER SECTION:
api.domain.local. 3600 IN CNAME rp-int.dmz.domain.local.
dmz.domain.local. 3600 IN DNAME dmz.domain.internal.
rp-int.dmz.domain.internal. 60 IN A 10.1.1.1
rp-int.dmz.domain.local. 3600 IN CNAME rp-int.dmz.domain.internal.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Apr 06 08:24:06 UTC 2022
;; MSG SIZE rcvd: 139
It works 100% times.
However, getent host is failing a lot:
getent hosts api.domain.local
Using .internal domains also fails most of the time.
I'm seeing the same issue using Python socket module:
python3 -c 'import socket; socket.gethostbyname("api.domain.local")'
Traceback (most recent call last):
File "", line 1, in
socket.gaierror: [Errno -2] Name or service not known
Any idea what's going on here, I'm completely lost. I guess my DNAME
usage is somehow incorrect but I don't understand why it's working
intermittently (and always with pure DNS call using dig...)
Thanks a lot in advance,
Best regards, Adam.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
