[Unbound-users] Any thoughts on long running Python process and DNSSEC validation

[Leen Besselink]

Hi,

As I was looking into using the PyUnbound library I started to wonder
about a few things.

When I did an Unbound installation, I set it up to use
auto-trust-anchor-file to make sure any changes at the root will be
handled properly. Other people might choose to use a cronjob with
unbound-anchor.

What if you have a long running process which uses the Unbound (Python)
library ? Especially if it needs DNSSEC-validation and wants to know if
something is validated as 'secure'.

This what I'm pretty sure about:
- each context has a seperate cache
- a context can be reused
- each context has a seperate ub_fb() and process() (atleast in the
Python library for handling callbacks with resolve_async (); haven't
checked the C-library)
- the result should be freed after use (obviously)
- forwarding queries to a locally running Unbound helps reduce the
overhead of creating a new context (actually cache) and reduces the
cache-size needed by the Unbound-library

I guess you have a few options:
A let the user setup a key-file and create one context and use it for
the whole duration of the process and hope for the best -> sounds like a
bad idea

B create a new context for every time the application needs to resolve a
bunch of things and use an Unbound running locally as a cache (possibly
pointing the application to the auto-trust-anchor-file of Unbound).
There is some overhead for handling lots of requests to localhost.

C create a new context every few hours and thus reread the anchor file
-> maybe it is updated by an unbound-anchor cronjob. In Debian atleast
unbound-anchor is part of the Unbound package, not the Unbound-library
package. So people will probably need to install Unbound anyway and then
prevent it from being started.

D create a new context every few hours and thus reread the anchor file,
but try to use ub_ctx_set_option to setup an auto-trust-anchor-file.
Have no idea if that would work; probably needs testing too. Maybe need
to make sure the process does not have 2 contexts at the same time so
the file is not corrupted ?

E Combine B and D. Create a context every time the application needs to
resolve a bunch of things, every context rereads the anchor file
normally and uses a locally running Unbound as cache. Every few hours
create a seperate context which again uses the auto-trust-anchor-option
by calling ub_ctx_set_option so the anchor file is rewritten when it
needs to be.

F I didn't see this as an option in the Unbound API (probably an other
library could do that), but in theory atleast it is possible to trusts
the AD-bits of a locally running Unbound. -> it isn't the best idea I
ever had though

Any other options ?

Any thoughts from others ? Any ideas ?

Thanks for reading my questions.

Have a nice day,
    Leen.