Subject: Re: In the spirit of Festivus

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Jan 2008 12:10:38 +0100

Ed,

Edward Lewis wrote:
> What I did was go to rfc-editor.org and searched for "DNS" in the RFCs. 
> The first two that pop up are RFC 1034 and 1035 naturally.  To the right
> is a list of RFCs that they obsoleted and RFCs that have since updated
> them.  What got me was that a handful of the updating RFCs are obsolete,
> in one case the obsoleted RFC was obsoleted by an RFC which is also
> obsolete.  (The NSAP RR.)  Many important RFCs (measuring by the impact
> they have on the protocol definition) are not listed as updating the
> original specifications.  At least one of the RFCs updating the
> originals did not pop up in the rest of the search list.

<snip/>

> So - the question is - is this a matter of the IETF updating the RFC
> Editor or is it a matter that the RFC Editor needs to clean this up? I
> am a bit reluctant to blindly try to do this myself because when I have
> tried to clean up matters in the IANA DNS parameters registry, my
> efforts seem to go for naught[0].  (I've been doing that a bit each year
> for about 4 now.  There is a draft Andrew Sullivan has volunteered to
> help write - sorry Andrew I haven't gotten back to you but I'm hung on
> getting someone else else where [ex-ATM forum members] to clear
> something up.)

This has been a problem with IETF documents as long as I can remember. RFCs are
a nightmare if you come from outside the IETF and want to implement an IETF
standard. I don't see this as a DNS problem, although in DNS one feels it more
keenly because it is an old, widely-used protocol.

I mean, the search at the RFC Editor returns 144 matches on a search for "DNS"!
A lot of "standards track" RFCs one can safely ignore, some one cannot.

Given the IETF approach of working groups that are short-lived, there is no
long-term maintenance of standards. I don't mean STD documents, I mean this in
the larger sense of the collection of STD and RFC and other knowledge that
comprises the *actual* interoperable protocols.

Is it even a goal that someone not deeply involved in the IETF culture be able
to implement an IETF protocol?

There are some efforts to clean things up, but nothing structural as far as I
can see. Of course, I don't read [email-masked], so maybe this is all a solved
problem? ;)

--
Shane

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Wed, 02 Jan 2008 14:25:20 +0100

> A lot of "standards track" RFCs one can safely ignore, some one cannot.

And this is not even the complete list.  Some RFCs update 1034, 1035 or
1123 without explicitly saying so (and do not contain the magic string
"DNS" in the title or the abstract, either).

---

From: Andras Salamon <[email-masked]>
Date: Wed, 2 Jan 2008 19:21:46 +0200

> "DNS" in the title or the abstract, either).

The list at
    http://www.dns.net/dnsrd/rfc/
is up to date up to 2004, and was meant to be comprehensive for DNS.

-- Andras Salamon                   [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 3 Jan 2008 14:03:02 +0100

On Wed, Jan 02, 2008 at 12:10:38PM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 52 lines which said:

> long-term maintenance of standards.

An effort have been done for some protocols, either to update the base
definition (SMTP : RFC 821 -> 2821 -> 2821bis currently in Last Call),
or to document the various RFCs with indication of which are important
and what is not in the RFCs (TCP : RFC 4614).

Clearly, the DNS needs its RFC 4614. Who volunteers?

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jan 2008 22:53:45 +0000

> Clearly, the DNS needs its RFC 4614. Who volunteers?

"volunteer" is the wrong word.  who has ambition and funding for this effort?
(i had both, a few years ago, but i've learned the error of those ways.)

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 03 Jan 2008 20:30:54 -0500

>Clearly, the DNS needs its RFC 4614. Who volunteers?

Someone has, stay tuned for official announcement and draft plan next week.

         Olafur

---

From: Florian Weimer <[email-masked]>
Date: Fri, 04 Jan 2008 21:46:57 +0100

> is up to date up to 2004, and was meant to be comprehensive for DNS.

It misses RFC 3484 (my current litmus test).

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Jan 2008 17:58:21 -0500

>It misses RFC 3484 (my current litmus test).

This has come up before.  From my reading RFC 3484 has little to do 
with the DNS protocol.  The web page says that the page lists RFCs 
that are "directly relevant" to the DNS.  RFC 3484 mentions "DNS" 5 
times, and the content in it is not "directly relevant."

1) "For example, when DNS"
2) "As one example, suppose a DNS"
3) "In the case of destination address selection, the
    DNS may return a set of addresses for a given name, and an
    application needs to decide which one to use..."
4) when applied to the set of addresses returned by the DNS
5) Consider a site ...  All hosts in both sites register two addresses
    in the DNS.

#'s 1,2,5 the DNS is seen playing a supporting role in an example.  # 
3 talks about an application dealing with the normal return of the 
DNS.  # 4 talks about applying a rule to the same.  None of this has 
a bearing on the DNS protocol.

Later there is a rule that has been raised before has having a 
conflict with DNS operations.

#   Rule 9:  Use longest matching prefix.
...
#   Rule 10:  Otherwise, leave the order unchanged.

The issue is the server selection algorithm by an interating process. 
There are two things to consider, first is that the server selection 
process is not governed by the DNS protocol specifications, 
nevertheless there are commonly followed algorithms in the field. 
And, there is also this catch in the same RFC:

#  Rules 9 and 10 may be superseded if the implementation has other
#  means of sorting destination addresses.

Which certainly applies in the case of DNS servers.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 11 Jan 2008 10:48:31 +0100

* Edward Lewis:

> DNS.

The RFC may be worded as if this were an application issue, but to my
knowledge, your item 3 is implemented in resolvers (if implemented at
all).  Therefore, Rule 9 in RFC 3484 changes DNS name resolution
behavior which was previously documented in RFC 2219 and other places.

I understand that it's sometimes desirable to disguise DNS protocol
changes as application behavior recommendation to route RFCs around
certain working groups.  But the net effect is the same: if the change
is bogus and is implemented widely, considerable suffering is the
result.  (In fact, this is what happened with Rule 9 in RFC 3484.)

---

From: Danny Mayer <[email-masked]>
Date: Sat, 12 Jan 2008 22:11:03 -0500

> result.  (In fact, this is what happened with Rule 9 in RFC 3484.)

One of the interesting recent requests we've had in ntp is to pick
randomly from the list of addresses returned so that any ntp daemon is
likely to use a different address for the ntp server that it's going to
query. The is useful since although the pool DNS server are regularly
updating the list, if you don't randomize what you use then a lot of
clients are likely to use it. For the pool option we also want to use a
randomized list. We don't expect DNS or the resolvers to give a
randomized list, we expect to need to do this ourselves. This sort of
thing is exactly what 3) talks about.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sat, 12 Jan 2008 22:10:37 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Danny