Thanks for the review!
On 14 Jan 2016, at 11:32, 神明達哉 wrote:
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."?
Good catch. The RRset will expire at the same time.
(btw I think 'root zone' is better
than 'root servers' here).
This is not the expiration on the whole root zone, only on the NS
records. The expiration of the root zone itself comes from the SOA,
which has a different value than the TTLs on the NS RRset. That is, in
the current root, the expiration in the SOA is 604800 but the TTLs on
the NS records are 518400.
- Section 3.1: some modern recursive servers "prefetch" un-expired
RRsets. We might also mention that case here.
Yes.
- 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.
The first bullet point is not necessary for your argument. Would the
following be better than the quoted sentence?
At the time this document is being published, there is little use to
performing
DNSSEC validation on the priming query. This is because being able to
validate
the NS records is not sufficient for having authenticated addresses for
the root
servers: having validated A and AAAA RRsets for each root server is also
needed.
Without those validated A and AAA RRsets, a man-in-the-middle attack on
the
priming query can result in malicious data in the responses
- 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.
Those implicit assumptions are not needed for the current text. RFCs
1034 and 1035 and 2181 do not restrict what can be put in the Additional
section to only being things for which the server is authoritative.
- 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.
This seems like a reasonable question. What do others think?
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.
Fixed. Thanks again!
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
