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.