On Mon, Nov 23, 2015 at 1:08 PM, 神明達哉 <jin...@wide.ad.jp> wrote:
> 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). Yes, I agree. The current description is a bit too implementation specific. > 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. > Also agree. I think it would be best if this draft remained focussed on correct interpretation of the NXDOMAIN response code, and leave this SOA discussion out. > > > 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. > > > 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. > Yes, this sounds appropriate. -- Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
