wiki:ResolverHighLevelRequirements

High Level Recursive Resolver Requirements

This document lists the high-level requirements of the recursive resolver. As the plan is to implement the resolver in a number of stages, the requirements have been broken down by stage.

Nomenclature
A resolver accepts queries from clients and, as part of the resolution process, sends queries to authoritative servers. To minimize confusion in this document, queries received from clients are referred to a "queries". Queries sent by the resolver to authoritative servers are referred to as "fetches".

Stage 1: Basic Recursive Resolver

This aims to produce a Recursive Resolver able to receive a query and return an answer, the idea being to get a firm framework on which subsequent development work can be based. To get this stage implemented as soon as possible, a number of simplifications are being made, the main ones being:

  • A cache interface will be defined, but only a simple cache will be supplied.
  • The resolver will not understand DNSSEC.
  • The fetch logic will be simple: no retransmits on timeout and no TCP fallback on truncated response; a failure of an fetch will cause the query that originated it to be dropped.

1.1 General Behaviour

The general behaviour of a resolver is described in a number of RFCs. Rather than provide a detailed description of it here, this set of requirements identify the RFCs that need to be consulted. It is expected that other documents will describe the requirements of the RFCs in more detail.

Number

Description

Notes

Reference

1.1.1 The logic of the resolver should follow that described in section 5.3 of RFC 1034 and section 7 of RFC 1035 This is the basic resolver logic. RFC 1034 RFC 1035
1.1.2 The implementation should note the clarifications and corrections identified in RFC 2181, RFC 6604 and RFC 6672. RFC 2181 RFC 6604 RFC 6672
1.1.3 The implementation must take note of the issues described in RFC 1535, RFC 1536 and RFC 4697. These documents describe problems and misbehaviour seen with early versions of nameservers. It is important that the resolver does not repeat these mistakes. RFC 1535 RFC 1536 RFC 4697
1.1.4 Although this stage does not implement DNSSEC, the resolution logic should be aware of the requirements imposed by RFC 4035, as this may influence the structure of the code. RFC 4035
1.1.5 The resolver must be able to make use of multi-CPU/multi-core processors. It may do this either by using multiple threads, multiple processes sharing a cache, or by some other method.
1.1.6 The resolver must be able to serve some locally-configured zones A suitable solution may include handing off such queries to a locally-running BIND X authoritative server. RFC 6303
1.1.7 The server must support EDNS0. At this stage, all that is required is that the server accept an OPT RR in an incoming query and act on if it supports the requested option. The server be able to add an OPT RR to fetches if appropriate (and act on the response). RFC 6891
1.1.8 The resolver should use a flexible logging framework.

1.2 Cache

The design must describe the interface into the cache. Only a naive cache is expected to be implemented in stage 1; the cache proper is the subject of stage 2 development. The interface should be capable of handling the following:

Number

Description

Notes

Reference

1.2.1 The cache should be able to store the results of fetches from authoritative nameservers.
1.2.2 The cache should store the capabilities and characteristics of upstream nameservers, including a measure of their responsiveness. The measure of responsiveness is typically the moving average of recent round-trip times for queries to that nameserver.
1.2.3 It should be possible to put a limit on the size of the cache. Limiting the size of the cache to a fixed number of bytes is not necessary; a limit to the number of entries in the cache is acceptable. The idea behind the requirement is to prevent the cache growing without bound.
1.2.4 The cache should be able to handle entries with a TTL of 0. RFC 1123, section 6.1.2.1.
1.2.5 The cache should be able to cache negative responses. RFC 2308
1.2.6 It should be possible to flush the entire cache and to remove individual entries from it.
1.2.7 It should be possible to obtain statistics information from the cache. E.g. number of entries, average size of entries etc.

1.3 Specific Configuration

A number of parameters control the operation of the resolver. This section lists some of these options: by implication, the resolver should honour the values at the appropriate point in its processing.

Number

Description

Notes

Reference

1.3.1 It must be possible to configure the addresses of the root servers. The problem of routing queries for local domains (also mentioned in the same section) is left to a later stage of implementation. A later stage will implement the recommendations of the root priming draft. RFC 1123, section 6.1.3.1
1.3.2 It must be possible to specify the IP addresses/ports to listen on. A list of addresses should be able to be specified in the configuration. In the absence of any specification, the server should listen on all connected interfaces.
1.3.3 It must be possible to specify the query address (the address from which upstream fetches originate).
1.3.4 It must be possible to specify the timeout waiting for a response from an authoritative server.
1.3.5 It must be possible to specify the source of random numbers used by the server. (This should default to the operating system's "random" device if no source is specified.) If a system does not have a source of randomness, an alternative random number generator should be implemented.
1.3.6 It must be possible to set the maximum UDP size in replies.
1.3.7 It must be possible to set the EDNS buffer size in replies.
1.3.8 It must be possible to set the maximum number of CNAMES/DNAMES followed before a query is abandoned.

1.4 Server Information

The server should be able to return information about itself in response to appropriate queries. It should do this without generating upstream queries.

Number

Description

Notes

Reference

1.4.1 The server should be able to respond to queries TXT/CH for the following domain names: ID.SERVER, HOSTNAME.BIND, VERSION.SERVER and VERSION.BIND. The values returned for each of the query strings should be configurable and if a query is received for one of the special names for which no value is configured, the server should return a an appropriate response. ID.SERVER is the server identification, corresponding to the BIND 9 "server-id" configuration setting. HOSTNAME.BIND is a query for hostname of the server hosting the resolver software (name returned by gethostname()). VERSION.SERVER and VERSION.BIND are queries for the same thing, the version of the resolver software.
1.4.2 The server should respond to queries containing the EDNS0 NSID option. The data returned in response to an NSID request should be configurable, and if no NSID data has been configured, the server should behave as if it does not understand the NSID option. RFC 5001

1.5 Query Tracing

To aid debugging, both during development of the resolver and during its operation, it is essential that query tracing be included at the earliest opportunity. The following are requirements for this feature.

Number

Description

Notes

Reference

1.5.1 There must be some way by which queries of interest can be specified. This must allow specification as a combination of domain name, query type, and class, with an option to allow any or all of the components to be specified as a wildcard. This could be as a configuration option, or by some extension mechanism using a hooks plugin.
1.5.2 For each query of interest, the system should log the data used to get to the answer and the origin (i.e. name of upstream name server or result obtained from cache).
1.5.3 Each fetch made to an upstream nameserver in the process of resolving a query of interest should include the NSID OPT RR; if NSID data is received in the response, it should be logged along with the data. RFC 5001

1.6 Statistics

Management of a resolver requires information as to what it is doing. Query tracing can provide some information, but statistics on numbers and types of queries are requirements. The BIND X framework already supplies a way of obtaining statistics; the resolver must conform to this.

Number

Description

Notes

Reference

1.6.1 The resolver must be able to supply a set of statistics, both on queries received and on the results/behavior of authoritative nameservers queried.
1.6.2 It must be possible to set how often the resolver is polled for statistics. This is an artifact of the current implementation.

1.7 Testing Requirements

In parallel with the development of the resolver software, a suitable testing environment must be established. This may be provided as open-source software, or it may be internal ISC software, developed as an extension to the software used for testing BIND 9.

Number

Description

Notes

Reference

1.7.1 A functional test bed must be provided.
1.7.2 a Performance test bed must be provided.

1.8 Other Requirements

Miscellaneous other requirements for this stage include:

Number

Description

Notes

Reference

1.8.1 The resolver should try to fetch nameserver addresses in a way to minimize latency. (This deals with the question of getting the addresses of a potentially large number of nameservers for a zone when the query requires that only the address of one nameserver.)
1.8.2 The resolver logic should have a way of using the most responsive nameserver for a zone while at the same time periodically checking whether other nameservers for that zone have changed their response time.

1.9 RFCs Referenced

The following RFCs have been referenced in the requirements for stage 1:

  • RFC 1034 DOMAIN NAMES - CONCEPTS AND FACILITIES
  • RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
  • RFC 1123 Requirements for Internet Hosts -- Application and Support
  • RFC 1535 A Security Problem and Proposed Correction With Widely
  • RFC 1536 Common DNS Implementation Errors and Suggested Fixes
  • RFC 2181 Clarifications to the DNS Specification
  • RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
  • RFC 4035 Protocol Modifications for the DNS Security Extensions
  • RFC 4697 Observed DNS Resolution Misbehavior
  • RFC 5001 DNS Name Server Identifier (NSID) Option
  • RFC 6303 Locally Served DNS Zones
  • RFC 6604 xNAME RCODE and Status Bits Clarification
  • RFC 6672 DNAME Redirection in the DNS
  • RFC 6891 Extension Mechanisms for DNS (EDNS(0))

Stage 2: Basic non-validating server implementation

The major feature in this stage is the addition of a full cache implementation. In addition, some items that were skimmed over in stage 1 will be completed. At the end of this stage, we will have a fully working resolver with good performance, although it will not be able to handle DNSSEC.

2.1 Cache Implementation

The cache is the heart of the resolver and is crucial to its performance. For this reason, implementation of the full cache has been given (more or less) a stage to itself. Stage 1.2 provided the interface to the cache and a naive implementation of it. This phase replaces that implementation with a fully-functioning and optimised cache. In addition to the requirements of stage 1.2, the following additional requirements are imposed:

Number

Description

Notes

Reference

2.1.1 Implement caching for RRs, Nameservers, Keys, negative responses. At the same time, configurable limits on the use of resources by these caches should be set. Negative caching is described in the referenced RFC. RFC 2308
2.1.2 It must be possible to configure the minimum and maximum TTLs of records in the cache, although the special case nature of a TTL of 0 should be honoured. Prevents records with an excessively high TTL being "stuck" in the cache. It also allows the manager to override excessively low TTLs to prevent excessive upstream querying. TTL=0 issues are covered in the referenced RFC. RFC 1123 section-6.1.2.1
2.1.3 It must be possible to set the ordering of RRs returned in an RRset retrieved from cache (fixed, random, cyclic).
2.1.4 It must be possible to associate capabilities against nameservers to optimize later processing. E.g. EDNS0 support.

2.2 Retries and TCP

This section completes the I/O handling of stage 1.

Number

Description

Notes

Reference

2.2.1 If a response is received from an upstream server with the truncated bit set (TC=1), the query should be repeated using TCP. The TCP connection should be dropped after the query is received; intelligent connection handling in included in stage 7. The use of the TC bit is described in the referenced RFCs. RFC 2181 RFC 1035
2.2.2 If a UDP query to an upstream server times out, it should be repeated up to a configurable number of retries. Should the server retry a query to a nameserver or automatically choose another on a timeout?

2.3 Miscellaneous

Number

Description

Notes

Reference

2.3.1 Commands should be provided to flush the cache and to remove an individual entry from it.

2.4 RFCs Referenced

The following RFCs have been referenced in the requirements for stage 2:

  • RFC 1034 DOMAIN NAMES - CONCEPTS AND FACILITIES
  • RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
  • RFC 1123 Requirements for Internet Hosts -- Application and Support
  • RFC 2181 Clarifications to the DNS Specification
  • RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)

Stage 3: Basic Validating Server

Previous stages implemented a basic validating resolver. Although the processing included stubs for DNSSEC, the resolver did not understand it. This stage adds DNSSEC processing, albeit with limitations:

  • It will not understand NSEC3
  • It will not be possible to configure local trust anchors; all validation will be done via the root keys.

3.1: Root Key Management

A later stage will add code to handle root key rollovers. For the current stage, a valid root key must be provided.

Number

Description

Notes

Reference

3.1.1 A root key should be provided with the BIND X Resolver distribution. It is desirable that this is in a form (e.g. exteral file, configuration option) that can be replaced without rebuilding the code.

3.2: DNSSEC Implementation

The implementation should follow the processing described in RFC 4035, as clarified in RFC 6604 and RFC 6840. Unless noted otherwise here, as a reference implementation all SHOULD, MAY etc. RFC 2119 keywords in RFC 4035 must be interpreted as MUSTs.

Number

Description

Notes

Reference

3.2.1 Unless inhibited by a configuration option, the resolver must add an OPT RR with the DO bit set to outgoing queries, and must retry the query if the server returns an appropriate error code. This allows the disabling of the DNSSEC, turning the server into a non-validating resolver. RFC 3225
3.2.2 The resolver must only trust glue obtained from the server authoritative for it. An additional security measure.
3.2.3 The resolver logic must follow that described in RFC 4035, section 4 Much of this should have been implemented in Stage 1, as that logic was supposed to be aware of DNSSEC considerations. This requirement is here to ensure that any gaps are filled. RFC 4035, section 4
3.2.4 In this stage, it is only required that the resolver be able to be configured with the root trust anchor. Configuration of multiple trust anchors is left to a later stage of implementation. RFC 4035, section 4.4
3.2.5 The resolver must be able to interpret the data in the resource records associated with DNSSEC RFC 4034
3.2.6 The resolver must be able to authenticate DNS responses as described in RFC 4035, section 5. RFC 4035, section 5
3.2.7 An option should be available to ignore (but report) validation failures. This is aimed at ISPs who wish to assess the risks of enabling DNSSEC. A future version of the resolver may implement "negative trust anchors".

3.3 RFCs Referenced

The following RFCs have been referenced in the requirements for stage 3:

  • RFC 3225, Indicating Resolver Support of DNSSEC
  • RFC 4034, Resource Records for the DNS Security Extensions
  • RFC 4035, Protocol Modifications for the DNS Security Extensions
  • RFC 6604, xNAME RCODE and Status Bits Clarification
  • RFC 6840, Clarifications and Implementation Notes for DNS Security (DNSSEC)

Stage 4: Advanced Non-Validating Server Features

With the basic validating resolver completed, this and subsequent stages start adding the "bells and whistles", fleshing out the capabilities of the server.

4.1: Additional Non-Validating Features

Number

Description

Notes

Reference

4.1.1 The resolver must harden security by the use of measures such as random ports when originating fetches and accepting in-bailiwick resposes. Appropriate configuration features should be in place, e.g. range(s) of ports over which to randomise etc. RFC 5452
4.1.2 The resolver should originate a priming query when it starts, and periodically thereafter. draft-ietf-dnsop-resolver-priming
4.1.3 The cache should be extended to include EDNS0 information about nameservers. Processing should be altered to adjust payload size to match that capable of being accepted by authoritative servers, and to handle selection between EDNS0-capable servers and fallback to TCP for other ones. RFC 6891
4.1.4 It should be possible to configure some zones to be served by specific authoritative servers. This may allow the serving of local zones by passing the query to a BIND X authoritative server on the same machine. RFC 6303
4.1.5 Provision of a configuration option allowing minimal responses to be returned (i.e. only the answer section, no authority or additional section information)
4.1.6 To minimise delay, the server should be capable of fetching frequently-accesses RRs (including DNSKEY RRs) in advance of expiration. One way of doing this is given as a reference: there may be other ways. draft-wkumari-dnsop-hammer

4.2 RFCs Referenced

The following RFCs and Internet Drafts have been referenced in the requirements for stage 4:

Stage 5: Advanced Validating Server

The work in Stage 3 added basic DNSSEC support. This stage completes the DNSSEC implementation (apart from additional algorithms) by adding support for NSEC3.

5.1 Addition of NSEC3 Support

RFC 5155 not only describes the NSEC3 authenticated denial of existence record, it also describes "opt out" - a way to reduce the DNSSEC overhead in a zone where the majority of delegations are unsigned. This stage aims to implement both of these features.

Number

Description

Notes

Reference

5.1.1 The resolver should implement understand NSEC3 denial of existence and opt-out, as described in RFC 5155 RFC 5155

5.2 RFCs Referenced

The following RFCs have been referenced in the requirements for stage 5:

  • RFC 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

Stage 6: Additional Useful Features

Miscellaneous useful features are added in this stage. Most important are advanced TCP connection handling and ACLs.

6.1 TCP Connection Handling

The TCP requirements of DNS were enhanced and clarified in RFC 5966. This stage implements all the recommendations of that RFC.

Number

Description

Notes

Reference

6.1.1 The resolver should implement implement the TCP recommendations of RFC 5966, in particular the sections on protocol handling (TCP can be tried first if there appropriate reason), connection handling and response reordering. RFC 5966

6.2 ACLs

ACLs allow the resolver to accept or reject queries based on various criteria, e.g. accept queries from a particular interface, reject queries from a particular IP address etc. The format of ACLs are not described here - they can be found in the BIND X Guide. At this stage, validation through the use of a TSIG key will not be implemented.

Number

Description

Notes

Reference

6.2.1 It must be possible to add one or more ACLs to the resolver configuration.
6.2.2 If a request is received and ACLs are present, the resolver must validate the request properties against the ACL(s) in order to decide whether or not to process the request.

6.3 Answer Re-Write

This is an optimization to speed up the processing of requests. As well as caching resource records, the resolver caches wire-format answers. When a query is received, if a formatted answer is in the cache it is instead of incurring the overhead of re-rendering the answer. However, the resolver needs to do some work: the TTLs of the RRs in the answer must be updated and the QID modified to match that of the query.

Number

Description

Notes

Reference

6.3.1 Wire-format replies of popular answers should be cached and used (with appropriate modification of TTLs and QID) where appropriate. It probably makes sense only to cache a wire-format reply if there are enough queries to justify it.
6.3.2 When any of the RRs in the answer expire, the answer should be discarded from cache; a new answer should be created when conditions justify it. It is left to the implementer whether this can by bypassed if a fetch for expired RRs reveal an unchanged RRset.
6.3.3 It must be possible to limit the size of the answer cache. If adding an answer takes the size above this limit, one or more answers must be dropped. Specifying size by number of cached answers is acceptable.

6.4 NAT 64

While the Internet is still in the process of moving from IPv4 to IPv6, transition tools will be needed. One such tool is DNS64, a mechanism for synthesizing AAAA records from A records, allowing an IPv6-only client to initiate communications by name to an IPv4-only server

Number

Description

Notes

Reference

6.4.1 The resolver should be able to handle the necessary operations to allow DNS64 to function. Most DNS64 functions apply to the authoritative server, but the resolver needs to be aware of the technology, especially for glue records. RFC 6147

6.5 RFCs Referenced

The following RFCs have been referenced in the requirements for stage 6:

  • RFC 5966 DNS Transport over TCP - Implementation Requirements
  • RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers

Stage 7: Very Advanced Validating Server

By this point, the resolver is a fully-working validating resolver. This stage implements miscellaneous additional features related to DNSSEC.

7.1 Additional DNSSEC-Related Features

Number

Description

Notes

Reference

7.1.1 The resolver should understand DNSSEC records that use the GOST hash algorithm. RFC 5831
7.1.2 The resolver should understand DNSSEC records that use the ECDSA hash algorithm. ??
7.1.3 It should be possible to configure manual trust anchors and handle their updates automatically RFC 5011
7.1.4 It must be possible to configure "Negative Trust Anchors", which disable DNSSEC for specific domains and their subdomains. This supplements the ability to report (and ignore) failing DNSSEC validation. draft-livingood-negative-trust-anchors

7.2 RFCs Referenced

The following RFCs and Internet Drafts have been referenced in the requirements for stage 7:

Stage 8: Miscellaneous Updates

The resolver is fully functioning. This stage adds miscellaneous features.

8.1 Miscellaneous Changes

Number

Description

Notes

Reference

8.1.1 ACLs should be extended to recognise TSIG keys. This allows access to be restricted to those in possession of the approved key. RFC 2845 RFC 2930 RFC 4635
8.1.2 The resolver should be able to signal to authoritative servers the DNSSEC algorithms it understands. RFC 6975

8.2 RFCs Referenced

The following RFCs and Internet Drafts have been referenced in the requirements for stage 8:

  • RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
  • RFC 2930 Secret Key Establishment for DNS (TKEY RR)
  • RFC 4635 HMAC SHA TSIG Algorithm Identifiers
  • RFC 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)

Section 9. Non-Requirements

This section contains items that will not be done - they are explicit non-requirements.

Last modified 4 years ago Last modified on Jan 23, 2014, 6:50:11 PM