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

[Warren Kumari <[e-mail]>]

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.

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.
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf