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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 10 Nov 2009 00:47:49 +0900

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.

---

From: Peter Koch <[email-masked]>
Date: Mon, 9 Nov 2009 17:50:01 +0100

Jinmei,

> Basically, I think this document is useful and I support it to be

thanks for your review. This (and also Afred's helpful comments) will be
addressed in an updated version.  But let me respond one by one.

>   these cases are covered as an exception to "SHOULD NOT"?

Your observation is true, but that's why section also says that re-priming
at 75% of the lifetime is OK. We're not covering the "internal" root
servers completely, that is, we're not giving guidance how to configure
and run them, just need to discourage anybody to hard code the "13".
As a corollary we could suggest minimum TTLs for the root NS RRSet,
but that's probably a secondary issue.

>   I don't understand what "resending" means here.  Does this mean a

Imprecise wording, indeed. "retry" would have been the technical term.

>   different server when previous ones time out (or fail unexpectedly)?

the latter.

>   from a root server, which is authoritative and could be signed and

You could validate the NS RRSet, but that is of little value since the
"critical" information is in the address records, not in the names.
Actually, and that's why referrals aren't signed, as per the DNSSEC model,
the names or identities of the servers don't matter, since the zones
are the signing entities. So, a forged referral would (ideally) be
detected because the forged-in servers wouldn't be able to provide valid
signatures.  The same holds for the root, where the priming query does
nothing else but provide the "initial" referral into the cache.
The draft already explains why with the current model the addresses
could not be verified anyway and we left out the whole discussion about
re-homing the servers to the ARPA domain since validation wasn't wanted.

>   "no error" (or "No error") as spelled in RFC1035.

Actually, as per <http://www.iana.org/assignments/dns-parameters>, as
updated by RFC 5395, maps "0" to "NoError". Will change the case and add
the numeric value here and throughout the document, where appropriate.

>   additional section comes from the root-servers.net zone).

There are two issues here:
1) How do the addresses of the root name servers get there in the first
   place?
   Traditionally, the addresses for the root name servers have been
   provided from within the root zone.  However, there is no reason
   for them to be present in the root zone itself, see section 6.1 of
   the (expired) draft-koch-dns-glue-clarifications-03.txt.
2) There is the open issue of completing the priming response which may
   involve asking for the A/AAAA RRSets directly and since the resolver
   is in the not-yet-completed priming state, all it knows is the root
   servers themselves.

We'd need to check the issue you mentioned, but that would become relevant
only if the root servers' addresses would be deleted from the root zone.

>   purged separately for implementation specific reasons (e.g. memory

The background is that it should be avoided that the A/AAAA RRSets expire
before the NS RRset entirely, which would leave the resolver in an undesirable
state.  More on this during the WG session.

>   moved to somewhere more appropriate.

Careful address management should prevent this, but it might happen that
an old address of a retired root name server is reasssigned.  Someone
could set up a "fake" root server in this space with obvious consequences.
Precedent to be located by your favorite search engine ...

Thanks,
  Peter

---

From: Chris Thompson <[email-masked]>
Date: 09 Nov 2009 21:27:09 +0000

I think I would like to ask "what's special about priming anyway?".

As part of explaining how the DNS works, I tend to include something
along the following lines:

 Q. Why does the root "hint" zone not look like a real zone?
 A. Because it isn't a zone at all, it's a referral.
 Q. A referral? from where?
 A. It's the referral from Trantor[*] when asked about anything
    in this poxy little planet-bound Internet. See: the NS records
    are the Authority section of the referral, and the address
    records are the glue in the Additional section. (Because all
    the nameservers are on the same planet! Shocking...) We keep
    a local copy because the RTT to Trantor is inconveniently long,
    and the referral always looks the same anyway, apart from the
    Question section.

[*] Feel free to substitute the Galactic Centre of your choice.

The logic is: if you don't have any record of nameservers in your
cache superior to the name being queried for (because they have
been timed out, squeezed out for lack of memory, or you have just
started up), then invent the appropriate referral based on the
root "hints" and take it from there.

It seems to me that this is more or less how RFC1034 is saying
the SBELT structure should be used, except that we no longer think
it appropriate to have customised referrals-from-Trantor including
"two of the servers for the host's domain".

Now I am aware that this isn't exactly how nameservers are actually
programmed, and that they perform explicit priming rather than the
"lazy priming" implied above. But would it actually matter if they
did it that way? And maybe the right attitude towards explicit
priming ought to be "don't do it in a way that makes more queries
to the root servers than lazy priming would".

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.