Transcript TCP/IP Protocol Suite

DECUS Europe 2000
Domain Name System
Introduction And Overview
Tuesday, 11 Apr 2000
4:00 - 4:45
Jeff Schreiber
[email protected]
1
©1997-2000 Process Software
Brief History Lesson

How it worked
– Started as a single file in ARPANET
– Updated a couple times a week
– All systems transferred file from a single host

What went wrong
– More additions = more load on host
– Large delay from change to update
– Larger delay from update to full transfer
2
“And then there were many”

The Solution to the problem in 1984
– RFCs 882 and 883 originally
– Updated by RFCs 1034 and 1035

Distributed database
–
–
–
–
Allows local control
dispersed load and maintenance
Client & Server architecture
Hierarchical approach to name resolution
3
How Hierarchy works
.
[root]
us
ca.us
org
com
arpa
decus.org
foo.com
in-addr.arpa
ma.us
edu
unh.edu
sales.foo.com
eng.foo.com
boston.ma.us
ref.eng.foo.com
4
dev.eng.foo.com
test.eng.foo.com
bu.edu
Basic Design

Client / Server Architecture
– Resolver (Client)
 Initiates
questions
– Nameserver (Server and Client)
 Listens
for questions
 Answers questions
 Caches information
 Delegates authority
 forwards questions (acting as a client)
5
DNS Resolvers





Accessed by way of programming libraries
Configured with a list of default nameservers
Relies on nameserver to find answer
Generally doesn’t cache answers
Often will look in local ‘hosts’ file before
sending question
6
Local vs. fully qualified

Resolver determines order of attempts
– Uses number of dots to determine action

Some resolvers allow number to be configurable
– local (append domain)

Some resolvers allow multiple domain search lists
– fully qualified (as is)


Trailing dot interpreted as ‘fully qualified’ only
Some have special actions
– e.g. Netscape Browsers
7
www.<name>.com
local vs. fully qualified
Name asked for
Resolver Looks up
krypto
Assumed local
krypto.
Trailing dot = fully qualified
krypto.foo.com
# dots >= 1, assumed fully qualified
krypto.foo.com.
Trailing dot = fully qualified
Name asked for
krypto
1) krypto.foo.com
2) krypto
1) krypto
1) krypto.foo.com
2) krypto.foo.com.foo.com
1) krypto.foo.com
Netscape Resolver
Assumed local
8
1) krypto.foo.com
2) krypto
3) www.krypto.com
Resolving with Search Lists
Host: cozmo.hub.foo.com
Search List:
Name asked for
cozmo
cozmo.hub
foo.com hub.foo.com test.foo.com
Resolver Looks up
1) cozmo.foo.com
3) cozmo.test.foo.com
2) cozmo.hub.foo.com
4) cozmo
1) cozmo.hub
3) cozmo.hub.hub.foo.com
2) cozmo.hub.foo.com
4) cozmo.hub.test.foo.com
With the number of dots configured to be 2
cozmo.hub
1) cozmo.hub.foo.com
3) cozmo.hub.test.foo.com
9
2) cozmo.hub.hub.foo.com
4) cozmo.hub
Two types of delegation

Non-Recursive Query

– server gives hint if no
answer
– client asks other servers
based on hints working
down name hierarchy
– generally only
nameservers work as
non-recursive resolvers
Recursive Query
– client asks server to ‘find’
answer
– most resolvers can only
do recursive queries
– most servers working as
clients won’t use
recursion
10
Non-Recursive Queries
1
“www.eng.foo.com?”
“Ask root server”
3
2
“www.eng.foo.com?”
“Ask .com server”
5
Non-Recursive
Server
Root
Server
4
“www.eng.foo.com?”
.com
Server
Client
“Ask ns.foo.com server”
7
“www.eng.foo.com?”
“Ask ns.eng.foo.com server”
9
6
ns.foo.com
Server
8
“www.eng.foo.com?”
“Yea… That’s 10.0.0.123”
11
ns.eng.foo.com
Server
10
Recursive Queries
“www.eng.foo.com?”
3
4
.com
Server
“www.eng.foo.com?”
“Yea… That’s 10.0.0.123”
8
“Yea… That’s 10.0.0.123”
Root
Server
“www.eng.foo.com?”
2
7
ns.foo.com
Server
“www.eng.foo.com?”
9
5
6
“Yea… That’s 10.0.0.123”
Recursive
Server
“Yea… That’s 10.0.0.123”
10
“Yea… That’s 10.0.0.123”
“www.eng.foo.com?”
Client
1
12
ns.eng.foo.com
Server
With some Realism
2
“www.eng.foo.com?”
“(Recursion Desired)”
“www.eng.foo.com?”
“Ask ns.foo.com server”
1
resolver
Default
Server
8
“Yea… That’s 10.0.0.123”
“(Recursion Available)”
4
3
“www.eng.foo.com?”
“Ask ns.eng.foo.com server” 5
6
“www.eng.foo.com?”
“Yea… That’s 10.0.0.123”
13
Root
&
.com
Server
ns.foo.com
Server
ns.eng.foo.com
Server
7
Caching

Saving answers to use in future queries
Most servers cache answers
Most resolvers do not cache answers
caching based on Time To Live (TTL)

Advantages




– Cuts down traffic
– speeds up resolution
Disadvantages
– Memory requirements
– Delay in updates
14
Example with Caching
“cozmo.hub.foo.com?”
Default
Server
Root
&
.com
Server
1
resolver
Cache
6
2
foo.com NS
eng.foo.com NS
“Yea… That’s 10.0.4.13”
“Ask ns.hub.foo.com”
www.eng.foo.com
4
hub.foo.com NS
“cozmo.hub.foo.com?”
ns.foo.com
Server
3
“cozmo.hub.foo.com?”
ns.hub.foo.com
Server
cozmo.hub.foo.com
“Yea… That’s 10.0.4.13”
Default Server has foo.com information cached
15
5
Primary Servers

Actually “Server primary for a zone”
– Primary Servers can also be Secondary servers
– Generally Caching servers as well

Only one Primary server per zone
– rest must be secondary
– Primary maintains the database file

Authoritative source for records in zone
16
Secondary Servers

Actually “Server with Secondary Zones”
– Can be Primary for other zones
– Generally are Caching Servers as well

Knows primary and/or other secondaries
– Uses that information to download zone data
– can fail over to other authoritative servers if
updates can’t be obtained from primary


Only maintains a ‘backup’ copy of the zone
Will loose authority if updates can’t be
obtained
17
Zone Transfer


How Secondary servers download zone info
Secondary requests transfer
– Done by invoking an xfer process
– Requests SOA record first to see if xfer needed
– Often limits the number of simultaneous transfers

Can be requested other ways
– Nslookup’s “ls” command
– other “show zone”-style commands

Actually an AXFR record query
18
Basic setup
The Great Beyond
Zone Primary
Server
Internal
Secondary
Internal
Secondary



Secondary servers transfer off of primary
Secondaries & primary query network
Queries from network come into primary
19
Forwarders and Forwarding

Forwarding servers ‘forward’ unknown
questions.
– Most servers ‘forward’ to root servers
– Some servers can be configured with a list of
forwarders.

Use of Forwarders
– centralized caching
– servers behind firewalls
– Internal root servers
20
Centralized Caching
1
Forwarder
Server
“cozmo.foo.com?”
Forwarding
Server
[Answer]
7
2
[Referral]
6
“meatz.foo.com?”
foo.com NS
[Answer]
11
cozmo.foo.com
12 “cozmo.foo.com?”
meatz.foo.com
Forwarding
Server
[Answer]
Root
Servers
3
Cache
4
Forwarding
Server
“cozmo.foo.com?”
“cozmo.foo.com?”
[Answer]
9
“meatz.foo.com?”
[Answer]
13
21
5
10
Domain
Servers
Forwarding Setup
The Great Beyond
Zone Primary
Server
Internal
Secondary





Secondary servers transfer off of primary
Secondaries forward to primary
Primary queries network
Queries from network come into primary
Secondaries query network if primary doesn’t
respond
22
Internal
Secondary
Forward Only Setup
The Great Beyond
Zone Primary
Server
Internal
Secondary
Internal
Secondary





Secondary servers transfer off of primary
Secondaries forward to primary
All queries go through primary
Queries from network come into primary
Secondaries never query through firewall
23
Allow-transfer

Security option in many servers
– Introduced in BIND version 4.9.3 as xfrnets.
– helps prevent unauthorized zone transfers

Allows Domain Administrator to restrict zone
transfer access
– Zone transfer requests only honored from IP
addresses or networks on list.
– BIND 8 versions allow restrictions on per zone
basis as well as per server.
24
bogus servers

Security option in many servers
– Introduced in BIND version 4.9.3
– Helps to filter rogue and problematic nameservers


Nameserver won’t ask questions of servers
configured to be bogus
If bogus server is only server for zone, zone
will be unresolvable.
– E.g. if 10.1.2.3 is the only ns for foo.com, and
10.1.2.3 is flagged as bogus, foo.com addresses
will be unresolvable.
25
SOA Records
@

IN
SOA
cozmo.foo.com. wheelhog.cozmo.foo.com. (
2000041101 ; Serial
[Apr 11th 2000]
3600 ; Refresh
[once every hour]
600 ; Retry
[every 10 minutes]
43200 ; Expire
[after 12 hours]
86400 ) ; Minimum
[TTL of 1 day]
Serial number

– Version number of zone

– How long to go without a
refresh before secondary
stops answering
authoritatively for zone.
Refresh Time
– elapsed for a secondary to
wait before checking for a
serial number change

Expire Time

Minimum
– default TTL for zones
records.
Retry Time
– How long to wait before
retrying a failed transfer
26
Refresh, Retry and Expire
0
3600
1
2
Time
1
0 (00:00)
7200 7800
4
9000
4
4
3
46800
45000
4
4
4
Action Taken
Status
Original Transfer of Zone
Successful
5
2
3600 (01:00)
Start of Authority record checked
No serial change
3
7200 (02:00)
Start of Authority record checked
Serial Change
Here a Tree falls
3
7200 (02:00)
Attempt Transfer of Zone
Failure
4
7800 (02:10)
Retry to Transfer Zone
Failure
every 10 mins
Retry to Transfer Zone
Failure
46800 (13:00)
Zone Expired - Server no longer authoritative
6
27
Adjusting Minimum
Minimum is the default TTL for the data in
the zone file
 The TTL is the maximum time a remote
nameserver will cache a record

Planning changes? Lower your Minimum!
Caching servers will come back more frequently looking for updates
28
Sequence Space
Problem
Solution
Finite Number Space for an
infinite number of modifications
Set up a wrapping sequence space so
there will always be a value 1 more than X
But then 255 + 1 = 0,
which is less than 255?
Sequence Space Arithmetic
0


X + [1..127] is
greater than X.
191
63

X
127
29
Defines a number that can be added
to any number in the sequence and
be greater.
Time is a sequence space (11 is later
than 9, but earlier than 1)
Make sure the difference between 2
serial numbers seen in ‘expire’ time is
less than largest meaningful integer.
That’s all folks…
Any Questions?
30
Mailing Lists and Newsgroups

bind-users
– http://www.isc.org/services/public/lists/bind-lists.html




namedroppers
– Send mail to [email protected]
‘subscribe’ in the subject
comp.protocols.dns.bind
comp.protocols.dns.ops
comp.protocols.tcp-ip
31
Handouts
Slides available via anonymous FTP:
ftp://ftp.process.com/decus/europe_2000/dnsintro.ppt
32
Other References

DNS and BIND Third Edition , Paul Albitz and Cricket Liu, O’Reilly &
Associates, Inc. 1992, 1997, 1998 ISBN #1-56592-512-2




The BOG (Bind Operations Guide) v4.9.4, Paul Vixie,
http://www.dns.net/dnsrd/docs/bog/bog.html
The BIND 8 Online Docs
http://www.multinet.process.com/bind-docs/index.html
DNS Defined - http://www.process.com/ipresources.htm
RFCs
–
–
–
–
–
–
RFC 1034 - Domain Names - Concepts and Facilities
RFC 1035 - Domain Names - Implementation and Specification
RFC 1537 - Common DNS Data File Configuration Errors
RFC 1982 - Serial Number Arithmetic
RFC 1996 - A Mechanism for Prompt Notification of Zone Changes
RFC 2136 - Dynamic Updates in the Domain Name System
33