2008 DNS Zones

Start of Authority (SOA)

The first record in any DNS zone is the Start of Authority (SOA) Resource Record (RR). The SOA RR specifies the authoritative DNS server for the zone, i.e., the best source of data for the zone. Depending upon the installation options the SOA RR may or may not be automatically added for a new zone.

Setting Zone PropertiesYou’ll see six tabs in the zone’s Properties dialog box for a forward or reverse lookup zone. You use the Security tab only to control who can change properties and make dynamic updates to records on that zone.

In the DNS snap in, right mouse click on the .local dns zone and click on properties.

General TabThe Status indicator and the associated Pause button let you see and control whether thiszone can be used to answer queries. When the zone is running, the server can use it toanswer client queries; when it’s paused, the server won’t answer any queries it gets for thatparticular zone.

The Type indicator and its Change button allow you to select the zone type. As you change the type, the controls you see below the horizontal dividing line will change too. For primary zones, you’ll see a field that lets you select the zone filename. For secondary zones, you’ll get controls that allow you to specify the IP addresses of the primary servers. When you change to the AD-integrated zone, you have the ability to make the dynamic zones secure only.

Secondary zones don’t have a Security tab, and their SOA tab shows you the contents of the master SOA record, which you can’t change.

A Primary zone stores the most current records and settings for the zone.

For each standard zone that is not Active Directory – integrated only one primary DNS server is allowed, and this server contains the only read/write version of the zone database.

A Secondary zone is a read-only copy of the primary zone used to improve performance and fault tolerance.

A Stub zone is a copy of a zone that contains only those resource records necessary to identify the actual authoritative DNS servers for that zone.

Stub zones only contain resource records (of type SOA, NS, and A) that specify the authoritative DNS server(s) (primary and secondary) for the zone, and therefore simply redirect a client queries to the DNS server(s) that holds the authoritative zone and is able to resolve these requests.

Active Directory Service Integration

Store the zone in Active Directory (available only if DNS server is a domain controller)

This check box in the Change Zone Type box allows you to store the primary zone information in the Active Directory database instead of in the WINDOWS\System32\Dns folder.

In Active Directory integrated zones, zone data is replicated through AD. In most cases this eliminates the need to configure zone transfers to secondary servers.

The Replication indicator and its Change button allow you to change the replication scope if the zone is stored in Active Directory.

Configuring Zone Replication for Active Directory–Integrated ZonesYou can install Active Directory–integrated zones only on domain controllers on which theDNS Server role is installed. Active Directory–integrated zones are generally preferable to standard zones because they offer multimaster data replication, simpler configuration, andimproved security and efficiency.

A DNS server installed on a domain controller running Windows 2008 can use two built-in application directory partitions for storing DNS information. ForestDnsZones.domainName and DomainDnsZones.domainName, are replicated to all DNS servers in the forest or in the domain, respectively.

In addition, DNS server can store data in user created application partitions with their own replication scopes. (Keep in mind that DNS data stored in application partitions is not replicated to Global Catalog.)

When a DNS zone is integrated with Active Directory you need to specify where it will be stored and its replication scope. You can specify the replication scope when creating a new zone and you can change it at any time after creation. The following storage options are available for Active Directory-integrated zones:

Forest-wide DNS application directory partition –

To all DNS servers in this forest replicated to all DNS servers running on domain controllers in the forest. This partition is automatically created when DNS is installed on the first domain controller in a new forest. This provides the broadest scope of replication but generates the most replication traffic.

Domain-wide DNS application directory partition –

To all DNS servers in this domain DNS zones stored in this partition are replicated to all DNS servers running on domain controllers in the domain. This partition is automatically created when DNS is installed on the first domain controller in a new domain.

For instance, if you create stub zone on a DNS server in Company.com that points at Branch.Company.com, the records in the stub zone would be placed in cn=DomainDNSZones, dc=Company, dc=com.

Domain partition –To all domain controllers in this domain DNS zones stored in this partition are replicated to all domain controllers in the zone, even those that are not running the DNS Server service. This is the only option for zones that are replicated to domain controllers running Windows 2000 Server.

Custom DNS application directory partition –

DNS zones stored in this partition are replicated to all DNS servers running on domain controllers that enlist in the partition. To utilize this type of partition you must first create the application directory partition from a command prompt using dnscmd.

The DnsCmd command Creating custom application directory partitions

Use the following syntaxDnsCmd ServerName /CreateDirectoryPartition FQDN of partition

ExampleCreate an application directory partition named DNSPartition on a domain controller DC01.

Open a command prompt and enterdnscmd DC01 /createdirectorypartition DNSPartition.abc.com

When the application directory partition has been successfully created, you see. DNS Server DC01 created directory partition: DNSPartition.abc.com Command completed successfully.

Configuring an additional domain controller DNS server to host the application directory partition

To configure an additional domain controller that is acting as a DNS server to host the new application directory partition that you created, use the following syntax.

DnsCmd ServerName /EnlistDirectoryPartition FQDN of partition

To configure the domain controller named DC02 to host this custom application directory partition.

Open a command prompt and enterdnscmd DC02 /enlistdirectorypartition CustomDNSPartition.abc.com

The following appearsDNS Server DC02 enlisted directory partition: CustomDNSPartition.abc.com Command completed successfully.

Security tab

The properties dialog box of an Active Directory-integrated zone has an additional tab, the Security tab. This is the tab where you set access permissions for the specific zone:

Configure who can modify the properties of a specific zone Configure who add dynamic updates to records for a specific zone.

Zone File Name field

This field only applies for standard primary DNS servers, and secondary DNS servers that do not store zone data in Active Directory.

The Zone File Name field lists the file name of the DNS zone in the %systemroot%\system32\dns directory.

The default zone file name is the zone name with a .dns extension. You can change this default zone file name using the Zone File Name field.

Dynamic updates

None Dynamic Updates are not allowed for this particular zone. This means that all registrations and updates to zone resource records must be manually performed.

Nonsecure and SecureAllows client computers to automatically create and also update its resource records. In this case both secure and nonsecure dynamic updates can occur on this zone.

Secure Only (Only available for Active Directory-integrated zones)This will prevent computers not in your active directory from writing entries in your DNS and allows AD client computers to automatically create and update their own resource records.

Here as the Zone is Primary and not Active Directory Integrated the secure option is unavailable

Select either None or Nonsecure and Secure it is best practice to select Nonsecure and Secure because not allowing pc's to update their own DNS entries creates an administrative overhead.

Aging and Scavenging

Windows DHCP can register host records (A) and Reverse lookup or Pointer (PTR) resource records automatically whenever you add a new device to the network. This enables simplified and easy network administration. However, these records are not automatically purged when they are stale or outdated (say when the host gets a new ip address) and they remain in the DNS zone database indefinitely. This can cause network issues and can prevent host names from re-used.

ScavengingBy configuring the DNS Server to track the age of each dynamically-assigned record we can periodically remove records (scavenging) that are older than the number of days that you specify.The age of a resource record is based on when it was created or when it was last updated. By default, Windows client systems by default send a request every 24 hours to the DNS server to update their records. This prevents the records the records from being removed from the database.

Aging Provides a means of finding and clearing outdated records from the zone database.

Aging in DNS refers to the process of placing a timestamp on a dynamically registered resource record and tracking the age of this record.

Scavenging is the deletion of outdated resources records when aging is enabled.With DNS, aging can be setup to run automatically or manually on your DNS zones.

By default aging and scavenging are disabled! You must enable Aging/Scavenging

Scavenging needs to be enabled both at the DNS server and from the Zone level.

Setting Aging / Scavenging at the individual Zone Level

1. Click Start > Administrative Tools > DNS. This starts the DNS Server MMC snap-in.

2. In the console tree right click the applicable DNS zone and choose Properties.

3. On the General tab, click Aging.

Setting Aging / Scavenging for All Zones on the Server

In Windows Server 2008, Scavenging is disabled by default. To Enable at the Server

1. Click Start > Administrative Tools > DNS. This starts the DNS Server MMC snap-in.

2. In the console tree, click the applicable DNS server.

3. Set Aging/Scavenging for All Zones

This setting enables aging and scavenging for all new zones at the server level, it does not automatically enable aging or scavenging on existing Active Directory–integrated zones at the server level.

To set the for existing zones, click OK, and then, in the Server Aging/Scavenging Confirmation dialog box that appears, enable the option to apply these settings to existing Active Directory–integrated zones.

Modifying Zone Aging/Scavenging Properties

There are two key settings related to aging and scavenging: the no refresh interval and the refresh interval.

■ Modifying the no-refresh interval The no-refresh interval is the period after a timestamp during which a zone or server rejects a timestamp refresh. The no-refresh feature preventsthe sever from processing unnecessary refreshes and reduces unnecessary zone transfer traffic. The default no-refresh interval is seven days.

■ Modifying refresh intervals The refresh interval is the time after the no-refresh interval during which timestamp refreshes are accepted and resource records are not scavenged.After the no-refresh and refresh intervals expire, records can be scavenged from the zone.The default refresh interval is seven days. Consequently, when aging is enabled, dynamically registered resource records can be scavenged after 14 days by default.

Exam Tip You need to understand the no-refresh and refresh intervals for the 70-642 exam.

Refresh and No-Refresh intervals

Both of these must elapse before a record can be deleted.

The No-refresh interval is a period of time during which a resource record cannot be refreshed.  A refresh is a dynamic update where we are not changing the host/IP of a resource record, just touching the timestamp.  If a client changes the IP of a host record this is considered an "update" and is exempt from the No-refresh interval.  The purpose of a No-refresh interval is simply to reduce replication traffic.  A change to a record means a change that must be replicated.

After the (Record Timestamp) + (No-refresh interval) elapses we enter the Refresh interval.  The refresh interval is the time when refreshes to the timestamp are allowed.  This is the time when good things must happen.  The client is allowed to come in and update it's timestamp.  This timestamp will be replicated around and the No-refresh interval begins again.  If for some reason the client fails to update it's record during the refresh interval it becomes eligible to be scavenged.

Example assume, Zone is set to a 3 day Refresh and a 3 day No-Refresh interval

Remember also that the refresh interval should be equal to or greater than the no-refresh interval.

Automatic Scavenging

1. Click Start > Administrative Tools > DNS. This starts the DNS Server MMC snap-in.2. In the console tree, click the applicable DNS server.3. On the Action menu, click Properties.4. Click the Advanced tab, select “Enable automatic scavenging of stale records” OK.

The Scavenging Period is how often this particular server will attempt to scavenge.  When a server scavenges it will log a DNS event 2501 to indicate how many records were scavenged.  An event 2502 will be logged if no records were scavenged.  Only one server is required to scavenge since the zone data is replicated to all servers hosting the zone.

Manual ScavengingWhen automatic Scavenging is not enabled, you can perform manual scavenging in zones by right-clicking the server icon in the DNS Manager console tree and then choosing Scavenge Stale Resource Records.

Scavenging is particularly important if you use Dynamic DNS to automatically register client host names when their IP addresses change, as is often the case when the clients receive address assignments through DHCP.

Tip: You can tell exactly when a server will attempt to scavenge by taking the timestamp on the most recent 2501/2502 event and adding the Scavenging period to it.

Scavenging settings on a Resource Record

To see the scavenging setting on a record hit View > Advanced in the DNS MMC then bring up properties on a record

Start of Authority (SOA) record

The Start of Authority (SOA) resource record is always first in any standard zone. The Start of Authority (SOA) tab allows you to make any adjustments necessary. You can change the primary server that holds the SOA record, and you can change the person responsible for managing the SOA. Finally, one of the most important features is that you can change your DNS server configuration without deleting your zones and having to re-create the wheel.

When a DNS server loads a zone, it uses the SOA resource record to determine basic and authoritative properties for the zone. These settings also determine how often zone transfers are performed between primary and secondary servers.

The Serial Number contains the revision number of the zone file. This number increases each time a resource record changes in the zone or when you manually increment the value in this tab by clicking Increment. Each time a zone is changed this number is incremented by a value of 1 to indicate a new zone version. This tells secondary zone transfer servers that a change has occurred and a zone transfer is needed.

When zones are configured to perform zone transfers to one or more secondary servers, the secondary servers query the master server intermittently for the serial number of the zone. This query is called the SOA query. If, through the SOA query, the serial number of the master zone is determined to be equivalent to the serial number stored on the secondary, no transfer is made. However, if the serial number for the zone at the master server is greater than that at the requesting secondary server, the secondary server initiates a transfer.

NOTE When you click the Increment button, you force a zone transfer.

Primary Server contains the full computer name for the primary DNS server of the zone. This name must end with a period.

Responsible Person contains the name of a responsible person (RP) resource record that specifies a domain mailbox name for a zone administrator. The name of the record entered into this field should always end with a period. The name “hostmaster” is used in this field by default. This name can be seen when using the internet whois command

Refresh Interval determines how long a secondary DNS server waits before querying the master server for a zone renewal.When the refresh interval expires, the secondary DNS server requests a copy of the currentSOA resource record for the zone from its master server which answers this SOA query. The secondary DNS server then compares the serial number of the source server’s current SOA resource record (as indicated in the master’s response) with the serial number of its own local SOA resource record. If they are different, the secondary DNS server requests a zone transfer from the primary DNS server. The default value for this setting is 15 minutes.Exam Tip Increasing the refresh interval decreases zone transfer traffic.

Retry Interval determines how long a secondary server waits before retrying a failed zone transfer. Normally, this time is less than the refresh interval. The default value is 10 minutes.Expires After determines the length of time that a secondary server, without any contact with its master server, continues to answer queries from DNS clients. After this time elapses, the data is considered unreliable. The default value is one day.

Minimum (Default) TTL determines the default Time to Live (TTL) that is applied to all resource records in the zone. The default value is one hour.TTL values are not relevant for resource records within their authoritative zones.Instead, the TTL refers to the cache life of a resource record in nonauthoritative servers.A DNS server that has cached a resource record from a previous query discards the record when that record’s TTL has expired.

TTL For This Record determines the TTL of the present SOA resource record. This value overrides the default value setting in the preceding field.

After you create it, an SOA resource record is represented textually in a standard zone filein the manner shown in this example:

@ IN SOA computer1.domain1.local. hostmaster.domain1.local. (5099 ; serial number3600 ; refresh (1 hour)600 ; retry (10 mins)86400 ; expire (1 day)60 ) ; minimum TTL (1 min)

Name Server Records

A name server (NS) record specifies a server that is authoritative for a given zone. When you create a zone in Windows Server 2008, every server hosting a primary copy of an ActiveDirectory–integrated zone will have its own NS record appear in the new zone by default. Ifyou are creating a standard primary zone, an NS record for the local server appears in thezone by default.

However, you need to manually add NS records for servers hosting secondary zones on a primary copy of the zone.

To add an NS record, double-click any existing NS record in DNS Manager.

In the Name Servers tab, click the Add button to add the FQDN and IP address of the server hosting the secondary zone of the local primary zone. When you click OK after adding the new server, a new NS record pointing to that server appears in DNS Manager.

After you create the record, a line such as the following appears in the standard zone file:@ NS dns1.yourdomain.com.

Under the Name Servers tab you should see the name of each of the DNS servers running in Active Directory integrated mode.

Exam Tip! In Windows 2003, 2008 Zone transfers are only allowed to servers specified on the Name Servers tab

Windows Server 2008 Name Servers tab If you are migrating from a system that uses standard DNS zones, the first thing to remember about zone transfers is how the standard DNS zone servers are arranged. Standard DNS zones operate in a single master arrangement where only one DNS server has the master writable copy of the DNS zone data; all other servers have read-only copies.

The two types of standard zone servers you may encounter are:

Standard primary server: This server is the one that holds the one and only master writable copy of the zone data file. The zone data file is then replicated (via zone transfer) to all configured secondary zone servers using the standard zone data file text format. This server must make all the changes that must be made to the zone data file.

Standard secondary server: This server holds a read-only copy of the zone data file in standard zone data file text format. Secondary zones can be created and used for many reasons, but the most common reason is to provide increased performance and redundancy for the DNS zone. Secondary zones are commonly seen in locations such as screen subnets (the DMZ) or in remote offices connected to the central office over a low-speed WAN link.

In order to migrate your DNS zone data to a Windows Server 2008 computer, you will need to have a standard primary server; you will also need to make the new Windows Server 2008 DNS server a standard secondary server in that zone by creating a new standard secondary zone on that server. Once this is done, you will need to configure the standard primary server to allow zone transfers with the new Windows Server 2008 computer.

Zone Transfers tab

Enabling Zone Transfers By default, zone transfers are disabled from any zone, and you must enable them in the Zone Transfers tab.

When all of your DNS servers are located on domain controllers, you will want to use Active Directory replication to keep zone data consistent among all DNS servers. However, this option is not available when you install a DNS server on a computer that is not a domain controller.

In such cases you cannot store the zone in Active Directory and instead must use a standardzone that stores data in a local text file on each DNS server. If your organization requiresmultiple DNS servers, then the source data can be copied to read-only secondary zones hosted on other servers. In order to keep data consistent and up-to-date between a primary and any secondary zones, you need to configure zone transfers.

After you have selected the option to allow zone transfers from the zone, you have a choice of three sub-options:

To any server This is the least secure. Because a zone transfer is essentially a copy of zone data, this setting allows anyone with network access to the DNS server to discover the complete contents of the zone, including all server and computer names along with their IP addresses. This option should therefore be used only in private networks with a high degree of security.

Only to servers listed on the Name Servers tab restricts zone transfers only to secondary DNS servers that have an NS record in the zone and are therefore already authoritative for zone data.

Only to the following servers allows you to specify a list of secondary servers to which you will allow zone transfers. The secondary servers do not need to be identified by an NS record in the zone.If this is selected click Edit and enter the IP addresses for each desired DNS server.

To specify secondary servers to be notified of zone updates click Notify

Because zone transfers are pull operations, they cannot be configured to push new data to secondary zones. Instead, when a modification occurs in zone data, the primary zone sends a notification to any specified servers hosting secondary zones. When the secondary zone receives this notification, it initiates a zone transfer.

DNS servers on the secondary notify list will be told that a change has taken place and they will carry out a zone transfer by copying the zone database to themselves so that they can become current again.

Manually Updating a Secondary Zone

By right-clicking a secondary zone in the DNS Manager console tree, you can perform the following secondary zone update operations:

Reload This operation reloads the secondary zone from the local storage.Transfer From Master The server hosting the local secondary zone determines whetherthe serial number in the secondary zone’s SOA resource record has expired and then pulls a zone transfer from the master server.Reload From Master This operation performs a zone transfer from the secondary zone’s master server regardless of the serial number in the secondary zone’s SOA resource record.

Manual zone transfer steps Alternatively, you can perform the zone transfer method from the command line

dnscmd ServerName /ZoneRefresh ZoneName

Again, you will need to have the standard primary zone server available and the secondary zone already created on the new Windows Server 2008 server before performing the zone transfer. You can create the standard secondary zone on your Windows Server 2008 DNS server from the command line as well by issuing this command:

dnscmd ServerName /ZoneAdd ZoneName /Secondary MasterIPaddress

You can specify multiple IP addresses by separating them with a comma.

Manually copying zone data For all versions of Windows since Windows NT 4.0, if you still want to manually copy your zone data, you can locate the raw files at %systemroot%\system32\dns.

Delegated zonesDNS provides the ability to divide up the namespace into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. When deciding whether to divideyour DNS namespace to make additional zones, consider the following reasons to use additional zones:

A need to delegate the management of part of your DNS namespace to another location or department within your organizationA need to divide one large zone into smaller zones for distributing traffic loads among multiple servers for improving DNS name resolution performance or for creating a more fault-tolerant DNS environmentA need to extend the namespace by adding numerous subdomains at once, such as to accommodate the opening of a new branch or site

Each new delegated zone requires a primary DNS server just like a regular DNS zone. When delegating zones within your namespace, be aware that for each new zone you create, you need to place delegation records in other zones that point to the authoritative DNS servers for the new zone. This is necessary both to transfer authority and to provide correct referral to other DNS servers and clients of the new servers being made authoritative for the new zone.

How DNS delegation worksDelegation of child DNS domain allows the root DNS server to forward DNS queries for the Child DNS domain to the Child DNS Server. When a client requests a lookup for a resource on a child DNS domain against the root DNS Server, the root DNS Server forwards the query to child DNS Server.

A delegated zone is a child zone (such as east.nwtraders.msft) of a parent zone (such as nwtraders.msft) that is typically hosted on its own DNS server. With delegations, the parent zone includes an NS record for the server hosting the child zone, so when the parent receives queries for names in the child zone, those queries get redirected to the server specified in that NS record.

DNS delegation showing NS and glue record for delegated zoneFor example, if an Exchange server in company.com needs to route an e-mail to an Exchange server in na.company.com, it sends a resource record request to the DNS server in company.com. If that DNS server doesn't have a way to locate a DNS server in na.company.com, it cannot fulfill the request and the e-mail doesn't get routed.

Note these records are automatically created by the DNS console when you create a new delegation.

Creating a Delegated DNS Zone

1. Open the DNS management snap-in by selecting Start > Administrative Tools > DNS.2. Expand the DNS server, and locate your chosen zone 3. Right-click the zone, and choose the New Delegation command.4. The New Delegation Wizard appears. Click Next

5. Enter a name in the Delegated Domain field. This is the name of the domain for which you want to delegate authority to another DNS server. It should be a subdomain of the primary domain (for example, to delegate authority for microsoft.example.net, you’d enter microsoft in the Delegated Domain field). Click Next

When the Name Servers page appears, use the Add button to add the name and IP address(es) of the servers that will be hosting the newly delegated zone. Click Resolve to automatically resolve this domain name’s IP address into the IP address field. Click OK and Next.

7. Select Finish. The New Delegation Wizard disappears, and you’ll notice the new zone you just created appear beneath the zone you selected.The newly delegated zone’s folder icon is drawn in gray to indicate that control of the zone is delegated.

There's a problem with standard delegation. The DNS servers in the parent domain have no way of knowing if you take a DNS server down for maintenance. You must remember to remove the delegation record from the parent zone; otherwise, you end up with a lame delegation. Windows Server 2003 helps resolve this problem with a feature called stub zones.

A stub zone acts a little like a sneaky kid in a candy store. It knows that you want up-to-date information about the name servers in the child domain, but it doesn't have sufficient permissions to directly request a zone transfer. So it periodically asks an innocent question of the child DNS server, "Please give me all the NS records you currently have for this zone." The DNS server gets queries like this all day long and is happy to answer.

The parent DNS server then tucks these NS records into a separate zone file and refers to them when it is asked for a resource record in the child domain. It periodically refreshes the list, so there is very little chance of getting a lame delegation.

Stub ZonesA stub zone is a copy of a zone that contains only the most basic records in the master zone.

Active Directory Integrated zones work well for most networks, but they do have some issues. One limitation is if you are dealing with two separate forests (disjointed namespace), a common scenario when companies are merging or form part of a conglomerate.

Enter stub zones to the rescue. A stub zone is like a secondary zone in that it obtains its resource records from other name servers one that is authoritative for a child DNS domain.  (one or more master name servers). A stub zone is also read-only like a secondary zone, so administrators can't manually add, remove, or modify resource records on it. But the differences end here, as stub zones are quite different from secondary zones in a couple of significant ways.

Stub Zones have only 3 records, SOA, NS and A.

The records needed to locate the name servers of the master zone. The SOA identifies the primary master DNS server for the zone.The NS RR contains a list of authoritative DNS servers for a zone (primary and secondary servers)The A (glue) record holds the ip address of the DNS servers authoritative for the zone.

Secondary zones have a full set of A records. Stub zones can thus replace secondary zones in cases where achieving DNS connectivity across domains is important but providing data redundancy for the master zone is not.

Finally, the logic is that you create the Stub Zone only in the Root domain and the Stub Zone then has three records for each child domain. The A (Host) records in the Stub zone are referred to as 'glue' records.

The purpose of a stub zone is to enable the local DNS server to forward queries to the nameservers authoritative for the master zone. In this way a stub zone is functionally identical to azone delegation. However, because stub zones can initiate and receive zone transfers from the master (delegated) zone, stub zones provide the added benefit of informing parent zones of updates in the NS records of child zones.

Read only stub zone

Here you can see the contents of the stub zone.  It simply contains the SOA (Start of authority) record, NS (name server) resource records, and the glue A resource records for the delegated zone.

Stub zones are used to facilitate name resolution across domains in a manner that avoids searching the DNS namespace for a common parent server. Stub zones can thus replace secondary zones when achieving DNS connectivity across domains is important but providing data redundancy for the master zone is not. Also note that stub zones improve name resolution and eliminate the burden on network resources that would otherwise result from large zone transfers.

Why does a stub zone improve name resolution when it is implemented across domains in a large forest or other DNS namespace?

A stub zone provides a DNS server with the names of servers that are authoritative for a given zone. When this information is stored locally, the DNS server does not need to query other servers to find the authoritative servers for that zone. The process of resolving a name in that zone is therefore more efficient.

When a query is sent to a stub zone it can forward it straight to the correct DNS server as it knows it’s details.

The point of Stub Zones is to streamline administration, improve name resolution and possibly, reduce network traffic.  Needless to say, Stub Zones are only needed in large complicated Forests, and are unnecessary if you only have one domain.

Stub zones are normally used to make name resolution between forests more efficient. Stub zones are also used to keep delegated zone information up to date. This will prevent lame delegation which can cause name resolution within a forest to break.

WINS and DNS IntegrationIf you must have a WINS server, then at least achieve the best configuration possible.  Take the situation where the WINS database contains records for computers that DNS does not know about.  It costs very little to configure DNS to query WINS for such NetBIOS names.

When you configure reverse WINS lookups in DNS, the IP address of the host can be resolved to a NetBIOS computer name. The procedure works like this: The DNS server looks for a pointer record for the specified IP address. If a record is found, the server uses the record to resolve the fully qualified domain name.

How the Integration Works When a DNS client sends a name resolution query to the DNS server, the first thing the server does is look in its DNS zones to try and resolve the request.  If it fails to find a name match, DNS strips down the fully qualified domain name to just the hostname, and passes a request for that name to the WINS server.  If WINS finds such a name amongst its records, it sends back the name and IP address to DNS. And finally, DNS replies with answer to the client's query. WINS resolves computer names to IP addresses (similar to DNS), and WINS-R provides reverse DNS lookups.

WINS tabChoose the WINS tab and enter the IP address of your WINS server.

WINS-R

To configure WINS-R, follow the same steps but right-click and choose Properties on the reverse lookup zone

Global Name Zones (GNZ), The replacement for WINS.

It was possible for a Server 2003 to be a WINS server and resolve NetBIOS or NetBEUI requests over multiple network segments. (NetBIOS is not routable.)

The purpose of WINS is to allow a NetBIOS name to be converted to an IP address. Therefore computers using WINS must be using NBT (NetBIOS over TCP/IP). WINS was originally put in place to compensate for a shortcoming of NetBEUI which is the fact that it is not routable. Therefore on large Networks IP is used to transport NetBIOS and rather than using broadcasts, information is sent to the WINS server.

Microsoft Windows Server 2008 can utilize NetBIOS but it cannot be a WINS server. Instead, it utilizes Global Name Zones (GNZ). This is supposed to assist organizations to move away from WINS and allow organizations to move to an all-DNS environment. Unlike WINS, The GlobalNames zone is not intended to be used for peer-to-peer name resolution.

The GlobalNames zone is intended to provide single-label name resolution for a limited set of host names, typically corporate servers and web sites that are centrally managed and have a static ip address. The GlobalNames zone is most commonly used to hold CNAME resource records to map a single-label name to a Fully Qualified Domain Name (FQDN).

Unlike WINS, the GlobalNames Zone functionality does not allow host name entries to be registered dynamically. All host name entries in the GlobalNames Zone must be created manually.

A GlobalNames Zone can be deployed in a single-forest environment or a multiple-forest environment. A single-forest deployment of GNZ allows single-label name resolution via DNS using an Active Directory-Integrated GNZ. A multiple-forest deployment of GNZ allows single-label name resolution via DNS using an Active Directory-Integrated GNZ for each forest within the multiple-forest environment.

Deploying a GlobalNames ZoneThe GlobalNames zone is compatible only with DNS servers running Windows Server 2008.Therefore, it cannot replicate to servers running earlier versions of Windows Server.There are three basic steps in deploying a GlobalNames zone:

■ Enable GlobalNames zone support You can perform this step before or after you create the zone, but you must perform it on every DNS server to which the GlobalNames zone will be replicated.At an elevated command prompt, type:Dnscmd <yourservername> /config /Enableglobalnamessupport 1

■ Create the GlobalNames zone Create the zone on a DNS server that is a domain controller running Windows Server 2008.The GlobalNames zone is simply an Active Directory– integrated forward lookup zone that is called GlobalNames. When you create the zone, select the option to replicate zone data to all DNS servers in the forest. On the Dynamic Update page, select the Do Not Allow Dynamic Updates option, and then click Next.You should choose the option because dynamic updates are not supported with the GlobalNames zone.

How to create GlobalNames Zone

1. Open DNS Manager from Administrative Tools.2. expend the DNS server, right-click “Forward Lookup Zones”, and choose “New Zone”3. Click Next4. Choose “Primary zone” (Store zone in Active Directory), click Next5. Choose the Active Directory Zone Replication Scope. Click Next6. On Zone Name, screen, enter “GlobalNames”, click Next7. On Dynamic Update screen, choose “Do not allow dynamic updates”, click Next8. Click Finish

■ Populate the GlobalNames zone For each server that you want to be able to provide single-label name resolution for, create an alias (CNAME) resource record in the Global-Names zone. The name you give each CNAME record represents the single-label name that users will use to connect to the resource. Note that each CNAME record points to a host record in another zone.

So simply put

1.  On you DNS server, go to a cmd prompt and type

dnscmd /config /enableglobalnamesupport 1

2. Create a new forward look up zone called GlobalNames.

3. Add CNAME records for those names you would like single label resolution to.

dnscmd <yourservername> /recordadd GlobalNames <single-label-hostname> CNAME <yourservernameFQDN>

replace <yourservername> with the name of your server, replace <single-label-hostname> with the single label hostname you wish to use.

Zone Theory

A Primary zone stores the most current records and settings for the zone.

For each standard zone that is not Active Directory – integrated only one primary (master) DNS server is allowed, and this server contains the only read/write version of the zone database.

A Secondary zone is a read-only copy of the primary zone used to improve performance and fault tolerance.

In standard zones, information from a primary zone is transmitted to a secondary zone by performing a zone transfer, which is done by copying the zone file from the primary server to a secondary server. A zone transfer can be a full zone transfer (called an AXFR), in which the entire contents of the zone is copied from the primary server to the secondary server during each zone transfer, or an incremental zone transfer (called an IXFR), in which only changed information is transmitted after an initial AXFR, in order to cut down on bandwidth usage between primary and secondary servers. When a secondary zone is created, you must specify the IP address of one or more master DNS servers from which you want to copy the zone; these can be the Primary DNS server for the zone or another Secondary DNS server.

Exam Tip

To migrate a standard primary server, configure a secondary server, transfer the zone to secondary server and then promote the secondary server to a primary server after the secondary server has been promoted you can delete the original primary server.

A Stub zone is a copy of a zone that contains only those resource records necessary to identify the actual authoritative DNS servers for that zone.

Stub zones only contain resource records (of type SOA, NS, and A) that specify the authoritative DNS server(s) (primary and secondary) for the zone, and therefore simply redirect a client queries to the DNS server(s) that holds the authoritative zone and is able to resolve these requests.

Reverse lookup zoneMost queries sent to a DNS server are forward queries; they request an IP address based on a DNS name. DNS also provides a reverse lookup process, which enables a host to determine another host's name based on its IP address.For example, a query contains the equivalent of "What is the DNS domain name of the host at IP address 192.168.100.1?" To answer this query, the in-addr.arpa domain is consulted.

The in-addr.arpa domain tree makes use of the pointer (PTR) resource record, which is used to associate the IP address with the host name. This lookup should correspond to an address (A) resource record for the host in a forward lookup zone.

The Dcpromo utility does not create any reverse zones on the DNS server. Therefore, to make the DNS server configuration fully operational, it is recommended that you: manually create an appropriate reverse zone (because some utilities and applications use it), enable dynamic updates for it, and re-register the domain controller address with the ipconfig / registerdns command.

Active Directory Service Integration

Store the zone in Active Directory (available only if DNS server is a domain controller)

This check box in the Change Zone Type box allows you to store the primary zone information in the Active Directory database instead of in the WINDOWS\System32\Dns folder.

In Active Directory integrated zones, zone data is replicated through AD. In most cases this eliminates the need to configure zone transfers to secondary servers.

An Active Directory integrated forward lookup zone is similar to a standard primary zone. Outside of Active Directory, primary and secondary servers are necessary because they follow a singlemaster update model, where only one server contains a writable copy of the zone database.

However, Active Directory integrated zones follow a multimaster update model, meaning all Active Directory integrated zones contain a read/write copy of the zone and can make changes to the zone information.

Zone Transfers

While standard DNS queries use UDP port 53, zone transfers use TCP port 53. UDP is more efficient for DNS queries, which typically only require two packets: a one-packet query sent to the DNS server and a one-packet response sent back to the client. Zone transfers can be very large (especially the first zone transfer), and thus they require the reliability and flow control of TCP. Allowing zone transfers is a significant security vulnerability, because the recipient can immediately identify every computer in your organization, and the processing time required can be used to create a denial-of-service attack. Fortunately, the Windows Server 2008 DNS server will not allow zone transfers from unauthorized servers. To provide an additional layer of protection, use network firewalls and Windows Firewall to block TCP port 53 .”

The following events trigger zone transfers:

• A transfer is manually initiated using the console at the secondary server.• The zone refresh interval expires.• The DNS Server service is started at the secondary server.• The master server notifies the secondary server of a zone change or changes.

Zone transfers are always initiated at the secondary server for a zone and sent to the server's configured master server, which acts as its source for the zone. A master server can be any other DNS server that loads the zone, such as either the primary server for the zone or another secondary server

In a full zone transfer, the primary DNS server hosting the primary zone transfers a copy ofthe entire zone database to the secondary DNS server hosting a copy of the zone. Whether a full or incremental transfer, the following process takes place:

1. When the value of the Refresh field in the Start of Authority (SOA) resource record for the zone hosted on the secondary DNS server expires, the secondary DNS server queries the primary DNS server for the SOA record of the primary zone.

2. The primary DNS server for the zone replies to the query with the SOA resource record.3. The secondary DNS server for the zone compares the serial number in the returned SOArecord to the serial number in the SOA record for the local copy of the zone. If the serial number sent by the primary DNS server for the zone is higher than the serial number for its local zone, the zone needs to be updated, and the secondary DNS server sends anAXFR request (a request for a full zone transfer) to the primary DNS server.

4. The primary DNS server receives the request for the zone transfer and sends the full zone database to the secondary DNS server, essentially re-creating the copy of the zone while maintaining any zone settings.

An incremental zone transfer uses the following process:

1. Initially, when a secondary server is first configured, it sends a full zone transfer request (AXFR) to its master DNS server. The master (source) server responds by sending a full copy of the zone to the secondary (destination) server.

2. Each zone delivery has a version indicated by a serial number in the properties of the SOA resource record and a refresh interval (by default, 900 seconds). The refresh interval indicates at what interval the secondary server should request another copy of the zone from the source server.

3. After the interval expires, the destination server submits an SOA query to request an incremental zone transfer.

4. The source server answers the query by sending its SOA record, which contains the aforementioned serial number.

5. The destination server compares the serial number from the SOA record to its current local serial number. If the numbers are equal, no transfer is requested, and the refresh interval is reset.

6. If the value of the serial number in the SOA response is higher than its current local serial number, records on the source are newer than the local records and an IXFR query is sent to the source server. This query contains the local serial number so the source server can determine which records the destination server needs.

7. Depending on several factors, the source server responds with either an incremental or full transfer of the zone. The primary DNS server for a zone is not required to perform an incremental zone transfer. It can choose to perform a full zone transfer under the following conditions:

• The primary DNS server does not support incremental zone transfers.• The primary DNS server does not have all the necessary data for performing an incremental zone transfer.

A DNS infrastructure with zone transfers between sites

Exam Tip

Many exams questions ask you to look at a network and decide how best to deploy a second or third DNS server. These questions have clues like, "you need to minimize zone transfer traffic" or "you need to make sure clients can resolve dns queries when WAN links are down," etc.

Caching Only = Slow WAN link - Since caching only servers do not do zone transfers, they create less traffic over the WAN link than other types would. They really are like just big caches of DNS info for the clients on their network since they do not resolve queries on their own the first time they get them or keep copies of the database, they just remember the queries they've resolved before, saving having to forward those queries across the WAN link and decreasing traffic over it.

Stub Zones = Knowing where to forward w/out fault tolerance - These are usually used when you want the Domain servers in one zone to know where to forward queries for another zone without having to have your primary DNS servers keep up with changes in the DNS servers in the other zone. They are similar to delegating a zone, but they allow NS records to be kept in the parent domain instead of a delegated domain keeping its own separate NS records. Unlike Secondary zones, they do NOT give you fault tolerance, redundancy, or load balancing, so if you need any of these, go with a secondary zone instead or if the parent zone does not want to manage NS records.

Stub zones enable a parent domain to keep an updated list of name servers in a child domain

Secondary Zones = Decreases Traffic on WAN link, but still has full copy of zone - A secondary zone is a read-only copy of the primary zone, so the server can resolve queries so long as the information is contained in either the database or the server's cache without forwarding or recursion. However, these servers still have to participate in zone transfers to update their databases, so they still have this traffic, although they do not have to send updates to the primary zone DNS servers since they cannot add to the database. If you use AD, this happens automatically with replication.

Conditional Forwarding = Company mergers - Only sends queries regarding the other domain to servers in the other domain, limiting traffic and keeping queries from one domain local as much as is possible.

Zone Delegation - Giving Up Control of a subset of your domain to another Admin - for example, if you have a company that grows named proprofs.com and it gets to the point where a subdomain needs to be created called random.proprofs.com and that subdomain is going to have it's own IT team, then you probably will want them to manage their own DNS servers. Simply create a zone delegation, giving their DNS servers authority over that

subdomain. Now your DNS servers will automatically forward all queries regarding random.proprofs.com to their DNS servers.

Creating an Application Directory Partition for DNS

Create a custom application directory partition and then modify the Nwtraders.msft zone to store data in that partition. (Note that zone data can only be stored in directory partitions for Active Directory–integrated zones.)

Create the New Application Directory Partition on Dcsrv1.

1. Log on to Nwtraders from Dcsrv1 as a domain administrator.2. At an elevated command prompt, type the following:dnscmd . /createdirectorypartition DNSpartitionA.nwtraders.msft

This command creates an application directory partition that will replicate in Active Directory only to domain controllers that you enlist in the partition. You do not need to enlist the local server in the partition.

Storing Zone Data in the New Application Directory PartitionModify the properties of the Nwtraders.msft zone so that its data is stored in the new application directory partition you have just created.1. While you are logged on to Nwtraders from Dcsrv1 as a domain administrator, openDNS Manager.2. In the DNS Manager console tree, expand the Forward Lookup Zones folder, select andthen right-click the Nwtraders.msft zone, and then choose Properties.3. In the General tab of the Nwtraders.msft Properties dialog box, click the Change buttonfor replication. This button is found directly to the right of the text “Replication: All DNSServers In This Domain.”4. In the Change Zone Replication Scope dialog box that opens, select To All Domain ControllersIn The Scope Of This Directory Partition.5. In the associated drop-down list box, select DNSpartitionA.nwtraders.msft, click OK.6. In the Nwtraders.msft Properties dialog box, click OK.The Nwtraders.msft zone data is now stored in the new application directory partition you have created on Dcsrv1. Other domain controllers that are DNS servers in theNwtraders.msft forest will receive a copy of the Nwtraders.msft primary zone only if you enlist those servers in the new partition by using the following command:dnscmd <server name> /enlistdirectorypartition DNSpartitionA.nwtraders.msft