I've read draft-bortzmeyer-dnsop-nxdomain-cut-00 and have a few comments. (I support the basic idea of the proposal, btw)
- Abstract: s/status code/response code/ This document states clearly that when a DNS resolver receives a response with status code NXDOMAIN, it means that the name in the - Section 2 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. 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. If the resolver implementation frees memory region used for the corresponding cached RRsets that are now known to be nonexistent, it would be certainly considered a "delete". 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 (as described in the first paragraph). And the implementation may actually rather prefer to keep them in-memory until it needs memory for other purposes to save the overhead of actually freeing them. So, in terms of interoperability the only important requirement is the first SHOULD. IMO, whether the resolver implementation should "delete" the ancestor RRsets (including what "delete" actually means) should leave to specific implementation, and therefore I suggest just removing this paragraph. - Section 3 NXDOMAIN cut may also help with random QNAME attacks [joost-dnsterror] [balakrichenan-dafa888]. In these attacks, queries are sent for a QNAME composed of a fixed suffix ("dafa888.wf" in one of the articles above), which is typically nonexistent, and a random prefix, different for each request. If the intended attack is against the authoritative server (such as that for "dafa888.wf" or "wf") exploiting innocent resolvers, then I see that. But if it's about the attack against the resolver (forcing it to perform recursive resolutions very often), I doubt the mitigation effect of this proposal since the attacker can easily circumvent the defense (using '<random>.' or existent names in a zone that has a wildcard, etc). Assuming the intended attack is the former type ([balakrichenan-dafa888] seems to talk about that type of attack), I suggest stating that more clearly. - Section 5 In this document, we deduce the non-existence of a domain only for NXDOMAIN answers where the QNAME was this exact domain. A minor corner case, but I suspect this is not fully accurate if QNAME is the name specified in the question section. If I remember it correctly BIND 9 returns an NXDOMAIN if it finds a CNAME chain that leads to a non-existent name. In this case "QNAME" itself exists but the response is NXDOMAIN. I'm not sure if we do something about the text because of this, but I'm noting this just for completeness. - References [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? -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop