Re: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews <Mark_Andrews@isc.org> Wed, 09 July 2008 00:54 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33623A6B5E; Tue, 8 Jul 2008 17:54:45 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0943A6B5E for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 17:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.582
X-Spam-Level:
X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcj8oaSUMNdA for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 17:54:43 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by core3.amsl.com (Postfix) with ESMTP id AB79A3A6B3F for <ietf@ietf.org>; Tue, 8 Jul 2008 17:54:42 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m690sjPw067847; Wed, 9 Jul 2008 10:54:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200807090054.m690sjPw067847@drugs.dv.isc.org>
To: Ted Faber <faber@ISI.EDU>
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-reply-to: Your message of "Tue, 08 Jul 2008 10:27:08 MST." <20080708172708.GC2519@zod.isi.edu>
Date: Wed, 09 Jul 2008 10:54:45 +1000
Cc: Theodore Tso <tytso@MIT.EDU>, Keith Moore <moore@network-heretics.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
> > --mvpLiMfbWzRoNl4x > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote: > > > > > >The site-dependent interpretation of the name is determined not by the > > >presence of dot within the name but its absence from the end.=20 > >=20 > > not so. in many contexts the trailing dot is not valid syntax. > > Let me be precise. The resolver treats those names differently because > it was handed a name that did or did not end in a dot - the resolver's > syntax for absolute vs. relative pathname. I understand that may > conflict with application syntax. Applications that do not support an > explicit notation for absolute domain names will not be able to look > them up when those names are masked by site-dependent resolution of > relative names. Both "hk" and "www.isi.deterlab.net" are relative > names and subject to masking. The (some) resolver handles names differently if it contains a dot. pet.com is lookup up as pet.com FIRST then "pet.<search-element>". pet is looked up as "pet.<search-element>" FIRST and "pet" LAST. The above heuristics worked reasonably well in a IPv4 only world where tld's weren't turning back the clock and trying to make make single label hostnames work in a global context. There is a good case to be made that "pet" should *never* be looked up as plain "pet" if there is not a match on the search list. There is a good case to be made that "pet.com" should never be looked up against the search list. > I understand that such maskings are more intuitive with short names like > "hk", but that limitation of the application interface applies to any > relative domain name. The only reason to want single labels to be looked up "as is" is reverse the clock and support deprecated naming schemes. > > >I don't buy "unreliable" as a diagnosis for that state of affairs. "hk" > > >operates exactly as any other DNS name with respect to search path.=20 > >=20 > > search path isn't the only factor here. > > Understood. It was the objection I was responding to, though. > > >=20 > > there are also protocol specifications that expect DNS names to have=20 > > dots in them. > > One could argue that such protocols are not able to express all valid > domain names, which may be a feature. :-) > > That's probably a longer discussion than I want to have though, so I > agree that this is a stumbling block. > > >=20 > > there are also software implementations that use the presence/absence of= > =20 > > a dot to distinguish a DNS name from some other kind of name. in any=20 > > context where both a DNS name and something else can appear, it's useful= > =20 > > to be able to distinguish the two - and the presence/absence of a dot is= > =20 > > about the only test that works. > > I'm sure that there are plenty of apps that break here, and certainly > some protocols that have been specified that way, and I feel the pain of > backward compatibility. If I were running the website at hk, I'd > publicize the conventional DNS names and not hk. =20 > > I really didn't intend to get as deeply into this as I did. I was > honestly intrigued by a 2-letter hostname and wanted to see if it really > worked, as I could see no reason it wouldn't. For me it did. > > I understand that your resolver, server, and application may all prevent > it. I also understand that using such names may sow confusion among > those who don't care to examine the workings of their DNS set-up. And > that any confusion about computers is set upon by the unscrupulous to > gather money. Encouraging TLD hostnames as a matter of policy is more > complex than noting that the DNS specifications allow such a thing. It's clear that single label host names are not supposed to be used in a global context anymore. Just because nobody wrote down "Don't add a A or MX record at the apex of a TLD" doesn't mean that adding one was expected or desired. There are lots of things we do and don't expect infrastructure zone operators to do that differ from end user zones. Most of these are not codified. Mark > But it was pretty cool. :-) > > --=20 > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= > asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= > SIG > > --mvpLiMfbWzRoNl4x > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > > iEYEARECAAYFAkhzo2wACgkQaUz3f+Zf+XsK4QCg2VpDMr/fF1VnBGzx7Pa4dRgs > /0kAoJCVm5WBUIpZrAIvdIa3A2E1Gdtb > =x6uM > -----END PGP SIGNATURE----- > > --mvpLiMfbWzRoNl4x-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Update of RFC 2606 based on the recent ICANN chan… Marshall Eubanks
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … Marshall Eubanks
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Joe Abley
- RE: Update of RFC 2606 based on the recent ICANN … Hallam-Baker, Phillip
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Lawrence Conroy
- Re: Update of RFC 2606 based on the recent ICANN … Joe Baptista
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Philip Guenther
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Tony Finch
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- RE: Update of RFC 2606 based on the recent ICANN … Hallam-Baker, Phillip
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … Thomas Narten
- Re: Update of RFC 2606 based on the recent ICANN … David Conrad
- Re: Update of RFC 2606 based on the recent ICANN … Philip Guenther
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Paul Hoffman
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Thomas Narten
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Steve Crocker
- Re: Update of RFC 2606 based on the recent ICANN … Paul Hoffman
- Re: Update of RFC 2606 based on the recent ICANN … Ole Jacobsen
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Paul Hoffman
- RE: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Lyman Chapin
- Re: Update of RFC 2606 based on the recent ICANN … Steve Crocker
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- RE: Update of RFC 2606 based on the recent ICANN … Bernard Aboba
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- RE: Update of RFC 2606 based on the recent ICANN … Bernard Aboba
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Stephane Bortzmeyer
- Re: Update of RFC 2606 based on the recent ICANN … SM
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- RE: Update of RFC 2606 based on the recent ICANN … Bernard Aboba
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Services and top-level DNS names (was: Re: Update… John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… Bernard Aboba
- Single-letter names (was: Re: Update of RFC 2606 … John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… Bernard Aboba
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Dave Crocker
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- RE: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Single-letter names (was: Re: Update of RFC 2… JFC Morfin
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Services and top-level DNS names Karl Auerbach
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names Frank Ellermann
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names Frank Ellermann
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Brian E Carpenter
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… John Levine
- Re: Services and top-level DNS names (was: Re: Up… Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … moore
- Re: Services and top-level DNS names (was: Re: Up… Jaap Akkerhuis
- Re: Update of RFC 2606 based on the recent ICANN … Lyman Chapin
- Re: Update of RFC 2606 based on the recent ICANN … Lyman Chapin
- Re: Update of RFC 2606 based on the recent ICANN … Vint Cerf
- Re: Single-letter names (was: Re: Update of RFC 2… William Tan
- Re: Single-letter names (was: Re: Update of RFC 2… Vint Cerf
- RE: Single-letter names (was: Re: Update of RFC 2… Edmon Chung
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Single-letter names (was: Re: Update of RFC 2… michael.dillon
- RE: Single-letter names (was: Re: Update of RFC 2… Ted Hardie
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Services and top-level DNS names (was: Re: Up… Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Theodore Tso
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Theodore Tso
- Re: Update of RFC 2606 based on the recent ICANN … Willie Gillespie
- Re: Update of RFC 2606 based on the recent ICANN … Karl Auerbach
- Re: Update of RFC 2606 based on the recent ICANN … Theodore Tso
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Frank Ellermann
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … James Seng
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Dave Crocker
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Joe Abley
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Brian E Carpenter
- Re: Update of RFC 2606 based on the recent ICANN … Douglas Otis
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Services and top-level DNS names (was: Re: Up… Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Marshall Eubanks
- Re: Services and top-level DNS names (was: Re: Up… John C Klensin
- RE: Services and top-level DNS names (was: Re: Up… Cellario Luca
- Re: Update of RFC 2606 based on the recent ICANN … Bob Braden
- Re: Single-letter names Eric Brunner-Williams
- RE: Single-letter names (was: Re: Update of RFC 2… John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Tony Finch
- Re: Update of RFC 2606 based on the recent ICANN … John Levine
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … John C Klensin
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Keith Moore
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Mark Andrews
- Re: Update of RFC 2606 based on the recent ICANN … Bill Manning
- Re: Update of RFC 2606 based on the recent ICANN … Joe Touch
- Re: Update of RFC 2606 based on the recent ICANN … Ted Faber