Lect 03 - Domain Name System (DNS)

Technical Support Fundamentals (ITP 4107)
DOMAIN NAME SYSTEM (DNS)
Domain Name System (DNS)

Topic 03,p.1
©VTC 2012
LESSON INTENDED LEARNING OUTCOMES

On completion of the lesson, students are expecte
d to
 setup, configure, monitor and control appropriat
e TCP/IP network services for satisfying given r
equirements.

Topic 03,p.2
©VTC 2012
OVERVIEW
 Names and Addresses
 DNS Domains
 BIND
 Configuring DNS
 Testing of DNS Resolution

Topic 03,p.3
©VTC 2012
NAMES, ADDRESSES, AND ROUTES

 The Internet Protocol document defines names,
addresses, and routes as follows:
 A name indicates what we seek.
 An address indicates where it is.
 A route indicates how to get there.

Topic 03,p.4
©VTC 2012
DNS DOMAINS
 Everyone in the world has a first name and a l
ast (or family) name.
 The same thing is true in the DNS world: A fam
ily of Web sites can be loosely described as a
domain.
 For example, the domain vtc.edu.hk has a numbe
r of children, such as cwvideo.vtc.edu.hk, cwc
im.vtc.edu.hk as well as www.vtc.edu.hk.

Topic 03,p.5
©VTC 2012
NAME AND ADDRESS

 Every network interface attached to a TC
P/IP network is identified by a unique 3
2-bit IP address.
 A name (called a hostname) can be assign
ed to any device that has an IP address.
 Names are assigned to devices because, c
ompared to numeric Internet addresses, n
ames are easier to remember and type cor
rectly.
 Names aren't required by the networking
software, but they do make it easier for
humans to use the network.

Topic 03,p.6
©VTC 2012

 There are two common methods for transl
ating names into IP addresses:
1) The older method simply looks up the ho
stname in a table called the host table
.
2) The newer technique uses a distributed
database system called the Domain Name
System (DNS) to translate names to addr
esses.

Topic 03,p.7
©VTC 2012
THE HOST TABLE

 The host table is a simple text file that assoc
iates IP addresses with hostnames.
 On most Unix systems, the table is in the file
/etc/hosts.
 On MS Windows systems, the table is in the file
WINDOWS\system32\drivers\etc\hosts
 Each table entry in /etc/hosts contains an IP a
ddress separated by whitespace from a list of h
ostnames associated with that address.
 Comments begin with the character #.

Topic 03,p.8
©VTC 2012
WHY USE HOST TABLE

 Most systems have a small host table contai
ning name and address information about the
important hosts on the local network.
 This small table is used when DNS is not ru
nning, such as during the initial system st
artup.
 Even if we use DNS, we should create a sm
all /etc/hosts file containing entries fo
r our host, i.e. localhost, and for the g
ateways and servers on the local network.

Topic 03,p.9
©VTC 2012
WHY USE HOST TABLE

 Very small sites that are not connecte
d to the Internet sometimes use the ho
st table.
 If there are few local hosts and the info
rmation about those hosts rarely changes,
and there is also no need to communicate
via TCP/IP with remote sites, then there
is little advantage of using DNS.

Topic 03,p.10
©VTC 2012
WEAKNESSES OF THE HOST TABLE

 The old host table system is inadequat
e for the global Internet for two reas
ons:
a. inability to scale and
b. lack of an automated update process

Topic 03,p.11
©VTC 2012

 DNS overcomes both major weaknesses
of the host table:
DNS scales well.
DNS guarantees that new host informat
ion will be disseminated to the rest
of the network as it is needed.

Topic 03,p.12
©VTC 2012
DNS CLIENTS
A DNS client doesn't store DNS informati
on; it must always refer to a DNS server
to get it.
 The only DNS configuration file for a DN
S client is the /etc/resolv.conf file, w
hich defines the IP address of the DNS s
erver and the DNS domain name.
 There is no need to configure any other
files.

Topic 03,p.13
©VTC 2012
HOW DNS WORKS

1. If a DNS server receives a request for
information about a host for which it
has no information, it passes on the r
equest to an authoritative server.
 An authoritative server is any server resp
onsible for maintaining accurate informati
on about the domain being queried.
2. When the authoritative server answers,
the local server saves, or caches, the
answer for future use.

Topic 03,p.14
©VTC 2012
3. The next time the local server receive

s a request for this information, it a
nswers the request itself.
4. The ability to cache host information
from an authoritative source and to au
tomatically disseminate accurate infor
mation makes DNS superior to the host
table, even for networks not connected
to the Internet.

Topic 03,p.15
©VTC 2012
THE DOMAIN HIERARCHY

 DNS is a distributed hierarchical system
for resolving hostnames into IP addresse
s.
 Under DNS, there is no central database
with all of the Internet host informatio
n.
 The information is distributed among tho
usands of name servers organized into a
hierarchy similar to the hierarchy of th
e Unix file-system.
Topic 03,p.16
©VTC 2012
ROOT DOMAIN
 DNS has a root domain at the top of the
domain hierarchy that is served by a gro
up of name servers called the root serve
rs.
 Information about a domain is found by t
racing pointers from the root domain thr
ough subordinate domains to the target d
omain.

Topic 03,p.17
©VTC 2012
TOP-LEVEL DOMAINS
 Directly under the root domain are the
top-level domains (TLDs).
 There are two types of top-level domain
s: geographic and organizational.

Topic 03,p.18
©VTC 2012
GEOGRAPHIC DOMAINS
 Geographic domains have been set aside f
or each country in the world and are ide
ntified by a two-letter country code.
 Thus, this type of domain is called a co
untry code top-level domain (ccTLD).
 For example, the ccTLD for the Hong Kong
is .hk, for Japan it is .jp, and for the
United Kingdom it is .uk.

Topic 03,p.19
©VTC 2012
ORGANIZATIONAL DOMAINS
 Organizational domain: membership in a
domain is based on the type of organizat
ion (commercial, military, etc.) to whic
h the system belongs.
 These domains are called generic top-lev
el domains or general-purpose top-level
domains (gTLDs).

Topic 03,p.20
©VTC 2012
OFFICIAL GENERIC TOP-LEVEL DOMAINS

 com
 Commercial organizations
 edu
 Educational institutions
 gov
 Government agencies
 mil
 Military organizations
 net
 Network support organizations, such as network operat
ion centers
 int
 International governmental or quasi-governmental orga
nizations
Topic 03,p.21
©VTC 2012
 org
 Organizations that don't fit into any of the above, such a
s nonprofit organizations
 aero
 Organizations involved in the air-transport industry
 biz
 Businesses
 coop
 Cooperatives
 museum
 Museums
 pro
 Professionals, such as doctors and lawyers
 info
 Sites providing information
 name
 Individuals

Topic 03,p.22
©VTC 2012
DOMAIN HIERARCHY
No servers, not even the root servers, have complete information about all domains,
but the root servers have pointers to the servers for the top-level domains. So while
the root servers may not know the answer to a query, they know who to ask.

Topic 03,p.23
©VTC 2012
CREATING DOMAINS AND SUBDOMAINS

 ICANN, the Internet Corporation for Assigned Names a
nd Numbers, accredits various agencies to be part of
its shared registry project for registering names in
the gTLDs such as com, net, and org.
 Check icann.org for the definitive list of the agenc
ies. ICANN is in the process of creating many more g
TLDs.
 To register for a ccTLD name, check the IANA (Intern
et Assigned Numbers Authority) web page iana.org/cct
ld to find the registry in charge of a particular co
untry’s registration.
 Once the authority to create a domain is granted, ad
ditional subdomains can be created under local contr
ol.
Topic 03,p.24
©VTC 2012
NAME SERVER (NS) RECORD

A new subdomain becomes accessible when
pointers to the servers for the new subd
omain are placed in the domain above it.
 The DNS database record that points to t
he name servers for a domain is the NS
(name server) record.
 This record contains name of the domain
and the name of the host that is a serve
r for that domain.

Topic 03,p.25
©VTC 2012
RECURSIVE AND NONRECURSIVE SERVERS

 Name servers are either recursive or nonrecursive.
 If a nonrecursive server has the answer to a query
cached from a previous transaction or is authorita
tive for the domain to which the query pertains, i
t provides an appropriate response. Otherwise, ins
tead of returning a real answer, it returns a refe
rral to the authoritative servers of another domai
n that are more likely to know the answer.
A client of a nonrecursive server must be prepared
to accept and act on referrals.
 The remote servers are examples of nonrecursive se
rvers (see next slide).
 Remote servers tell the local server who to ask nex
t.
Topic 03,p.26
©VTC 2012

Topic 03,p.27
©VTC 2012
RECURSIVE QUERY

Topic 03,p.28
©VTC 2012
DNS: ITERATIVE QUERY

 With iterative query, a DNS server, i
Iterative
f the requested information is not fo Query
und, . NS
 It replies with an answer in the form
.com NS
of a referral (a link to another DNS
server) For example: abc.com NS
a DNS server (NS) n asks the root name s
erver for www.abc.com, the root name ser
ver replies with a list of com NSs.
 n asks a com NS for www.abc.com, the com DNS
NS tells n the NS for abc.com Server
 n asks abc.com NS for www.abc.com, the a

bc.com NS tells n the IP address of www.
abc.com
Topic 03,p.29
©VTC 2012
RECURSIVE AND NONRECURSIVE SERVERS

 A recursive server returns only real answers and erro
r messages. It follows referrals itself, relieving cl
ients of this responsibility. In other respects, the
basic procedure for resolving a query is essentially
the same.
 The local server is an example of a recursive server.
 The local server follows the pointers and returns
the final answer for the query to the client.
 Authoritative-only servers (e.g., root servers
and top-level domain servers) are all nonrecur
sive, but since they may process tens of thous
ands of queries per second, they have good rea
son not to take on extra work.
Topic 03,p.30
©VTC 2012
A DNS QUERY
Non-recursive Servers
Local server has no information,
so it queries a root server
Recursive Server
2 NS records and 1 A record will be cached in the local server

Topic 03,p.31
©VTC 2012
DOMAIN NAMES
 Domain names reflect the domain hierarchy.
 They are written from most specific (a hostname) to
least specific (a top-level domain), with each part
of the domain name separated by a dot (.).
 A fully qualified domain name (FQDN) starts with a s
pecific hostname and ends with a top-level domain. E
xample:
 cwcim.vtc.edu.hk is the FQDN of server cwcim, in the vtc
domain, of the edu domain under hk.
 A “domain” is a subtree of the DNS naming tree. Fo
r example, the atrust.com domain contains atrust.com
and all of atrust.com’s subdomains and hosts. By co
ntrast, a “zone” is a domain minus any subdomains
that have been delegated to other name servers.
Topic 03,p.32
©VTC 2012
DOMAIN NAMES
 Name servers are associated with zones, not domains. Yo
u can determine whether a given name (such as booklab.a
trust.com ) identifies a subdomain rather than a host b
y checking DNS. Subdomains have name server (NS) record
s associated with them.
 Domain names are not always written as fully qualified
domain names.
 They can be written relative to a default domain in the
same way that Unix pathnames are written relative to th
e current (default) working directory.
 DNS adds the default domain to the user input when cons
tructing the query to the name server.
 e.g. if the default domain is vtc.edu.hk, a user can
omit the vtc.edu.hk extension for any hostname in tha
t domain.
 On most systems, the default domain name is added only
if there is no dot (.) in the requested hostname.
Topic 03,p.33
©VTC 2012
BIND: RESOLVER AND NAME SERVER

 The implementation of DNS used on Unix sy
stems is the Berkeley Internet Name Domai
n (BIND) software.
 DNS software is conceptually divided into
two components—a resolver and a name ser
ver.
 The resolver is the software that forms the q
uery; it asks the questions.
 The name server is the process that responds
to the query; it answers the questions.

Topic 03,p.34
©VTC 2012
RESOLVER
 The resolver does not exist as a distinc
t process running on the computer.
 The resolver is a library of software ro
utines (called the resolver code) that i
s linked into any program that needs to
look up IP addresses; e.g. web browser.
 Under BIND, all computers use the resolv
er code, but not all computers run the n
ame server process.

Topic 03,p.35
©VTC 2012
NAME SERVER
 The BIND name server runs as a distinc
t process called named.
 Name servers are classified differentl
y depending on how they are configured
.
 The three main categories of name serv
ers are:
a) Master,
b) Slave, and
c) Caching-only

Topic 03,p.36
©VTC 2012
(A) MASTER NAME SERVER

 The master server (also called the prima
ry server) is the server from which all
data about a domain is derived.
 The master server loads the domain infor
mation directly from a disk file created
by the domain administrator.
 Master servers are authoritative.
 There should be only one master server f
or a zone.

Topic 03,p.37
©VTC 2012
(B) SLAVE NAME SERVER

 Slave servers (also known as secondary se
rvers) get the entire domain database fro
m the master server.
 A particular database file for a zone is
called a zone file; copying this file to
a slave server is called a zone file tran
sfer.
 A slave server assures that it has curren
t information about a zone by periodicall
y transferring the zone file.
 Slave servers are also authoritative for
their zone.
Topic 03,p.38
©VTC 2012
(C) CACHING-ONLY NAME SERVER

 Caching-only servers get the answers to a
ll name queries from other name servers.
 Once a caching server has received an ans
wer to a query, it caches the information
and will use it in the future to answer q
ueries itself.
 Caching servers are non-authoritative, me
aning that their information is second-ha
nd and incomplete, though usually accurat
e.

Topic 03,p.39
©VTC 2012
WHEN TO USE CACHING NAME SERVER

 Most clients don't ask authoritative ser
vers directly, they usually ask a cachin
g name server on behalf.
 The caching name server then stores (or
caches) the most frequently requested in
formation to reduce the lookup overhead
of subsequent queries.

Topic 03,p.40
©VTC 2012
BIND CONFIGURATIONS
 Basic BIND configuration tasks:
 Configuring the BIND resolver
 Configuring the BIND name server (named)
 Constructing the name server database files,
called the zone files
 RFC 1033, the Domain Administrators Operati
ons Guide, defines the basic set of standar

d records used to construct zone files.

Topic 03,p.41
©VTC 2012
BIND CONFIGURATIONS
 The four levels of service :
a. resolver-only systems (DNS clients),
b. master servers,
c. slave servers, and
d. caching-only servers.
 The resolver is the code that asks nam
e servers for domain information
 On Unix systems, it is implemented as a li
brary rather than as a separate client pro
gram.

Topic 03,p.42
©VTC 2012
(A) RESOLVER-ONLY SYSTEMS ( DNS CLIENT

S)
 Use only the resolver; they don't run a
name server.
 Resolver-only systems are very easy to c

onfigure: just need to set up the /etc/r
esolv.conf file

Topic 03,p.43
©VTC 2012
(B) MASTER NAME SERVER

 The authoritative source for all informatio
n about a specific zone
 Loads the zone information from a locally m
aintained disk file that is built by the do
main administrator.
 Requires creating a complete set of configu
ration files:
1. zone files for the forward-mapping zone and
the reverse-mapping zone,
2. the configuration file,
3. the root hints file, and
4. the loopback file.
Topic 03,p.44
©VTC 2012
SAMPLE CONFIGURATION OF MASTER SERVER

# transfer range
allow-transfer {localhost; 192.168.19.0/24;}; /etc/named.conf
# recursion range
allow-recursion {localhost; 192.168.19.0/24;};
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
/* Forward lookups of hostnames in my domain (ADD) */
zone “mysite.com" IN {
type master;
file “mysite.zone";
};
/* Reverse lookups of IP addresses in my domain (ADD) */
zone "142.168.192.in-addr.arpa" {
type master;
file “192-168-142.zone";
}; allow-recursion defines a match list of IP addresses which are
allowed to issue recursive queries to the server.
Topic 03,p.45
©VTC 2012
(C) SLAVE NAME SERVER

 Transfers a complete set of zone files
from the master server – zone transfe
r.
 Considered as an authoritative server.
 Zone files are downloaded from the mas

ter server.
 Other files (a boot file, a cache file
, and a loopback file) are required to
be created.

Topic 03,p.46
©VTC 2012
SAMPLE CONFIGURATION OF SLAVE SERVER
/* Forward lookups of hostnames in my domain (ADD) */

zone “mysite.com" IN {
type slave;
masters { 192.168.142.137; }; /etc/named.conf
file "slaves/mysite.zone";
};
/* Reverse lookups of local IP addresses in my domain (ADD) */

zone "142.168.192.in-addr.arpa" {
type slave;
masters { 192.168.142.137; };
file "slaves/192-168-142.zone";
};

Topic 03,p.47
©VTC 2012
(D) CACHING-ONLY NAME SERVER

 Runs the name server software but keeps no zone
files.
 It learns the answer to every name query from s
ome remote server.
 Once it learns an answer, the server caches the
answer and uses it to answer future queries for
the same information.
 Not considered as an authoritative server, beca
use all of the information it provides is secon
d-hand and incomplete.
 Only a boot file and a cache file are required.

Topic 03,p.48
©VTC 2012
SAMPLE CONFIGURATION OF CACHING SERVER
// List all the nameservers which you can query.

forwarders { 192.168.142.137; 192.168.142.128; };
/etc/named.conf

Topic 03,p.49
©VTC 2012
CONFIGURING THE RESOLVER

 /etc/resolv.conf
 The resolv.conf file is read when a proc

ess using the resolver starts, and is ca
ched for the life of that process.
 If the configuration file is not found,
the resolver attempts to connect to the
named server running on the local host.

Topic 03,p.50
©VTC 2012
SAMPLE CONFIGURATION OF RESOLVER

# Domain name resolver configuration file
#
search mysite.com /etc/resolv.conf
nameserver 192.168.142.137
nameserver 192.168.142.128
 The nameserver entries identify, by IP addresse
s, the name servers that the resolver is to que
ry for domain information.
 The search entry defines a series of domain nam
es to be searched when a hostname does not cont
ain a dot (.)

Topic 03,p.51
©VTC 2012
CONFIGURING NAMED
 Several files are used to configure named
1. The configuration file (boot file): /etc/n
amed.conf
 Sets general named parameters and points to th
e sources of DNS database information (zone fi
les) used by this server. These source files c
an be on local disk or remote servers.
2. The root hints file (cache file): named.ca
, db.cache, named.root, or root.ca
 Points to the root domain servers.
3. The localhost file (loopback file): named.
localhost
 Used to locally resolve the loopback address.
Topic 03,p.52
©VTC 2012
CONFIGURING NAMED
4. Forward-mapping zone file – forward zone file
 The zone file that maps hostnames to IP addresse
s. This is the file that contains the bulk of th
e information about the zone. The zone file is g
enerally given a descriptive name, such as mysit
e.zone, that identifies which zone data is conta
ined in the file.
5. Reverse-mapping zone file – reverse zone file

 The zone file that maps IP addresses to hostname
s. The reverse zone file is generally given a de
scriptive name, such as
192-168-142.zone, that identifies which IP addre
sses are mapped by the file.

Topic 03,p.53
©VTC 2012
SAMPLE FORWARD ZONE FILE

; filename: na035.com.zone
$TTL 3D
@ IN SOA ns1.na035.com. hostmaster.na035.com. (
2004100841 ; serial #
4H ; refresh
1H ; retry
1W ; expiry
10 before MX is priority #
1D ) ; minimum
IN NS ns1
IN MX 10 mail
; Firstly, DNS server:
ns1 IN A 192.168.19.35
; FTP server:
@ by default
ftp IN A 192.168.19.7
; Aliases:
www IN CNAME ns1
mail IN CNAME ns1
Topic 03,p.54
©VTC 2012
SAMPLE REVERSE ZONE FILE

; Filename: 192-168-19.zone
;
$TTL 3D
@ IN SOA ns1.na035.com. hostmaster.na035.com. (
200303301 ; serial number
8H ; refresh
2H ; retry
4W ; expire
1D ) ; minimum
;
IN NS ns1.na035.com. ; Nameserver Address
;
35 IN PTR www.na035.com.
7 IN PTR ftp.na035.com.

Topic 03,p.55
©VTC 2012
DNS RECORD TYPES

 Type: SOA
Start of Authority
This record defines a zone
Each zone has exactly one SOA record
Specifies
 The master name server for the zone
 The zone administrator’s email address
 Slave server update information
Typically is the first RR in zone fil

e
Should be an SOA for both forward &
reverse
Domain Name System (DNS) zone files Topic 03,p.56
©VTC 2012
DNS RECORD TYPES

 Type: NS
Name server record
Identifies authoritative servers for t
he zone
i.e. the master and all slaves
Used by named to identify slaves for z
one changes
Typically comes immediately after SOA
record
@ IN NS ns1.na035.com.
@ IN NS ns2.na035.com.
Topic 03,p.57
©VTC 2012
DNS RECORD TYPES

 An MX (mail exchange) record maps a domain name
to a list of mail exchange servers for that dom
ain.
 An A (address) record maps a hostname to a 32-b
it IPv4 address.
 A CNAME (canonical name) record
 Assigns a nickname to a host's real name,
i.e. an alias
 Other records must use real names
 A PTR (pointer) record maps an IPv4 address to
the name for that host.

Topic 03,p.58
©VTC 2012
BASIC TESTING OF DNS RESOLUTION

 DNS resolution maps a fully qualified dom
ain name (FQDN), such as www.vtc.edu.hk,
to an IP address.
 This is also known as a forward lookup.
 The reverse is also true: By performing a

reverse lookup, DNS can determining the f
ully qualified domain name associated wit
h an IP address.

Topic 03,p.59
©VTC 2012
COMMANDS FOR TESTING DNS RESOLUTION

 There are a number of commands to
do these lookups:
host
dig
nslookup

Topic 03,p.60
©VTC 2012
TROUBLESHOOTING BIND
1. Determine whether the DNS server is
accessible on DNS UDP/TCP port 53.
 Lack of connectivity could be caused b
y a firewall with incorrect permit, NA
T, or port forwarding rules to the DNS
server.
 Failure could also be caused by the na
med process being stopped. It is best
to test this both inside the network a
nd outside from the Internet.

Topic 03,p.61
©VTC 2012
2. Linux status messages are logged
to the file /var/log/messages.
 Use it to make sure all your zone f
iles are loaded when you start the
named.
 Check your /etc/named.conf file if
they fail to do so.

Topic 03,p.62
©VTC 2012
 Use the host (nslookup in Windows) comman
d for both forward and reverse lookups to
make sure the zone files were configured
correctly.

Topic 03,p.63
©VTC 2012
FURTHER DIAGNOSIS
 Double check the serial numbers in the m
odified zone files are updated, and also
inspect the individual records within th
e files for mistakes.
 Ensure there is not a firewall that coul
d be blocking DNS traffic on TCP and/or
UDP port 53 between the host and the DNS
server.
 Use the dig command to determine whether
the name server for the domain is config
ured correctly.
Topic 03,p.64
©VTC 2012
POSSIBLE CAUSES OF FAILURE

1. Typographical errors. In this case, th
e misspelling was entered through keyb
oard.
2. Incorrect domain registration.
3. Correct domain registration, but there
is a lag in the propagation of the dom
ain information across the Internet. D
elays of up to four days are common.
4. A firewall could be blocking DNS traff
ic on TCP and/or UDP port 53 between t
he host and the DNS server.
Topic 03,p.65
©VTC 2012
SUMMARY
 Names and Addresses
 DNS Domains
 BIND
 Configuring DNS
 Testing of DNS Resolution
 Troubleshooting BIND

Topic 03,p.66
©VTC 2012

Lect 03 - Domain Name System (DNS)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lect 03 - Domain Name System (DNS)

Uploaded by

Copyright:

Available Formats

Technical Support Fundamentals (ITP 4107)

DOMAIN NAME SYSTEM (DNS)

Domain Name System (DNS)

LESSON INTENDED LEARNING OUTCOMES

Domain Name System (DNS)

 Testing of DNS Resolution

Domain Name System (DNS)

NAMES, ADDRESSES, AND ROUTES

Domain Name System (DNS)

Domain Name System (DNS)

NAME AND ADDRESS

Domain Name System (DNS)

DOMAIN NAME SYSTEM (DNS)

Domain Name System (DNS)

THE HOST TABLE

Domain Name System (DNS)

WHY USE HOST TABLE

Domain Name System (DNS)

WHY USE HOST TABLE

Domain Name System (DNS)

WEAKNESSES OF THE HOST TABLE

Domain Name System (DNS)

DOMAIN NAME SYSTEM (DNS)

Domain Name System (DNS)

Domain Name System (DNS)

HOW DNS WORKS

Domain Name System (DNS)

3. The next time the local server receive

Domain Name System (DNS)

THE DOMAIN HIERARCHY

Domain Name System (DNS)

Domain Name System (DNS)

Domain Name System (DNS)

Domain Name System (DNS)

OFFICIAL GENERIC TOP-LEVEL DOMAINS

Domain Name System (DNS)

Domain Name System (DNS)

CREATING DOMAINS AND SUBDOMAINS

NAME SERVER (NS) RECORD

Domain Name System (DNS)

RECURSIVE AND NONRECURSIVE SERVERS

Domain Name System (DNS)

Domain Name System (DNS)

DNS: ITERATIVE QUERY

 n asks abc.com NS for www.abc.com, the a

RECURSIVE AND NONRECURSIVE SERVERS

2 NS records and 1 A record will be cached in the local server

Domain Name System (DNS)

BIND: RESOLVER AND NAME SERVER

Domain Name System (DNS)

Domain Name System (DNS)

Domain Name System (DNS)

(A) MASTER NAME SERVER

Domain Name System (DNS)

(B) SLAVE NAME SERVER

(C) CACHING-ONLY NAME SERVER

Domain Name System (DNS)

WHEN TO USE CACHING NAME SERVER

Domain Name System (DNS)

ons Guide, defines the basic set of standar

Domain Name System (DNS)

Domain Name System (DNS)

(A) RESOLVER-ONLY SYSTEMS ( DNS CLIENT

 Resolver-only systems are very easy to c