Performing Full Zone Transfers
The standard method for zone
transfers, which transfers the entire contents of a DNS zone from the
primary server to the secondary server, is known as asynchronous zone
transfer (AXFR), or full zone transfer. This type of zone transfer
copies every item in the DNS database to the secondary server,
regardless of whether the server already has some of the items in the
database. Older implementations of DNS utilized AXFR exclusively, and
it is still utilized for specific purposes today.
Initiating Incremental Zone Transfers
An incremental zone transfer (IXFR) is a
process by which all incremental changes to a DNS database are
replicated to the secondary DNS server. This saves bandwidth over AXFR
replication changes because only the deltas, or changes made to the
database since the last zone transfer, are replicated.
IXFR zone transfers are accomplished by
referencing a serial number that is stored on the SOA of the DNS server
that holds the primary zone. This number is incremented upon each
change to a zone. If the server requesting the zone transfer has a
serial number of 45, for example, and the primary zone server has a
serial number of 55, only those changes made during the period of time
between 45 and 55 will be incrementally sent to the requesting server
via an IXFR transfer. However, if the difference in index numbers is
too great, the information about the requesting server is assumed to be
stale, and a full AXFR transfer will be initiated. For example, if a
requesting server has an index of 25, and the primary zone server’s
index is 55, an AXFR zone transfer will be initiated, as illustrated in
Figure 1.
Figure 1. IXFR zone transfers.
Performing Recursive Queries
Recursive queries are most often performed by
resolvers, or clients, that need a specific name resolved by a DNS
server. Recursive queries are also accomplished by a DNS server if
forwarders are configured to be used on a particular name server. A
recursive query essentially asks whether a particular record can be
resolved by a particular name server. The response to a recursive query
is either negative or positive. Figure 2 shows a common recursive query scenario.
Figure 2. Recursive and iterative queries.
Performing Iterative Queries
Iterative queries ask a DNS server to either
resolve the query or make a best-guess referral to a DNS server that
might contain more accurate information about where the query can be
resolved. Another iterative query is then performed to the referred
server and so on until a result, positive or negative, is obtained.
In the example shown in Figure 2, Client1 in CompanyABC opens a web browser and attempts to browse to the website for www.microsoft.com.
A recursive query is initiated to the default name server; in this
case, Server1 is contacted. Because Server1 is authoritative only for
the companyabc.com namespace, and no entries exist for microsoft.com,
the query is sent to an “upstream” DNS server that is listed in the
root hints of the DNS server. That server, Server2, is not
authoritative for microsoft.com but sends a referral back to Server1
for Server3, which is a name server for the .com namespace. Server3
knows that Server4 handles name-resolution requests for microsoft.com
and sends that information back to Server1. A final iterative query is
then sent from Server1 to Server4, and Server4 successfully resolves
www to the proper IP address. Server1, with this information in hand,
returns Client1’s original recursive query with the proper IP address
and Client1’s browser successfully resolves www.microsoft.com.
This type of functionality lies at
the heart of the distributed nature of DNS and allows DNS lookups to
function as efficiently as they do.
