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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
