Subject: [dnsext] single-ton AXFRs, was Re: -10

From: Alfred Hönes <[email-masked]>
Date: Fri, 13 Feb 2009 01:03:35 +0100 (MEZ)

At Thu, 12 Feb 2009 16:11:24 -0500 , Edward Lewis wrote:

> In going through some noted from Alfred...
>
>>> What is done about old servers that put one RR per message into AXFR
>>> responses?  How does this play with the words about complete RR sets?
>
> At 11:40 +1100 12/31/08, Mark Andrews wrote:
>
>>      The answer is the set of messages which make up the AXFR
>>      response.  As long as the set of messages contains the
>>      complete RRset there is no problem.
>
> The question is how do we patch up this inconsistency?:
>
> ... [quote from RFC 2181, section 9 stripped off]
>
> This says an incomplete RRSet triggers a TC bit.
> Should AXFR clarify say that DNS clarify's words on TC setting
> to not apply to AXFR?

The TC rules of RFC 2181, section 9, seem to be not 100% applicable,
since AXFR already operates on a TCP connection; as such, a signal
to switch to TCP does not make sense.

The basic question I cannot answer is:
After all the software updates performed in the recent past,
how many servers are still deployed that exhibit that bad behavior?

I strongly suspect that it can be expected that the authoritative
servers for a zone are (at least) to some degree under cooperative
management, and for many many zones today AXFR is administratively
restricted to this group, or a slightly larger group of AXFR clients.

However the strong guideline from RFC 1034 to always send entire
RRsets in the Answer Section pertain, and the use of 'single-ton'
or otherwise overly short AXFR response messages is a rather bad
and inefficient behavior that should not be encouraged.

Therefore, I suggest -- and IIRC the WG consensus on that point
already had been achieved --, that new AXFR server implementations
SHOULD conform to this general requirement and MUST NOT set the
TC bit in any case.
For "turnkey DNS implementations" (cf. section 1.2 of the AXFR draft)
supporting AXFR, this even could be stated as a MUST.
For "general purpose DNS implementations" we might conclude that
the population of deployed AXFR clients still warrants a MAY for
the 'single-ton' behavior, based on configuration and/or adaptive
behavior (if the AXFR server indeed wants to maintain client state),
but we should emphasize that this MUST NOT be the default behavior.

In support of Postel's Principle, I suggest that it would be wise
to request that _all_ AXFR clients MUST ignore the TC bit and
SHOULD accept the zone data split into any (otherwise legal) sets
of entire resource records per AXFR response message, as only the
concatenation of all the RRs in these Answer sections counts --
after removal of the duplicate SOA RR from the last resonse message
it must represent the zone content, and that is independent of its
partitioning for transfer.

The quote from Mark above should perhaps be read as:
>>            ...  As long as the set of messages contains the
>>      complete RRset^W _collection of RRsets_ there is no problem.

Kind regards,
  Alfred.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>