Maintained by: NLnet Labs

[Unbound-users] Unbound as an "authoritative" cache?

Jan-Piet Mens
Wed Feb 6 11:42:08 CET 2008

I would like to discuss the possibility of increasing Unbound's (already
very impressive) list of features by something I consider to be of great
use to many people who currently implement hidden (or stealth) primaries
with a master (often BIND) behind which are slower name servers which
have their DNS data in SQL databases or LDAP directory servers. Sites
with a heavy load of DNS requests employ stealth servers hoping to offer
a higher performance with their master "front-end" servers.

   Internet -> BIND -> Stealth server -> database

If Unbound, as a caching server, could be made to recognize a number of
zones for which I have back-end authoritative servers, and if it could
be convinced (for those zones, and for those only) to not perform
recursion, but to query the back-end authoritative servers, Unbound
could be used as a high-speed cache for slower back-end authoritative
DNS servers. For answers it retrieves from the back-end auth servers, it
would also have to set the `aa' bit on replies.

    Internet -> Unbound -> Slow-authoritative-server -> database

Ideally, and to avoid having to restart (sighup) Unbound whenever the
list of my authoritative zones change, Unbound would do a lookup when a
query arrives for a zone not yet in its cache to determine whether or
not it is "authoritative" for the zone.

I could imagine a configuration setting such as

  auth-zones: <soname> <funcname> <timeout>
With <soname> pointing to a shared library provided by the
administrator. This shared library has three routines prefixed by

1. <funcname>_init() is called by Unbound when it launches; this routine
   initializes its environment.

2. <funcname_query() is called by Unbound when it gets a query for and is not (yet or any longer) in its cache.
   The query() function determines what name servers are authoritative
   for the zone and returns an Address (or list of Addresses) as struct
   in_addr (or in ASCII). If the query() function returns NULL, it is
   not authoritative for the zone.

        struct return_type *my_query(const char *zonename);
3. <funcname>_destroy() is called when Unbound exits (or gets a sighup)

4. <timeout> is given in number of seconds that Unbound is willing to
   wait for an answer from <funcname>_query().

The reason for determining dynamically whether Unbound is
"authoritative" for a given zone is so that administrators can add or
remove DNS zones to their back-end databases (SQL/LDAP/whatever) and
provide a routine to query that data set.

I hope I've made myself clear?