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 , they may get an answer like "www.example.com's A record is the IP 10.1.2.3"  .
DNS replies can have multiple DNS records which can be in one of three sections:
These are some typical answers we can get for our "www.example.com" query above:
How Deadwood resolves a name
A simplified version of the method Deadwood uses to resolve a domain via recursion is as follows:
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:
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:
While more complicated, Deadwood's recursion algorithm provides, short of DNSSEC, the best DNS spoof protection.
 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.
 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.
 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.
 I agree with DJB that having NS referrals done by name instead of IP was a mistake in the design of DNS.
 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"