DDNS, Notify and IXFR
Brad Knowles
brad at shub-internet.org
Thu Aug 12 17:10:57 UTC 1999
At 9:48 AM -0700 1999/8/12, Kevin J. Dunlap wrote:
> When you start seeing the fan out of the packets you start to wonder if
> this sequence of events will start to consume the network. One
>update packet goes
> from the originator to each of the five name servers. The primary
>ends up sending a
> packet to the other four name servers. Those four send an IXFR
>request to the primary.
> These generate four more notifies that start four more IXFRs. And
>the loop continues.
There would appear to be a fallacy in your logic -- the IXFRs
don't actually cause more zone updates and therefore more NOTIFYs and
therefore more IXFRs, they just happen to occur at about the same
rate as the updates, so you instead end up with:
Dynamic update notifies the primary
Zone is updated and serial number is incremented
NOTIFYs get sent out to all secondaries
Secondaries start doing IXFRs
Now, this does end up happening once every four or so seconds, so
all that IXFR traffic would definitely cause a heck of a lot of
interrupts and generate a heck of a lot of traffic. So, this is
still a problem -- not just quite the scale you were thinking of.
For myself, this is why I would like to see the ability to
directly interface BIND to a back-end database system such as Oracle
or Sybase -- let OPS or Sybase deal with the data update and
replication issues, and then let BIND deal with the issues of serving
that information via UDP and TCP on port 53 (or whatever port you've
configured them to listen on).
--
Brad Knowles <brad at shub-internet.org> <http://www.shub-internet.org/brad/>
<http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xE38CCEF1>
Your mouse has moved. Windows NT must be restarted for the change to
take effect. Reboot now? [ OK ]
More information about the bind-workers
mailing list