Caching in libunbound

[Rick van Rein]

Hi Paul,

(Yeah, it's pretty neat, as it can connect the entire Internet through
Kerberos.  Of related interest is a TLS-KDH ciphersuite that is tens
of thousands times faster than X.509-based crypto, and it is of course
Post Quantum, as Kerberos has always had that property.)

>> 2.
>> The KDC and my daemon each use libunbound.  Does that mean they each
>> have their own cache, and if so, is there a way to combine their storage
>> and validation efforts?
>
>
> If your want to trust your system unbound, don't do validation yourself
> and check the AD bit? If you want to do validation in the app for
> security, then you cannot trust the unbound daemon's validation. So I
> am not quite sure what you are asking for.


The trust is mutual between KDC and my KXOVER daemon.  I would like to be
responsive to "you're doing it twice" claims, but I also don't want to
create a solution that relies on the OS.  You are right, such trust
relations between processes are notoriously difficult.  However, the hope
I had was that since Unbound == Unbound it might trust itself and allow
two streams of requests to come together.

> Everything on localhost could use the unbound daemon on 127.0.0.1 as
> forwarder, so it would use its cache. You will still have some duplicate
> cache, but at least no additional latency since it is all local after
> the unbound daemon put the data in its cache.

That would mean I'd have to inspect the AD bit and rely on it.  I
suppose that is one way of doing it, indeed.  I have to enforce DNSSEC
and reject anything that doesn't have it on several of the queries
though.

You've pretty much acknowledged that there are two not-entirely-perfect
ways of doing what I have in mind, and that this is a logical
consequence of the way systems are usually structured.  I was just
curious if Unbound might be different ;-)

Thanks,
 -Rick