At Sun, 22 Nov 2015 14:52:34 +0100, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
> > I've read draft-bortzmeyer-dnsop-nxdomain-cut-00 > > Do note that -01 will be out in the next days and there are > substantial changes. So, readers may prefer to wait 48h :-) Okay, I'm now referring to 01. > > I suspect this is highly implementation dependent and so the > > RFC2119 'SHOULD' is not really appropriate. First off, what > > "delete" means isn't very clear. > > It is now defined. ' "Deleted" means that subsequent requests for > these names will yield NXDOMAIN. ' > > > But even if the resolver doesn't really "delete" the memory, it > > could look as if it did as long as the resolver doesn't use it for > > subsequent query handling > > Correct, but this is a general rule with IETF protocols: we mandate > the external behavior, not the implementation. That was exactly my point, and in that sense I'd say "SHOULD delete" is redundant (and possibly imposes unnecessary restrictions on implementations). The revised wording in 01 now looks even more redundant: When an iterative caching DNS resolver stores an NXDOMAIN in its cache, all names and RRsets at or below that node SHOULD be deleted since they will have become unreachable. "Deleted" means that subsequent requests for these names will yield NXDOMAIN. as it's already covered in the first paragraph: When searching downward in its cache, an iterative caching DNS resolver SHOULD stop searching if it encounters a cached NXDOMAIN. The response to the triggering query should be NXDOMAIN. (Strictly speaking it does not use a 'SHOULD' about returning NXDOMAIN for these queries, but that should be a natural consequence of the SHOULD about stopping the search). > > I suggest stating that more clearly. > > Done Regarding this topic, I think it should rather refer to qname-minimization here: queries. (It would be better if the SOA record in the NXDOMAIN response were sufficient to find the non-existing domain but this is more delicate, see Section 5.) than updating the interpretation of SOA. qname-minimization is much less controversial and will certainly help in this scenario. > > A minor corner case, but I suspect this is not fully accurate if > > QNAME is the name specified in the question section. > > Added. Perhaps you might introduce a dedicated terminology such as "NXDOMAIN name" as used in someone else's comment and use it consistently, rather than just note this once and keep using QNAME in other places. > > [joost-dnsterror] > > Joost, M., "About DNS Attacks and ICMP Destination > > Unreachable Reports", December 2014, > > <http://www.michael-joost.de/dnsterror.html>. > > > > Getting this URL resulted in 403 error. Is that only for me? > > Works for me. Sorry for the false alarm, it seems to be my local problem. One additional comment on 01: - Section 7 The technique described here may help against a denial-of-service attack named "random qnames" and described in Section 3. I suggest "a denial-of-service attack on authoritative servers" for the same reason as my comment on the "benefits" section of the previous version. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
