[dns-operations] unrelated to Re: Recommended zone serial number format for over 100 changes / day

[Edward Lewis]

I really ought to be doing other work today than answering this thread. ;)

On 4/4/16, 12:08, "dns-operations on behalf of Colm MacCárthaigh"
<dns-operations-bounces at dns-oarc.net on behalf of colm at stdlib.net> wrote:

>Otherwise the zone may end up black-holed.

One of the perennial issues in zone transfers is "what happens if the
client of the XFR gets confused?" IOW, if a slave gets a version of the
zone from the master and it contains records that should have special
meanings to the DNS algorithms but the slave doesn't realize it.

The first stipulation of selecting the set of authoritative servers is
that all of them are capable of performing whatever version/style of DNS
service you want.  DNSSEC or not?  ANAME or not?  Whatever otr not?  If
you insist on using a BIND 4 server, you're gonna get what you're gonna
get.

In the AXFR client-server mechanism, what a client does when it gets in a
snit is defined in section 6 of the AXFR RFC (5936).  The relevant text is:

'...upon successful completion of the AXFR operation and some sanity
checks, this data set is "loaded" and made available for serving the zone
in an atomic operation, and flagged "valid" for use during the next
restart of the DNS server; if any error is detected, this data set MUST be
deleted, and the AXFR client MUST continue to serve the previous version
of the zone, if it did before.'


The phrase I'll draw attention to is "some sanity checks."  These are not
defined in the document as they would be subject to "local policy."  (I've
since learned never to leave such phases laying around.)  The reason the
sanity checks are not defined here is that this may be the case:

1 - the client might be attempting to be an authoritative server (listed
in the NS set) and therefore ought to know all the relevant,
algorithm-impacting RR types for that zone (like DNSSEC).  There might be
a few sanity checks to carry out (not proposing any).

OR

2 - the client might be something archiving the zone for
historical/logging reasons and not care what the meanings of the RR types
are.

The sanity check in the former would be that it knew how to serve the
zone, the latter the sanity check would be pretty much a no-op.

Of course, 'no server knows what it doesn't know', limiting the kind of
sanity checks one might dream of.  If a zone has NSEC17 in it because
that's the new way to produce negative answers based on on-the-fly
signature generation[*], and if the server is BIND 8.4.3, the sanity
checks won't even think to include "if the zone has NSEC17, dump the
update".

The only way out of a mess is - if the server thinks it can serve it, try
and have the admin discover the problem.  If the server thinks it can not,
drop it and let the zone expire if no valid update comes along.  In either
case, this is something an administrator can discover, debug, and recover
on their own.  This is an administrative issue.

[*] I made that up, there's no NSEC17[2].  Don't go looking for it in an
RFC or some operator's PR's.
[2] Yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160404/5e0101db/attachment.bin>