<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 07/05/2021 06:14, Steven Garner via
Pdns-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJNrfiaL5a8TF1p1Ve0x5Jr9=ObjEuz=+XwsSGaWt75Za3Yicg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>I have a noob question about DNS forwarding - just
implemented pdns version 4.2.1 on three servers on separate
networks</div>
</div>
</blockquote>
<p>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 <a class="moz-txt-link-freetext" href="https://repo.powerdns.com/">https://repo.powerdns.com/</a> (ignore the
"master branch", this is bleeding-edge)<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJNrfiaL5a8TF1p1Ve0x5Jr9=ObjEuz=+XwsSGaWt75Za3Yicg@mail.gmail.com">
<div dir="ltr">
<div>, 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.<br>
</div>
</div>
</blockquote>
<p>I am not sure what you mean by "DNS forwarding" in the context of
an authoritative server. It either answers, or it doesn't.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAJNrfiaL5a8TF1p1Ve0x5Jr9=ObjEuz=+XwsSGaWt75Za3Yicg@mail.gmail.com">
<div dir="ltr">
<div><br>
I have records for some 383 domains in MySQL as a backend.<br>
<br>
I have the master set up with:<br>
<br>
master=yes<br>
<br>
... and the slaves set up with:<br>
<br>
slave=yes<br>
<br>
... all in /etc/powerdns/pdns.conf<br>
<br>
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.<br>
<br>
dig would seem to indicate that everything is working fine:<br>
<br>
==========================================<br>
<br>
dig soa <a href="http://opensourceserver.io"
moz-do-not-send="true">opensourceserver.io</a> @<a
href="http://ns3.opensourceserver.io" moz-do-not-send="true">ns3.opensourceserver.io</a><br>
<br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Looking from here, ns3 doesn't work for me:</p>
<p>$ dig +norec soa opensourceserver.io @ns3.opensourceserver.io<br>
<br>
; <<>> DiG 9.10.6 <<>> +norec soa
opensourceserver.io @ns3.opensourceserver.io<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: <b>REFUSED</b>,
id: 31728<br>
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 1232<br>
;; QUESTION SECTION:<br>
;opensourceserver.io. IN SOA<br>
<br>
;; Query time: 128 msec<br>
;; SERVER: 47.225.208.154#53(47.225.208.154)<br>
;; WHEN: Fri May 07 09:11:11 BST 2021<br>
;; MSG SIZE rcvd: 48</p>
<p><br>
</p>
<p>ns2 doesn't work for me either:<br>
</p>
<p>$ dig +norec soa opensourceserver.io @ns2.opensourceserver.io<br>
</p>
<p>; <<>> DiG 9.10.6 <<>> +norec soa
opensourceserver.io @ns2.opensourceserver.io<br>
;; global options: +cmd<br>
;; connection timed out; no servers could be reached<br>
<br>
</p>
<p>But ns1 does work:</p>
<p>$ dig +norec soa opensourceserver.io @ns1.opensourceserver.io<br>
</p>
<p>...<br>
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1<br>
...<br>
;; ANSWER SECTION:<br>
opensourceserver.io. 86400 IN SOA
ns1.opensourceserver.io. hostmaster.embode.net. 2021050501 10380
3600 1814400 3796<br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>This is clearly broken at the moment:</p>
<p>$ dig +norec @a0.nic.io. ns1.opensourceserver.io.<br>
...<br>
;; ADDITIONAL SECTION:<br>
ns1.opensourceserver.io. 86400 IN A 76.76.238.10<br>
ns2.opensourceserver.io. 86400 IN A 76.76.238.10<br>
ns3.opensourceserver.io. 86400 IN A 76.76.238.10<br>
</p>
<p>!!!!</p>
<p>But:</p>
<p>$ dig +short +norec @76.76.238.10 ns1.opensourceserver.io.<br>
76.76.238.10<br>
$ dig +short +norec @76.76.238.10 ns2.opensourceserver.io.<br>
207.177.51.156<br>
$ dig +short +norec @76.76.238.10 ns3.opensourceserver.io.<br>
47.225.208.154</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>Regards,</p>
<p>Brian.<br>
</p>
</body>
</html>