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

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 03 Feb 2016 07:49:22 -0800

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

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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 3 Feb 2016 10:08:16 -0800

At Wed, 03 Feb 2016 07:49:22 -0800,

> be essential in the future.

I'm not sure if you're disagreeing with me on some point or are just
making some general statement, and in the case of former whether it's
about my concern of "what if AAAA/A is missing" or about the specific
text I showed...as a general matter I tend to agree that we should
distinguish issues specific to the current practice and from general
matters, but I'm not sure how that's related to the above comment of
mine.

So, in the end, are you saying your revised text should be good
enough, or are you suggesting to revise my proposed text to clarify
what's based on the current practice, or something else?

--
JINMEI, Tatuya