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

[Jelte Jansen]

Simon Vallet wrote:
> On Wed, 16 May 2007 16:56:11 +0200
> Jelte Jansen <jelte at NLnetLabs.nl> wrote:
>> But what i want to reach is the point where one can see at what level
>> and what the underlying error was; like
>> 'validation failed at bogussig.test.jelte.nlnetlabs.nl; The DS record
>> could not be validated: Bogus Signature'.
> 
> Hmmm... if you want to propagate domain information along with the
> status code, then there is some more work to do. Maybe we could use
> some specific status struct here ?
> 

I have got two approaches to this problem, a 'simple' one, and a
not-so-simple, but in the end probably more flexible and clean one:

1) a linked list of errors, containing for example; dname, rr type,
error, and a link to the same structure

This approach would be the least work, and would let the current
function remain mostly as they are now.

However, this approach is also not very flexible, and an application
would not be able to do much more that print what went wrong (not that i
can think of much else to do at this moment, but hey).

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

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

Anyway, this is what i'm leaning towards, thoughts are welcome.

Jelte



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20070521/3416c622/attachment.bin>