[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AXFR "clarify"
Edward Lewis wrote:
At 21:34 -0500 1/18/08, Brian Dickson wrote:
Edward Lewis wrote:
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.
Specifically, what change? Before expecting that a change is going to
be made because it is suggested, keep in mind "it had better be a
gooood, really good change."
The clarification being discussed in this thread. For example, language
consistent with the following:
"To clarify the intent of 1034/1035, which says that once data is in the
domain name system, its case should be preserved. AXFR and IXFR are
transfers *within* the domain name system, server-to-server, and as
such, SHOULD preserve case."
"This is contrasted with client-server (true client to caching resolver,
or recursive resolver to server), where query and DNS data are compared
in a case-insensitive manner, and the responses to queries may differ in
case. Clients MUST handle answers which differ in case from queries."
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.
In my opinion, the deployed base rules in this case. I don't see any
consumer of DNS services (such as web site hosters, tld operators,
home hobbyists) howling that they cannot locate DNS implementations
that do AXFR. In my opinion, and why I am motivated to do this, is
that it is the specification that is lacking. Keep in mind my concern
is addressing RFPs and not writing a new implementation.
RFPs may be *your* concern, but the membership of the WG will vote your
document up/down based on *their* concerns, if I understand how things work.
IMHO, I believe that any clarification to an existing set of RFCs should
reflect the general purpose of the WG, which is to produce RFCs which
can be used by implementers.
This MUST include new implementations, if the WG is "active", rather
than "maintenance". And that is the case for this WG.
The IETF is all about interoperability and I don't hear that this is
lacking in the AXFR space. That is why, to me, the current code base
rules.
I believe that Mark Andrews has already expressed the need for
addressing the need for case-sensitivity for AXFR, and that suggests an
interoperability specifically on AXFR and IXFR.
It is not possible to make a clarification on AXFR without addressing
the interoperability related to IXFR.
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.
I don't think this is a a point of contention but I want to set
expectations by at least revealing my interpretation of the
situation. I am for tightening up the requirements in the sense that
they reflect reality. I am not for raising the bar on functionality.
If language tightening improves interoperability, and nothing else, then
I do not believe that adds functionality.
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.
I think the rationale for, and the case against, compression has
already been laid out in previous documents. Compression isn't an
AXFR issue though, it's a general message processing issue. Lip
service is all I would put towards it in the document.
I don't see how tightening language on *how* one should or should not do
compression, changes the arguments about compression itself.
The real question is, when should case differences be expected, and when
should they not?
A query of any type other than AXFR or IXFR, will include a domain name.
The answer necessarily will return data which may differ only in case.
The originator (who made the query) MUST handle that case issue, because
the information regarding case is not know prior to making the query.
However, for an IXFR, there is no data in the query, other than the
parent zone.
It should not be the case that case gets changed on zone data, and the
*cost* of doing the comparison scale by the size of the data set.
And most importantly, interoperability requires either that case is
preserved, or that case mangling gets handled.
Not specifying the requirement on case, makes the choice of these two
ambiguous - but they are mutually exclusive.
Regardless of which way it *gets* clarified, it *needs* to be clarified.
Having case preserved specifically on XFR, is something much more
important
than any normal query/answer data.
I don't think that it is as simple as that.
I can paint a scenario in which an "ordinary" response's mashing of
capitalization results in more stub resolvers getting "incorrectly"
capitalized answers than the mashing done in an zone transfer.
E.g., a lookup from a large consumer-serving ISP for a high-traffic
on-line retainer will cause a cache entry that will get jillions of
hits before it times out. There are some TLDs that won't get even a
smidgen-of-a-jillion queries in the same time.
This is why I say it's not particular to AXFR.
Correct - but the client MUST handle the case difference (on non-AXFR or
-IXFR) between the query and answer. Existing RFCs make this clear.
So, there are two issues I see:
* whether is is important to *clarify* that either case preservation
must be done, or alternatively, may *not* be done (explicitly)
* if so, which it is: that case preservation MUST be done; or that case
preservation MAY NOT be done.
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/>