NANOG36-NOTES 2006.02.13 talk 2 Duane Wessels, DNS cache poisoning

2006.02.13 talk 2
DNS cache poisoners
Lazy, Stupid, or Evil
Duane Wessels

During March/April 2005, SANS internet storm
center reported a number of DNS cache poisoning “attacks”
were occurring
Poisoned nameservers have bogus NS records for the com zone
SANS ISC theorizes it may have been a vector for spyware
Microsoft windows (most versions) and symantic firewall
products are affected.

Slides are on the website, BTW.

The poisoning attack:
an auth nameserver (where queries normally go) is
configured to return bogus and out of baliwick NS
auth records.

caching resolver receives and trusts those bogus referrals

future queries for names in poisoned zone go to the
bogus NS

dig +trace
will show the poisoned NS auth responses

which has
NS com.

so any caching resolvers may consider
authoritative for any unknowns in com zone.

Vulnerable implementations:
Windows NT (by default, SP4, can tweak it via reg)
Windows 2K, (by default, later fixed)
Windows 2003 (not by default, but easy to unfix)

Symantec gateway firewalls
SYM04-010 and SYM05-010 to Yahoo search and find more.

How to find poisoners?
start with a large list of DNS names or zones
discover set of auth servers for the zone by following
referrals on down from root
query each auth nameserver
compare the NS RR set in each reply to the previously-learned
referrals for parent zones
this technique only finds parent-zone poisoning.

February 2006 Survey
input list is about 6 million names from nameservers they
have access to.
Found 284 “poisoning” nameservers; returns bogus NS
entries for root or TLD.
. has 217
com 49
net 29
org 24
au 3
cc 2
cn 1
to 1
default 1

some nameservers poison more than one zone.

List of some poisoners on slide 12.

Never attribute to malice what can be adequately to be
explained by stupidity
Many of the nameservers that return bad referrals
appear to be companies in the DNS business
typo profiteers
others appear to be legitimate companies
they should know better
many of the names leading to poisoners are either expired
or parked

Is the sky falling?
with so many poisoners out there, why don’t we hear
more about the problem?

Most implementations don’t allow root to be poisoned

If you were surfing the web with poisoned DNS cache,
would you know it?

let’s simulate it…
for every bad referral found, we
put the nameserver’s IP address
go to
go to
see what you get., for example, happily pretends
to be is amusing, because their ads are
from google, even as they hijack it. at least does an HTTP redirect
doesn’t return any A record, so you at least know
something’s wrong.

More examples follow… “smart people use pairnic for DNS”…
Duane would beg to differ.
returns an amusing message that is clearly wrong,
blaming the clients for the traffic the DNS server
itself is causing.

Lazy, Stupid, or Evil
The admin is too lazy to put each domain delegated to
them into separate zone files. Instead, they create a
com zone and list A records for each delegation.

Laziness such as this is probably the source of most of
the poison out there.

(includes guess at what their zone file looks like)

Typos, combined with laziness, create an interesting
situation. Looks like is using the com zone
technique, but forgot to make the nameservers fully qualified.

Note that etc are legitimate DNS names and have
A records different than those returned by

Just forgot the dot after the trailing name on the NS

Our definition of an evil poisoning nameserver is one
where it answers queries with the wrong address, and
maybe proxies web traffic sent there so you get what
you (mostly) expect.

To help find them, give each source of poison an
evilness ranking from 1-5, with one point for each
issue below:
Returning bad referral
poisoning a TLD
Answering an A query for “important names”
Answering query incorrectly
Answering the query such that the web browser looks
like it might be correct DNS

A few fours, no fives.

Some of the poison sources that we find are actually
vulnerable implementations that hve been previously
poisoned by someone else.
Remember: authoritative nameservers should NEVER accept
recursive queries!!
Some NS records have non-FQDN names. The name “ns”
is a popular example.
It’s a good thing even the vulnerable implementations
don’t let the root zone become poisoned.

Bottom Line:
Several hundred misconfigured nameserves out there that
return bad referrals that can poison DNS caches
About 75% try to poison root zone, which usually has
no effect
Probably 90% of nameservers out there today are not
vulnerable to this type of poisoning
Most attempted poisonings
wessels at

Question from microphone: what do you do when you find
these poisoned nameservers?
And how often do you run the scripts to avoid false
Right now, he doesn’t do anything other than put it in
the database seen above. He tried contacting one, but
never got any answer back.
Contacting people is very hit or miss; hard to get
responses from people.
For second question, he’s run the survey a few times;
it takes about 10 days to go through the 6 million names,
so he might try running it once a month or so.
He doesn’t think of any cases of “false” positives; they
may fix their config, but if it was positive, it’s not

Applause, and onto the next talk.