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

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 13 Jan 2016 13:53:06 -0800

Greetings. The WG chairs have added me as a co-author for 
draft-ietf-dnsop-resolver-priming to help drive the work to completion. 
As you just saw, there is a new version of the draft. Looking over the 
earlier discussions over the years, we have greatly simplified the 
document:

- Advice on how the root server operators should reply to priming 
queries is gone.

- Requirements on how the priming query should look have been loosened 
to reflect that this is a normal DNS query

We'd really like folks to review it, particularly because this is such a 
large change from earlier versions. The document is still definitely 
open for discussion, and if there is consensus to reverse some of the 
changes, that's of course fine. Regardless, let's get this published in 
a form where everyone (?) is happy.

--Paul Hoffman

---

From: 神明達哉 <[email-masked]>
Date: Thu, 14 Jan 2016 11:32:24 -0800

At Wed, 13 Jan 2016 13:53:06 -0800,

> a form where everyone (?) is happy.

Here are my comments on the 06 version:

- Section 3.1

   [...]  This would be when the resolver starts with an empty cache,
   and when one or more of the NS records for the root servers has
   expired.

  This seems to talk about a recursive server behavior that allows a
  subset of an RRset to expire.  Is that the intent?  Is there any
  reason why we can't simply say "...and when the NS RRSet for the
  root zone has expired."? (btw I think 'root zone' is better
  than 'root servers' here).

- Section 3.1: some modern recursive servers "prefetch" un-expired
  RRsets.  We might also mention that case here.

- Section 3.3

   [...]  At the time this
   document is being published, there is little use to performing DNSSEC
   validation on the priming query because the "root-servers.net" zone
   is not signed, and so a man-in-the-middle attack on the priming query
   can result in malicious data in the responses.

  I think this text needs more explanation.  Since the priming query
  is "./NS", it's not immediately obvious why the fact that
  "root-servers.net" is unsigned matters.  This text seems to be based
  on some implicit assumptions/facts such as:
  - all root servers are authoritative for the root-servers.net zone
  - we'll eventually need AAAA and A RRsets of the NS names
  - even if ./NS is signed, it's not very useful in practice unless
    these AAAA and A are also signed
  and, reading between the lines I think I can agree with the seeming
  intent, but IMO it should be explained more clearly and explicitly.

- Section 4.1

   answer section) and an Additional section with A and/or AAAA RRSets
   for the root name servers pointed at by the NS RRSet.

  Similar to the previous point, it seems to be based on some implicit
  assumptions including:
  - all root servers are authoritative for the root-servers.net zone
  - all these servers populate the additional section from a different
    zone they are authoritative for than that for the query name ("."
    in this case)
  - none of the root server implementations use the
    "minimal-responses" (or equivalent) option

  I think these should be clearly stated.

- Section 4.2

   For an EDNS response, a resolver SHOULD consider the address
   information found in the Additional section complete for any
   particular server that appears at all.

  This one also seems to assume some particular behavior of the root
  server implementations.  At least protocol-wise, we cannot
  necessarily assume this completeness, right?  Then I'd also suggest
  clarifying the assumption.

Editorial nits:

- Section 3.2: s/other other/other/

   [...]  Two other other
   common methods include picking the first from the list, and

- Section 4.2: s/to to/to/

   [...]  Instead, the recursive resolver needs to to
   issue direct queries for A and AAAA RRSets for the remaining names.

--
JINMEI, Tatuya

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 14 Jan 2016 17:29:04 -0800

Thanks for the review!

On 14 Jan 2016, at 11:32, 神明達哉 wrote:

> root zone has expired."?

Good catch. The RRset will expire at the same time.

> (btw I think 'root zone' is better

This is not the expiration on the whole root zone, only on the NS 
records. The expiration of the root zone itself comes from the SOA, 
which has a different value than the TTLs on the NS RRset. That is, in 
the current root, the expiration in the SOA is 604800 but the TTLs on 
the NS records are 518400.

> RRsets.  We might also mention that case here.

Yes.

> intent, but IMO it should be explained more clearly and explicitly.

The first bullet point is not necessary for your argument. Would the 
following be better than the quoted sentence?

At the time this document is being published, there is little use to 
performing
DNSSEC validation on the priming query. This is because being able to 
validate
the NS records is not sufficient for having authenticated addresses for 
the root
servers: having validated A and AAAA RRsets for each root server is also 
needed.
Without those validated A and AAA RRsets, a man-in-the-middle attack on 
the
priming query can result in malicious data in the responses

> I think these should be clearly stated.

Those implicit assumptions are not needed for the current text. RFCs 
1034 and 1035 and 2181 do not restrict what can be put in the Additional 
section to only being things for which the server is authoritative.

> clarifying the assumption.

This seems like a reasonable question. What do others think?

>  issue direct queries for A and AAAA RRSets for the remaining names.

Fixed. Thanks again!

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Fri, 15 Jan 2016 15:54:25 +0000

Attached please find a PDF with annotations...

I'm trying to find a more efficient way to do reviews and figured I'd try
this approach (open draft in Goodreader on an iPad, make edits directly
there, mail annotated copy) instead of my standard "print it out, scribble
notes on paper, loose papers, find papers, decide that trying to decode my
chicken scratches is not worth the bother, become disheartened, discard
paper" approach.

This *should* be PDF compliant and open in most PDF viewers, but some may
decided to ignore the annotations....

W

On Wed, Jan 13, 2016 at 5:33 PM Paul Hoffman <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 15 Jan 2016 10:03:02 -0800

At Thu, 14 Jan 2016 17:29:04 -0800,

> the NS records are 518400.

I'm afraid we are talking about the different things (perhaps partly
my bad, I mixed two different issues).  What I tried to say is this:

The current draft test is:

After fixing the RRSet-based TTL on which we seem to agree, it would
be:

   [...]  This would be when the resolver starts with an empty cache,
   and when the NS RRSet for the root servers has expired.

My incremental different suggestion was to revise it further:

   [...]  This would be when the resolver starts with an empty cache,
   and when the NS RRSet for the root zone has expired.

Is it clear enough now, or did you mean this last text has an issue
(like as if it talked about zone expiration)?

> >  can result in malicious data in the responses.
[...]
> priming query can result in malicious data in the responses

Looks good to me (I'd say "A and AAAA RRsets for each root server
*name*" though).

> section to only being things for which the server is authoritative.

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.

--
JINMEI, Tatuya

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 22 Jan 2016 09:28:21 -0800

> (like as if it talked about zone expiration)?

This is fine, and it will be in the next version.

> Looks good to me (I'd say "A and AAAA RRsets for each root server

Please see the message I sent yesterday with Warren's challenge about 
this section. It would be good for the WG to come to consensus on the DO 
bit before we do more wordsmithing.

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

--Paul Hoffman

---

From: 神明達哉 <[email-masked]>
Date: Fri, 29 Jan 2016 10:38:09 -0800

At Fri, 22 Jan 2016 09:28:21 -0800,

> 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