Hi Stephane, I read over this and have a few thoughts to share:
This updates RFC 2308 (Negative Caching of DNS Queries). This would seem to be the key text from 2308 to update: A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response. RFC 2308 defines four types of NXDOMAIN responses, all of which have a CNAME RR in the answer section. They differ in the contents of the authority and additional sections. I'm not sure why 2308 doesn't have a simple NXDOMAIN type (with no answer RRs) but it seems likely the new draft will need to address CNAME and friends. I think the WG needs to discuss and agree whether or not to make the NXDOMAIN cut based on QNAME only, or on the SOA owner name. If the goal is to thwart random qname attacks, then it would be better to use the SOA (or hope for wide adoption of qname minimization). Implementing NXDOMAIN cut should also reduce the effectiveness of a Kaminsky attack since the attack relies on the cache to forward numerous non-existent names. I think its a little dangerous to say that an NXDOMAIN response SHOULD cause a cache to delete already cached "positive" data. Perhaps MAY is a better choice there. Or SHOULD when DNSSEC validated, but MAY without. In Acknowledgements, s/Roland/Rodney DW > On Nov 6, 2015, at 12:22 AM, Stephane Bortzmeyer <[email protected]> wrote: > > The stuff discussed in Yokohama yesterday. > > From: <[email protected]> > Subject: I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-00.txt > Date: November 6, 2015 at 12:18:31 AM PST > To: <[email protected]> > Reply-To: <[email protected]> > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : NXDOMAIN really means there is nothing underneath > Author : Stephane Bortzmeyer > Filename : draft-bortzmeyer-dnsop-nxdomain-cut-00.txt > Pages : 7 > Date : 2015-11-06 > > Abstract: > This document states clearly that when a DNS resolver receives a > response with status code NXDOMAIN, it means that the name in the > question section AND ALL THE NAMES UNDER IT do not exist. > > REMOVE BEFORE PUBLICATION: this document should be discussed in the > IETF DNSOP (DNS Operations) group, through its mailing list. The > source of the document, as well as a list of open issues, is > currently kept on at Github [1]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-nxdomain-cut/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-bortzmeyer-dnsop-nxdomain-cut-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
