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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf