1

Chapter 23 – Domain Name System (DNS)

23.2 Names for Machines

It is usually easier to refer to a machine as juniper than as 138.26.66.6

23.3 Flat Namespace

► Early ARPAnet: unique names for machines, registered with Network Information

Center► Continued until 1000 machines

► Beyond that a massive bureaucracy would have been necessary to ensure uniqueness of

names

► The Domain Name System was created

2

Chapter 23 – Domain Name System (DNS) - continued

23.4 Hierarchical Names

City “Athens” – Athens, AL or Athens, GA or Athens, TN … ?

Specifying state removes ambiguity.

23.5 Delegation of Authority for Names

If you want to start a new city and call it “Athens,” you probably need permission from the state – you will probably be allowed to do it if there is not already and “Athens” in your state.

Once you have permission for the city name, you probably have the authority to name the neighborhoods.

In DNS “The topmost level of the hierarchy divides the namespace and delegates authority for each division; it need

not be bothered by changes within a division.”

3

23.6 Subset Authority

This can be carried down to more levels:

local.group.site

There is an analogy to the telephone numbering system:

<area code> – <exchange> – <extension>

(although in this case the highest level is written on the left).

4

In the Internet, hierarchical machine names are assigned according to the structure of organizations that obtain authority for parts of the namespace, not necessarily according to the structure of the physical network connections.

Example 1:

Two small departments, philosophy and foreign languages, might share a floor in the Humanities building; their domain names, pl.uab.edu and fl.uab.edu are different but they may share a single LAN and therefore have the same IP (sub)network address.

Example 2:

The CIS department has a large number of hosts and several LANs. All hosts have domain names with the same suffix, cis.uab.edu but their IP addresses are 138.26.64.x 138.26.65.y 138.26.66.z

5

23.7 Internet Domain Names

The Domain Name System has two, conceptually independent aspects:

■ (“abstract”) - name syntaxand delegating authority over names

■ (“concrete”) - distributed computing system that efficiently maps names to addresses

Section 23.7 continues with the first topic.

6

23.7 Internet Domain Names – continued

Domain name

cs.purdue.edu

contains three labels. This is the lowest-level domain

or third-level domain.

Any suffix of a label in a domain name is also called a domain:purdue.edu is the second-level domainedu is the top-level domain

(labels can be up to 63 ASCII characters long; the total length of the name can be up to 255 characters long)

7

23.8 Top-Level Domains

Figure 23.1 Top-level domains

8

23.8 Top-Level Domains - continued

The domain name space can be represented

by a rooted tree:

top-level domain

second-level domain

third-level domain

Different from Comer! More later

merlin

Figure 23.2

9

23.8 Top-Level Domains - continued

top-level domain

second-level domain

third-level domain

All domain names end in .e.g. cs.purdue.edu. but the . is usually omitted in

speech (not omitted in coding).

The domain name of a subtree is a list of its labels, separated by periods, along the path to the root.

10

23.8 Top-Level Domains - continued

Conceptually, the top-level names permit two independent naming hierarchies:

■ geographic

■ organizational

An organization can choose which way it wants to be known.

In the US we mostly see the organizational structuree.g uab.edu not uab.al.us

Other countries often use the geographic hierarchye.g. bham.ac.uk for the University of Birmingham (England).

For the geographic scheme each country has a two-letter codee.g. us for United States

Beneath this top level there are second-level domains for each state,e.g. al.us

11

23.8 Top-Level Domains - continued

There is a registrar for each top-level domain,

e.g. edu

An organization applies to the top-level registrar for approval of a second-level domain,

e.g. uab.edu

A department of an organization applies to the organization administration for approval of a third-level domain,

e.g. cis.uab.edu

The departmental administrator may assign fourth-level domains,e.g. juniper.cis.uab.edu

12

23.9 Name Syntax and Type

A record in the domain name system specifies the domain name, and also the type of this particular record, e.g.

■ IP address of the named machine (type A)

■ mailbox (type MX –

name of the machine running the SMTP server)

At first we’ll use the first type for examples – other types later

13

23.9 Name Syntax and Type - continued

The syntax of a domain name does not determine what type of object is represented.

gwen.purdue.edu

could be an individual machine (leaf of tree), although

cs.purdue.edu

Is a non-leaf domain, with numerous machines under it.

14

gwen

One cannot distinguish the names of subdomains from the names of individual objects or the type of an object using only the domain name syntax.

Comer’s example: machine gwen.purdue.edu.

15

23.10 Mapping Domain Names to Addresses

Recall that:

DNS has two, conceptually independent aspects:

■ (abstract) - name syntaxdelegating authority over names

■ (“concrete”) - a distributed computing systemthat efficiently maps names to addresses

Now we consider the second aspect.

16

23.10 Mapping Domain Names to Addresses – continued

The domain name system includes an

■ efficient

■ reliable

■ general-purpose

■ distributed

system for mapping names to addresses.

17

23.10 Mapping Domain Names to Addresses – continued

What is meant by these characteristics?

■ efficient most names can be mapped locally, without needing Internet traffic

(probably not true of home network)■ reliable no single machine failure will prevent the system

from operating correctly

■ general-purpose not restricted to mapping machine domain names to IP addresses

(but we will often use this as our example)

■ distributed a set of servers at multiple sites

cooperatively solve the mapping problem

18

Name Server

This is a server that supplies name-to-address translation, mapping from domain names to IP addresses (the example we’re concentrating on).

There is a cooperating system of such servers.

The corresponding client software is called a name resolver, which accesses one or more name servers when needing to translate a name.

23.10 Mapping Domain Names to Addresses – continued

19

23.10 Mapping Domain Names to Addresses – continued

Figure 23.3

Line means “able to contact” not usually directly

Similarly, the top-level domain server knows how to contact the server for each second-level domain … and so on.The servers can be physically located anywhere.

First, assume:

► name server for each level in the tree

► Search starts at root (top-down)

► Root server knows how to contact all top-level servers

20

23.10 Mapping Domain Names to Addresses – continued

► Arrangement on previous slide would produce a large number of small servers.

Figure 23.4

I don’t think this is right! See later.

► In practice the tree of servers will be flattened.

21

23.10 Mapping Domain Names to Addresses – continued

The company VeriSign runs the top-level server for .com, .net, and .org, and responds to:

6 – 18 billion requests per day (about 1 – 3 for each person on earth).

second-level domains (2008):

► 80,000,000 .com

► 10,000,000 .net

► 6,000,000 .org

► 174,000,000 total

DNS is an amazing system, which made the Internet usable by ordinary people! (Contrast having to use IP addresses.)

22

23.11 Domain Name Resolution

We continue to assume that name resolution proceeds top-down.

There are two ways to use the system:

■ iterative – the client contacts the chain of servers, one at a time

■ recursive – the client contact the first server and asks it to take over the task or resolution.

In either case the client forms a domain name query that has four components:

■ the domain name to be resolved

■ iterative or recursive resolution

■ the type of answer desired (e.g. machine IP address)

■ the class of the domain name (will always be IP for us)

23

23.11 Domain Name Resolution - continued

Here is a very small portion of the divided namespace:

The entire DNS namespace is divided into non-overlapping zones of authority.

There is a name server for each zone – authoritative server

24

23.11 Domain Name Resolution - continued

When a domain server receives a query it checks to see if the name lies in the subdomain for which this server is an authority.

If yes:

the server translates the domain name to an IP address, appends the answer to the query, and returns it to the client

If not:the server checks to see if the client requested iterative or recursive

If iterative the server replies to the client with a suggestion about the next server the client should contact

If recursive, the server turns round and recursively becomes a client, acting on behalf of the previous client; eventually an authoritative server is reached, the translation found, and the recursion unwinds, returning the answer to the original client.

25

23.11 Domain Name Resolution - continued

Q: How does a name server find another name server to contact if the first server cannot answer the query?

A: A name server must know the IP address at least one root server

(there are 13 root servers, spread around the world, referred to as A .. M – the A root server is 198.41.0.4).

The domain name service uses well-known port 53, usually UDP.

Q: How does a client find a name server at which to begin the search?

A: A client must know the IP address of at least one name server.(In UNIX systems these addresses are in the file /etc/resolv.conf)

26

23.12 Efficient Translation

We have pretended that resolution proceeds top-down, but this would be inefficient, because:

■ name resolution often refers to local names

(questionable – not true in home environment;

may be true in organizational environment);

■ if every client always went first to the top-level server, it might become overloaded;

■ failure of the top-level server, or of communication with it, would prevent resolution, even if a local server could resolve the name.

27

23.12 Efficient Translation - continued

So we adopt a two-step name resolution mechanism that preserves the administrative hierarchy but permits efficient translation:

■ resolution begins with a local name server

■ if this server cannot resolve the name, the query is sent to a higher server in the domain name system.

28

23.12 Efficient Translation - continued

Example: User on machine flits.cs.vu.nl pings machine linda.cs.yale.edu

209.86.66.94130.37.16.112

29

23.13 Caching: The Key to Efficiency

Scenario: A name server receives a recursive request for a name not in the server’s zone of authority. The server recursively becomes a client and eventually receives back the requested mapping, which it provides to the original client.

The server also retains the mapping in its DNS cache.If the server receives another request for this same mapping, it supplies the information from its DNS cache. However, it does not mark its reply as authoritative.

Since mappings may change, “soft state” is used. When an authoritative server provides a mapping, the server includes a Time to Live (TTL) that indicates how long the mapping may be assumed to remain valid. The receiving server deletes the mapping after the TTL has elapsed.

TTL is usually set to 1 day

30

23.13 Caching: The Key to Efficiency - continued

After step 7 the server cs.vu.nl would enter the mapping in its DNS cache and start a soft-state timer

(and in step 8 provide the mapping to the name resolver on machine flits).

Example: User on machine flits.cs.vu.nl pings machine linda.cs.yale.edu

31

23.13 Caching: The Key to Efficiency – continued

We can now refine the algorithm for a DNS server receiving a query:

IF query domain is in server’s Zone Of Authorityreply with answer marked AUTHORITATIVE

ELSE IF query domain is in server’s cache reply with answer not marked AUTHORITATIVE

and provide source of information

ELSE IF recursion requested & available server becomes client and searches

ELSE IF iteration requested or recursion not available return no answer, but provide suggestions

of other servers that may be helpful

32

23.14 Domain Name System Message Format

This format is used for all messages (requests and replies):

Figure 23.5

33

23.14 Domain Name System Message Format - continued

Figure 23.6

9 reserved 10 authenticated 11 disabled

4-bit op-code

Response code

34

23.14 Domain Name System Message Format – continued

Format of the QUESTION section of the general format:

Figure 23.7

juniper.cis.uab.edu.

A IP

35

The domain name system database consists of a collection of resource records

Figure 23.8

All DNS replies (ANSWER section, AUTHORITY section, and

ADDITIONAL INFORMATION section are in the form of resource records

juniper.cis.uab.edu.

A IP

138.26.66.64

1 day

36

23.15 Compressed Name Format

The first paragraph is not actually about compression!

Count byte

A: Domain names are stored as a sequence of labels; each label begins with an octet that specifies its length.

So juniper.cis.uab.edu is stored as 07 6a 75 6e 69 70 65 72 03 63 69 73 03 75 61 62 03 65 64 75 00 j u n i p e r c i s u a b e d u

End of name

Q: Because DNS labels and names are variable in length, how can we represent them internally?

Q: How do we know when the name is complete?

A: All names end at the root, which has a “zero-length name,” so the length prefix at the end of the name will be zero (explains why not “un-named root”).

37

23.15 Compressed Name Format – continued

To conserve space in the reply, name servers compress by sending only the first copy of each domain name.

Subsequent mentions of the name, or parts of it, are represented by pointer bytes to the first occurrence.

Pointers always occur at the beginning of a label and replace the count byte.

A: Labels cannot be more than 63 characters long, so the leftmost two bits of a count byte must be 00

Q: How do we distinguish count bytes from pointers?

Pointers are distinguished by having the leftmost two bits 11The next 14 bits of a two-byte field are the pointer.

38

Part of a Wireshark trace of DNS reply to query for

juniper.cis.uab.edu

AUTHORITY and ADDITIONAL INFORMATION sections

The complete name is in the RR but it is compressed in the answer section.

39

23.16 Abbreviation of Domain Names

Telephone analogy:

If destination and source are in same area,

it’s (usually) not necessary to dial the area code

Similarly, within CIS departmentjuniper

may be used for juniper.cis.uab.edu.

40

Although the human user may key in “juniper” the client software must add the suffix before accessing the domain

name system.

The DNS system allows for lookupof fully-qualified domain names only.

23.16 Abbreviation of Domain Names - continued

(in a UNIX system file /etc/resolv.conf contains possible values of the suffix)

41

23.17 Inverse Mappings and 23.18 Pointer Queries

We have been concentrating on mapping from a machine’s domain name to its IP address.

Sometimes we need the inverse mapping (given address, find name)

There is a special domain in-addr.arpa for this

For an IP address 138.26.66.6the form of the query to the DNS system is

6.66.26.138.in-addr.arpa

which should give the reply

juniper.cis.uab.edu

42

23.19 Object Types and Resource Record Contents

Recall that in reply to a query the DNS sends a copy of the relevant resource records.

DNS contains several types of resource record.

Figure 23.9

Here are some:

43

23.19 Object Types and Resource Record Contents - continued

A server always returns helpful information in the ADDITIONAL INFORMATION SECTION of the response.

For example, the ANSWER SECTION responding to a mail-server question contains the domain name of a server for the requested domain.

The ADDITIONAL INFORMATION SECTION will provide the corresponding IP address ( a type A resource record)

44

Wireshark trace of DNS reply to query for juniper.cis.uab.edu

45

23.19 Object Types and Resource Record Contents - continued

A small portion of a possible DNS database for domain cs.vu.nl

46

23.20 Obtaining Authority for a Subdomain

Before an organization is granted authority for a second-level domain it must agree to operate a DNS server that meets stringent standards.

The Internet authority requires that the information in every second-level domain server be replicated.

The information must appear in at least two independent name servers.

“Independent” means that the servers have no single common point of failure.

The servers ■ cannot be on the same physical network;■ cannot obtain electrical power from the same source.

In practice, an organization must find at least one other site that agrees to run a backup server.

For UAB the backup is at deltacom.net

Q: What is the definition of independent?