On Feb 5, 2018, at 12:18 AM, Mark Andrews <ma...@isc.org> wrote:
> The original problem is that HTTP doesn’t specify that names learn across the
> wire, including from on disk html files, need to be treated as absolute names.
> This is HTTP’s mess due to allowing relative names in what is transmitted over
> the wire.  This should be sent back to HTTP say FIX YOUR INSECURE PROTOCOL.

That's totally orthogonal to the question we are considering.   It's also 
nonsense.   How does HTTP, a protocol, know the source of an IP address that 
it's been given by the name resolution API?   Does the API even give you a way 
to tell?   What you mean is that the implementation should know the difference. 
 This is what the document is doing.   It's saying that the API should never 
look this name up in the DNS.

> The second bugtraq issue is also HTTP’s insecure security model that doesn’t
> take into account that addresses have scopes.  Again that is for HTTP to fix.

HTTP should certainly be smart about scopes, and I would argue that "machine 
scope" is not a scope in which connections should be assumed to be trustworthy, 
so indeed in a sense that you are right.

But the reason for wanting the DNS to not return answers for localhost is that 
implementations may get this wrong, and if they do we want it to fail safe.   
So again, your premise is valid, but doesn't apply.

As for search lists, I think it's reasonable to say that search lists, which 
are not part of the DNS protocol, should not be applied to the bare label 
'localhost.'   If the document said that DNS servers should treat FQDNs 
containing the label 'localhost' specially other than when it is the top-level 
label, that would be wrong.   But it doesn't say that.   It just specifies the 
handling of localhost with respect to searchlists, and what it says is correct 
and important.   If I can supply you a search list and use that to trick you 
into connecting to a remote service rather than a local one, that's a 
significant attack surface.

DNSOP mailing list

Reply via email to