notify option does not work in Bind 9.x, is this a known bug?

Jim Reid jim at rfc1035.com
Mon Feb 21 03:27:43 UTC 2005


>>>>> "Steven" == Steven Job <list3 at wwwcrazy.com> writes:

    >> Yes. Switch off NOTIFY on all the servers except the master. On
    >> the master, use an explicit also-notify{} list so that the
    >> NOTIFYs go to all the servers in your anycast cloud. This list
    >> will of course contain the real IP addresses of the servers,
    >> not their anycast address(es).

    Steven> This is what I have done.  But none of the servers in the
    Steven> "also-notify" seem to be getting any of the NOTIFY
    Steven> messages. (and yes it is the real IP address and not the
    Steven> anycasted. ;-) )

Well in that case, it looks like you have found a bug. If the master
isn't sending NOTIFYs -- watch for them on the wire -- file a bug
report. If it is, there could be a network connectivity problem or
something that's blocking the traffic. Check too that the slaves are
doing their SOA refreshes to the right address. You might also want to
make sure that the correct source address is used on the outgoing
NOTIFYs from the master: notify-source is your friend.

    >> Or you could have a hierarchical NOTIFY scheme if there are
    >> lots of servers: ie a stratum N server sends NOTIFYs to X
    >> stratum N+1 servers and so on.

    Steven> Only 13 different locations to start.  Do you think I
    Steven> would need it at this level?  Put up two systems and at
    Steven> the second level and have one send to six and the other
    Steven> send to seven?

Probably not: it'll depend on your internal connectivity/bandwith and
topology. In other words, it depends on how quickly you want new zone
date to propagate (and how much) and what the throughput is on your
DNS infrastructure. Trying this hierarchical approach doesn't make
sense until you've got things working. ie If you have any anycast
set-up that's up and running, hierarchical NOTIFYs might be worth
considering if there are propagation concerns.

    Steven> I totally agree and I understand what IP anycast is.  I
    Steven> have just been having problems with getting a good anycast
    Steven> setup with 13 systems now (3 visible anycasted IPs).  And
    Steven> you are correct.  ANS was created after UltraDNS purchase
    Steven> GNS and it's software.

No it wasn't. Nominum's GNS ran ANS for 1-2 years before the
*business* was acquired by UltraDNS.

    Steven> But it was my understanding the UltraDNS
    Steven> purchased their platform from Nominum.  I was wondering if
    Steven> they did that since they had problems with the IP anycast
    Steven> on Bind.

Well since UltraDNS has always run its own implementation, they never
could have had anycast issues with BIND.

    Steven> I know that many of root name servers are anycasted but
    Steven> they really do not have that many zones.  Wondering if
    Steven> there is a limitation in Bind with this.  Or it is just a
    Steven> configuration problem on our end. ;-)

Since anycasting is orthogonal to the number of zones, I suspect you
have a configuration problem. Unless of course you're loading tens of
thousands of zones, each of which requires tens of NOTIFYs and this is
creating internal queue management problems for BIND: eg "too many"
pending NOTIFYs locks out some internal data structure or the server
can't send out the NOTIFYs fast enough or something like that.



More information about the bind-users mailing list