DNS-OARC 24th Workshop, Buenos Aires, Presentations
Public Stories, etc
OARC, Inc. is a nonprofit corporation formed under the laws of the State of Delaware. The corporation was created June 30, 2008 (file number 4569769).
Submitted by admin on Wed, 2009-05-13 22:44 categories [ ]
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 [ ]
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 [ ]
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 [ ]
OARC operates a number of mailing lists for its members, for other groups, and for the public.
OARC also hosts a number of private mailing lists as a service to its membership. Any OARC member can request the creation of a private mailing list whose charter is related to OARC's mission. Members may view information about OARC's private lists.
Submitted by wessels on Tue, 2008-07-08 23:50 categories [ ]
One of OARC's activities is to convene periodic workshops, usually focused on DNS research and operations.
Please see the hosting page if your organization is considering hosting an OARC workshop.
Submitted by admin on Tue, 2008-01-15 23:19 categories [ ]
Submitted by admin on Fri, 2008-01-11 19:10 categories [ ]
OARC member Yuji Sekiya, from WIDE, presents work related to active measurement of the anycast instances of root DNS servers. Follow the attachment link below to view slides for the presentation.
Submitted by Anonymous on Tue, 2006-03-21 06:13 categories [ ]
The following OARC members participate in quarterly 48-hour data collection:
Root and TLD operators have very different network topologies and methods by which they provide DNS service. Such details may be useful to researchers studying this data. Links to specific details such as anycast vs. unicast routing and addressing, global vs. local nodes, geographic location, and autonomous systems are provided below for each member that submits data.
Submitted by Anonymous on Wed, 2006-03-15 17:12 categories [ ]
The following links provide information for members to upload various types of data to the OARC catalog. Organizations that wish to only share data with OARC (but have no access to member data/services), see the OARC Participation Agreement.
Click here for instructions on uploading PCAP files from quarterly 48-hour tcpdump runs.
Click here for instructions on uploading DSC statistics via SSH.
Submitted by Anonymous on Thu, 2006-03-09 18:53 categories [ ]
Public Interest Registry
Verizon Digital Media Svs
Integrated S and T
Tel Aviv University