On 15 Jan 2016, at 10:03, 神明達哉 wrote:
My incremental different suggestion was to revise it further:
[...] This would be when the resolver starts with an empty cache,
and when the NS RRSet for the root zone has expired.
Is it clear enough now, or did you mean this last text has an issue
(like as if it talked about zone expiration)?
This is fine, and it will be in the next version.
- 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.
[...]
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
Looks good to me (I'd say "A and AAAA RRsets for each root server
*name*" though).
Please see the message I sent yesterday with Warren's challenge about
this section. It would be good for the WG to come to consensus on the DO
bit before we do more wordsmithing.
- 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.
Right, but there's no requirement what to be put in the additional
section, so this "expected property" relies on a particular
implementation behavior (rather than something we can expect from any
"protocol-compliant" implementation). That's fine to me, but I
thought it should be clearly stated.
This is a good point: the current text conflates all three things. How
about:
The priming response is expected to have an RCODE of NOERROR, and to
have the
AA bit set. Also, it is expected to have an NS RRSet in the Answer
section (because the
NS RRSet originates from the root zone), and an empty Authority section
(because the
NS RRSet already appears in the answer section). There may be an
Additional section with A
and/or AAAA RRSets for the root name servers pointed at by the NS RRSet.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
