From 0723468aa624c75c1b1384e9fadcf3664e7ded18 Mon Sep 17 00:00:00 2001 From: Remi Gacogne Date: Mon, 24 Jul 2017 10:45:50 +0200 Subject: [PATCH] dnsdist: Add AXFR instructions to the new docs --- pdns/dnsdistdist/docs/advanced/axfr.rst | 30 ++++++++++++++++++++++++ pdns/dnsdistdist/docs/advanced/index.rst | 1 + 2 files changed, 31 insertions(+) create mode 100644 pdns/dnsdistdist/docs/advanced/axfr.rst diff --git a/pdns/dnsdistdist/docs/advanced/axfr.rst b/pdns/dnsdistdist/docs/advanced/axfr.rst new file mode 100644 index 000000000..574714a12 --- /dev/null +++ b/pdns/dnsdistdist/docs/advanced/axfr.rst @@ -0,0 +1,30 @@ +AXFR, IXFR and NOTIFY +===================== + +When :program:`dnsdist` is deployed in front of a master authoritative server, it might receive +AXFR or IXFR queries destined to this master. There are two issues that can arise in this kind of setup: + +- If the master is part of a pool of servers, the first `SOA` query can be directed + by :program:`dnsdist` to a different server than the following AXFR/IXFR one, which might fail if the servers + are not perfectly synchronised. +- If the master 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 :program:`dnsdist` server. + +The first issue can be solved by routing SOA, AXFR and IXFR requests explicitly to the master:: + + newServer({address="192.168.1.2", name="master", pool={"master", "otherpool"}}) + addAction(OrRule({QTypeRule(dnsdist.SOA), QTypeRule(dnsdist.AXFR), QTypeRule(dnsdist.IXFR)}), PoolAction("master")) + +The second one might require allowing AXFR/IXFR from the :program:`dnsdist` source address +and moving the source address check on :program:`dnsdist`'s side:: + + addAction(AndRule({OrRule({QTypeRule(dnsdist.AXFR), QTypeRule(dnsdist.IXFR)}), NotRule(makeRule("192.168.1.0/24"))}), RCodeAction(dnsdist.REFUSED)) + +When :program:`dnsdist` is deployed in front of slaves, however, an issue might arise with NOTIFY +queries, because the slave will receive a notification coming from the :program:`dnsdist` address, +and not the master's one. One way to fix this issue is to allow NOTIFY from the :program:`dnsdist` +address on the slave side (for example with PowerDNS's `trusted-notification-proxy`) and move the address +check on :program:`dnsdist`'s side:: + + addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(makeRule("192.168.1.0/24"))}), RCodeAction(dnsdist.REFUSED)) + diff --git a/pdns/dnsdistdist/docs/advanced/index.rst b/pdns/dnsdistdist/docs/advanced/index.rst index 212ee45ba..c16d04e27 100644 --- a/pdns/dnsdistdist/docs/advanced/index.rst +++ b/pdns/dnsdistdist/docs/advanced/index.rst @@ -15,3 +15,4 @@ These chapters contain information on the advanced features of dnsdist ebpf tuning snmp + axfr -- 2.50.1