Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Petr Špaček <[e-mail]>]

On 27.1.2018 18:56, Warren Kumari wrote:
> On Fri, Jan 26, 2018 at 6:03 PM, Viktor Dukhovni <[e-mail]> wrote:
>> On Fri, Jan 26, 2018 at 02:24:26PM -0600, Ted Lemon wrote:
>>
>>>> Disagreed, with respect to recursive resolvers, because the
>>>> requirement is neither necessary nor sufficient to achieve the
>>>> stated security goals, is not required for interoperability, and
>>>> is in conflict with existing uses of local data for localhost.
>>>
>>> The point of the requirement is that it breaks stacks that use DNS to look
>>> up localhost.
>>
>> Multiple participants in this discussion have pointed out that such
>> queries are rare.
> 
> <no hats>
> 
> I've somewhat lost track of which exactly "such queries" are
> ('localhost', '*.localhost', with or without DO bit, etc), and what we
> are considering as "rare", but, as mentioned in
> https://mailarchive.ietf.org/arch/msg/dnsop/k9Rec7WuLCLjLBb5hI7kynAxf3U
> :
> 'Around 0.3% of responses from Google Public DNS are for "localhost".'
> 
> If I opened a packet of M&Ms[0] and <0.3% of them were green I'd call
> green M&Ms rare, but if 0.3% of people who went swimming got eaten by
> sharks I'd likely not call shark attacks rare :-p
> 
> 
> 
>>  And, we must not forget that, absent local
>> overrides, the iterative resolvers are *already* returning NXDomain,
>> because the authoritative data from the root returns NXDomain.
> 
> 
> ... do they?
> 
> Google Public DNS:
> $ dig  +dnssec localhost @8.8.8.8
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62555
> ;; AUTHORITY SECTION:
> . 64929 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018012700
> 1800 900 604800 86400
> . 64929 IN RRSIG SOA 8 0 86400 20180209050000 20180127040000 41824 .
> i1JPur/fqut5...==
> 
> 
> Verisign Public DNS:
> $ dig +dnssec localhost @64.6.64.6
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8025
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 10687 IN A 127.0.0.1
> 
> 
> Quad9:
> $ dig +dnssec localhost @9.9.9.9
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22677
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 86170 IN A 127.0.0.1
> 
> 
> OpenDNS:
> dig +dnssec localhost @208.67.222.222
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14156
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; ANSWER SECTION:
> localhost. 604800 IN A 127.0.0.1
> 
> 
> My local BIND instance:
> # dig +dnssec localhost @127.0.0.1
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62183
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> ;localhost.                     IN      A
> 
> ;; AUTHORITY SECTION:
> .                       10800   IN      SOA     a.root-servers.net.
> nstld.verisign-grs.com. 2018012700 1800 900 604800 86400
> .                       10800   IN      RRSIG   SOA 8 0 86400
> 20180209050000 20180127040000 41824 . i1JPur/fqut5jJ...
> 
> 
> (above examples edited for readability. No queries were harmed in the
> making of this).
> 
> I'm not really sure anymore who's point I'm making here, but I
> disagree that localhost queries hitting the DNS is rare, and that
> iterative resolvers already return NXD - some do, and some don't.

To add more to this, Unbound by default returns 127.0.0.1, and so does
Knot Resolver, because both decided to respect
https://tools.ietf.org/html/rfc6761#section-6.3

This is a security hole, and again, purpose of NXDOMAIN is to make it
fail safe instead of keeping insecure stub implementations doing what
they did up until now.

So again, I support documents in its current form.

Petr Špaček  @  CZ.NIC


> W
> </no hats>
> 
> 
> [0]: For non-Americans, M&Ms are kind of like Rowntree (now Nestlé)
> Smarties[0], but much less tasty.
> [1]: For American readers, Rowntree Smarties are like much much better
> M&M's, and *nothing* like the US Smarties (which are mainly sugar,
> citric acid and calcium stearate, but always taste like chalk to
> me...).
> We'll be in London soon, you should really give them a try...
> 
> 
>>
>> So what you seem to be asking for is to *require* implementations
>> that currently serve local data with the expected loopback addresses
>> (and don't forward towards the root) to stop doing as configured and
>> return NXDomain.  Despite the explicitly configured "knobs" that turn
>> on this non-default behaviour.
>>
>> I claim that this is too big a hammer for too small a nail.  There
>> is simply no need to do this.  A clear requirement to short-circuit
>> localhost name -> address resolution *before* it gets to the resolver
>> is quite sufficient.  I'm breathlessly enthusiastic for this part
>> of the draft. :-)
>>
>>> If you think there's no risk to applications that rely on
>>> this, obviously it's not worth doing.   The reason I'm being such a stickler
>>> about this is that we have beaucoup experience over the past two decades
>>> that if there is an attack surface, somebody will come up with an attack.
>>> It's better to fail safe than fail unsafe.   If apps are breaking all over
>>> the place because they use DNS to look up localhost, then we all win in
>>> the long run.
>>
>> Reports from the field seem to indicate that this is largely a
>> non-problem, and perhaps the maintainers of glibc and the like will
>> pay attention to this specification and ensure correct localhost
>> resolution without asking even the (e.g. glibc) DNS stub resolver,
>> let alone an upstream recursive resolver.
>>
>>> That said, I absolutely do not want to deprive you of the ability to do
>>> your hack.   I just don't think that the current text does that.
>>
>> The MUST says otherwise, and if we don't mean that, then we should
>> not say so.
>>
>>> If the way the stack accomplishes the MUST is to have some code in
>>> nsswitch.conf that does the right thing, I think that follows the MUST.
>>
>> It follows the MUST for the part I am breathlessly enthusiastic about,
>> the requirements on the hostname -> address resolution library.  No
>> problems with that at all.  My objection all along is with the MUST
>> at the recursive resolver.
>>
>>> The reason I drilled down into your use case is that I don't think there's
>>> ever going to be a time when Christos disables this behavior.   So I don't
>>> think this text is going to actually create an inconvenience for you.
>>
>> I'm fine with MUST NOT FORWARD, except when the DO bit is set in
>> the query, in which case I'm inclined to say that a validated
>> NXDomain from the root is better than a bogus NXDomain, and
>> is still (or more) secure.
>>
>>> Is there a way we can change what the text says so that it's sufficiently
>>> emphatic to make me happy, and sufficiently open to make you [not] unhappy?
>>
>> Yes.  Keep the MUST for the platform library.  Downgrade the MUST for
>> the iterative resolver to a SHOULD (absent local data), and either
>> exempt DNSSEC or explain why "bogus" local NXDomain is better than
>> a cacheable validated NXDomain from the roots.
>>
>> --
>>         Viktor.