I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This document suggests that resolvers should use NSEC/NSEC3 proof of non-existence for a domain name in a received query to generate a negative reply, rather than relying on the current spec of an exact match to the domain name. Generating positive replies from wildcard answers is also suggested.
The motivation is improvements in latency for queriers and improvements in bandwidth and CPU load on recursive resolvers and validation servers.
I have no serious objections about the draft.
I am curious about my thought that an attacker might find this of benefit, as they can learn of non-existence in just one query, rather than every name in a NSEC denied range. I know zone walking is a concern to some, but I do not know if ease of determining non-existence is also a concern.
Section 7 explicitly spells out the changes to RFC4035 are explicitly spelled
out as to what is removed and what replaces it. Section 5 is not so clearly
delineated.
The last paragraph of 5., nothing in 5.1 or 5.2, and the last paragraph of 5.3
use SHOUD/MUST/MAY kinds of language. For the paragraphs that don’t - should
they? For the paragraphs that do, is this additional behavior or a
replacement for existing spec (i.e. like the section 7 update to RFC4035).
If a replacement, a replacement of what? If not, where do the new paragraphs
fit?
The following is a sequential set of comments, not in importance order.
page 3
This document updates RFC 4035 to allow recursive resolvers to use
NSEC/NSEC3 resource records to synthesize negative answers from the
information they have in the cache.
re: recursive resolvers - is the technique not applicable to stub resolvers?
(I do see references to stub resolver caches in a web search, but you can’t
trust the web.)
[RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to
using NXDOMAIN information for more effective caching. This takes
this technique further.
Unless rfc8020 and the vixie draft are the same thing (don’t think so),
should be “propose”.
Too many uses of “this” in that last sentence - I presume you mean
This draft takes those previous techniques further.
page 4
If a validating resolver receives a query for cat.example.com, it
contacts its resolver (which may be itself)
Maybe
If a validating resolver receives a query for cat.example.com, it
contacts its recursive resolver (which may be itself)
About:
and also has
privacy implications (e.g: typos leak out further than necessary).
Does it also make certain explorations easier, where someone can find out a range
that does not exist by doing just one query rather than query every name in the
range? Or is that sort of exploration already prevented by other techniques?
If a query is received for leek.example.org, it contacts its resolver
(which may be itself)
I suggest “the resolver contacts its <recursive> resolver” - the query is not
doing the contacting.
page 6
section 5.1 and 5.2 say “resolver can immediately return” - is this meant
to specify new behavior, should they have SHOULD/MAY/MUST kinds of words?
page 7
Section 5 of [RFC2308] states that the maximum number of negative
cache TTL value is 3 hours (10800).
I don’t find a maximum in RFC2308. I do find:
Values of one to three hours have been found to work well
and would make sensible a default.
Did I miss something?
“the maximum number of negative cache TTL value is” - a bit twisty. Did you
mean something like:
Section 5 of [RFC2308] states that the maximum negative cache TTL value is”
otherwise, I’d think “number of … values”, but even so I don’t think there are
multiple values here. Are there?
page 9
<truly nitty>
The text says
Thanks to Mark Andrews for providing the helpful notes for
implementors provided in Appendix B.
The authors would like to specifically thank
…
Mark Andrews also provided the
helpful notes for implementors (https://www.ietf.org/mail-
archive/web/dnsop/current/msg18332.html) which we made into
Appendix B.
Perhaps you intended to thank him twice? No problem, just wondering.
—Sandy
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail