At Thu, 14 Jan 2016 17:29:04 -0800,
"Paul Hoffman" <paul.hoff...@vpnc.org> 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.
I'm afraid we are talking about the different things (perhaps partly
my bad, I mixed two different issues). What I tried to say is this:
The current draft test is:
[...] 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.
After fixing the RRSet-based TTL on which we seem to agree, it would
be:
[...] This would be when the resolver starts with an empty cache,
and when the NS RRSet for the root servers has expired.
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)?
> > - 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).
> > - 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.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
