also-notify - how long should it take?

[Michael Bryan]

icculus4128 at my-deja.com wrote:
> 
> No, this doesn't appear to be the case. The next morning, the data had
> been tranferred to the seondary server.

That is most likely caused by they slave checking every 12 hours to
see if the johnstewart.com domain has changed.  (That's controlled
by the "refresh" parameter in the SOA record for the domain, which
you currently have set to 12 hours.)  This has nothing to do with the
NOTIFY feature, it appears that for whatever reason, NOTIFY is not
working for you.

> So the notify does seem to work, I think the question is how long the
> update should take?

It should happen in less than one minute in normal circumstances.  Heavy
traffic or CPU load might affect that, of course.  If it took several hours
for the update to go through, the NOTIFY did not work, and your slave server
just did it's periodic refresh function.

> I was under the impression (again, based on the limited documentation
> I've been able to find - the latest O'Reilly BIND book predates the
> also-notify feature apparently - can anyone recommend something more
> verbose than the README file?) that the xfer should be triggered
> immediately - otherwise what's the point?

Try the online documentation.  A copy of it is included in the doc tarball for
the BIND distribution, or you can read it here:

	http://www.isc.org/products/BIND/docs/config/

At this point, you'll need to do some low-level debugging to see what's
going on.  If you have a packet sniffer or a firewall that will log packets
matching a certain type, you should watch to see if the NOTIFY packet gets
sent by the master, and if it gets received by the slave.  You can also use
the "ndc trace" function on both systems to enable debugging, update the zone,
and then watch to see what happens on each system.  (The debugging output
can get lengthy, so be sure you use "ndc notrace" after you're done.)

The debugging output on the master side should have a line like this when
it sends out the notify:

Sent NOTIFY for "xxxxxx.com IN SOA" (xxxxxx.com); 3 NS, 3 A

The debugging output on the slave side should look something like this if
it receives the NOTIFY:

datagram from [10.2.3.4].2697, fd 20, len 28
rcvd NOTIFY(xxxxxx.com, IN, SOA) from [10.2.3.4].2697
qserial_query(xxxxxx.com)
sysquery: send -> [10.2.3.4].53 dfd=4 nsid=59400 id=0 retry=960601680
qserial_query(xxxxxx.com) QUEUED
next maintenance for zone 'xxxxxx.com' in 67016 sec
ns_req: answer -> [10.2.3.4].2697 fd=20 id=28907 size=28
datagram from [10.2.3.4].53, fd 4, len 204
qserial_answer(xxxxxx.com, 2000060906)
qserial_answer: zone is out of date
startxfer() xxxxxx.com
/usr/libexec/named-xfer -z xxxxxx.com -f slave/xxxxxx.com.db -s 2000060905 -C 1
-P 13568 -d 1 -l xfer.ddt 12.16.212.5


Also, your name server (dns.heurikon.com) is running version 8.2.1 of BIND,
which is an out of date version with known security problems, including the
ability for anybody to gain root access on your system.  See this web page
for more information:

	http://www.isc.org/products/BIND/bind-security-19991108.html

You should upgrade to 8.2.2-P5 immediately, and you should also try to determine
if somebody has broken into that server.  (Or just assume it has been rooted, and
wipe/reload the system anyway.)  There were a number of other bug fixes between 8.2.1
and 8.2.2-P5, as well, some of them dealing with NOTIFY, and you might find that
your systems work ok after upgrading the software.