Goals for BIND 10 Resolver 2013

This page describes an approach to re-implementing the BIND 10 recursive resolver.

The primary goals for the BIND 10 recursive resolver are:

  • High performance
  • Transparent operations that can be debugged
  • Able to be customized

We assume that the software will be both correct and secure, so these are not explicit goals.

Overall Approach

We will put most of the BIND 10 development effort into the BIND 10 Resolver work.

In the past we attempted to split the team during development of the resolver, and it resulted in a lack of focus. This resulted in incomplete implementations of both the resolver and the authoritative server.

In 2013 we will still have to dedicate resources to the authoritative server, especially in support, as we will have production users. There will also be a certain amount of ongoing feature development. Neither of these should become a distraction for the main purpose of creating a fully functional resolver.


There are 5 milestones, as well as a "non-milestone" of things that will probably not fit in 2013, but should still be done before much time passes.

  • Milestone 1: Architecture research, benchmarking, and selection

In this milestone we need to document more formally the requirements of the resolver. We also need to benchmark and design the basic components of the server architecture, including both synthetic and real-world performance tests.

  • Milestone 2: Non-validating server implementation

    Here we provide a server which does basic recursive resolution. Although basic, it will have a lot of features:

    • DNS recursive resolution
    • DNS caching
    • Query tracing
    • Server capability tracking (adb in BIND 9, NSAS in BIND 10)
    • Port randomization (anti-Kaminsky)
    • Root priming
    • EDNS(0) logic
    • Locally-served zones
    • DNSKEY fetching

The main work missing here is DNSSEC validation, although we will be fetching DNSKEY information.

  • Milestone 3: DNSSEC validation

Here we validate answers that we get back, manage trust anchors, and implement the various DNSSEC algorithms.

  • Milestone 4: Hooks

Being able to hook into the resolution process to take action on specific events, or change either the resolution process or the results returned is an important goal for BIND 10. This milestone covers that need, from the recursive resolution point of view.

This milestone is somewhat independent of the other milestones, so can be done parallel with them, as appropriate.

  • Non-Milestone

    Several features are very useful, but can be postponed until later.

    • RFC 5011 support (not really necessary until root rolls its key)
    • Multi-tiered cache
    • Cache persistence
    • Cache migration
    • ICMP port unreachable collection


Here are some proposed high-level work items for each milestone, along with estimates in work-days for these.

Milestone 1: Architecture research, benchmarking, selection

1.1 Requirements document (5d)

1.2 Benchmarking infrastructure design and implementation (10d)

1.3 Server architecture design (20d)

1.4 Performance testing (15d)

Milestone 2: Basic server implementation

2.1 Internal queuing mechanism (15d)

The idea of this item is that whatever our architecture is we will need to send work between the various components of the system and have an efficient way to do this.

2.2 Simple DNS cache (20d)

This means defining the API, data structures, and implementing a simple DNS cache

2.3 Query receiver / receptionist (20d)

This is a component covers whatever we need to do to actually receive queries & answers, and direct them properly. It could be a separate program or merely a class.

2.4 Query tracing (20d)

2.5 Server capability tracking (30d)

This is something like BIND 9's adb, or the existing NSAS in BIND 10, although with additional server information tracking.

2.6 Port randomization (anti-Kaminsky) (30d)

2.7 Root priming (5d)

2.8 EDNS0 logic (15d)

BIND 9 just finished revising EDNS0, so we can steal those heuristics.

2.9 Recursive resolution (30d)

2.10 Locally served zones (15d)

2.11 DNSKEY fetching (10d)

This is merely retrieving the DNSKEY records as we resolve, not actually doing anything with them.

2.12 Recursive resolver functional test bed (30d)

2.13 Recursive resolver performance test bed (15d)

Milestone 3: DNSSEC validation

3.1 Manual trust anchor configuration (10d)

3.2 Signature verification (15d)

3.3 Modify cache to track RR security status (20d)

This probably should be designed in from the beginning, but I am thinking that perhaps a great deal of the implementation can be left stubbed-out until we actually do validation.

3.4 CD/AD bit handling (10d)

3.5 Checking RRSIG RR validity (25d)

3.6 NSEC handling (15d)

3.7 NSEC3 handling (30d)

3.8 RFC 5702 (SHA-2) (5d)

3.9 RFC 5933 (GOST) (10d)

3.10 RFC 6605 (ECDSA) (10d)

3.11 Negative trust anchors (15d)

This could be based on

Milestone 4: Code hooks definition

4.1 Hook definitions (10d)

4.2 Implementation and examples (20d)

Non-milestone stuff

5.1 RFC 5011 support (20d)

5.2 Multi-tiered cache (30d)

This may be useful if we have multiple processes not using shared memory as resolvers, or on clustered setups.

5.3 Cache persistence (20d)

Preserving cache on shutdown may speed startup, although of course the costs of storing/loading need to be analyzed.

5.4 Cache migration (30d)

With cache persistence, we should have basic tools to perform cache migration between hosts in a cluster.

5.5 ICMP port unreachable collection

Receiving port unreachable messages can speed up resolution. (We may wish to do this earlier.)

Last modified 6 years ago Last modified on Dec 7, 2012, 3:47:16 PM