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

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

 



Ted Faber wrote:
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.
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.

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.

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.

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.

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

One could argue that such protocols are not able to express all valid
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
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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