Unbound as an "authoritative" cache?

Unbound
1

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
<funcname>:

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
   example.org and example.org 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?

Regards,
        -JP

2

For security purposes it is highly recommended that caching and
authoritative servers be separate servers. Combining the two seems to be in
conflict with the idea of small fast secure servers.

Oh, absolutely.

                                                     Isn't this proposal
just “feature creep” towards being just another Bind server that is all
things to all people?

I don't think so.

What would happen to NSD ? Would it be relegated to being just a slave
server? Or would it just go away?

NSD has nothing to do with this discussion, and NSD certainly does *not*
need a cache in front of it: it is fast enough :slight_smile:

It is possible to run unbound and NSD on the same hardware with different
IP's thus avoiding cache poisoning. Putting both the authoritative and
caching server in one program would defeat the the security wall of
separate servers.

I'm not talking of NSD. I'm talking of slow servers with a database
backend (e.g. BIND-SDB). This can be used as an authoritative server,
but it lacks in performance. My proposal is to put a fast cache before
servers of its kind, having the cache answer authoritatively.

Obviously one can put an slave NSD or a slave BIND (or whatever else)
and have them perform AXFR from the slower backend server, but the
problem is always how the slaves are informed of new/removed zones.
Getting the front-end authoritative cache to determine "electrically"
which zones exist, seems a good idea.

        -JP