Overview

Deadwood is immune to many DNS spoofing attacks because it uses a different method to resolve domains than what most other DNS servers use. While more complicated, and sometimes a little slower, this is more than compensated for by having better security.

The information here assumes some knowledge of DNS, which I will briefly summarize.

How DNS works

A DNS reply contains multiple DNS answers. It has an answer section, which has the answer to a DNS question made. For example, if one requests the A (IPv4 IP) record for, say, www.example.com [1], they may get an answer like "www.example.com's A record is the IP 10.1.2.3" [2] [3].

DNS replies can have multiple DNS records which can be in one of three sections:

  1. The "answer" section, which is for direct answers to DNS questions.
  2. The "authority records" (or "name server") section, which is for nameserver referrals.
  3. The "additional records" or "glue" section, which has any other DNS records which may be of interest.

These are some typical answers we can get for our "www.example.com" query above:

Note that NS referrals are done by name, not IP. DNS gives out a name like "www.example.net" for an answer instead of an IP like "10.4.2.1". [4] A DNS answer may, or may not, have the IPs for the NS referrals in the "additional records" section of the answer. If if does have the corresponding IPs for the NS records, it is called a "glued NS referral". If it does not have the corresponding IPs, it is a "glueless NS referral".

How Deadwood resolves a name

A simplified version of the method Deadwood uses to resolve a domain via recursion is as follows:

  1. Deadwood gets a request to resolve a given domain from a stub resolver
  2. Deadwood requests a domain from a root server.
  3. Deadwood gets an answer from that server.
  4. Deadwood looks at the answer.
  5. There are three types of answers Deadwood can get:
    1. A complete answer that answers the DNS question.
    2. An incomplete NS referral, which can either have glue or be glueless.
    3. An incomplete CNAME referral
  6. If the answer is a complete answer, Deadwood sends the answer back to the stub resolver.
  7. If the answer is an incomplete answer, Deadwood must send more queries to get a complete answer. I will detail this process below.

How Deadwood stops blind spoofing attacks

Deadwood's recursive resolver is written with the following philosophy: The only answers that Deadwood will place in the cache while resolving a name are either pointers to incomplete NS referrals, or the direct answer to the question originally given to Deadwood.

For example, if someone asks Deadwood "what is the IP for www.paypal.com", Deadwood will only add the following records to the cache while resolving www.paypal.com:

The information about what name servers to use for a given domain, say "example.com", can only come from one of the following two sources:

Information given by example.com's own name servers only affect names ending in "example.com"; they do not affect the name servers for example.com [5].

Handling "incomplete" answers

Deadwood does not store name server referrals as NS records nor incomplete CNAME referrals as CNAME records. Deadwood uses special records for storing these incomplete records.

In the case of either a glueness NS referral or an incomplete CNAME answer, Deadwood will create a sub-query to answer the query in question. This query is a new query that starts at the root to resolve a given name.

Choosing what to cache

Unlike other DNS resolvers, Deadwood does not indiscriminately add records to the cache that are seen in the additional records section of a DNS answer, even if the answers are "in bailiwick". This protects Deadwood from the Kaminsky DNS attack where someone can try and get "www.paypal.com" to point to a phishing page by sending queries like "0000001.paypal.com", "0000002.paypal.com", and so on, along with spoofed answers which have a very small chance of being accepted. The spoofed answers to the query have, in the additional records section, the DNS record "www.paypal.com has the IP 10.6.6.6" and "10.6.6.6" points to a phishing page. If someone tries this attack on Deadwood, a successful spoof will only affect meaningless records like "62f8ec94.paypal.com".

Linking names to IPs

In order to avoid needing to indiscriminately store records in the "additional records" section, Deadwood, when getting an incomplete NS referral, will look to see if any of the names in the authority records section have a corresponding IP for the name in the additional records section. If they do, said names are converted and stored in Deadwood's cache as IPs. If not, they are stored as glueless names.

For example, let us suppose we have an answer like this when we ask for www.example.com:

Deadwood converts this answer to look like this: See dwx_make_ns_refer() in DwRecurse.c for more details.

Conclusion

While more complicated, Deadwood's recursion algorithm provides, short of DNSSEC, the best DNS spoof protection.

Footnotes

[1] Note that "example.com" is always used for examples and is reserved when examples are needed in documents about DNS. example.net and example.org are other example domains.

[2] These are not real-world numbers; IPv4 IP numbers that begin in "10" are only used in internal networks and can not be reached from the Internet at large.

[3] The format of DNS queries is somewhat different; I am translating them in to English. It's like translating conversations from Spanish in to English. The binary format is described in RFC 1035.

[4] I agree with DJB that having NS referrals done by name instead of IP was a mistake in the design of DNS.

[5] example.com's name servers can also sub-delegate domain names to other name servers. For example, the example.com name servers can say "all names that end in 'sub.example.com' are handled by the name servers at 10.3.2.1"