[ldns-users] [PATCH 0/3] Add full validating capabilities to ldns
Simon Vallet
svallet at genoscope.cns.fr
Thu May 17 09:29:41 UTC 2007
On Wed, 16 May 2007 16:56:11 +0200
Jelte Jansen <jelte at NLnetLabs.nl> wrote:
> I have looked at the patches, and they look very useful. Thanks again.
No problem -- thanks for ldns :-)
> However, I don't think i want to leave the functions as they are now. I
> think it needs more error feedback (as they are, it almost always
> returns 'general error' on any dnssec error. While this might not be a
> problem for apps that only want to know 'ok' or 'not ok', it will be for
> more specified applications that want to know what went wrong.
Yes -- I agree with that. This is what I had in mind first: in fact,
you can still see the 'status' variable everywhere. But I got lazy
trying to figure out a way to pass trusted_keys to
fetch_valid_domain_keys: since it is called recursively, doing this
cleanly without leaking could become very inelegant.
I agree on the goal, though: it's always better to have a specific
error status -- I'll take a look at it also.
> 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 ?
> If you have any objections to this, i can also make extra functions that
> to this, and leave your functions as they are (at least on the API level).
I'm totally OK with this: as I said, returning a specific status is
always better. Besides, the only API I'm depending on is the one for
ldns_verify_trusted, and I think this one is acceptable.
Simon
More information about the ldns-users
mailing list