Hi,
I am using libunbound for DANE-based realm-crossover for Kerberos. This
requires the KDC to map hosts to realms via DNSSEC, but otherwise it is
just a wrapper around the KDC,
https://github.com/arpa2/kxover/tree/tls-based-attempt
1.
Does libunbound cache like an Unbound server would, for the duration of
the TTL if the program does not exit before?
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? I could speedup lookups with an Unbound daemon
behind libunbound, but that'd give three caches and three independent
validations!
Allow me to add that libunbound is very pleasant to work with! The only
thing I miss in the API is the lack of an invalid value for the
async_id, so apart from storing that value there also is a need to flag
whether such a field is occupied (and possibly calling for locking to
keep the two consistent).
Thanks!
-Rick
I am using libunbound for DANE-based realm-crossover for Kerberos. This
requires the KDC to map hosts to realms via DNSSEC, but otherwise it is
just a wrapper around the KDC,
https://github.com/arpa2/kxover/tree/tls-based-attempt
neat!
1.
Does libunbound cache like an Unbound server would, for the duration of
the TTL if the program does not exit before?
Yes.
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.
I could speedup lookups with an Unbound daemon
behind libunbound, but that'd give three caches and three independent
validations!
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.
Paul
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
Ah...
I was thinking that Unbound might merge processes...
However, the hope
I had was that since Unbound == Unbound it might trust itself and allow
two streams of requests to come together.
...because it fork()ed a process in the background, which I assumed
might be a shared Unbound daemon.
Apparently this is just to service query/responses. Unexpected, as I
had setup an event loop and was tidily calling ub_process() and
receiving its callbacks.
To be honest, I don't really understand why Unbound doesn't have a modus
operandi that supports event loops without thread or process!
-Rick
Hi Rick,
> Ah...
>
> I was thinking that Unbound might merge processes...
>
>> However, the hope
>> I had was that since Unbound == Unbound it might trust itself and allow
>> two streams of requests to come together.
>
> ...because it fork()ed a process in the background, which I assumed
> might be a shared Unbound daemon.
>
> Apparently this is just to service query/responses. Unexpected, as I
> had setup an event loop and was tidily calling ub_process() and
> receiving its callbacks.
>
> To be honest, I don't really understand why Unbound doesn't have a modus
> operandi that supports event loops without thread or process!
It does, with the unbound_event api. See libunbound/unbound-event.h
I believe this is also what getdns uses.
unwind(8) uses it and it works fine. https://man.openbsd.org/unwind.8
Have a look at
https://github.com/openbsd/src/blob/master/sbin/unwind/resolver.c for
inspiration on how to use it. check_resolver() on line 979 might be a
good starting point.
Hi,
To be honest, I don't really understand why Unbound doesn't have a modus
operandi that supports event loops without thread or process!
It does, with the unbound_event api. See libunbound/unbound-event.h
Ah! That makes sense. But dare I suggest an update of the pages that I held to be authoritative? There is no mention of this mode on
https://nlnetlabs.nl/documentation/unbound/libunbound/
(But I do agree that "asynchronous lookup" does not carry all the patterns that come with "event looping".)
Have a look at
https://github.com/openbsd/src/blob/master/sbin/unwind/resolver.c for
inspiration on how to use it. check_resolver() on line 979 might be a
good starting point.
Lovely, a complete example ripped from real life 
Thanks guys,
-Rick