[Openswan dev] [ldns-users] function call backs in ldns_resolver_send*?

[Paul Wouters]

On Fri, 17 Dec 2010, D. Hugh Redelmeier wrote:

> It is sad that Pluto has to know as much as it does about DNS.  In
> particular, it parses DNS records on its own.  There didn't seem to be
> a better way.

These days there is, for instance with ldns.

> Caching ought to be done outside of Pluto.  But if nothing else does
> it reasonably (quickly, reliably, and securely) then Pluto will have
> to do it.  Trust and performance would seem to suggest that a local
> agent be used.

Yes, I think requiring a local resolver would be best.

> Pluto is event driven.  It would be nice if whatever provided Pluto
> with the data fit into that model.  As it is, Pluto has had to work
> around the blocking nature of lwdns by creating worker processes to
> perform the DNS tasks.  Unfortunate.

Perhaps evldns would be nest then? Its a combination of libevent with ldns

http://code.google.com/p/evldns/

> | Currently, openswan accepts host keys from DNS even if no DNSSEC is present. This
> | will be changed to require DNSSEC, meaning we need to have some confidence that
> | we obtained this data securely, including the currently "undetectable last mile".
>
> Hmm.  That is a purist approach.  Maybe maybe the level of purity
> required ought to be configurable per conn.  I don't know whether
> reverse domains are DNSSec'ed (a) never, (b) always, (c) at the
> whim of upstream, (d) at the choice of the IP holder.  My guess is
> that the answer isn't always (a) or (d).

I think we need to wait a little longer to get DNSSEC deployment, but
then we should slowly move towards a model where DNS is only trusted
with DNSSEC. Unless we can somehow distinguish the "anonymous ipsec"
from a "priviledged ipsec".

Perhaps I should rephrase this as, "we only support opportunstic encryption
when using dnssec". Note that we very well may allow keys from unsecured DNS
space, but we must ensure to use DNSSEC so that we detect DNS attacks for those
who did deploy DNSSEC. So if we have a signed zone for openswan.org, we should
not accept unvalidated keys for www.openswan.org, while for www.unsecure.org we
might.

Paul