--On 24 October 2011 07:29:55 -0400 Keith Moore
<mo...@network-heretics.com> wrote:
I'm just pointing out that for the vast majority of the contexts in
which domain names are used, the expectation is that a domain name that
contains a "." is fully-qualified.
This is sampling bias.
No, I don't think so. The vast majority of contexts where domain names
are used, are contexts in which the domain is supplied by one party and
(at least potentially) used by another party. Email addresses, URLs,
domain names written on advertisements and business cards, etc.
Of course, but that explicitly excludes every case where a search
list is useful. That's why I'm saying you have to look at the
cases were a search list is used. In large organisations "domain names"
(used loosely) can have dots in and be expected to have
search list items appended. Given search list use is rare,
it's obviously going to be rare to have them with dots.
The question here should be "where search lists are used, are
they frequently used in combination with domain names that
are not fully qualified". I would suggest the answer to this
question is "yes".
That's not a useful way to phrase the question, because there's no way
for software to know whether or not the user intends that a name
containing "." is fully-qualified.
You are begging the question. Of course the name "foo.bar" is
ambiguous. That's precisely /why/ there is a search list, so
foo.bar is only looked up if foo.bar.example.com (or whatever)
does not exist. The existence of the "if" step means that the
software cannot know what the domain means (in the sense
of what it will ultimately resolve to) without doing a lookup.
If so, then to the extent that search lists
are supported, you need to make them interwork names with
dots in them. Moreover, with a search list of "example.com",
having "mail" work, but not "mail.dev" is going to be a
pretty surprising outcome.
It will be surprising to that relatively small portion of users that
relies on search lists being applied to multi-label names. But overall,
having a clear, visible distinction between names for which searching is
potentially applied (i.e. bare or single-label names), and names for
which searching is not applied (multi-label names) results in less
surprising behavior for everyone.
I do not think you have established that a relatively small number
of users of search lists use multi-label names. I suspect that
is not true.
I think the two options are either deprecating search lists
(or not supporting them), or supporting them properly, in
which case they must be used whatever domain name is
specified, and the way to avoid using a search list
is the same old hack as before (i.e. putting a dot on the
end).
Supporting search lists "properly" is NOT using them whenever a domain
name is specified. That makes all domain names context-sensitive, and
breaks every application that uses domain names supplied by other parties
or in other contexts.
I don't have RFC references to hand, but precisely for the reasons you have
set out above, I do not believe there is anything within them that search
lists should only be used if "a domain name is specified", precisely
because it's impossible to tell whether a string with dots in it is "a
domain name", or merely something to go on the front of search lists.
What you are, I think, saying, is that you want to change the behaviour of
search lists so they only work with single labels. What I'm saying is that
there are likely to be a significant number of users of search lists who
are affected by that, as they currently pass things with dots in them. A
completely unscientific analysis I know, but every internet company I have
worked with since we moved out of uucp naming has done this, and not
because I have told them to. Even current 20 person software house does
this. So, if you are going to substantially break search lists (which is
not inherently a bad idea - they have caused all sorts of trouble in times
past), you might as well just deprecate them or not support them.
--
Alex Bligh
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
