AXFR, IXFR and NOTIFY

In front of primaries

When dnsdist is deployed in front of a primary authoritative server, it might receive AXFR or IXFR queries destined to this primary. There are two issues that can arise in this kind of setup:

• If the primary is part of a pool of servers, the first SOA query can be directed by dnsdist to a different server than the following AXFR/IXFR one, which might fail if the servers are not perfectly synchronised.
• If the primary only allows AXFR/IXFR based on the source address of the requestor, it might be confused by the fact that the source address will be the one from the dnsdist server.

The first issue can be solved by routing SOA, AXFR and IXFR requests explicitly to the primary:

newServer({address="192.168.1.2", name="primary", pool={"primary", "otherpool"}})
addAction(OrRule({QTypeRule(DNSQType.SOA), QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}), PoolAction("primary"))

The second one might require allowing AXFR/IXFR from the dnsdist source address and moving the source address check to dnsdist’s side:

addAction(AndRule({OrRule({QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}), NotRule(NetmaskGroupRule("192.168.1.0/24"))}), RCodeAction(DNSRCode.REFUSED))

Changed in version 1.4.0: Before 1.4.0, the QTypes were in the dnsdist namespace. Use dnsdist.AXFR and dnsdist.IXFR in these versions. Before 1.4.0, the RCodes were in the dnsdist namespace. Use dnsdist.REFUSED in these versions.

A different way would be to configure dnsdist to pass the source IP of the client to the backend. The different options to do that are described in Passing the source address to the backend.

Warning

Be wary of dnsdist caching the responses to AXFR and IXFR queries and sending these to the wrong clients. This is mitigated by default when the source IP of the client is passed using EDNS Client Subnet, but not when the proxy protocol is used, so disabling caching for these kinds of queries is advised:

-- this rule will not stop the processing, but disable caching for AXFR and IXFR responses
addAction(OrRule({QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}), SetSkipCacheAction())
-- this rule will route SOA, AXFR and IXFR queries to a specific pool of servers
addAction(OrRule({QTypeRule(DNSQType.SOA), QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}), PoolAction("primary"))

Changed in version 1.8.0: Since 1.8.0, dnsdist will no longer cache responses to AXFR and IXFR queries.

In front of secondaries

When dnsdist is deployed in front of secondaries, however, an issue might arise with NOTIFY queries, because the secondary will receive a notification coming from the dnsdist address, and not the primary’s one. One way to fix this issue is to allow NOTIFY from the dnsdist address on the secondary side (for example with PowerDNS’s trusted-notification-proxy) and move the address check to dnsdist’s side:

addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(NetmaskGroupRule("192.168.1.0/24"))}), RCodeAction(DNSRCode.REFUSED))

Changed in version 1.4.0: Before 1.4.0, the RCodes were in the dnsdist namespace. Use dnsdist.REFUSED in these versions.

Warning

Be wary of dnsdist caching the responses to NOTIFY queries and sending these to the wrong clients. This is mitigated by default when the source IP of the client is passed using EDNS Client Subnet, but not when the proxy protocol is used, so disabling caching for these kinds of queries is advised:

-- this rule will disable the caching of responses for NOTIFY queries
addAction(OpcodeRule(DNSOpcode.Notify), SetSkipCacheAction())