Someone suggested that I repeat this post I made to namedroppers on
the main list. The reference to "wayne" refers to the message
archived at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00864.html
oo The forwarded message oo
Date: Thu, 9 Jun 2005 10:51:49 -0400
To: namedroppers@xxxxxxxxxxxx
From: Edward Lewis <Ed.Lewis@xxxxxxxxxxx>
Subject: IAB DNS choices 02
Cc: ed.lewis@xxxxxxxxxxx
Sender: owner-namedroppers@xxxxxxxxxxxx
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;none
Referring to http://www.ietf.org/internet-drafts/draft-iab-dns-choices-02.txt
This is going to be a lengthy email, because I want to discuss this
issue from an different perspective than I've seen from others on the
mailing list.
I saw the comments from wayne <wayne@xxxxxxxxxxx> on this document. I
have a different perspective, I think, in that I want to protect the
future of the DNS. (I don't mean to say he's out to hurt the DNS,
his objective is to meet the needs of application developers - also a
worthy goal.) My stipulation is that the DNS is a developed, healthy
protocol and system, positioned at the core of Internet operations.
Although it is heavily used, it is not threatened (as much as some
what to exclaim). Being at the core means that any change to it
causes many ripples in the Internet, that a conservative approach to
changes is wise.
From this viewpoint, my conclusion about the paper is that it is
making the correct recommendation, to rely on the use of new RR types
to "extend" the DNS. This is in contrast with wayne's conclusion
(somewhat) but like he, I agree the paper is somewhat "pollyanna-ish"
in it's justifications.
The paper reminds me of RFC 2826, "IAB Technical Comment on the
Unique DNS Root", published in 2000. A unique DNS root is beneficial
for the Internet. But because of this RFC, conducting large-scale
DNS experiments, such as is needed for DNSSEC, has been hindered.
The reality is that once a system becomes as crucial to operations as
DNS has, you can no longer tinker with it without endangering it's
stability. The moral here is that you need a test environment for
experimentation, separate from the operational environment. Because
of the cited RFC, there has been resistance and reluctance to set up
and join in the needed large scale (time, distance, and volume)
testing needed to safely introduce DNSSEC into the operational DNS.
I bring this up because that situation and the situation wayne has
been describing reflects what I think has been a large shift in the
dynamics of innovation in the Internet over time, and in the past
decade (plus).
It used to be that people could afford the time to gab informally
about what they wanted to accomplish, implement the ideas in quick
manner and then document the experiences. At the time, the Internet
could afford outages (it was not critical infrastructure in any way)
although it was fairly sound. The stability arose from the higher
per capita expertise in operations and a smaller workload.
Today that is not the case. The IETF recognizes this as well as
industry. The IETF has responded by formalizing the gab sessions
into requirements documents and (say) formal processes for reserving
IANA numbers. Industry has responded in different ways, by either
implementing minimally what they need regardless of the full
specification, innovating without consulting the IETF first, or
rolling out contract and/or regulatory agreements presupposing the
environment.
Coming back to the document at hand, I think what needs to be
examined is "how does someone, beginning from scratch, develop a new
application that needs to put data in the DNS get this application to
specified in a standard?" I'm not interested in "what it means to be
a standard" but more about "how does the process get a proper DNS
record type?"
Skipping ahead to the day where the developer realizes "hey, I need
to put this factiod in the DNS." Once the RR's RDATA contents are
determined, there needs to be a place to put it (name), assume class
IN, and a type code. For simplicity, let's say the name relates to
either a host or zone, so it's fairly obvious where the factoid RR
will be sitting in the DNS tree.
What is done about the RR type? The relevant RFC, assuming that
there is an obvious lead to this, is RFC 2929. In this, it says that
the type code numbers from 65280 to 65535 are available for private
use. Since the state of the work is early, that is the proper number
to use.
Getting a reserved RR type number requires "IETF consensus." That
has is rumored to take a long time. ;) So, what is likely to happen
is that implementation and testing will happen using what's at hand -
the "private use" number.
Eventually, IANA allocates a type code number. What happens next?
Well, all of the new implementations should go out there with the new
type code and that is where every one should move the records. This
would work if there was ever a clean transition from testing to
production. This clean break rarely happens in the Internet world.
(Consider the discussion over the termination of ip6.int - we fear
clean breaks because it might mean a disruption of service.)
Instead of having a clean break, the thought has been to have the new
software look in both the old and new place. Doing "new, if fails,
old" lookups is not workable for applications because this would make
the new stuff slower than the old - a disincentive to upgrade. Doing
simultaneous lookups increases the burden and does not yield any
incentive to upgrade. (This is the same as if the TXT record was
used for initial work.)
The document goes to lengths to say that name servers can handle
unknown types. In fact, so long as a type is unknown, it will work
better. This is because of the standardization of the "printable
format." Until a name server can parse a resource record, it doesn't
matter what the format of the the RDATA is, meaning it can be more
easily dumped into a file format like that used by slave servers for
zones they have received.
I mention that because what we have is a bureaucratic problem whose
source is RFC 2929. I don't mean to criticize the effort behind RFC
2929, but to say that we are learning something in hindsight here.
And maybe some of what wayne has said applies to these lessons.
I'll suggest two possibly radical notions for the assignment of new
RR type codes. One is somewhat anarchic and is prompted by wayne's
discussion of Unix file magic numbers. The other is a "number lease".
We could state that IANA only reserves numbers upon consensus of the
IETF, but encourage innovating implementers to reuse any number not
otherwise reserved by IANA and not obviously in use. If two such
innovators collide (as wayne mentions), the issue is somehow
resolved. The IETF and IANA should be clear that unreserved type
codes are open territory. A real conflict, not a bureaucratic one,
will be settled.
Alternatively, we could lower the bar for getting an IANA type code
number reservation to just documenting it in an internet-draft with
the caveat that the number is only reserved for two (X) years, by
which time consensus is needed to give it "tenure." The latter would
work so long as no name servers try to parse the RDATA of non-tenured
RR types.
Winding this all up, the problem of adding new RR types is not a
problem for the DNS. It is a problem with the bureaucracy
surrounding the DNS and for applications making use of the data. I've
mentioned the bureaucratic problem (and I am not referring to the
operations of the IANA registry, but the instructions in RFC 2929
given to IANA), but I haven't said much about the problem for
applications.
Assuming that name servers don't parse types until they are
"permanent" - referring to the leased (non-tenured) numbers, then
there shouldn't be a problem with the use of a RR type code 98 for
one application from 2012 to 2013 and by another application from
2017 to 2019. The presumption is that the first application failed
to win enough acceptance to gain a permanent hold on record 98 and
has fallen by the wayside. It's not like a wrestling match between
application #1 and application #2 would be too close to call.
If, though, there is still some holdover data from one application to
the other's era and if the name servers all treat 98 as unknown, the
DNS will not have a problem. The problem will be within the (new)
application. Implementers will have to be aware of that possibility.
In summary, for a stable DNS the goal is to extend it via new RR
types. Although this is the "right thing to do" in a conceptual
world, the bureaucratic world works against this, given the
environment of innovation. I hope that the IAB statement on this
issue can be made more realistic, reflecting the reality of the day
and not only on a theoretical view of the Internet (which is why I
raised the side point about the unique root statement).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
If you knew what I was thinking, you'd understand what I was saying.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf