c



  

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.

    

¦ou¶ll see six tabs in the zone¶s Properties dialog box for a forward or reverse lookup zone.
¦ou 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.

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

   stores the most current records and settings for the zone.
For each standard zone that is Active Directory ± integrated only one primary DNS
server is allowed, and this server contains the only read/write version of the zone database.

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

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



   
 !! 
  
 " 
" 
   
     !   

   # 

 
" 

  "  
 
 
" 
 #

$ 


"    " %   

   "   " 

" 
    

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 .
u  &  "    '%   

¦ou 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.
(


$  and 

$  , 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. ¦ou 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:

(
)*      ±


"


 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.

)*      ±


"

  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.

  ±  


  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. 

  
    
 
 + *
c  " $ 

u
     ±

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

Use the following syntax


u  "  ,u      (- 

Example
Create an application directory partition named DNSPartiti on on a domain controller DC01.

Open a command prompt and enter

—
— 
 —
 

  
   

When the application directory partition has been successfully created, you see.




 ——
 

  
   
 — —


 

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.


u  "  ,.
   (-  

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

Open a command prompt and enter

—
—  
—
 

  

   
The following appears


 
——
 

  


   
 — —


 

  

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.

 (    


  
 
    
"
! 
  
"

 
   "   $ 

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. ¦ou can change this
default zone file name using the Zone File Name field.

 


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

Ê

    
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.


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


/ 
  
    "   %    
 

" 

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.


 "  Ê

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.


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

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.

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

0  
"   
 12
  ,"  
" 
     
"      " $ 

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

%+ *
 " c
!" 
 
  $ .   "  

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

 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 V 

 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 ¦ou need to understand the no -refresh and refresh intervals for the 70 -642 exam.

& 
 )& 
 "


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.

"  


1. Click Start > Administrative Tools > DNS. This start s 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 ³ . 
" 
  
´ 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.
†"  
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.

3¦ V  V

   
V V    V
  V 
V VV 
VV    
Y
 


 


R 

t

i  
tti  

 
 it Vi
 A 
 i
t
S t

i  

ti
   


      

R
St t f A t it S A 


 i l  fit i t  
. R
Stt

f At it S A t
ll  t 
 jt
t

 . ¦    
t

i  

 t t l t
S A 
,       
t

 
 i
l
f
 i  t
S A. i ll , 
f t
t i t t f
t
 i t t     

S 

  fiti it t 
l
ti   
   i  t 

t
t


l.

 S 

 l  
, it 
 t
S A 


 t 
t
i

i  
t itti

ti
 f t

. R


tti  l 
t
i
 ft

t f



f


t

i   
  

.

     ti t

ii 

 f t

fil
. R i 

 i 



 ti
 


   
 i t

 
  ll i 

t t
l

i t i t

lii  I 

t. E ti
 
i   
 t i 

 i i 

t


 l
f t i it

 

i . R i t
ll 
  
t f
 

 t t 
  
 
    
t f
 i


.


 
 fi
 t 
f 
t f
 t 
 

  

,t


  

 
 t
t
 

 i t
itt
tl f t

il 

 f t

.

R i 
 i ll
 t
 !
 . If, t  t
S A 
 , t

il 

 ft

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.

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

   " containsthe full computer name for the primary DNS server of the zone.
This name mustend with a period.

&

 
 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

& 
% " 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.

&  % " 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.
.4
 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.
† 5 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.

5( 
&  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:

 
—   


— ! 
"##$

 

ÿ

ÊÊÊ Ê
Ê


ÊÊ Ê
ÊÊ
 

ÊÊÊ ÊÊ
%&$ ''(! & 

  " & 


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:
—

— 

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

Exam Tip! %+ *

c 6!c
  

 * 
"

  
   "

+ *
 " c
  "

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:

O     
" 3 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.
O   
  
" 3 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.

  



Enabling Zone Transfers

0 !  

  
   ! 
   
   

 $

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:


" This 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.


"

    "
 restricts zone transfersonly to secondary
DNS servers that have an NS record in the zone and are thereforealready authoritative for
zone data.

 *
"
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 .  and enter the IP addres ses for each desired DNS server.

 
  
"
    
7 

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.

†8     


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

&  This operation reloads the secondary zone from the local storage.
 
 ( †
 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.
&  ( †
 This operation performs a zone transfer from the secondaryzone¶s
master server regardless of the serial number in the secondary zone¶s SOAresource record.
†  
 
 

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

—
— 
 
   

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. ¦ou can create the standard secondary zone on your Windows Server 2008 DNS
server from the command lin e as well by issuing this command:

—
— 
 ——  
 — 

 ——



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

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

Ê
Ê
Ê
Ê
Ê
Ê
Ê



   

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.

/*  * 7

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.

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

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

u     

9$Open the DNS management snap -in by selecting Start > Administrative Tools > DNS.
c$Expand the DNS server, and locate your chosen zone
6$Right-click the zone, and choose the New Delegation command.
:$The New Delegation Wizard appears. Click Next
Õ$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
 
in 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.
$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. ¦ou 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  " Vis 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.



" 6 
!! $ 

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.

+ # 


  * 
   
" 

7*
;
 
$ 

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.


+% %   

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

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

 

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

 
 
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

¦ou 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:

 <
"  =,,. 

 9 

Ŷ 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    

"
 
$ On the Dynamic Update page, select  *
8 
 , andthen click Next.
¦ou should choose the option because dynamic updates are not supported with the
GlobalNameszone.

/*  

 

1. Open DNS Manager from Administra tive Tools.

2. expend the DNS server, right -click ³Forward Lookup Zones´, and choose ³New Zone´
3. Click Next
4. Choose ³Primary zone´ (Store zone in Active Directory), click Next
5. Choose the Active Directory Zone Replication Scope. Click Next
6. On Zone Name, screen, enter ³GlobalNames´, click Next
7. On Dynamic Update screen, choose ³Do not allow dynamic updates´, click Next
8. 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


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

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


 <
"  =,   
<
 ) )
 =u†.
<
"  (-=

replace<yourservername> with the name of your server, replace <single -label-hostname>

with the single label hostname you wish to use.

   

   stores the most current records and settings for the zone.

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

    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.
Ê
Ê
Ê
 is a copy of a zone that contains only those resource records necessary to
identify the actual authoritative DNS servers for that 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.

& "
7
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  V #$%&'  ( which is used
to associate the IP address with the host name. This lookup should correspond to an
# '   for the hostin a forward lookup zone.

The Dcpromo utility does not create any 
 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.


"    " %   

   "   " 

" 
    

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  
) V     " V 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.
Ê

  



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.











 
  *  

 * 


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.

u?*+7 - 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.


= 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.

    7   
 
"
 





   
?  

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

u ( * ?u 

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

u      


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.

9$Log on to Nwtraders from Dcsrv1 as a domain administrator.

c$At an elevated command prompt, type the following:

 $,      $* 
$
 

This command creates an application directory partition that will replicate in ActiveDirectory
only to domain controllers that you enlist in the partition. ¦ou do not need toenlist the local
server in the partition.

    *    

Modify the properties of the Nwtraders.msft zone so that its data isstored in the new
application directory partition you have just created.
9$While you are logged on to Nwtraders from Dcsrv1 as a domain administrator, open
DNS Manager.
c$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.
6$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.´
:$In the Change Zone Replication Scope dialog box that opens, select To All Domain
Controllers
In The Scope Of This Directory Partition.
Õ$In the associated drop -down list box, select DNSpartitionA.nwtraders.msft, click OK.
@$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:


 ±

 
, 
     $* 
$