The domain name provides a memorable substitute for a numerical IP address. Many people think of domain names as standing for websites or as a “home address” for someone’s email. DNS itself cannot associate a domain name with a personal web page or email account. DNS uses a domain name to retrieve the numerical IP address of the host providing web service or email service.

Many domain registrars provide a service to link a registered domain name to an existing email account or to a web page hosted on a larger site. The registrars implement special hosts to provide this service. The domain name’s owner supplies information about their existing email address or web page, and the registrar’s server redirects email and web transactions to the appropriate destination. This provides an “alias” for an email address or website.

When handling a website alias, the registrar translates the domain name into a link to a particular web page. For example, Kevin might not have his own host and global IP address. Instead, Kevin has a personal website on “comcast.net” and he wants “einsec.com” to point to those pages. Using a web-based interface provided by the registrar, Kevin supplies a link to his Comcast home page. After that, the registrar automatically redirects any visit to “einsec.com” to Kevin’s home page at comcast.net.

This allows Kevin to use a personalized domain name with web space he already owns. Many domain registrars also offer web services and will automatically link a personal domain name to the customer’s rented web space.

Registrars often also provide email aliases. For example, Kevin has an email account at school, but he wants to also use the email address “[email protected].” To do this, the registrar provides another web-based interface to establish email forwarding. Kevin selects his domain name “einsec.com” and gives it the user name “kev.” Then he enters his school email address as the email destination.

Whenever the registrar receives email for “einsec.com,” it looks at Kevin’s email forwarding requests. If the user name on the email is “kev,” then the registrar retrieves Kevin’s school email address and forwards the email there.

Most computer systems have a keyboard command nslookup that uses the resolver to look up domain names. The command works in Unix command shells available in MacOS and Linux and in the MS-DOS command shell on Windows. Unlike the nmap command examined earlier, nslookup doesn’t take a list of options and parameters. Instead, it starts its own command shell that collects domain names to look up.

The following is an example using nslookup on MS-DOS. We underline the commands typed by the user. First, the user Kevin types the nslookup command itself. The program responds by typing the name and IP address of the default name server. In private networks behind a firewall, this will be the local address of the network’s gateway. Because this server address has no domain name, the “Server” name is “Unknown.” Then nslookup types a “>” to prompt the user for a domain name:

Kevin types in the domain name to retrieve its IP address:

Nslookup responds with a short report of the domain’s IP address. If the domain has several IP addresses, the report lists them. For example, a large site like google.com will produce a list of IP addresses. Kevin also may set certain options in the program.

For example, he can tell the program to return “any” domain records it finds instead of only returning the basic IP address record. FIGURE 12.11 shows what happens when he does this and repeats his query.

Names in the DNS form a hierarchy, and different servers are assigned to different sections of the hierarchy. These sections are called “zones.” A server assigned to a zone is considered the authority for answering questions about domain names in that zone.

The starting point is, of course, the “root zone” at the top of the hierarchy in Figure 12.9. If we need to resolve a domain name like “www.stthomas.edu” and we don’t know where to start, we go to a root server. The root server then refers us to a more specialized server to answer our question. The process repeats until we find the server with the answer.

FIGURE 12.13 illustrates this iterative lookup process. Our first query goes to the root server. The server looks at the top-level domain in the name: “.edu” in this case. The server doesn’t know the whole answer itself, so it refers us to a server with better information.

We send our query a second time, this time to the “.edu” server. This server looks up the subdomain name “stthomas” and finds a server that can answer queries about it. Our second query, like our first, yields a referral to another name server. Our third query goes to the “stthomas.edu” server, which finally returns a response.

Because “stthomas” belongs to a university with a large IT department, it runs its own domain name server. Personal domain names often are directed to a server belonging to a domain registrar. If the subdomain has subdomains, those usually are interpreted by the same server.

Figure 12.13 shows that a domain name query might go through three or more servers in its quest for resolution. Each is responsible for part of the domain name space, and they work together to answer queries. The server responsible for a particular name’s meaning can update the information itself without having to update other systems. This is what makes the DNS a distributed database.

By distributing authority to different servers, DNS decentralizes management of different parts of domain names. Authority for “stthomas” or “umn” domain names are delegated to the organizations that own the names. In mid-2011, there were over 130 million subdomains registered under the major TLDs. The distributed approach provides a practical way to manage the enormous address space.

This attack provides bogus responses to DNS queries. It takes advantage of the fact that most resolvers contain a cache. If the cache contains bogus data about a host, the resolver will provide the bogus data to all queries about that host.

A simple but inefficient approach to cache poisoning is a form of bucket brigade attack. The attacker sits on a node between the resolver and some DNS servers. When a server sends a response, the attacker modifies the response so that the domain name points to the wrong IP address. In some cases, the attacker can trick the resolver into using the wrong servers to resolve top-level domain names like .com. This allows the attacker to provide bogus answers on a large portion of the names the resolver queries.

A more efficient attack transmits numerous bogus answers to a resolver in hopes of matching a query’s port number and transaction number. If the port and transaction numbers are predictable, this attack may work. Some DNS software resists this attack by using truly random values for those numbers and by carefully checking DNS responses against outstanding queries. However, such checks reduce DNS performance, so they are not used everywhere.

Attackers have targeted ISPs and specific sites with cache poisoning attacks. In 2008, the domain name for a security researcher’s site was hijacked by poisoning the cache on the ISP’s DNS servers. The attack occurred after the site had published details of how to exploit cache poisoning. Similar attacks hit a large ISP in China a few months later. In 2009, a cache poisoning attack redirected traffic to a bogus site masquerading as Brazil’s largest bank.

In 2002, hundreds of computers worldwide sent thousands of packets to all of the DNS root servers for about an hour. This was a DDOS attack because it relied on numerous separate computers to work together to overwhelm the targets with traffic. The attack briefly interrupted service from all but four of the root servers. Most internet users saw no service trouble because most DNS queries are answered with cached responses. A similar attack occurred in early 2007. Although the second attack lasted several hours, it affected even fewer root servers.

However, the basic risk remains: Attackers can try to shut down portions of DNS by attacking authoritative servers for different parts of the name space. On Christmas Eve 2009, the DNS provider for amazon.com suffered a DDOS attack. It interfered with access to the Amazon website for about an hour, but only affected visitors in parts of California.

Because DNS resolvers often reside in DNS servers that serve a particular zone of the name space, these machines are targets for attack. However, resolvers also may be tricked into taking part in an amplification attack.

In general, an amplification attack is one where the attacker sends a small amount of traffic to a server which responds with a lot of traffic. The attacker forges the packets’ return addresses to point to the victim’s computer. The server unwittingly sends vast quantities of traffic at the victim on behalf of the attacker.

In a DNS-based amplification attack, the attacker sends thousands of DNS queries to a resolver, with the victim’s IP address given as the source of the query. Each query is perhaps 50 bytes long, but the responses may be thousands of bytes long. Thus, the attacker sends a relatively small amount of attack data, and the DNS resolver sends a flood of data to the victim. The attacker can make the attack even more effective by sending a flood of queries to several different resolvers, so that they send the victim an even larger flood of responses.

DNS is one of the oldest and most heavily used elements of the internet. As such it is difficult to modify, because so many systems rely on its present structure and operation. However, there are certain steps that many sites and systems take to improve DNS security.

• ■   Randomized requests. The port number and transaction identifier in a DNS request are supposed to be randomly chosen so as to be hard to predict. Not all systems choose them randomly, though software updates have corrected this weakness.

• ■   Limited access to resolvers. An “open resolver” is one that accepts a DNS query from anywhere on the internet. It is easy to use an open resolver for an amplification attack. Many sites block access to their resolvers so that they are available only to their customers.

• ■   Distributed DNS servers. These provide multiple DNS servers to provide authoritative answers for important domain queries. The major root and TLD domains are covered by multiple servers distributed worldwide. DNS is less vulnerable to DDOS attacks if the attack must target numerous servers in separate locations.

Security improvements also arise from the DNS Security Extensions (DNSSEC), which consist primarily of cryptographic techniques for validating DNS transactions. DNSSEC prevents cache poisoning and man-in-the-middle attacks by affixing digital signatures to DNS responses and by providing a certification hierarchy for verifying the signature keys. DNSSEC was first deployed to root servers in 2010.