2007-01-15 14:38:36 +00:00
|
|
|
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
|
2008-01-04 18:00:45 +00:00
|
|
|
project. Section 5 discusses choices made during development.
|
2007-01-15 14:38:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
2007-08-02 09:13:32 +00:00
|
|
|
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.
|
2007-08-03 09:13:54 +00:00
|
|
|
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.
|
2007-10-22 15:25:37 +00:00
|
|
|
o The method by which dnssec-lameness is detected is not secure. DNSSEC lame
|
|
|
|
is when a server has the zone in question, but lacks dnssec data, such as
|
|
|
|
signatures. The method to detect dnssec lameness looks at nonvalidated
|
|
|
|
data from the parent of a zone. This can be used, by spoofing the parent,
|
|
|
|
to create a false sense of dnssec-lameness in the child, or a false sense
|
|
|
|
or dnssec-non-lameness in the child. The first results in the server marked
|
|
|
|
lame, and not used for 900 seconds, and the second will result in a
|
|
|
|
validator failure (SERVFAIL again), when the query is validated later on.
|
|
|
|
|
|
|
|
Concluding, a spoof of the parent delegation can be used for many cases
|
|
|
|
of denial of service. I.e. a completely different NS set could be returned,
|
|
|
|
or the information withheld. All of these alterations can be caught by
|
|
|
|
the validator if the parent is signed, and result in 900 seconds bogus.
|
|
|
|
The dnssec-lameness detection is used to detect operator failures,
|
|
|
|
before the validator will properly verify the messages.
|
|
|
|
|
|
|
|
Also for zones for which no chain of trust exists, but a DS is given by the
|
2008-01-02 13:24:35 +00:00
|
|
|
parent, dnssec-lameness detection enables. This delivers dnssec to our
|
2007-10-22 15:25:37 +00:00
|
|
|
clients when possible (for client validators).
|
2007-10-23 08:30:21 +00:00
|
|
|
|
|
|
|
The following issue needs to be resolved:
|
|
|
|
a server that serves both a parent and child zone, where
|
|
|
|
parent is signed, but child is not. The server must not be marked
|
|
|
|
lame for the parent zone, because the child answer is not signed.
|
|
|
|
Instead of a false positive, we want false negatives; failure to
|
|
|
|
detect dnssec-lameness is less of a problem than marking honest
|
|
|
|
servers lame. dnssec-lameness is a config error and deserves the trouble.
|
|
|
|
So, only messages that identify the zone are used to mark the zone
|
|
|
|
lame. The zone is identified by SOA or NS RRsets in the answer/auth.
|
|
|
|
That includes almost all negative responses and also A, AAAA qtypes.
|
|
|
|
That would be most responses from servers.
|
|
|
|
For referrals, delegations that add a single label can be checked to be
|
|
|
|
from their zone, this covers most delegation-centric zones.
|
|
|
|
|
|
|
|
So possibly, for complicated setups, with multiple (parent-child) zones
|
|
|
|
on a server, dnssec-lameness detection does not work - no dnssec-lameness
|
|
|
|
is detected. Instead the zone that is dnssec-lame becomes bogus.
|
|
|
|
|
2007-11-14 15:07:54 +00:00
|
|
|
o authority features.
|
|
|
|
This is a recursive server, and authority features are out of scope.
|
|
|
|
However, some authority features are expected in a recursor. Things like
|
|
|
|
localhost, reverse lookup for 127.0.0.1, or blocking AS112 traffic.
|
|
|
|
Also redirection of domain names with fixed data is needed by service
|
|
|
|
providers. Limited support is added specifically to address this.
|
|
|
|
|
|
|
|
Adding full authority support, requires much more code, and more complex
|
|
|
|
maintenance.
|
|
|
|
|
|
|
|
The limited support allows adding some static data (for localhost and so),
|
|
|
|
and to respond with a fixed rcode (NXDOMAIN) for domains (such as AS112).
|
|
|
|
|
|
|
|
You can put authority data on a separate server, and set the server in
|
|
|
|
unbound.conf as stub for those zones, this allows clients to access data
|
|
|
|
from the server without making unbound authoritative for the zones.
|
2007-11-22 13:48:58 +00:00
|
|
|
|
|
|
|
o the access control denies queries before any other processing.
|
|
|
|
This denies queries that are not authoritative, or version.bind, or any.
|
|
|
|
And thus prevents cache-snooping (denied hosts cannot make non-recursive
|
|
|
|
queries and get answers from the cache).
|
2007-11-28 12:06:32 +00:00
|
|
|
|
|
|
|
o If a client makes a query without RD bit, in the case of a returned
|
|
|
|
message from cache which is:
|
|
|
|
answer section: empty
|
|
|
|
auth section: NS record present, no SOA record, no DS record,
|
|
|
|
maybe NSEC or NSEC3 records present.
|
|
|
|
additional: A records or other relevant records.
|
|
|
|
A SOA record would indicate that this was a NODATA answer.
|
|
|
|
A DS records would indicate a referral.
|
|
|
|
Absence of NS record would indicate a NODATA answer as well.
|
|
|
|
|
|
|
|
Then the receiver does not know whether this was a referral
|
|
|
|
with attempt at no-DS proof) or a nodata answer with attempt
|
|
|
|
at no-data proof. It could be determined by attempting to prove
|
|
|
|
either condition; and looking if only one is valid, but both
|
|
|
|
proofs could be valid, or neither could be valid, which creates
|
|
|
|
doubt. This case is validated by unbound as a 'referral' which
|
|
|
|
ascertains that RRSIGs are OK (and not omitted), but does not
|
|
|
|
check NSEC/NSEC3.
|
|
|
|
|
2008-01-21 16:03:59 +00:00
|
|
|
o Case preservation
|
|
|
|
Unbound preserves the casing received from authority servers as best
|
|
|
|
as possible. It compresses without case, so case can get lost there.
|
2008-04-16 09:33:24 +00:00
|
|
|
The casing from the query name is used in preference to the casing
|
|
|
|
of the authority server. This is the same as BIND. RFC4343 allows either
|
2008-01-21 16:03:59 +00:00
|
|
|
behaviour.
|