DNS Security: Defending the Domain Name System

possible.

Chapter 1

Understanding DNS

Abstract

This chapter provides a history of the DNS protocol and an explanation of how DNS came to be as well as how it is set up today. It will give readers a quick and dirty guide to how DNS operates in theory and in the real world.

Keywords

DNS; root servers; RFC; DDoS; recursive servers; zone files; malware; hosts.txt

Information in This Chapter

• DNS History

• The Root

• Recursive and Authoritative Services

• Zone Files

• Resource Records

Introduction

Prior to discussing ways to secure DNS infrastructure, it is important to understand what DNS is, and what needs to be secured. DNS has traditionally been an afterthought at many organizations. Often times initialization and maintenance of an organization’s DNS infrastructure falls to the people responsible for the setting up and patching webservers, or configuring and managing the network devices. They are frequently untrained on the intricacies of DNS and are reliant upon information they can glean from various web sources some of which are great and others well, not so much.

From a security perspective, this can be extremely problematic. How can someone be expected to effectively secure a solution they do not understand? Simply put they cannot, without sound understanding of the principles, an administrator cannot be expected to comprehend the nuances associated with securing the system, let alone keeping up with and realizing the risks posed by the volume of vulnerabilities published on this topic alone annually. Given the large number of DNS vulnerabilities published every year and the number of ways an administrator can expose a DNS infrastructure to attack, it is imperative that those who manage DNS installations understand the principles behind DNS, in order to be able to properly secure those installations.

The best place to start is by defining DNS. The acronym DNS stands for Domain Name System, although some use DNS to refer to Domain Name Servers. DNS is a redundant, hierarchical, distributed database that is used to pass information about domain names. The acronym disagreement demonstrates the difficulty anyone would have in documenting DNS. If people cannot even agree on what the acronym stands for how can they agree on anything else? As you progress through this book, you will note that DNS administrators rarely agree on anything.

The metaphor most often used to describe DNS is a tree. DNS has a root, and the various Top Level Domains (TLDs) are similar to branches that shoot off the root. Each branch has smaller branches, which are Second Level Domains, and the leaves are Fully Qualified Domain Names (FQDNs), sometimes referred to as hostnames. Do not get the idea that this tree is a peaceful Palm Tree or a strong Oak. This is a monstrosity of a tree, planted in cement with roots ensnarling each other and branches spread in every direction, that often feels like it is held together by force of will more than anything else. If DNS is a tree, it is more like the Banyan Tree, in Lahaina, Maui. The Banyan was 8 ft tall when it was first planted in 1873 now it is more than 60 ft tall and it has spread over 2/3 of an acre. Much like DNS, the Banyan Tree has grown so large by dropping new roots from its branches, those roots go on to become new trunks in the Banyan Tree. The complete flow of a DNS query from workstation to response is outlined in Fig. 1.1.

Figure 1.1 A stylized version of the traffic flow of a DNS query.

DNS is not only important to the functionality of the Internet, but also important to the functionality of almost any reasonably sized organization. A poorly configured DNS server can impact an entire organization and a poorly secured DNS server or Domain provides an attacker an easy opening into an organization’s network. Even if an organization is properly protected, DNS can still be used as an attack vector against an organization.

This chapter covers the basics of DNS—it is designed as a very high level overview of the DNS process and does not get overly bogged down in details. Starting with the beginnings of the DNS it then moves onto the root system, details the different types of DNS servers, and reviews how DNS servers speak to each other, and what type of information is communicated between servers.

DNS History

When most people think of Internet luminaries Bill Gates, Steve Jobs, Marc Andreessen, and Mark Zuckerberg come to mind. Certainly these people have made great contributions to the progression of the Internet (or its downfall, depending on who you ask), but there are a whole group of people whose impact has been much more profound. These contributions did not necessarily result in multimillion dollar Initial Public Offerings (IPOs), but without them the Internet would not be what it is today.

The Hosts.txt File

The Internet is sometimes compared to an organism. Like any organism it evolves over time and also like an organism it leaves traces of its former existence behind. In this case remnant of the precursor to DNS, the hosts.txt file, is still found on many systems.

To understand why DNS became necessary, take a look at the file /etc/hosts on UNIX systems or %systemroot%\system32\drivers\etc\hosts.txt in Microsoft Windows or the hosts.txt file on Android devices. The format of all these files is the same:

IP Address Computer Name Comment

These files are used to map IP Addresses to hostnames, in other words they serve the same function that DNS does. These files were the precursor to DNS. Prior to the introduction of DNS, the host file was used as the primary method of sharing data about hostnames.

Two events helped bring about the birth of the host file. In December of 1973, and outlined in conjunction with RFC 592, an official host naming convention was established. Numbers, letters, and dashes were the only characters allowed in hostnames, parentheses were allowed as part of network names.

Once the list of hostnames (all 81 of them!) had been gathered, the next step came with RFC 606 and RFC 608. These RFCs outline the creation of a new centralized file, called HOSTS.TXT, which could be downloaded via FTP so that all administrators connected to the ARPANET would have the same data regarding hostnames.

It is interesting to note that while this idea makes a lot of sense in retrospect, the author of RFC 606, L. Peter Deutsch, felt compelled to add the following disclaimer:

I realize that there is a time-honored pitfall associated with suggestions such as the present one: it represents a specific solution to a specific problem, and as such may not be compatible with or form a reasonable basis for more general solutions to more general problems. However, (1) this particular problem has been irking me and others I have spoken to for well over a year, and it is really absurd that it should have gone unsolved this Long; (2) no one seems particularly interested in solving any more general problem.

The first hosts.txt file went online March 25, 1974 and was announced by RFC 627. Prior the release of the first hosts.txt file, another DNS institution was introduced. RFC 623 and RFC 625 discussed placing the hosts.txt file on an additional server. If the primary server, OFFICE-1, was unavailable, a host could retrieve the file from the secondary server. Again, this is very similar to the way DNS works today.

Mail Problems

ARPANET continued in this manner for more than a decade. As more organizations connected to this Internet, it became obvious that there were some issues with this system, particularly when it came to most commonly used application: Computer Mail.

The problem with computer mail was that too many people were using the system, so it became difficult for postmasters to manage mail messages. The format of mail addresses was based on the addresses in the host file. So, if someone wanted to send a message to Allan Liska at Example Corp, the format would be something along the lines of liska@example or aliska@example. This is fine, as long as there is only one computer to which users at the originating organization are connected. But ARPANET was growing in popularity, and computer users were not isolated to one department or even to one campus. There were ARPANET users spread out across organizations and in multiple locations.

As the popularity of ARPANET increased postmasters we having to add mail servers in multiple locations. Each one would have to be assigned a unique hostname, which would then have to be added to the hosts.txt file. If Allan Liska is located at Example Corp’s Virginia office, a hostname for that office would have to be created. Instead of sending mail to liska@example, it would have to be sent to liska@exampleva. On the other hand, if Bruce Liska was in Example Corp’s California office, mail would have to be sent to liska@exampleca. This could create a tremendous amount of confusion—if the sender was not sure what office a person was located in, or what the various naming conventions were it was very easy to misaddress mail.

This created a problem that postmasters had to deal with. After all, once a person has been exposed to electronic mail, he cannot be deprived of it. On January 11, 1982 a meeting was held to discuss this mail problem, among others, and to develop a solution. Some of the people in attendance at the meeting included Vint Cerf, Bill Joy, Dave Crocker, Paul Mockapetris, David Mills, and of course Jon Postel.

The results of the meeting were published as RFC 805 Computer Mail Meeting Notes. The banal title masks the importance that this document had on DNS. The solution proposed during the meeting was a combination of an addition to the current mail format and the incorporation of Internet Domain Names proposed by David L. Mills in RFC 799.

The basic proposal was that the format of the electronic mail address system would have to be expanded by adding two levels, called nodes, to the current address scheme. In addition to address at host, the proposal would add the nodes organization and domain to the address. In the example above, if you wanted to send mail to Allan Liska at Example Corp the format would shift to address at hostname node separator company node separator domain, for example, allan@mailserver.example.in (.in for an Internet Address).

This system would make it a lot easier for geographically dispersed organizations to manage mail for users. Addresses could be broken down geographically. If someone wanted to send mail to Allan Liska at Example Corp’s Virginia office, the address could be allan@va.example.in; on the other hand, Bruce Liska in the California office would be something like bruce@ca.example.in. Obviously, this would give organizations a lot more freedom and make life easier for mail administrators. Of course, it also meant having to rewrite mail programs so they could handle multiple nodes.

In March of 1982 the first HOSTNAMES server came online. This server did not support domain queries. It was primarily used to share information about Networks, Gateways, and Hosts, but it used the same format the domain queries would eventually follow.

RFC 819 and 920

RFC 819 marks a major leap forward in domain evolution; it outlines the domain structure and laid out a foundation for a DNS infrastructure. Jon Postel and Zaw-Sing Su wrote RFC 819, entitled The Domain Naming Convention for Internet User Applications and released it in August of 1982.

The RFC is really a framework for a DNS infrastructure. It does not focus on the specifics, allowing those to be filled in by others. This is one of the great things about the DNS protocol: it has always been less rigid than other protocols, making it very adaptable to change. This flexibility also makes DNS a target for those who develop standards. They often want to create new extensions within DNS or attempt to use the protocol in ways for which it was never intended.

On the surface, the next year was quiet, in terms of DNS—the framework set out in RFC 819 was being refined and molded. In 1983 three RFCS were released in rapid succession. RFC 881, RFC 882, and RFC 883 laid out the framework for the current DNS infrastructure. These RFCs shaped the way DNS works today. RFC 882 and RFC 883, written by Paul Mockapetris, were especially important because they discussed the way DNS lookups would be performed and they provided an overview of delegation, which is the hallmark of DNS and one of the reasons DNS has been so successful.

Once discussion of the DNS design had finished—which took almost another year—RFC 920 was released. RFC 920, released in October 1984, laid out the requirements for actually implementing DNS ARPANET-wide and what steps would have to be taken. RFC 920 also finalized the initial list of TLDs: ARPANET (which was to be a temporary TLD), .GOV, .MIL, .EDU, .COM, .ORG and the two-letter country code domains.

Those involved in initial creation of DNS wanted to get it set up quickly, and RRC 920 outlined a fast pace. From the release of RFC 920 everything was ready to be launched and new domains registered within 6 months. In fact, the first non-TLD domain registered was NORDU.NET on January 1, 1985.¹ The Defense Information Systems Agency, which now controlled ARPANET, awarded the maintenance of the root infrastructure to the Stanford Research Institute and the modern DNS infrastructure was born.

On to Commercialization

DNS proceeded pretty much unchanged for the next several years. In October of 1992 the National Science Foundation (NSF)—or more specifically NSFNet, which had taken ownership of ARPANET in 1986—awarded a management services contract to Network Solutions Inc. This was huge change as it moved control of DNS from the, largely, academic community to the private sector.

Up until 1995 anyone who wanted a domain name was able to register one. As more people saw the commercial value in the Internet, some began registering hundreds of domains, thinking that they might be valuable in the future. To stop the spread of this practice, and to recoup some of the costs of maintaining the DNS infrastructure, Network Solutions, with the approval of the NSF, began charging a fee to register domain names. The initial fee was $100 for 2 years, with $30 of that money going to support the Internet infrastructure.

This coincided with the ideas of the US government at the time, which had a mandate to privatize and increase competition on the Internet. The Department of Commerce was especially interested in DNS and had solicited comments from the public about ways to help them fulfill President Clinton’s mandate.

In 1998 the government released a paper outlining moving control of DNS from the exclusive domain of Network Solutions to an independent organization that would foster competition and encourage further use of the Internet. From this paper, the Internet Corporation for Assigned Names and Numbers (ICANN) was eventually born.

ICANN took over the management of the root name servers in 1999 and opened up the registration process. Companies meeting a set of requirements are allowed to register domains on behalf of the general public. These domains are entered in the various TLD databases and all ICANN-approved registrars are able to register the Generic TLDs.

The Root

The heart of the DNS is the root, or more appropriately, the multiple roots. The root systems maintain authoritative data about domains and help direct requests to the proper servers. There are two different types of root servers that are used in DNS: the root servers and the TLD roots.

Generally, when people talk about root servers, they are referring to the root servers queried by recursive name servers (discussed in the next section). The 13 root name servers are dispersed around the world, maintained by different organizations and are on different networks.

In addition to the root name servers, each TLD also has its own root server or servers. This root server is authoritative for information about the specific TLD, the root server of a domain is the top node in the domain tree and is represented by a . which trails the domain name. The trailing . is generally not displayed outside the realm of DNS, but it is important to remember it is there. So, the domain example.com is properly presented as:

example.com.

The TLD root servers are not queried directly. Instead, the root servers direct queries to these servers as requests are processed. Obviously, this makes the functioning of the root name servers critical to the continued operation of the Internet. If the root name servers were taken off-line typical Internet communication would eventually stop. This is not to say that all communication on the Internet would stop, routing and other services that do not rely on DNS would continue functioning as expected. But services like mail, FTP, and HTTP would quickly become unusable as they rely so heavily on