[ldns-users] [PATCH 0/3] Add full validating capabilities to ldns

[Simon Vallet]

On Mon, 21 May 2007 12:21:52 +0200
Jelte Jansen <jelte at NLnetLabs.nl> wrote:

> Therefore, i suggest another approach
> 3) separate the building of the dnssec trust chain and the validation of
> that chain:
> - first build a list-like structure, containing:
>     - node rrset
>     - parent type (DS or DNSKEY, if DS then there is no rrsig)
>     - parent (pointer to another instance of this structure)
>     - rrsig
> (and possibly some entries for optimization, like 'is_verified', but i
> want the base structures and algorithm right first)
> 
> - then a seperate function can validate that chain
> 
> at this point we're not much further than with the current approach, but
> now we can use the default functions that calls both of these if you
> only want to know 'verified' or 'not verified' (and optionally, return
> the error the application os most likely to want to know). Debuggers,
> and other programs that are more interested in failure scenario's, can
> show the complete dnssec chain together with all of it's data and
> intermediate results.
> 
> This approach will definitely not be more efficient (you need to copy
> and store data, because the origin packets will be lost), Altough it
> might be more efficient in the number of actual queries it sends. It
> will definitely be more flexible (and allows, i think, for cleaner code).

Well, you got my vote on this one too, even if the implementation is
likely to be more complex (see below).

> One question is whether it is actually possible to reliably build the
> chain without doing any validation in between (this could maybe be
> optimized later by optionally calling the verification at each level
> anyway).

I think it's possible, but unless all we have is a 
DS -> DNSKEY [-> DS ... ] chain, you'll probably end up with multiple
 possibilities to check at the end. 

Consider the following:
(. DNSKEY) -> (com. DS) -> (com. DNSKEY) -> (example.com. DS) -> (example.com. DNSKEY) -> (www.example.com A)

in this case, there will only be 1 RRSIG per RR, and we can walk up to 
the root without problems

if we introduce a trusted (or non-trusted) KSK somewhere, say a second 
example.com DNSKEY, we now have two RRSIG on the example.com. apex RRset.
This gives us several possible valid chains starting from example.com,
which we'll all have to verify (at least until we find a trusted one).
If you have the same situation at com., then you multiply the chains -- 
in this scenario, a tree-like structure with several parents might 
be more appropriate.

As you said, efficiency would probably suffer, since you won't be able 
to know before validation which branches are worth building, and 
which are not.

It seems worth to implement, though

Simon