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

BIND

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

  options {
      directory "/etc/namedb";
      recursion no;
      allow-query { none; };
  };
  
  zone "example.net" {
      type master;
      file "master/example.net.db";
      allow-query { any; };
  };
  
  zone "." {
      type hint;
      file "named.root";
  };
  

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