Professional Documents
Culture Documents
Features in AD DS
A set of rules, the schema, that defines the classes of objects and
attributes that are contained in the directory, the constraints and limits
on instances of these objects, and the format of their names.
A query and index mechanism, so that objects and their properties can
be published and found by network users or applications.
that are running on the same Windows Server 2008 R2 server as ADWS.
ADWS is installed automatically when you add the AD DS or AD LDS server
roles to your Windows Server 2008 R2 server.
Authentication Mechanism Assurance
Authentication Mechanism Assurance packages information about the type of
logon method (smart card or user name/password) that is used to
authenticate domain users inside each users Kerberos token. When this
feature is enabled in a network environment that has deployed a federated
identity management infrastructure, such as Active Directory Federation
Services (AD FS), the information in the token can then be extracted
whenever a user attempts to access any claims-aware application that has
been developed to determine authorization based on a users logon method.
Authentication Mechanism Assurance requires the Windows Server 2008 R2
domain functional level.
To manage Active Directory objects by using the newest GUI tool, with
improved options for viewing and managing Active Directory data,
click Active Directory Administrative Center.
To manage Active Directory sites and site links, click Active Directory
Sites and Services.
The partial copies of all domain objects included in the global catalog are those most
commonly used in user search operations. These attributes are marked for inclusion in the
global catalog as part of their schema definition. Storing the most commonly searched upon
attributes of all domain objects in the global catalog provides users with efficient searches
without affecting network performance with unnecessary referrals to domain controllers.
You can manually add or remove other object attributes to the global catalog by using the
Active Directory Schema snap-in. For more information, see Customizing the global catalog.
A global catalog is created automatically on the initial domain controller in the forest. You
can add global catalog functionality to other domain controllers or change the default
location of the global catalog to another domain controller. For more information, see Enable
or disable a global catalog.
A global catalog performs the following directory roles:
Finds objects
A global catalog enables user searches for directory information throughout all
domains in a forest, regardless of where the data is stored. Searches within a forest
are performed with maximum speed and minimum network traffic.
When you search for people or printers from the Start menu or choose the Entire
Directory option within a query, you are searching a global catalog. Once you enter
your search request, it is routed to the default global catalog port 3268 and sent to a
global catalog for resolution. For more information, see Finding directory
information and "Finding information in Active Directory" at the Microsoft Windows
Resource Kits Web site.
For more information about universal groups, see Group scope. For more information
about universal groups and replication, see Global catalog replication and Global
catalogs and sites.
Note
o
When there is only one domain in a forest, it is not necessary for users to
obtain universal group memberships from a global catalog when logging on.
This is because Active Directory can detect that there are no other domains in
the forest and will prevent a query to the global catalog for this information.
Units of Policy
Units of Replication
Units of Trust
Each domain has a domain administrators group. Domain administrators have full control
over every object in the domain. These administrative rights are valid within the domain
only and do not propagate to other domains.
Organizational Units
The organizational unit is a particularly useful type of directory object contained within
domains. Each organizational unit is an Active Directory container within a domain into
which users, groups, computers, and other organizational units of the domain can be placed.
An organizational unit cannot contain objects from other domains.
An organizational unit is the smallest scope or unit to which Group Policy settings can be
assigned or to which administrative authority can be delegated. A hierarchy of
organizational units can be extended as necessary to model the hierarchy of an organization
within a domain. The administrative model of the organizational unit can be scaled to any
size. For more information about Group Policy, see How Core Group Policy Works.
Administrative authority can be delegated for individual organizational units or for multiple
organizational units. Organizational units can be nested to create a hierarchy within a
domain and form logical administrative units for users, groups, and resource objects, such as
printers, computers, applications, and file shares. The organizational unit hierarchy within a
domain is independent of the structure of other domains: Each domain can implement its
own hierarchy. Likewise, domains that are managed by the central authority can implement
similar organizational unit hierarchies. The structure is flexible, which allows organizations to
create an environment that mirrors the administrative model, whether it is centralized or
decentralized.
Objects
Active Directory objects represent the physical entities that make up a network. An object
stores an instance of a class. A class is defined in the Active Directory schema as a specific
set of mandatory and optional attributes that is, an attribute can be present in an object
in Active Directory only when that attribute is permitted by the objects class. Classes also
contain rules that determine which classes of objects can be superior to (parents of) a
particular object of the class. Each attribute is also defined in the directory schema. The
attribute definitions determine the syntax for the values the attribute can have.
Creation of an Active Directory object requires specification of values for the attributes of the
object in its particular class, consistent with the rules of the directory schema. For example,
creating a user object requires specification of alphanumeric values for the users first and
last names and the logon identifier, which are mandatory according to the directory schema.
Other non-mandatory values can also be specified, such as telephone number and address.
Applications that create or modify objects in Active Directory use the directory schema to
determine what attributes the object must and might have, and what those attributes can
look like in terms of data structures and syntax constraints. The directory schema is
maintained forest-wide so that all objects created in the directory conform to the same
values.
Objects are either container objects or leaf objects. A container object stores other objects,
and as such occupies a specific level in a subtree hierarchy. An object class is a container if
at least one other class specifies it as a possible superior, so any object class defined in the
schema can become a container. A leaf object does not store other objects, so it occupies
the endpoint of a subtree. For more information about Active Directory Objects, see How
Domains and Forests Work and How the Active Directory Schema Works.
You cannot define different account policies for different organizational units in the same
domain. Policy settings are stored as Group Policy objects (GPOs) in Active Directory. A GPO
establishes how domain resources can be accessed, configured, and used. The policies
associated with a GPO are applied only within the domain and not across domains. A GPO
can be associated with one or more Active Directory containers, such as a site, domain, or
organizational unit.
Account policies and Public Key policies have domain-wide scope and are set at the domain
GPO level. All other policies can be specified at the level of the organizational unit. Some
policies that can be applied only at the domain container level include:
Password policy. Determines the rules, such as password length, that must be met
when a user sets a password.
Account lockout policy. Defines rules for intruder detection and account deactivation.
Because organizational units provide multiple levels of administrative authority, you can use
them to systematically apply Group Policy settings and delegate administrative control.
Delegation simplifies the task of managing these objects and enables you to structure Active
Directory to fit the requirements of your organization. Using delegated authority in
conjunction with GPOs and group memberships allows one or more administrators to be
assigned rights and permissions to manage objects in an entire domain or in one or more
organizational units within the domain.
For more information about Group Policy, see How Core Group Policy Works.
All domain controllers in the forest are also updated with changes to forest-wide data. For
more information about replication at the Forest level, see Forests as Units of Replication
later in this section Domain-wide replication relies on three components of the Active
Directory physical structure to be in place for optimal performance, these include:
Domain Controllers
The physical domain controller contains the domain partition data that is replicated to other
domain controllers in that same domain. A domain partition stores only the information
about objects located in that domain. All domain controllers in a domain receive changes
and replicate those changes to the domain partition stored on all other domain controllers in
the domain. In this way, all domain controllers are peers in the domain and manage
replication as a unit.
Domain controllers also have two non-domain directory partitions that store forest-wide
data, which includes the directory schema and configuration data. Optionally, domain
controllers, application partitions can be configured to be located on designated domain
controllers anywhere in a forest. Unlike the schema and configuration partitions, application
partitions are not located on every domain controller in a forest. For more information about
the replication of forest-wide data, see Forests as Units of Replication later in this section.
Partitioning Active Directory data into three physical partitions on each domain controller
helps to control replication so that data is replicated only to where it is needed. In this way,
Active Directory can scale globally over a network that has limited available bandwidth.
Sites
Within the scope of a forest, sites are a representation of the physical network topology. This
includes physical subnet and site definitions. Replication of updates to domain data occurs
between multiple domain controllers to keep replicas synchronized. Multiple domains are
common in large organizations, as are multiple sites in disparate locations. In addition,
domain controllers for the same domain are commonly placed in more than one site.
Therefore, replication must often occur both within sites and between sites to keep domain
and forest data consistent among domain controllers that store the same directory
partitions. Replication within sites generally occurs at typical LAN speeds between domain
controllers that are on the same network segment. Replication between sites usually occurs
over WAN links that might be costly in terms of bandwidth. To accommodate the differences
in distance and cost of replication within a site and between sites, the intrasite replication
topology is used to optimize speed, and the intersite replication topology is used to minimize
cost based on a configurable replication schedule.
The Knowledge Consistency Checker (KCC) is a distributed application that runs on every
domain controller and is responsible for creating the connections between domain
controllers that collectively form the replication topology. The KCC uses Active Directory data
to determine where to create connections between source domain controllers and
destination domain controllers.
Intersite replication is optimized for bandwidth efficiency, and directory updates between
sites occur automatically based on a configurable schedule.
There are three operations master roles per domain. These include the Relative Identifier
(RID) Master, Primary Domain Controller (PDC) emulator, and Infrastructure Master. These
three roles must be unique in each domain, so each domain can have only one RID master,
one PDC emulator, and one Infrastructure Master. For information about forest-wide roles,
see Forest-Wide Operations Master Roles later in this section. For more information about
replication, see How Active Directory Replication Topology Works.
Authentication is not limited to users. Computers and services are also authenticated when
they make network connections to other servers. For example, domain joined computers
connect Active Directory in their domain for policy information during startup. Computers
and services also prove their identity to clients that request mutual authentication. Mutual
authentication prevents an intruder from adding another computer as an imposter between
the client and the real network server. The Kerberos version 5 authentication protocol is a
technology for single sign-on to network resources. Kerberos V5 protocol is used to provide
single sign-on to network services within a domain, and to services residing in trusted
domains. The Kerberos V5 protocol verifies both the identity of the user and of the network
services, providing mutual authentication.
Authentication and authorization services in one domain can be extended to accounts that
are located in trusted domains. This can be done by using trusts. Trusts are logical
relationships established between domains to allow pass-through authentication in which a
trusting domain honors the logon authentications of a trusted domain. Consequently, trust
relationships inherently allow domain-specific authentication and authorization services to
be extended, thereby enabling single sign-on access control capabilities throughout a forest.
Because the domain trust relationships between all domains in the forest are bidirectional by
default, authentication in one domain is sufficient for referral or pass-through authentication
to resources in other domains in the forest.
A domain is the smallest container within Active Directory that can be used in a trust
relationship. All domains within a forest are connected by Kerberos-based trusts. Kerberosbased trusts are two-way and transitive in nature. Trusts act as authentication pipelines that
must be present in order for users in one domain to access resources in another domain. All
authentication requests made between domains located inside or outside of a forest must
occur over trusts. Trust relationships within a forest are created as implicit two-way
transitive trusts.
Note
Within a forest, trust relationships are automatically created between the forest root domain
and any tree root domains on the one hand, and all child domains that are subordinate to
the forest root domain on the other. Because trust relationships are two-way and transitive
by default, users and computers can be authenticated between any domain containers in
the forest, as shown in the following figure.
Domains as Units of Trust and the Authentication Paths they Provide
In accordance with DNS naming standards, Active Directory domains within a single forest
are created in an inverted tree structure, with the forest root domain at the top. This tree
structure requires that trusts exist between domains to facilitate security of
communications. Adding a domain tree to a forest requires specification of the forest root
domain, which results in the establishment of a trust relationship between the root domain
of the new tree and the forest root domain. For more information about trusts and root
domains, see Forests as Collections of Domain Containers that Trust Each Other later in
this section.
Units of Replication
Security Boundaries
Units of Delegation
All domain containers in a forest share a common global catalog, directory schema, and
directory configuration, as well as automatic two-way transitive trust relationships. Because
all of the domain containers are inherently joined through two-way transitive trusts, all
authentication requests made from any domain in the forest to any other domain in the
same forest will be granted. In this way, all security principals that are located in domain
containers within a forest inherently trust each other.
Forests can be used to segregate domain containers into one or more unique DNS
namespace hierarchies known as domain trees. Although each domain tree consists of a
unique namespace the schema and configuration data for the forest are shared throughout
all the domain containers in a forest irrespective of namespace. Each domain container in a
forest must adhere to DNS naming schemes and all domains are organized in a root and
subordinate domain hierarchy. Root domains, such as forest root and tree root domains,
define the DNS namespace for their subordinate domains. Although a forest can consist of
multiple domain trees, it represents one organization. However, an organization can have
multiple forests. For more information about multiple forests, see Forests as Units of
Delegation later in this section. As shown in the following figure, the namespace for each
root domain must be unique.
Domain Containers, Root Domains and DNS Namespaces Within a Forest
Multiple domain trees can belong to a single forest and do not form a contiguous
namespace; that is, they have noncontiguous DNS domain names. Although the roots of the
separate trees have names that are not contiguous with each other, the trees share a single
overall namespace because names of objects can still be resolved by the same Active
Directory instance. A forest exists as a set of cross-reference objects and trust relationships
that are known to the member trees. Transitive trusts at the root domain of each namespace
provide mutual access to resources.
The domain hierarchy in a forest determines the transitive trust links that connect each
domain. Each domain has a direct trust link with its parent and each of its children. If there
are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a
trust perspective, all other tree roots are children. That means authentication traffic between
any two domains in different trees must pass through the forest root.
The following table describes each of the three forest-wide partitions in more detail.
Forest-Wide Directory Partitions
Partition
Description
Schema
The schema partition contains the forest-wide schema. Each forest has one schema so that the d
all object and attribute data that can be stored in the directory. Active Directory domain control
computer accounts, groups, domains, organization units, and security policies. Administrators a
attributes or by adding new attributes for existing objects. Schema objects are protected by acce
schema partition is replicated to each domain controller in the forest.
Configuratio
n
The configuration partition describes the topology of the forest as well as other forest, domain a
domains, trees, and forests and the locations of the domain controllers and global catalogs. The
Application
Applications and services can use application directory partitions to store application-specific d
where information needs to be replicated but not necessarily on a global scale. Application dire
Application directory partitions are usually created by the applications that will use them to sto
that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different d
controller or any set of domain controllers anywhere in the forest. This differs from a domain d
domain.
Only domain controllers running Windows Server 2003 or higher can host a replica of an applic
and managed by the administrator.
All forest replication is Multi-Master with the exception of the three domain-wide and two
forest-wide operations master roles. Forest-wide replication requires domain controllers and
three other components of the Active Directory physical structure to be in place for optimal
performance. These components are forest-wide operations master roles, sites, and global
catalogs.
Sites
Sites in Active Directory represent the physical structure, or topology, of the network. Within
the scope of a forest, sites are a representation of the physical network topology, including
physical subnet and site definitions. When you establish sites, domain controllers within a
single site communicate frequently. This communication minimizes the latency within the
site; that is, the time required for a change that is made on one domain controller to be
replicated to other domain controllers. You create sites to optimize use of the bandwidth
between domain controllers in different locations. For more information about sites, see
How Active Directory Replication Topology Works.
Global Catalogs
The global catalog stores a full copy of all Active Directory objects in the directory for its host
domain and a partial copy of all objects for all other domains in the forest. Users in a forest
do not need to be aware of directory structure because all users see a single directory
through the global catalog. Applications and clients can query the global catalog to locate
any object in a forest. The global catalog is hosted on one or more domain controllers in the
forest. It contains a partial replica of every domain directory partition in the forest. These
partial replicas include replicas of every object in the forest, including the attributes most
frequently used in search operations and the attributes required to locate a full replica of the
object. A global catalog is created automatically on the first domain controller in the forest.
Optionally, other domain controllers can be configured to serve as global catalogs.
A global catalog serves the following roles:
Enables user searches for directory information about objects throughout all domains
in the forest
Resolves user principal names (UPNs) during authentication, when the authenticating
domain controller does not have information about the account
For more information about global catalogs and their roles, see How the Global Catalog
Works.
no administrators from outside a forest can control access to information inside the forest
unless first given permission to do so by the administrators within the forest.
Enterprise Administrators Outside of a Forest Can Administer Only Within Their
Own Forest
A forest is the only component of the Active Directory logical structure that is a security
boundary. By contrast, a domain is not a security boundary because it is not possible for
administrators from one domain to prevent a malicious administrator from another domain
within the forest from accessing data in their domain. A domain is, however, the
administrative boundary for managing objects, such as users, groups, and computers. In
addition, each domain has its own individual security policies and trust relationships with
other domains.
If your organization requires strict isolation of authority between domains, you must deploy
multiple forests with manually created trusts between domains in the different forests.
Because each forest is administered separately, adding additional forests to your
organization increases the management overhead of the organization. The number of forests
that you need to deploy is based on the autonomy and isolation requirements of each group
within your organization. Reasons to create multiple forests in your organization include:
To secure data within each forest. Sensitive data can be protected so that only users
within that forest can access it.
Because the forest is a security boundary, each forest does not trust or allow access from
any other forest by default. However, in Windows Server 2003 and higher Active Directory,
transitive trust relationships can be manually established between forests to establish crossforest access to resources, so that users in one forest can access resources in another forest.
Forest trusts help you to manage a segmented Active Directory infrastructure within your
organization by providing support for accessing resources and other objects across multiple
forests. By using forest trusts, you can link two different Windows Server 2003 or higher
forests to form a one-way or two-way transitive trust relationship. A forest trust allows
administrators to federate two Active Directory forests with a single trust relationship to
provide a seamless authentication and authorization experience across the forests.
When two forests are connected by a forest trust, authentication requests made using the
Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources
in both forests. Trust security settings and firewalls can be configured between domains in
different forests that are joined by trust relationships to limit cross-forest connectivity to
specific users or applications. For more information about trust security settings, see
Security Considerations for Trusts.
A forest trust can be created only between a forest root domain in one Windows Server 2003
or higher forest and a forest root domain in another Windows Server 2003 or higher forest.
Forest trusts can be created between two forests only and cannot be implicitly extended to a
third forest. This means that if a forest trust is created between Forest 1 and Forest 2, and
another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an
implicit trust with Forest 3. The following figure shows two separate forest trust relationships
between three forests in a single organization.
Two Forest Trusts Between Three Windows Server 2003 Forests
Organizational units
A particularly useful type of directory object contained within domains is the organizational
unit. Organizational units are Active Directory containers into which you can place users,
groups, computers, and other organizational units. An organizational unit cannot contain
objects from other domains.
An organizational unit is the smallest scope or unit to which you can assign Group Policy
settings or delegate administrative authority. Using organizational units, you can create
containers within a domain that represent the hierarchical, logical structures within your
organization. You can then manage the configuration and use of accounts and resources
based on your organizational model. For more information about Group Policy settings,
see Group Policy (pre-GPMC).
As shown in the figure, organizational units can contain other organizational units. A
hierarchy of containers can be extended as necessary to model your organization's
hierarchy within a domain. Using organizational units will help you minimize the number of
domains required for your network.
You can use organizational units to create an administrative model that can be scaled to any
size. A user can have administrative authority for all organizational units in a domain or for a
single organizational unit. An administrator of an organizational unit does not need to have
administrative authority for any other organizational units in the domain. For more
information about delegating administrative authority, see Delegating administration.
Fsmo roles
peers. However, some changes are impractical to perform in using multimaster replication,
so, for each of these types of changes, one domain controller, called the operations master,
accepts requests for such changes.
In every forest, there are at least five operations master roles that are assigned to one or
more domain controllers. Forest-wide operations master roles must appear only once in
every forest. Domain-wide operations master roles must appear once in every domain in the
forest.
Note
The operations master roles are sometimes called flexible single master operations
(FSMO) roles.
Schema master
These roles must be unique in the forest. This means that throughout the entire forest there
can be only one schema master and one domain naming master.
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 entire forest.
The domain controller holding the domain naming master role controls the addition or
removal of domains in the forest. There can be only one domain naming master in the entire
forest.
Note
Any domain controller running Windows Server 2003 can hold the role of the domain
naming master. A domain controller running Windows 2000 Server that holds the role
of domain naming master must also be enabled as a global catalog server.
Infrastructure master
These roles must be unique in each domain. This means that each domain in the forest can
have only one RID master, PDC emulator master, and infrastructure master.
RID master
The RID master allocates sequences of relative IDs (RIDs) to each of the various domain
controllers in its domain. At any time, there can be only one domain controller acting as the
RID master in each domain in the forest.
Whenever a domain controller creates a user, group, or computer object, it assigns the
object a unique security ID (SID). The SID consists of a domain SID, which is the same for all
SIDs created in the domain, and a RID, which is unique for each SID created in the domain.
To move an object between domains (using Movetree.exe), you must initiate the move on
the domain controller acting as the RID master of the domain that currently contains the
object.
The PDC emulator master processes password changes from client computers and replicates
these updates to all domain controllers throughout the domain. At any time, there can be
only one domain controller acting as the PDC emulator master in each domain in the forest.
The PDC emulator role is used in the following ways:
To provide consistent password experience for users across sites (can be turned off
with AvoidPdcOnWan registry parameter) - The PDC emulator is used as a reference
DC to double-check incorrect passwords and it also receives new password changes.
When the PDC is reachable, users can use a new password immediately and
consistently across the environment. For more information about AvoidPdcOnWan
see, New Password Change and Conflict Resolution Functionality in
Windows (http://go.microsoft.com/fwlink/?LinkId=202451)
As a preferred point of administration for services (examples are Group Policy and
Distributed File System, DFS) - For more information about DFS see, DFS
Management (http://go.microsoft.com/fwlink/?LinkId=202456). For more information
about DCs and Group Policy see, Specifying a Domain Controller for Editing Group
Policy (http://go.microsoft.com/fwlink/?LinkId=202457).
As a point of contact for applications hard-coded to the PDC (often written for
Windows NT 4.0 and older domains) - The legacy API often used for this is
NetGetDcName. It is strongly suggested to change applications to use the new API to
locate DCs. DsGetDcName by default does not target the PDC, and has more options
that allows you to pick the type of DC needed to perform the operation. For more
information about locating DCs from applications see, DSGetDcName
Function (http://go.microsoft.com/fwlink/?LinkId=202455).
As a default time server for all other DCs in the domain - The time server
configuration of a PDC requires manual consideration and should be reviewed when
you change the owner of the PDC role.
The domain controller configured with the PDC emulator role supports two authentication
protocols:
Infrastructure master
At any time, there can be only one domain controller acting as the infrastructure master in
each domain. The infrastructure master is responsible for updating references from objects
in its domain to objects in other domains. The infrastructure master compares its data with
that of a global catalog. Global catalogs receive regular updates for objects in all domains
through replication, so the global catalog data will always be up to date. If the infrastructure
master finds data that is out of date, it requests the updated data from a global catalog. The
infrastructure master then replicates that updated data to the other domain controllers in
the domain.
Important
Unless there is only one domain controller in the domain, the infrastructure master
role should not be assigned to the domain controller that is hosting the global
catalog. If the infrastructure master and global catalog are on the same domain
controller, the infrastructure master will not function. The infrastructure master will
never find data that is out of date, so it will never replicate any changes to the other
domain controllers in the domain.
In the case where all of the domain controllers in a domain are also hosting the global
catalog, all of the domain controllers will have the current data and it does not matter
which domain controller holds the infrastructure master role.
The infrastructure master is also responsible for updating the group-to-user references
whenever the members of groups are renamed or changed. When you rename or move a
member of a group (and that member resides in a different domain from the group), the
group may temporarily appear not to contain that member. The infrastructure master of the
group's domain is responsible for updating the group so it knows the new name or location
of the member. This prevents the loss of group memberships associated with a user account
when the user account is renamed or moved. The infrastructure master distributes the
update via multimaster replication.
There is no compromise to security during the time between the member rename and the
group update. Only an administrator looking at that particular group membership would
notice the temporary inconsistency.
For information about transferring operations master roles, see Transferring operations
master roles. For information about what to do when an operations master fails,
see Responding to operations master failures.
What Is DHCP?
349 out of 381 rated this helpful - Rate this topic
Every device on a TCP/IP-based network must have a unique unicast IP address to access the
network and its resources. Without DHCP, IP addresses for new computers or computers that
are moved from one subnet to another must be configured manually; IP addresses for
computers that are removed from the network must be manually reclaimed.
With DHCP, this entire process is automated and managed centrally. The DHCP server
maintains a pool of IP addresses and leases an address to any DHCP-enabled client when it
starts up on the network. Because the IP addresses are dynamic (leased) rather than static
(permanently assigned), addresses no longer in use are automatically returned to the pool
for reallocation.
The network administrator establishes DHCP servers that maintain TCP/IP configuration
information and provide address configuration to DHCP-enabled clients in the form of a lease
offer. The DHCP server stores the configuration information in a database that includes:
Reserved IP addresses associated with particular DHCP clients. This allows consistent
assignment of a single IP address to a single DHCP client.
The lease duration, or the length of time for which the IP address can be used before
a lease renewal is required.
Requested DHCP options, which are additional parameters that a DHCP server is
configured to assign to clients. Some examples of DHCP options are Router (default
gateway), DNS Servers, and DNS Domain Name. For a full list of DHCP options,
see DHCP Tools and Options.
Benefits of DHCP
In Windows Server 2008, the DHCP Server service provides the following benefits:
The efficient handling of IP address changes for clients that must be updated
frequently, such as those for portable computers that move to different
locations on a wireless network.
The forwarding of initial DHCP messages by using a DHCP relay agent, which
eliminates the need for a DHCP server on every subnet.
DHCP messages
The following list includes the eight types of messages that can be sent between DHCP
clients and servers.
DHCPDiscover
Broadcast by a DHCP client when it first attempts to connect to the network. The
DHCPDiscover message requests IP address information from a DHCP server.
DHCPOffer
Broadcast by each DHCP server that receives the client DHCPDiscover message and has an
IP address configuration to offer to the client. The DHCPOffer message contains an unleased
IP address and additional TCP/IP configuration information, such as the subnet mask and
default gateway. More than one DHCP server can respond with a DHCPOffer message. The
client accepts the best offer, which, for a Windows DHCP client, is the first DHCPOffer
message that it receives.
DHCPRequest
Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message contains
the IP address from the DHCPOffer that it selected. If the client is renewing or rebinding to a
previous lease, this packet might be unicast directly to the server.
DHCPAck
Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message. At
this time, the server also forwards any options. Upon receipt of the DHCPAck, the client can
use the leased IP address to participate in the TCP/IP network and complete its system
startup. This message is typically broadcast, because the DHCP client does not officially
have an IP address that it can use at this point. If the DHCPAck is in response to a
DHCPInform, then the message is unicast directly to the host that sent the DHCPInform
message.
DHCPNack
Broadcast by a DHCP server to a DHCP client denying the clients DHCPRequest message.
This might occur if the requested address is incorrect because the client moved to a new
subnet or because the DHCP clients lease has expired and cannot be renewed.
DHCPDecline
Broadcast by a DHCP client to a DHCP server, informing the server that the offered IP
address is declined because it appears to be in use by another computer.
DHCPRelease
Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the
remaining lease. This is unicast to the server that provided the lease.
DHCPInform
Sent from a DHCP client to a DHCP server, asking only for additional local configuration
parameters; the client already has a configured IP address. This message type is also used
by DHCP servers running Windows Server 2008 to detect unauthorized DHCP servers.
A DHCP-enabled client obtains a lease for an IP address from a DHCP server. Before the lease
expires, the DHCP client must renew the lease or obtain a new lease. Leases are retained in
the DHCP server database for a period of time after expiration. By default, this grace period
is four hours and cleanup occurs once an hour for a DHCP server running Windows
Server 2008. This protects a clients lease in case the client and server are in different time
zones, the internal clocks of the client and server computers are not synchronized, or the
client is off the network when the lease expires.
If the client is using the APIPA alternate configuration, the client selfconfigures an IP address for its interface.
In both cases, the client begins a new cycle of DHCPDiscover messages in the
background every five minutes, using the same intervals as before (0, 4, 8, 16, and
32 seconds), until it receives a DHCPOffer message from a DHCP server.
3. The client indicates acceptance of the offer by selecting the offered address and
broadcasting a DHCPRequest message in response.
4. The client is assigned the address and the DHCP server broadcasts a DHCPAck
message in response, finalizing the terms of the lease.
When the client receives acknowledgment, it configures its TCP/IP properties by using the
DHCP option information in the reply, and completes its initialization of TCP/IP.
In rare cases, a DHCP server might return a negative acknowledgment to the client. This can
happen if a client requests an address that is not valid or a duplicate. If a client receives a
negative acknowledgment (DHCPNack), the client must begin the entire lease process again.
When the DHCP client and the DHCP server are on the same IP broadcast subnet, the
DHCPDiscover, DHCPOffer, DHCPRequest, and DHCPAck messages are sent to identify clients
by means of IP-level broadcasts sent to the limited broadcast address and the media access
control (MAC) broadcast address.
When the DHCP server and DHCP client are not on the same subnet, either a router or a host
on the DHCP clients subnet must act as a DHCP relay agent to support the forwarding of
DHCP messages between the DHCP client and the DHCP server.
Scopes
A scope must be properly defined and activated before DHCP clients can use the DHCP
server for automatic TCP/IP configuration. A DHCP scope is an administrative collection of IP
addresses and TCP/IP configuration parameters that are available for lease to DHCP clients
of a specific subnet. The network administrator creates a scope for each subnet.
A scope has the following properties:
A unique subnet mask, which determines the network ID for an IP address in the
scope.
Each DHCP scope can have a single continuous range of IP addresses. To use several
address ranges within a single scope, you must first define the entire address range for the
scope, and then set exclusion ranges.
Lease durations
When a scope is created, the lease duration is set to eight days by default. However, there
are situations when the administrator might want to change the lease duration. The
following are examples of adjusting the lease duration due to individual network
consideration:
For example, consider the ratio between connected computers and available IP addresses. If
40 computers share 254 available addresses, the demand for reusing addresses is low. A
long lease time, such as a few months, might be appropriate in such a situation. However, if
230 computers must share the same address pool, demand for available addresses is higher,
and a shorter lease time (for example, a few days), is more appropriate.
Exclusion ranges
When you create a new scope, immediately exclude the addresses of existing statically
configured computers. By using exclusion ranges, you can exclude specific IP address ranges
within a scope so that those addresses are not offered to clients. Assign IP addresses within
exclusion ranges to computers or devices that must have a static IP address, such as
servers, firewalls, or routers.
You can use excluded IP addresses on your network by manually configuring these addresses
at computers that do not use DHCP to obtain an address, or by configuring reservations for
these addresses.
Reservations
You can reserve IP addresses for assignment to specified computers or devices on the
network. Reservations ensure that a specified hardware device on a subnet always receives
the same IP address lease. Use reservations for DHCP-enabled devices that must always
have the same IP address on your network, such as servers that do not support Domain
Name System (DNS) dynamic update.
When the DHCP server is deployed in a network, it allows the users to either exclude a
range of IP addresses from being assigned to the DHCP client computers, or reserve
some particular IP addresses for the mission-critical computers only. The detailed
information about the DHCP exclusion and DHCP reservation is given below:
DHCP Reservation
DHCP reservation is a feature in the DHCP server that allows the DHCP administrators
to reserve one or more IP addresses for particular mission-critical computers only. In
order to configure DHCP reservation, the administrators are required to know the
physical addresses a.k.a. MAC addresses of the target computers for which the
particular IP addresses are to be reserved. Once the MAC addresses are known, the
administrators can then reserve the appropriate IP addresses by mapping them with
the MAC addresses.
For example, if computer A is playing the role of a print server, and has MAC address of
00:A1:FB:12:45:4C and you want that the computer should always get 192.168.0.7 as
its IP address, you can map the MAC address of the computer A with the IP address to
configure reservation.
When an IP address is reserved for a particular computer, the IP address remains in the
DHCP address pool, even if it is the only address available for the assignment and any
other client computer is requesting for the address. The reserved IP address will only be
assigned to the computer whose MAC address is used to map with it. In this example,
as soon as the print server boots up and requests for a dynamic IP address from the
DHCP server, the DHCP server assigns the 192.168.0.7 IP address to the server as
configured.
DHCP Exclusion
DHCP exclusion, on the other hand, is a configuration in the DHCP server using which
you, as a DHCP administrator, exclude a single IP address or a range of IP addresses
from being assigned automatically to the DHCP client computers.
DHCP exclusion range is specified while configuring the DHCP server if you have
assigned a few static IP addresses to the mission-critical computers in order to avoid
latency in the network.
For example, if you have assigned the IP addresses from 192.168.0.2 to 192.168.0.5 to
the DNS server, DHCP server, Active Directory domain controller, and the WDS server
respectively, you must exclude the said IP addresses from the DHCP address pool.
When an IP address or range of IP addresses is excluded from the DHCP server, the
excluded IP addresses are never assigned automatically to the requesting DHCP client
computers whatsoever.
When configuring a DHCP server I have often seen people interchange the
words reservation and exclusion. These are two incredibly different
concepts.
I have seen people interchange the words reservation and exclusion many
times when talking about the configuration of a DHCP server. These two
concepts sound similar at first but they are actually quite different and serve
their own purpose.
An exclusion is an address or range of addresses taken from a DHCP
scope that the DHCP server is not allowed to hand out. For example, if you
have set a DHCP server to exclude the address range 192.168.0.1192.168.0.10 then the only way a computer on your network would get an
address of 192.168.0.4 would be if you assigned it statically on that
machine. This is because DHCP knows NOT to give this range of IP
addresses out.
A reservation is a specific IP addresses that is tied to a certain device
through its MAC address. For example, if we have a workstation on the
network that requires a certain IP address, but we dont want to go through
to trouble of assigning it statically, then we can create a reservation for it.
So if the MAC address of the NIC on the computer is AA-BB-00-FF-CC-AA
and we want it to maintain the IP address of 192.168.0.100 then we would
create a DHCP reservation under that particular scope saying that the IP
address 192.168.0.100 is reserved only for the MAC address AA-BB-00FF-CC-AA.
80/20 Rule
You will probably install more than one DHCP server so that the failure of any individual
server will not prevent DHCP clients from starting. However, DHCP does not provide a way
for DHCP servers to cooperate in ensuring that assigned addresses are unique. Therefore,
you must carefully divide the available address pool among the DHCP servers to prevent
duplicate address assignment.
For balancing DHCP server usage, use the 80/20 rule to divide scope addresses between
DHCP servers. Figure 4.11 is an example of the 80/20 rule.
Combining the values of the M and O flags can yield the following:
Both M and O Flags are Set to 0. This combination corresponds to a network without a
DHCPv6 infrastructure. Hosts use router advertisements for non-link-local addresses and other
methods (such as manual configuration) to configure other settings.
Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and other configuration
settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning stateful
addresses to IPv6 hosts.
The M Flag is Set to 0 and the O Flag is Set to 1. DHCPv6 is not used to assign
addresses, only to assign other configuration settings. Neighboring routers are configured to advertise
non-link-local address prefixes from which IPv6 hosts derive stateless addresses. This combination is
known as DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 hosts, but stateless
configuration settings.
The M Flag is Set to 1 and the O Flag is Set to 0. In this combination, DHCPv6 is used
for address configuration but not for other settings. Because IPv6 hosts typically need to be configured
with other settings, such as the IPv6 addresses of Domain Name System (DNS) servers, this is an
unlikely combination.
Like DHCP for IPv4, the components of a DHCPv6 infrastructure consist of DHCPv6
clients that request configuration, DHCPv6 servers that provide configuration, and
DHCPv6 relay agents that convey messages between clients and servers when clients
are on subnets that do not have a DHCPv6 server.
DHCPv6 Messages
As with DHCP for IPv4, DHCPv6 uses User Datagram Protocol (UDP) messages. DHCPv6
clients listen for DHCP messages on UDP port 546. DHCPv6 servers and relay agents
listen for DHCPv6 messages on UDP port 547. The structure for DHCPv6 messages is
much simpler than for DHCP for IPv4, which had its origins in the BOOTP protocol to
support diskless workstations. Figure 1 shows the structure of DHCPv6 messages sent
between client and server.
Figure 1 DHCPv6 messages between client and server (Click the image for a larger
view)
The 1-byte Msg-Type field indicates the type of DHCPv6 message. The 3-byte
Transaction-ID field is determined by a client and used to group the messages of a
DHCPv6 message exchange together. Following the Transaction-ID field, DHCPv6 options
are used to indicate client and server identification, addresses, and other configuration
settings. For the list of defined DHCPv6 options, see RFC 3315, as referenced in the
"DHCPv6 RFC Resources" sidebar.
DHCPv6 options are formatted with the type-length-value (TLV) format. Figure 2 shows
the structure of DHCPv6 options.
The 2-byte Option-Code field indicates a specific option. The 2-byte Option-Len field
indicates the length of the Option-Data field in bytes. The Option-Data field contains the
data for the option.
There is a separate message structure for the messages exchanged between relay
agents and servers to record additional information. Figure 3 shows the structure of
these kinds of messages.
Figure 2 Structure of DHCPv6 options (Click the image for a larger view)
The 1-byte Hop-Count field indicates the number of relay agents that have received the
message. A receiving relay agent can discard the message if it exceeds a configured
maximum hop count. The 16-byte Link-Address field contains a non-link-local address
that is assigned to an interface connected to the subnet on which the client is located.
From the Link-Address field, the server can determine the correct address scope from
which to assign an address. The 16-byte Peer-Address field contains the IPv6 address of
the client that originally sent the message or the previous relay agent that relayed the
message. Beyond the Peer-Address field are DHCPv6 options that include the Relay
Message option, which contains the message being relayed and other options. The
Relay Message option provides an encapsulation of the messages being exchanged
between the client and the server.
There are no broadcast addresses defined for IPv6. Therefore, the use of the limited
broadcast address for some DHCPv4 messages has been replaced with the use of the
All_DHCP_Relay_Agents_and_Servers address of FF02::1:2 for DHCPv6. For example, a
DHCPv6 client attempting to discover the location of the DHCPv6 server on the network
sends a Solicit message from its link-local address to FF02::1:2. If there is a DHCPv6
server on the host's subnet, it receives the Solicit message and sends an appropriate
reply. More typically, a DHCPv6 relay agent on the host's subnet receives the Solicit
Figure 3 Structure of messages between relay and server (Click the image for a
larger view)
A Reply message sent by the requested server that contains addresses and
configuration settings.
If there is a relay agent between the client and the server, the relay agent sends the
server Relay-Forward messages containing the encapsulated Solicit and Request
messages from the client. The server sends the relay agent Relay-Reply messages
containing the encapsulated Advertise and Reply messages for the client. For a
complete list of DHCPv6 messages, see Figure 4.
Figure 4 DHCPv6 messages
DHCPv6
Message
Description
Equivalent DHCP
for IPv4 Message
Solicit
DHCPDiscover
Advertise
DHCPOffer
Request
DHCPRequest
Confirm
DHCPRequest
Renew
DHCPRequest
DHCPRequest
Reply
DHCPAck
Release
Decline
DHCPDecline
N/A
DHCPInform
RelayForward
flags in received router advertisement messages. Therefore, to use DHCPv6, you must
configure DHCPv6 servers and relay agents to service each IPv6 subnet and then
configure your IPv6 routers to set these two flags to their appropriate values. If there
are multiple advertising routers for a given subnet, they should be configured to
advertise the same stateless address prefixes and values of the M and O flags. IPv6
hosts running Windows XP or Windows Server 2003 do not include a DHCPv6 client
and therefore ignore the values of the M and O flags in received router advertisements.
You can configure an IPv6 router that is running Windows Vista or Windows Server 2008
to set the M flag to 1 in router advertisements with the "netsh interface ipv6 set
interface InterfaceName managedaddress=enabled" command. Similarly, you can set
the O flag to 1 in router advertisements with the "netsh interface ipv6 set interface
InterfaceName otherstateful=enabled" command.
Windows Server 2008 supports a DHCPv6 relay agent and DHCPv6 stateless and
stateful configuration with the DHCP Server service. For stateless configuration ,you can
configure the DHCP Server service for DHCPv6 options to be distributed to all DHCPv6
clients in the two-message DHCPv6 message exchange previously described. For
stateful configuration, you can configure the DHCP Server service for DHCPv6 scopes
and options
DNS
Short for Domain Name System (or Service or Server), anInternet service that
translates domain names into IP addresses. Because domain names are alphabetic,
they're easier to remember. The Internet however, is really based on IP addresses.
Every time you use a domain name, therefore, a DNS service must translate the name
into the corresponding IP address. For example, the domain
name www.example.com might translate to198.105.232.4.
The DNS system is, in fact, its own network. If one DNS server doesn't know how to
translate a particular domain name, it asks another one, and so on, until the correct IP
address is returned.
Short for Domain Name System (or Service or Server), anInternet service that
translates domain names into IP addresses. Because domain names are alphabetic,
Resource records, which map DNS domain names to a specific type of resource
information for use when the name is registered or resolved in the namespace.
DNS servers, which store and answer name queries for resource records.
DNS clients, also known as resolvers, which query servers to look up and resolve
names to a type of resource record specified in the query.
For more information about Requests for Comments (RFCs), see DNS RFCs.
The previous figure shows how Microsoft is assigned authority by the Internet root servers
for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers
use queries as the fundamental method of resolving names in the tree to specific types of
resource information. This information is provided by DNS servers in query responses to DNS
clients, who then extract the information and pass it to a requesting program for resolving
the queried name.
In the process of resolving a name, keep in mind that DNS servers often function as DNS
clients, querying other servers in order to fully resolve a queried name. For more
information, see How DNS query works.
In addition to second-level domains, other terms used to describe DNS domain names by
their function in the namespace are described in the following table.
Top-level domain
A name of two or three letters used to indicate a country/region or the type of organization
using a name. For more information, see Top-level domains.
".com", which indicates a name registered to a business for commercial use on the Internet.
Second-level domain
Variable-length names registered to an individual or organization for use on the Internet.
These names are always based upon an appropriate top-level domain, depending on the
type of organization or geographic location where a name is used.
"microsoft.com.", which is the second-level domain name registered to Microsoft by the
Internet DNS domain name registrar.
Subdomain
Additional names that an organization can create that are derived from the registered
second-level domain name. These include names added to grow the DNS tree of names in
an organization and divide it into departments or geographic locations.
"example.microsoft.com.", which is a fictitious subdomain assigned by Microsoft for use in
documentation example names.
network. For example, if a name at this level is used in a host (A) RR, it is used to look up the
IP address of computer based on its host name.
"host-a.example.microsoft.com.", where the first label ("host-a") is the DNS host name for a
specific computer on the network.
Understanding Zones
34 out of 35 rated this helpful - Rate this topic
Applies To: Windows Server 2008, Windows Server 2008 R2
In addition to dividing your Domain Name System (DNS) namespace into domains, you can
also divide your DNS namespace into zones that store name information about one or more
DNS domains. A zone is the authoritative source for information about each DNS domain
name that is included in the zone.
A zone starts with a single DNS domain name. If other domains are added below the initial
domain, these domains can either be part of the same zone or belong to another zone. That
is, when you add a subdomain, you can either include it as part of the original zone, or you
can delegate it away to another zone that you create to support the subdomain.
For example, the following illustration shows the microsoft.com domain, which contains
domain names for Microsoft. When the microsoft.com domain is first created at a single
server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however,
the microsoft.com domain must use subdomains, those subdomains must be included in the
zone or delegated away to another zone.
updates. Unlike in earlier DNS implementations in which any request for an update of zone
data required a full transfer of the entire zone database, with incremental transfer the
secondary server can pull only those zone changes that it needs to synchronize its copy of
the zone with its source, either a primary or secondary copy of the zone that is maintained
by another DNS server.
Primary zone
Secondary zone
Stub zone
Primary zone
When a zone that this DNS server hosts is a primary zone, the DNS server is the primary
source for information about this zone, and it stores the master copy of zone data in a local
file or in AD DS. When the zone is stored in a file, by default the primary zone file is
named zone_name.dns and it is located in the %windir%\System32\Dns folder on the server.
Secondary zone
When a zone that this DNS server hosts is a secondary zone, this DNS server is a secondary
source for information about this zone. The zone at this server must be obtained from
another remote DNS server computer that also hosts the zone. This DNS server must have
network access to the remote DNS server that supplies this server with updated information
about the zone. Because a secondary zone is merely a copy of a primary zone that is hosted
on another server, it cannot be stored in AD DS.
Stub zone
When a zone that this DNS server hosts is a stub zone, this DNS server is a source only for
information about the authoritative name servers for this zone. The zone at this server must
be obtained from another DNS server that hosts the zone. This DNS server must have
network access to the remote DNS server to copy the authoritative name server information
about the zone.
You can use stub zones to:
Keep delegated zone information current. By updating a stub zone for one of its child
zones regularly, the DNS server that hosts both the parent zone and the stub zone
will maintain a current list of authoritative DNS servers for the child zone.
Improve name resolution. Stub zones enable a DNS server to perform recursion using
the stub zone's list of name servers, without having to query the Internet or an
internal root server for the DNS namespace.
Simplify DNS administration. By using stub zones throughout your DNS infrastructure,
you can distribute a list of the authoritative DNS servers for a zone without using
secondary zones. However, stub zones do not serve the same purpose as secondary
zones, and they are not an alternative for enhancing redundancy and load sharing.
There are two lists of DNS servers involved in the loading and maintenance of a stub zone:
The list of master servers from which the DNS server loads and updates a stub zone.
A master server may be a primary or secondary DNS server for the zone. In both
cases, it will have a complete list of the DNS servers for the zone.
The list of the authoritative DNS servers for a zone. This list is contained in the stub
zone using name server (NS) resource records.
When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the
master servers, which can be in different locations, for the necessary resource records of the
authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may
contain a single server or multiple servers, and it can be changed anytime.
Understanding Reverse
Lookup
18 out of 24 rated this helpful - Rate this topic
lookup takes the form of a question, such as "Can you tell me the DNS name
of the computer that uses the IP address 192.168.1.20?"
DNS was not originally designed to support this type of query. One problem
in supporting the reverse query process is the difference in how the DNS
namespace organizes and indexes names and how IP addresses are
assigned. If the only method to answer the previous question is to search in
all domains in the DNS namespace, a reverse query would take too long and
require too much processing to be useful.
To solve this problem, a special domain, the in-addr.arpa domain, was
defined in the DNS standards and reserved in the Internet DNS namespace to
provide a practical and reliable way to perform reverse queries. To create the
reverse namespace, subdomains within the in-addr.arpa domain are formed,
using the reverse ordering of the numbers in the dotted-decimal notation of
IP addresses.
This reversed ordering of the domains for each octet value is necessary
because, unlike DNS names, when IP addresses are read from left to right,
they are interpreted in the opposite manner. When an IP address is read from
left to right, it is viewed from its most generalized information (an IP network
address) in the first part of the address to the more specific information (an
IP host address) that is contained in the last octets.
For this reason, the order of IP address octets must be reversed when the inaddr.arpa domain tree is built. The IP addresses of the DNS in-addr.arpa tree
can be delegated to organizations as they are assigned a specific or limited
set of IP addresses within the Internet-defined address classes.
Finally, the in-addr.arpa domain tree, as it is built into DNS, requires an
additional resource record typethe pointer (PTR) resource recordto be
defined. This resource record creates a mapping in the reverse lookup zone
that typically corresponds to a named host (A) resource record for the DNS
computer name of a host in its forward lookup zone.
The in-addr.arpa domain applies to all TCP/IP networks that are based on
Internet Protocol version 4 (IPv4) addressing. The New Zone Wizard
automatically assumes that you are using this domain when you create a
new reverse lookup zone.
If you are installing DNS and configuring reverse lookup zones for an Internet
Protocol version 6 (IPv6) network, you can specify an exact name in the New
Zone Wizard. This way, you can create reverse lookup zones in DNS Manager
that can support IPv6 networks, which use a different special domain name,
the ip6.arpa domain.
nonstandard DNS query operation, and their use is limited to some of the
earlier versions of Nslookup, a command-line utility for troubleshooting and
testing the DNS Server service.
The DNS Server service recognizes and accepts inverse query messages,
answering them with a fake inverse query response. For DNS servers running
in Windows NT Server 4.0, this support is available by default if the server
computer has been updated to Service Pack 4 (SP4) or later.
The MX record stands for mail exchange and is basically a list of mail exchange
servers that are to be used for the domain.
The PTR record stands for pointer record and maps an Ipv4 address to the CNAME
on the host.
The NS record stands for name server and indicates which Name Server is
authoritative for the domain.
An SOA record stands for State of Authority and is easily one of the most essential
DSN records because it stores important information like when the domain was last
updated and much more.
An SRV record stands for service and is used to define a TCP service on which the
domain operates.
A TXT record lets the administrator insert any text they'd like into the DNS record, and
it is often used for denoting facts about the domain.
Conclusion
DNS records are an important, yet unseen aspect of how the internet works. If you're
studying internet technology or training to become a server administrator, you will
definitely need to learn more information about all of the aforementioned DNS record
types and their uses.
MX
SRV
Next, it lists some of the other resource records specified by RFC
standards. Finally, it lists resource records that are specific to the
Windows 2000 implementation and one resource record specified
by the ATM Forum.
SOA Resource Records
Every zone contains a Start of Authority (SOA) resource record at
the beginning of the zone. SOA resource records include the
following fields:
The Owner , TTL , Class , and Type fields, as described in
"Resource Record Format" earlier in this chapter.
The authoritative server field shows the primary DNS
server authoritative for the zone.
The responsible person field shows the e-mail address of
the administrator responsible for the zone. It uses a period
(.) instead of an at symbol (@).
The serial number field shows how many times the zone
has been updated. When a zone's secondary server contacts
the master server for that zone to determine whether it
needs to initiate a zone transfer, the zone's secondary server
compares its own serial number with that of the master. If
the serial number of the master is higher, the secondary
server initiates a zone transfer.
The refresh field shows how often the secondary server for
the zone checks to see whether the zone has been changed.
The retry field shows how long after sending a zone transfer
request the secondary server for the zone waits for a
response from the master server before retrying.
The expire field shows how long after the previous zone
transfer the secondary server for the zone continues to
respond to queries for the zone before discarding its own
zone as invalid.
The minimum TTL field applies to all the resource records in
the zone whenever a time to live value is not specified in a
resource record. Whenever a resolver queries the server, the
server sends back resource records along with the minimum
time to live. Negative responses are cached for the minimum
TTL of the SOA resource record of the authoritative zone.
The following example shows the SOA resource record:
noam.reskit.com. IN SOA (
noamdc1.noam.reskit.com. ; authoritative server for the
zone
administrator.noam.reskit.com. ; zone admin e-mail
; (responsible person)
5099 ; serial number
3600 ; refresh (1 hour)
600 ; retry (10 mins)
86400 ; expire (1 day)
60 ) ; minimum TTL (1 min)
Top Of Page
NS Resource Records
The name server (NS) resource record indicates the servers
authoritative for the zone. They indicate primary and secondary
servers for the zone specified in the SOA resource record, and
they indicate the servers for any delegated zones. Every zone
must contain at least one NS record at the zone root.
For example, when the administrator on reskit.com delegated
authority for the noam.reskit.com subdomain to
noamdc1.noam.reskit.com., the following line was added to the
zones reskit.com and noam.reskit.com:
noam.reskit.com. IN NS noamdc1.noam.reskit.com.
Top Of Page
A Resource Records
The address (A) resource record maps an FQDN to an IP address,
so the resolvers can request the corresponding IP address for an
FQDN. For example, the following A resource record, located in
the zone noam.reskit.com, maps the FQDN of the server to its IP
address:
noamdc1 IN A 172.16.48.1
Top Of Page
PTR Records
The pointer (PTR) resource record , in contrast to the A resource
record, maps an IP address to an FQDN. For example, the
following PTR resource record maps the IP address of
noamdc1.noam.reskit.com to its FQDN:
1.48.16.172.in-addr.arpa. IN PTR
noamdc1.noam.reskit.com.
Top Of Page
CNAME Resource Records
The canonical name (CNAME) resource record creates an alias
(synonymous name) for the specified FQDN. You can use CNAME
records to hide the implementation details of your network from
the clients that connect to it. For example, suppose you want to
put an FTP server named ftp1.noam.reskit.com on your
noam.reskit.com subdomain, but you know that in six months you
will move it to a computer named ftp2.noam.reskit.com, and you
do not want your users to have to know about the change. You
can just create an alias called ftp.noam.reskit.com that points to
ftp1.noam.reskit.com, and then when you move your computer,
you need only change the CNAME record to point to
ftp2.noam.reskit.com. For example, the following CNAME resource
record creates an alias for ftp1.noam.reskit.com:
ftp.noam.reskit.com. IN CNAME ftp1.noam.reskit.com.
Once a DNS client queries for the A resource record for
ftp.noam.reskit.com, the DNS server finds the CNAME resource
record, resolves the query for the A resource record for
ftp1.noam.reskit.com, and returns both the A and CNAME
resource records to the client.
Note
According to RFC 2181, there must be only one canonical name
per alias.
Top Of Page
MX Resource Records
The mail exchange (MX) resource record specifies a mail
exchange server for a DNS domain name. A mail exchange server
is a host that will either process or forward mail for the DNS
domain name. Processing the mail means either delivering it to
the addressee or passing it to a different type of mail transport.
Forwarding the mail means sending it to its final destination
server, sending it using Simple Mail Transfer Protocol (SMTP) to
another mail exchange server that is closer to the final
destination, or queuing it for a specified amount of time.
Note
Only mail exchange servers use MX records.
SRV Records
With MX records, you can have multiple mail servers in a DNS
domain, and when a mailer needs to send mail to a host in the
domain, it can find the location of a mail exchange server. But
what about other applications, such as the World Wide Web or
telnet?
Service (SRV) resource records enable you to specify the location
of the servers for a specific service, protocol, and DNS domain.
Thus, if you have two Web servers in your domain, you can create
SRV resource records specifying which hosts serve as Web
servers, and resolvers can then retrieve all the SRV resource
records for the Web servers.
The format of an SRV record is as follows:
_Service._Proto.Name TTL Class SRV Priority Weight
Port Target
The _ Service field specifies the name of the service, such
as http or telnet. Some services are defined in the standards,
and others can be defined locally.
The _ Proto field specifies the protocol, such as TCP or UDP.
The Name field specifies the domain name to which the
resource record refers.
The TTL and Class fields are the same as the fields defined
earlier in this chapter.
The Priority field specifies the priority of the host. Clients
attempt to contact the host with the lowest priority.
The Weight field is a load balancing mechanism. When the
priority field is the same for two or more records in the same
domain, clients should try records with higher weights more
often, unless the clients support some other load balancing
mechanism.
The Port field shows the port of the service on this host.
The Target field shows the fully qualified domain name for
the host supporting the service.
CAS Server
Role
Front End Transport service on Mailbox servers This service acts as a stateless
proxy for all inbound and (optionally) outbound external SMTP traffic for the
Exchange 2016 organization. The Front End Transport service doesn't inspect
message content, doesn't communicate with the Mailbox Transport service, and
doesn't queue any messages locally.
The Mailbox Transport service doesn't communicate with the Front End Transport
service, doesn't communicate with the Mailbox Transport service or mailbox
databases on other Mailbox servers, and doesn't queue any messages locally.
Transport service on Edge Transport servers This service is very similar to the
Transport service on Mailbox servers. If you have an Edge Transport server installed in
the perimeter network, all mail coming from the Internet or going to the Internet
flows through the Transport service Edge Transport server. This service is described in
more detail later in this topic.
The following diagram shows the relationships among the components in the Exchange 2016
transport pipeline.
Overview of the transport pipeline in Exchange 2016.
Return to top
1. A message from outside the organization enters the transport pipeline through the
default Receive connector named "Default Frontend <Mailbox server name>" in the
Front End Transport service.
2. The message is sent to the Transport service on the local Mailbox server, or on a
different Mailbox server. The Transport service listens for messages on the default
Receive connector named "Default<Mailbox server name>".
3. The message is sent from the Transport service to the Mailbox Transport Delivery
service on the local Mailbox server, or on a different Mailbox server.
4. The Mailbox Transport Delivery service uses RPC to deliver the message to the local
mailbox database.
1. A message from outside the Exchange organization enters the transport pipeline
through the default Receive connector named "Default internal Receive
connector <Edge Transport server name>" in the Transport service on the Edge
Transport server.
2. In the Transport service on the Edge Transport server, the default Send connector
named "EdgeSync - Inbound to <Active Directory site name>" sends the message to
a Mailbox server in the subscribed Active Directory site.
3. In the Front End Transport service on the Mailbox server, the default Receive
connector named "Default Frontend <Mailbox server name>" accepts the message.
4. The message is sent from the Front End Transport service to the Transport service on
the local Mailbox server, or on a different Mailbox server. The Transport service listens
for messages on the default Receive connector named "Default <Mailbox server
name>".
5. The message is sent from the Transport service to the Mailbox Transport Delivery
service on the local Mailbox server, or on a different Mailbox server.
6. The Mailbox Transport Delivery service uses RPC to deliver the message to the local
mailbox database.
Return to top
1. The Mailbox Transport Submission service uses RPC to retrieve the outbound
message from the local mailbox database.
2. The Mailbox Transport Submission service uses SMTP to send the message to the
Transport service on the local Mailbox server, or on a different Mailbox server.
3. In the Transport service, the default Receive connector named "Default <Mailbox
server name>" accepts the message.
Default The Transport service uses the Send connector you created to send
the message to the Internet.
Outbound proxy The Transport service uses the Send connector you
created to send the message to the Front End Transport service on the local
Mailbox server, or on a remote Mailbox server. In the Front End Transport
service, the default Receive connector named "Outbound Proxy
Frontend <Mailbox server name>" accepts the message. The Front End
Transport services sends the message to the Internet.
1. The Mailbox Transport Submission service uses RPC to retrieve the outbound
message from the local mailbox database.
2. The Mailbox Transport Submission service uses SMTP to send the message to the
Transport service on the local Mailbox server, or on a different Mailbox server.
3. In the Transport service on a Mailbox server in the subscribed Active Directory site,
the default Receive connector named "Default <Mailbox server name>" accepts the
message.
4. The message is sent to the Edge Transport server using the implicit and invisible
intra-organization Send connector that automatically sends mail between Exchange
servers in the same organization.
5. In the Transport service on the Edge Transport server, the default Receive connector
named "Default internal Receive connector <Edge Transport server name>" accepts
the message.
6. In the Transport service on the Edge Transport server, the default Send connector
named "EdgeSync - <Active Directory site name> to Internet" sends the message to
the Internet.
Return to top
SMTP Receive When messages are received by the Transport service, message
content inspection is performed, transport rules are applied, and anti-spam and antimalware inspection is performed if they are enabled. The SMTP session has a series
of events that work together in a specific order to validate the contents of a message
before it's accepted. After a message has passed completely through SMTP Receive
and isn't rejected by receive events, or by an anti-spam or anti-malware agent, it's
put in the Submission queue.
Through the Pickup directory or the Replay directory. These directories exist on
Mailbox servers and Edge Transport servers. Correctly formatted message files
that are copied into the Pickup directory or the Replay directory are put
directly into the Submission queue.
Categorizer The categorizer picks up one message at a time from the Submission
queue. The categorizer completes the following steps:
Routing resolution.
Content conversion.
Additionally, mail flow rules that are defined by the organization are applied. After
messages have been categorized, they're put into a delivery queue that's based on
the destination of the message. Messages are queued by the destination mailbox
database, DAG, Active Directory site, Active Directory forest, or external domain.
SMTP Send How messages are routed from the Transport service depends on the
location of the message recipients relative to the Mailbox server where categorization
occurred. The message could be routed to one of the following locations:
o
Return to top
- to view info and settings for each email account, double click on an
email account.
- Click (highlight) the extra or duplicate email accounts that you are
not using and click on Remove button (on the right)
- Make sure that you do not have CAP LOCK on - passwords are
case sensitive.
- Click on your Outbox and see if there are any email messages stuck
in there. If so, either click and move the message(s) to the Draft folder or
right click and delete the message(s) that are left in your Outbox.
- Our mail server requires you to login to check your email before
sending email (for spam protection) and clicking on Send/Recv button
just does that.
- Double Check your Outgoing Mail (SMTP) setting - use the above
instructions (1.)
- Double Check your Incoming Mail (POP3) settings (Use the above
instructions)
- Login to your Web Mail and Delete any suspicious email that can
block your Mailbox. (emails that have no "From" or corrupted spam
emails can cause Outlook/Outlook Express to hang.
8. Double check your Internet connection:
- Double Check your Internet connection. Make sure you can browse
web sites.
12. Write down the error message and number (error# example:
0x800ccc15) and do a Google/Yahoo/MSN search on the error#:
message. Login to your Web Mail and delete all of the suspicious
messages. Also try to upgrade your Outlook/Outlook Express.
The user logs into their local PC (as they typically would when commencing work
in the morning)
2.
The user needs to obtain information on a partner company's extranet website for example to obtain pricing or product details
3.
4.
The partner website now does not require any password to be typed in - instead,
the user credentials are passed to the partner extranet site using AD FS
5.
The user is now logged into the partner website and can interact with the website
'logged in'