Note: you can skip ahead to BIND fixes.
Recently the hosting company ISPrime became the victim of a DNS-based DDoS attack using spoofed source addresses. Some are calling it an amplification attack because the query ". IN NS" is quite small (47 octets) while an upward referral response is a bit larger (256 octets). For some additional information on this attack, see ISC SANS story #5713. OARC members can track this as incident #10780.
One interesting aspect of this attack is that the queries are apparently sent to authoritative nameservers only. In the past we have seen DNS-based attacks bounce queries through open resolvers. Its not clear why this attack is using authoritative nameservers. Perhaps because it is easy to get a list of nameservers if you already have a list of domain names and you can be reasonably sure that an authoritative nameserver will give some kind of answer.
The attack brings an old debate back into the light: What is an authoriative nameserver's appropriate response to a query that cannot be answered?
The configuration and/or implementation of some authoritative nameservers causes them to return an upward referral to the root zone. We recommend against this behavior for a number of reasons:
We feel that a REFUSED response code is better than an upward referral.
To find out if your authoritative nameservers return an upward referral, send them a query with the dig program:
$ dig @ns.example.net . NS
If you see a long list of ROOT-SERVERS.NET names and addresses, you have an upward referral. Click here to see an example.
Eliminating Upward Referrals
Submitted by admin on Thu, 2009-01-22 00:06 categories [ ]
Great news everyone! Matt Larson and Cricket Liu are resurrecting their Ask Mr. DNS advice column as a podcast:
Submitted by email@example.com on Mon, 2009-01-12 21:56
A number of years ago I did some simulations and measurements to show how different DNS resolvers distribute their queries to a set of authoritative servers (see PAM 2004 paper and NANOG29 presentation). At that time I tested BIND, Windows, DJBDNS, and CNS.
Recently someone asked if I know the behavior for PowerDNS. I ran a quick test against PowerDNS 3.1.7 that shows it having a strong affinity to a small number of authoritative servers. It seems to favor the nameservers with the lowest latency, which is not too surprising. In this case, it sent most of its queries to I- and F-roots, both of which are less than 1 ms away from the resolver host.
(click for larger image)
Submitted by firstname.lastname@example.org on Wed, 2008-12-31 19:45
While working on the TLDmon plugins a couple of weeks ago, I noticed that a certain query to b.iana-servers.net was consistenly failing:
$ dig +bufsiz=2048 @b.iana-servers.net XN--9T4B11YI5A RRSIG ; <<>> DiG 9.3.5-P2 <<>> +bufsiz=2048 @b.iana-servers.net XN--9T4B11YI5A RRSIG ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached
It was strange because queries to the same server for all of the other TLD hosted there work just fine:
$ dig +short +bufsiz=2048 @b.iana-servers.net XN--KGBECHTV RRSIG | wc 6 78 1794 $ dig +short +bufsiz=2048 @b.iana-servers.net XN--HGBK6AJ7F53BBA RRSIG | wc 6 78 1831
It was also strange because the problematic TLD works fine from hosts outside of ISC's network (which is where the OARC servers are located), and it works if the query is sent to a.iana-servers.net or c.iana-servers.net.
A tcpdump shows that the DNS reply message is fragmented and we only get the first fragment.
That this problem happens only (?) when querying from ISC's network seems to imply it is caused by something on ISC's network. But then why does it work when querying c.iana-servers.net? Why would the second fragment from c arrive, but not the fragment from b? Here's a tcpdump showing the correctly received second fragment from c.
I think it safe to assume that the fragment leaving b is the same, except with different values some TCP header fields (ip_sum, ip_id, ip_ttl, ip_src). Here's another tcpdump showing the fragment from b received outside ISC's network.
Note that both of these fragments are smaller (ip_len=31) than the minimum Ethernet payload size so they are padded out to 46 bytes.
Submitted by email@example.com on Tue, 2008-12-09 21:22 categories [ ]
In his Who Protects The Internet? article, Matt Rutherford mentions something near and dear to us as an example of
Submitted by firstname.lastname@example.org on Thu, 2008-12-04 17:24
On October 9, 2008, the U.S. National Telecommunications and Information Administration solicited public comments on the deployment of DNSSEC. Yesterday was the deadline for submission and today all of the comments have been published. Looks like slightly over 53 comments (of varying coherence) were received.
Submitted by email@example.com on Wed, 2008-11-26 00:29
Eric Osterweil gave an interesting talk at the NANOG44 DNSSEC BOF. His data (shown below) from SecSpider indicates a significant increase in signed zones right around the time that CERT VU #800113 was released:
(click for larger)
The blue line shows a large increase in the number of signed zones automatically discovered by the SecSpider crawlers in August 2008. A message to the dnssec-deployment list confirms this as well.
Submitted by firstname.lastname@example.org on Mon, 2008-10-13 22:02
Last week David Conrad of ICANN asked if I could make DSC show the EDNS buffer sizes advertized by clients. This is now available in DSC versions dated after 2008-08-22. Furthermore, the new version is running on the F-root collector nodes.
The breakdown of buffer sizes looked different than I remembered for recent DITL data, so I generated some graphs for the 2006 through 2008 DITL data (F-root nodes) using the same size ranges.
The trend is good news. Back in Jan 2007, 50% of queries did not indicate any EDNS support. 20% had bufsiz=2048, and 30% had bufsiz=4096. Now we have about 65% of queries with bufsiz=4096, while 35% still don't support EDNS.
Submitted by wessels on Mon, 2008-08-25 20:17
Date: Mon, 4 Aug 2008 18:22:46 -0400
ISC SIE has developed a tool for detecting cache poisoning attempts. it consists of two parts: ncaptool, the part which performs packet gathering, reassembly, and dns filtering; and mod_urstate, a message processing module which attempts to statefully detect unsolicited responses that may be indicative of cache poisoning attempts. specifically, the tool is designed to listen at the network layer of a recursive dns server, auditing the query-response stream between recursive and authoritative dns servers. when a potential cache poisoning attempt is detected, both the offending and original dns responses will be emitted into the output stream.
ncaptool and mod_urstate may be obtained via ftp:
the defaults are tuned for a dedicated IDS-style setup; e.g. fairly fast machines with >= 1 GB of memory and aggregated taps of dns traffic between recursive and authoritative nameservers. it ought to be possible to run it directly on a machine running a recursive nameserver, however.
we would like people to use it, and if possible provide feed back or contribute the data it generates to SIE.
mod_urstate is an ncaptool dns message parsing plugin that attempts to detect unsolicited dns responses that may be indicative of cache poisoning attempts. it does this by statefully tracking the application layer state of the dns transactions between recursive and authoritative dns servers. it gracefully handles query retransmissions due to client timeouts and byte identical responses from dns authorities.
two data collections are employed by mod_urstate:
when a query for a previously unknown tuple arrives, the query payload is cached so that subsequent byte identical queries may be discarded. when the first response for this query arrives, its payload is also cached. the vast majority of dns queries will only elicit a single response, so most cache entries will be quietly expired in fifo order.
however, in the usual case that a domain name's authoritative nameservers are reachable and functioning, a potentially successful cache poisoning attempt has these properties:
(it should be noted that certain types of benign dns responses unfortunately also match these criteria. it will be possible to filter these out in the post-processing / analysis phase.)
the mod_urstate module will output dns responses matching the above criteria. this output can then be analyzed to help answer the following questions:
it should be noted that an out of band method of distinguishing malicious from legitimate responses will be needed by the analyst.
Submitted by wessels on Fri, 2008-08-08 22:30
Timeline of Events
Tools for Testing and Monitoring
Data, Documentation, Papers, and Presentations
Submitted by wessels on Thu, 2008-07-31 22:36
ARI Registry Services
Public Interest Registry
University of Maryland