[Pdns-users] DNS Forwarding on Master/Slave Servers

[Brian Candler]

On 07/05/2021 06:14, Steven Garner via Pdns-users wrote:
> I have a noob question about DNS forwarding - just implemented pdns 
> version 4.2.1 on three servers on separate networks

I have to ask: why are you implementing something which is approaching 
end-of-life?  PowerDNS Authoritative current version is 4.4.x, and only 
two previous ones are maintained.  Get the current software from 
https://repo.powerdns.com/  (ignore the "master branch", this is 
bleeding-edge)


> , intending for one to be a master (primary) and the other two to be 
> slaves (secondaries).  So far I love it, but I think I may be doing 
> something wrong with DNS forwarding.

I am not sure what you mean by "DNS forwarding" in the context of an 
authoritative server.  It either answers, or it doesn't.


>
> I have records for some 383 domains in MySQL as a backend.
>
> I have the master set up with:
>
> master=yes
>
> ... and the slaves set up with:
>
> slave=yes
>
> ... all in /etc/powerdns/pdns.conf
>
> Also the master/slave state is configured on a per domain basis in the 
> domains table with the type column set to either MASTER or SLAVE 
> respectively. The slave has the master node IP addresses set for each 
> domain in the master column in the domains table.
>
> dig would seem to indicate that everything is working fine:
>
> ==========================================
>
> dig soa opensourceserver.io <http://opensourceserver.io> 
> @ns3.opensourceserver.io <http://ns3.opensourceserver.io>
>

Looking from here, ns3 doesn't work for me:

$ dig +norec soa opensourceserver.io @ns3.opensourceserver.io

; <<>> DiG 9.10.6 <<>> +norec soa opensourceserver.io 
@ns3.opensourceserver.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: *REFUSED*, id: 31728
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;opensourceserver.io.        IN    SOA

;; Query time: 128 msec
;; SERVER: 47.225.208.154#53(47.225.208.154)
;; WHEN: Fri May 07 09:11:11 BST 2021
;; MSG SIZE  rcvd: 48


ns2 doesn't work for me either:

$ dig +norec soa opensourceserver.io @ns2.opensourceserver.io

; <<>> DiG 9.10.6 <<>> +norec soa opensourceserver.io 
@ns2.opensourceserver.io
;; global options: +cmd
;; connection timed out; no servers could be reached

But ns1 does work:

$ dig +norec soa opensourceserver.io @ns1.opensourceserver.io

...
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
opensourceserver.io.    86400    IN    SOA ns1.opensourceserver.io. 
hostmaster.embode.net. 2021050501 10380 3600 1814400 3796


Given that ns1, ns2 and ns3 are all your own machines, then it's up to 
you to fix them so that they respond authoritatively.  My first guess is 
that the master/slave replication isn't working; look at logs on both 
sides.  In the case of ns2 it may be firewalled off, although it does 
respond to pings.

Incidentally, given that you are using powerdns exclusively, then 
there's a better approach than master/slave for syncing zones. You can 
use "native" replication: that is, in effect you configure all three as 
primary, and sync the mysql databases using mysql's own replication 
capabilities.

This will give you near-instantaneous replication, guarantees all 
databases are identical, and avoid all issues with notifies, authorizing 
AXFRs etc.  For a new deployment I'd definitely recommend it.  However, 
if you want to use traditional master/slave then it should work too.  
Check your configs and the zones configured in your databases.

One other thing. Zone opensourceserver.io has nameservers within the 
same zone (i.e. ns1/ns2/ns3.opensourceserver.io).  This means you need 
to be careful that all your glue records are correct as well.

This is clearly broken at the moment:

$ dig +norec @a0.nic.io. ns1.opensourceserver.io.
...
;; ADDITIONAL SECTION:
ns1.opensourceserver.io. 86400    IN    A    76.76.238.10
ns2.opensourceserver.io. 86400    IN    A    76.76.238.10
ns3.opensourceserver.io. 86400    IN    A    76.76.238.10

!!!!

But:

$ dig +short +norec @76.76.238.10 ns1.opensourceserver.io.
76.76.238.10
$ dig +short +norec @76.76.238.10 ns2.opensourceserver.io.
207.177.51.156
$ dig +short +norec @76.76.238.10 ns3.opensourceserver.io.
47.225.208.154

This sort of inconsistency will bite you in the end, so make sure you 
get it right.  In this case you need to fix the glue records with your 
registrar.

I can see from reverse DNS that these are the primary names for those 
nameservers.  When it comes to your other 382 domains: I don't know what 
you've chosen to do, but it's easier and safer if you point their NS 
records to ns1/ns2/ns3.opensourceserver.io, rather then 
ns1/ns2/ns3.otherdomain.com.  The latter is known as "vanity" 
nameservers, and will mean you have to sort glue out for each domain as 
well.

Regards,

Brian.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20210507/7b7ac17c/attachment.htm>