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