mirror of
https://github.com/NLnetLabs/unbound.git
synced 2024-09-21 22:57:08 +00:00
124 lines
5.2 KiB
Plaintext
124 lines
5.2 KiB
Plaintext
Requirements for Recursive Caching Resolver
|
|
(a.k.a. Treeshrew, Unbound-C)
|
|
By W.C.A. Wijngaards, NLnet Labs, October 2006.
|
|
|
|
Contents
|
|
1. Introduction
|
|
2. History
|
|
3. Goals
|
|
4. Non-Goals
|
|
|
|
|
|
1. Introduction
|
|
---------------
|
|
This is the requirements document for a DNS name server and aims to
|
|
document the goals and non-goals of the project. The DNS (the Domain
|
|
Name System) is a global, replicated database that uses a hierarchical
|
|
structure for queries.
|
|
|
|
Data in the DNS is stored in Resource Record sets (RR sets), and has a
|
|
time to live (TTL). During this time the data can be cached. It is
|
|
thus useful to cache data to speed up future lookups. A server that
|
|
looks up data in the DNS for clients and caches previous answers to
|
|
speed up processing is called a caching, recursive nameserver.
|
|
|
|
This project aims to develop such a nameserver in modular components, so
|
|
that also DNSSEC (secure DNS) validation and stub-resolvers (that do not
|
|
run as a server, but a linked into an application) are easily possible.
|
|
|
|
The main components are the Validator that validates the security
|
|
fingerprints on data sets, the Iterator that sends queries to the
|
|
hierarchical DNS servers that own the data and the Cache that stores
|
|
data from previous queries. The networking and query management code
|
|
then interface with the modules to perform the necessary processing.
|
|
|
|
In Section 2 the origins of the Unbound project are documented. Section
|
|
3 lists the goals, while Section 4 lists the explicit non-goals of the
|
|
project.
|
|
|
|
|
|
2. History
|
|
----------
|
|
The unbound resolver project started by Bill Manning, David Blacka, and
|
|
Matt Larson (from the University of California and from Verisign), that
|
|
created a Java based prototype resolver called Unbound. The basic
|
|
design decisions of clean modules was executed.
|
|
|
|
The Java prototype worked very well, with contributions from Geoff
|
|
Sisson and Roy Arends from Nominet. Around 2006 the idea came to create
|
|
a full-fledged C implementation ready for deployed use. NLnet Labs
|
|
volunteered to write this implementation.
|
|
|
|
|
|
3. Goals
|
|
--------
|
|
o A validating recursive DNS resolver.
|
|
o Code diversity in the DNS resolver monoculture.
|
|
o Drop-in replacement for BIND apart from config.
|
|
o DNSSEC support.
|
|
o Fully RFC compliant.
|
|
o High performance
|
|
* even with validation.
|
|
o Used as
|
|
* stub resolver.
|
|
* full caching name server.
|
|
* resolver library.
|
|
o Elegant design of validator, resolver, cache modules.
|
|
* provide the ability to pick and choose modules.
|
|
o Robust.
|
|
o In C, open source: The BSD license.
|
|
o Highly portable, targets include modern Unix systems, such as *BSD,
|
|
solaris, linux, and maybe also the windows platform.
|
|
o Smallest as possible component that does the job.
|
|
o Stub-zones can be configured (local data or AS112 zones).
|
|
|
|
|
|
4. Non-Goals
|
|
------------
|
|
o An authoritative name server.
|
|
o Too many Features.
|
|
|
|
|
|
5. Choices
|
|
----------
|
|
o rfc2181 decourages duplicates RRs in RRsets. unbound does not create
|
|
duplicates, but when presented with duplicates on the wire from the
|
|
authoritative servers, does not perform duplicate removal.
|
|
It does do some rrsig duplicate removal, in the msgparser, for dnssec qtype
|
|
rrsig and any, because of special rrsig processing in the msgparser.
|
|
o The harden-glue feature, when yes all out of zone glue is deleted, when
|
|
no out of zone glue is used for further resolving, is more complicated
|
|
than that, see below.
|
|
Main points:
|
|
* rfc2182 trust handling is used.
|
|
* data is let through only in very specific cases
|
|
* spoofability remains possible.
|
|
Not all glue is let through (despite the name of the option). Only glue
|
|
which is present in a delegation, of type A and AAAA, where the name is
|
|
present in the NS record in the authority section is let through.
|
|
The glue that is let through is stored in the cache (marked as 'from the
|
|
additional section'). And will then be used for sending queries to. It
|
|
will not be present in the reply to the client (if RD is off).
|
|
A direct query for that name will attempt to get a msg into the message
|
|
cache. Since A and AAAA queries are not synthesized by the unbound cache,
|
|
this query will be (eventually) sent to the authoritative server and its
|
|
answer will be put in the cache, marked as 'from the answer section' and
|
|
thus remove the 'from the additional section' data, and this record is
|
|
returned to the client.
|
|
The message has a TTL smaller or equal to the TTL of the answer RR.
|
|
If the cache memory is low; the answer RR may be dropped, and a glue
|
|
RR may be inserted, within the message TTL time, and thus return the
|
|
spoofed glue to a client. When the message expires, it is refetched and
|
|
the cached RR is updated with the correct content.
|
|
The server can be spoofed by getting it to visit a especially prepared
|
|
domain. This domain then inserts an address for another authoritative
|
|
server into the cache, when visiting that other domain, this address may
|
|
then be used to send queries to. And fake answers may be returned.
|
|
If the other domain is signed by DNSSEC, the fakes will be detected.
|
|
|
|
In summary, the harden glue feature presents a security risk if
|
|
disabled. Disabling the feature leads to possible better performance
|
|
as more glue is present for the recursive service to use. The feature
|
|
is implemented so as to minimise the security risk, while trying to
|
|
keep this performance gain.
|