Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?

From: <[email-masked]>
Date: Mon, 7 Jul 2008 13:32:10 -0700 (PDT)

> I have to congratulate you on one of the most subtle 
> proposals to destroy the Internet that I have seen 
> in a long time.  More on that in a moment.

Maybe you should read and understand the proposal before commenting on it.  I realize that it's difficult to actually
be sure you understand a single sentence before writing
several paragraphs - but hey, it's not much to ask.
(hint: It doesn't affect ICANN or the root servers at all.)

> So who's going to explain to the Vatican that, sorry, 
> pope@va doesn't work any more?  Or will the US take 
> issue when addresses @as, which is part of the US, 
> don't work?  Or France about @gp and @mq, which are 
> as much part of France as Hawaii is part of the US?

I'd be very surprised if any of these work as-is, with any reliability.  They certainly won't work for email.  The assumption that fully qualified domain names contain at least one '.' is widespread in both protocol specifications and implementations.

> I'm impressed, it never occurred to me that one could 
> cause this much damage with such an arcane change to 
> name resolution. 

If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument.   e.g. an actual email address or URL that uses a single-label domain name.

Keith
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 13:38:28 -0700

On Mon, Jul 07, 2008 at 01:32:10PM -0700, [email-masked] wrote:
> If you can cite verifiable evidence that even a single case that works
> reliably now, will cease to work, I'll concede that there is at least
> a hint of merit to your argument.   e.g. an actual email address or
> URL that uses a single-label domain name.

zod:~$ ping hk
PING hk (203.119.2.28): 56 data bytes
64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms
64 bytes from 203.119.2.28: icmp_seq=1 ttl=243 time=195.586 ms
64 bytes from 203.119.2.28: icmp_seq=2 ttl=243 time=196.055 ms
64 bytes from 203.119.2.28: icmp_seq=3 ttl=243 time=183.091 ms
^C
--- hk ping statistics ---
5 packets transmitted, 4 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 183.091/189.578/196.055/6.247 ms
zod:~$ whost 203.119.2.28
203.119.2.28 www.hkdnr.hk 
zod:~$ cat /etc/resolv.conf
search isi.edu
nameserver 128.9.160.161
nameserver 128.9.64.64

-- 
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
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 13:44:28 -0700

> 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms

Sorry. Typo.  I mean:

zod:/auto/boreas/jade/faber$ dig hk

; <<>> DiG 9.4.2 <<>> hk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34376
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15, ADDITIONAL: 5

;; QUESTION SECTION:
;hk.				IN	A

;; ANSWER SECTION:
hk.			604392	IN	A	203.119.2.28

;; AUTHORITY SECTION:
hk.			604392	IN	NS	ADNS2.BERKELEY.EDU.
hk.			604392	IN	NS	TLD5.ULTRADNS.INFO.
hk.			604392	IN	NS	TLD1.ULTRADNS.NET.
hk.			604392	IN	NS	ADNS1.BERKELEY.EDU.
hk.			604392	IN	NS	TLD6.ULTRADNS.CO.UK.
hk.			604392	IN	NS	NS1.HKIRC.NET.hk.
hk.			604392	IN	NS	B.DNS.TW.
hk.			604392	IN	NS	NS3.CUHK.EDU.hk.
hk.			604392	IN	NS	SEC3.APNIC.NET.
hk.			604392	IN	NS	TLD2.ULTRADNS.NET.
hk.			604392	IN	NS	TLD3.ULTRADNS.ORG.
hk.			604392	IN	NS	NS2.CUHK.EDU.hk.
hk.			604392	IN	NS	NS2.HKIRC.NET.hk.
hk.			604392	IN	NS	TLD4.ULTRADNS.ORG.
hk.			604392	IN	NS	NS-HK.RIPE.NET.

;; ADDITIONAL SECTION:
TLD4.ULTRADNS.ORG.	36836	IN	A	199.7.67.1
TLD4.ULTRADNS.ORG.	36836	IN	AAAA	2001:502:100e::1
TLD3.ULTRADNS.ORG.	34966	IN	A	199.7.66.1
TLD2.ULTRADNS.NET.	29696	IN	A	204.74.113.1
TLD1.ULTRADNS.NET.	29696	IN	A	204.74.112.1

;; Query time: 4 msec
;; SERVER: 128.9.160.161#53(128.9.160.161)
;; WHEN: Mon Jul  7 13:43:55 2008
;; MSG SIZE  rcvd: 508

---

From: Theodore Tso <[email-masked]>
Date: Mon, 7 Jul 2008 17:01:30 -0400

> > reliably now, will cease to work, I'll concede that there is at least
    ^^^^^^^^
> 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms

% ping hk.
PING hk (203.119.2.28) 56(84) bytes of data.
64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms
64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms

Not very reliably, I think.  :-)

							- Ted

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Jul 2008 14:04:31 -0700

> ;; WHEN: Mon Jul  7 13:43:55 2008

also...  
% dig version.bind txt chaos @128.9.160.161

; <<>> DiG 8.3 <<>> version.bind txt chaos @128.9.160.161 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      version.bind, type = TXT, class = CHAOS

;; ANSWER SECTION:
version.bind.           0S CHAOS TXT    "9.4.2"

;; AUTHORITY SECTION:
version.bind.           0S CHAOS NS     version.bind.

	so - recent resolver code does this trick.

ob. "Unexpected attachment on this mail?"  -  I was actually expecting
	an attachment that was not there.  

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 14:13:47 -0700

> Not very reliably, I think.  :-)

Umm, hk. resolves to the same address from both our machines and is
pingable (modulo a single packet loss from yours, depending on how your
ping counts) from both.  http://hk pulls up a web page on a machine with
the same address.  (www.hkdnr.hk is an alias for hk. - the same machine;
you're not being redirected.)

That's at least as reliable as my (multi-dotted) home domain. :-)

I'm not sure what's not to like here.  But then again, I may be blind.

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 14:25:31 -0700

> 	so - recent resolver code does this trick.

Fair enough.  Perils of working for ISI, I suppose - modern
infrastructure.

Not to argue with someone who's forgotten more about DNS than I know,
but I was able to get it to work from zig.usc.edu as well. On zig (a
Linux box talking to an ambiguously identified "USC Bind 9x" server)
ping needed the trailing dot on hk. to work.  And by "got it to work, I
mean "typed ping".  I also had no trouble on a FreeBSD machine talking
to bind 9.3.3.  It works at home, too, but that's also a 9.4.2 bind.

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Jul 2008 17:37:38 -0400

> the same address. 

interesting.  I had actually tried that URL before sending the last 
message, and from where I tried it, it failed.  trying it again just 
now, from my home network, it works.  so the sample size is small but 
I'm still in doubt that this works reliably.

and even if there is "a hint of merit" to John's argument, John's claim 
that it would destroy the Internet, or even do it significant harm, 
seems utterly preposterous.

Keith

---

From: Theodore Tso <[email-masked]>
Date: Mon, 7 Jul 2008 17:42:14 -0400

> > Not very reliably, I think.  :-)

Sorry, I cut and paste the wrong example.  What I had meant to cut and
paste:

5% ping hk
PING hk.ibm.com (9.190.250.244) 56(84) bytes of data.
...

							- Ted

---

From: Willie Gillespie <[email-masked]>
Date: Mon, 07 Jul 2008 15:56:10 -0600

> PING hk.ibm.com (9.190.250.244) 56(84) bytes of data.

With your hk.ibm.com example, do you have any search lines in your 
/etc/resolv.conf file that would be automatically appending?
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Theodore Tso <[email-masked]>
Date: Mon, 7 Jul 2008 18:12:36 -0400

> /etc/resolv.conf file that would be automatically appending?

Of course!  That was my point about why "http://hk" or "ping hk" is
not going to be terribly reliable.  If you think people are going to
type "http://hk.", I can probably come up with Web 2.0 startup that
you could fund, if you're not interested in purchasing a certain
bridge in New York City...  :-)

						- Ted

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 15:25:15 -0700

> PING hk.ibm.com (9.190.250.244) 56(84) bytes of data.

I can do that with hk.com, too, as you know.  I think it's a feature.
YMMV.

My point is that from my minimal sample, hk seems to work about the
same as any other DNS name.  I believe that was in dispute.

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Jul 2008 15:49:53 -0700

> to bind 9.3.3.  It works at home, too, but that's also a 9.4.2 bind.

	so... the point i was tryig to make was/is:

	simple queries only help if you know:
		) the version of software running on your caching server
		and
		) the search list defined by your "resolv.conf" 

	zig.usc.edu,
	boreas.isi.edu,
	luna-base.org,
	ep.net,
	lcs.mit.edu,
	comcast.net,

	all run slightly different caching code and variable search lists.

	you, me, Ted, Keith, John, et.al.  are going to see -slightly- different
	responses  when presenting our individual local caching servers with
	non-terminated DNS strings.

	Japp and Karl both hinted at this problem - local policy  is the worst policy,
	except for all the others.  Your local DNS admin can (and occasionally they do)
	toss you into a random walled-DNS garden that has only a passing similarity to
	what you think of as the "Internet".   http://www.icann.org/committees/security/sac032.pdf
	is illustrative.  

-- 
--bill

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 17:14:58 -0700

> 		) the search list defined by your "resolv.conf" 

Fair enough.   (I did include the resolv.conf in the first example, but
hadn't considered the caching server.)

And I understand how a DNS name without a dot in it can be confusing.
Even with a dot in there, DNS admins (or DHCP spoofers) can put you into
a walled garden pretty easily, though.

I'm not sure I see any great benefit to using the undotted names - the
dot really indicates the "Internet brand" pretty strongly - but it seems
to function in the environments I have easy access to.  I was primarily
responding to the fellow who doubted the practicality of the idea, not
endorsing it.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2008 10:18:25 +1000

> 
> --===============1515233305==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye"
> Content-Disposition: inline
> 
> 
> --tsOsTdHNUZQcU9Ye
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> > > On Mon, Jul 07, 2008 at 01:32:10PM -0700, [email-masked] wr=
> ote:
> > >=20
> > > 64 bytes from 203.119.2.28: icmp_seq=3D0 ttl=3D243 time=3D183.582 ms
> >=20
> > % ping hk.
> > 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=3D1 ttl=3D238 time=3D=
> 265 ms
> > 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=3D2 ttl=3D238 time=3D=
> 265 ms
> >=20

	The point is that it is NOT reliable.  Whether it works
	depends apon what names are matched in the search list.  It
	does work for some people some of the time.  It does not
	work for all of the world all of the time.  "hk" is not
	globally unique.

bsdi# ping hk
PING hk.dv.isc.org (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.148 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.170 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.172 ms
^C
--- hk.dv.isc.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.148/0.163/0.172/0.011 ms
bsdi# 

> --=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
> 
> --tsOsTdHNUZQcU9Ye
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (FreeBSD)
> 
> iEYEARECAAYFAkhyhwsACgkQaUz3f+Zf+Xu/JQCg0bBCl+ufJrXaLx7X+qsE3Jfk
> nhUAoKdEtfZ+47v4Uu+MCHng2R+A5anJ
> =Xp3s
> -----END PGP SIGNATURE-----
> 
> --tsOsTdHNUZQcU9Ye--
> 
> --===============1515233305==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============1515233305==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 8 Jul 2008 02:26:53 +0200

Bill Manning wrote:

> http://www.icann.org/committees/security/sac032.pdf
> is illustrative.

| entrusted agents should provide opt-out mechanisms that
| allows clients to receive the original DNS answers to
| their queries.

[...]

| Organizations that rely on accurate NXDomain reporting
| for operational stability should choose an entrusted
| agent that asserts it will not modify DNS responses in
| its terms of service.

Certainly "illustrative" , but not affecting 2606bis ;-)

 Frank

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 18:32:42 -0700

> 	work for all of the world all of the time.  "hk" is not

That statement is also true for hk.com, ibm.com, google.com, or any
other relative DNS name.

The site-dependent interpretation of the name is determined not by the
presence of dot within the name but its absence from the end.  "hk." is
as global as "hk.com." with respect to the search list; "hk" and
"hk.com" are both relative names and their resolution is resolver
dependent.

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.  An
incautious user or clever DNS administrator can create a confusing state
of affairs with or without the interior dot.

(As Bill Manning hinted, there may be other parts of the resolution code
that are less reliable for names without a dot in them.  That I might
buy as an argument for unreliability). 

If you'd like to argue something more subjective like "confusing" or
even "misleading," you'll find no resistance from me.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2008 11:45:25 +1000

> buy as an argument for unreliability).=20
> 

	The point of going to heirachical names (RFC 921) is to
	remove abmiguity.  "tld"s don't meet the definition of a
	heirachical name.

	It is time that tld operators stopped mis-using the zones
	they operate.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2008 11:47:15 +1000

> presence of dot within the name but its absence from the end.

	No.  Please go and re-read RFC 921.

>  "hk." is

---

From: Ted Faber <[email-masked]>
Date: Mon, 7 Jul 2008 19:02:28 -0700

> 	No.  Please go and re-read RFC 921.

What a charming document.

I don't see anything in it that indicates a hierarchical name can't
consist of one level, though I see plenty of examples of 2-level names.
If you see text in there that I missed, I'm all ears.

I do see this in RFC 1035, though:

>When a user needs to type a domain name, the length of each label is
>omitted and the labels are separated by dots (".").  Since a complete
>domain name ends with the root label, this leads to a printed form which
>ends in a dot.  We use this property to distinguish between:
>
>   - a character string which represents a complete domain name
>     (often called "absolute").  For example, "poneria.ISI.EDU."
>
>   - a character string that represents the starting labels of a
>     domain name which is incomplete, and should be completed by
>     local software using knowledge of the local domain (often
>     called "relative").  For example, "poneria" used in the
>     ISI.EDU domain.
>
>Relative names are either taken relative to a well known origin, or to a
>list of domains used as a search list.  Relative names appear mostly at
>the user interface, where their interpretation varies from
>implementation to implementation, and in master files, where they are
>relative to a single origin domain name.  The most common interpretation
>uses the root "." as either the single origin or as one of the members
>of the search list, so a multi-label relative name is often one where
>the trailing dot has been omitted to save typing.

That sounds a lot to me like "hk." is as global as "hk.com."

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2008 12:54:16 +1000

> --YD3LsXFS42OYHhNZ

	"hk." is not a syntactically valid hostname (RFC 952).
	"hk." is not a syntactically valid mail domain.
	Periods at the end are not legal.

	RFC 1035 has *nothing* to do with defining what is legal
	as a hostname.

	Mark

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Jul 2008 23:28:05 -0400

> presence of dot within the name but its absence from the end. 

not so.  in many contexts the trailing dot is not valid syntax.

> operates exactly as any other DNS name with respect to search path. 

search path isn't the only factor here.

there are also protocol specifications that expect DNS names to have 
dots in them.

there are also software implementations that use the presence/absence of 
a dot to distinguish a DNS name from some other kind of name.  in any 
context where both a DNS name and something else can appear, it's useful 
to be able to distinguish the two - and the presence/absence of a dot is 
about the only test that works.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jul 2008 00:35:05 -0400

--On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews
<[email-masked]> 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.
> 

This is the same RFC 921 that 
	
	* is listed in the RFC Index as "Status: UNKNOWN"
	
	* was not even examined in the "requirements" review
	that led up to RFC 1123 and is not referenced there.
	
	* primarily talks about an implementation schedule and
	transition plan, not about long-term stable
	interpretations.

??

Isn't claiming that as an authority in 2008 a bit of a stretch?
Especially since, as Ted Farber points out, text in 1035 itself
seems to contradict your reading of that particular section?

I believe that 952 is almost equally irrelevant wrt this
argument. YMMD, of course.

As Keith points out, there are lots and lots of reasons to avoid
believing that dot-less strings will be interpreted as domain
names consistently and in the way that users will expect.  Most
of them have to do with handling of names in applications, which
tends to get strange in edge cases and stranger when one relies
too much on having specific contents in resolver configuration
files.  The mere fact of inconsistent (but valid)
interpretations in different applications or configurations (or
even implementations of the same 
application) may be more than enough reason to avoid these
things, or at least be very careful about them.  But claiming
921 as an authority isn't one of the reasons, IMO.

     john

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2008 15:27:03 +1000

> 	* is listed in the RFC Index as "Status: UNKNOWN"

	Unknown doesn't mean irrelevent.
 
> 	that led up to RFC 1123 and is not referenced there.

	RFC 1123 -> RFC 952 -> RFC 921

> Isn't claiming that as an authority in 2008 a bit of a stretch?

	No.  Old does not mean irrelevent.

> seems to contradict your reading of that particular section?

	No.  RFC 1035 applies to domain names, not hostnames.
	
> argument. YMMD, of course.

	RFC 952 is the latest rfc which defines the syntax of a
	hostname.

---

From: Ted Faber <[email-masked]>
Date: Tue, 8 Jul 2008 09:13:35 -0700

> 	RFC 1035 has *nothing* to do with defining what is legal

Fair enough. 

By RFC952 standards "hk" is a perfectly fine hostname.

By RFC1035 standards, if you look it or any other DNS name up using the
DNS resolver, that resolver will treat the name as relative unless it
ends with a dot.   Arguing that hk is an unreliable hostname if you
look it up as a relative pathname is pretty much the same as arguing
that www.isi.deterlab.net is an unreliable hostname.  Both of them are
subject to the search path without that trailing dot.

So far, the only distinction between the two is that hk is short.

I understand the assumption that getting a collision in the search path
with a 2-letter name is higher than getting one with a 20-letter name.
I believe that the 2-letter collisions are no harder to avoid in
principle than the 20-letter ones, and no harder to create should an
admin want to do so (e.g., to create local aliases).  I think you
believe that search path collisions for short names are inherently
harder to avoid (and might rule out using the trailing dot notation in
applications to avoid them).

Is that basically what we disagree about?

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 12:23:38 -0400

> subject to the search path without that trailing dot.

RFC1035 may recognize the trailing dot, but (for better or worse) many 
applications do not recognize it, and some explicitly forbid it.

> Is that basically what we disagree about?

No.  There's more to this than just the possibility of name collisions 
caused by the lookup using a search path.

For instance, there are also applications that try to distinguish 
between an absolute DNS name and some other kind of name (DNS name 
relative to the search path, or a name in /etc/hosts, NetBIOS, NIS, ...) 
by checking to see whether the name contains a '.'.  So for instance, if 
the domain name contains a '.', the "search path" function might be 
turned off during name lookup.

This behavior isn't necessarily prescribed in any specification, but 
it's a useful heuristic - especially for an application (like email 
addresses or URLs) where it's important that domain names be unambiguous 
and location-independent.

Keith

---

From: Ted Faber <[email-masked]>
Date: Tue, 8 Jul 2008 10:27:08 -0700

> 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.

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.

> search path isn't the only factor here.

Understood.  It was the objection I was responding to, though.

> there are also protocol specifications that expect DNS names to have 

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.

> 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.  

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.

But it was pretty cool. :-)

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 11:13:26 -0700

Keith Moore wrote:
|
|
| Ted Faber wrote:
|> On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
|>>     "hk." is not a syntactically valid hostname (RFC 952).
|>>     "hk." is not a syntactically valid mail domain.
|>>     Periods at the end are not legal.
|>>
|>>     RFC 1035 has *nothing* to do with defining what is legal
|>>     as a hostname.
|>
|> Fair enough.
|> By RFC952 standards "hk" is a perfectly fine hostname.
|>
|> By RFC1035 standards, if you look it or any other DNS name up using the
|> DNS resolver, that resolver will treat the name as relative unless it
|> ends with a dot.   Arguing that hk is an unreliable hostname if you
|> look it up as a relative pathname is pretty much the same as arguing
|> that www.isi.deterlab.net is an unreliable hostname.  Both of them are
|> subject to the search path without that trailing dot.
|
| RFC1035 may recognize the trailing dot, but (for better or worse) many
| applications do not recognize it, and some explicitly forbid it.

RFC1043 defines the dot. The fact that some apps don't recognize it is a
bug. Given its impact, let's not call it a feature or BCP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 11:15:18 -0700

Joe Touch wrote:
|
|
| Keith Moore wrote:
| |
| |
| | Ted Faber wrote:
| |> On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
| |>>     "hk." is not a syntactically valid hostname (RFC 952).
| |>>     "hk." is not a syntactically valid mail domain.
| |>>     Periods at the end are not legal.
| |>>
| |>>     RFC 1035 has *nothing* to do with defining what is legal
| |>>     as a hostname.
| |>
| |> Fair enough.
| |> By RFC952 standards "hk" is a perfectly fine hostname.
| |>
| |> By RFC1035 standards, if you look it or any other DNS name up using the
| |> DNS resolver, that resolver will treat the name as relative unless it
| |> ends with a dot.   Arguing that hk is an unreliable hostname if you
| |> look it up as a relative pathname is pretty much the same as arguing
| |> that www.isi.deterlab.net is an unreliable hostname.  Both of them are
| |> subject to the search path without that trailing dot.
| |
| | RFC1035 may recognize the trailing dot, but (for better or worse) many
| | applications do not recognize it, and some explicitly forbid it.
|
| RFC1043 defines the dot. The fact that some apps don't recognize it is a
sorry -- 1034.

| bug. Given its impact, let's not call it a feature or BCP.
|
| Joe
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 14:17:57 -0400

Ted Faber wrote:
> relative names. 

It's more likely that the application (as specified) simply expects 
(implicitly or explicitly) absolute domain names.  If and when relative 
domain names "work", it's either by accident or a result of sloppy coding.

Few applications are specified in such a way that relative DNS names 
make sense and there is a clear way to distinguish relative names from 
absolute DNS names.  (Note that "make sense" generally includes 
converting relative names to absolute names in the context of whoever 
typed in the relative name - and dealing with the potential for skew 
over time between the relative name and absolute equivalent.  in other 
words, this is not an easy thing to do well.)

The problem is worsened because most APIs for name lookup are poorly 
designed in several ways.  One of their problems is that they tend to do 
"relative" lookups by default even though often that's not desirable. 
Another problem is that they tend to do other kinds of lookups by 
default in addition to DNS (perhaps as a fallback) even in contexts 
where DNS lookups are required for interoperability.  Applications may 
or may not work around these API problems, and to the extent they do, 
they probably don't do so consistently from one implementation to the next.

> "hk", but that limitation of the application interface applies to any

I'm not sure what "intuitive" means in this context.  But the 
probability of collision is certainly larger for short names than for 
longer ones.  I suspect it's also larger for single-label names than for 
multiple-label names, where each label is assigned by a different entity.

And a higher probability of collision definitely translates to a lower 
degree of reliability.

> domain names, which may be a feature. :-)

The notion of a single-label fully-qualified DNS name being "valid" is 
an odd one.   DNS, as far as I can tell, was always intended to be 
federated, both in assignment and lookup.  The notion of having terminal 
(basically, non NS) records at the root seems contraindicated by several 
of the DNS design goals.

For example, at the time DNS was established, single label names like 
CMUA or MIT-AI were the norm.  But those names were not incorporated 
into the root (even during a transition), nor were TLDs created for 
those zones - because DNS was not intended to work that way.  The whole 
idea was to federate the name space, not to provide another way to look 
up single-label names.  (Instead, the names were incorporated into the 
.ARPA TLD for a time, with CNAMEs pointing to the real names.)

So I persist in thinking that single-label DNS names are not valid, and 
that to the extent they work at all, they work only by accident or as a 
result of poor specification or sloppy implementation.

And given the recent interest in vanity TLDs and ICANN's apparent lack 
of willingness to run the DNS for the benefit of all, maybe it's time 
for IETF to remind people that single label TLDs are not actually 
supposed to work.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 14:32:32 -0400

> bug. 

not when the application explicitly specifies that FQDNs are to be used.
in such cases the dot is superfluous.

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 11:34:59 -0700

Keith Moore wrote:
|> RFC1043 defines the dot. The fact that some apps don't recognize it is a
|> bug.
|
| not when the application explicitly specifies that FQDNs are to be used.
| in such cases the dot is superfluous.

Superfluous is fine. Prohibited is not. If the app inputs DNS names,
then FQDNs should be valid, even if redundant.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 14:46:16 -0400

> then FQDNs should be valid, even if redundant.

I don't think you get to revise a couple of decades of protocol design 
and implementation by declaring that RFC 1043's authors and process 
trump everything that's  been done afterward.

face it, there are large numbers of identifiers for which relative names 
are simply not appropriate - because they cannot be made to work well 
over the time frame that those identifiers need to be valid.  email 
addresses and URLs are two obvious examples.

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 11:56:06 -0700

> trump everything that's  been done afterward.

I'll repeat:
	
	some app misbehaviors are just bugs

	not all app misbehaviors define new, acceptable behavior

At some point we as a group decide what to accept as BCP, and what to 
just call a bug. This, IMO, falls squarely in the 'bug' bin.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 15:01:39 -0400

> just call a bug. This, IMO, falls squarely in the 'bug' bin.

IMO you are broadly overgeneralizing.

For many apps (and certainly for the apps most widely used today), the 
ability to use relative names, even as an accident because the API 
allows them, is a bug.

Many, many working groups have looked at the problems associated with 
relative names and determined that they're not acceptable.  It's a "bug" 
that relative names are forbidden in these apps, nor that the final "." 
is implicit and in many cases disallowed.  These are carefully 
considered design features.  (for instance, forbidding the final "." 
makes it simpler to compare domain names for equivalence.)

Ketih

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Jul 2008 20:01:42 +0100

On Mon, 7 Jul 2008, [email-masked] wrote:

> I'd be very surprised if any of these work as-is, with any reliability.
> They certainly won't work for email.  The assumption that fully
> qualified domain names contain at least one '.' is widespread in both
> protocol specifications and implementations.

I've been investigating this and I have discovered an oddity that I didn't
expect: Exim on my FreeBSD workstation handles TLD MXs without a problem,
but on my SuSE mail relays it fails. This is because of different
behaviours between the resolver code in the FreeBSD and GNU C libraries.
Both of them are based on the BIND resolver code so this is rather
surprising!

Exim uses res_search() to do DNS lookups. The postmaster can control the
resolver's treatment of single-component names using Exim's qualify_single
option, which controls the resolver's RES_DEFNAMES flag.

GNU libc refuses to resolve a single component domain name unless there's
a trailing dot (which there never is for a mail domain), or RES_DEFNAMES
is set and . is on the search list. Our mail relays use Exim's own seach
logic when looking up MXs so they switch RES_DEFNAMES off; therefore TLD
MXs do not work on those machines.

FreeBSD libc will resolve single-component names without trailing dots and
without RES_DEFNAMES set, so TLD MXs would work on FreeBSD. However,
FreeBSD's behaviour has varied in the past, and I suspect the same is true
for the upstream BIND resolver code - though I haven't checked the history
in detail.

So the question of whether TLD MXs work depends on the interactions
between lot of complicated option settings and software versions, and is
likely in practice to work or fail unpredictably.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
TYNE DOGGER: WEST 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 3 OR 4, THEN
SOUTHEAST 4 OR 5 LATER. SLIGHT OR MODERATE. SHOWERS, RAIN LATER. MODERATE OR
GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: Tue, 8 Jul 2008 15:12:23 -0400 (EDT)

> likely in practice to work or fail unpredictably.

That sounds utterly reasonable.

To me the bigger question is whether this failure scenario is something 
the IETF needs to address, or is it is sufficiently localized that it's 
something that just another thing a domain owner should deal with.

Personally, I don't think that foo@ai -> [email-masked] is a major issue, 
because in recent years mail addressing has gotten rather flat, most DNS 
resolvers are configured via DHCP, and I don't get the impression that 
they have any search lists at all.  Search lists were useful 15 or 20 
years ago, but not now.  It would be interesting to hear from people 
running mail systems who were NOT running them ten years ago, to avoid the 
selection bias of people whose configuration preferences were set on the 
T1 backbone.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 12:58:54 -0700

Keith Moore wrote:
...
> makes it simpler to compare domain names for equivalence.)

It's nonsensical for an application to decide that relative names are 
unacceptable, but to require users to input names as relative.

An explicit trailing '.' has either no impact on comparison or can only 
help. If all names have the '.' impicitly, it can be chopped off as 
redundant when it is provided by the user. If the '.' is not implicit, 
then you're preventing the user from providing it.

All the '.' does is inhibit the resolver from trying a list of suffixes 
in succession; its presence makes resolution and comparison easier, not 
harder.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 16:22:39 -0400

>> relative names and determined that they're not acceptable.  It's a 
>> "bug" that relative names are forbidden in these apps, nor that the 
>> final "." is implicit and in many cases disallowed.  These are 
>> carefully considered design features.  (for instance, forbidding the 
>> final "." makes it simpler to compare domain names for equivalence.)
> 

it's nonsensical for you to unilaterally declare that such names are 
relative, when well over two decades of practice indicates otherwise.

(and remember, some of these apps predate DNS and the whole notion of 
relative names)

it's almost as if the very concept of relative names in DNS is itself a 
bug - especially if you insist that handling of DNS names be absolutely 
uniform from one app to the next.  IMHO they cause far more problems 
than they're worth.

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 13:32:31 -0700

> relative, when well over two decades of practice indicates otherwise.

I didn't declare it; 1034 did. Apps misbehaving over arbitrary periods 
of time don't make it otherwise.

> (and remember, some of these apps predate DNS and the whole notion of 

Those apps bought into the DNS spec (or started violating it) when they 
tied into the DNS - regardless of what they did with names before.

> uniform from one app to the next.  IMHO they cause far more problems 

I agree that relative names are probably not worth the trouble, but that 
doesn't mean that I shouldn't be allowed to type a "." at the end of any 
DNS name. DNS names have a syntax; things that take DNS names as input 
and/or tie into the DNS protocol need to use that syntax, not presume to 
redefine it.

Joe

---

From: Ted Faber <[email-masked]>
Date: Tue, 8 Jul 2008 13:41:42 -0700

> (basically, non NS) records at the root seems contraindicated by several 

But there are no such non-NS records at the root.  The A record for the
host hk is on the .hk servers, not the root servers.  Conceptually, the
delegee controls the namespace at the root of the delegation.

This is exactly analogous to the practice of assigning an address to the
root of a delegated domain like isi.edu.  There are NS records in edu
pointing to isi servers and the A record for isi.edu lives inside the
delegated namespace, which is entirely consistent with federation.

> for IETF to remind people that single label TLDs are not actually 

There are plenty of reasons to argue against using TLDs as hostnames,
but I don't think consistency with the federation/delegation model is
one.

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 16:50:07 -0400

> I didn't declare it; 1034 did. 

Yes - but you're the one declaring that 1034 trumps decades of later 
work.  Normally the assumption would be that work can be revised as bugs 
are found or conditions change over time, and that things that had 
achieved IETF consensus since 1034 was published would be considered at 
least equal, and often superior, to earlier work.

I don't think 1034 was handed down from a mountain on stone tablets.

I believe it always was inevitable that different apps would use DNS (or 
any shared naming facility) in slightly different ways.  Yes this is 
somewhat confusing, but DNS (like the rest of the Internet) has been 
stretched far beyond its original design goals or scale.  For instance, 
we don't interpret DNS names as hostnames any more - because in the 
modern world the concept of "host name" is irrelevant in the vast 
majority of cases.

And maybe this provides an illustration of how difficult it is for us to 
use service protocols consistently from one application to another (it's 
not hard to find other examples).  But such difficulty is real and it 
reflects genuine differences in requirements from one app to the next. 
Arguably 1034 didn't even address the needs of apps existing at that 
time (email being one of those apps), much less apps that came later.

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2008 14:03:03 -0700

Keith Moore wrote:
>>>> It's nonsensical for an application to decide that relative names 
>>>> are unacceptable, but to require users to input names as relative.
>>>

It was not. But when other programs started using the DNS, it was *they* 
that endorsed what the DNS as per that doc.

> any shared naming facility) in slightly different ways.

Yes. Some ways are compliant, others are not.

> Yes this is 
> we don't interpret DNS names as hostnames any more 

Who doesn't? If you're saying they could be more than one host, fine. If 
you're saying they're not hosts any more, I disagree.

If you're intent on saying "the Internet is whatever anyone says it is 
on any given day" - as the above suggests - I appreciate your confusion. 
I prefer to consider the Internet as being based on standards, and 
reliably working when - and *because* - we adhere to them.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 17:11:35 -0400

> host hk is on the .hk servers, not the root servers.

I should have been clearer.  I meant the root of the name space, not the 
root zone.

> but I don't think consistency with the federation/delegation model is

I disagree.  I think this puts more pressure on the root.  It gives them 
a much larger, and more varied set of "customers" to deal with, when the 
root (i.e. ICANN) already has a fair amount of difficulty dealing with 
the ones it has.

There's a fairly basic (if implicit) assumption of DNS (and hierarchical 
names in general) that each delegation level has some shared interest 
with the one above it.  This shared interest helps to minimize conflicts 
and (more importantly) to keep those conflicts from affecting the rest 
of the net.

However, the assumption of shared interest breaks down at the root. 
This has traditionally been dealt with by imposing constraints on the 
root for all parties.  E.g.

(a) keep the root minimal and make changes only with great care,
(b) create TLDs that group together like interests and make it obvious 
where in the root a particular organization belongs (.COM, vs .ORG, vs .EDU)
(c) after .COM was captured (with various ill effects) - provide a small 
number of alternative TLDs (and with multiple, competing registrars) so 
that owner of a single TLD cannot impose a barrier to acquiring a domain.

Flattening the root (which is essentially what is being proposed) has 
the consequence that conflicts are more likely to affect parties not 
involved in the conflict.

And vanity TLDs are going to be much more attractive if people think 
they can get single-label host names out of them.

Keith

---

From: Ted Faber <[email-masked]>
Date: Tue, 8 Jul 2008 14:34:59 -0700

> they can get single-label host names out of them.

Of your concerns (which I don't have the relevant experience to comment
on in detail), this seems to be fairly small and speculative to me.

Time will tell.

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 17:41:12 -0400

> that endorsed what the DNS as per that doc.

...but they also profiled it in various ways for use with that specific 
app.  Some apps define their own RRs, others use MX or SRV or TXT 
records, others restrict the syntax of allowable DNS names beyond the 
restrictions imposed by DNS itself.  And IDNs have their own subtle (and 
not-so-subtle) effects which can also vary from one app to the next.

It's really no different than a protocol specification saying (for 
example) "this protocol is layered on top of TLS, but certain 
ciphersuites are not acceptable as they're not suitable for this case."

>> I believe it always was inevitable that different apps would use DNS 
>> (or any shared naming facility) in slightly different ways.
> 
>> Yes this is somewhat confusing, but DNS (like the rest of the 
>> Internet) has been stretched far beyond its original design goals or 
>> scale.  For instance, we don't interpret DNS names as hostnames any more 
> 

I'm saying that the mapping between a DNS name and a set of hosts is 
more-or-less arbitrary.  It can be zero hosts, one host, many hosts. 
And with MX and SRV records, the mapping between the DNS name and the 
hosts that provide that service can differ from one application to the 
next.   That's a long way from the traditional concept of "host name" 
where a host was a single box with a user community and a set of 
services that were all associated with that name.  Nowdays we're much 
more likely to use a different DNS name for each service.  The 
traditional notion of "host" as a box that you could log into is only 
one such service, and (for most users) a fairly minor one at that.

> reliably working when - and *because* - we adhere to them.

I often find myself *wishing* the Internet worked that way.  Then we 
wouldn't have NATs, for instance.  And I long for a day when we actually 
  design protocols that use other protocols based on a careful 
consideration of well-known characteristics of those substrate protocols 
- much in the way that a structural engineer (say) designs structures 
based on the characteristics of load-bearing members and fasteners.

But I don't think we're there yet.  And even if we had been doing that 
all of these years, I doubt that we'd all be using DNS in the same way 
today.  Rather, we'd have a dozen DNS-like systems, all slightly 
different from one another, with some degree of inconsistency in name 
assignment from one to the next.  Because insisting on strict adherence 
to 1035 would not have removed the need for different protocols to use 
DNS in slightly different ways.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 17:47:51 -0400

> on in detail), this seems to be fairly small and speculative to me.

it is certainly speculative.  but I do recall considerable past interest 
in "keywords" and a widespread desire to have DNS support them.  I doubt 
that interest has waned.

and I'm not very business minded - but I don't think I'd have much 
trouble finding a thousand different English words that would be worth 
far more than $100K each if I could arrange for people to be able to 
type those words into a browser and reliably get back a web page of my 
choosing.  if it's a no-brainer for me, how much easier will it be for 
someone who actually cares about making lots of money and doesn't mind 
screwing up the DNS root?

Keith

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jul 2008 10:54:45 +1000

> --mvpLiMfbWzRoNl4x
> > >presence of dot within the name but its absence from the end.=20
> >=20

	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.

> "hk", but that limitation of the application interface applies to any

	The only reason to want single labels to be looked up "as
	is" is reverse the clock and support deprecated naming
	schemes.

> > >operates exactly as any other DNS name with respect to search path.=20
> >=20
> > there are also protocol specifications that expect DNS names to have=20
> > dots in them.
> 
> > 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
> publicize the conventional DNS names and not hk. =20
> 

	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

> --mvpLiMfbWzRoNl4x
> iEYEARECAAYFAkhzo2wACgkQaUz3f+Zf+XsK4QCg2VpDMr/fF1VnBGzx7Pa4dRgs
> /0kAoJCVm5WBUIpZrAIvdIa3A2E1Gdtb
> =x6uM
> --mvpLiMfbWzRoNl4x--

---

From: Ted Faber <[email-masked]>
Date: Tue, 8 Jul 2008 18:42:59 -0700

> 	The (some) resolver handles names differently if it contains a dot.

The distinction that I have been unclearly stating is between absolute
and relative names.  RFC 1034 (i said 1035 earlier, but it's 1034) lays
out a convention for specifying which one you want by appending the dot.
As long as you tell the resolver which one you want, it matters little
if the dot character is at the end or not.

1034/1035 compliant resolvers are allowed to do site dependent things to
relative names and not to absolute ones.

> 	be looked up against the search list.

I prefer the 1034/1035 view that this sort of decision is up to the
application and the DNS admin and that the DNS simply provides the
ability to do both.

> 	is" is reverse the clock and support deprecated naming

I don't "want" anything in this space.  I don't care if the root's
unchanged or as wide as .com.

If I "want" those labels to work at all it's because their working
reflects a clean DNS design.  It (irrationally) warms my heart to see
that they mostly do.  I'm not extending my admiration of the design
into an operational recommendation, no matter how much you'd like me to.

The fact that the existing TLDs could do this would lead to a pretty
boring flat name space - 110 names fit in /etc/hosts or equivalent just
fine.  A proliferation of TLDs is your problem, of course.  I don't
think that forcing the seekers of vanity TLDs to prepend "www." to their
webserver hostname is going to change anything. After all many browsers
will add that for you.  

If you're worried about a flat namespace, attack the right problem - a
proliferation of TLDs, not this business of the TLD having an A record
at the top.  For most uses, www.<yournamehere> is just as flat.  And
just as flat as <yournamehere>.com, I might add.

> 	of these are not codified.

If there are only a few TLDs I really fail to see how this one fits
there and if there are a lot of TLDs I don't see how outlawing it helps
you.  But YMMV and I'm not running a TLD server, so my opinion matters
little.

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Jul 2008 21:59:46 -0400

> if the dot character is at the end or not.

in my experience, far too often applications don't tell the resolver 
which one they want.  also, APIs can vary enough from one implementation 
to another that a "portable" application may behave differently 
depending on which API implementation it is using.

> relative names and not to absolute ones.

for better or worse, application protocols and applications haven't 
strictly followed 1034/1035 in this regard.

> application and the DNS admin and that the DNS simply provides the

in general I agree, but I think we've learned a few things since then 
about the corner cases.

(I would _almost_ agree that "pet" should never be looked up as plain 
"pet" - except that I think it should be possible to directly query a 
server to find out what RRs that server has (right or wrong) and I 
wouldn't want the server to lie or the API to prevent such queries. 
That's why I would rather forbid servers to forward single-label queries 
- and perhaps, to refuse to cache NS records for them.)

> reflects a clean DNS design.  

Cleanliness is secondary to function.  The purist in me likes regularity 
too.  But even if the _protocol_ is the same at the root as for any 
other zone, the root of the _name space_ really is special, and 
inherently so (given that these labels have semantics associated with 
them).  At a certain very technical level there is no difference between 
the root and any other zone.  But at a different level the root has a 
special role and is different than the other zones.  It is a single 
point of failure - not in the sense of a single server or a single 
network link but in the sense of a single organization running it whose 
mistakes affect the entire network.  Also, the relationship between the 
root and its subdomains is likely to be very different than that between 
any other domain and its subdomains.

> at the top. 

Vanity TLDs are indeed part of the problem.  Without vanity TLDs there 
would be much less incentive to have single-label domain names.

(I guess I need a better name than "vanity" TLDs for these - but I think 
you get what I mean.)

Keith

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jul 2008 12:54:24 +1000

> --5me2qT3T17SWzdxI

	"hk" is not a legal absolute hostname.  The current resolver
	code handles all legal absolute hostnames (has a dot in the
	middle).

	Tools that look in the DNS have to handle *more* than
	hostnames such tools may need to treat "hk" as absolute in
	which case "hk." is reasonable.  "dig" and "nslookup" are
	examples of such tools.

	Telnet is not a example of a tool that need to support "hk."
	as it is expecting hostnames not arbitary domain names.

	Web browers are not tools that needs to support "hk.".

> application and the DNS admin and that the DNS simply provides the

	You are wanting to extend the definition of a legal absolute
	hostname.
 
> unchanged or as wide as .com.

	There was a clear decision to move from a single label
	hostnames to multiple label hostnames (RFC 921).  You are
	attempting to reverse that decision.

	Just because it is technically possible to add A records
	at the apex of a tld or to add A records to names with
	underscores in them doesn't change the fact that doing
	either of these is a bad idea.

> into an operational recommendation, no matter how much you'd like me to.

	No, it doesn't represent clean design.  Making them work is
	outside of the design scope.  Unqualified names being looked
	up against search lists was in the design scope.  The
	official names of hosts having multiple labels was in the
	design scope.  Single labels were explictly excluded from
	being official names in the design scope.

	Having single label hostnames match against the root is a
	clear implementation error.

> will add that for you. =20
>
> --5me2qT3T17SWzdxI
> iEYEARECAAYFAkh0F6MACgkQaUz3f+Zf+XuzqQCcC69WZYCEJvHjCbVDgo4rB6WE
> 2owAnji2UmzqfY2p2kQTFKfXdZ2toe4Q
> =hUoe
> --5me2qT3T17SWzdxI--

---

From: Bill Manning <[email-masked]>
Date: Wed, 9 Jul 2008 06:27:48 -0700

> on in detail), this seems to be fairly small and speculative to me.

it is possible to have a host name also be a domain name.
myself, i look forward to sending email to

	<ted@v>

-- 
--bill

---

From: Ted Faber <[email-masked]>
Date: Wed, 9 Jul 2008 10:30:26 -0700

> 	attempting to reverse that decision.

I've said everything I want to say about this topic, but I'd like to
reiterate that I'm not attempting to reverse any decision.  I have no
hidden agenda and I am not advocating a policy position based on
technical and conceptual feasibility (or anything else).

I don't care which one the community picks here.  I've now asserted it
twice.

I don't care which one the community picks here.  Now it's true.