notify problems and issues on 8.2.4 (long)

[Brad Knowles]

At 11:04 PM -0400 6/26/01, Mark Jeftovic wrote:

>  Note that these came from the other two slaves, not the primary.
>  Still though, the new address didn't kick in on this box. After
>  waiting a few minutes and nothing happening, I manually reloaded
>  the zone and the change kicked in right away (rather than waiting
>  for the refresh to occur)

	Note that the DNS primarily uses UDP, which is an unreliable 
protocol -- sometimes, packets get dropped or munged, and if this 
happens with all the retransmissions, the NOTIFY to a particular 
machine may get lost.

	The only purpose of NOTIFY is to give the secondaries a chance to 
update more quickly, once the domain has changed, and therefore it 
should not be a big deal if they get lost.  If it is a big deal if 
they get lost, you've got something wrong with your zone TTL 
settings, and you need to adjust those.


	Moreover, syslog also uses UDP, and I've seen as much as 75% of 
all syslog data get lost and thrown away, on a busy network.  To make 
sure you're not losing log data, you should have BIND log directly to 
a file and avoid syslog.

>  1) what factors govern the speed at which the notifies get sent, are
>  there tunable parameters, are there any tips for optimizing servers for
>  large numbers of zones so that notifies go out quickly?

	I don't believe that there are any tunable parameters.

>  2) are the formats of the notify log entries documented anywhere?

	Chapter 10, section 2 of third edition of _DNS & BIND_ (by Paul 
Albitz and Cricket Liu, published by O'Reilly & Assoc.) is the only 
indexed reference entry for NOTIFY.  This information is expanded on 
in Chapter 10 from fourth edition of _DNS & BIND_, but there doesn't 
seem to be any particular indication in either edition regarding the 
NOTIFY log format.

>  3) assuming the current number of named_xfers in progress < transfers_out
>  on the primary and < transfers_in on the slave, why wouldn't a slave pick
>  up an update after receiving a notify?

	Dunno.  It's hard to say.  You might have the NOTIFY being sent 
out by the master, but not received by the slave.  However, if you've 
got your "refresh" and "retry" intervals set properly, it should 
still periodically check in on a sufficiently frequent basis and 
validate that the SOA serial number hasn't changed, and if so update 
its copy of the zone.  If not, you need to modify these values in 
your SOA records for your zone(s).

>  4) under what circumstances do the slaves also send notifies to the other
>  slaves?

	I'm not aware of any.  Not unless you configured "also-notify 
10.1.2.3" in the /etc/named.conf on the secondary in question.

>  5) why are notifies for a zone that hasn't been modified in months
>  floating around?

	Remember, UDP is trivially easy to forge, so it may be someone 
trying to perform a DoS attack on your server.  Since this 
information cannot be trusted, all that happens is that a secondary 
that receives a NOTIFY, is that it sends back a NOTIFY response to 
the master named in the DNAME field of the SOA record, and then it 
schedules an update (as if the "refresh" interval had expired) to 
check to see if the SOA serial number has changed, and if so then it 
will schedule a transfer of the zone.  NOTIFY is purely advisory.

>  Any pointers on some or all appreciated, thanks for reading this far.

	If you're running into problems with too many copies of 
named-xfer running, or where your nameservers are not answering 
queries during the long start-up phase, you should upgrade to BIND 9. 
It handles zone transfers internally, and since it's multi-threaded, 
it will start answering queries immediately, while background threads 
continue to load the zones.

-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'