Re: dnssec: resolver - application communication

[Jelte Jansen <jelte@nlnetlabs.nl>]

>     >> o We need something like the CD-bit, that will return an entire
>     >> chain of trust, which consists of the RR's you specified above:
>     >> ALL keys, ALL DSs, ALL RRSIGs, and the RRset,
> 
>     David> Why?
> 
>   Because  a) I want to audit it.
> 	   b) admins need to see it anyway.
> 

The problem with returning a complete chain of trust is that it could be 
way too big, even for EDNS0.

Correct me if I'm wrong here, but I believe the proposal is something 
like this:

- Let applications that don't care (like all apps now) do old-school 
insecure dns stub resolving, but:

- Let caching forwarders do fully aware secure resolving from the root 
down, and only pass verified (unsecure) data.

- Let applications that do care do validation from the data they receive 
from the caching forwarder, which can only resolve to validated or not 
validated (since the security state of a single piece of data is 
unknown), whether you call it SERVFAIL of DNSSECERR, or whatever, but 
SERVFAIL, although overloaded, does exist at the moment and is therefore 
'supported' by those applications that do not care.

- Let there be a tool (dig++, or just dig +trace) do validation from the 
top down, so that interested parties can actually see exactly what goes 
wrong.

The thought here is that we would spare the higher servers from 
individual harassment by every single machine on the planet, and still 
provide the most important piece of information (a result or a message 
that it has failed), whilst allowing 'debugging' (dig++), and preventing 
major spoofing (by having the forwarders do 'real' validation) and not 
have every single application implement their own validation routines 
(which the original proposal came down to), or demanding yet another 
extension to the protocol (which would take, er, pretty long probably).

Jelte