[nycbug-talk] dns slaves serve up empty data

[Miles Nordin]

>>>>> "ms" == Marco Scoffier <marcoscoffier at gmail.com> writes:

    ms> zone metm.org/IN: notify to 87.98.164.164#53: retries exceeded

I've never seen that before.

notifies are an optional part of the protocol to speed things up.  I'd
the impression they weren't even acknowledged, so I'm not sure why
they would be retried---I'd therefore not infer too much from the
soudn of the error message.

The mandatory way for slaves to operate, whether the master sends
notifies or not, is to poll your master for an SOA record on a period
specified by the 'refresh' timer in the SOA record they already have.
If they don't succeed, they begin polling on the 'retry' timer's
period, which is typically more frequent.  There's no exponential
backoff or anything like that.  notifies didn't used to be part of the
standard at all, and the whole process will work without them, so
don't overfocus on it.  

notifies could be broken in your environment if gandi doesn't in fact
use the single nameserver they expose to you.  It's possible to use a
slave as the master for another slave, so if they wanted (not sure why
they would), they could have one hidden server that sucks down all the
zones from their customers' masters, and then a network of exposed
slaves that sucks zones from that hidden zonesuck server.  In that
case, you'd send a notify to the exposed master, which might (I'm not
sure) say ``this notify's coming from the wrong source, so I'm
ignoring it.''  I don't think they do this weird arrangement---it's
just a reasonable example that breaks notifies, unless you manually
reconfigure your master.  and you'll never notice, because notifies
aren't actually needed: gandi is allowed to openly or accidentally not
support them.  really notifies go together with IXFR as a mechanism for
synchronizing dyndns updates.

Without notifies you will have to wait the 'retry' period after making
changes to the master for the slaves to poll again, although I'm not
absolutely certain slaves will respect SOA 'retry' on an expired
zone---they may use a fixed default polling timer which, without
actually knowing (I control all my slaves so I just 'rndc reload' or
ask my friend to do so), I would guess to be about an hour.

If you have been working on this for several days and writing all
these mails you probably have some effort to burn: why don't you try
setting up your own slave server on your laptop or something, and see
if you can get it to suck down the zone.  If you can't, fix it.  If
you can, check that gandi has the right IP for your master, and if
they do, get a different company to be your slave server.  (I like
gandi in general but have not used this feature of theirs.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20090731/da331a26/attachment.bin>