Chapter 31 -- naming with the domain name system

( Latest Revision: Sun Apr 8 2007 )

Notes On Chapter Thirty-One -- Naming With The Domain Name System

31.1 Introduction

Users like symbolic names for hosts, web sites, and so on. Symbolic names are relatively easy to remember, and they can even be poetic and fun (for example, a Google search revealed that someone thinks surrealitybites.org is a "nice domain name.)
IP numbers are best for computers. Numbers are compact. Computers can manipulate and transmit them quickly. They require little storage space.
The function of the Domain Name System (DNS) is mainly to translate between symbolic names and IP numbers.
DNS is an interesting example of client-server software and a distributed database.
This chapter is about
- the hierarchical structure of the DNS database,
- about the organization of the name servers, and
- about how caching makes DNS more efficient.

31.2 Structure Of Computer Names

Domain names have a form like: www.cs.csustan.edu
A domain name is a series of strings (segments) separated by periods.
There is no limit to the number of segments between the periods.
Except for the rightmost two, the segments need not correspond to domains, sub-domains, or networks.
Top level domain names (rightmost segment) are governed by the Internet Corporation for Assigned Names and Numbers (ICANN).
Seven new top level domain names were added by ICANN after the publication of the third edition of our text. As of the date of publication of the fourth edition, the top level domains were:
Each organization is assigned a unique domain suffix (at least two segments.) For example:
- csustan.edu,
- whitehouse.gov, or
- aol.com

31.3 Geographic Structure

DNS also allows geographic names. For example: cnri.reston.va.us
Some domains use a combination of organizational and geographic segments: ac.uk, u-aizu.ac.jp

31.4 Domain Names Within An Organization

A local organization may decide on further segmentation to denote whatever hierarchy or significance they desire. Examples:
- athena.csustan.edu (host, organization, TLD)
- host2.dbh.csustan.edu (host, location, organization, TLD)
- positron.physics.science2.csustan.edu (host, division, location, organization. TLD)
- sartre.philosopy.csustan.edu (host, division, organization, TLD)
- hegel.librarybuilding.philosophy.csustan.edu (host, location, division, organization, TLD)
- hopcroft.compilers.software.cs.csustan.edu (host, sub-subdivision, subdivision, division, organization, TLD)
We see above that there may be more segments for a larger part of the organization.
The names are paths in a hierarchy and various parts of an organization may be responsible for creating their part of that hierarchy.

31.5 Domain Names That Begin With www

There is no actual rule that says a web server's domain name has to start with www
The name of a host is completely independent of whether or not it functions as a web server.

31.6 The DNS Client-Server Model

The group that has a certain domain name suffix assigned by the central authority is also given the autonomy and authority to create and/or change any name with their assigned suffix. For example, we here at CSU Stanislaus can create or change any domain name with the suffix "csustan.edu." Of course, we can't change that suffix itself!
Organizations designate domain name servers to translate the names in their domain. For example we have name servers:
- w2k3-ns01.csustan.edu,
- w2k3-ns02.csustan.edu,
- splendor.csustan.edu, and
- altair.csustan.edu
to perform name service for names with the suffix "csustan.edu." Csustan.edu is our domain name.
The servers are organized in a hierarchy. A client asks a server to translate a name to an IP address (or vice-versa). The server may in turn act as a client to another server to get the answer.

31.7 The DNS Server Hierarchy

The DNS servers form a cooperating hierarchy
At the top are the root servers. Root servers are authorities for all the top level domains such as .com, .gov, .edu, and so on.
The root servers don't contain all the information, but they know how to contact other servers for the various domains that correspond to IP networks. E.g. they can contact the servers registered in the whois database.
It is quite flexible how authority for different parts of the naming hierarchy can be divided up and assigned to servers.
In the words of RFC 2181:

31.8 Server Architecture

Have someone else take care of your name service if it works for you -- that's the simplest way.
Have one server in your organization if it works for you -- that's the next simplest way.
Have more than one server if you need to do it to keep up with requests or maintenance of the database.
If you have lots of servers you can divide up the responsibility for making changes to the database. People can change things on the different servers independently.

31.9 Locality Of Reference And Multiple Servers

Users tend to look up the names of local computers, and they tend to look up the same hosts repeatedly.
Administrators can form local groups (zones) and assign name servers to each. If done 'right,' most request will be handled by local servers for members of the local zone, and none of the servers will tend to be overloaded.

31.10 Links Among Servers

A server is assigned one or more suffixes. It is responsible for all names having those suffixes.
- For example: a server assigned the suffix csustan.edu is responsible for translating any domain name that ends with csustan.edu.
- Another example: a server assigned suffixes physics.csustan.edu and cs.csustan.edu would be responsible for translating all domain names that end either in physics.csustan.edu or cs.csustan.edu.
Delegation Rules
- IF X serves suffix S (e.g. S == foobar.com), and
- Y serves suffix T (e.g. T == walnut.candy.foobar.com), and
- S is a suffix of T (e.g. S==foobar.com is a suffix of T==walnut.candy.foobar.com),
- THEN X must know the IP address of Y (and be able to refer queries about names with suffix T to Y.)
Every DNS server knows a root server. Every DNS server knows how to get servers for each of its subdomains.

31.11 Resolving A Name

A resolver is software that translates a domain name into an IP Address.
The Unix resolver is the function gethostbyname()
gethostbyname() inputs a string like "foobar.ac.us" and returns a structure that can contain one or more IP addresses.
Typically a host is "configured" with static information that gives it the IP number of a local name server.
- On a Unix host the information is in a file (/etc/resolv.conf). For example the contents of resolv.conf on a laptop computer might be:
```
nameserver 130.17.70.35
nameserver 130.17.70.4
```
  We see from this that the laptop knows the IP addresses of two name servers. For more information, do the command: man resolv.conf on one of the Suns.
- On personal computers the user places the same kind of information in a TCP/IP settings, preferences, or control panel.
When a host H wants to resolve a name, it sends a query to one of the name servers it knows about. (Note that H does not need name service to get the IP address of the name server!)
The name server X that H contacts will answer H directly if it knows the answer.
- X may have an authoritative answer because it is responsible for the domain or zone in question.
- It may have a non-authoritative answer it has cached from a previous query.
The server X may not know the answer. In that case it will know the identity of another server Y to ask.
If Y knows the answer it will send the answer to X, who will send it to the orginal host H.
If Y does not know, Y will send the IP number of a server Z to X and tell X to ask Z. X will then send a query to Z.
This sort of thing goes on until one of the servers knows the translation and sends it back to X, which then sends it to the host H.
Note that a host H typically requests recursive query resolution -- H asks X to get the answer for H, even if X has to contact other name servers to get the answer.
In contrast, a name server usually requests iterative query resolution -- if name server X needs to ask name server Y for a translation and Y does not have it, then Y will not go and get the answer from some other name server on behalf of X. Instead Y sends the IP number of another server to X and it is X's responsibility to try that server next.
It usually makes sense to do things this way because it puts most of the workload on the local name servers and not on the hosts or higher-level name servers.
Most servers do not know the IP numbers of very many other servers.
- All servers are configured to know IP addresses of servers for the "root domain" -- the domain that contains all hosts on the Internet.
- If X is responsible for a domain D that has subdomains, then X will know servers for the subdomains immediately below the level of D in the domain hierarchy.
- Root servers know servers for all the "top-level" domains such as .com, .org, and so forth.
Typically a query about a host inside the local domain is answered by the first name server queried or by a name server farther "down" in the hierarchy.
Typically a query about a host outside the local domain jumps "up" to a root server immediately and then travels back down a different branch level-by-level to a server that is responsible for the domain containing the host that is the target of the query.

31.12 Optimization Of DNS Performance

Replication: There are lots of root servers "out there." A local name server will use the root server that is the "most responsive" the one that tends to answer soonest. This practice tends to keep the workload balanced evenly from server to server.
More importantly, all name servers cache the answers they get. They do not make a query to another server if they have the answer in the cache. This greatly reduces the total number of queries. Cache entries eventually expire.

31.13 Types Of DNS Entries

DNS supports queries other than the "generic" type A (address) queries to translate a domain name to an IP address.
For example there are Mail eXchanger (MX) records. E-mail software requests info relating to MX records.
The MX translation of a name like foobar.ac.us can be one IP number in an MX record, but a different IP number in an A record.
This allows system administrators to do things like create "mail hubs." For example we could use this idea to make all mail addresed to any of the Sun Ultra's in our lab to be delivered to the same machine -- say to zaurak, because it does not have a lot of other work to do.

31.14 Aliases Using The CNAME Type

DNS data bases also have CNAME entries. CNAME entries allow you to create an "alias" for a host.

Example: Here are some entries from the DNS database for our local domain:


www.cs          IN      A           130.17.1.35
splendor        IN      CNAME       www.cs
ftp.cs          IN      CNAME       www.cs
yahi            IN      CNAME       www.cs
honors          IN      CNAME       www.cs
www.honors      IN      CNAME       www.cs
cogs            IN      CNAME       www.cs
test            IN      CNAME       www.cs
math            IN      CNAME       www.cs
www.math        IN      CNAME       www.cs

Basically the first line says that the IP address for www.cs.csustan.edu is 130.17.1.35.
The next line says that if you want to know the IP address for splendor.csustan.edu then you should "see" the entry for www.cs.csustan.edu, because splendor.csustan.edu is just an alias (CNAME) for www.cs.csustan.edu.
The other entries for ftp.cs, yahi, honors. www.honors, cogs, test, math, and www.math are like the entry for splendor -- the one computer has all those aliases!
This kind of aliasing makes it easy to reassign a service such as anonymous ftp service. When someone wants to use our anonymous ftp server, s/he will typically use the name "ftp.cs.csustan.edu." If we change the CNAME entry in the DNS database from
```
ftp.cs          IN      CNAME       www.cs
```
to
```
ftp.cs          IN      CNAME       shalim
```
Then ftp.cs.csustan.edu will become an alias for shalim instead of www.cs. Anonymous ftp users can continue to use ftp.cs for their ftp service. Also users who are in the habit of using the name of shalim or www.cs can continue that same name usage. Note that we haven't actually changed shalim's name. Anonymous ftp service has changed locations to shalim, but that is "transparent" to the users.

31.15 An Important Consequence Of Multiple Types

A DNS server may return different translations of a name depending on the type of the query. This can be confusing to "mere mortals."
An e-mail system may attempt an MX query first. If that fails to resolve the name the e-mail software may try a type A request.
The trouble with MX entries is that you can put them in your DNS database, but you can't force the e-mail software "out there" to use them.
You can put in an MX entry for a host, and not put any A entry for the host at all. That way "law-abiding" e-mail software will be able to send e-mail to the hub for your host, but it will make it hard for other machines to figure out how to contact the host directly. You may want that for security purposes. On the other hand, it can be very inconvenient.

31.16 Abbreviations And The DNS

Users on a local host can "drop" suffixes because the local resolvers are programmed to try appending each member of a set of suffixes with their queries to the name server. The system administrator may have to "configure in" these suffixes.
You may have seen these suffixes referred to as "search domains" in your Mac TCP/IP control panel or your Windows Settings.
The first line of this /etc/resolv.conf file from a Unix host is a suffix for the local domain:
```
domain csustan.edu
nameserver 130.17.1.50
nameserver 130.17.1.35
nameserver 130.17.1.4
```
This is what allows us to use names like "vega" instead of "vega.csustan.edu" when we send e-mail from a host on the local network. (Sometimes the host is not configured with the right suffix(es) and so it turns out you have to use the fully qualified domain name even though it seems you shouldn't have to.)

31.17 Summary