After receiving NOTIFY on a secundairy IP powerdns uses the primary IP for the zone transfer

[dekker-m]

Last week I noticed some behavior which I did not expect regarding NOTIFY/zone transfers. We use some kind of a hidden master setup for one of our DNS clusters. The diagram below shows a similar network setup.

host1 ----\                                                /----- NOTIFY ---- ns1
           \                                              /
host2 --------> NOTIFY ----> (IP2) | Hidden master | (IP1) ---- NOTIFY ---- ns2
           /                                              \
...   ----/                                                \---- NOTIFY ---- ns3

1. The host1, host2, ... all run local DNS servers with master zones (non-powerdns). They are configured to send the NOTIFY message to IP2 and allow zone transfers from IP2.
2. The hidden master has two IP addresses on the same ethernet card.The hidden master is PowerDNS.
3. The servers ns1, ns2 and ns3 are all PowerDNS, configured with the hidden master as their supermaster. The hidden master sends NOTIFY messages to this servers.

In this setup, IP1 is the primary IP for this server and IP2 is the secundairy IP. IP1 is configured as the supermaster in the ns1, ns2 and ns3. The host1, host2, etc. are configured to NOTIFY the hidden master on IP2. So far, so good, but here is where the problem starts.

Once the hidden master receives a NOTIFY on IP2, is starts the zone transfer, but it tries to executes the zone transfer from IP1. I would have expected that a DNS server will execute the zone transfer from the same IP on which it received the NOTIFY query.

The RFCs do not seem to mention anything on this behavior, but personally, I would think it makes sense to use IP2 in this case as the source of the zone transfer. In fact, the other server is probably configured to accept zone transfers from this IP.

I know you can modify the IP from which PowerDNS will sent ALL of it's queries. But this makes it impossible for ns1, ns2 and ns3 to receive the NOTIFY queries from IP1.

Suggested solution: Execute the zone transfer from the same IP as the notify query is received on. In addition, store the local IP on which the NOTIFY was received for executing future zone transfers (in case the zone needs a zone transfers after the SOA refresh has expired and the master's SOA serial record has changed for this zone.)

[rgacogne]

Perhaps the AXFR-SOURCE metadata option 1 might be of help here, at least as a workaround.

[dekker-m]

The AXFR-SOURCE metadata would indeed be a workaround. However, it will only work for existing domains and not new domains which are accepted because the source IP is a supermaster. Those domains will not be in the database. For existing domains a trigger for the domains table can be added so the domains will automatically add the AXFR-SOURCE metadata.

Can you think of a workaround for new domains which should be accepted because the source IP is a supermaster?

[dekker-m]

Just ignore my previous comment ;-)

I just added a trigger to the domains table and it seems to work like expected. For those who have a similar problem, I used the following trigger for MySQL:

DELIMITER |

CREATE TRIGGER `insert_axfr_source` AFTER INSERT ON `domains`
  FOR EACH ROW
  BEGIN
    INSERT INTO `domainmetadata` (`id`, `domain_id`, `kind`, `content`) VALUES (NULL, NEW.id, 'AXFR-SOURCE', 'YOUR-IP-HERE');
  END;
|

Keep in mind, this will add the AXFR-SOURCE to all domain types (MASTER/SLAVE/NATIVE). If you wish to only insert this metadata for SLAVE domains you should add an IF statement in the domains.

[Habbie]

If you want this on all domains, why not set query-local-address in pdns.conf instead?

Also, closing this as I understand your problem is solved.