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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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 email@example.com 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
A number of people have been asking for a way to check transaction ID randomness, in addition to source port randomness. OARC's porttest tool has now been expanded to also report on transaction IDs. To use it, issue a TXT query for the name txidtest.dns-oarc.net. For example, with dig:
Also note that in conjunction with this enhancement, the scoring critera for porttest and txidtest have been changed to match the web-based port test. The scoring is as follows:
Submitted by wessels on Mon, 2008-07-28 17:24 categories [ ]
The announcement in Jul 2008 of CERT VU#800113 made it clear that resolvers should use random source source ports when sending queries. Here at OARC, we crafted a special DNS name and server that you can query to learn whether or not your own resolver is using random ports. Use a DNS query tool such as dig to ask for the TXT record of porttest.dns-oarc.net:
You should get back an answer that looks like this:
Submitted by wessels on Thu, 2008-07-10 06:10
CERT and numerous vendors are making a major announcement today regarding a DNS protocol vulnerability that may enable cache poisoning of recursive resolvers. From the CERT page:
We can expect patches from most vendors that will implement randomization of query source ports. According to ISC, source port randomization only increases the difficulty of the attack, but does not entirely prevent it. The best prevention, they say, is to implement DNSSEC.
Here are some vendor announcements:
The vulnerability was discovered by Dan Kaminsky of IOActive.
Submitted by wessels on Tue, 2008-07-08 18:47
ARI Registry Services
Public Interest Registry
University of Maryland