This section provides information on the basics of DNS along with providing a historical overview of why DNS was implemented.
History
DNS, short for Domain Name System, is the language the Internet uses to translate names like example.com into a string of numbers like 192.0.34.72 and vice versa. DNS exists today because of ARPANET, the precursor to the Internet. ARPANET was a network engineered by the U.S. Government to implement and test new networking technologies. On this network, participating machines used unique numbers to identify themselves to the rest of the machines.
While computers technically work with only numbers, humans have a much easier time memorizing names. To make life on ARPANET easier, the Stanford Research Institute created and distributed a single text file named HOSTS.TXT, which contained the name to address mappings of all connected hosts. This file was then distributed on a daily or weekly basis to all interested parties on the network. As ARPANET grew from 4 computers to more than 500, transferring this file on a frequent basis became unmanageable. The amount of data that needed to be transferred put too large a load on the network and the frequency of updates was too much for one site to coordinate.
Hierarchy
The hierarchy of DNS is very similar to how the UNIX file system is laid out; the root of the theoretical tree branches off into smaller, more specific host or file paths. The root domain, similar to the root directory under Unix, is indicated with a single period. Below root exists a collection of domains known as the Top Level Domains. The TLDs are broken up into three main groups: generic TLDs, restricted TLDs, and country code TLDs. The most popular group consists of aero, biz, com, coop, info, museum, name, net, org, and pro. The remainder of the gTLDs have certain requirements that must be met before they are assigned. The TLD of mil is only assigned to the US Military, gov to US Government agencies, edu to educational organizations, and int to organizations established by international treaties between governments or Internet infrastructure databases. The final group is the Country Code Top Level Domains (ccTLDs) that are assigned to the countries of the world. Refer to Figure 1 to see how the fully qualified domain names (FQDNs) of store.apple.com, norad.mil, and vega.communitech.net are broken up.
figure 1
The next diagram shows the delegation of a few domains and the specific name servers involved, specifically communitech.net, apple.com, and ic.bm. At the top of the virtual tree are the 13 root servers, which are the first point of contact for most DNS queries. The TLD servers then delegate the common domain extensions to the gTLD servers. The delegation process continues with the gTLD servers delegating the communitech.net zone to our servers and apple.com to Apple Computer's servers. In addition, the main root servers delegate the domain for Bermuda to a collection of name servers that then delegates the domain ic.bm to sugar.maKintosh.com.
figure 2
DNS: Resolution Process (Basic)
This section describes the process of DNS queries, explains the use of popular DNS tools, and also brings in some live DNS examples.
While the structure of DNS is rather simple, the process involved in translating example.com into 192.0.34.72 is rather long and complex. When DNS resolution is initiated from most applications, the resolution process will continue until a DNS server gives an authoritative answer for the requested domain. Figure 3 illustrates the process of a basic DNS request.
figure 3
To manually perform a DNS query, tools like host, dig, and nslookup can be used. Keep in mind that nslookup is old, poorly written, and is not recommended by the DNS experts, so if you have a choice, use dig or host. Using dig, we can trace the path of a DNS query. To follow the same path illustrated in the above diagram, we can use the dig command as shown below.
% dig www.maKintosh.com A @echo.sound.net +trace
; <<>> DiG 9.2.1 <<>> www.maKintosh.com A @echo.sound.net
+trace
;; global options: printcmd
. 348358 IN NS C.ROOT-SERVERS.NET.
. 348358 IN NS H.ROOT-SERVERS.NET.
;; Received 436 bytes from 209.153.64.21#53(echo.sound.net) in
26 ms
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
;; Received 467 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in
142 ms
maKintosh.com. 172800 IN NS ARLEIGH.TESSIER.com.
maKintosh.com. 172800 IN NS NORAD.maKintosh.com.
maKintosh.com. 172800 IN NS SUGAR.maKintosh.com.
;; Received 153 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in
44 ms
www.maKintosh.com. 38400 IN A 209.15.204.209
maKintosh.com. 38400 IN NS norad.maKintosh.com.
maKintosh.com. 38400 IN NS sugar.maKintosh.com.
maKintosh.com. 38400 IN NS arleigh.tessier.com.
;; Received 169 bytes from 216.22.145.243#53(ARLEIGH.TESSIER.com)
in 50 ms
The above command asks echo.sound.net, a random name server, for any IPs to which www.maKintosh.com resolves. In addition, the "trace" option displays the path taken. As you can see, the first server queried is echo.sound.net, which gives a list of the 13 root name servers. From the returned list, c.root-servers.net is randomly picked for the next query and then it is ask about www.maKintosh.com. The "c" root server gives back the gTLD servers and the process continues until we end up with the one A record for www.maKintosh.com. While the dig command is handy for detailed debugging, the host command easier to use and its output is much easier to parse. Our next example shows host asking ns2.swbell.net for the MX records of a specific domain and then resolving an IP address for the MX record that was returned.
% host -t MX ic.bm ns2.swbell.net
Using domain server:
Name: ns2.swbell.net
Address: 151.164.1.7#53
Aliases: ic.bm mail is handled by 10 mx.ic.bm.
% host mx.ic.bm ns2.swbell.net
Using domain server:
Name: ns2.swbell.net
Address: 151.164.1.7#53
Aliases: mx.ic.bm has address 209.15.204.209
DNS: Records
DNS handles data similar to that contained in an address or phone book. This section goes into some specifics of the different data types.
RFC 1035 defines 16 types of stuff that DNS can hold. The following 4 records are the most common.
A: a host address
An A record translates example.com into 192.0.34.72. Multiple A records can exist for any given domain name and many sites use this functionality as a way to do free load balancing over multiple computers. For example, cnn.com resolves to eight different IP addresses.
% host cnn.com
cnn.com has address 64.236.16.116
cnn.com has address 64.236.24.4
cnn.com has address 64.236.24.12
cnn.com has address 64.236.24.20
cnn.com has address 64.236.24.28
cnn.com has address 64.236.16.20
cnn.com has address 64.236.16.52
cnn.com has address 64.236.16.84
CNAME: the canonical name for an alias
CNAME records are aliases for other A records. Apple uses CNAMEs to redirect web traffic to Akamai's servers. Akamai provides content management for other companies and using CNAMEs allows them to modify A records on their network without involving the company they host.
% host
trailers.apple.com
trailers.apple.com is an alias for trailers.apple.com.edgesuite.net.
trailers.apple.com.edgesuite.net is an alias for a772.g.akamai.net.
a772.g.akamai.net has address 80.67.66.8
a772.g.akamai.net has address 80.67.66.14
NS: an authoritative name server
NS records are used to delegate authority for a specific domain or sub-domain. For example, if we host the DNS and public website for a company but don't host their private, corporate site, NS records can be created so that requests for corp.example.com are handled by a different set of name servers.
MX: mail exchange
MX records tell SMTP daemons where to send e-mail for a specific FQDN. Each MX record has a priority or cost value tied to it and there can be multiple MX records per domain. When a SMTP daemon goes to send an e-mail, it first makes a list of the MX records and then it picks the MX record with the lowest cost value. If all MX records have the same cost, some daemons will pick a random one and others will pick the first or last one they come across.
% host -t MX hotmail.com
hotmail.com mail is handled by 5 mx1.hotmail.com.
hotmail.com mail is handled by
5 mx2.hotmail.com.
hotmail.com mail is handled by
5 mx3.hotmail.com.
hotmail.com mail is handled by
5 mx4.hotmail.com.
hotmail.com mail is handled by
5 mx5.hotmail.com.
% host -t MX yahoo.com
yahoo.com mail is handled by 5 mx4.mail.yahoo.com.
yahoo.com mail is handled by 1 mx1.mail.yahoo.com.
yahoo.com mail is handled by 1 mx2.mail.yahoo.com.
The final type of data to discuss is the "glue" record. These records are not defined as a separate type of record because they're just a standard A record, but in practice, they're given a different name because of the way they're delegated. Glue records are used when a sub-domain is delegated to a set of name servers in the same domain. If we wanted ns1.example.com to delegate corp.example.com to ns1.corp.example.com, a glue record would need to be added to ns1.example.com for ns1.corp.example.com so it knew where to refer queries that asked about the corp sub-domain. It’s slightly confusing, but that’s all the detail needed because we’re not DNS administrators. The main problem we do run into with glue records is that clients forget to remove them from the gTLD servers. The maKintosh.com domain has a real example of this problem.
% host -t NS maKintosh.com
maKintosh.com name server sugar.maKintosh.com.
maKintosh.com name server arleigh.tessier.com.
maKintosh.com name server norad.maKintosh.com.
Authority for maKintosh.com has been delegated to three different name servers, one of which has a stale glue record. If we query a random name server to see what NORAD.maKintosh.com resolves to, we get an IP address of 24.10.199.248. However, if we ask one of maKintosh.com's name servers the same thing, we get back 68.46.227.160 instead.
% host NORAD.maKintosh.com echo.sound.net
Using domain server:
Name: echo.sound.net
Address: 209.153.64.21#53
NORAD.maKintosh.com has address 24.10.199.248
% host NORAD.maKintosh.com sugar.maKintosh.com
Using domain server:
Name: sugar.maKintosh.com
Address: 209.15.204.209#53
NORAD.maKintosh.com has address 68.46.227.160
The discrepancy occurs because the gTLD servers have created a record for NORAD.maKintosh.com so resolvers know what IP address NORAD.maKintosh.com resolves to. If the gTLD servers didn't store this information, they wouldn't know what IP address NORAD.maKintosh.com resolves to. An easy way to look for glue records is to use the whois utility either on the UNIX command line or via the web interfaces provided by InterNIC.
Server Name: NORAD.MAKINTOSH.COM
IP Address: 24.10.199.248
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Normally this isn't an issue because most people point NS authority to host records named ns.example.com or dns.example.com. However, when some people create example.com, they use www.example.com and mail.example.com as their DNS servers. When the client decides to switch providers and host with CommuniTech, they point their domain to ns.hosting4u.net but forget to delete the glue records of www.example.com and mail.example.com that exist in the gTLD servers. The next time a random Internet user tries to visit www.example.com, their name server returns the glue record instead of asking ns.hosting4u.net for the correct address of www.example.com.
September 2002 © John Kerbawy