Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

["Paul Hoffman" <[e-mail]>]

On 29 Jan 2016, at 10:38, 神明達哉 wrote:

> At Fri, 22 Jan 2016 09:28:21 -0800,
> "Paul Hoffman" <[e-mail]> 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