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: 

* The "answer" section, which is for direct answers to DNS questions.

* The "authority records" (or "name server") section, which is for 
  nameserver referrals.

* 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: 

* A direct answer to their question in the answer section, such as 
  "www.example.com has the IP 10.1.2.3"

* What I call an "incomplete CNAME answer"; this is an answer like 
  "www.example.com has the CNAME www.example.net". CNAME is a DNS 
  record used for aliases; if, say, www.example.com has the CNAME 
  www.example.net, this means that www.example.com's IP is whatever 
  www.example.net's IP is.

* What I call an "incomplete NS referral"; this is an answer which has 
  no records in the answer section, but has referrals to other DNS 
  name servers in the "authority records" section, and, ideally, 
  IPs for those name servers in the "additional records" section.

* What is sometimes called a "NXDOMAIN" answer. This is an answer 
  which means "this name does not exist". Its format is no records 
  in the answer section, and a record type called a "SOA" record in 
  the "authority records" section.

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: 

* Deadwood gets a request to resolve a given domain from a stub 
  resolver

* Deadwood requests a domain from a root server.

* Deadwood gets an answer from that server.

* Deadwood looks at the answer.

* There are three types of answers Deadwood can get:

* A complete answer that answers the DNS question.

* An incomplete NS referral, which can either have glue or be 
  glueless.

* An incomplete CNAME referral

* If the answer is a complete answer, Deadwood sends the answer back 
  to the stub resolver.

* 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 IPs of the name servers for anything ending ".com" that doesn't 
  otherwise have a name server. These IPs can only be set by the 
  root server IPs (which are either the default ICANN root servers 
  built-in to Deadwood or specified in ones dwood3rc file).

* The IPs of the name servers for anything ending in "paypal.com" can 
  be added by either the root name servers or the name servers 
  delegated by the root servers as being the name servers for 
  ".com". No other servers are allowed to assign names to 
  "paypal.com".

* A name server delegation must be part of the domain asked for. If 
  someone asks for "random-name-00000001.com", any answers received 
  will only affect ".com" (if they come from the root servers) or 
  "random-name-00000001.com" (but only if they come from the .com 
  servers). See dwx_string_bailiwick_query() in DwRecurse.c

* The IP for "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: 

* The root name servers

* The name servers designated to serve ".com" domains.

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: 

* Authority section: A name server for example.com is ns1.example.com

* Authority section: A name server for example.com is ns2.example.com

* Authority section: A name server for example.com is ns.example.net

* Additional section: ns1.example.com has the IP 10.2.2.1

* Additional section: ns2.example.com has the IP 10.2.2.2

Deadwood converts this answer to look like this: 

* This record contains name servers for example.com

* 10.2.2.1 is a glued name server

* 10.2.2.2 is a glued name server

* ns.example.net is a glueless name server

See dwx_make_ns_refer() in DwRecurse.cfor 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 DJBthat 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"



