Goals for BIND 10 Resolver 2013 (version 2)

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.

We will attempt to steadily build more and more functional versions of the server over time, with each milestone.


There are 5 milestones, as well as a "non-milestone" of things that will not fit, but should still be done before too 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: Basic non-validating server implementation

    Here we provide a server which does basic recursive resolution.

    • DNS recursive resolution
    • DNS caching
    • Query tracing
    • Server capability tracking (adb in BIND 9, NSAS in BIND 10)
    • Recursive resolver functional test bed
    • Recursive resolver performance test bed
  • Milestone 3: Basic DNSSEC validator

    Here we add in basic DNSSEC support.

    • DNSKEY fetching
    • Signature verification
    • Modify cache to track RR security status
    • Positive validation
    • NSEC handling
    • NSEC3 handling
    • RFC 5702 (SHA-2)

At this point the server will support basic recursive resolution with DNSSEC, but should not be used on the Internet.

  • Milestone 4: Advanced non-validating server implementation

    Here we add remaining necessary features for a production recursive resolver.
    • Port randomization (anti-Kaminsky)
    • Root priming
    • EDNS(0) logic
    • Locally-served zones
  • Milestone 5: Advanced DNSSEC validation

    Here we extend the functionality of the DNSSEC validator.

    • Manual trust anchor configuration
    • CD/AD bit handling
    • RFC 5933 (GOST)
    • RFC 6605 (ECDSA)
    • Negative trust anchors

At this point the resolver is essentially complete.

  • 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

1.2 Benchmarking infrastructure design and implementation

1.3 Server architecture design

1.4 Performance testing

Milestone 2: Basic non-validating server implementation

2.1 Internal queuing mechanism

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

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

2.3 Query receiver / receptionist

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

2.5 Server capability tracking

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

2.6 Recursive resolution

2.7 Recursive resolver functional test bed

2.8 Recursive resolver performance test bed

Milestone 3: Basic DNSSEC validator

3.1 DNSKEY fetching

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

3.2 Signature verification

3.3 Modify cache to track RR security status

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 Checking RRSIG RR validity

3.5 NSEC handling

3.6 NSEC3 handling

3.7 RFC 5702 (SHA-2)

Milestone 4: Advanced non-validating server implementation

4.1 Port randomization (anti-Kaminsky)

4.2 Root priming

4.3 EDNS0 logic

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

4.4 Locally served zones

Milestone 5: Advanced DNSSEC validator

5.1 Manual trust anchor configuration

5.2 CD/AD bit handling

5.3 RFC 5933 (GOST)

5.4 RFC 6605 (ECDSA)

5.5 Negative trust anchors

This could be based on

Non-milestone stuff

6.1 RFC 5011 support

6.2 Multi-tiered cache

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

6.3 Cache persistence

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

6.4 Cache migration

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

6.5 ICMP port unreachable collection

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

Last modified 4 years ago Last modified on Nov 14, 2013, 10:16:03 PM