IAB DNS choices 02

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(_at_)ops(_dot_)ietf(_dot_)org
From: Edward Lewis <Ed(_dot_)Lewis(_at_)neustar(_dot_)biz>
Subject: IAB DNS choices 02
Cc: ed(_dot_)lewis(_at_)neustar(_dot_)biz
Sender: owner-namedroppers(_at_)ops(_dot_)ietf(_dot_)org
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(_at_)schlitt(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf