Transcript Chapter 16 The Domain Name System Yun Wan June 29, 1999

Chapter 16 The Domain Name System
Yun Wan June 29, 1999
16.1 Introduction
1. DNS is a distributed database that holds information about
computers on the Internet, which includes the host’s name, IP
address, mail routing information and so on.
2. Primary job : map between hostnames and IP addresses.
Users refer to machines by names, while low-level network
software understands only numbers.
16.2 The History of DNS
1. Mapping between hostnames and addresses was kept in a single text
file that was managed centrally and distributed to all the hosts.
2. It is reasonable for small network, but inadequate for the large and
growing network.
Solution : hierarchical hostnames and distributed responsibility
3. BIND, Berkeley Internet Name Domain system, was produced by
Kevin Dunlap in 1985.
16.3 Who Needs DNS
1. A site on the Internet needs DNS to participate fully
2. DNS defines :
 A hierarchical namespace for hosts
 A host table implemented as a distributed database
 Library routines for querying this database
 Improved routing for email
 A protocol for exchangeing naming information
16.4 The DNS Namespace
1. DNS namespace is a tree of domains with ascending authority.
2. The root of the tree is called “.”, followed by the top-level domains.
3. Two sorts of domain:
domains in the US : describe organizational and political
structures, which are given three-letter names such as com, edu,
and so on.
domains outside the US : two-letter ISO country codes such as
AU(Australia), CA(Canada).
16.4 The DNS Namespace (Cont’d)
4. A fully qualified hostname is formed by appending the domain
name to the hostname such as boulder.colorado.edu.
5. The structure of the naming tree is illustrated as following :
.
Root Domain
Top Level
EDU
Second Level
Subdomains
and
Machines
colorado
cs
anchor
COM
berkeley
boulder
vangogh
cs
east
FI
sun
funet
central
mammoth
16.4 The DNS Namespace (Cont’d)
6. Selecting a Domain Name
Certain names are taboo such as names that are already taken,
the keyword AT, combinations of top-level domains (edu.com)
repeating names like x.x.com.
7. Registering a Second-level Domain Names
In US, sent your application electronically or via US mail to
Registration Services group of the Network Information Center
8. Creating your own Subdomains
choose a name that is unique in the local context
Identify two or more hosts to be severs for your new domain
Coordinate with the administrator of the parent domain
16.5 Components of BIND
1. Three components:
A deamon called named that answers queries
Library routines that resolve host queries using DNS
Commnand-line interfaces to DNS: nslookup, dig and host
2. What does the named do ?
Answers queries about hostnames and IP addresses
If it doesn’t know the ansewer, asks other severs and cashes their
responses
performing “zone transfers” to copy data among the servers of a
domain
16.5 Components of BIND (cont’d)
3. Three modes of Name Severs :
Primary, Secondary and Cashing-only
4. How to distinquish the three modes :
where the data comes from and whether the sever is authoritative
for the domain.
5. Primary name server keeps the master copy of the domain’s data on
disk and is an authoritative name server.
6. Secondary name server copies its domain’s data from the primary
server via a “zone transfer” operation and it is also an authoritative
name server
16.5 Components of BIND (cont’d)
7. A caching-only name server loads the addresses of a few important
machines (servers for the root domain) from a startup file and gets
all the rest of its data by caching answers to the queries it resolves.
8. A caching-only name server is a non-authoritative name server.
9. An authoritative answer is “guaranteed” to be accurate, while a
non-authoritative answer may be out of date.
10. Caching-only servers can reduce the amount of DNS traffic on the
networks
11. Even “authoritative” answers can be inconsistent if a sysadmin
changes the primary name server’s data and forgets to update the
secondaries.
16.5 Components of BIND (cont’d)
12. The Resolver Library:
Before DNS, hostname mappings were looked up in /etc/hosts by
two library routines : gethostbyname and gethostbyaddr
In order for this information to be provided by DNS, these routines
must change, either integrated into the system’s C library, libc.a or
put in their own library, libresolv.a
13. Shell Interface :
The nslookup command allows you to access DNS from a shell. It
is much as the grep command used to look up a hostname in
/etc/hosts
16.6 How DNS Works
1. Name servers are either “recursive” or “non-recursive”
2. A non-recursive server is a lazy, half-hearted server.
In the case that a non-recursive server has no answer cached froma
previous query and it is not the authoritative server, it will provide
a referral to authritative servers of another domain that are more
likely to know the answer. The client will follow the referral to get
the answer.
3. A recursive server returns only real answers and error messages. It
follows referral itself.
16.6 How DNS Works (cont’d)
4. Here is a real example
Suppose we look up the address for mammoth.cs.berkeley.edu
from the machine lair.cs.colorado.edu
1-Q
lair
2-Q
ns.cs.colorado
8-A
3-R
7-A
START
edu
4-Q
6-A
cs.berkeley
berkeley
5-Q
Recursive
Non-Recursive
16.7 Caching and Efficiency
1. Caching increases the efficiency of lookups
2. A cached answer is almost free and usually correct because
mappings change infrequently
3. Most queries are for local hosts and can be resolved quickly
4. Many queries are repeated.
16.8 BIND Client Issues
1. Configuring the Resolver :
Each BIND client must have a file called /etc/resolv.conf that lists
the name servers to query. The format of resolv.conf is :
; Comment
search domainname …
nameserver ipaddr
this is an example:
search cs.colorado.edu colorado.edu
; ns, piper, boulder
nameserver 128.138.243.151
nameserver 128.138.204.4
nameserver 128.138.240.1
16.8 BIND Client Issues (cont’d)
2. Testing the Resolver
After configuring /etc/resolv.conf, we can test name lookups by
either nslookup or dig.
3. Impact on the Rest of the System
Changing from static host tables to DNS creates some
dependencies that we need to protect against. Three particular
areas are affected :
booting, configuration files and mail delivery
16.9 Setting Up a Name Server
1. Complete configuration for named consists of the boot file, the
cach file and for primary servers, the data file or files containing
address
/etc/named.boot : the boot file
The format of the named.boot file is as followings:
directory
cache
primary
secondary
dirname
.
zone
zone
filename
filename
ipaddr […] filename
16.9 Setting Up a Name Server (cont’d)
The directory keyword specifies that all subsequent filenames
are relative to the listed directory
the cache keyword specifies the name of the file that contains
root name servers and their addresses.
The primary keyword indicates that this host is the primary
server for specified zone and that data for the zone is in
filename
The secondary keyword says that this host is secondary
server for zone
16.10 The DNS Database
A domain’s DNS database is a set of text file maintained by the
system administrator on the domain’s primary name server.
Items stored in the database are called resource records
The basic format of a resource record is
[name] [ttl] [class] type data
The name field identifies the entity that the record describes
The ttl (time to live) field specifies the time, in seconds, that the
data item can be cached and still be considered valid
Class specifies the network type such as IN, CH, HS
16.10 The DNS Database
The type field specify the type of the resource records, which is
grouped into three groups:
Zone records : identify domains and their name servers
Basic records : map names to addresses and route mail
Optional records : provide extra information about hosts
The content of the data field depend on the record type. Record types
are listed in Table 16.5 on page 333.