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
