warning: Creating default object from empty value in /usr/local/apache2/sites/drupal5/modules/taxonomy/ on line 33.
Public Stories, etc

DO=1 Queries and small reply size limits at the Root

Recently, the U.S. Department of Commerece, ICANN, and Verisign announced their cooperation to get the DNS Root zone signed by the end of 2009.

Anyone who has had the pleasure of signing a DNS zone knows that the DNSSEC keys and signatures are much larger than most DNS resource records (and not particularly pretty, either). There is some concern among DNS operators that a signed root zone will lead to truncated responses and queries arriving over TCP, rather than UDP. RFC 4035 has something to say about DNSSEC and message sizes:

A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets.

DNS-OARC looked at EDNS data last year and found about 65% of queries used EDNS and a message size of 4096, a little less than 35% did not use EDNS at all, and a very small percentage used EDNS with an advertized message size of 512 bytes. More recently we've been asked to look at EDNS message sizes again and see how often a root server receives queries with the DO bit set and a message size of 512 bytes. The results of our analysis of the DITL 2009 data are below:

The first graph (above) shows distributions of queries received from three classes of clients: No EDNS, EDNS with the DNSSEC OK bit clear, and EDNS with the DNSSEC OK bit set. For example, in this plot we can see that "DO=1" queries were received from about one million different clients, the busiest of that group sent more than 10 million queries in this 72 hour period. The "No EDNS" group sent fewer queries overall, but there are more clients in that group.

The second graph shows, again, that about 65% of queries arrive with DO=1 and a buffer size of 4096. These DNS clients meet the requirements of RFC 4035 should be fine with respect to large DNSSEC responses. The blue area represents the approximately 31% of queries that lack EDNS. These should be fine also, since they are not requesting to be sent any DNSSEC records. However, the green area beneath the blue shows that about 2% of queries arrive with DO=1 and a message size of 512 bytes. If these clients switch to TCP, it could present a significant load to the root server system.

The final graph shows a distribution, similar to the first, for the clients in this "DO=1 512 bytes" category. In this 72 hour period, the root server received such queries from about 75,000 unique sources.

Submitted by admin on Tue, 2009-06-09 21:10 categories [ ]

Corporate Documents and Structure


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).


Name Position
Keith Mitchell President, Secretary
Submitted by admin on Wed, 2009-05-13 22:44 categories [ ]

Upward Referrals Considered Harmful

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:

  1. Upward referrals are generally useless. The resolver that is iterating through the space already knows where to start.
  2. A proper iterative resolver should consider the upward referral "out of bailiwick" and ignore the data anyway.
  3. The authoritative nameserver's root zone "hints" may become stale over time if not properly maintained, causing delivery of queries to decommissioned root server addresses.
  4. Upward referrals are known to cause "referral loops" that result in hundreds of useless queries.

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

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


  • Disable recursion on authoritative nameservers with this global option:
    recursion no;
  • If your BIND nameserver is a master for some zones, it needs the root hints to correctly send NOTIFY messages to the slave nameservers. To prevent upward referral responses, you can add this line to the global options:
    additional-from-cache no;

    Then, a query such as ". IN NS" should result in a REFUSED response.

    Alternatively, you can use access controls to accomplish the same thing by denying all queries globally and then allowing queries for each zone. Click here to see an example.

  • If your nameserver is authoritative and acting only as a slave, it doesn't really need the root hints because it won't send NOTIFY messages. However, simply removing the root hints from your configuration does not solve this problem because BIND comes with the root hints built into the source code. Therefore, you should still use one of the above techniques.
  • If your nameserver is both authoritative and caching, you really should separate the two functions. Caching nameservers are susceptible to poisoning and other types of attacks. You don't necessarily need separate hardware for each. You might need to use separate IP addresses, or possibly configure the authoritative nameserver to use an external address while the caching nameserver uses an internal address.
  • If you have a caching-only nameserver, make sure that it has proper access controls in place to prevent its abuse by external users.
Submitted by admin on Thu, 2009-01-22 00:06 categories [ ]

dig +bufsiz=2048 XN--9T4B11YI5A RRSIG

While working on the TLDmon plugins a couple of weeks ago, I noticed that a certain query to was consistenly failing:

$ dig +bufsiz=2048 XN--9T4B11YI5A RRSIG

; <<>> DiG 9.3.5-P2 <<>> +bufsiz=2048 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 XN--KGBECHTV RRSIG | wc
       6      78    1794
$ dig +short +bufsiz=2048 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 or

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 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 on Tue, 2008-12-09 21:22 categories [ ] -- Check your resolver's transaction ID behavior

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 For example, with dig:

$ dig +short TXT
" is GREAT: 26 queries in 2.7 seconds from 26 txids with std dev 20574.11"

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 hosted mailing lists

OARC operates a number of mailing lists for its members, for other groups, and for the public.


A closed list for OARC members only.
Users are automatically subscribed based on the information in the portal database. Posts are accepted from list members only and are not normally held for approval. All OARC-related topics are appropriate.
To read the members archives, you'll need to know your mailman password. If you don't know your mailman password, visit the listinfo page and enter your email address at the bottom to receive a password reminder.


An open public forum for informal reporting, tracking, resolving, and discussing DNS operational issues including outages, attacks, errors, failures, and features. Discussion of non-ICANN root systems is explicitly off-topic.
Subscriptions are open to anyone and will be approved by a list moderator. Posts are accepted from list members only and are not normally held for approval. Participants with a history of off-topic posts will be moderated.
Visit the dns-operations page to subscribe and read the archives.


Mailing list for co-ordinating operators of anycasted AS112 DNS servers for RFC1918 in-addr queries.
List participants must be AS112 server operators. Posts are accepted from list members only and are not normally held for approval. Archives are publicly readable.
Visit the as112-ops page to subscribe and read the archives.

Private Lists

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 [ ]

DNSSEC Walker - Similar to "dnswalk" but for use with DNSSEC


Similar to "dnswalk" but for use with DNSSEC, of course.

Submitted by admin on Fri, 2008-01-11 19:10 categories [ ]

Active Measurement of Anycast DNS

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 [ ]

Quarterly 48-hour tcpdump

The following OARC members participate in quarterly 48-hour data collection:

ISC (F-root)
RIPE (K-root)
Cogent (C-root)
NASA (E-root)

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 [ ]