On 29 Jan 2016, at 10:38, 神明達哉 wrote:
At Fri, 22 Jan 2016 09:28:21 -0800,
"Paul Hoffman" <paul.hoff...@vpnc.org> wrote:
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.
(sorry for the delayed response) in clarity it now looks good, but I'm
not sure this is enough as a description of priming query behavior. I
would wonder what if the AAAA and/or A RRSets are missing - in that
case the result of the priming query is almost useless or could even
be harmful as you'd now only cache the new ./NS RRSet (which could be
totally different from that of the "hint").
If I were to write this text, I'd say something like this:
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). The Additional section is conventionally
expected to include A and/or AAAA RRSets for the root name servers
pointed at by the NS RRSet. Although these RRSets are not
guaranteed to be included by the protocol standards, they are
essential for the priming response to be useful in practice, and
currently deployed root servers actually meet the expectation.
We should be a bit cautious here. They are *currently* essential, but if
the root server operators choose a different naming scheme, they may not
be essential in the future.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
