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. Section 5 discusses choices made during development.
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.
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
parent, dnssec-lameness detection enables. This delivers dnssec to our
clients when possible (for client validators).
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.
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.
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).
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.
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.
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
behaviour.
o Denial of service protection
If many queries are made, and they are made to names for which the
authority servers do not respond, then the requestlist for unbound
fills up fast. This results in denial of service for new queries.
To combat this the first 50% of the requestlist can run to completion.
The last 50% of the requestlist get (200 msec) at least and are replaced
by newer queries when older (LIFO).
When a new query comes in, and a place in the first 50% is available, this
is preferred. Otherwise, it can replace older queries out of the last 50%.
Thus, even long queries get a 50% chance to be resolved. And many 'short'
one or two round-trip resolves can be done in the last 50% of the list.
The timeout can be configured.
o EDNS fallback. Is done according to the EDNS RFC (and update draft-00).
Unbound assumes EDNS 0 support for the first query. Then it can detect
support (if the servers replies) or non-support (on a NOTIMPL or FORMERR).
Some middleboxes drop EDNS 0 queries, mainly when forwarding, not when
routing packets. To detect this, when timeouts keep happening, as the
timeout approached 5-10 seconds, and EDNS status has not been detected yet,
a single probe query is sent. This probe has a sub-second timeout, and
if the server responds (quickly) without EDNS, this is cached for 15 min.
This works very well when detecting an address that you use much - like
a forwarder address - which is where the middleboxes need to be detected.
Otherwise, it results in a 5 second wait time before EDNS timeout is
detected, which is slow but it works at least.
It minimizes the chances of a dropped query making a (DNSSEC) EDNS server
falsely EDNS-nonsupporting, and thus DNSSEC-bogus, works well with
middleboxes, and can detect the occasional authority that drops EDNS.
For some boxes it is necessary to probe for every failing query, a
reassurance that the DNS server does EDNS does not mean that path can
take large DNS answers.
o 0x20 backoff.
The draft describes to back off to the next server, and go through all
servers several times. Unbound goes on get the full list of nameserver
addresses, and then makes 3 * number of addresses queries.
They are sent to a random server, but no one address more than 4 times.
It succeeds if one has 0x20 intact, or else all are equal.
Otherwise, servfail is returned to the client.
o NXDOMAIN and SOA serial numbers.
Unbound keeps TTL values for message formats, and thus rcodes, such
as NXDOMAIN. Also it keeps the latest rrsets in the rrset cache.
So it will faithfully negative cache for the exact TTL as originally
specified for an NXDOMAIN message, but send a newer SOA record if
this has been found in the mean time. In point, this could lead to a
negative cached NXDOMAIN reply with a SOA RR where the serial number
indicates a zone version where this domain is not any longer NXDOMAIN.
These situations become consistent once the original TTL expires.
If the domain is DNSSEC signed, by the way, then NSEC records are
updated more carefully. If one of the NSEC records in an NXDOMAIN is
updated from another query, the NXDOMAIN is dropped from the cache,
and queried for again, so that its proof can be checked again.
o SOA records in negative cached answers for DS queries.
The current unbound code uses a negative cache for queries for type DS.
This speeds up building chains of trust, and uses NSEC and NSEC3
(optout) information to speed up lookups. When used internally,
the bare NSEC(3) information is sufficient, probably picked up from
a referral. When answering to clients, a SOA record is needed for
the correct message format, a SOA record is picked from the cache
(and may not actually match the serial number of the SOA for which the
NSEC and NSEC3 records were obtained) if available otherwise network
queries are performed to get the data.
o Parent and child with different nameserver information.
A misconfiguration that sometimes happens is where the parent and child
have different NS, glue information. The child is authoritative, and
unbound will not trust information from the parent nameservers as the
final answer. To help lookups, unbound will however use the parent-side
version of the glue as a last resort lookup. This resolves lookups for
those misconfigured domains where the servers reported by the parent
are the only ones working, and servers reported by the child do not.
o Failure of validation and probing.
Retries on a validation failure are now 5x to a different nameserver IP
(if possible), and then it gives up, for one name, type, class entry in
the message cache. If a DNSKEY or DS fails in the chain of trust in the
key cache additionally, after the probing, a bad key entry is created that
makes the entire zone bogus for 900 seconds. This is a fixed value at
this time and is conservative in sending probes. It makes the compound
effect of many resolvers less and easier to handle, but penalizes
individual resolvers by having less probes and a longer time before fixes
are picked up.
