[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AXFR "clarify"

Edward Lewis wrote:

At 15:50 +1100 1/18/08, Mark Andrews wrote:


    I said *allows* for innovation.
When it comes to tightening up a requirement like you mention, I think that we need to hear from more implementers that such a change is desired. 


Such a change is desired.
Correct me if I'm wrong, but it doesn't matter what the deployed base is, or the state of the software, or where or how it's used. Anyone doing any kind of implementation, for any purpose, of RFC 1034/1035/1995/1996 has a chip in the game. Like me. 
I vote for tightening up requirements.
In 1034/1035, the language is "should" (lower case). At a minimum it should be "SHOULD", and preferably "MUST". (The irony of the case comparison between "should" and "SHOULD" is not lost on me.)
I see no reason that the language describing the behavior (recommending against changing case on rdata) should be ignored, and the RFC text near that language, even contemplates potential reasons for this. 
    Actually it isn't.  The worst thing the IETF can do is produce
    wishy washy specification.
Which it already has done. The worst next thing is to break the world we built on a bad foundation. 


Just like the data described in the protocols (like 822):
(IMHO) Maintainers of RFCs should be liberal in what they accept, and strict in what they send.
If you are updating an RFC, the worst thing you can do is weaken a specification. In fact, it could/should be argued, that when the opportunity to tighten up language *known* to be ambiguous, that it SHOULD be done. RFCs do not get updated that often, and this RFC is rather important 
to the health of the Internet.


    People DO care about this.  I've got the bug reports to
    prove it.
This is the first I have heard of it. Anyone else? And in that vein, a soapbox moment:
I want to issue this challenge to the implementers on this list. A lot is heard about ISC's BIND experience. ISC has been energetic in contributing to the process. But the volume of the contribution sometimes backfires, and one victim has been the axfr-clarify document. To make a clarification, or an updated definition, have merit it needs to be based on a broad spectrum of implementation experiences.
The goal is not to declare, by default, the BIND way of doing DNS as a standard. The goal is an interoperable definition. The experience of BIND yields a wealth of information to us, and that's valuable input. The question is how can the document benefit from the BIND reports without becoming BIND centric? The answer is to have input and reactions from other implementations. 
I humbly disagree
The issue is strictly interoperability between implementations, which needs to be based on very strong RFCs. 

Interoperability is particularly critical for AXFR and IXFR.
Inadequately specifications can (and will, and may in the past have) lead to problems directly as a consequence of implementation choices which are incompatible. And just as important - tightening up the RFCs lowers the barriers to new implementations which will interoperate with existing implementations. New implementations are important to ensuring a healthy diversity of available code for operators. 

Diversity is critical to protecting infrastructure.
Single implementation populations are vulnerable to zero-day issues, which for DNS is not a reasonable situation. 

Case in point:
AXFR/IXFR are special, because of the need/desire to achieve performance optimizations due to the volume of data, and the fact that both ends are authority servers.
Consider a small mesh of servers, which for redundancy reasons includes multiple implementations. Data originates at a true, hidden master "M". Servers use software implementations, call them "B" and "N". 

It is quite conceivable that [AI]XFR paths could look like:

M-N-N-B
 \            \
   B-B-B-B(client)
If the software "B" includes optimizations to determine the fingerprint of the upstream XFR sender, and quite reasonably assumes that case will be preserved on the XFR, it can then do simple binary comparison of labels, rather than a much slower byte-by-byte case-insensitive comparison.
However, if "N" does case-smashing, then the two paths will contain XFR data which differs in case, but is otherwise identical.
This *will* break the optimization. At the "client", the data from "N" path will be compared against data from the non-"N" path. Binary comparison of different-case data will fail, and zone data corruption is likely to occur (duplicate rdata differing only by case, specifically).
(I will avoid naming names, but this exact situation *has* occurred in the past, in production zone data, so it's not just hypothetical.)
Having case preserved specifically on XFR, is something much more important than any normal query/answer data.
And, IMHO, special attention SHOULD be paid to this, possibly specifying case preservation as a "MUST".
The *proper* place to do case-smashing is on the master (e.g. when data is imported into the DNS system), after which the issue can be viewed as moot.
If the data prior to XFR is single-case, then problems can't be introduced by trying to optimize case, nor is there any *need* to do case optimizations. 

Brian Dickson

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