SYBEX Sample Chapter

Linux DNS Server Administration

(Craig Hunt Linux Library)

by Craig Hunt

The DNS Protocols

Screen reproductions produced with Collage Complete.
Collage Complete is a trademark of Inner Media Inc.

SYBEX, Network Press, and the Network Press logo are registered trademarks of SYBEX Inc.
Mastering, Expert Guide, Developer’s Handbook, and No experience required. are trademarks of SYBEX Inc.

TRADEMARKS: SYBEX has attempted throughout this book to distinguish proprietary trademarks from descriptive terms by
following the capitalization style used by the manufacturer.

Netscape Communications, the Netscape Communications logo, Netscape, and Netscape Navigator are trademarks of
Netscape Communications Corporation.

Microsoft® Internet Explorer ©1996 Microsoft Corporation. All rights reserved. Microsoft, the Microsoft Internet Explorer logo,
Windows, Windows NT, and the Windows logo are either registered trademarks or trademarks of Microsoft Corporation in
the United States and/or other countries.

The author and publisher have made their best efforts to prepare this book, and the content is based upon final release soft-
ware whenever possible. Portions of the manuscript may be based upon pre-release versions supplied by software manufac-
turer(s). The author and the publisher make no representation or warranties of any kind with regard to the completeness or
accuracy of the contents herein and accept no liability of any kind including but not limited to performance, merchantability,
fitness for any particular purpose, or any losses or damages of any kind caused or alleged to be caused directly or indirectly
from this book.

Photographs and illustrations used in this book have been downloaded from publicly accessible file archives and are used in
this book for news reportage purposes only to demonstrate the variety of graphics resources available via electronic access.
Text and images available over the Internet may be subject to copyright and other rights owned by third parties. Online avail-
ability of text and images does not imply that they may be reused without the permission of rights holders, although the
Copyright Act does permit certain unauthorized reuse as fair use under 17 U.S.C. Section 107.

Copyright ©2000 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. World rights reserved. No part of this pub-
lication may be stored in a retrieval system, transmitted, or reproduced in any way, including but not limited to photocopy,
photograph, magnetic or other record, without the prior agreement and written permission of the publisher.
The DNS Protocols
2
A protocol is a set of rules that define how two computers should interact to
exchange information over a network. Exchanging DNS data requires a set of standardized
protocols. Like any distributed database, DNS clients need to retrieve information from the
database and servers need to keep the information in the database accurate and up to date.
Queries require the exchange of questions and answers in agreed-upon formats. Synchro-
nizing databases among distributed servers requires an agreement on when and how the
synchronization is to be done.
The technical details of protocols and packet structure can be complex and intimidating,
particularly if your background is system administration and not network design. A pro-
tocol designer would probably feel the same way if asked to read one of your shell scripts.
If this chapter is not your cup of tea, feel free to jump ahead to more practical chapters. But
if you do, I urge you to come back and read this chapter after you have worked with DNS
configuration. You will find an elegant linkage between the actions you take in configuring
your system and the packets your system puts on the network.
This chapter tells you the rules that DNS uses to exchange information, not so you can
master the protocols but so you can master the DNS servers that depend on these proto-
cols. Understanding how data moves through the network helps in understanding why cer-
tain configuration parameters are required and what can be done to optimize them. Let’s
begin by understanding the protocol suite that DNS is part of.

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

24 Chapter 2 The DNS Protocols

The Internet Protocols Suite

The DNS architecture, described in Chapter 1, is implemented on top of a network archi-
tecture. The network upon which DNS runs is the Internet and the software that makes
the Internet possible is the Internet Protocol (IP) suite. The DNS protocols are part of that
suite.
The Internet Protocol is the foundation of the protocol suite. IP defines the network
addressing, thus the term IP address, and it defines the basic unit of information that
moves though the network. This unit of information is a block of data, called a datagram,
that contains addressing and administrative information, as well as application-specific
data. Because the datagram carries its own addressing information with it, it can move
through the network independent of any other datagram. The benefits of this indepen-
dence are robustness and efficiency. Robustness comes from the fact that each datagram
can choose its own path through the network. If part of the network fails, the datagram
can move around it on any available path. Efficiency comes from the minimal overhead
involved in this scheme. Because each packet is independent, there is no need to keep track
of other packets in the flow, which simplifies processing. The weakness of this indepen-
dence is that sometimes the application data must span multiple datagrams. The IP pro-
tocol does not provide a way to sequence the data across datagrams.
Application programs access the IP protocol through two transport protocols: UDP and
TCP. The User Datagram Protocol (UDP) provides the application with full access to the
strengths of IP. With UDP, an application creates a message that becomes the data por-
tion of a datagram. Each UDP message is an independent entity that moves through the
network without depending on any other message.
The Transport Control Protocol (TCP) offers the application a way to address the weak-
nesses of IP. When an application needs to send a stream of related data, TCP provides
the features necessary for the data to arrive at the remote location reliably and in
sequence. TCP maintains the sequence by embedding sequence numbers in the stream of
transmitted data and ensures reliability by requiring acknowledgements from the remote
end. DNS is a network application that uses both UDP and TCP to send data over IP.
Figure 2.1 shows these protocol layers.

Figure 2.1 Protocol layers from DNS to IP

DNS

UDP TCP

IP

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 The DNS Message 25

The only time DNS uses TCP is when distributed servers synchronize their databases by

How Thnigs Work

transferring entire domain database files. One of the challenges of a distributed database
system is ensuring that all of the servers in that system provide accurate answers. The
backup servers and the master servers must provide information of the same high quality.
DNS keeps each backup server’s data accurate by periodically transferring the entire
domain database from the master server. During a file transfer, many related records are
transmitted and it is important to keep the data in sequence. TCP is perfect for this. It has PART 1
the reliability mechanisms needed to ensure that the entire database is received by the dis-
tributed servers, and it has sequence numbering to guarentee that all of the database
records are received in order.
DNS uses UDP for the majority of its network traffic. It sends queries and receives
responses as UDP packets. Given the critical nature of DNS, some people question the
wisdom of sending DNS data over the unreliable UDP protocol. But the truth is, DNS is
a perfect match for UDP. A DNS query fits into a single UDP packet and so does the
response to the query—one packet is sent and one packet is received. No overhead is
needed to establish a connection and no overhead is needed to sequence records because
each DNS message is an independent entity. The response to the query is the acknowl-
edgment of the request so there is no need to use a separate protocol for acknowledg-
ments. Teaming a request/response protocol like DNS with UDP is highly efficient. The
queries and responses that DNS sends over UDP have a well-defined message format.

The DNS Message

The format of the DNS message is defined in RFC 1035, “Domain Names—Implemen-
tation and Specification.” This RFC defines a standard message format composed of up
to five parts:
Header The header section provides administrative information about the mes-
sage, including information about what is contained in subsequent sections of the
message.
Question The question section defines the question being asked by a query.
When the question section is returned in a response, it is used to help determine
which question the response is answering.
Answer The answer section is found in a response and it contains the answer to
the specific question sent in the query.
Authority The authority section is found in a response and it contains pointers
to the servers responsible for the domain being queried. Chapter 1, “The DNS
Architecture,” shows how important these pointers are for locating information

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

26 Chapter 2 The DNS Protocols

within the DNS hierarchy, even when the first server queried cannot provide a
real answer to the question.
Additional The additional section is found in a response. This section contains
database records that provide additional, important information that supports
the answer. These are not database records directly requested by the query, but
they help in interpreting or utilizing the response.
The format of the DNS message is clearly shown by the dig test tool. dig is one of the
DNS test tools included with Linux. It is used throughout this text and covered exten-
sively in Chapter 11, “Testing DNS.” A nice feature of dig is that it shows the entire DNS
message, not just the answer to the query. Listing 2.1 shows the DNS message format, as
displayed by dig.

Listing 2.1 The DNS message format shown by dig

[craig]$ dig dog.mammals.org

; <<>> DiG 8.2 <<>> dog.mammals.org

;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; dog.mammals.org, type = A, class = IN

;; ANSWER SECTION:
dog.mammals.org. 1H IN A 192.168.24.11

;; AUTHORITY SECTION:
mammals.org. 1H IN NS ns.exodus.net.
mammals.org. 1H IN NS fox.mammals.org.

;; ADDITIONAL SECTION:
ns.exodus.net. 15M IN A 206.79.230.10
fox.mammals.org. 1H IN A 192.168.24.5

;; Total query time: 249 msec

;; FROM:owl.foobirds.org to SERVER: default -- 10.22.11.61
;; WHEN: Wed Feb 23 09:33:30 2000
;; MSG SIZE sent: 33 rcvd: 137

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 The DNS Message 27

The first three lines and the last four lines contain information that dig provides in addi-

How Thnigs Work

tion to the DNS message. Those lines will be explained when dig is described in more
detail. The focus of this chapter is the DNS message. dig prints all five sections of the mes-
sage that it received in response to its query. Without an understanding of the structure
of a DNS message, the dig response can lead to more confusion than enlightenment. Let’s
look at each section in more detail.
PART 1
The Header Section
All DNS messages have a header section to describe how the data that follows should be
interpreted. The header section, as described in RFC 1035, consists of six 16-bit words.
Figure 2.2 shows the header section as it is laid out by the RFC.

Figure 2.2 The DNS message header section

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

IDENTIFIER

QR OPCODE AA TC RD RA Z AD CD RCODE

QDCOUNT

ANCOUNT

NSCOUNT

ARCOUNT

Contents of the Header Section

Many of the values in the header section can be affected by configuration values you
define for your server. Examples of the effect you can have on header values are noted and
each item in the header section is described in the following sections.

IDENTIFIER The first word of the header is a 16-bit identifier generated by the server
that issued the query. This identifier is used in the response so that the response can easily
be matched to the query.
The DNS software that Linux provides has an option called use-id-pool that improves
the randomness of the query identifier to avoid duplicates. While not required for basic
server operation, the use-id-pool option illustrates the scope of control you have over
the DNS configuration and demonstrates that you cannot fully understand the configu-
ration options available to you without understanding the underlying details of DNS. See

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

28 Chapter 2 The DNS Protocols

Appendix B, “name.conf Command Reference,” for a short description of the use-id-

pool option.

QR QR stands for query/response. This is a one-bit field that indicates whether the mes-
sage is a query or a response. 0 means it is a query and 1 means it is a response.

OPCODE The OPCODE is a four-bit field that defines what kind of query is contained
in the message. Like the identifier, it is initially set by the server that generates the query
and is left unchanged by the server that generates the response. There are five defined
OPCODE values:
0 means that this is a standard query. All queries for DNS database information
use this OPCODE.
1 means that this is an inverse query. Inverse queries are obsolete and no longer
used.
2 means that this is a query for server status, not a query for database informa-
tion. While defined, this OPCODE is not supported or used.
4 means that this is a DNS NOTIFY message. NOTIFY is a technique used to
synchronize the databases on master and slave servers.
5 means that this is an update message. Update messages change the records
stored in the DNS database on authoritative servers that support dynamic DNS.

AA AA stands for authoritative answer. This is a one-bit field that is used only when the
message is a response. The bit is set to 1 if the response comes from an authoritative
server. As explained in Chapter 1, all servers cache answers and can then answer queries
from their caches. These answers are not authoritative. Only a server responding to a
query for information in its zone of authority can provide an authoritative answer. When
an authoritative server provides an authoritative answer, it sets this bit to 1. When a
server answers from its cache of answers, it sets this bit to 0, indicating it is a non-author-
itative answer. You will create the authoritative servers for your domain.

TC TC stands for truncation. The truncation bit is set to 1 if the response was too large
to fit in a message and had to be truncated. If the truncation bit is 0, the entire response
fits into one message, which is the normal case.

RD RD stands for recursion desired. This bit is set to 1 to request recursion. Most clients
request recursion. RES_RECURSE, an option described in Chapter 4, “Configuring the
Resolver,” that causes the client to set this bit to 1, is compiled into the DNS software by
default. By its very nature, recursion means that the first recursive server to handle the
request will send out as many additional queries as are needed to find the answer to the
original question. Because the server is already recursively handling the query, it does not
need other servers to also recursively pursue an answer. The server normally sets this bit

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 The DNS Message 29

to 0 on subsequent queries so that the other servers don’t unnecessarily start their own

How Thnigs Work

recursive searches.

RA RA stands for recursion available. This bit is set to 1 if the name server generating the
message supports recursion. It is set to 0 if the name server is a non-recursive server. By
default, Linux name servers are recursive servers. However, you control this through the
recursion configuration option covered in Chapter 8, “Special BIND Configurations.” PART 1

Unused This is an unused bit available for future use.

AD AD stands for authenticated data. This bit is set to 1 when the data in the message
has been authenticated using the DNS security (DNSSEC) protocol.

CD CD stands for checking disabled. Setting this bit to 1 indicates that the server is
unable to authenticate the message, not because the data failed authentication, but
because the server either does not have or has currently disabled support for the DNSSEC
protocols. See Chapter 10, “DNS Security,” for more information on DNSSEC.

RCODE The response code is a four-bit value used for error codes in a response message.
Linux software supports ten error codes:
0 No errors occurred. The response is good.
1 There was an error in the format of the query and the name server could not
understand the query.
2 Due to a name server failure, the name server was not able to process the
query.
3 The domain name referenced in the query does not exist. This is a very useful
error code when it comes from an authoritative server. It literally means that
the requested domain name does not exist, which is information that is just as
important as knowing the address of a domain name. For this reason, this
type of information is cached just like an answer containing an address. In
fact, this error code is referred to NXDOMAIN (non-existent domain) almost
as if it were a real DNS database record. Caching NXDOMAIN information
is called negative caching. Several times in the discussion of name server con-
figuration, we will examine options relating to negative caching.
5 The request was refused. The server supports the requested function but it
won’t do it for the client. Security is the primary reason for this response code.
You control what DNS services are offered and what hosts they are offered to
with configuration options like allow-query and allow-transfer.
6 The request contained a dynamic DNS update that attempted to add a domain
name that already exists. The update was rejected.

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

30 Chapter 2 The DNS Protocols

7 A dynamic update attempted to add a set of database records that already

exist. The update was rejected.
8 The DNS update request attempted to delete or change records that don’t
exist. The update was rejected.
9 The request asked the server to update a zone for which the server is not
authoritative. A non-authoritative server cannot perform a dynamic DNS
update. Therefore, the update was rejected.
10 The database records in the DNS update request do not belong to the domain
for which the update was requested. The update was rejected.

QDCOUNT QDCOUNT stands for query data count. This field contains the number of
entries in the question section of the message.

ANCOUNT ANCOUNT stands for answer count. This field contains the number of
DNS database records contained in the answer section of the message.

NSCOUNT NSCOUNT stands for name server count. This field contains the number of
DNS name server database records contained in the authority section of the message.

ARCOUNT ARCOUNT stands for additional record count. This field contains the
number of DNS database records contained in the additional section of the message.

Evaluating the dig Header Data

Use the information about the header section to interpret the output of the dig command
in a more meaningful way. Here is the header data from Listing 2.1:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

dig does not display the header data in the order in which it occurs in the header section,
but it is still easy to identify:
opcode: QUERY clearly indicates that this is a standard query; in other words,
the OPCODE field contains a 0.
status: NOERROR is a little trickier. status really refers to the RCODE field
and NOERROR means that the RCODE field contains a 0.
id: 4 indicates that the identifier used for this message was the number 4. This
value doesn’t seem random. If your server generated this response, you might
want to enable the use-pool-id option described in Appendix B. It improves the
randomness of the identifier at the cost of a small increase in the memory used by
the name server.

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 The DNS Message 31

flags: qr aa rd ra really covers four different fields in the header section and

How Thnigs Work

gives us information about three others. dig uses flags to group together all of
the one-bit fields. It lists each field that is set to 1. This means that QR is set to 1,
indicating this is a response. AA is set to 1 because this answer came from an
authoritative server. RD is set to 1 to indicate that recursion was requested by the
query. RA is set to 1, indicating that recursion is available on the server. TC is not
listed, meaning it is set to 0 and that the response was not truncated. AD and CD PART 1
are also set to 0 because DNSSEC is not in use.
QUERY: 1, ANSWER: 1, AUTHORITY: 2, and ADDITIONAL: 2 represent the last
four fields in the header section, QDCOUNT, ANCOUNT, NSCOUNT, and
ARCOUNT. This information tells you that there is one entry in the question sec-
tion, one database record in the answer section, two records in the authority
section, and two records in the additional section.

The Question Section

The question section is the first section after the header. It holds the query sent from the
DNS client and is found in both the request and the response message. Each query in the
question section is three 16-bit words long. Figure 2.3 shows the format of a query.

Figure 2.3 A DNS query

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Query Name

Query Type

Query Class

Query Name Field

The Query Name field contains the fully qualified domain name for which information
is sought. Recall that a fully qualified domain name ends with the root. For example,
mammals.org. and robin.foobirds.org. are fully qualified domain names. When a
domain name is stored in the Query Name field, the separating dots are dropped and each
piece of the name is preceded by a byte that defines the length of that piece of the name.
robin.foobirds.org. is stored as 5robin8foobirds3org0. Notice the zero length at
the end of the name. All query names end in this way because they all end with the root
and the root is a null name; a null name is a name with no length.

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

32 Chapter 2 The DNS Protocols

Query Type Field

The Query Type field defines the type of database records being requested. There are
many different types of DNS database records, all of which are defined in Appendix C,
“Resource Record Reference.” Each record type is assigned a numeric value and it is that
value that is used in the Query Type field. For example, a 1 in the Query Type field means
that the client wants the IP address of the host identified in the Query Name field. A
domain name can have more than one type of database record assigned. The Query Type
field permits the client to request an individual record type or groups of records. The
values used to request multiple records are listed here:
250 This value, called TSIG, requests the transaction signature record for a
domain. These records are used for authentication to improve DNS security. See
Chapter 10 for more information.
251 This value requests an incremental zone file transfer (IXFR). The zone file
is the database file that contains all of the records for a specific zone of authority.
Distributed servers synchronize the database by transferring the zone file. This is
one of the techniques used to transfer the file.
252 This value requests a full zone file transfer (AXFR). This is the technique
used by a backup name server to synchronize its database with the master server
for the specified domain. This is a basic function of DNS. Protocols relating to this
function are covered later in this chapter.
253 This is an obsolete value that is no longer used. Called MAILB, it was
designed to retrieve various mailbox records. The records it retrieves are no
longer used.
254 This is an obsolete value that is no longer used. Called MAILA, it was
designed to retrieve various mail agent records. This value was already obsolete
in 1987 when RFC 1035 was written.
255 This value, called ANY, retrieves any and all records relating to the query
name. This is a powerful and popular query type.

Query Class Field

The third word in the query entry is the Query Class field. There are five possible class
values: Internet (1), Hesiod (3), Chaosnet (4), NONE (254), and ANY (255).The ANY
and NONE values are used for special purposes, such as dynamic updates. Hesiod is a
server developed almost 20 years ago at MIT as part of Project Athena. Cool stuff like X
Windows and the Kerberos authentication server came from that project, but Hesiod is
no longer widely used. Chaosnet also dates to about 20 years ago. It was the network used
by the Lisp machines that were once very popular in the articficial intelligence research
community. Your Linux server will always work with Internet database records so the

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 The DNS Message 33

query class used for all of your queries will be Internet, which is abbreviated as IN and has

How Thnigs Work

a numeric value of 1.

Evaluating the dig Query Data

The dig command used in Listing 2.1 displayed this query data:
;; QUERY SECTION:
;; dog.mammals.org, type = A, class = IN PART 1

Using information from the header, you know that this query section contains only one
query. The three fields of this query are clearly shown. You know the query is asking for
information about dog.mammals.org because that is the query name. Specifically, the
query is asking for the Internet address of dog. You know that because the query type is A,
which is the record type of address records, and the class field is IN, stating that the client
is only interested in Internet records. An Internet address query is the most common query
and it is the one that dig defaults to if no arguments are added to the dig command line.

The Answer, Authority, and Additional Sections

The three remaining sections of the response message all have the same format. The
answer, authority, and additional sections all contain a list of DNS domain records. The
number of records in each section is specified in the header. The records are laid out as
shown in Figure 2.4.

Figure 2.4 The format of database records in a response

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

NAME

TYPE

CLASS

TTL

LENGTH

DATA

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

34 Chapter 2 The DNS Protocols

As you’ll see in Chapter 6, “Creating a Master Server,” most of these fields are entered
by you when you create the domain database for the master server. Although not entered
in exactly this order, the meaning of the fields will become very familiar to you as you
build your own database files. The fields are as follows:
NAME This is the domain name of the object to which this record relates.
TYPE This is the database record type. It can be any of the record types listed
in Appendix C.
CLASS This is the class of the database. It can be IN for Internet, HS for Hesiod,
or CH for Chaosnet. It is usually IN.
TTL This is the time-to-live field. It defines how long the database record can
be saved in a remote server’s cache.
LENGTH This is the only field that is not created by the domain administrator.
It specifies the length of the following data field in bytes.
DATA This is the data field that relates to this type of resource record. For
example, in an address record, this would be an address. On a name server record,
this would be the domain name of the name server. The data field varies in con-
tent and length depending on the record type.

Evaluating the dig Data for the Answer, Authority, and Additional Sections
The dig command in Listing 2.1 displayed the following answer, authority, and addi-
tional sections:
;; ANSWER SECTION:
dog.mammals.org. 1H IN A 192.168.24.11

;; AUTHORITY SECTION:
mammals.org. 1H IN NS ns.exodus.net.
mammals.org. 1H IN NS fox.mammals.org.

;; ADDITIONAL SECTION:
ns.exodus.net. 15M IN A 206.79.230.10
fox.mammals.org. 1H IN A 192.168.24.5

The header section displayed by dig says that there is one database record in the answer
section, two records in the authority section, and two records in the additional section.
The query asked for the address of dog and that is exactly what the answer section pro-
vides. dig displays the information in the order in which it is entered when building a
database record, which is slightly different from the order in which it is transmitted in a
response message. The answer shows the full domain name of dog. It shows that the TTL

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 Synchronizing Databases 35

for this record is 1 hour (1h). The class is IN for Internet, the type is A for address, and

How Thnigs Work

the data field of the record is the Internet address of dog, 192.168.24.11.
The authority section lists the servers that are authoritative for the mammals.org domain
to which dog belongs. There are two name server records, each providing the name of an
authoritative server. From this, we know that fox.mammals.org. and ns.exodus.net.
are authoritative for mammals.org.
PART 1
The additional section completes the message by providing the address of each of the
authoritative servers. The addresses are important because if the local server wants to
send future queries directly to the authoritative servers for the mammals.org domain, it
needs to know the address of those servers. In this case, the addresses are 206.79.230.10
and 192.168.24.5.
All of the information from all of these sections is cached by the local server. If it receives
a query for the addresses of dog.mammals.org or fox.mammals.org, it can now answer
those queries directly from its own cache—at least for the next hour. The longest TTL on
any of these records is one hour.
The DNS message is the building block of all DNS client/server activity. It is the unit sent
to a server as a query and the unit with which the server responds to a query. Most DNS
information is exchanged in DNS messages sent over UDP. The exception is when servers
need to synchronize an entire domain database.

Synchronizing Databases
Synchronizing databases begins with the exchange of request and response packets over
UDP just like any other DNS interaction. The request message sent depends on the tech-
nique being used to update the backup domain files. There are two techniques:
■ A traditional pull technique in which the backup servers pulls the data down from
the master server.
■ A newer push technique in which the master server pushes database updates out
to the backup servers.

Slave-Initiated Zone Pull

When the pull technique is used, the backup server sends a query to the master server
asking for administrative information about the zone. This information is held in the Start
of Authority (SOA) record for the zone, so the slave server queries the master for an SOA
record. The data field of the SOA record contains a lot of information, but one item, the
zone’s serial number, is particularly important to the slave server. The slave compares

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

36 Chapter 2 The DNS Protocols

that serial number to the serial number of its copy of the zone. If the serial number of the
master file is greater than the serial number of the slave’s copy of the zone, the slave
assumes that it needs to download an updated database from the master.
The slave server can download the entire database with a zone file transfer (AXFR) or it
can request just the changes to the zone with an incremental zone file transfer (IXFR). For
a full zone file transfer, the question section of the slave’s request message contains the
name of the domain being transferred in the query name field, IN in the Query Class field,
and AXFR in the Query Type field. The question section and a properly formatted header
section are all that is required for a zone file transfer request.
The request message for an incremental zone file transfer is slightly more complex. As you
might expect, the message contains a properly formatted header and a question section
that contains the name of the requested domain, the class IN, and the type IXFR. In addi-
tion, an incremental zone transfer request contains the slave’s SOA record in the authority
section. The slave sends its SOA record to the master so that the master knows how far
out of synchronization the database files are. The master then sends the slave those
records that have changed between the version of the zone the slave has and the current
version of the zone on the master. Unlike the AXFR, which transfers the entire file, only
the individual database records that have changed are sent in an IXFR.
The incremental zone transfer has the potential to greatly improve zone transfer effi-
ciency. But like many things that look good, it is not as easy as it sounds. IXFR reduces
network load at the cost of increased processing.
First, IXFR forces the master server to maintain a history of database updates in order to
know what should be sent to the slave. This history may need to be several changes deep,
depending on the frequency with which the zone changes and the slave checks for
changes.
Second, the slave needs to understand how to process these changes in a manner that guar-
antees that the database files are synchronized. These requirements increase the complexity
of the DNS software. Some DNS servers avoid the complexity by treating an IXFR as an
AFXR. In the long run, however, I expect that all name servers will comply with the RFCs
and support incremental zone transfer requests. Linux DNS servers do support IXFR.

Master-Initiated Zone Push

The master server starts the process of pushing an updated zone down to its slave with a
standard DNS request message sent over UDP. In the header section of the message, the
OPCODE is set to 4, which is the NOTIFY code. The question section of the request mes-
sage contains a query for the SOA record of the slave server. When the slave receives the
request message, it flips the QR bit from query to response and sends the message right

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com

 In Sum 37

back to the master. This is fine because the master server isn’t really interested in the

How Thnigs Work

slave’s SOA record. It wants a positive acknowledgement that the slave server has
received the domain NOTIFY message and it gets that when it receives the slave’s
response message.
After responding to the master, the slave server begins to retrieve the updated zone file.
The slave can use either a full zone file transfer or an incremental zone file transfer to get
PART 1
the update. NOTIFY simplifies the processing of an incremental zone transfer because it
limits the amount of history that the master server is forced to maintain. The NOTIFY is
sent every time the zone changes so only those records changed in the last zone update
need to be sent for the IXFR. There is no need to stored changes from earlier updates
because the slave has already received them in response to earlier NOTIFY messages.
NOTIFY also simplifies the IXFR process for the slave because only one set of changes
needs to be processed. By simplifying IXFR, NOTIFY makes it more useful.
Using these various techniques, the servers responsible for a zone ensure that the database
information on every authoritative server is accurate.

In Sum
The Domain Name System is a network-based, distributed database service. DNS uses
standardized protocols to communicate over the network. The network that DNS is built
on is the Internet. The Internet is a logical network created by the IP suite, which is com-
posed of IP, the transport protocols UDP and TCP, and application protocols. The DNS
network protocol is one of the application protocols. DNS works by exchanging stan-
dardized request and response messages over the network.
The DNS protocols are implemented in the Berkeley Internet Name Domain (BIND) soft-
ware. Every Linux name server uses BIND to construct the request and response messages
and perform all of the tasks associated with DNS. Chapter 3, “The BIND Software,”
introduces the BIND client/server software and describes how it is installed in your Linux
DNS server.

Copyright © 2000 SYBEX, Inc., Alameda, CA. www.sybex.com