Home
Contents

Book Fire Online by http://bookfire.net

Prev Page Next Page
 
Main Page
Table of content
Copyright
Preface
Versions
What's New in the Fourth Edition?
Organization
Audience
Obtaining the Example Programs
Contacting O'Reilly
Conventions Used in This Book
Quotations
Acknowledgments
Chapter 1. Background
1.1 A (Very) Brief History of the Internet
1.2 On the Internet and internets
1.3 The Domain Name System in a Nutshell
1.4 The History of BIND
1.5 Must I Use DNS?
Chapter 2. How Does DNS Work?
2.1 The Domain Name Space
2.2 The Internet Domain Name Space
2.3 Delegation
2.4 Name Servers and Zones
2.5 Resolvers
2.6 Resolution
2.7 Caching
Chapter 3. Where Do I Start?
3.1 Getting BIND
3.2 Choosing a Domain Name
Chapter 4. Setting Up BIND
4.1 Our Zone
4.2 Setting Up Zone Data
4.3 Setting Up a BIND Configuration File
4.4 Abbreviations
4.5 Host Name Checking (BIND 4.9.4 and Later Versions)
4.6 Tools
4.7 Running a Primary Master Name Server
4.8 Running a Slave Name Server
4.9 Adding More Zones
4.10 What Next?
Chapter 5. DNS and Electronic Mail
5.1 MX Records
5.2 What's a Mail Exchanger, Again?
5.3 The MX Algorithm
Chapter 6. Configuring Hosts
6.1 The Resolver
6.2 Sample Resolver Configurations
6.3 Minimizing Pain and Suffering
6.4 Vendor -Specific Options
Chapter 7. Maintaining BIND
7.1 Controlling the Name Server
7.2 Updating Zone Data Files
7.3 Organizing Your Files
7.4 Changing System File Locations in BIND 8 and 9
7.5 Logging in BIND 8 and 9
7.6 Keeping Everything Running Smoothly
Chapter 8. Growing Your Domain
8.1 How Many Name Servers?
8.2 Adding More Name Servers
8.3 Registering Name Servers
8.4 Changing TTLs
8.5 Planning for Disasters
8.6 Coping with Disaster
Chapter 9. Parenting
9.1 When to Become a Parent
9.2 How Many Children?
9.3 What to Name Your Children
9.4 How to Become a Parent: Creating Subdomains
9.5 Subdomains of in-addr.arpa Domains
9.6 Good Parenting
9.7 Managing the Transition to Subdomains
9.8 The Life of a Parent
Chapter 10. Advanced Features
10.1 Address Match Lists and ACLs
10.2 DNS Dynamic Update
10.3 DNS NOTIFY (Zone Change Notification)
10.4 Incremental Zone Transfer (IXFR)
10.5 Forwarding
10.6 Views
10.7 Round Robin Load Distribution
10.8 Name Server Address Sorting
10.9 Preferring Name Servers on Certain Networks
10.10 A Nonrecursive Name Server
10.11 Avoiding a Bogus Name Server
10.12 System Tuning
10.13 Compatibility
10.14 The ABCs of IPv6 Addressing
10.15 Addresses and Ports
10.16 IPv6 Forward and Reverse Mapping
Chapter 11. Security
11.1 TSIG
11.2 Securing Your Name Server
11.3 DNS and Internet Firewalls
11.4 The DNS Security Extensions
Chapter 12. nslookup and dig
12.1 Is nslookup a Good Tool?
12.2 Interactive Versus Noninteractive
12.3 Option Settings
12.4 Avoiding the Search List
12.5 Common Tasks
12.6 Less Common Tasks
12.7 Troubleshooting nslookup Problems
12.8 Best of the Net
12.9 Using dig
Chapter 13. Reading BIND Debugging Output
13.1 Debugging Levels
13.2 Turning On Debugging
13.3 Reading Debugging Output
13.4 The Resolver Search Algorithm and Negative Caching (BIND 8)
13.5 The Resolver Search Algorithm and Negative Caching (BIND 9)
13.6 Tools
Chapter 14. Troubleshooting DNS and BIND
14.1 Is NIS Really Your Problem?
14.2 Troubleshooting Tools and Techniques
14.3 Potential Problem List
14.4 Transition Problems
14.5 Interoperability and Version Problems
14.6 TSIG Errors
14.7 Problem Symptoms
Chapter 15. Programming with the Resolver and Name Server Library Routines
15.1 Shell Script Programming with nslookup
15.2 C Programming with the Resolver Library Routines
15.3 Perl Programming with Net::DNS
Chapter 16. Miscellaneous
16.1 Using CNAME Records
16.2 Wildcards
16.3 A Limitation of MX Records
16.4 Dialup Connections
16.5 Network Names and Numbers
16.6 Additional Resource Records
16.7 DNS and WINS
16.8 DNS and Windows 2000
Appendix A. DNS Message Format and Resource Records
A.1 Master File Format
A.2 DNS Messages
A.3 Resource Record Data
Appendix B. BIND Compatibility Matrix
Appendix C. Compiling and Installing BIND on Linux
C.1 Instructions for BIND 8.2.3
C.2 Instructions for BIND 9.1.0
Appendix D. Top-Level Domains
Appendix E. BIND Name Server and Resolver Configuration
E.1 BIND Name Server Boot File Directives and Configuration File Statements
E.2 BIND 4 Boot File Directives
E.3 BIND 8 Configuration File Statements
E.4 BIND 9 Configuration File Statements
E.5 BIND Resolver Statements
Colophon
Index
Index SYMBOL
Index A
Index B
Index C
Index D
Index E
Index F
Index G
Index H
Index I
Index J
Index K
Index L
Index M
Index N
Index O
Index P
Index Q
Index R
Index S
Index T
Index U
Index V
Index W
Index X
Index Y
Index Z
I l@ve RuBoard Previous Section Next Section

1.3 The Domain Name System in a Nutshell

The Domain Name System is a distributed database. This allows local control of the segments of the overall database, yet the data in each segment is available across the entire network through a client-server scheme. Robustness and adequate performance are achieved through replication and caching.

Programs called name servers constitute the server half of DNS's client-server mechanism. Name servers contain information about some segments of the database and make it available to clients, called resolvers. Resolvers are often just library routines that create queries and send them across a network to a name server.

The structure of the DNS database is very similar to the structure of the Unix filesystem, as shown in Figure 1-1. The whole database (or filesystem) is pictured as an inverted tree, with the root node at the top. Each node in the tree has a text label, which identifies the node relative to its parent. This is roughly analogous to a "relative pathname" in a filesystem, like bin. One label—the null label, or ""—is reserved for the root node. In text, the root node is written as a single dot ( .). In the Unix filesystem, the root is written as a slash ( / ).

Figure 1-1. The DNS database versus a Unix filesystem
figs/dns4_0101.gif

Each node is also the root of a new subtree of the overall tree. Each of these subtrees represents a partition of the overall database—a "directory" in the Unix filesystem, or a domain in the Domain Name System. Each domain or directory can be further divided into additional partitions, called subdomains in DNS, like a filesystem's "subdirectories." Subdomains, like subdirectories, are drawn as children of their parent domains.

Like every directory, every domain has a unique name. A domain's domain name identifies its position in the database, much as a directory's "absolute pathname" specifies its place in the filesystem. In DNS, the domain name is the sequence of labels from the node at the root of the domain to the root of the whole tree, with dots separating the labels. In the Unix filesystem, a directory's absolute pathname is the list of relative names read from root to leaf (the opposite direction to DNS, as shown in Figure 1-2), using a slash to separate the names.

Figure 1-2. Reading names in DNS versus in a Unix filesystem
figs/dns4_0102.gif

In DNS, each domain can be broken into a number of subdomains, and responsibility for those subdomains can be doled out to different organizations. For example, Network Solutions runs the edu (educational) domain, but delegates responsibility for the berkeley.edu subdomain to UC Berkeley (Figure 1-3). This is something like remotely mounting a filesystem: certain directories in a filesystem may actually be filesystems on other hosts, mounted from a remote host. The administrator on host winken, for example (again, Figure 1-3), is responsible for the filesystem that appears on the local host as the directory /usr/nfs /winken.

Figure 1-3. Remote management of subdomains and filesystems
figs/dns4_0103.gif

Delegating authority for berkeley.edu to UC Berkeley creates a new zone, an autonomously administered piece of the namespace. The zone berkeley.edu is now independent from edu and contains all domain names that end in berkeley.edu. The zone edu, on the other hand, contains only domain names that end in edu but aren't in delegated zones like berkeley.edu. berkeley.edu may be further divided into subdomains like cs.berkeley.edu, and some of these subdomains may themselves be separate zones if the berkeley.edu administrators delegate responsibility for them to other organizations. If cs.berkeley.edu is a separate zone, the berkeley.edu zone doesn't contain domain names that end in cs.berkeley.edu (Figure 1-4).

Figure 1-4. The edu, berkeley.edu, and cs.berkeley.edu zones
figs/dns4_0104.gif

Domain names are used as indexes into the DNS database. You might think of data in DNS as "attached" to a domain name. In a filesystem, directories contain files and subdirectories. Likewise, domains can contain both hosts and subdomains. A domain contains those hosts and subdomains whose domain names are within the domain.

Each host on a network has a domain name, which points to information about the host (see Figure 1-5). This information may include the IP address, information about mail routing, etc. Hosts may also have one or more domain name aliases, which are simply pointers from one domain name (the alias) to another (the official or canonical domain name). In the figure, mailhub.nv... is an alias for the canonical name rincon.ba.ca....

Figure 1-5. An alias in DNS pointing to a canonical name
figs/dns4_0105.gif

Why all the complicated structure? To solve the problems that HOSTS.TXT had. For example, making domain names hierarchical eliminates the pitfall of name collisions. Each domain has a unique domain name, so the organization that runs the domain is free to name hosts and subdomains within its domain. Whatever name is chosen for a host or subdomain, it won't conflict with other domain names because it ends in the organization's unique domain name. For example, the organization that runs hic.com can name a host puella (as shown in Figure 1-6), since it knows that the host's domain name will end in hic.com, a unique domain name.

Figure 1-6. Solving the name collision problem
figs/dns4_0106.gif

    I l@ve RuBoard Previous Section Next Section
    Linking to Www Google.Com. Host by Book Fire