DNS Security

Defending the Domain Name System

Allan Liska, Geoffrey Stowe

• Publisher: Syngress
• Year: 2016
• Print ISBN: 9780128033067
• eBook ISBN: 9780128033395
• Topic: Computer Science
• Subtopic: Computer Networking
• Index: Computer Science

DNS Security: Defending the Domain Name System provides tactics on how to protect a Domain Name System (DNS) framework by exploring common DNS vulnerabilities, studying different attack vectors, and providing necessary information for securing DNS infrastructure. The book is a timely reference as DNS is an integral part of the Internet that is involved in almost every attack against a network. The book focuses entirely on the security aspects of DNS, covering common attacks against DNS servers and the protocol itself, as well as ways to use DNS to turn the tables on the attackers and stop an incident before it even starts.- Presents a multi-platform approach, covering Linux and Windows DNS security tips- Demonstrates how to implement DNS Security tools, including numerous screen shots and configuration examples- Provides a timely reference on DNS security, an integral part of the Internet- Includes information of interest to those working in DNS: Securing Microsoft DNS and BIND servers, understanding buffer overflows and cache poisoning, DDoS Attacks, pen-testing DNS infrastructure, DNS firewalls, Response Policy Zones, and DNS Outsourcing, amongst other topics

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

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• About the Authors
• Acknowledgments
• Chapter 1. Understanding DNS
• Chapter 2. Issues in DNS security
• Chapter 3. DNS configuration errors
• Chapter 4. External DNS exploits
• Chapter 5. DNS reconnaissance
• Chapter 6. DNS network security
• Chapter 7. BIND security
• Chapter 8. Windows DNS security
• Chapter 9. DNS outsourcing
• Chapter 10. DNSSEC
• Chapter 11. Anycast and other DNS protocols
• Index