Suppressing duplicate notify

Jim Reid jim at rfc1035.com
Thu Mar 2 18:10:16 UTC 2000


>>>>> "Henri" == Henri J Schlereth <henris at neandertal.org> writes:

    Henri> I dont know if I posted this before but here is the
    Henri> question.  This deals with an internal network. If I put in
    Henri> an NS record for the slave server I get the following:

    Henri> Mar 2 09:59:34 kesrith named[2294]: suppressing duplicate notify ("neandertal.org" IN SOA)

    Henri> Removing the NS record makes the message go away. Does this
    Henri> imply that the NS records must be for masters only? BTW the
    Henri> named.conf insures that the slave gets the notify anyway,
    Henri> so nothing is really broken, I am just curious.

Your named.conf is not quite right. In BIND, the master name server
sends NOTIFY messages to the IP addresses of the zone's NS records.
[NS records should exist for most (all?) of the authoritative name
servers for the zone: not only its master server.] So if your
named.conf has also-notify clauses, these could be redundant. The name
server already knows from the zone's NS records who it needs to
NOTIFY. It would be better to keep the zone's NS records and remove
the (unnecessary) also-notify clauses rather than the other way
round. NS records matter to the rest of the world's name servers. The
also-notify clause matters only to your name server and is probably
not needed anyway. Most people use also-notify for fast propagation of
zone changes to "stealth" name servers.

The log message above is the name server telling you that it's figured
out that it would be sending a second NOTIFY to the same name server.
This is a subtle way of telling you that there is an inconsistency
between named.conf and the zone's NS records.



More information about the bind-users mailing list