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

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 06 Dec 2016 11:08:25 -0800

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? ...?)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 6 Dec 2016 20:32:34 -0600

Hi, Paul,

> This message follows up on the comments.

Deleted down to

>>    Resolver software SHOULD treat the response to the priming query as a

I'm somewhat curious about why this isn't a MUST, but ... ok.

> fewer, we don't know what it will do (fail to come up? retry incessantly?
> ...?)
>

I'm really curious about why this is not a MUST - can anything good happen
when you expect 13 NS RRs? Usually, we're saying "SHOULD NOT, unless you
can assess the risks of doing it". Is that possible, in this case?

Spencer

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 06 Dec 2016 18:39:36 -0800

[[ BTW, sorry for not changing the subject line on this thread. It 
really does relate to all the IESG comments, not jus Ben's. ]]

> I'm somewhat curious about why this isn't a MUST, but ... ok.

For example, an implementation might treat the responses special by 
altering the TTLs based on some understanding that the vendor has that 
only is relevant to priming queries. Why prevent that?

>> incessantly?

We could certainly say "SHOULD NOT expect exactly 13 NS RRs because 
historically some root servers have returned fewer".

--Paul Hoffman

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 6 Dec 2016 22:03:14 -0600

Hi, Paul,

On Tue, Dec 6, 2016 at 8:39 PM, Paul Hoffman <[email-masked]> wrote:

> [[ BTW, sorry for not changing the subject line on this thread. It really
> does relate to all the IESG comments, not jus Ben's. ]]
>
> altering the TTLs based on some understanding that the vendor has that only
> is relevant to priming queries. Why prevent that?

That wasn't my intention. Thanks for indulging my curiosity.

Sometimes, I'm a curious guy ;-)

> historically some root servers have returned fewer".

That is exactly the kind of thing that seems uber-helpful to mention!

Thanks for the background.

Spencer

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 08 Dec 2016 09:15:25 -0600

> 1035. It does not create a new requirement.

Works for me, thanks!

Ben.