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

[D. Hugh Redelmeier]

| From: Paul Wouters <paul at xelerance.com>

| The question is, where should the DNSSEC code be and where should the cache be?
| Assuming something like the above is added, we have the following choices:
| 
| 1) dnssec resolver using a more generic query to localhost from openswan
| 
| 2) using stubunbound or similar, and move the resolver/cache into openswan
| 
| 3) using ldns with callbacks (no cache?)
| 

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.

There ought to be a way to delegate the DNSSec aspect.  I hope that
Pluto doesn't have to do it.  But if nothing else does what Pluto
needs, then it will have to do it.  Remember that one requirement is
useful diagnostics.

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.

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.

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