On 27.1.2018 18:56, Warren Kumari wrote: > On Fri, Jan 26, 2018 at 6:03 PM, Viktor Dukhovni <[email protected]> > 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. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
