[DNSOP] comments on draft-ietf-dnsop-resolver-priming-02

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

Basically, I think this document is useful and I support it to be
(eventually) published.

Here are my comments on the current version:

- Section 2.2

   A resolver SHOULD NOT originate a priming query more often than once
   per day (or whenever it starts).

  Depending on the TTL of the NS, this requirement cannot be met
  as long as we honor the TTL.  Even if this is not a problem in
  practice for the Internet root servers today, we may (though
  unlikely) see much a shorter TTL in the future.  Note also that this
  document seems to cover "internal" root servers (Section 3.1), which
  perhaps have a shorter TTL more realistically.  Is that intent that
  these cases are covered as an exception to "SHOULD NOT"?

- Section 2.3

   For resending the priming query to a
   different server the random selection SHOULD also be used.

  I don't understand what "resending" means here.  Does this mean a
  subsequent priming query after the cached ./NS RRset (or its glues)
  expires?  Or does that mean a priming query that is resent to a
  different server when previous ones time out (or fail unexpectedly)?

- Section 2.4

   Discussion: Delegations in referral responses are not signed, so
   consequently the priming response is not validated, either.

  I don't understand this.  The priming response is a response to ./NS
  from a root server, which is authoritative and could be signed and
  validated?

- Section 3.1

   The priming response can be expected to have an RCODE of NOERROR and
   the AA bit set.

  Some people don't like terms like NOERROR because it's an
  implementation specific keyword.  If the IESG is consistent (which I
  doubt though), they will object to the use of it in an RFC.  I
  personally don't have an opinion on the usage, but it's safer to use
  "no error" (or "No error") as spelled in RFC1035.

- Section 4.

   addresses of all root name servers.  This can easily achieved by
   making all root name servers authoritative for the zone containing
   the servers' names.

  nit: s/can easily achieved/can easily be achieved/

  More substantially, I'm not sure if this is true.  If I remember
  correctly, (at least some versions of) NSD doesn't populate the
  additional section from a different zone than that for the answer
  (in this case, the answer section comes from the root zone and the
  additional section comes from the root-servers.net zone).

- Section 4.

   [[Do the TTLs for the root NS RRSet and address RRSets in the root
   and the ROOT-SERVERS.NET. zones need to be aligned?  In real life
   responses, the address RRSet's TTL values vary by implementation.]]

  I don't think it matters much because the cached RRsets can be
  purged separately for implementation specific reasons (e.g. memory
  shortage).

- Section 5.

   There is also a chance that the
   random target selection chooses the address of a retired root name
   server.

  I didn't understand security implication of this point.  Maybe more
  explanation should be provided or this sentence should be removed or
  moved to somewhere more appropriate.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.