[MaraDNS list] Another Deadwood workaround to add: easydns.{com|org|net|info} tarpit

[Sam Trenholme]

[EasyDNS: I am a the implementor of Deadwood, which is MaraDNS 2.0's
recursive DNS server.  Because of how my server works, the way your
DNS servers makes it difficult for Deadwood to resolve names your DNS
servers serve.]

easydns.{com|net|org|info} is a set of DNS servers that serves records
in such a way that it can put Deadwood in a tar pit trying to resolve
a domain name.

Here's what happens.  Let us suppose we want to resolve, say,
plosone.org, which is served by easydns.too-many-tlds.  We get a NS
referral in this form:

# Querying the server with the IP 199.19.57.1
# Question: Aplosone.org.
# NS replies:
plosone.org. +86400 ns ns1.easydns.com.
plosone.org. +86400 ns ns2.easydns.com.
plosone.org. +86400 ns remote1.easydns.com.
plosone.org. +86400 ns remote2.easydns.com.
plosone.org. +86400 ns ns1.plos.org.
# AR replies:
#ns1.plos.org. +86400 a 68.165.106.110

As it turns out ns1.plos.org is offline, so we need to chase a
glueless DNS record.  So, we start chasing, say ns1.easydns.com.  We
end up with something like this:

# Querying the server with the IP 192.5.6.30
# Question: Ans1.easydns.com.
# NS replies:
#easydns.com. +172800 ns dns3.easydns.org.
#easydns.com. +172800 ns dns1.easydns.com.
#easydns.com. +172800 ns dns2.easydns.net.
#easydns.com. +172800 ns dns4.easydns.info.
# AR replies:
#dns1.easydns.com. +172800 aaaa 2001:1838:f001:0:0:0:0:10
#dns1.easydns.com. +172800 a 64.68.192.10
#dns2.easydns.net. +172800 a 72.52.2.1

So, suppose we start chasing dns3.easydns.org.  We end up with
something like this from the .org servers:

# Querying the server with the IP 199.19.53.1
# Question: Adns3.easydns.org.
# NS replies:
#easydns.org. +86400 ns dns3.easydns.org.
#easydns.org. +86400 ns dns1.easydns.com.
#easydns.org. +86400 ns dns2.easydns.net.
#easydns.org. +86400 ns dns4.easydns.info.
# AR replies:
dns3.easydns.org. +86400 a 64.68.193.10
dns3.easydns.org. +86400 aaaa 2620:49:a:0:0:0:0:10

So now suppose Deadwood decides to start chasing dns1.easydns.info.
We end up with something like this from the .info servers:

# Querying the server with the IP 199.254.49.1
# Question: Adns4.easydns.info.
# NS replies:
#easydns.info. +86400 ns dns2.easydns.net.
#easydns.info. +86400 ns dns1.easydns.com.
#easydns.info. +86400 ns dns3.easydns.org.
#easydns.info. +86400 ns dns4.easydns.info.
# AR replies:
dns4.easydns.info. +86400 a 194.0.2.19
dns4.easydns.info. +86400 aaaa 2001:678:5:0:0:0:0:13

So, now, it's possible that we chase dns1.easydns.com ... which puts
us in a tarpit, since Deadwood doesn't cache dns1.easydns.com from its
AR record -- if we did cache dns1.easydns.com before, it would make
Deadwood more vulnerable to DNS spoofing attacks.

(To protect Deadwood from some kinds of DOS attacks, Deadwood will
only stay in a tarpit like this so long before giving up)

There are some ways to avoid this kind of tarpit:

* We can have heuristics that favor chasing glued records over
glueless records, which reduces the chance of falling in to this kind
of tarpit (as long as at least one name has glue)

* We can have a list of glueless records we have already chased in
trying to resolve a given name, and set up the resolution code to not
allow us to chase a name we have already chased before when trying to
resolve this query.

- Sam