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

[Jelte Jansen <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Note that this makes the assumption that that is actually the trust
point that has a validatable chain, and not a failing one while there is
a higher trust point that would lead to succesful validation (yes yes,
this may or may not be good or bad or local policy or whatever, cue
discussion for multiple chains where some fail).

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

i would also like to see something like this, btw.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2TG4AACgkQ4nZCKsdOncUpvACcCshacCAQx+GnU/+NXAnRUL/n
hbkAn34dNBZuvqHubIIhKlcS9WtASj21
=jnsf
-----END PGP SIGNATURE-----