IAB DNS choices 02

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

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]