User:David MacQuigg/Sandbox/Domain Name System

======== Domain Name System ========                          DMQ DRAFT 3/6/09
../Notes/Encyclopedia/Citizendium/dns/DomainNameSystem.txt

The Domain Name System (DNS) is the "phone book" of the Internet. When you want to look at a webpage for <somedomain.com>, the first thing your browser does is send a query to DNS requesting an IP address for the domain. Domain owners can provide other information in their DNS records - additional addresses for alternate webservers, addresses for mail servers, various bits of information for special services, and strings of arbitrary text, which can have any purpose the domain owner wants. These TXT records are most often used for authentication. There are dozens of DNS record types. Table 1 shows the types most commonly supported by commercial DNS services.

Table 1. Common DNS Records

 A, AAAA, MX, NS, PTR, CNAME, TXT, SOA, SRV
 

As you might expect, DNS is a HUGE database including millions of domains. It must be available 24/7 worldwide, and handle billions of queries every hour. It must also be secure enough to resist a never-ending flood of attacks from "script kiddies" wanting to "take down the Internet" and serious criminals with more sophisticated tools. To accomplish this, DNS uses a distributed database involving millions of "name servers" all over the world.

Most of these are "cache servers" that provide local copies of DNS records, but there are also many "authoritative servers" providing original information on all domains that have been "delegated" to them. The process of delegation creates a hierarchy, starting with the *root servers*, then the *top-level domains* (TLDs in Figure 1), then *second-level domains* (SLDs), and so on, down to as many *subdomains* as the owner of the lowest-level server cares to create.

Figure 1. Hierarchy of DNS Name Servers --> delegation to a lower authority --- subdomains within the same zone of authority

  [.org  ]   [.com]   [.us]
 -->[example               add more zones and subdomains
    ---smtp                use color to show the zones [   ]
      ---mailin ]

How it Works

Let's follow in detail a DNS query from start to finish. If this process seems a bit long, remember, it all happens in milliseconds, automatically when I take a simple action, like clicking SEND in my email client.

The first step is to locate the mail server <mailin-01.mx.aol.com>, a name which I entered into the configuration data of my email program when I first signed up for email service with AOL. To locate this server, my mail client first does a DNS query to a local name server. Of course, it can't use DNS to locate that first name server, so it must have an actual IP address for this first query. This address (two addresses, including a backup server) was configured into my computer's network setup when I first signed up with my Internet Service Provider.

The local name server at my ISP just happens to have current data for mailin-01.mx.aol.com, so it sends an immediate response to my mail client. The response packet includes three "A records", each record having one IP address that my mail client can try for mail service at aol.com. We can replicate this process using the dig program (see Domain Name System - Digging for Data).

  $ dig mailin-01.mx.aol.com
  ...
  mailin-01.mx.aol.com.   222     IN      A       64.12.139.249
  mailin-01.mx.aol.com.   222     IN      A       205.188.156.248
  mailin-01.mx.aol.com.   222     IN      A       205.188.159.57
  ...
  

These records, at the moment we retrieved them, had 222 seconds remaining before expiration. If we query the authoritative nameservers for aol.com directly, we will see 300 seconds as the initial lifetime. This is rather short, but makes sense for a domain as large as aol.com. A typical initial lifetime for DNS records is 24 hours. The optimum lifetime is a compromise between minimizing queries to the authoritative server, and minimizing the time a domain owner needs to wait for changed records to replace old ones in cache servers all over the world.

  {The IN in the above records means these are Internet records. It is an artifact left over from the days when the Internet was just getting started, and the DNS designers had to allow for the possibility of competing internets.}

Recursive Queries

What if I was using a not-so-well-known mail server? My ISP's local DNS server might have "stale data" or no data at all on <mailin.smtp.example.org>. In this case, the local server begins a process called a recursive query, starting with one of the 13 "root servers", whose addresses are well known, and permanently saved in a configuration file. Typically, a query to a root server won't be necessry, because the next level down, .org, is already in our cache.

Using a cached address for a .org nameserver, our local server sends a query for mailin.smtp.example.org. The .org nameserver has no data on this exact name, but it does have a "delegation of authority" to example.org, so it answers with a "referral":

ANSWER SECTION

example.com. 10454 IN NS a.iana-servers.net. example.com. 10454 IN NS b.iana-servers.net.

ADDITIONAL SECTION

a.iana-servers.net. 161552 IN A 192.0.34.43 b.iana-servers.net. 107492 IN A 193.0.0.236

Except for the long lifetimes, this is a fairly typical referral response. The lifetimes are long, because example.org is not a real domain, but a special name that has been reserved for experiments like this. The addresses almost never change, so a lifetime of a few days is no problem for IANA (Internet Assigned Names and Numbers) the organization running these servers.

You might have noticed that the referral contained two types of records: NS or nameserver records, and A records, which we have already seen. Why not just give us the addresses and save time? The reason for this two-step process is that the designers of DNS were far more concerned about the time of a DNS administrator than the time needed to send extra bytes in a packet. There is a lot more flexibility in a two-step process. Typically servers will be given a "permanent" name, and an address that seldom changes. However, the arrangement of those servers in a publicly-offered service may change frequently. If a domain's DNS records are well organized, it is very easy to change the NS records and let the setup at each server stay the same. See DNS Records for more examples of this two-step process.

<DNS Records> Subtopic Ask for a service, and get a list of server names. Query a particular name, and get the actual address.

< repeat example with NS records >

The same two-step process was done for mail service records (MX records in our first example). We just didn't show the first query. Here it is in full detail:

[dave@open-mail ~]$ dig mx aol.com

<<>> DiG 9.2.4 <<>> mx aol.com

global options

printcmd

Got answer

->>HEADER<<- opcode

QUERY, status: NOERROR, id: 60376

flags

qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 13

QUESTION SECTION

aol.com. IN MX

ANSWER SECTION

aol.com. 3457 IN MX 15 mailin-04.mx.aol.com. aol.com. 3457 IN MX 15 mailin-03.mx.aol.com. aol.com. 3457 IN MX 15 mailin-02.mx.aol.com. aol.com. 3457 IN MX 15 mailin-01.mx.aol.com.

ADDITIONAL SECTION

mailin-03.mx.aol.com. 157 IN A 64.12.138.153 mailin-02.mx.aol.com. 3457 IN A 64.12.137.89 mailin-01.mx.aol.com. 157 IN A 205.188.159.57 mailin-04.mx.aol.com. 157 IN A 205.188.159.216 mailin-04.mx.aol.com. 157 IN A 64.12.138.88 mailin-03.mx.aol.com. 157 IN A 205.188.252.17 mailin-02.mx.aol.com. 3457 IN A 205.188.249.91 mailin-02.mx.aol.com. 3457 IN A 205.188.155.72 mailin-01.mx.aol.com. 157 IN A 64.12.139.249 mailin-04.mx.aol.com. 157 IN A 64.12.138.57 mailin-02.mx.aol.com. 3457 IN A 64.12.138.120 mailin-03.mx.aol.com. 157 IN A 205.188.109.56 mailin-01.mx.aol.com. 157 IN A 205.188.156.248

Query time

2 msec

SERVER

72.249.191.254#53(72.249.191.254)

WHEN

Thu Mar 5 18:29:02 2009

MSG SIZE rcvd

340

AOL is currently using four mailserver names. They all have equal priority (15). Each name is actually three or four servers, makig a total of 13.

All of this came in one packet, and took only 2 milliseconds.

</DNS Records>

Continuing with our recursive query example, my email program is still waiting for the address of a mailserver, and my local DNS nameserver now has a referral to two authoritative nameservers for example.org. We still need the address of mailin.smtp.example.org. The "resolver" program in the local DNS server picks one of the two authoritative servers and resends the original query. It also sets a timer, so it can query the second server, if the first does not respond.

The name server at example.org has authoritative data for all its subdomains (no further delegation), so it responds with the A records for mailin.smtp.example.org. The packet with those records is then relayed to my mail client. The local DNS nameserver keeps a copy of these records in its cache in case there are future queries on this name from me or any other customer of my ISP. A record of the response time is also kept, so future queries can pick the nameserver responding most quickly. The whole system is designed for speed and efficiency.

Zones of Authority

A zone in DNS includes all the subdomains in one "zone of authority". As shown in Figure 1, a zone can include more than one level in the DNS name hierarchy. You can tell where each zone starts by looking at the resonse to a series of queries. If the name in the query is within the zone, the response is the requested record (or NXDOMAIN - no such domain). If the name is not within the zone, but possibly in a delegated zone, the response is a referral to the nameservers for the delegated zone.

Delegation of authority to lower zones can continue for as many levels as needed. In this way, DNS has built up a distributed database with up-to-date and reliable information on millions of domains all over the world. The authority for each zone is entirely in the hands of the owner of that zone, and the maintenance of records within that zone are his responsibility. Delegation of authority to lower zones is also in the hands of each owner. Thus the design of DNS is intended to limit to one zone and its subzones, any damage due to incompetence or abuse. See DNS Security for further discussion of these issues.

The first delegation of authority from the root nameservers is done by IANA to the Registries for each of the Top Level Domains (TLDs). These Registries are operated by various trusted private and governmental organizations, but the actual data in the Registries is controlled by a much larger number of Registrars, some of which have proven to be incompetent. Luckily, an incompetent or dishonest Registrar can only damage records within the domain for which he has been granted privileges.

From each TLD, delegation is typically one level down in the domain namespace, but sometimes there will be lower subdomains in a Registry. Anyone can pay a fee to a Registrar, and pick a domain name not already taken. Registrars don't make a big effort to verify identities, as long as they get their money. All they really have to do is keep track of their registrants' data, including the IP addresses chosen by the registrant for the domain's nameservers. A favorite trick, known as "domain hijacking" is to pretend to be the owner of a domain name, and ask the Registrar for that domain to change the addresses of its nameservers. Registrars are required by IANA to verify these requests by contacting the owner of record, but there have been some spectacular failures in the news. It's like conning the phone company to move your competitor's phone service.

== defered to suptopics == (things I thought of while writing the above)

 glue records
 domain hijacking ???  (instead of in Zones of Authority above)
 

== Related Articles == (needs more work to include everything in the

                        original DNS article)
 Parents:  
   Computer > Networks
 Subtopics: 
   Domain Name System - Digging for Data
     Lots of cool examples exploring the intricacies of DNS
   Donmain Name System - Records
     http://www.dnsmadeeasy.com/s0306/res/recs.html
   Domain Name System - History
   Domain Name System - Non-technical Issues - politics, business, etc.
 Other:
   Domain Name System - Security - TSIG, DNSSEC, etc.
   Domain Name System - Dynamic Update
   Email Authentication - DNS Records
   User Datagram Protocol
   IPv6

Bibliography

RFCs - 1034 ... Books - Albitz & Liu, "DNS and BIND", 4th ed, O'Reilly 2001.

     - Aitchison, "Pro DNS and BIND", Apress 2005. - best introduction
     - Peterson & Davie, "Computer Networks", Ch.9