Re: RFC 2119 section 6

[Kevin Darcy <[e-mail]>]

Look, Dan, if AXFR clients are going to be a special case to the general
rule that DNS clients only look for direct answers to their question, when
definitively answered, in the Answer Section, then surely it makes more
sense to declare AXFR a separate protocol, with a separate port assignment,
than to declare every incremental extension to DNS, present and future,
which might happen to put RR's in the non-Answer sections of AXFR
responses, a separate protocol requiring a separate port assignment. Why
should the many suffer for the sake of the one? Yet I don't see you pushing
for AXFR to use a different port number. TSIG and EDNS0 are already with
us, and as far as I know it is legal for either or both to be transmitted
in an AXFR response; are you seriously suggesting that we already need 2
new port assignments, with more to be obtained as new extensions are
adopted? That's madness. It's obviously not scalable for all nameservers to
have to listen on a new port every time another protocol extension comes
down the pike. And do you really want to make a living hell for firewall
administrators who have to change the rulesets on all of their boxes every
time a new port is defined for general use?

The "ignore unexpected RR's" language of the clarify draft allows these
incremental extensions to reliably co-exist with AXFR without drastic
measures like forking off new port assignments. The only thing that is lost
is the opportunity for an AXFR client to be "section-agnostic", but you
have IMO fallen far short of demonstrating that "section-agnosticism" has
any practical value, let alone that its preservation is worth stunting the
evolution of extensions to the DNS protocol if and whereever those
extensions may coincidentally apply to AXFR responses. Between the two
types of interoperability under inspection here -- interoperability between
AXFR and protocol extensions, on the one hand, and interoperability between
non-standards-conforming servers and "section-agnostic"-wannabe clients, on
the other -- the type of interoperability which facilitates long-term
growth and evolution should be preferred.


- Kevin


D. J. Bernstein wrote:

> Kevin Darcy writes:
> > it's a perfectly reasonable assumption -- and a perfectly reasonable
> > interpretation of the original, unclear specification of AXFR -- that
> > the RR's of the zone will be in the Answer Section
>
> I agree. There's no dispute about this. AXFR _servers_ have to put all
> the records into the answer section. Any server that violates this rule
> will have interoperability problems with some AXFR clients.
>
> Now, given a stream of DNS messages, with empty authority and additional
> sections, how does the AXFR _client_ extract all the records?
>
> There are several methods that work. I'm using one. BIND uses another.
> The choice of method has no effect on interoperability. axfr-clarify is
> violating RFC 2119 section 6 by requiring a particular parsing method.
>
> > If I propose a FOOBAR extension tomorrow, which puts a new type of RR
> > in the Additional Sections of, among other responses, AXFR responses,
>
> Then you are an idiot. You are pointlessly breaking compatibility with
> working AXFR clients deployed at thousands of sites. Put your protocol
> on a new port, and stop demanding that I pay attention to it.
>
> > (let's not split hairs again over
> > whether an AXFR client is a DNS client or not)
>
> Zone transfers are requested by name servers. The zone-transfer protocol
> is described in RFC 1034 section 4: ``NAME SERVERS.''
>
> Resolution is requested by caches (``resolvers''). The resolution
> protocol is described in RFC 1034 section 5: ``RESOLVERS.''
>
> See RFC 1035, page 6, for a data-flow diagram showing the different
> roles of caches and name servers.





to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.