Dns Overview

DNS Overview 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 Name: Address: Aliases: ic.bm mail is handled by 10 mx.ic.bm.

server: ns2.swbell.net 151.164.1.7#53

% host mx.ic.bm ns2.swbell.net Using domain Name: Address: Aliases: mx.ic.bm has address 209.15.204.209

server: ns2.swbell.net 151.164.1.7#53

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 has cnn.com has cnn.com has cnn.com has cnn.com has cnn.com has cnn.com has cnn.com has address 64.236.16.84

address address address address address address address

cnn.com 64.236.16.116 64.236.24.4 64.236.24.12 64.236.24.20 64.236.24.28 64.236.16.20 64.236.16.52

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 hotmail.com mail is hotmail.com mail is hotmail.com mail is hotmail.com mail is hotmail.com mail is handled by

-t MX handled by handled by handled by handled by 5 mx5.hotmail.com.

% host -t MX yahoo.com mail is handled by 5 yahoo.com mail is handled by 1 yahoo.com mail is handled by 1 mx2.mail.yahoo.com.

5 5 5 5

hotmail.com mx1.hotmail.com. mx2.hotmail.com. mx3.hotmail.com. mx4.hotmail.com.

yahoo.com mx4.mail.yahoo.com. mx1.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 maKintosh.com

-t name

NS server

maKintosh.com sugar.maKintosh.com.

maKintosh.com name server maKintosh.com name server norad.maKintosh.com.

arleigh.tessier.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 Using domain Name: Address: NORAD.maKintosh.com has address 24.10.199.248 % host NORAD.maKintosh.com Using domain Name: Address: NORAD.maKintosh.com has address 68.46.227.160

echo.sound.net server: echo.sound.net 209.153.64.21#53

sugar.maKintosh.com server: sugar.maKintosh.com 209.15.204.209#53

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 http://megaohm.resistor.net/~sm/dns/index.html