Re: [dnsext] caches, validating resolvers, CD and DO

[Paul Vixie <[e-mail]>]

> From: Mark Andrews <[e-mail]>
> Date: Wed, 30 Mar 2011 17:23:35 +1100
> ...
> When these do not validate or SERVFAIL is returned, the validating
> resolver should then re-issue the query with CD set and a EDNS option
> indicating which upstream servers have been tried.  This option is
> initially empty.  The cache will then behave as a proxy for this query
> (excluding the EDNS option) adding the responding server's address to
> the EDNS option.  If there are no more addresses to try, SERVFAIL (new
> rcode?) is returned along with the EDNS option from the query.

objection. this assumes that the reason for servfail is upstream (which
it may not be), assumes that the upstream server identities are
unambiguous from the client's point of view (which in the case of nat
may not be true), and assumes that the client knows better than the
server how to avoid failure.  since your proposal assumes new protocol
elements to be implemented in all servers and some clients, i think it
would be better to add something that solves the actual problem.  the
server in this case should consider using michael graff's hybrid blast
protocol, send the query to the first upstream, and if it fails then
resend it to all upstreams in parallel.  this would get the upstream
transaction timeout down into the downstream client's timeout window.

the wire change i would like is wholly different.  since clients should
not need to add caches when they add validation, i'd like the chain of
rrsig and dnskey to be sent from the recursive server to the stub,
everything it takes to validate the answer.  to do this, a new EDNS
option would allow the client to express its closest trust point.  so if
the client already knows (in a current-transaction cache that is not
shared with other applications or transactions on the client host) it
has a valid dnskey for google.com and it's asking for www.google.com
then the only RRSIGs or DS/DNSKEY's it needs are for www.google.com
and www.l.google.com.

> If the cache is using another cache the entire query/response is
> proxied.  The intent is for the validating client to talk through
> intermediate caches to the cache talk directly to the authoritative
> servers.  The EDNS option maintains a list of authoritative server
> addresses for the zone that have been tried.  This list is passed
> back and forth between the validating resolver and the cache talking
> to the authoritative server.

again, if we're going to change the servers by adding support for some
new wire element, let's just make the server do the right kind of failure
avoidance.  and if we're going to add a new wire element let's have it be
one that lets cacheless stub validation work.