Windows Server 2008 R2 Unleashed (61 page)

After the last step, the zone will automatically transfer from the primary DNS server to the

secondary DNS server.

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 data-

base 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.

ptg

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 on 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 10.10.

Understanding DNS Queries

The primary function of DNS is to provide name resolution for requesting clients, so the

query mechanism is subsequently one of the most important elements in the system. Two

types of queries are commonly made to a DNS database: recursive and iterative.

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 essen-

tially asks whether a particular record can be resolved by a particular name server. The

Understanding DNS Queries

277

Index = 50

A zone transfer for all

changes from index

50 to 55 is initiated from

Server1 to Server2.

Server2

IXFR Zone

ansfer

Index = 55

Tr

Index = 45

A zone transfer for all

changes from index

IXFR Zone

45 to 55 is initiated from

Server1 to Server3.

Transfer

Server1

Server3

AXFR Zone

Transfer

Index = 25

Because the difference

between index numbers is

great, a full AXFR zone

transfer is initiated from

Server1 to Server4.

Server4

ptg

FIGURE 10.10

IXFR zone transfers.

response to a recursive query is either negative or positive. A common recursive query

scenario is illustrated in Figure 10.11.

3

Server2

(Root Server)

Recursive

Query

2

Resolver

1

5

Query

4

Query

8

Response

6

Client1

Server1

Server3

(.com TLD Server)

10

Iterative

Queries

7

Server4

(microsoft.com Name Server)

FIGURE 10.11

Recursive and iterative queries.

278

CHAPTER 10

Domain Name System and IPv6

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 10.11, 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.

ptg

Other DNS Components

Several other key components lie at the heart of DNS and are necessary for it to function

properly. In addition, you need to fully understand the functionality of several key

components of DNS that are utilized heavily by Microsoft DNS.

Dynamic DNS

Older versions of DNS relied on administrators manually updating all the records within a

DNS database. Every time a resource was added or information about a resource was

changed, the DNS database was updated manually, normally via a simple text editor, to

reflect the changes. Dynamic DNS was developed as a direct response to the increasing

administrative overhead that was required to keep DNS databases functional and up to

date. With Dynamic DNS, clients can automatically update their own records in DNS,

depending on the security settings of the zone.

It is important to note that only Windows 2000/XP and higher clients support dynamic

updates and that down-level (NT/9x) clients must have DHCP configured properly for

them to be updated in DNS. There are, however, security issues associated with this func-

tionality that are detailed in subsequent sections of this chapter and are described further

in Chapter 11, “DHCP/WINS/Domain Controllers.”

Other DNS Components

279

The Time to Live Value

The Time to Live (TTL) value for a RR is the amount of time (in seconds) that a resolver or

name server will keep a cached DNS request before requesting it again from the original

name server. This value helps to keep the information in the DNS database relevant.

Setting TTL levels is essentially a balancing act between the need for updated information

and the need to reduce DNS query traffic across the network.

In the example from the “Performing Iterative Queries” section, if Client1 already

requested the IP address of www.microsoft.com, and the information was returned to the

DNS server that showed the IP address, it would make sense that that IP address would

not change often and could, therefore, be cached for future queries. The next time

another client requests the same information, the local DNS server will give that client the

IP address it received from the original Client1 query as long as the TTL has not expired.

This helps to reduce network traffic and improve DNS query response time.

The TTL for a response is set by the name server that successfully resolves a query. In

other words, you might have different TTLs set for items in a cache, based on where they

were resolved and the TTL for the particular zone they originated from.

NOTE

ptg

The default TTL for manually created records in Windows Server 2008 R2 DNS is one

hour. Records created dynamically via Dynamic DNS have a 20-minute default TTL.

The TTL setting for a zone is modified via the SOA record. The procedure for doing this in

Windows Server 2008 R2 is as follows:

1. Launch Server Manager.

2. Expand the Roles, DNS Server, DNS, server name, and Forward Lookup Zones nodes.

3. Select the zone node.

4. Find the SOA record for the zone and double-click it.

5. Modify the Minimum (Default) TTL entry to match the TTL you want, as shown in

Figure 10.12.

6. Click OK to accept the changes.

Performing Secure Updates

10

One of the main problems with a Dynamic DNS implementation lies with the security of

the update mechanism. If no security is enforced, nothing will prevent malicious users

from updating a record for a server, for example, to redirect it to another IP address. This

is known as DNS poisoning. For this reason, dynamic updates are, by default, turned off

on new standard zones that are created in Windows Server 2008 R2. However, with AD-

integrated DNS zones, a mechanism exists that allows clients to perform secure dynamic

280

CHAPTER 10

Domain Name System and IPv6

FIGURE 10.12

Changing the TTL.

ptg

updates. Secure updates utilize Kerberos to authenticate computers and ensure that only

those clients that created a record can subsequently update the same record.

If you’re using DHCP to provide secure updates on behalf of DHCP clients, one important

caveat is that DHCP servers should not be located on the domain controller, if possible,

because of specific issues in regard to secure updates. The reason for this recommendation

is that all DHCP servers are placed in a group known as DNSUpdateProxy. Any members

of this group do not take ownership of items that are published in DNS. This group was

created because DHCP servers can dynamically publish updates for clients automatically,

and the clients would need to modify their entries themselves. Subsequently, the first

client to access a newly created entry would take ownership of that entry. Because domain

controllers create sensitive SRV records and the like, it is not wise to use a domain

controller as a member of this group, and it is subsequently not wise to have DHCP on

domain controllers for this reason. If establishing DHCP on a domain controller is

unavoidable, it is recommended to disable this functionality by not adding the server into

this group.

Exploring Aging and Scavenging for DNS

DNS RRs often become stale, or no longer relevant, as computers are disconnected from

the network or IP addresses are changed without first notifying the DNS server. The

process of scavenging those records removes them from a database after their original

owners do not update them. Scavenging is not turned on, by default, but this feature can

be enabled in Windows Server 2008 R2 by following these steps:

Other DNS Components

281

1. Launch Server Manager.

2. Expand the Roles, DNS Server, and DNS nodes, and then select the DNS server name.

3. Right-click the server name and choose Properties.

4. Select the Advanced tab.

5. Check the Enable Automatic Scavenging of Stale Records check box.