At 10:26 AM -0700 05/21/2004, Bob Atkinson wrote:
A serious concern I have with the above is its testability.
With this approach we'd be asking people to code to an eventuality that
won't show up for years. Query for a new RR type first, and if not
there, query for TXT: the first case will virtually never hit for years
and years to come.
I think this is seriously overstated. There will, no doubt, be available
domains with MARID RRs as soon as the type code has been assigned;
you've seen from the test scenarios posted that some sites have
no problems creating arbitrary RRs and populating their zones
with them. Those zones may not exercise all of the available
functions in a converged spec, but that can be tested separately.
A much more serious concern would be chaining--where there was
a requirement to test for MARID, then test for TXT RRs. As was
discussed in the meeting, this can be optimized such that the
queries are issued simultaneously with preference given to the
data in the MARID RRs returned. There are a small number of cases in
which a lost or delayed response means someone might start
processing based on the TXT response and then receive a
MARID response; I think those can be resolved (proceed with
the current based on TXT, for example, but cache MARID) and I don't
see it as a show-stopper.
And there's a real cost to asking people to code to this: basically
double the DNS query cost for the foreseeable future. And the benefit to
be gained from paying this cost is what, architectural purity?
There are several. As was discussed yesterday, a new RR could allow
UTF-8, where TXT is limited to US-ASCII according to RFC 1464; that
would make it easier deal with XML (since some other part of the
process would not have to enforce and mark the XML as US-ASCII).
TXT remains a common target of enterprise records, and avoiding
it means you will have less risk of packet overflow when inside
firewalls (Wayne's data yesterday pointed out that this was not
usually a problem with externally-facing authoritative resolvers,
but those are also not "behind firewalls" in the way the RPC-limited
ones described here are).
Perhaps most important is the opportunity to move beyond a tweak
to an architectural change. Frankly, before the unknown RRs RFC
the situation in the deployed DNS wasn't that different from that
in the Microsoft environment--you had to be sure that all of the
resolvers that might *potentially* be in the path between a query
and the authoritative server were upgraded before you could use
a new type. Fixing that means that new types are not limited by
the DNS itself, they are limited by configuration and OS issues
that are part of the larger environment. By fixing those (even
with a time horizon of five years), you open things up to improvement
at a much more rapid pace later. That will help when the thing
that comes after NSEC or MARID comes along.
Looking back, I find that virtually all my professional life I have been
dealing with extensible and dynamically versioned systems, from OLE/COM
through many other things. And one thing I've learned if I've learned
anything is that, as much as I would wish it were otherwise, if it ain't
tested it doesn't work.
Again, the testability problem is probably smaller than you fear; there
will be records you can test against. Given I administer my own domain, I
am pretty sure I can guarantee it :).
The point that Ed was making yesterday is similar, though, and bears
repeating. Sub-typing has to be built in from the beginning; coming
back to something that is defined as unstructured and trying to introduce
sub-typing has a world of problems--we've seen it with TXT, with
KEY, and with lots of other systems. We can do if we're pressed, but
we need to do it knowing it's a workaround, not as the long term
basis of a new part of the infrastructure.
Note that we're talking about adding 2821.Fred to the mail system too,
rather than re-purposing something like 2821.MAIL-FROM; that
decision is based on exactly the same kind of reasoning--we need this
new piece of infrastructure, and we need to get it deployed in a way that
neither breaks existing use nor limits what we want in the long term.
And again, we have a transition--use 2821.Fred as soon as it is
available, but "grovel through" the 2822 headers until it is. As Jim
put it yesterday--that's the way to get this done quickly while
leading us to a place where we can do it well.
But at least it's not fatally flawed, only misguided.
Bob
Thank heavens for small favors!
regards,
Ted Hardie