[ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?)

[Miek Gieben]

[ Quoting Paul Wouters in "Re: DNSSEC (was Re: [ldns-users] fu"... ]
> >So any app. just uses the DNS as it always has done and displays that
> >information (a dns packet, a webpage, whatever) to the user.  When
> >security is needed, extra lookups are performed and the crypto is
> >checked. And when this dane-protocol works you can check that too.
> 
> I assume you do mean that spoofed answers give a servfail and you go investigate?

No, I mean: do an insecure lookup

> >o is_this_secure(DNSKEY record), gives back yes/no, checks the chain
> >o is_this_secure_dane(SSL cert), gives back yes/no, uses the dane protocol
> 
> In the case of firefox, I think what is going to happen is that DANE based cert/keys
> are going to be treated as DV certificates, and their validation forks based on the
> equivalent of using both is_this_secure() and is_this_secure_dane(). Additionally, if
> any cert info is filled in (eg CN, O, OU) then since they might present it to the user,
> they also want to validate that, so they need to walk the CA path as well. So for
> DANE based certs, it is best to leave all of that empty.
> 
> Hoever, my question was more, where does the validating code and cache live? Should
> openswan keep caches of the DNSKEYs in their lookup mechanism? Should it do validation?

Just use the local resolver, but don't trust it. The DNSSEC
validation should happen in openswan.

> Keeping the validating resolver within openswan protects against bad resolvers on the
> host, at the expense of sharing the cache, which if any other application does similar
> resolves, ends up with duplicated caches of infrastructure lookups.

... and how bad would that be?

> In short, should openswan link a secure resolver library and cache, or trust the AD bit
> on localhost? (or other last mile solution IETF comes up with)

use the local resolver
dont trust the local resolver
do the validation yourself


--
 Miek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20101215/c1078128/attachment.bin>