The Domain Name System (DNS) is vital to the Internet, providing a mechanism for resolving host names into Internet Protocol (IP) addresses. Insecure underlying protocols and lack of authentication and integrity checking of the information within the DNS threaten the proper functionality of the DNS.
The DNS plays a critical role in supporting the Internet infrastructure by providing a distributed and fairly robust mechanism that resolves Internet host names into IP addresses and IP addresses back into host names. The DNS also supports other Internet directory-like lookup capabilities to retrieve information pertaining to DNS Name Servers, Canonical Names, Mail Exchangers, etc. Unfortunately many security weaknesses surround IP and the protocols carried by IP. The DNS is not immune to these security weaknesses. The accuracy of the information contained within the DNS is vital to many aspects of IP based communications.
DNS Functions
The DNS not only supports host name to network address resolution, known as forward resolution, but it also supports network address to host name resolution, known as inverse resolution. Due to its ability to map human memorable system names into computer network numerical addresses, its distributed nature, and its robustness, the DNS has evolved into a critical component of the Internet. Without it, the only way to reach other computers on the Internet is to use the numerical network address. Using IP addresses to connect to remote computer systems is not a very user-friendly representation of a system’s location on the Internet and thus the DNS is heavily relied upon to retrieve an IP address by just referencing a computer system's Fully Qualified Domain Name (FQDN). A FQDN is basically a DNS host name and it represents where to resolve this host name within the DNS hierarchy.
Threats to DNS Servers
The original DNS specifications did not include security based on the fact that the information that it contains, namely host names and IP addresses, is used as a means of communicating data. As more and more IP based applications developed, the trend for using IP addresses and host names as a basis for allowing or disallowing access (i.e., system based authentication) grew.
Another contributing factor to the vulnerabilities in the DNS is that the DNS is designed to be a public database in which the concept of restricting access to information within the DNS name space is purposely not part of the protocol. Later versions of the BIND implementation allow access controls for such things as zone transfers, but all in all, the concept of restricting who can query the DNS for RRs is considered outside the scope of the protocol.
The existence and widespread use of such protocols as the r-commands put demands on the accuracy of information contained in the DNS. False information within the DNS can lead to unexpected and potentially dangerous exposures. The majority of the weaknesses within the DNS fall into one of the following categories: Cache poisoning, client flooding, dynamic update vulnerability, information leakage, and compromise of the DNS server’s authoritative database.
· Cache Poisoning
Whenever a DNS server does not have the answer to a query within its cache, the DNS server can pass the query onto another DNS server on behalf of the client. If the server passes the query onto another DNS server that has incorrect information, whether placed there intentionally or unintentionally, then cache poisoning can occur. Malicious cache poisoning is commonly referred to as DNS spoofing.
· Rogue servers
Rogue DNS servers pose a threat to the Internet community because the information these servers contain may not be trustworthy. They facilitate attack techniques such as host name spoofing and DNS spoofing. Host name spoofing is a specific technique used with PTR records. It differs slightly from most DNS spoofing techniques in that all the transactions that transpire are legitimate according to the DNS protocol while this is not necessarily the case for other types of DNS spoofing. With host name spoofing, the DNS server legitimately attempts to resolve a PTR query using a legitimate DNS server for the zone belonging to that PTR. It’s the PTR record in the zone’s data file on the primary server that is purposely configured to point somewhere else, typically a trusted host for another site. Host name spoofing can have a TTL of 0 resulting in no caching of the misleading information, even though the host name is being spoofed.
· Denial of Service
DoS is accomplished in several ways. One takes advantage of negative responses (i.e., responses that indicate the DNS name in the query cannot be resolved). By sending back the negative response for a DNS name that could otherwise be resolved, results in a DoS for the client wishing to communicate in some manner with the DNS name in the query. The other way DoS is accomplished is for the rogue server to send a response that redirects the client to a different system that does not contain the service the client desires.
Another attack is to flood the DNS farm with requests (valid or not) with the intent to cause downtime to valid users trying to access these servers.
· Application Vulnerabilities
Needles to say that vulnerabilities to Operational Systems (Linux, Windows, Solaris, etc) or services (Windows DNS, Bind, etc) when exploited can cause DNS service disruption.
How to secure DNS Infrastructures
In this topics we’ll cover some ways that companies can increase the overall security for their DNS Infrastructures
· Segregate DNS Servers
This refers to the practice of separating DNS into an external and internal view. This provides a logical separation between the DNS information available to internal network clients/subscribers and what is made publicly available to the internet at large. DNS stores a wealth of information regarding the configuration of a network. Being able to enumerate this information is an invaluable resource for would-be attackers. By separating the publicly available information from that required by internal clients, adds a very critical layer of protection. This segregation can be accomplished in several methods, but separation on physical devices is the preferred.
It’s also recommend to a company to deploy servers to accommodate different functions. Authoritative servers, cache server, resolvers, forwarders. All of this functions should be splited in order to increase security/performance.
At last, deploy DNS services on dedicated servers or appliances.
· Recursion
In simple terms is the ability of a DNS server to answer client requests for domains which it is not authoritative for. Using a Segragate DNS deployment model, there are two primary sets of DNS servers, internal and external. Internal servers should be configured to perform recursion to service the requests of the internal network clients. However, external DNS servers should be explicitly configured to deny recursion. External DNS servers should solely answer requests for the domains for which they are the authoritative for. Public DNS servers which allow recursion have been recently exploited in as amplification machines in Distributed Denial of Service (DDoS) attacks. Not only does this consume valuable machine and bandwidth resources, but there also could be legal ramifications for an organization whose servers were exploited.
In simple terms, always configure your servers to answer only requests for valid users/networks
· Redundancy
As well all agree that DNS is a critical service it’s also certain that DNS can’t be allowed to be a single point of failure. It’s wise if possible to deploy multiple DNS farms with two or more primary DNS servers. These devices should be both geographic and carrier diverse. Having multiple DNS servers in the same physical location on the same internet connection provides very limited redundancy. A single carrier outage or fiber cut can instantly isolate all of your DNS servers. Instead, these should be distributed in across different geographical regions utilizing different internet providers. The use of load balancers/multiple DNS Servers can reduce the possibility of failure and increase the DNS Server Performance.
· NS records
The NS records for an organization's domain name provide public DNS servers with the information needed to find the authoritative name servers for that domain. These records are uploaded from your domain registrar to the Top Level Domain (TLD) DNS servers. As changes are made to your DNS infrastructure, its imperative that your NS records updated to reflect these changes.
· Zone transfers
Zone transfers are the ability for a slave DNS server to pull records from a master server to a slave. This allows you to host all of your zonefiles on a master machine and have them automatically propagate to slave machines after a change is made. The ability to transfer an entire zonefile for a domain also provides a easy way for would-be attackers to enumerate an organizations network. Because of this DNS servers should be configured to limit zone transfer requested to the IP addresses of designated slave machines.
· Deploy DNS Cache Servers
On loaded DNS farms, it’s wise to make use of DNS Caches in order to reduce the number of queries answered by your DNS. Normally this is done deploying a L2 (invisible) device in front of your DNS farm with the ability to identify and answer the most common queries. The overall results can be great if you think that a lot of requests are done against the same domains (google, yahoo, msn, etc). These queries will be answered by the DNS Cache reducing the number of servers need and increasing the performance.
· All MX records should have a corresponding PTR record
RFC1912 dictates that all mail gateways should have Reverse DNS entries configured. Many mail servers are configured to not accept email from gateways which don't have proper Reverse DNS entries.
· DNS server versions
To allow external users to actually identify running software versions often provide a would-be attacker with valuable information about the DNS application running on that machine. Published exploits corresponding to that specific version of the application can quickly be located and launched. For this reason, DNS server versions should be modified to obfuscate the actual running version number. Also, try to keep you OS and DNS Server application updated with the most recent version (stable) and patches.
· Deploy firewalls with appropriated rules
It’s very important to deploy a dedicated firewall solution to control who/whom can access the DNS servers and with what purposes. Take attention to the order where you’ll create the DNS control rules, try to fit these rules in the beginning of the chain (to improve firewall performance if you have a non “Best fit” firewall). Again when planning the rules, think about to use a “least privilege” approach. It’s always good.
It’s also important to design the system in order to support all traffic. Looks basic but many companies face serious performance issues in theirs DNS infrastructures and many times a overloaded firewall is the bottleneck.
· Deploy IPS systems
A Intrusion Prevention System can also increase DNS Security protecting the infrastructure against L7 attacks. I always recommend companies to try to deploy IPS systems dedicated to protect the DNS Infrastructure. Doing this you can select only DNS and OS related signatures improving detection and performance, and reducing false-positives.
· Deploy Specific DNS Protection Mechanisms
If per example a DNS server only answers A and MX type records, why allow NS records to reach this server? There are solutions in market that help to increase DNS Security protecting against DNS Protocol flaws and blocking non allowed queries to be made. It’s a very good way to increase security.
· DNSSEC
DNSSEC was designed to protect the Internet from certain attacks, such as DNS cache poisoning . It is a set of extensions to DNS, which provide:
a) origin authentication of DNS data, b) data integrity, and c) authenticated denial of existence.
These mechanisms require changes to the DNS protocol. DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). These new RRs are described in detail in RFC 4034.
It also adds two new DNS header flags: Checking Disabled (CD) and Authenticated Data (AD). In order to support the larger DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 support (RFC 2671).
Finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit (RFC 3225) so that a security-aware resolver can indicate in its queries that it wishes to receive DNSSEC RRs in response messages. By checking the signature, a DNS resolver is able to check if the information is identical (correct and complete) to the info on the authoritative DNS server.
DNSSEC services protect against most of the threats to the Domain Name System. There are several distinct classes of threats to the Domain Name System, most of which are DNS-related instances of more general problems, but a few of which are specific to peculiarities of the DNS protocol.
Note that DNSSEC does not provide confidentiality of data. Also, DNSSEC does not protect against DDoS Attacks.
DNS offers good security but can be almost impossible to deploy on carriers scenario. Actually we see some DNSSEC deployments on companies but none in carriers (at least I don’t see!!)
Conclusion
This paper is focused to present a overview about the DNS protocol, related threats and some ways to protect DNS Infrastructures against attacks. You can take all of this in order to increase your security (which is good) or choose some that you believe is more appropriated for your environment.
The important here is to understand that DNS is a critical service and must be treated as it.