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 Properties You¶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 Tab The Status indicator and the associated Pause button let you see and control whether this zone can be used to answer queries. When the zone is running, the server can use it to answer client queries; when it¶s paused, the server won¶t answer any queries it gets for that particular zone. The Type indicator and its Change button allow you to select the zone type. As you change the type, the controls yousee below the horizontal dividing line will change too. For primary zones, you¶ll see a fieldthat lets you select the zone filename. For secondary zones, you¶ll get controls that allow youto specify the IP addresses of the primary servers. When you change to the AD -integrated zone, youhave 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 replicationscope if the zone is stored in Active Directory .

Configuring Zone Replication for Active Directory ±Integrated Zones You can install Active Directory ±integrated zones only on domain controllers on which the DNS Server role is installed. Active Directory ±integrated zones are generally preferable to standardzones because they offer multimaster data replication, simpler configuration, and improved 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 a ny 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 ty pe 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 syntax DnsCmdServerName /CreateDirectoryPartition FQDN of partition

Example Create an application directory partition named DNSPartiti on on a domain controller DC01. Open a command prompt and enter dnscmd 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. DnsCmdServerName /EnlistDirectoryPartition FQDN of partition To configure the domain controller named DC02 to host this custom application directory partition. Open a command prompt and enter dnscmd DC02 /enlistdirectorypartit ion CustomDNSPartition.abc .com

The following appears DNS Server DC02 enlisted directory partitio n: 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 p roperties 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 Secure Allows 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 c omputers not in your active directory f rom writing entries in your DNSa nd allows AD client computers to automatically create and update their own resource records.

Here as the Zone is Primary and not Active DirectoryIntegrated the secure option is unavailable Select either None or N onsecure and Secure it is best practice to select N onsecure and Secure because not allowing pc's to update their own DNS entries creates an administrative overhead.

Agingand 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 automaticall y 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. Scavenging By configuring the DNS Server to t rack 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. AgingProvides 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 b oth 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 Zoneson 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 Confirmationdialog 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 norefreshinterval and the refresh interval. Modifying the no -refresh interval The no-refresh interval is the period after a timestampduring which a zone or server rejects a timestamp refresh. The no -refresh feature prevents the sever from processing unnecessary refreshes and reduces unnecessary zonetransfer traffic. The default no -refresh interval is seven days. Modifying refresh intervals The refresh interval is the time after the no -refresh intervalduring 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, dynamicallyregistered 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. 2. 3. 4. Click Start > Administrative Tools > DNS. This start s the DNS Server MMC snap-in. In the console tree, click the applicable DNS server. On the Action menu, click Properties. 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 Scavenging When automatic Scavenging is not enabled, you can perform manual scavenging in zones by right-clicking the server icon in the DNS Manager con sole tree and then choosing Scavenge StaleResource 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 S then bring up properties on a record

S

i

S

The St t f A thorit S A resource record is l s first i st dard one. The Start of Authorit S A tab allows ou to ake any adjust ents necessary. You can change the ri ary server that holds the S A record, and you can change the erson res ponsible for anaging the S A. inally, one of the ost i portant features is that you can change your S server configuration without deleting your ones and having to re -create the wheel. hen a S server loads a one, it uses the S A resource record o determine basic and t authoritative properties for the one. These settings also determine how often one transfers are performed between primary and secondary servers.

S i l m containsthe revision number of the one file. This number increases each time a resourcerecord changes in the one or when you manually increment the value in this tab byclicking Increment. Each time a one is changed this number is incremented by f a value of to indicate a new one version. This tells secondary one transer servers that a change has occurred and a one transfer is needed.

hen ones are configured to perform one transfers to one or more secondary servers,the secondary servers uery the master server intermittently for the serial number of thezone. This uery is called the SOA q . If, through the S A uery, the serial number ofthe

£¢ ¡ 

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 masterserver i s greater than that at the requesting secondary server, the secondary server initiatesa transfer. NOTE When you click the Increment button, you force a zone transfer. Primary Server containsthe full computer name for the primary DNS server of the zone. This name mustend 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 peri od. The name ³hostmaster´ is used in this field by default.This name can be seen when using the internet whois command Refresh Interval determines howlong 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 current SOA resource record for the zon e from its master server which answersthis SOA query. The secondary DNS server then compares the serial number of thesource server¶s current SOA resource record (as indicated in the master¶s response) withthe serial number of its own local SOA resource record. If they are different, the secondaryDNS server requests a zone transfer from the primary DNS server. The default valuefor this setting is 15 minut es. Exam Tip Increasing the refresh interval decreases zone transfer traffic. Retry Interval determines how longa secondary server waits before retrying a failed zone transfer. Normally, this time is lessthan the refresh interval. The default value is 10 minutes. Expires After determines the length oftime that a secondary server, without any contact with its master server, continues toanswer queries from DNS clients. After this time elapses, the data is considered unre liable. The default value is one day.

Minimum (Default) TTL determines the default Time to Live (TTL) that is applied to all resource records in thezone. 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 therecord when that record¶s TTL has expired. TTL For This Record determines the TTL of thepresent SOA resource record. This value overrides the default value setting in the precedingfield. After you create it, an SOA resource record is represented textually in a standard zone file in the manner shown in this example: @ IN SOA computer1.d omain1.local. hostmaster.domain1.local. ( 5099 ; serial number 3600 ; 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 youcreate a zone in Windows Server 2008, every server hosting a primary copy of an Active Directory±integrated zone will have its own NS record appear in the new zone by default. If you are creating a standard primary zone, an NS record fo r the local server appears in the zone by default. However, you need to manually add NS records for servers hosting secondary zones on a primarycopy of the zone. To add an NS record, double -click any existing NS record in DNS Manager . In theName Servers tab, click the Add button to add the FQDN and IP address of the server hostingthe 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:
y

y

Standard primary server: This server is the one that holds the one and only master writable copy of the zone d ata 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 se rver: 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 theZone Transfers tab. When all of your DNS servers are located on domain controllers, you will want to useActive Directory replication to keep zone data consistent among all DNS servers. However, thisoption 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 standard zone that stores data in a local text file on each DNS server. If your organization requires multiple DNS servers, then the source data can be copied to read -only secondary zones hostedon other servers. In order to keep data consistent and up -to-date between a primary and anysecondary zones, you need to configure zone transfers.

After youhave selected the option to allow zone transfers from the zone, you have a choice of threesub-options: To any serverThis is the least secure. Because a zone transfer is essentially acopy of zone data, this setting allows anyone with network access to the DNS server todiscover the complete contents of the zone, including all serv er and computer names along with their IP addresses. This option should therefore be used only in private networkswith a high degree of security. Only to servers listed on the Name Servers tab restricts zone transfersonly to secondary DNS servers that have an NS record in the zone and are thereforealready authoritative for zone data. Only to the following servers allows you to specify a list of secondaryservers to which you will allow zone transfers. The secondary servers do not need to beidentified by an NS record in the zone. If this is selected click Edit and enter the IP addres ses for each desired DNS server.

To specify secondary servers to be notified of zone updates click Notify Because zone transfers are pull operations, they cannotbe configured to push new data to secondary zones. Instead, when a modification occursin zone data, the primary zone sends a notification to any specified servers hosting secondaryzones. 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 canperform 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 zo ne determines whether the serial number in the secondary zone¶s SOA resource record has expired and thenpulls a zone transfer from the master server. Reload From Master This operation performs a zone transfer from the secondaryzone¶s master server regardless of the serial number in the secondary zone¶s SOAresource record.

Manual zone transfer steps Alternatively, you can perform the zone transfer method from the command line dnscmdServerName /ZoneRefreshZoneName 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 lin e as well by issuing this command: dnscmdServerName /ZoneAddZoneName /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 stil l want to manually copy your zone data, you can locate the raw files at %systemroot% \system32\dns.

Delegated zones DNS provides the ability to divide up the namespace into one or more zones, which can thenbe stored, distributed, and replicated to other DNS servers. When deciding whether to divide your DNS namespace to make additional zones, consider the following reasons to use additionalzones: A need to delegate the management of part of your DNS namespace to another locationor department within your organization A need to divide one large zone into smaller zones for distributing traffic loads amongmultiple servers for improving DNS name resolution performance or for creating a morefault-tolerant DNS environment A need to extend the namespa ce by adding numerous subdomains at once, such as toaccommodate the opening of a new branch or site Each new delegated zone requires a primary DNS server just like a regular DNS zone. Whendelegating zones within your namespace, be aware that for each new zone you create, you needto place delegation records in other zones that point to the authoritative DNS servers for thenew zone. This is necessary both to transfer authority and to provide correct referral to otherDNS servers and clients of the new servers being made authoritative for the new zone. How DNS delegation works Delegation 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 request s 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 includesan NS record for the server hosting the child zone, so when the parent receives queries for namesin the child zone, those queries get redirected to the server specified in that NS record. DNS delegation showing N S and glue record for delegated zone For 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. 2. 3. 4. Open the DNS management snap -in by selecting Start > Administrative Tools > DNS. Expand the DNS server, and locate your chosen zone Right-click the zone, and choose the New Delegation command. 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 delegateauthority to another DNS server. It should be a subdomain of the primary domain (forexample, to delegate authority for microsoft.example.net, you¶d ent er microsoftin theDelegated Domain field). Click Next

When the Name Servers page appears, use the Add button to add the name and IPaddress(es) of the servers that will be hosting the newly delegated zone. Click Resolve to automatically resolve this do main 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 newzone 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 N S 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 Zones
A 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 co uple 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 serv ers 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 c onnectivity 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) reco rds 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 name servers authoritative for the master zone. In this way a stub zone is functionally identical to a zone delegation. However, because stub zones can initiate and receive zone transfers from themaster (delegated) zone, stub zones provide the added bene fit 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 thatavoids searching the DNS namespace for a common parent server. Stub zones can thus replacesecondary zones when achieving DNS connectivity across domains is important but providingdata redundancy for the master zone is not. Also note that stub zones improve name resolutionand eliminate the burden on network resources that would otherwise result from largezone transfers. Why does a stub zone improve name resolution when it is implemented acrossdomains in a large forest or other DNS na mespace? A stub zone provides a DNS server with the names of servers that are authoritativefor a given zone. When this information is stored locally, the DNS server does notneed to query other servers to find the authoritative servers for that zone. The p rocessof 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 r esolution 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 Integration If 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, t he 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 dom ain 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 qu alified 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 wit h answer to the client's query. WINS resolves computer names to IP addresses (similar to DNS), and WINS R provides reverse DNS lookups. WINS tab Choose 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 Z ones (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 in tended 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 Zone The 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 createthe zone, but you must perform it on every DNS server to which the GlobalNames zonewill be replicated. At an elevated command prompt, type: Dnscmd<yourservername> /config /Enableglobalnamessupport 1 Create the GlobalNames zone Createthe zone on a DNS server that is a do main 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 , andthen click Next. You should choose the option because dynamic updates are not supported with the GlobalNameszone.

How to create GlobalNames Zone 1. 2. 3. 4. 5. 6. 7. 8. Open DNS Manager from Administra tive Tools. expend the DNS server, right -click ³Forward Lookup Zones´, and choose ³New Zone´ Click Next Choose ³Primary zone´ (Store zone in Active Directory), click Next Choose the Active Directory Zone Replication Scope. Click Next On Zone Name, screen, enter ³GlobalNames´, click Next On Dynamic Update screen, choose ³Do not allow dynamic updates´, click Next Click Finish

Populate the GlobalNames zone For each server that you want to be able to providesingle -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 namethat users will use to connect to the resource. Note that each CNAME record points to ahost 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> /recorda dd 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 zon e transfer (called an IXFR), in which only changed information istransmitted after an initial AXFR, in order to cut down on bandwidth usage betweenprimary and secondary servers. When a secondary zone is created, you must specify theIP address of one or mor e 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 zone Most 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, whi ch 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 hostin 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. Outsideof Active Directory, primary and secondary servers are necessary because they follow a singlemas terupdate model, where only one server contains a writable copy of the zone database.

However, Active Directory integrated zones follow a multimaster update model, meaning allActive Directory integrated zones contain a read/write copy of the zone and can make changesto 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 t ransfers 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 i n 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, u se 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'sconfigured master server, which acts as its sou rce for the zone. A master server can be anyother DNS server that loads the zone, such as either the primary server for the zone or anothersecondary server In a full zone transfer, the primary DNS server hosting the primary zone transfers a copy of the entire zone database to the secondary DNS server hosting a copy of the zone. Whether afull or incremental transfer, the following process takes place: 1. When the value of the Refresh field in the Start of Authority (SOA) resource recordfor the zone hosted on the secondary DNS server expires, the secondary DNS serverqueries 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 fo r the zone compares the serial number in the returned SOA record to the serial number in the SOA record for thelocal copy of the zone. If th e serialnumber sent by the primary DNS server for the zone is higher than the serial numberfor its local zone, the z one needs to be updated, and the secondary DNS server sends an AXFR 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 fullzone database to the seconda ry DNS server, essentially re -creating the copy of the zonewhile 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 transferrequest (AXFR) to its master DNS server. The master (source) server responds bysending 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 ofthe SOA resource record and a refresh interval (by default, 900 seconds). The refreshinterval indicates at what interval the secondary server should request another copy ofthe zone from the source server. 3. After the interval expires, the destination server submits an SOA query to request anincremental zone transfer. 4. The source server answers the query by sending its SOA record, which contains theaforementioned serial number. 5. The destination server compares the serial number from the SOA record to its currentlocal serial number. If the numbers are equal, no transfer is requested, and the refreshinterval is reset. 6. If the value of the serial number in the SOA response is higher than its current localserial number, records on the source are newer than the local records an d an IXFRquery is sent to the source server. This query contains the local serial number so thesource server can determine which records the destination server needs. 7. Depending on several factors, the source server responds with either an incrementalor full transfer of the zone. The primary DNS server for a zone is not required to performan incremental zone transfer. It can choose to perform a full zone transfer underthe following conditions: ‡ The primary DNS server does not support incremental zone t ransfers. ‡ The primary DNS server does not have all the necessary data for performing anincremental 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 l inks 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 data base. 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 al l 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 theNwtraders.msft zone to store data in that partition. (Note that zone da ta can only be stored indirectory 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 . /createdirectorypartitionDNSpartitionA.nwtraders.msft This command creates an application directory partition that will replicate in ActiveDirectory only to domain controllers that you enlist in the partition. You do not need toenlist the local server in the partition. Storing Zone Data in the New Application Directory Partition Modify the properties of the Nwtraders.msft zone so that its data isstored in the new application directory partition you have just created. 1. While you are logged on to Nwtraders from Dcsrv1 as a domain administrator, open DNS Manager. 2. In the DNS Manager console tree, expand the Forward Lookup Zones folder, select and then 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 button for replication. This button is found directly to the right of the text ³Replication: All DNS Servers In This Domain.´ 4. In the Change Zone Replication Scope dialog box that opens, select To All Domain Controllers In 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 partitionyou have created on Dcsrv1. Other domain controllers that are DNS servers in the Nwtraders.msft forest will receive a copy of the Nwtraders.msft primary zone only if youenlist those servers in the new partition by using the following command: dnscmd<server me>/enlistdirectorypartitionDNSpartitionA.nwtraders.msft

¥¤

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times