Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)

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

Thanks for your comments and for having no objections to the document. 
This message follows up on the comments.

--Paul Hoffman

On 29 Nov 2016, at 15:31, Ben Campbell wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In section 3.1, is there a reason the requirement in paragraph 2 does 
> not
> get a 2119 keywords, when the requirement in the first paragraph does?
> They seem similar in impact.

The paragraph is:
    If a priming query does not get a response, the recursive resolver
    needs to retry the query with a different target address from the
    configuration.
The "needs to" is there because it describes the steps given in RFC 
1035. It does not create a new requirement.



On 30 Nov 2016, at 6:06, Stephen Farrell wrote:

> - intro: References for directions that fail "disastrously"
> would be good, if only to decrease the chances that other
> implementers choose known-bad approaches.

Documenting worst practices is usually not part of a BCP. :-) We will 
modify the sentence to give a common example of a bad practice.

> - section 5, 2nd para: such an attacker can also see what
> queries are being emitted by the resolver, and, in the
> absence of qname minimisation, that can be quite privacy
> sensitive. I think it'd be well worth noting that with a
> reference to RFC7816 as a possible mitigation.

This paragraph is about the priming query, not about future queries. You 
cannot do QNAME minimization on the name of the root (a null string), 
nor would you want to.


On 30 Nov 2016, at 9:24, Terry Manderson wrote:

> I also support Stephen's request to identify the scenarios in which 
> "Some
> implementers have chosen other directions, some of which work well and
> others of which fail (sometimes disastrously) under different
> conditions." An appendix would be fine IMHO.

See above.

> Given you raise some (awareness) issues in the security consideration
> section, if an administrator implements RFC7706 would that alter any 
> of
> those concerns? (admittedly, potentially buying others that are well
> documented in 7706)

RFC 7706 did not deal with priming queries, and in retrospect probably 
should have. I think adding security considerations to this document 
about RFC 7706 might be a bad idea, but maybe a rev to RFC 7706 would be 
good.


On 30 Nov 2016, at 22:48, Spencer Dawkins wrote:

> I find myself curious about both SHOULDs in
>
>    Resolver software SHOULD treat the response to the priming query as 
> a
>    normal DNS response, just as it would use any other data fed to its
>    cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs.
>
> Do you think these SHOULDs (especially the first one) are required for
> interoperation?

Yes.

> I'm wondering (1) why they aren't MUSTs, and (2) why RFC
> 2119 language is actually needed at all. If they are RFC 2119 SHOULDs,
> what happens if the resolver software violates them?

We cannot tell. For the first one, if a resolver treats the response to 
the priming query in a special way, we don't know what "special" means. 
For the second one, if a resolver expects exactly 13 NS RRs and gets 
fewer, we don't know what it will do (fail to come up? retry 
incessantly? ...?)