Home / server / Questions / 693403
Accepted
TCB13
Asked: 2015-05-21 11:09:27 +0800 CST

Bind9: Master->Slave Notify IPv6 with fallback to IPv4

  • 772

I've a small Master->Slave DNS scheme setup between two machines running Debian 8 + Bind9 in dual IP stack.

The master and the slave both own an IPv4 and IPv6 used by bind, enfored by the configuration parameters listen-on listen-on-v6 transfer-source transfer-source-v6 notify-source notify-source-v6 query-source address query-source-v6 address.

Currently my master is set to notify the slave as:

notify yes;
also-notify { xxxx:xxxx:xxxx:xxxx::xxx5; x.x.x.5; };

As my slave has on a zone configuration something like:

zone "example.dev" {
    type slave;
    masters { xxxx:xxxx:xxxx:xxxx::xxx2; x.x.x.2; };
    file "...";
};

This setup works fine, however by inspecting the log files (and as I expected) the master is notifying the slave twice on every zone change:

May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from x.x.x.2#52041: zone is up to date
May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from xxxx:xxxx:xxxx:xxxx::xxx2#51347: zone is up to date

One time, over IPv4 and another over IPv6.

Is there a way I can tell the bind server that xxxx:xxxx:xxxx:xxxx::xxx5 x.x.x.5 are indeed addresses for the same DNS server and try to notify it first over IPv6, and if it fails retry over IPv4? Also, how to do the same thing on the salve masters declaration?

Thank you.

bind

1 Answers

  1. Best Answer

    I don't believe there is a configuration option that will do what you ask for. However, I also don't believe that the double notifications is really any cause for concern.

    While it is redundant in this configuration, the overhead it leads to is minimal and typically no problem at all.

    Generally speaking, receiving multiple notify messages is not outside the norm, originally mainly from master + other slaves but now also dual-stack hosts, to the point where even the original spec expected this:

    4.2. Each slave is likely to receive several copies of the same NOTIFY request: One from the primary master, and one from each other slave as that slave transfers the new zone and notifies its potential peers. The NOTIFY protocol supports this multiplicity by requiring that NOTIFY be sent by a slave/master only AFTER it has updated the SOA RR or has determined that no update is necessary, which in practice means after a successful zone transfer. Thus, barring delivery reordering, the last NOTIFY any slave receives will be the one indicating the latest change. Since a slave always requests SOAs and AXFR/IXFRs only from its known masters, it will have an opportunity to retry its QUERY for the SOA after each of its masters have completed each zone update.

    • 4