« Are you Monitoring Your DNS? | Main | Avoid Risks: Manage your DNS Portfolio »

Monday, 06 January 2014

Harden your resolvers: protect your recursive DNS for you and for everyone else

The era of DDoS attacks will no doubt continue in 2014, yet operating recursive resolvers -- the name servers that process or resolve DNS queries on behalf of client devices or applications -- in a secure and reliable manner remains a critical yet commonly neglected administrative practice.

What is recursive DNS? It’s a process where a resolver asks other name servers for help in answering a query. This process begins when, for example, a user enters http://www.example.com into the address bar of her browser. A stub resolver operating on the user’s device will ask a recursive resolver for the IP address of the web page www.example.com. If the recursive resolver doesn’t know the answer, it asks a root name server for help. (Note that local or hints information provides root name server addresses to bootstrap this process.)

The root name server won’t know www.example.com but will helpfully refer the recursive resolver to a COM name server for help, and in this response the root name server will provide information about COM name servers. The stub resolver next asks a COM name server to help resolve www.example.com. Again, COM name servers won’t know www.example.com but will again helpfully refer the recursive resolver to a authoritative name servers for example.com. These name server hosts zone data for the example domain.

The recursive resolver now asks an example.com name server to resolve www.example.com and its patience is rewarded with a positive response containing the IP address of the web server. To reduce over-frequent recursion of commonly resolved names (e.g., google.com), administrators may configure recursive resolvers to keep a copy of positive responses in a local cache (for the time to live or TTL of the record).

From the above description, it's pretty clear how important recursive resolvers are in the name resolution process. Attackers routinely abuse or attack this iterative process for malicious or criminal purposes, so operators of recursive resolvers should configure and monitor against several classes of attacks:

Attacks that target you. Cache poisoning attacks take advantage of vulnerable name server configurations or implementation flaws to inject false information into your recursive resolver’s cache. Such attacks threaten anyone who uses your recursive resolver. Attackers may also target your resolver to disrupt name resolution by exhausting name server resources (CPU, memory, sockets). It is possible to configure or implement workarounds to mitigate these attacks (see adding entropy to request messages, data injection via additional section, weak transaction IDs, andKaminsky) but DNSSEC is the most effective means to prevent cache-poisoning attacks.

Attacks that target others. Attackers scan for and exploit open recursive resolvers and use these in reflection or amplification DDoS attacks. Such attacks threaten anyone targeted by an attacker. If you don’t exercise care in managing or monitoring your recursive resolvers, your organization may be an unwitting party to a criminal act.

Is your resolver open for attack? You can test whether any recursive resolver in your IP block is open or not at the Open Resolver Project, or you can run an NMAP script to do so. The Open Resolver Project also maintains a list of known open resolvers: this is probably not a list where you’d want any of your servers to appear.

Run recursive resolvers responsibly

Both US-CERT and CERT-BE are outstanding resources to learn how to run recursive resolvers responsibly. For example, you can use IP address-based authorization and the inbound interface (where queries arrive) to limit recursion to authorized clients (BCP 140), apply response rate limiting (DNS RRL), and use traffic filters to prevent source IP spoofing (BCP 38) on your networks. For mobile clients, BCP 140 recommends that you have clients connect to your network using a VPN, where they can use your recursive resolver. BCP 140 also suggests that you might run a local caching recursive resolver on mobile devices.

You can use the resources I’ve mentioned to ensure that you are running recursive resolvers responsibly, and that you’ve protected your infrastructure from cache poisoning and resource depletion attacks. As part of routine monitoring and network hygiene, you should also:

  • Verify that you have disabled open recursion on your authoritative name servers.

  • Verify that traffic with source addresses from private IP address space or from address blocks that are not allocated to you cannot exit your network.

  • Use event logs or real-time activity monitoring to confirm that your recursive resolvers are responding only to authorized users or applications, or observing or detecting suspicious query traffic (e.g. requests from unauthorized address space or requests that would cause your resolver to return atypical -- and large-- responses or unusual query, CPU, or memory consumption).

  • Run configuration checks on production recursive resolvers. REN-ISAC suggests using DNSCheck. DNSHealth at Pingdom runs similar tests.

Add these to your administrative routine and you will not only provide the best service to your users or customers, but you’ll prevent attackers from using your recursive resolvers to harm others.

 

This is the second post of a three part series on DNS and domain registration risk and protection:

Part I: Are you monitoring your DNS?

Part II: Harden your resolvers: protect your recursive DNS for you and for everyone else

Part III: Avoid Risks: Manage your DNS Portfolio

Originally posted 8/26/2013 at 21st Century IT under Don't Leave Resolvers Open to DDoS Attack.

Related articles
Emergence of DDoS as a Service (DDoSAAS)
Protecting the world from Your network
Domain Internet Groper: Using dig to access DNS zone data

Posted at 07:00 AM in Domain names and DNS |

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

The comments to this entry are closed.

Find me on Mastodon and Facebook

Spotlight Posts

  • FTC's proposed Trade Regulation Rule on Impersonation of Government and Businesses is important for #infosec
    M3AAWG comments on the FTC's proposed rule Trade Regulation Rule on Impersonation of Government and Businesses is available. I was one of the contributors to the comment. In the comment, M3AAWG "suggests additional regulatory solutions and best practices to complement the goals of this rule, such as clarifying the scope of the rule to include the use of domain names in impersonation schemes and the use of technologies that enable impersonation" and the important role that Whois plays in investigating impersonation and fraud. Several reports that my Interisle colleagues and I published are cited in the comment, along with the...
  • Cybercrime Information Center reports sharp increases in phishing attacks, unique domains reported in August-October 2022 time period
    A recent ebb in domain names reported for phishing created some euphoria in the domain industry. With phishing activity, as with tides, ebbs are invariably followed by flows. In their August- October 2022 Quarterly Phishing Activity, the Cybercrime Information Center observed a 40% increase in phishing attacks and a nearly 20% increase in unique domain names reported for phishing.
  • Cybercrime Information Center's YouTube Channel
    My colleagues and I at Interisle have created a YouTube channel to complement the quarterly reporting and studies of cybercrime we host at the Cybercrime Information Center. Our goal is to share, in a few minutes, the findings and insights from our research in a format that's easily accessible and shareable, informative, and entertaining. The inaugural videos provide 2-5 minute summaries of our annual Phishing and Malware Landscape studies. We'll continue to produce videos of our annual studies. If you like what you see, leave us a comment.
  • Malware Landscape 2022: unabated malware growth, continued exploitation of IoT devices
    My colleagues at Interisle and I have published a study, Malware Landscape 2022: A Study of the Scope and Distribution of Malware. The study, which analyzed 2.5 million records of distinct malware events from May 2021 to April 2022 collected by the Cybercrime Information Center, explains what malware was most prevalent, where malware was served from, and what resources criminals used to pursue their attacks.
  • New TLDs are coming #Dangerclose.
    A Domain Name Wire post, Time to pay attention to the next round of new TLDs, begins with an ominous: They’re coming. Eventually. While not as dramatic or enduring as Arnold Schwarzenegger's "I'll be back", the reporter cites policy activity at ICANN as evidence that new TLDs are coming. Eventually. In a September 2019 post, and in response to the ICANN memorandum, Readiness to Support Future Rounds of New gTLDs, I asked, Has enough been done to study and rectify the concentration of security threats in the new TLD space? In that post, I quoted correspondence from ICANN's security advisory...

Search

My Photo

Categories