On Oct 24, 2011, at 7:55 AM, Alex Bligh wrote: > > > --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 the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases. The presence or absence of a '.' is a simple and easily-understood convention. It might be somewhat inconvenient for large organizations that currently rely on search lists for multi-label names, but overall that's a small price to pay in exchange for having consistent behavior of domain names across the board. The only reason that those organizations have managed to get away with it so far is that TLDs (particularly TLDs with more than 2 characters) have been relatively few in number. But with vanity TLDs this will no longer be the case. >>> 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. No, it's not ambiguous. It's fully qualified. > 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. That's insane. That allows a local enterprise to change the meaning of every domain name. Domain names are supposed to have the same meaning everywhere in the Internet. >>> 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. My assumption is that search lists in conjunction with multi-label names are mostly used within fairly large enterprises, but search lists are potentially in much wider use. >>> 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. No disagreement on that point. But search lists always have been broken. It's just unfortunate that DNS APIs have supported them for so long, and their behavior has become entrenched in several organizations (including some that ought to know better). My belief is that local names (i.e. bare or single-label names) are useful and necessary but their behavior cannot really be standardized. So letting them continue to be subject to search lists is a useful compromise that is less drastic than doing away with search lists entirely. It also has the virtue of being a simple rule that users can easily understand (a name with a "." is always fully qualified and usable in a global context, a name without a "." is ambiguous and only useful in a local context). Keith _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
