On Feb 9, 2018, at 5:55 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > > Hi, > > On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote: >> That's pretty clear. This document is not forbidding the appearance of >> such names in the DNS, nor the resolution of such names. >> > > Instead, it is wanting to have its cake and eat it too. Because… > >> >> Note, however, that the admonition against searchlist usage could >> affect their resolution in practice, as discussed in Section 3 > > …of the "admonition" (or whatever you want to call it). In effect, > the document requires special-casing of "localhost" as a label in > every searchlist context.
This is really fascinating. To me what this code requires it something like the following, in any affected stub resolver: resolve(name): if (name == 'localhost'): return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')] if labelcount(name) == 1: for domain in searchlist: result = resolve_dns(labelconcat(name, domain)) if len(result) != 0: return result return resolve_dns(name) What is needed without this restriction, is either the same code, because it's what is obvious to any thinking person (kidding!) or: resolve(name): if labelcount(name) == 1: for domain in searchlist: result = resolve_dns(labelconcat(name, domain)) if len(result) != 0: return result if (name == 'localhost'): return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')] return resolve_dns(name) So to me there is no obvious architectural superiority to what you think is correct. It's just a question of whether to test for localhost before or after the domain search list loop. The standard you refer to currently says: 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. So in fact what we are saying is completely consistent with STD13, in the sense that STD13 does not require some other behavior than what we are specifying. It's true that behaviors that are allowed by STD13 are forbidden by this document. That's the point. What this admonition does is to remove an ambiguity in the specification, and for good reason. Yet to you it appears to be self-evident that the second code sample is correct, and the first is "having your cake and eating it too." Obviously you are seeing something here that I am not. Can you point it out? > The reason I think that is because of the earlier part: > > 2. Application software MAY recognize localhost names as special, or > MAY pass them to name resolution APIs as they would for other > domain names. > > If you can just pass this to a resolution API, then it's actually the > resolution API that needs to know to handle the search list rules > according to this new specification (this part of the specification > does not say that you can only use the API if you can tell the API not > to use search lists, &c). Yes, applications may anticipate broken APIs and do the right thing prophylactically. But APIs should do the right thing anyway. Is that what you mean with the cake bit? > there's > no reason to suppose that this alternative approach is going to make > things any better. Essentially what you are saying is that because existing name servers do not take advantage of this attack surface, there is no reason to remove it. :)
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop