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

Fri May 7 10:35:48 UTC 2021

Gentlemen,

I greatly appreciate you all taking the time to respond in such depth.

So first upgrade the version of pdns, then I will separately address the
other issues you all raise.

Thanks for the heads up.  It is not that I was knowingly "implementing
something which is approaching end-of-life".  All 3 of my name servers are
running on the latest updated long-term release version of Ubuntu (Ubuntu
20.04.2 LTS).  I thought the best practice to ensure current software on
Ubuntu was to use apt, first to update and then to install:

sudo apt update
sudo apt install pdns-server pdns-backend-mysql -y

... and from there configure the installation:

mysql -u pdnsadmin -p pdns <
/usr/share/pdns-backend-mysql/schema/schema.mysql.sql
vi /etc/powerdns/pdns.d/pdns.local.gmysql.conf
etc

I did not realize that doing this just over the last few days would install
a version of pdns slated for EOL ~ April 2021!  (given that it's May
already - https://doc.powerdns.com/authoritative/appendices/EOL.html)

I understand from your referenced documentation (https://repo.powerdns.com/),
that the preferred installation method for "PowerDNS Authoritative Server -
master branch" on Ubuntu 20.04 "Focal Fossa" is to:

Create the file '/etc/apt/sources.list.d/pdns.list' with this content:

deb [arch=amd64] http://repo.powerdns.com/ubuntu bionic-auth-master main

And this to '/etc/apt/preferences.d/pdns':

Package: pdns-*

Pin: origin repo.powerdns.com

Pin-Priority: 600

and execute the following commands:

curl https://repo.powerdns.com/CBC8B383-pub.asc | sudo apt-key add - &&

sudo apt-get update &&

sudo apt-get install pdns-server

There is nothing there about installing the preferred backend, but would I
be correct in assuming I could extend that last line to read:

sudo apt install pdns-server pdns-backend-mysql

I find the documentation on upgrading pdns (
https://doc.powerdns.com/authoritative/upgrading.html) to be highly
contextual and difficult to follow, in that there does not appear to be
procedures set forth to actually upgrade any distribution.

So instead of upgrading, do I first uninstall, remove and purge the old
pdns 4.2.1 installation and then follow the installation of the latest
master branch above?

apt-get --purge autoremove pdns-server pdns-backend-mysql

I'm assuming as a backend, the apt-updated version of MySQL is adequate:

mysql  Ver 8.0.23-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))

... where all the domain and record information will persist.

I will respond about the other issues once I have the latest master branch
installed, but for now let me clarify the ip addressing of my 3 servers - I
have each server on a separate network from a separate provider, each with
reverse dns established.  Here are the 3 servers, their ip addresses and
the name servers for each of the provider (upstream) networks:

ns1.opensourceserver.io = 76.76.238.10
dns2.lisco.com 69.18.32.51
dns1.lisco.com 69.18.32.50

ns2.opensourceserver.io = 207.177.51.156
ns1.natel.net 207.177.74.108
ns1.natel.com 207.177.74.118

ns3.opensourceserver.io = 47.225.208.154
rns01.charter.com 71.10.216.1
rns02.charter.com 71.10.216.2

Thanks in advance.

Steve Garner
+1 302 364 0325 (USA)
stevenjgarner at gmail.com

On Fri, May 7, 2021 at 3:32 AM Brian Candler <b.candler at pobox.com> wrote:

> 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 @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/164ad9b6/attachment-0001.htm>