Can DNS Be Considered Secure?

In April, a Dutch hacker was arrested for what is being called the biggest distributed denial of service attack ever seen. The attack was perpetrated on Spamhaus, an anti-spam organization, and according to ENISA, the European Union’s IT security agency, the load on Spamhaus’s infrastructure reached 300 gigabits per second, three times the previous record. It also caused major Internet congestion, and jammed up Internet infrastructure worldwide.

Of course, DNS attacks are hardly rare. But while the hacker in the Spamhaus case only meant to harm his target, the larger ramifications of the attack also pointed to what many are calling a major flaw in Internet infrastructure: the Domain Name System. As a result, recent attacks on core DNS infrastructure have left technicians and businessmen alike scrambling for solutions. So what about you? It’s important to know what options you have for bolstering your own business’s DNS infrastructure as well as how the DNS root servers operate. So let’s take a look at some of the problems, and what businesses can do to protect themselves. (Learn more about DNS in DNS: One Protocol to Rule Them All.)

Existing Infrastructure

The Domain Name System (DNS) is from a time the Internet has forgotten. But that doesn’t make it old news. With the ever-changing threat of cyberattacks, DNS has come under a great deal of scrutiny over the years. In its infancy, DNS offered no forms of authentication to verify the identity of a sender or receiver of DNS queries.

In fact for many years, the very core name servers, or root servers, have been subject to extensive and varied attacks. These days they are geographically diverse and operated by different types of institutions, including government bodies, commercial entities and universities, to maintain their integrity.

Alarmingly, some attacks have been somewhat successful in the past. A crippling attack on the root server infrastructure, for example, occurred in 2002 (read a report about it here). Although it didn’t create a noticeable impact for most Internet users, it did attract the attention of the FBI and the U.S. Department of Homeland Security because it was highly professional and highly targeted, affecting nine of the 13 operating root servers. Had it persisted for more than one hour, experts say, the results could have been catastrophic, rendering elements of the Internet’s DNS infrastructure all but useless.

To defeat such an integral part of the Internet’s infrastructure would give a successful attacker a great deal of power. As a result, significant time and investment has since been applied to the issue of securing the root server infrastructure. (You can check out a map showing root servers and their services here.)

Securing DNS

Aside from the core infrastructure, it’s equally important to consider how robust your own business’s DNS infrastructure might be against both attack and failure. It’s common for example (and stated in some RFCs) that name servers should reside on entirely different subnets or networks. In other words, if ISP A has a full outage and your primary name server falls offline, then ISP B will still be serving your key DNS data to anyone requesting it.

Domain Name System Security Extensions (DNSSEC) are one of the most popular ways that businesses can secure their own name server infrastructure. These are an add-on to ensure that the machine connecting to your name servers is what it says it is. DNSSEC also allows authentication for identifying where the requests are coming from, as well as verifying that the data itself hasn’t been changed en route. However, due to the public nature of the Domain Name System, the cryptography used does not ensure confidentiality of the data, nor does it have any concept of its availability should parts of the infrastructure be suffering a failure of some description.

A number of configuration records are used to provide these mechanisms including RRSIG, DNSKEY, DS and NSEC record types. (For more info, check out 12 DNS Records Explained.)

RRISG is used whenever DNSSEC is available to both the machine submitting the query and the one sending it. This record gets sent along in hand with the requested record type.

A DNSKEY containing signed information might look like this:

ripe.net has a DNSKEY record 257 3 5 AwEAAXf2xwi4s5Q1WHpQVy/kZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk+Y7vZCvSN1AcYy0/ZjL7cNlkc3Ordl2DialFHPI6 UbSQkIp3l/5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i958WZJ6LI0pOTNK+BIx8u98b+EVr7C08dPpr9V6Eu/7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtmJxDT067oJoNBIK+gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XSCm5sNxrRk=

The DS, or delegated signer, record is used to help authenticate the chain of trust so that a parent and a child zone may communicate with an added degree of comfort.

NSEC, or next secure, entries essentially jump to the next valid entry in a list of DNS entries. It is a method that can be used to return a non-existent DNS entry. This is important so that only configured DNS entries are trusted as being genuine.

NSEC3, an improved security mechanism to help mitigate dictionary-style attacks, was ratified in March 2008 in RFC 5155.

DNSSEC Reception

Although many proponents have invested in deploying DNSSEC it is not without its critics. Despite its ability to help avoid attacks such as man-in-the-middle attacks, where queries can be hijacked and incorrectly fed at will unwittingly to those generating DNS queries, there are alleged compatibility issues with certain parts of the existing Internet infrastructure. The main issue is that DNS usually uses the less bandwidth-hungry User Datagram Protocol (UDP) whereas DNSSEC uses the heavier Transmission Control Protocol (TCP) to pass its data back and forth for greater reliability and accountability. Large parts of the old DNS infrastructure, which get peppered with millions of DNS requests 24 hours a day, seven days a week, may not be capable of the increase in traffic. Even so, many believe that DNSSEC is a major step toward securing Internet infrastructure.

While nothing in life is guaranteed, taking some time to consider your own risks might prevent many costly headaches in the future. By deploying DNSSEC, for example, you can increase your confidence in parts of your key DNS infrastructure.