Caching in libunbound
Rick van Rein
rick at openfortress.nl
Thu Mar 21 10:34:48 UTC 2019
(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.)
>> 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
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 ;-)
More information about the Unbound-users