Global Catalog
Global Catalog
Global Catalog
The Global Catalog (GC) has two primary functions. First, it acts as a domain controller that
stores object data and manages queries about objects and their most common attributes (called
the Global Catalog Partial Attribute Set, or PAS). Second, it provides data that permits network
logon. In single domain controller environments, the Active Directory and GC reside on the
same server. Where multiple domain controllers exist, as we discuss later, it is often advisable to
move the GC to its own dedicated domain controller. All domain trees have a GC, and must
reside on a domain controller.
NOTE
In the absence of a GC, a user can log on only to the local system. However, a member of the
Domain Administrators group can log on to the network without a GC.
Network connectivity to the Global Catalog server must be fast and of high quality because
access to a GC is required for successful network logon. Given that a site is bounded by rapid
and reliable network connectivity, at least one GC domain controller per site is recommended.
Multimaster domain replication assumes that all domain controllers eventually receive
synchronized Active Directory information. However, there are master domain controller
relationships to handle certain Active Directory information within a domain or forest. The
master roles are defined below:
Domain naming master. This domain controller manages the addition and removal of
domains in the forest. A forest can have only one domain naming master, which can be
transferred to another domain controller through the Active Directory Domains and
Trusts snap-in.
Infrastructure master. The infrastructure master is responsible for managing group and
user references. Expect a delay in changes to user g when they are made across domains.
Updates to other domains are made by the infrastructure master domain controller via a
process called multimaster replication. This master role can be transferred to another
domain controller through the Active Directory Users and Computers snap-in.
PDC Emulator master. In a mixed Windows 2000 and Windows NT environment, the
PDC Emulator master supports the BDCs. Thus, it manages user account and password
changes, and forwards that information to the Windows NT BDC. In a native mode
Windows 2000 environment, the PDC Emulator master receives preference in the
replication of user account passwords. Before a logon fails, it is checked for updated
information. This master role can be transferred to another domain controller through the
Active Directory Users and Computers snap-in.
Relative ID master. A single relative ID master in each domain of a tree manages the
allocation of sequential relative IDs (RIDs) to each of the domain controllers. This makes
all security IDs (SIDs) created in a domain relative to the domain controller. This master
role can be transferred to another domain controller through the Active Directory Users
and Computers snap-in.
Schema master. The schema master controls updates to the domain schema data. There
is one schema master in the entire forest. It can be transferred to another domain
controller through the Active Directory Schema Master snap-in.
CAUTION
Microsoft issues a word of caution regarding potential conflicts between the infrastructure master
and the Global Catalog. In environments where more than one domain controller exists, the
Global Catalog should not be hosted on a controller that also hosts the infrastructure master.
Because the infrastructure master compares its data with the Global Catalog, there may be
significant replication impacts, and full replication may fail. In particular, outdated information
will not be seen. The exception to this rule about separating the Global Catalog and the
infrastructure master is an environment where every domain controller retains a copy of the GC.
Group Policy is a feature of the Microsoft Windows NT family of operating systems. Group Policy is a set
of rules which control the working environment of user accounts and computer accounts. Group Policy
provides the centralized management and configuration of operating systems, applications and users'
settings in an Active Directory environment. In other words, Group Policy in part controls what users can
and can't do on a computer system. Although Group Policy is more often seen in use for enterprise
environments, it is also common in schools, smaller businesses and other kinds of smaller organizations.
Group Policy is often used to restrict certain actions that may pose potential security risks, for example:
to block access to the Task Manager, restrict access to certain folders, disable the downloading of
executable files and so on.
You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an
MMC snap-in tool. Depending on the FSMO role that you want to transfer, you can use one of
the following three MMC snap-in tools:
To transfer the FSMO role the administrator must be a member of the following group:
Transferring the RID Master, PDC Emulator, and Infrastructure Masters via GUI
To Transfer the Domain-Specific RID Master, PDC Emulator, and Infrastructure Master FSMO
Roles:
1. Open the Active Directory Users and Computers snap-in from the Administrative Tools
folder.
2. If you are NOT logged onto the target domain controller, in the snap-in, right-click the
icon next to Active Directory Users and Computers and press Connect to Domain
Controller.
3. Select the domain controller that will be the new role holder, the target, and press OK.
4. Right-click the Active Directory Users and Computers icon again and press Operation
Masters.
5. Select the appropriate tab for the role you wish to transfer and press the Change button.
6. Press OK to confirm the change.
7. Press OK all the way out.
1. Open the Active Directory Domains and Trusts snap-in from the Administrative Tools
folder.
2. If you are NOT logged onto the target domain controller, in the snap-in, right-click the
icon next to Active Directory Domains and Trusts and press Connect to Domain
Controller.
3. Select the domain controller that will be the new role holder and press OK.
4. Right-click the Active Directory Domains and Trusts icon again and press Operation
Masters.
5. Press the Change button.
6. Press OK to confirm the change.
7. Press OK all the way out.
In a forest, there are at least five FSMO roles that are assigned to one or more domain controllers. The
five FSMO roles are:
Schema Master: The schema master domain controller controls all updates and modifications to
the schema. To update the schema of a forest, you must have access to the schema master.
There can be only one schema master in the whole forest.
Domain naming master: The domain naming master domain controller controls the addition or
removal of domains in the forest. There can be only one domain naming master in the whole
forest.
Infrastructure Master: The infrastructure is responsible for updating references from objects in
its domain to objects in other domains. At any one time, there can be only one domain
controller acting as the infrastructure master in each domain.
Relative ID (RID) Master: The RID master is responsible for processing RID pool requests from all
domain controllers in a particular domain. At any one time, there can be only one domain
controller acting as the RID master in the domain.
PDC Emulator: The PDC emulator is a domain controller that advertises itself as the primary
domain controller (PDC) to workstations, member servers, and domain controllers that are
running earlier versions of Windows. For example, if the domain contains computers that are
not running Microsoft Windows XP Professional or Microsoft Windows 2000 client software, or
if it contains Microsoft Windows NT backup domain controllers, the PDC emulator master acts
as a Windows NT PDC. It is also the Domain Master Browser, and it handles password
discrepancies. At any one time, there can be only one domain controller acting as the PDC
emulator master in each domain in the forest.
You can transfer FSMO roles by using the Ntdsutil.exe command-line utility or by using an MMC snap-in
tool. Depending on the FSMO role that you want to transfer, you can use one of the following three
MMC snap-in tools:
Active Directory Schema snap-in
Active Directory Domains and Trusts snap-in
Active Directory Users and Computers snap-in
If a computer no longer exists, the role must be seized. To seize a role, use the Ntdsutil.exe utility.
Register Schmmgmt.dll
1. Click Start, click Run, type mmc in the Open box, and then click OK.
2. On the File, menu click Add/Remove Snap-in.
3. Click Add.
4. Click Active Directory Schema, click Add, click Close, and then click OK.
5. In the console tree, right-click Active Directory Schema, and then click Change Domain
Controller.
6. Click Specify Name, type the name of the domain controller that will be the new role holder,
and then click OK.
7. In the console tree, right-click Active Directory Schema, and then click Operations Master.
8. Click Change.
9. Click OK to confirm that you want to transfer the role, and then click Close.
1. Click Start, point to Administrative Tools, and then click Active Directory Domains and Trusts.
2. Right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller.
NOTE: You must perform this step if you are not on the domain controller to which you want to
transfer the role. You do not have to perform this step if you are already connected to the
domain controller whose role you want to transfer.
3. Do one of the following:
o In the Enter the name of another domain controller box, type the name of the domain
controller that will be the new role holder, and then click OK.
-or-
o In the Or, select an available domain controller list, click the domain controller that will
be the new role holder, and then click OK.
4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations
Master.
5. Click Change.
6. Click OK to confirm that you want to transfer the role, and then click Close.
Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles
1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Right-click Active Directory Users and Computers, and then click Connect to Domain Controller.
NOTE: You must perform this step if you are not on the domain controller to which you want to
transfer the role. You do not have to perform this step if you are already connected to the
domain controller whose role you want to transfer.
3. Do one of the following:
o In the Enter the name of another domain controller box, type the name of the domain
controller that will be the new role holder, and then click OK.
-or-
o In the Or, select an available domain controller list, click the domain controller that will
be the new role holder, and then click OK.
4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and
then click Operations Master.
5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or Infrastructure), and
then click Change.
6. Click OK to confirm that you want to transfer the role, and then click Close.
7. Moving the FSMO roles while both the original FSMO role holder and the future
FSMO role holder are online and operational is called Transferring, and is
described in this article.
8. The transfer of an FSMO role is the suggested form of moving a FSMO role
between domain controllers and can be initiated by the administrator or by
demoting a domain controller. However, the transfer process is not initiated
automatically by the operating system, for example a server in a shut-down state.
FSMO roles are not automatically relocated during the shutdown process - this
must be considered when shutting down a domain controller that has an FSMO role
for maintenance, for example.
10. However, when the original FSMO role holder went offline or became non
operational for a long period of time, the administrator might consider moving the
FSMO role from the original, non-operational holder, to a different DC. The
process of moving the FSMO role from a non-operational role holder to a different
DC is called Seizing, and is described in the
11. However, when the original FSMO role holder went offline or became non
operational for a long period of time, the administrator might consider moving the
FSMO role from the original, non-operational holder, to a different DC. The
process of moving the FSMO role from a non-operational role holder to a different
DC is called Seizing, and is described in this article.
12. If a DC holding a FSMO role fails, the best thing to do is to try and get the server
online again. Since none of the FSMO roles are immediately critical (well, almost
none, the loss of the PDC Emulator FSMO role might become a problem unless you
fix it in a reasonable amount of time), so it is not a problem to them to be
unavailable for hours or even days.
13. If a DC becomes unreliable, try to get it back on line, and transfer the FSMO roles
to a reliable computer. Administrators should use extreme caution in seizing FSMO
roles. This operation, in most cases, should be performed only if the original FSMO
role owner will not be brought back into the environment. Only seize a FSMO role if
absolutely necessary when the original role holder is not connected to the network.
All objects inside a common directory database is known as domain. Each domain stores
information only about the objects that belong to that domain. A tree consists of a single domain
or multiple domains in a contiguous namespace. A forest is a collection of Trees and represents
the outermost boundary within which users, computers, groups, and other objects exist. The
forest is the security boundary for Active Directory.
The Active Directory framework that holds the objects can be viewed at a number of levels. At
the top of the structure is the forest
A forest is a collection of multiple trees that share a common global catalog, directory schema,
logical structure, and directory configuration. The forest, tree, and domain are the logical parts in
an Active Directory network.
The Active Directory forest contains one or more transitive, trust-linked trees. A tree is a
collection of one or more domains and domain trees in a contiguous namespace, again linked in a
transitive trust hierarchy. Domains are identified by their DNS name structure, the namespace.
Trust
To allow users in one domain to access resources in another, Active Directory uses trusts.[15]
Trusts inside a forest are automatically created when domains are created. The forest sets the
default boundaries of trust, not the domain, and implicit, transitive trust is automatic for all
domains within a forest. As well as two-way transitive trust, AD trusts can be a shortcut (joins
two domains in different trees, transitive, one- or two-way), forest (transitive, one- or two-way),
realm (transitive or nontransitive, one- or two-way), or external (nontransitive, one- or two-way)
in order to connect to other forests or non-AD domains.[16]
One-way trust – One domain allows access to users on another domain, but the other domain
does not allow access to users on the first domain.
Two-way trust – Two domains allows access to users on both domains.
Trusting domain – The domain that allows access to users from a trusted domain.
Trusted domain – The domain that is trusted; whose users have access to the trusting domain.
Transitive trust – A trust that can extend beyond two domains to other trusted domains in the
tree.
Intransitive trust – A one way trust that does not extend beyond two domains.
Explicit trust – A trust that an admin creates. It is not transitive and is one way only.
Cross-link trust – An explicit trust between domains in different trees or in the same tree when
a descendant/ancestor (child/parent) relationship does not exist between the two domains.
A stub zone is a read-only copy of a zone, which obtains its resource records from other name
servers. It contains copies of only three types of resource records:
These resource records are necessary to identify the authoritative DNS server for the zone. A
stub zone is used to streamline name resolution, especially in a split namespace scenario.
A DNS server that is hosting a stub zone is configured with the IP address of the authoritative
server from which it loads. DNS servers can use stub zones for both iterative and recursive
queries. When a DNS server hosting a stub zone receives a recursive query for a computer name
in the zone to which the stub zone refers, the DNS server uses the IP address to query the
authoritative server, or, if the query is iterative, returns a referral to the DNS servers listed in the
stub zone. A stub zone reduces the amount of DNS traffic on the network and makes DNS more
efficient especially over slow WAN links.
A DNS zone is a portion of the global Domain Name System (DNS) namespace for which administrative
responsibility has been delegated.
Definition
The DNS namespace is defined by RFC 1034, "Domain Names - Concepts and Facilities" and
RFC 1035, "Domain Names - Implementation and Specification". It is divided in hierarchical
tree-like fashion into cascading lower-level domains that are ordered as a reverse-prioritized
concatenation of names, each level separated by a full stop and descending in priority written
from right to left, e.g., sub-b.sub-a.example.com.
Administratively, each level or node in the hierarchy represents a potential boundary of authority
for management of the name space. The authority over every level in every branch of the name
space tree is delegated to a legal entity or organization, such as a top-level country's domain
registry, or a company or individual registered to use a given sub-domain in the system. These
administrative spaces or portions of the domain name system are termed "DNS zones". DNS
zones may consist of only one domain, or may comprise many domains and sub-domains,
depending on the administrative authority delegated to the manager. Each manager may further
delegate authority over a sub-space of its delegation to other parties.
The most tangible expression of a DNS zone are the database elements that are used to
technically administer a zone in a DNS management software system. Traditionally, each zone
was stored in a separate database file, the zone file, containing specification for host addressing,
name aliasing, electronic mail routing, backup server systems, geographic location,
administrative contacts, and many other pieces of information (see list of DNS record types),
with an extensible design that has scaled well with the growth of the Internet.
The term arose as the opposite of reverse zones, used for the reverse process, namely the process
of finding the DNS name associated with an IP address, for example. Such reverse zones are
maintained in the Internet Address and Routing Parameter Area (domain arpa).
Another common use of the term forward zone refers to a specific configuration of DNS name
servers, particularly caching name servers, in which resolution of a domain name is forwarded to
another name server that is authoritative for the domain in question, rather than being answered
from the established cache memory.
If the last nameserver queried did not contain authoritative data for the target of the CNAME, it
would have issued the resolver with yet another referral, this time to the "text.wikimedia.org."
zone. However, since the resolver had previously determined the authoritative nameservers for
the "org." zone, it would not need to begin the resolution process from scratch but instead start at
the "org." zone, thus avoiding a query to the root nameservers again.
Note that there is no requirement that resolving should involve any referrals at all. Looking up
"en.wikipedia.org." on the ICANN root nameservers will always result in referrals, but if an
alternative DNS root is used which is set up to contain a record for "en.wikipedia.org.", then the
record will be returned on the first query.
The port numbers are divided into three ranges: the well-known ports, the registered ports, and
the dynamic or private ports. The well-known ports are those from 0 through 1023. Examples
include:
21: FTP
23: Telnet
53: Domain Name System
80: World Wide Web HTTP
119: Network News Transfer Protocol
443: HTTP over Transport Layer Security/Secure Sockets Layer
445: microsoft-ds, Server Message Block over TCP
3389: Microsoft Server
NS Zones Overview
A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server
has authority, or is
authoritative. A zone is a portion of a namespace . it is not a domain. A domain is a branch of the
DNS namespace. A
DNS zone can contain one or more contiguous domains . A DNS server can be authoritative for
multiple DNS zones. A
noncontiguous namespace cannot be a DNS zone.
A zone contains the resource records for all of the names within the particular zone. Zone files
are used if DNS
data is not integrated with Active Directory. The zone files contain the DNS database resource
records which define the
zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory.
The different types of zones used in Windows Server 2003 DNS are listed below:
Primary zone
Secondary zone
A primary zone is the only zone type that can be edited or updated because the data in the zone is
the
original source of the data for all domains in the zone. Updates made to the primary zone are
made by the DNS server
that is authoritative for the specific primary zone. You can also back up data from a primary zone
to a secondary
zone.
A secondary zone is a read-only copy of the zone that was copied from the master server during
zone transfer.
In fact, a secondary zone can only be updated through zone transfer.
An Active Directory-integrated zone is a zone that stores its data in Active Directory. DNS zone
files are
not needed. This type of zone is an authoritative primary zone. Zone data of an Active Directory-
integrated zone is
replicated during the Active Directory replication process. Active Directory-integrated zones
also enjoy the security
features of Active Directory.
A reverse lookup zone is an authoritative DNS zone. These zones are mainly used to resolve
IP addresses to
resource names on the network. A reverse lookup zone can be either of the following zones:
Primary zone
Secondary zone
Active Directory-integrated zone
A stub zone is a new Windows Server 2003 feature. Stub zones only contain those resource
records necessary to
identify the authoritative DNS servers for the master zone. Stub zones therefore contain only a
copy of a zone, and are
used to resolve recursive queries and iterative queries:
Iterative queries: The DNS server provides the best answer it can. This can be:
o The resolved name
o A referral to a different DNS server
Recursive queries: The DNS server has to reply with the requested information, or with
an error. The DNS
server cannot provide a referral to a different DNS server
Zone delegation occurs when you assign authority over portions of the DNS namespace to
subdomains of the DNS
namespace. You should delegate a zone under the following circumstances:
Full transfer: When you configure a secondary DNS server for a zone, and start the
secondary DNS server, the
secondary DNS server requests a full copy of the zone from the primary DNS server. A
full transfer is performed of all
the zone information. Full zone transfers tend to be resource intensive. This disadvantage
of full transfers has led to
the development of incremental zone transfers.
Incremental zone transfer: With an incremental zone transfer, only those resource records
that have since
changed in a zone are transferred to the secondary DNS servers. During zone transfer, the
DNS databases on the primary
DNS server and the secondary DNS server are compared to determine whether there are
differences in the DNS data. If the
DNS data of the primary and secondary DNS servers are the same, zone transfer does not
take place. If the DNS data of
the two servers are different, transfer of the delta resource records starts. This occurs
when the serial number on the
primary DNS server database is higher than that of secondary DNS server.s serial
number. For incremental zone transfer
to occur, the primary DNS server has to record incremental changes to its DNS database.
Incremental zone transfers
require less bandwidth than full zone transfers.
Active Directory transfers: These zone transfers occur when Active Directory-integrated
zones are replicated
to the domain controllers in a domain. Replication occurs through Active Directory
replication.
DNS Notify is a mechanism that enables a primary DNS server to inform secondary DNS
servers when its
database has been updated. DNS Notify informs the secondary DNS servers when they
need to initiate a zone transfer so
that the updates of the primary DNS server can be replicated to them. When a secondary
DNS server receives the
notification from the primary DNS server, it can start an incremental zone transfer or a
full zone transfer to pull
zone changes from the primary DNS servers.
A few of the commonly used resource records (RR) and their associated functions are described
in the Table.
Resource Records
Name Function
Type
Contains the IP address of a specific host, and m
A Host record
addresses.
AAAA IPv6 address record Ties a FQDN to an IPv6 128-bit address.
Associates a DNS domain name to a server subty
AFSDB Andrews files system
volume or an authenticated name server using DC
Asynchronous Transfer Mode Associates a DNS domain name to the ATM ad
ATMA
address atm_address field.
CNAME Canonical Name / Alias name Ties an alias to its associated domain name.
HINFO Host info record Indicates the CPU and OS type for a particular
ISDN ISDN info record Ties a FQDN to an associated ISDN telephone nu
While there are various resource records that contain different information or data, there are a
few required fields
that each particular resource record has to contain:
Delegation records and glue records can also be added to a zone. These records are used to
delegate a subdomain into
a separate zone.
Delegation records: These are Name Space (NS) resource records in a parent zone. The
delegation record
specifies the parent zone as being authoritative for the delegated zones.
Glue records: These are A type resource records for the DNS server who is authoritative
for delegated
zone.
The more important resource records are discussed now. This includes the following:
Start of Authority (SOA), Name Server (NS), Host (A), Alias (CNAME), Mail exchanger
(MX), Pointer (PTR), Service
location (SRV)
The fields located within the SOA record are listed below:
Source host; the host for who the DNS database file is maintained
Contact e-mail; e-mail address for the individual who is responsible for the database file.
Serial number; the version number of the database.
Refresh time; the time that a secondary DNS server waits, while determining whether
database updates have
been made, that have to be replicated via zone transfer.
Retry time; the time for which a secondary DNS server waits before attempting a failed
zone transfer
again.
Expiration time; the time for which a secondary DNS server will continue to attempt to
download zone
information. Old zone information is discarded when this limit is reached.
Time to live; the time that the particular DNS server can cache resource records from the
DNS database
file.
The methods which are used to add host (A) resource records to zones are:
Priority
Mail server
The mail exchanger (MX) resource record enables your DNS server to work with e-mail
addresses where no specific mail
server is defined. A DNS domain can have multiple MX records. MX resource records can
therefore also be used to provide
failover to different mail servers when the primary server specified is unavailable. In this case, a
server preference
value is added to indicate the priority of a server in the list. Lower server preference values
specify higher
preference.
You can add PTR resource records to zones through the following methods:
The fields of the service (SRV) resource record are explained below:
Service name
The protocol used
The domain name associated with the SRV records.
The port number for the particular service
The Time to Live value
The class
The priority and weight.
The target specifying the FQDN of the particular host supporting the service
Domain Name file: When new A type resource records are added to the domain, they are
stored in this file.
When a zone is created, the Domain Name file contains the following:
o A SOA resource record for the domain
o A NS resource record that indicates the name of the DNS server that was created.
Reverse Lookup file: This database file contains information on a reverse lookup zone.
Cache file: This file contains a listing of the names and addresses of root name servers
that are needed for
resolving names which are external to the authoritative domains.
Boot file: This file controls the startup behavior of the DNS server. The boot file supports
the commands
listed below:
o Directory command; this command defines the location of the other files specified
in the Boot file.
o Primary command; defines the domain for which this particular DNS server has
authority.
o Secondary; specifies a domain as being a secondary domain.
o Cache command; this command defines the list of root hints used for contacting
DNS servers for the root domain
When determining how to break up the DNS zones, a few considerations you should include are
listed below:
DNS traffic patterns: You can use the System Monitor tool to examine DNS
performance counters, and to obtain DNS
server statistics.
Network link speed: The types of network links that exist between your DNS servers
should be determined when you
plan the zones for your environment.
Whether full DNS servers or caching-only DNS servers are being used also affects how
you break up DNS zones
The main zone types used in Windows Server 2003 DNS environments are primary zones and
Active Directory-integrated
zones. The question on whether to implement primary zones or Active Directory-integrated
zones; would be determined by
the DNS design requirements of your environment.
Both primary zones and secondary zones are standard DNS zones that use zone files. The main
difference between
primary zones and secondary zones is that primary zones can be updated. Secondary zones
contain read-only copies of
zone data. A secondary DNS zone can only be updated through DNS zone transfer. Secondary
DNS zones are usually
implemented to provide fault tolerance for your DNS server environment.
A few advantages that Active Directory-integrated zone implementations have oer standard
primary zone
implementations are:
Active Directory replication is faster, which means that the time needed to transfer zone
data between zones is far
less.
The Active Directory replication topology is used for Active Directory replication, and
for Active
Directory-integrated zone replication. There is no longer a need for DNS replication
when DNS and Active Directory are
integrated.
Active Directory-integrated zones can enjoy the security features of Active Directory.
The need to manage your Active Directory domains and DNS namespaces as separate
entities is eliminated. This in
turn reduces administrative overhead.
When DNS and Active Directory are integrated; the Active Directory-integrated zones
are replicated, and stored on
any new domain controllers automatically. Synchronization takes place automatically
when new domain controllers are
deployed.
The mechanism that DNS utilizes to forward a query that one DNS server cannot resolve, to
another DNS server is
called DNS forwarding. DNS forwarders are the DNS servers used to forward DNS queries for
different DNS
namespace to those DNS servers who can answer the query. A DNS server is configured as a
DNS forwarder when you
configure the other DNS servers to direct any unresolved queries to a specific DNS server.
Creating DNS forwarders can
improve name resolution efficiency.
Windows Server 2003 DNS introduces a new feature, called conditional forwarding. With
conditional forwarding,
you create conditional forwarders within your environment that will forward DNS queries based
on the specific
domain names being requested in the query. This differs from DNS forwarders where the
standard DNS resolution path to
the root was used to resolve the query. A conditional forwarder can only forward queries for
domains that are defined
in the particular conditional forwarders list. The query is passed to the default DNS forwarder if
there are no entries
in the forwarders list for the specific domain queried.
When conditional forwarders are configured, the process to resolve domain names is illustrated
below:
A few considerations for configuring forwarders for your DNS environment are:
You should only implement the DNS forwarders that are necessary for your environment.
You should refrain from
creating loads of forwarders for your internal DNS servers.
You should avoid chaining your DNS servers together in a forwarding configuration.
To avoid the DNS forwarder turning into a bottleneck, do not configure one external
DNS forwarder for all your
internal DNS servers.
1. Click Start, Administrative Tools, and the select DNS to open the DNS console.
2. In the console tree, proceed to expand your DNS server node, and then expand the
Forward Lookup Zones folder.
3. Locate and right-click the zone which you want to configure and then select Properties
from the shortcut menu.
4. When the Zone Properties dialog box opens, click the WINS tab.
5. Enable the Use WINS Forward Lookup checkbox.
6. Type the WINS server IP address. Click Add, and then click OK.
7. On the General tab, select Yes in the Allow Dynamic Updates list box.
8. Click OK.
Check
Control Panel --> Administrative Tools --> Services --> IIS Admin
For reinstalling