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. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
