At Wed, 13 Jan 2016 13:53:06 -0800,
"Paul Hoffman" <paul.hoff...@vpnc.org> wrote:
> We'd really like folks to review it, particularly because this is such a
> large change from earlier versions. The document is still definitely
> open for discussion, and if there is consensus to reverse some of the
> changes, that's of course fine. Regardless, let's get this published in
> a form where everyone (?) is happy.
Here are my comments on the 06 version:
- Section 3.1
[...] This would be when the resolver starts with an empty cache,
and when one or more of the NS records for the root servers has
expired.
This seems to talk about a recursive server behavior that allows a
subset of an RRset to expire. Is that the intent? Is there any
reason why we can't simply say "...and when the NS RRSet for the
root zone has expired."? (btw I think 'root zone' is better
than 'root servers' here).
- Section 3.1: some modern recursive servers "prefetch" un-expired
RRsets. We might also mention that case here.
- Section 3.3
[...] At the time this
document is being published, there is little use to performing DNSSEC
validation on the priming query because the "root-servers.net" zone
is not signed, and so a man-in-the-middle attack on the priming query
can result in malicious data in the responses.
I think this text needs more explanation. Since the priming query
is "./NS", it's not immediately obvious why the fact that
"root-servers.net" is unsigned matters. This text seems to be based
on some implicit assumptions/facts such as:
- all root servers are authoritative for the root-servers.net zone
- we'll eventually need AAAA and A RRsets of the NS names
- even if ./NS is signed, it's not very useful in practice unless
these AAAA and A are also signed
and, reading between the lines I think I can agree with the seeming
intent, but IMO it should be explained more clearly and explicitly.
- Section 4.1
answer section) and an Additional section with A and/or AAAA RRSets
for the root name servers pointed at by the NS RRSet.
Similar to the previous point, it seems to be based on some implicit
assumptions including:
- all root servers are authoritative for the root-servers.net zone
- all these servers populate the additional section from a different
zone they are authoritative for than that for the query name ("."
in this case)
- none of the root server implementations use the
"minimal-responses" (or equivalent) option
I think these should be clearly stated.
- Section 4.2
For an EDNS response, a resolver SHOULD consider the address
information found in the Additional section complete for any
particular server that appears at all.
This one also seems to assume some particular behavior of the root
server implementations. At least protocol-wise, we cannot
necessarily assume this completeness, right? Then I'd also suggest
clarifying the assumption.
Editorial nits:
- Section 3.2: s/other other/other/
[...] Two other other
common methods include picking the first from the list, and
- Section 4.2: s/to to/to/
[...] Instead, the recursive resolver needs to to
issue direct queries for A and AAAA RRSets for the remaining names.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
