search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.63k stars 904 forks source link

If multiple supermasters with same nameserver then master of AXFR'ed domain is wrong, AXFR transfer fails #1703

Closed myH2Oservers closed 9 years ago

myH2Oservers commented 10 years ago

We have ns1.domain.com till ns3.domain.com hosted in a pdns cluster. All webservers sync their DNS to ns1.domain.com with mysql replication to ns2 and ns3. All supermasters use ns1 till ns3 as their nameservers which means we have multiple supermasters with the same "nameserver" name but with different "ip". This works on our current ns1 which is version 3.2. Now testing with version 3.4-rc1 and we have this problem:

When we add a domain on one of the webservers bind notifies our ns1 and does a AXFR transfer. The master of the domain should be only the server which does the AXFR transfer, however PowerDNS seems to do a lookup to the supermaster table, search for all supermasters with ns1.domain.com as their nameserver record and take out all IP addresses and use all of them as the master of the domain. Look at the following logging:

Sep 5 10:45:22 ns1 pdns[19955]: Remote IP6 wants 'testtyje.nl|SOA', do = 0, bufsize = 512: packetcache MISS Sep 5 10:45:22 ns1 pdns[19955]: Received NOTIFY for testtyje.nl from IP6 for which we are not authoritative Sep 5 10:45:26 ns1 pdns[19955]: Query: insert into domains (type,name,master,account) values('SLAVE','testtyje.nl','IP1, IP2, IP3, IP4, IP5, IP6,'web3') Sep 5 10:45:26 ns1 pdns[19955]: Created new slave zone 'testtyje.nl' from supermaster IP6 Sep 5 10:45:28 ns1 pdns[19955]: While checking domain freshness: Query to 'IP1' for SOA of 'testtyje.nl' produced no results (RCode: Query Refused)

IP6 = IP of the server we added the domain on. IP1 till IP6 are all supermasters in the database with ns1.domain.com as their first nameserver (also in SOA record).

Hopefully this information is clear enough, please contact me if you need the real logging with real IP and names.

myH2Oservers commented 10 years ago

Some more info (forgot..)

Package from: https://www.monshouwer.eu/download/3rd_party/pdns/rc1/el7/x86_64/ Version: pdns-3.4.0rc1-2.el7.MIND.x86_64.rpm OS: up2date CentOS 7 64bit Backend: gmysql - this is actually MariaDB (!)

myH2Oservers commented 10 years ago

I have done additional testing and discovered that the master column in the domains table is (now) 128 characters big while it used to be only 20 characters, so it was in our database. I have corrected this to 128 characters and AXFR transfer was succesful now because the real master IP fitted in these 128 characters. However the reported issue still exists: it takes all IP addresses that have ns1.domain.com as nameserver in the supermasters table and use them all as masters. In our situation there were more masters then could fit in 128 characters and thus the record wasn't completely stored in the database. It also means that all servers that use ns1.domain.com are now master for this domain, so if the domain is added on a 2nd server it will overwrite the records with it's DNS data.

myH2Oservers commented 10 years ago

My feeling says that this problem is related to: https://github.com/PowerDNS/pdns/issues/632

Any idea when this will be fixed? 3.4 is the only version that run on CentOS 7 without problems. If fixing takes a couple of weeks we will go back to CentOS 6 and use the older non-rc version.

Habbie commented 10 years ago

Are you in a position to try the patch from #1710?

myH2Oservers commented 10 years ago

Not yet, I went back to CentOS 6 and used a stable version for now. I can test it on our old server after it is phased out. However looking at the patch I wonder: is the supermasters.account information available when the AXFR transfer is being executed? Why not take the IP address of the server that does the AXFR transfer as the master (like it used to be?).

Habbie commented 10 years ago

We used to take just that IP address, but this was suboptimal for dual stack setups; this is why we switched to taking all addresses for a given nameserver name. Now, I understand how this breaks things for your setup. When we merge #1710, you can use the account field to distinguish between your customers, and make sure you don't mix up their masters.

Please let me know if you see problems with the approach in #1710; otherwise, I will merge it before 3.4.0.