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
