Some starting questions for recursive resolver research.

doc/design/resolver/01-scaling-across-cores

@@ -0,0 +1,21 @@
+01-scaling-across-cores
+
+Introduction
+------------
+The general issue is how to insure that the resolver scales.
+
+Currently resolvers are CPU bound, and it seems likely that both
+instructions-per-cycle and CPU frequency will not increase radically,
+scaling will need to be across multiple cores.
+
+How can we best scale a recursive resolver across multiple cores?
+
+Some possible solutions:
+
+a. Multiple processes with independent caches
+b. Multiple processes with shared cache
+c. A mix of independent/shared cache
+d. Thread variations of the above
+
+All of these may be complicated by NUMA architectures (with
+faster/slower access to specific RAM).

doc/design/resolver/02-mixed-recursive-authority-setup

@@ -0,0 +1,28 @@
+02-mixed-recursive-authority-setup
+
+Introduction
+------------
+Ideally we will run the authoritative server independently of the
+recursive resolver.
+
+We need a way to run both an authoritative and a recursive resolver on
+a single platform, listening on the same IP/port.
+
+We have 3 basic components involved in this mix:
+
+1. Authoritative zones
+2. Cached RRSETs
+3. Non-cached information
+
+There are a number of possible approaches to this:
+
+a. Make a module that includes all logic. (The BIND 9 module?)
+b. Look at authoritative server first, and pass queries to the
+   recursive component.
+c. Make a module that combines authoritative and cache. Queries not
+   found get passed to a resolver, which also has to update the cache.
+d. Have a simple "receptionist" module which knows which zones we are
+   authoritative for and sends all queries to another daemon.
+
+Stephen did some modeling work on this already. We need to understand
+the latency and throughput implications of any of these approaches.

doc/design/resolver/03-cache-algorithm

@@ -0,0 +1,22 @@
+03-cache-algorithm
+
+Introduction
+------------
+Cache performance may be important for the resolver. It might not be
+critical. We need to research this.
+
+One key question is: given a specific cache hit rate, how much of an
+impact does cache performance have?
+
+For example, if we have 90% cache hit rate, will we still be spending
+most of our time in system calls or in looking things up in our cache?
+
+There are several ways we can consider figuring this out, including
+measuring this in existing resolvers (BIND 9, Unbound) or modeling
+with specific values.
+
+Once we know how critical the cache performance is, we can consider
+which algorithm is best for that. If it is very critical, then a
+custom algorithm designed for DNS caching makes sense. If it is not,
+then we can consider using an STL-based data structure.
+

doc/design/resolver/README

@@ -0,0 +1,5 @@
+This directory contains research and design documents for the BIND 10
+resolver reimplementation.
+
+Each file contains a specific issue and discussion surrounding that
+issue.