[dnsext] Trust Anchors

[Bob Halley <Bob.Halley@nominum.com>]

I've been reading drafts in preparation for Hiroshima, and I noticed  
that in draft-ietf-dnsext-dnssec-bis-updates-09.txt, section 4.9 says

4.9.  Nested Trust Anchors

    A DNSSEC validator may be configured such that, for a given  
response,
    more than one trust anchor could be used to validate the chain of
    trust to the response zone.  For example, imagine a validator
    configured with trust anchors for "example." and "zone.example."
    When the validator is asked to validate a response to
    "www.sub.zone.example.", either trust anchor could apply.

    When presented with this situation, DNSSEC validators SHOULD try all
    applicable trust anchors until one succeeds.

    There are some scenarios where different behaviors, such as choosing
    the trust anchor closest to the QNAME of the response, may be
    desired.  A DNSSEC validator MAY enable such behaviors as
    configurable overrides.

I reread the Trusted Anchors thread in the namedroppers archive, and I  
didn't see such a strong consensus for the ANY approach.  At best I  
saw support for ANY + CLOSEST (and perhaps other schemes).  Some  
people had a strong preference for only CLOSEST.  I didn't participate  
in that thread, but I too favor the CLOSEST approach.  Was there  
further discussion on this that I missed?  If not, I think the  
language in the draft is too strong, because it favors ANY and says  
that CLOSEST, while permissible, must be a "configurable override".

The purpose of the ANY approach appears to be system robustness.  The  
(certainly reasonable) concern is that statically configured trust  
anchors will go stale, and resolutions will fail.  While trying *more*  
statically configured data (i.e. other closer-to-the-root anchors) may  
help in some cases, this solution is not really getting at the real  
issue, which is static configuration.  We already have a standards  
track mechanism for keeping trust anchors fresh, namely RFC 5011.

I don't see any point to ANY.  It doesn't solve the staleness problem,  
it just adds hacks, which although they may be useful, may also be  
surprising and detrimental.  It also goes against the existing trust  
anchor practice of at least two validators (BIND and Nominum).

I propose that the draft mandate the use of CLOSEST and suggest the  
use of RFC 5011 to avoid staleness.  If there's no consensus for that,  
I'd be satisfied with just removing section 4.9.

/Bob