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