Commit edfad4a9 authored by Shane Kerr's avatar Shane Kerr Committed by Michal 'vorner' Vaner
Browse files

Some starting questions for recursive resolver research.

parent e93ef80d
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).
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.
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.
This directory contains research and design documents for the BIND 10
resolver reimplementation.
Each file contains a specific issue and discussion surrounding that
issue.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment