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) stevenjgar...@gmail.com On Fri, May 7, 2021 at 3:32 AM Brian Candler <b.cand...@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. >
_______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
