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

[Peter Koch <[e-mail]>]

Jinmei,

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

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.

> - 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"?

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.

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

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

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

the latter.

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

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.

> - Section 3.1

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

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.

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

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

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.

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

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.

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

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