> On 27 Jan 2018, at 11:02 am, Ted Lemon <[email protected]> wrote: > > On Jan 26, 2018, at 5:03 PM, Viktor Dukhovni <[email protected]> wrote: >> Multiple participants in this discussion have pointed out that such >> queries are rare. > > Sigh. Yes, such queries are rare. The things that make those queries are > the things that are vulnerable. That such queries are rare is further > evidence that responding to them when they come with NXDOMAIN is a safe > choice to make.
Actually NXDOMAIN is the WRONG choice to make. NXDOMAIN is driven by not wanting to engage with ICANN and sort out the fact that the TLD is scoped for local use and to deal with all the side effects of that come with that especially when DNSSEC is in use. 10.IN-ADDR.ARPA is scoped for local use and a insecure delegation to a otherwise empty zone works fine for it. This is NO TECHNICAL REASON TO RETURN NXDOMAIN! >> 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. > > That's a good point, of course. However, I think we heard in the discussion > prior to adoption that this is not in fact the default behavior for all > recursive resolvers. Local resolvers can return NODATA just as easily as NXDOMAIN by default and that with a insecure delegation is perfectly fine. >> 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. > > How about if it says "SHOULD" but explains what the exception is, and > strongly advocates the position that only when that exception is applicable > should this be treated as optional behavior. > > I would say that the exception is "when answering queries for the local host" > or something, but I don't understand the intricacies of your use case > sufficiently to know what would satisfy it. I thought I understood your use > case to be the case where the stub resolver is on the same host as the > recursive resolver, but I may have misunderstood. > > The case I'm trying to exclude is the one where the recursive resolver is > answering queries for hosts other than, well, localhost. > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
