Internet Information Services is used to make your computer a web server

. If we want to have a web server for developing dynamic website or want to publish website on
our own server then we install the IIS. IIS is used on windows plate form. For other plate form
we have different web servers. E.g. apache for Linux.

IIS takes request from user and executes the required files and sends result back to the user.
IIS server also provides the services of SMTP (Simple Mail Transport Protocol). We can send
emails using SMTP. FrontPage server extensions are also the part of IIS. Using FrontPage
server extension we can use the dynamic features of IIS like form handler, Hit counter and
etc.

To install IIS you must have your operating systems CD (Win XP or Win 2K). Go to control
panel and select "Add Remove Programs". From that window select "Add Remove Windows
Components". After this you can see Internet Information Services checkbox. Select this and
press OK. Installation will be started, during this installation it will ask you to give the path of
your Windows CD. Select from browse and give the path of Windows CD. After some time the
installation process will be done. And IIS can be used.

Read more: http://wiki.answers.com/Q/How_iis_works#ixzz1GxQkEKY6

Internet Information Services (IIS) – formerly called Internet Information Server – is a web
server application and set of feature extension modules created by Microsoft for use with
Microsoft Windows. It is the most used web server after Apache HTTP Server: As of January
2011[update], it served 21.00% of all websites on the Internet and 16.22% of the one million busiest
websites on the Internet.[1] IIS 7.5 supports HTTP, HTTPS, FTP, FTPS, SMTP and NNTP. It is
an integral part of Windows Server family of products, as well as all editions of Windows Vista
and Windows 7, although some features are not supported on client versions of Windows. IIS is
not turned on by default when Windows is installed.

Contents
[hide]
• 1 History
○ 1.1 Versions
• 2 Security
• 3 Features
• 4 IIS Express
• 5 Extensions
• 6 See also
• 7 References
• 8 External links
[edit] History
The first Microsoft web server was a research project at European Microsoft Windows NT
Academic Centre (EMWAC), part of the University of Edinburgh in Scotland, and was
distributed as freeware.[2] However since the EMWAC server was unable to scale sufficiently to
handle the volume of traffic going to microsoft.com, Microsoft was forced to develop its own
webserver, IIS.[3]
Almost every version of IIS was released either along or with a version of Microsoft Windows
operating system. IIS 1.0 was initially released as a free add-on, a set of web-based services for
Windows NT 3.51. However, IIS 2.0 was included with Windows NT 4.0. IIS 3.0, which was
included with Service Pack 3 of Windows NT 4, introduced the Active Server Pages dynamic
scripting environment.[4] IIS 4.0 was released as part of an "Option Pack" for Windows NT 4.0
and dropped support for the Gopher protocol.[citation needed] IIS 5.0 shipped with Windows 2000 and
introduced additional authentication methods, management enhancements including a new MMC
based administration application, support for the WebDAV protocol, and enhancements to ASP[5]
IIS 5.1 shipped with Windows XP Professional, and was nearly identical to IIS 5.0 on Windows
2000 except for several limitations Microsoft introduced. IIS 5.1 supported only 10 simultaneous
connections and supported only a single web site.[6][7] IIS 6.0, included with Windows Server
2003 and Windows XP Professional x64 Edition, added support for IPv6 and included a new
worker process model that increased security as well as reliability.[8]
IIS 7.0 was a complete redesign and rewrite of IIS, which shipped with Windows Vista and
Windows Server 2008. IIS 7.0 included a new modular design that allowed for a lessened attack
surface and increased performance. IIS 7.0 also introduced a hierarchical configuration system
allowing for simpler site deploys, a new Windows Forms based management application, new
command line management options, and increased support for the .NET Framework.[9] IIS 7.0 on
Vista does not limit the number of allowed connections as IIS on XP did, but limits concurrent
requests to 10 (Windows Vista Ultimate, Business, and Enterprise Editions) or 3 (Vista Home
Premium). Additional requests are queued, which hampers performance, but they are not rejected
as with XP.
The current shipping version of IIS is IIS 7.5, included in Windows 7 and Windows Server 2008
R2. IIS 7.5 improved WebDAV and FTP modules as well as command line administration in
PowerShell. It also introduced Best Practices Analyzer tool and process isolation for application
pools.[10]
[edit] Versions
• IIS 1.0, Windows NT 3.51 available as a free add-on
• IIS 2.0, Windows NT 4.0
• IIS 3.0, Windows NT 4.0 Service Pack 3
• IIS 4.0, Windows NT 4.0 Option Pack
• IIS 5.0, Windows 2000
• IIS 5.1, Windows XP Professional and Windows XP Media Center Edition (requires
retail CD)
• IIS 6.0, Windows Server 2003 and Windows XP Professional x64 Edition
• IIS 7.0, Windows Server 2008 and Windows Vista (Home Premium, Business, Enterprise
and Ultimate editions)
 • IIS 7.5, Windows Server 2008 R2 and Windows 7
[edit] Security
Earlier versions of IIS were hit with a number of vulnerabilities, chief among them CA-2001-19
which led to the infamous Code Red worm; however, both versions 6.0 and 7.0 currently have no
reported issues with this specific vulnerability.[11][12] In IIS 6.0 Microsoft opted to change the
behaviour of pre-installed ISAPI handlers,[13] many of which were culprits in the vulnerabilities
of 4.0 and 5.0, thus reducing the attack surface of IIS. In addition, IIS 6.0 added a feature called
"Web Service Extensions" that prevents IIS from launching any program without explicit
permission by an administrator.
In the current release, IIS 7, the components are provided as modules so that only the required
components have to be installed, thus further reducing the attack surface. In addition, security
features are added such as Request Filtering, which rejects suspicious URLs based on a user-
defined rule set.
By default IIS 5.1 and lower run websites in-process under the SYSTEM account,[14] a default
Windows account with 'superuser' rights. Under 6.0 all request handling processes have been
brought under a Network Services account with significantly fewer privileges so that should
there be a vulnerability in a feature or in custom code it won't necessarily compromise the entire
system given the sandboxed environment these worker processes run in. IIS 6.0 also contained a
new kernel HTTP stack (http.sys) with a stricter HTTP request parser and response cache for
both static and dynamic content.
There are various built-in security features from Microsoft. Many companies offer third-party
security tools and features, also known as "Web App Firewalls, or Web Application Firewalls."
The advantage of such tools is that they offer much more comprehensive elements (such as easy-
to-use GUI, etc.) that aid in protecting an IIS installation with an additional layer of protection at
a higher level. Though no security system is ever complete, most[who?] admins choose to run an
application-layer firewall and an Intrusion Prevention System.[citation needed]
[edit] Features
The architecture of IIS 7 is modular. Modules, also called extensions, can be added or removed
individually so that only modules required for specific functionality have to be installed. IIS 7
includes native modules as part of the full installation. These modules are individual features that
the server uses to process requests and include the following:
• HTTP modules – Used to perform tasks specific to HTTP in the request-processing
pipeline, such as responding to information and inquiries sent in client headers, returning
HTTP errors, and redirecting requests.
• Security modules – Used to perform tasks related to security in the request-processing
pipeline, such as specifying authentication schemes, performing URL authorization, and
filtering requests.
• Content modules – Used to perform tasks related to content in the request-processing
pipeline, such as processing requests for static files, returning a default page when a
client does not specify a resource in a request, and listing the contents of a directory.
• Compression modules – Used to perform tasks related to compression in the request-
processing pipeline, such as compressing responses, applying Gzip compression transfer
coding to responses, and performing pre-compression of static content.
 • Caching modules – Used to perform tasks related to caching in the request-processing
pipeline, such as storing processed information in memory on the server and using cached
content in subsequent requests for the same resource.
• Logging and Diagnostics modules – Used to perform tasks related to logging and
diagnostics in the request-processing pipeline, such as passing information and
processing status to HTTP.sys for logging, reporting events, and tracking requests
currently executing in worker processes.
IIS 5.0 and higher support the following authentication mechanisms:
• Basic access authentication
• Digest access authentication
• Integrated Windows Authentication
• .NET Passport Authentication (not supported in Windows Server 2008 and above)
IIS 7.5 includes the following additional security features:
• Client Certificate Mapping
• IP Security
• Request Filtering
• URL Authorization
Authentication changed slightly between IIS 6.0 and IIS 7, most notably in that the anonymous
user which was named "IUSR_{machinename}" is a built-in account in Vista and future
operating systems and named "IUSR". Notably, in IIS 7, each authentication mechanism is
isolated into its own module and can be installed or uninstalled.
[edit] IIS Express
IIS Express, a lightweight version of IIS, is available as a standalone freeware. It may be
installed on Windows XP with Service Pack 3 and subsequent versions of Microsoft Windows.
IIS 7.5 Express only supports HTTP and HTTPS protocol.[15] IIS Express can be downloaded
separately[16] or as a part of Microsoft WebMatrix.[17]
[edit] Extensions
IIS releases new feature modules between major version releases to add new functionality. The
following extensions are available for IIS 7.5:
• FTP Publishing Service – Lets Web content creators publish content securely to IIS 7
Web servers with SSL-based authentication and data transfer.
• Administration Pack – Adds administration UI support for management features in IIS
7, including ASP.NET authorization, custom errors, FastCGI configuration, and request
filtering.
• Application Request Routing – Provides a proxy-based routing module that forwards
HTTP requests to content servers based on HTTP headers, server variables, and load
balance algorithms.
• Database Manager – Allows easy management of local and remote databases from
within IIS Manager.
 • Media Services – Integrates a media delivery platform with IIS to manage and
administer delivery of rich media and other Web content.
• URL Rewrite Module – Provides a rule-based rewriting mechanism for changing
request URLs before they are processed by the Web server.
• WebDAV – Lets Web authors publish content securely to IIS 7 Web servers, and lets
Web administrators and hosters manage WebDAV settings using IIS 7 management and
configuration tools.
• Web Deployment Tool – Synchronizes IIS 6.0 and IIS 7 servers, migrates an IIS 6.0
server to IIS 7, and deploys Web applications to an IIS 7 server.

How WINS Works in Windows Server 2008

All Windows 9x and later operating systems can request services of WINS (Windows
Internet Name Service). To request a name-IP address resolution, the client queries any
WINS server designated to it on the network. It tries to contact WINS servers in the order
given in the WINS address list in its TCP/IP configuration.

The client tries to connect to the WINS server three times before giving up and moving on
to the next WINS server in the list.

After the client boots and authenticates on the network, it registers its name and IP address
with the designated WINS server. If the client does not register automatically, the
registration takes place whenever the client next makes a query or targets a folder on a
remote server.

The process to connect to a NetBIOS name by using TCP/IP is as follows:

1) Computer MCSQL01 logs on to the network and makes a registration request with
WINS. The NetBIOS name and IP address are thus recorded to the WINS database.

2) You come along and you need to connect workstation SQLCLIENT (at 10.5.4.132) to
\\MCSQL01\SHARE1 (at 100.50.2.32), which you will see in the browse list. SQLCLIENT
requires to make a request of the WINS server for the IP address of MCSQL01 to effect a
connection to the server via TCP/IP. In other words, the client requires to turn the target
address \\MCSQL01\MYSHARE into \\100.50.2.32\MYSHARE because the only way to
connect to the remote server, via several routers, is TCP/IP.

3) If the WINS server is unavailable, then SQLCLIENT tries two more times before trying
the next WINS server in its list. Assuming that MCSQL01 happens to register with WINS
and an IP address exists, the resolve is successful and the connection can be established.

4) Finally, if you cannot see or connect to the share, you can phone the owner or admin of
the server and ask for the IP address. For network administrators to do this to
troubleshoot connections is okay. For users to do this every time that they need a file or a
printer, however, is not okay.

In the Windows Server family, the primary means for client computer to locate and communicate
with other computers on an Internet Protocol (IP) network is by using Domain Name System
(DNS). However, clients that use older versions of Windows, such as Windows NT 4.0, use
network basic I/O system (NetBIOS) names for network communication. Some applications that
run on Windows Server 2003 may also use NetBIOS names for network communication. Using
NetBIOS names requires a method of resolving NetBIOS names to IP addresses.
One can implement Windows Internet Name Service (WINS) in a Windows Server 2003
network to ensure that clients using the older versions of Windows can locate and communicate
with network resources as needed. One can use WINS both to register NetBIOS names and to
resolve those names to IP addresses.
The WINS service resolves NetBIOS names,
which reduces broadcast traffic and enables
clients to resolve the NetBIOS names of
computers that are on different network
segments (subnets).
Components of WINS
The complete Windows Server 2003 WINS
system includes the following components:
• WINS Server: a computer that
processes name registration requests
from WINS clients, registers the
client's name and IP addresses, and
responds to NetBIOS name queries that
clients submit. The WINS server then
returns the IP address of a queried
name, if the name is listed in the server
database.
• WINS database: the WINS database stores and replicate the NetBIOS name to IP address
mappings for a network.
• WINS Client: computers that are directly pointing to a WINS server to register their
NetBIOS name and to communicate with other computers registered with same WINS
server on that network.
• WINS proxy agents: a computer that monitors broadcast for name query and give
responds for all those names which are not located on the local subnet. WINS server
 communicates with the proxy for resolving names and then it caches the names for a
particular time period.

If you spend any time on the Internet sending e-mail or browsing the Web, then you use domain
name servers without even realizing it. Domain name servers, or DNS, are an incredibly
important but completely hidden part of the Internet, and they are fascinating. The DNS system
forms one of the largest and most active distributed databases on the planet. Without DNS, the
Internet would shut down very quickly.
When you use the Web or send an e-mail message, you use a domain name to do it. For
example, the URL "http://www.howstuffworks.com" contains the domain name
howstuffworks.com. So does the e-mail address "iknow@howstuffworks.com."
Human-readable names like "howstuffworks.com" are easy for people to remember, but they
don't do machines any good. All of the machines use names called IP addresses to refer to one
another. For example, the machine that humans refer to as "www.howstuffworks.com" has the IP
address 70.42.251.42. Every time you use a domain name, you use the Internet's domain name
servers (DNS) to translate the human-readable domain name into the machine-readable IP
address. During a day of browsing and e-mailing, you might access the domain name servers
hundreds of times!
In this article, we'll take a look at the DNS system so you can understand how it works and
appreciate its amazing capabilities.

DNS Servers and IP Addresses

Domain name servers translate domain names to IP addresses. That sounds like a simple task,
and it would be -- except for five things:
• There are billions of IP addresses currently in use, and most machines have a
human-readable name as well.
• There are many billions of DNS requests made every day. A single person can
easily make a hundred or more DNS requests a day, and there are hundreds
of millions of people and machines using the Internet daily.
• Domain names and IP addresses change daily.
• New domain names get created daily.
• Millions of people do the work to change and add domain names and IP
addresses every day.
The DNS system is a database, and no other database on the planet gets this many requests. No
other database on the planet has millions of people changing it every day, either. That is what
makes the DNS system so unique.
IP Addresses
To keep all of the machines on the Internet straight, each machine is assigned a unique address
called an IP address. IP stands for Internet protocol, and these addresses are 32-bit numbers
normally expressed as four "octets" in a "dotted decimal number." A typical IP address looks like
this:
70.42.251.42
The four numbers in an IP address are called octets because they can have values between 0 and
255 (28 possibilities per octet).
Every machine on the Internet has its own IP address. A server has a static IP address that does
not change very often. A home machine that is dialing up through a modem often has an IP
address that is assigned by the ISP when you dial in. That IP address is unique for your session
and may be different the next time you dial in. In this way, an ISP only needs one IP address for
each modem it supports, rather than for every customer.
If you are working on a Windows machine, you can view your current IP address with the
command WINIPCFG.EXE (IPCONFIG.EXE for Windows 2000/XP). On a UNIX machine,
type nslookup along with a machine name (such as "nslookup www.howstuffworks.com") to
display the IP address of the machine (use the command hostname to learn the name of your
machine).
For more information on IP addresses, see IANA.
As far as the Internet's machines are concerned, an IP address is all that you need to talk to a
server. For example, you can type in your browser the URL http://70.42.251.42 and you will
arrive at the machine that contains the Web server for HowStuffWorks. Domain names are
strictly a human convenience.

Domain Names
If we had to remember the IP addresses of all of the Web sites we visit every day, we would all
go nuts. Human beings just are not that good at remembering strings of numbers. We are good at
remembering words, however, and that is where domain names come in. You probably have
hundreds of domain names stored in your head. For example:
• www.howstuffworks.com - a typical name
• www.yahoo.com - the world's best-known name
• www.mit.edu - a popular EDU name
• encarta.msn.com - a Web server that does not start with www
• www.bbc.co.uk - a name using four parts rather than three
• ftp.microsoft.com - an FTP server rather than a Web server
The COM, EDU and UK portions of these domain names are called the top-level domain or
first-level domain. There are several hundred top-level domain names, including COM, EDU,
GOV, MIL, NET, ORG and INT, as well as unique two-letter combinations for every country.
Within every top-level domain there is a huge list of second-level domains. For example, in the
COM first-level domain, you've got:
• howstuffworks
 • yahoo
• msn
• microsoft
• plus millions of others...
Every name in the COM top-level domain must be unique, but there can be duplication across
domains. For example, howstuffworks.com and howstuffworks.org are completely different
machines.
In the case of bbc.co.uk, it is a third-level domain. Up to 127 levels are possible, although more
than four is rare.
The left-most word, such as www or encarta, is the host name. It specifies the name of a
specific machine (with a specific IP address) in a domain. A given domain can potentially
contain millions of host names as long as they are all unique within that domain.
Because all of the names in a given domain need to be unique, there has to be a single entity that
controls the list and makes sure no duplicates arise. For example, the COM domain cannot
contain any duplicate names, and a company called Network Solutions is in charge of
maintaining this list. When you register a domain name, it goes through one of several dozen
registrars who work with Network Solutions to add names to the list. Network Solutions, in turn,
keeps a central database known as the whois database that contains information about the owner
and name servers for each domain. If you go to the whois form, you can find information about
any domain currently in existence.
While it is important to have a central authority keeping track of the database of names in the
COM (and other) top-level domain, you would not want to centralize the database of all of the
information in the COM domain. For example, Microsoft has hundreds of thousands of IP
addresses and host names. Microsoft wants to maintain its own domain name server for the
microsoft.com domain. Similarly, Great Britain probably wants to administrate the uk top-level
domain, and Australia probably wants to administrate the au domain, and so on. For this reason,
the DNS system is a distributed database. Microsoft is completely responsible for dealing with
the name server for microsoft.com -- it maintains the machines that implement its part of the
DNS system, and Microsoft can change the database for its domain whenever it wants to because
it owns its domain name servers.
Every domain has a domain name server somewhere that handles its requests, and there is a
person maintaining the records in that DNS. This is one of the most amazing parts of the DNS
system -- it is completely distributed throughout the world on millions of machines administered
by millions of people, yet it behaves like a single, integrated database!

The Distributed System

Name servers do two things all day long:
• They accept requests from programs to convert domain names into IP
addresses.
• They accept requests from other name servers to convert domain names into
IP addresses.
When a request comes in, the name server can do one of four things with it:
 • It can answer the request with an IP address because it already knows the IP
address for the domain.
• It can contact another name server and try to find the IP address for the
name requested. It may have to do this multiple times.
• It can say, "I don't know the IP address for the domain you requested, but
here's the IP address for a name server that knows more than I do."
• It can return an error message because the requested domain name is invalid
or does not exist.
When you type a URL into your browser, the browser's first step is to convert the domain name
and host name into an IP address so that the browser can go request a Web page from the
machine at that IP address (see How Web Servers Work for details on the whole process). To do
this conversion, the browser has a conversation with a name server.
When you set up your machine on the Internet, you (or the software that you installed to connect
to your ISP) had to tell your machine what name server it should use for converting domain
names to IP addresses. On some systems, the DNS is dynamically fed to the machine when you
connect to the ISP, and on other machines it is hard-wired. If you are working on a Windows
95/98/ME machine, you can view your current name server with the command
WINIPCFG.EXE (IPCONFIG for Windows 2000/XP). On a UNIX machine, type nslookup
along with your machine name. Any program on your machine that needs to talk to a name
server to resolve a domain name knows what name server to talk to because it can get the IP
address of your machine's name server from the operating system.
The browser therefore contacts its name server and says, "I need for you to convert a domain
name to an IP address for me." For example, if you type "www.howstuffworks.com" into your
browser, the browser needs to convert that URL into an IP address. The browser will hand
"www.howstuffworks.com" to its default name server and ask it to convert it.
The name server may already know the IP address for www.howstuffworks.com. That would be
the case if another request to resolve www.howstuffworks.com came in recently (name servers
cache IP addresses to speed things up). In that case, the name server can return the IP address
immediately. Let's assume, however, that the name server has to start from scratch.
A name server would start its search for an IP address by contacting one of the root name
servers. The root servers know the IP address for all of the name servers that handle the top-
level domains. Your name server would ask the root for www.howstuffworks.com, and the root
would say (assuming no caching), "I don't know the IP address for www.howstuffworks.com, but
here's the IP address for the COM name server." Obviously, these root servers are vital to this
whole process, so:
• There are many of them scattered all over the planet.
• Every name server has a list of all of the known root servers. It contacts the
first root server in the list, and if that doesn't work it contacts the next one in
the list, and so on.
The formatting is a little odd, but basically it shows you that the list contains the actual IP
addresses of 13 different root servers.
The root server knows the IP addresses of the name servers handling the several hundred top-
level domains. It returns to your name server the IP address for a name server for the COM
domain. Your name server then sends a query to the COM name server asking it if it knows the
IP address for www.howstuffworks.com. The name server for the COM domain knows the IP
addresses for the name servers handling the HOWSTUFFWORKS.COM domain, so it returns
those. Your name server then contacts the name server for HOWSTUFFWORKS.COM and asks
if it knows the IP address for www.howstuffworks.com. It does, so it returns the IP address to
your name server, which returns it to the browser, which can then contact the server for
www.howstuffworks.com to get a Web page.
One of the keys to making this work is redundancy. There are multiple name servers at every
level, so if one fails, there are others to handle the requests. There are, for example, three
different machines running name servers for HOWSTUFFWORKS.COM requests. All three
would have to fail for there to be a problem.
The other key is caching. Once a name server resolves a request, it caches all of the IP addresses
it receives. Once it has made a request to a root server for any COM domain, it knows the IP
address for a name server handling the COM domain, so it doesn't have to bug the root servers
again for that information. Name servers can do this for every request, and this caching helps to
keep things from bogging down.
Name servers do not cache forever, though. The caching has a component, called the Time To
Live (TTL), that controls how long a server will cache a piece of information. When the server
receives an IP address, it receives the TTL with it. The name server will cache the IP address for
that period of time (ranging from minutes to days) and then discard it. The TTL allows changes
in name servers to propagate. Not all name servers respect the TTL they receive, however. When
HowStuffWorks moved its machines over to new servers, it took three weeks for the transition to
propagate throughout the Web. We put a little tag that said "new server" in the upper left corner
of the home page so people could tell whether they were seeing the new or the old server during
the transition.

Domain Name System

The Domain Name System (DNS) is a hierarchical naming system built on a distributed
database for computers, services, or any resource connected to the Internet or a private network.
Most importantly, it translates domain names meaningful to humans into the numerical
identifiers associated with networking equipment for the purpose of locating and addressing
these devices worldwide.
An often-used analogy to explain the Domain Name System is that it serves as the phone book
for the Internet by translating human-friendly computer hostnames into IP addresses. For
example, the domain name www.example.com translates to the addresses 192.0.32.10 (IPv4) and
2620:0:2d0:200::10 (IPv6).
The Domain Name System makes it possible to assign domain names to groups of Internet
resources and users in a meaningful way, independent of each entity's physical location. Because
of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain
consistent and constant even if the current Internet routing arrangements change or the
participant uses a mobile device. Internet domain names are easier to remember than IP
addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6).
Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs)
and e-mail addresses without having to know how the computer actually locates them.
The Domain Name System distributes the responsibility of assigning domain names and
mapping those names to IP addresses by designating authoritative name servers for each domain.
Authoritative name servers are assigned to be responsible for their particular domains, and in
turn can assign other authoritative name servers for their sub-domains. This mechanism has
made the DNS distributed and fault tolerant and has helped avoid the need for a single central
register to be continually consulted and updated.
In general, the Domain Name System also stores other types of information, such as the list of
mail servers that accept email for a given Internet domain. By providing a worldwide, distributed
keyword-based redirection service, the Domain Name System is an essential component of the
functionality of the Internet.
Other identifiers such as RFID tags, UPC codes, International characters in email addresses and
host names, and a variety of other identifiers could all potentially use DNS.[1][2]
The Domain Name System also specifies the technical functionality of this database service. It
defines the DNS protocol, a detailed definition of the data structures and communication
exchanges used in DNS, as part of the Internet Protocol Suite.
Internet Protocol Suite
Application Layer

BGP · DHCP · DNS · FTP · HTTP · IMAP · IRC ·

LDAP · MGCP · NNTP · NTP · POP · RIP · RPC ·
RTP · SIP · SMTP · SNMP · SSH · Telnet ·
TLS/SSL · XMPP ·
(more)

Transport Layer

TCP · UDP · DCCP · SCTP · RSVP · ECN ·

(more)

Internet Layer

IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec ·

(more)

Link Layer

ARP/InARP · NDP · OSPF · Tunnels (L2TP) ·

PPP · Media Access Control (Ethernet, DSL,
ISDN, FDDI) · (more)

Overview
The Internet maintains two principal namespaces, the domain name hierarchy[3] and the Internet
Protocol (IP) address system.[4] The Domain Name System maintains the domain namespace and
provides translation services between these two namespaces. Internet name servers and a
communication protocol implement the Domain Name System.[5] A DNS name server is a server
that stores the DNS records for a domain name, such as address (A) records, name server (NS)
records, and mail exchanger (MX) records (see also List of DNS record types); a DNS name
server responds with answers to queries against its database.
History
The practice of using a name as a humanly more meaningful abstraction of a host's numerical
address on the network dates back to the ARPANET era. Before the DNS was invented in 1983,
each computer on the network retrieved a file called HOSTS.TXT from a computer at SRI (now
SRI International).[6][7] The HOSTS.TXT file mapped names to numerical addresses. A hosts file
still exists on most modern operating systems by default and generally contains a mapping of the
IP address 127.0.0.1 to "localhost". Many operating systems use name resolution logic that
allows the administrator to configure selection priorities for available name resolution methods.
The rapid growth of the network made a centrally maintained, hand-crafted HOSTS.TXT file
unsustainable; it became necessary to implement a more scalable system capable of
automatically disseminating the requisite information.
At the request of Jon Postel, Paul Mockapetris invented the Domain Name System in 1983 and
wrote the first implementation. The original specifications were published by the Internet
Engineering Task Force in RFC 882 and RFC 883, which were superseded in November 1987 by
RFC 1034[3] and RFC 1035.[5] Several additional Request for Comments have proposed various
extensions to the core DNS protocols.
In 1984, four Berkeley students—Douglas Terry, Mark Painter, David Riggle, and Songnian
Zhou—wrote the first Unix implementation, called The Berkeley Internet Name Domain (BIND)
Server.[8] In 1985, Kevin Dunlap of DEC significantly re-wrote the DNS implementation. Mike
Karels, Phil Almquist, and Paul Vixie have maintained BIND since then. BIND was ported to the
Windows NT platform in the early 1990s.
BIND was widely distributed, especially on Unix systems, and is the dominant DNS software in
use on the Internet.[9] With the heavy use and resulting scrutiny of its open-source code, as well
as increasingly more sophisticated attack methods, many security flaws were discovered in
BIND. This contributed to the development of a number of alternative name server and resolver
programs. BIND version 9 was written from scratch and now has a security record comparable to
other modern DNS software.[citation needed]
Structure
Domain name space
The domain name space consists of a tree of domain names. Each node or leaf in the tree has
zero or more resource records, which hold information associated with the domain name. The
tree sub-divides into zones beginning at the root zone. A DNS zone may consist of only one
domain, or may comprise many domains and sub-domains, depending on the administrative
authority delegated to the manager.
The hierarchical domain name system, organized into zones, each served by a
name server

Administrative responsibility over any zone may be divided by creating additional zones.
Authority is said to be delegated for a portion of the old space, usually in form of sub-domains,
to another nameserver and administrative entity. The old zone ceases to be authoritative for the
new zone.
Domain name syntax
The definitive descriptions of the rules for forming domain names appear in RFC 1035, RFC
1123, and RFC 2181. A domain name consists of one or more parts, technically called labels,
that are conventionally concatenated, and delimited by dots, such as example.com.
• The right-most label conveys the top-level domain; for example, the domain
name www.example.com belongs to the top-level domain com.
 • The hierarchy of domains descends from right to left; each label to the left
specifies a subdivision, or subdomain of the domain to the right. For example:
the label example specifies a subdomain of the com domain, and www is a sub
domain of example.com. This tree of subdivisions may have up to 127 levels.
• Each label may contain up to 63 characters. The full domain name may not
exceed a total length of 253 characters in its external dotted-label
specification.[10] In the internal binary representation of the DNS the
maximum length requires 255 octets of storage.[3] In practice, some domain
registries may have shorter limits.[citation needed]
• DNS names may technically consist of any character representable in an
octet. However, the allowed formulation of domain names in the DNS root
zone, and most other sub domains, uses a preferred format and character
set. The characters allowed in a label are a subset of the ASCII character set,
and includes the characters a through z, A through Z, digits 0 through 9, and
the hyphen. This rule is known as the LDH rule (letters, digits, hyphen).
Domain names are interpreted in case-independent manner. Labels may not
start or end with a hyphen.[11]
• A hostname is a domain name that has at least one IP address associated.
For example, the domain names www.example.com and example.com are also
hostnames, whereas the com domain is not.
Internationalized domain names
The permitted character set of the DNS prevented the representation of names and words of
many languages in their native alphabets or scripts. ICANN has approved the Internationalizing
Domain Names in Applications (IDNA) system, which maps Unicode strings into the valid DNS
character set using Punycode. In 2009 ICANN approved the installation of IDN country code
top-level domains. In addition, many registries of the existing top-level domain names (TLD)s
have adopted IDNA.
Name servers
The Domain Name System is maintained by a distributed database system, which uses the client-
server model. The nodes of this database are the name servers. Each domain has at least one
authoritative DNS server that publishes information about that domain and the name servers of
any domains subordinate to it. The top of the hierarchy is served by the root nameservers, the
servers to query when looking up (resolving) a TLD.
Authoritative name server
An authoritative name server is a name server that gives answers that have been configured by
an original source, for example, the domain administrator or by dynamic DNS methods, in
contrast to answers that were obtained via a regular DNS query to another name server. An
authoritative-only name server only returns answers to queries about domain names that have
been specifically configured by the administrator.
An authoritative name server can either be a master server or a slave server. A master server is a
server that stores the original (master) copies of all zone records. A slave server uses an
automatic updating mechanism of the DNS protocol in communication with its master to
maintain an identical copy of the master records.
Every DNS zone must be assigned a set of authoritative name servers that are installed in NS
records in the parent zone.
When domain names are registered with a domain name registrar their installation at the domain
registry of a top level domain requires the assignment of a primary name server and at least one
secondary name server. The requirement of multiple name servers aims to make the domain still
functional even if one name server becomes inaccessible or inoperable.[12] The designation of a
primary name server is solely determined by the priority given to the domain name registrar. For
this purpose generally only the fully qualified domain name of the name server is required,
unless the servers are contained in the registered domain, in which case the corresponding IP
address is needed as well.
Primary name servers are often master name servers, while secondary name server may be
implemented as slave servers.
An authoritative server indicates its status of supplying definitive answers, deemed authoritative,
by setting a software flag (a protocol structure bit), called the Authoritative Answer (AA) bit in its
responses.[5] This flag is usually reproduced prominently in the output of DNS administration
query tools (such as dig) to indicate that the responding name server is an authority for the
domain name in question.[5]
Recursive and caching name server
In principle, authoritative name servers are sufficient for the operation of the Internet. However,
with only authoritative name servers operating, every DNS query must start with recursive
queries at the root zone of the Domain Name System and each user system must implement
resolver software capable of recursive operation.
To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-
user applications, the Domain Name System supports DNS cache servers which store DNS query
results for a period of time determined in the configuration (time-to-live) of the domain name
record in question. Typically, such caching DNS servers, also called DNS caches, also
implement the recursive algorithm necessary to resolve a given name starting with the DNS root
through to the authoritative name servers of the queried domain. With this function implemented
in the name server, user applications gain efficiency in design and operation.
The combination of DNS caching and recursive functions in a name server is not mandatory, the
functions can be implemented independently in servers for special purposes.
Internet service providers typically provide recursive and caching name servers for their
customers. In addition, many home networking routers implement DNS caches and recursors to
improve efficiency in the local network.
DNS resolvers
See also: resolv.conf

The client-side of the DNS is called a DNS resolver. It is responsible for initiating and
sequencing the queries that ultimately lead to a full resolution (translation) of the resource
sought, e.g., translation of a domain name into an IP address.
A DNS query may be either a non-recursive query or a recursive query:
 • A non-recursive query is one in which the DNS server provides a record for a
domain for which it is authoritative itself, or it provides a partial result
without querying other servers.
• A recursive query is one for which the DNS server will fully answer the query
(or give an error) by querying other name servers as needed. DNS servers
are not required to support recursive queries.
The resolver, or another DNS server acting recursively on behalf of the resolver, negotiates use
of recursive service using bits in the query headers.
Resolving usually entails iterating through several name servers to find the needed information.
However, some resolvers function simplistically and can communicate only with a single name
server. These simple resolvers (called "stub resolvers") rely on a recursive name server to
perform the work of finding information for them.
Operation
Address resolution mechanism
Domain name resolvers determine the appropriate domain name servers responsible for the
domain name in question by a sequence of queries starting with the right-most (top-level)
domain label.

A DNS recursor consults three nameservers to resolve the address

www.wikipedia.org.

The process entails:

1. A network host is configured with an initial cache (so called hints) of the
known addresses of the root nameservers. Such a hint file is updated
periodically by an administrator from a reliable source.
2. A query to one of the root servers to find the server authoritative for the top-
level domain.
3. A query to the obtained TLD server for the address of a DNS server
authoritative for the second-level domain.
4. Repetition of the previous step to process each domain name label in
sequence, until the final step which returns the IP address of the host sought.
The diagram illustrates this process for the host www.wikipedia.org.
The mechanism in this simple form would place a large operating burden on the root servers,
with every search for an address starting by querying one of them. Being as critical as they are to
the overall function of the system, such heavy use would create an insurmountable bottleneck for
trillions of queries placed every day. In practice caching is used in DNS servers to overcome this
problem, and as a result, root nameservers actually are involved with very little of the total
traffic.
Circular dependencies and glue records
Name servers in delegations are identified by name, rather than by IP address. This means that a
resolving name server must issue another DNS request to find out the IP address of the server to
which it has been referred. If the name given in the delegation is a subdomain of the domain for
which the delegation is being provided, there is a circular dependency. In this case the
nameserver providing the delegation must also provide one or more IP addresses for the
authoritative nameserver mentioned in the delegation. This information is called glue. The
delegating name server provides this glue in the form of records in the additional section of the
DNS response, and provides the delegation in the answer section of the response.
For example, if the authoritative name server for example.org is ns1.example.org, a computer
trying to resolve www.example.org first resolves ns1.example.org. Since ns1 is contained in
example.org, this requires resolving example.org first, which presents a circular dependency.
To break the dependency, the nameserver for the org top level domain includes glue along with
the delegation for example.org. The glue records are address records that provide IP addresses
for ns1.example.org. The resolver uses one or more of these IP addresses to query one of
domain's authoritative servers, which allows it to complete the DNS query.
Record caching
Because of the large volume of requests generated DNS for the public Internet, the designers
wished to provide a mechanism to reduce the load on individual DNS servers. To this end, the
DNS resolution process allows for caching of records for a period of time after an answer. This
entails the local recording and subsequent consultation of the copy instead of initiating a new
request upstream. The time for which a resolver caches a DNS response is determined by a value
called the time to live (TTL) associated with every record. The TTL is set by the administrator of
the DNS server handing out the authoritative response. The period of validity may vary from just
seconds to days or even weeks.
As a noteworthy consequence of this distributed and caching architecture, changes to DNS
records do not propagate throughout the network immediately, but require all caches to expire
and refresh after the TTL. RFC 1912 conveys basic rules for determining appropriate TTL
values.
Some resolvers may override TTL values, as the protocol supports caching for up to 68 years or
no caching at all. Negative caching, i.e. the caching of the fact of non-existence of a record, is
determined by name servers authoritative for a zone which must include the Start of Authority
(SOA) record when reporting no data of the requested type exists. The value of the MINIMUM
field of the SOA record and the TTL of the SOA itself is used to establish the TTL for the
negative answer.
Reverse lookup
A reverse lookup is a query of the DNS for domain names when the IP address is known.
Multiple domain names may be associated with an IP address. The DNS stores IP addresses in
the form of domain names as specially formatted names in pointer (PTR) records within the
infrastructure top-level domain arpa. For IPv4, the domain is in-addr.arpa. For IPv6, the
reverse lookup domain is ip6.arpa. The IP address is represented as a name in reverse-ordered
octet representation for IPv4, and reverse-ordered nibble representation for IPv6.
When performing a reverse lookup, the DNS client converts the address into these formats, and
then queries the name for a PTR record following the delegation chain as for any DNS query.
For example, the IPv4 address 208.80.152.2 is represented as a DNS name as
2.152.80.208.in-addr.arpa. The DNS resolver begins by querying the root servers, which
point to ARIN's servers for the 208.in-addr.arpa zone. From there the Wikimedia servers are
assigned for 152.80.208.in-addr.arpa, and the PTR lookup completes by querying the
wikimedia nameserver for 2.152.80.208.in-addr.arpa, which results in an authoritative
response.
Client lookup

DNS resolution sequence

Users generally do not communicate directly with a DNS resolver. Instead DNS resolution takes
place transparently in applications programs such as web browsers, e-mail clients, and other
Internet applications. When an application makes a request that requires a domain name lookup,
such programs send a resolution request to the DNS resolver in the local operating system, which
in turn handles the communications required.
The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If
the cache can provide the answer to the request, the resolver will return the value in the cache to
the program that made the request. If the cache does not contain the answer, the resolver will
send the request to one or more designated DNS servers. In the case of most home users, the
Internet service provider to which the machine connects will usually supply this DNS server:
such a user will either have configured that server's address manually or allowed DHCP to set it;
however, where systems administrators have configured systems to use their own DNS servers,
their DNS resolvers point to separately maintained nameservers of the organization. In any
event, the name server thus queried will follow the process outlined above, until it either
successfully finds a result or does not. It then returns its results to the DNS resolver; assuming it
has found a result, the resolver duly caches that result for future use, and hands the result back to
the software which initiated the request.
Broken resolvers
An additional level of complexity emerges when resolvers violate the rules of the DNS protocol.
A number of large ISPs have configured their DNS servers to violate rules (presumably to allow
them to run on less-expensive hardware than a fully compliant resolver), such as by disobeying
TTLs, or by indicating that a domain name does not exist just because one of its name servers
does not respond.[13]
As a final level of complexity, some applications (such as web-browsers) also have their own
DNS cache, in order to reduce the use of the DNS resolver library itself. This practice can add
extra difficulty when debugging DNS issues, as it obscures the freshness of data, and/or what
data comes from which cache. These caches typically use very short caching times—on the order
of one minute.[citation needed]
Internet Explorer represents a notable exception: versions up to IE 3.x cache DNS records for 24
hours by default. Internet Explorer 4.x and later versions (up to IE 8) decrease the default time
out value to half an hour, which may be changed in corresponding registry keys.[14]
Other applications
The system outlined above provides a somewhat simplified scenario. The Domain Name System
includes several other functions:
• Hostnames and IP addresses do not necessarily match on a one-to-one basis.
Multiple hostnames may correspond to a single IP address: combined with
virtual hosting, this allows a single machine to serve many web sites.
Alternatively a single hostname may correspond to many IP addresses: this
can facilitate fault tolerance and load distribution, and also allows a site to
move physical location seamlessly.
• There are many uses of DNS besides translating names to IP addresses. For
instance, Mail transfer agents use DNS to find out where to deliver e-mail for
a particular address. The domain to mail exchanger mapping provided by MX
records accommodates another layer of fault tolerance and load distribution
on top of the name to IP address mapping.
• E-mail Blacklists: The DNS system is used for efficient storage and
distribution of IP addresses of blacklisted e-mail hosts. The usual method is
putting the IP address of the subject host into the sub-domain of a higher
level domain name, and resolve that name to different records to indicate a
positive or a negative. A hypothetical example using blacklist.com,
○ 102.3.4.5 is blacklisted => Creates 5.4.3.102.blacklist.com and
resolves to 127.0.0.1
○ 102.3.4.6 is not => 6.4.3.102.blacklist.com is not found, or default to
127.0.0.2
○ E-mail servers can then query blacklist.com through the DNS
mechanism to find out if a specific host connecting to them is in the
blacklist. Today many of such blacklists, either free or subscription-
based, are available mainly for use by email administrators and anti-
spam software.
• Software Updates: many anti-virus and commercial software now use the
DNS system to store version numbers of the latest software updates so client
computers do not need to connect to the update servers every time. For
these types of applications, the cache time of the DNS records are usually
shorter.
 • Sender Policy Framework and DomainKeys, instead of creating their own
record types, were designed to take advantage of another DNS record type,
the TXT record.
• To provide resilience in the event of computer failure, multiple DNS servers
are usually provided for coverage of each domain, and at the top level,
thirteen very powerful root servers exist, with additional "copies" of several of
them distributed worldwide via Anycast.
• Dynamic DNS (also referred to as DDNS) provides clients the ability to update
their IP address in the DNS after it changes due to mobility, e.g.

Protocol details
DNS primarily uses User Datagram Protocol (UDP) on port number 53 to serve requests.[5] DNS
queries consist of a single UDP request from the client followed by a single UDP reply from the
server. The Transmission Control Protocol (TCP) is used when the response data size exceeds
512 bytes, or for tasks such as zone transfers. Some operating systems, such as HP-UX, are
known to have resolver implementations that use TCP for all queries, even when UDP would
suffice.
DNS resource records
Further information: List of DNS record types

A Resource Record (RR) is the basic data element in the domain name system. Each record has a
type (A, MX, etc.), an expiration time limit, a class, and some type-specific data. Resource
records of the same type define a resource record set. The order of resource records in a set,
returned by a resolver to an application, is undefined, but often servers implement round-robin
ordering to achieve load balancing. DNSSEC, however, works on complete resource record sets
in a canonical order.
When sent over an IP network, all records use the common format specified in RFC 1035:[15]

RR (Resource record) fields

Length
Field Description
(octets)

NAME Name of the node to which this record pertains (variable)

TYPE Type of RR in numeric form (e.g. 15 for MX RRs) 2

CLASS Class code 2

TTL Count of seconds that the RR stays valid (The maximum is 231- 4
 1, which is about 68 years.)

RDLENG
Length of RDATA field 2
TH

RDATA Additional RR-specific data (variable)

NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be
shortened using label compression where ends of domain names mentioned earlier in the packet
can be substituted for the end of the current domain name.
TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use.
For example, the A record is used to translate from a domain name to an IPv4 address, the NS
record lists which name servers can answer lookups on a DNS zone, and the MX record specifies
the mail server used to handle mail for a domain specified in an e-mail address (see also List of
DNS record types).
RDATA is data of type-specific relevance, such as the IP address for address records, or the
priority and hostname for MX records. Well known record types may use label compression in
the RDATA field, but "unknown" record types must not (RFC 3597).
The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet
hostnames, servers, or IP addresses. In addition, the classes Chaos (CN) and Hesiod (HS) exist.[16]
Each class is an independent name space with potentially different delegations of DNS zones.
In addition to resource records defined in a zone file, the domain name system also defines
several request types that are used only in communication with other DNS nodes (on the wire),
such as when performing zone transfers (AXFR/IXFR) or for EDNS (OPT).
Wildcard DNS records
Main article: Wildcard DNS record

The domain name system supports wildcard domain names which are names that start with the
asterisk label, '*', e.g., *.example.[3][17] DNS records belonging to wildcard domain names
specify rules for generating resource records within a single DNS zone by substituting whole
labels with matching components of the query name, including any specified descendants. For
example, in the DNS zone x.example, the following configuration specifies that all subdomains
(including subdomains of subdomains) of x.example use the mail exchanger a.x.example. The
records for a.x.example are needed to specify the mail exchanger. As this has the result of
excluding this domain name and its subdomains from the wildcard matches, all subdomains of
a.x.example must be defined in a separate wildcard statement.
The role of wildcard records was refined in RFC 4592, because the original definition in RFC
1034 was incomplete and resulted in misinterpretations by implementers.[17]
Protocol extensions
The original DNS protocol had limited provisions for extension with new features. In 1999, Paul
Vixie published in RFC 2671 an extension mechanism, called Extension mechanisms for DNS
(EDNS) that introduced optional protocol elements without increasing overhead when not in use.
This was accomplished through the OPT pseudo-resource record that only exists in wire
transmissions of the protocol, but not in any zone files. Initial extensions were also suggested
(EDNS0), such as increasing the DNS message size in UDP datagrams.
Dynamic zone updates
Dynamic DNS updates use the UPDATE DNS opcode to add or remove resource records
dynamically from a zone data base maintained on an authoritative DNS server. The feature is
described in RFC 2136. This facility is useful to register network clients into the DNS when they
boot or become otherwise available on the network. Since a booting client may be assigned a
different IP address each time from a DHCP server, it is not possible to provide static DNS
assignments for such clients.
Security issues
DNS was not originally designed with security in mind, and thus has a number of security issues.
One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it
has received authentic information when, in reality, it has not.
DNS responses are traditionally not cryptographically signed, leading to many attack
possibilities; the Domain Name System Security Extensions (DNSSEC) modifies DNS to add
support for cryptographically signed responses. There are various extensions to support securing
zone transfer information as well.
Even with encryption, a DNS server could become compromised by a virus (or for that matter a
disgruntled employee) that would cause IP addresses of that server to be redirected to a
malicious address with a long TTL. This could have far-reaching impact to potentially millions
of Internet users if busy DNS servers cache the bad IP data. This would require manual purging
of all affected DNS caches as required by the long TTL (up to 68 years).
Some domain names can spoof other, similar-looking domain names. For example, "paypal.com"
and "paypa1.com" are different names, yet users may be unable to tell the difference when the
user's typeface (font) does not clearly differentiate the letter l and the numeral 1. This problem is
more serious in systems that support internationalized domain names, since many character
codes in ISO 10646, may appear identical on typical computer screens. This vulnerability is
occasionally exploited in phishing.[18]
Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS
results.
Domain name registration
The right to use a domain name is delegated by domain name registrars which are accredited by
the Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged
with overseeing the name and number systems of the Internet. In addition to ICANN, each top-
level domain (TLD) is maintained and serviced technically by an administrative organization,
operating a registry. A registry is responsible for maintaining the database of names registered
within the TLD it administers. The registry receives registration information from each domain
name registrar authorized to assign names in the corresponding TLD and publishes the
information using a special service, the whois protocol.
ICANN publishes the complete list of TLD registries and domain name registrars. Registrant
information associated with domain names is maintained in an online database accessible with
the WHOIS service. For most of the more than 240 country code top-level domains (ccTLDs),
the domain registries maintain the WHOIS (Registrant, name servers, expiration dates, etc.)
information. For instance, DENIC, Germany NIC, holds the DE domain data. Since about 2001,
most gTLD registries have adopted this so-called thick registry approach, i.e. keeping the
WHOIS data in central registries instead of registrar databases.
For COM and NET domain names, a thin registry model is used: the domain registry (e.g. VeriSign)
holds basic WHOIS (registrar and name servers, etc.) data. One can find the detailed WHOIS
(registrant, name servers, expiry dates, etc.) at the registrars.
Some domain name registries, often called network information centers (NIC), also function as
registrars to end-users. The major generic top-level domain registries, such as for the COM, NET,
ORG, INFO domains, use a registry-registrar model consisting of many domain name registrars[19]
[20]
In this method of management, the registry only manages the domain name database and the
relationship with the registrars. The registrants (users of a domain name) are customers of the
registrar, in some cases through additional layers of resellers.
Internet standards
The Domain Name System is defined by Request for Comments (RFC) documents published by
the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that
define the DNS protocol.

6.2. How DNS Works

DNS organizes hostnames in a domain hierarchy. A domain is a collection of sites that are
related in some sense—because they form a proper network (e.g., all machines on a campus, or
all hosts on BITNET), because they all belong to a certain organization (e.g., the U.S.
government), or because they're simply geographically close. For instance, universities are
commonly grouped in the edu domain, with each university or college using a separate
subdomain, below which their hosts are subsumed. Groucho Marx University have the
groucho.edu domain, while the LAN of the Mathematics department is assigned
maths.groucho.edu. Hosts on the departmental network would have this domain name tacked
onto their hostname, so erdos would be known as erdos.maths.groucho.edu. This is called the
fully qualified domain name (FQDN), which uniquely identifies this host worldwide.
Figure 6-1 shows a section of the namespace. The entry at the root of this tree, which is denoted
by a single dot, is quite appropriately called the root domain and encompasses all other domains.
To indicate that a hostname is a fully qualified domain name, rather than a name relative to some
(implicit) local domain, it is sometimes written with a trailing dot. This dot signifies that the
name's last component is the root domain.
Figure 6-1. A part of the domain namespace
Depending on its location in the name hierarchy, a domain may be called top-level, second-level,
or third-level. More levels of subdivision occur, but they are rare. This list details several top-
level domains you may see frequently:
Domai Description
n

edu (Mostly U.S.) educational institutions like universities.

com Commercial organizations and companies.
org Non-commercial organizations. Private UUCP networks are often in this domain.
net Gateways and other administrative hosts on a network.
mil U.S. military institutions.
gov U.S. government institutions.
uucp Officially, all site names formerly used as UUCP names without domains have been
moved to this domain.

Historically, the first four of these were assigned to the U.S., but recent changes in policy have
meant that these domains, named global Top Level Domains (gTLD), are now considered global
in nature. Negotiations are currently underway to broaden the range of gTLDs, which may result
in increased choice in the future.
Outside the U.S., each country generally uses a top-level domain of its own named after the two-
letter country code defined in ISO-3166. Finland, for instance, uses the fi domain; fr is used by
France, de by Germany, and au by Australia. Below this top-level domain, each country's NIC is
free to organize hostnames in whatever way they want. Australia has second-level domains
similar to the international top-level domains, named com.au and edu.au. Other countries, like
Germany, don't use this extra level, but have slightly long names that refer directly to the
organizations running a particular domain. It's not uncommon to see hostnames like
ftp.informatik.uni-erlangen.de. Chalk that up to German efficiency.
Of course, these national domains do not imply that a host below that domain is actually located
in that country; it means only that the host has been registered with that country's NIC. A
Swedish manufacturer might have a branch in Australia and still have all its hosts registered with
the se top-level domain.
Organizing the namespace in a hierarchy of domain names nicely solves the problem of name
uniqueness; with DNS, a hostname has to be unique only within its domain to give it a name
different from all other hosts worldwide. Furthermore, fully qualified names are easy to
remember. Taken by themselves, these are already very good reasons to split up a large domain
into several subdomains.
DNS does even more for you than this. It also allows you to delegate authority over a subdomain
to its administrators. For example, the maintainers at the Groucho Computing Center might
create a subdomain for each department; we already encountered the math and physics
subdomains above. When they find the network at the Physics department too large and chaotic
to manage from outside (after all, physicists are known to be an unruly bunch of people), they
may simply pass control of the physics.groucho.edu domain to the administrators of this
network. These administrators are free to use whatever hostnames they like and assign them IP
addresses from their network in whatever fashion they desire, without outside interference.
To this end, the namespace is split up into zones, each rooted at a domain. Note the subtle
difference between a zone and a domain: the domain groucho.edu encompasses all hosts at
Groucho Marx University, while the zone groucho.edu includes only the hosts that are managed
by the Computing Center directly; those at the Mathematics department, for example. The hosts
at the Physics department belong to a different zone, namely physics.groucho.edu. In Figure 6-1,
the start of a zone is marked by a small circle to the right of the domain name.
6.2.1. Name Lookups with DNS
At first glance, all this domain and zone fuss seems to make name resolution an awfully
complicated business. After all, if no central authority controls what names are assigned to which
hosts, how is a humble application supposed to know?
Now comes the really ingenious part about DNS. If you want to find the IP address of erdos,
DNS says, “Go ask the people who manage it, and they will tell you.”
In fact, DNS is a giant distributed database. It is implemented by so-called name servers that
supply information on a given domain or set of domains. For each zone there are at least two, or
at most a few, name servers that hold all authoritative information on hosts in that zone. To
obtain the IP address of erdos, all you have to do is contact the name server for the groucho.edu
zone, which will then return the desired data.
Easier said than done, you might think. So how do I know how to reach the name server at
Groucho Marx University? In case your computer isn't equipped with an address-resolving
oracle, DNS provides for this, too. When your application wants to look up information on erdos,
it contacts a local name server, which conducts a so-called iterative query for it. It starts off by
sending a query to a name server for the root domain, asking for the address of
erdos.maths.groucho.edu. The root name server recognizes that this name does not belong to its
zone of authority, but rather to one below the edu domain. Thus, it tells you to contact an edu
zone name server for more information and encloses a list of all edu name servers along with
their addresses. Your local name server will then go on and query one of those, for instance,
a.isi.edu. In a manner similar to the root name server, a.isi.edu knows that the groucho.edu
people run a zone of their own, and points you to their servers. The local name server will then
present its query for erdos to one of these, which will finally recognize the name as belonging to
its zone, and return the corresponding IP address.
This looks like a lot of traffic being generated for looking up a measly IP address, but it's really
only miniscule compared to the amount of data that would have to be transferred if we were still
stuck with HOSTS.TXT. There's still room for improvement with this scheme, however.
To improve response time during future queries, the name server stores the information obtained
in its local cache. So the next time anyone on your local network wants to look up the address of
a host in the groucho.edu domain, your name server will go directly to the groucho.edu name
server.[1]
Of course, the name server will not keep this information forever; it will discard it after some
time. The expiration interval is called the time to live, or TTL. Each datum in the DNS database
is assigned such a TTL by administrators of the responsible zone.
6.2.2. Types of Name Servers
Name servers that hold all information on hosts within a zone are called authoritative for this
zone, and sometimes are referred to as master name servers. Any query for a host within this
zone will end up at one of these master name servers.
Master servers must be fairly well synchronized. Thus, the zone's network administrator must
make one the primary server, which loads its zone information from data files, and make the
others secondary servers, which transfer the zone data from the primary server at regular
intervals.
Having several name servers distributes workload; it also provides backup. When one name
server machine fails in a benign way, like crashing or losing its network connection, all queries
will fall back to the other servers. Of course, this scheme doesn't protect you from server
malfunctions that produce wrong replies to all DNS requests, such as from software bugs in the
server program itself.
You can also run a name server that is not authoritative for any domain.[2] This is useful, as the
name server will still be able to conduct DNS queries for the applications running on the local
network and cache the information. Hence it is called a caching-only server.
6.2.3. The DNS Database
We have seen that DNS not only deals with IP addresses of hosts, but also exchanges
information on name servers. DNS databases may have, in fact, many different types of entries.
A single piece of information from the DNS database is called a resource record (RR). Each
record has a type associated with it describing the sort of data it represents, and a class specifying
the type of network it applies to. The latter accommodates the needs of different addressing
schemes, like IP addresses (the IN class), Hesiod addresses (used by MIT's Kerberos system),
and a few more. The prototypical resource record type is the A record, which associates a fully
qualified domain name with an IP address.
A host may be known by more than one name. For example you might have a server that
provides both FTP and World Wide Web servers, which you give two names: ftp.machine.org
and www.machine.org. However, one of these names must be identified as the official or
canonical hostname, while the others are simply aliases referring to the official hostname. The
difference is that the canonical hostname is the one with an associated A record, while the others
only have a record of type CNAME that points to the canonical hostname.
We will not go through all record types here, but we will give you a brief example. Example 6-4
shows a part of the domain database that is loaded into the name servers for the
physics.groucho.edu zone.
Example 6-4. An Excerpt from the named.hosts File for the Physics Department
; Authoritative Information on physics.groucho.edu.
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
1999090200 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
;
; Name servers
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Theoretical Physics (subnet 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
name server IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Collider Lab. (subnet 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...
Apart from the A and CNAME records, you can see a special record at the top of the file,
stretching several lines. This is the SOA resource record signaling the Start of Authority, which
holds general information on the zone the server is authoritative for. The SOA record comprises,
for instance, the default time to live for all records.
Note that all names in the sample file that do not end with a dot should be interpreted relative to
the physics.groucho.edu domain. The special name (@) used in the SOA record refers to the
domain name by itself.
We have seen earlier that the name servers for the groucho.edu domain somehow have to know
about the physics zone so that they can point queries to their name servers. This is usually
achieved by a pair of records: the NS record that gives the server's FQDN, and an A record that
associates an address with that name. Since these records are what holds the namespace together,
they are frequently called glue records. They are the only instances of records in which a parent
zone actually holds information on hosts in the subordinate zone. The glue records pointing to
the name servers for physics.groucho.edu are shown in Example 6-5.
Example 6-5. An Excerpt from the named.hosts File for GMU
; Zone data for the groucho.edu zone.
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 ; serial no
 360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
....
;
; Glue records for the physics.groucho.edu zone
physics IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
...

6.2.4. Reverse Lookups

Finding the IP address belonging to a host is certainly the most common use for the Domain
Name System, but sometimes you'll want to find the canonical hostname corresponding to an
address. Finding this hostname is called reverse mapping, and is used by several network
services to verify a client's identity. When using a single hosts file, reverse lookups simply
involve searching the file for a host that owns the IP address in question. With DNS, an
exhaustive search of the namespace is out of the question. Instead, a special domain, in-
addr.arpa, has been created that contains the IP addresses of all hosts in a reversed dotted quad
notation. For instance, an IP address of 149.76.12.4 corresponds to the name 4.12.76.149.in-
addr.arpa. The resource-record type linking these names to their canonical hostnames is PTR.
Creating a zone of authority usually means that its administrators have full control over how they
assign addresses to names. Since they usually have one or more IP networks or subnets at their
hands, there's a one-to-many mapping between DNS zones and IP networks. The Physics
department, for instance, comprises the subnets 149.76.8.0, 149.76.12.0, and 149.76.14.0.
Consequently, new zones in the in-addr.arpa domain have to be created along with the physics
zone, and delegated to the network administrators at the department: 8.76.149.in-addr.arpa,
12.76.149.in-addr.arpa, and 14.76.149.in-addr.arpa. Otherwise, installing a new host at the
Collider Lab would require them to contact their parent domain to have the new address entered
into their in-addr.arpa zone file.
The zone database for subnet 12 is shown in Example 6-6. The corresponding glue records in the
database of their parent zone are shown in Example 6-7.
Example 6-6. An Excerpt from the named.rev File for Subnet 12
; the 12.76.149.in-addr.arpa domain.
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
1999090200 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu.
Example 6-7. An Excerpt from the named.rev File for Network 149.76
; the 76.149.in-addr.arpa domain.
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 360000 3600 3600000 3600
}
 ...
; subnet 4: Mathematics Dept.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; subnet 12: Physics Dept, separate zone
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
...
in-addr.arpa system zones can only be created as supersets of IP networks. An even more severe
restriction is that these networks' netmasks have to be on byte boundaries. All subnets at
Groucho Marx University have a netmask of 255.255.255.0, hence an in-addr.arpa zone could be
created for each subnet. However, if the netmask were 255.255.255.128 instead, creating zones
for the subnet 149.76.12.128 would be impossible, because there's no way to tell DNS that the
12.76.149.in-addr.arpa domain has been split into two zones of authority, with hostnames
ranging from 1 through 127, and 128 through 255, respectively.
Notes
[1] If information weren't cached, then DNS would be as inefficient as any other method
because each query would involve the root name servers.
[2] Well, almost. A name server has to provide at least name service for localhost and reverse
lookups of 127.0.0.1.

Prev Home Next

The Resolver Library Up Running named

How does DNS work?

Suppose your computer wants to find the IP address of network-surveys.cr.yp.to. It
contacts a series of DNS servers around the Internet.

There are several DNS servers with information about network-surveys.cr.yp.to. A central
root server (located at Internet HQ in Virginia) has the following data in a file on disk:
.:198.41.0.4
&to:198.6.1.82
The root server's IP address is 198.41.0.4; your computer also has this address in a
file on disk. Your computer sends its question to the root server, and receives a
response from the root server's data:

+--------+ network-surveys.cr.yp.to? +-----------+

| Your | --------------------------> |198.41.0.4 |
|computer| <--------------- |root server|
+--------+ &to:198.6.1.82 +-----------+
The response &to:198.6.1.82 is a delegation. It says ``For information about .to,
ask the DNS server at IP address 198.6.1.82.''

The DNS server at 198.6.1.82 (also located somewhere in Virginia) has the following data in a
file on disk:
.to:198.6.1.82
&yp.to:131.193.178.160
Your computer sends its question to that DNS server, and receives a response:

+--------+ network-surveys.cr.yp.to? +----------+

| Your | --------------------------> |198.6.1.82|
|computer| <------------------------ |.to server|
+--------+ &yp.to:131.193.178.160 +----------+
The response &yp.to:131.193.178.160 is another delegation. It says ``For
information about .yp.to, ask the DNS server at IP address 131.193.178.160.''

The DNS server at 131.193.178.160 (located in my office in Chicago) has the following data in a
file on disk:
.yp.to:131.193.178.160
=network-surveys.cr.yp.to:131.193.178.100
Your computer sends its question to that DNS server, and receives a response:

+--------+ network-surveys.cr.yp.to? +---------------+

| Your | ------------------------------------------> |131.193.178.160|
|computer| <------------------------------------------ | .yp.to server |
+--------+ =network-surveys.cr.yp.to:131.193.178.100 +---------------+
The response =network-surveys.cr.yp.to:131.193.178.100 finally answers the
original question: the IP address of network-surveys.cr.yp.to is 131.193.178.100.

All of this work is handled by a DNS cache running on your computer. Your computer
remembers everything that it learned (for a limited amount of time; information changes!) to
save time later. As an alternative, your computer can contact an external DNS cache operated by
your Internet service provider; the external DNS cache will do all the work and report the
answer.
Multiple servers
To protect against computer failure, there are actually several root servers, several
.to servers, and two yp.to servers. Each of the root servers has the following
information:

.:198.41.0.4:a
.:128.9.0.107:b
.:192.33.4.12:c
.:128.8.10.90:d
.:192.203.230.10:e
.:192.5.5.241:f
.:192.112.36.4:g
.:128.63.2.53:h
.:192.36.148.17:i
.:192.58.128.30:j
.:193.0.14.129:k
 .:198.32.64.12:l
.:202.12.27.33:m
&to:128.250.1.21:a
&to:193.0.0.193:b
&to:196.7.0.139:c
&to:206.184.59.10:d
&to:198.6.1.82:e
&to:206.86.247.253:f
&to:148.59.19.11:g
Each of the .to servers has the following information:

.to:128.250.1.21:a
.to:193.0.0.193:b
.to:196.7.0.139:c
.to:206.184.59.10:d
.to:198.6.1.82:e
.to:206.86.247.253:f
.to:148.59.19.11:g
&yp.to:131.193.178.181:a
&yp.to:131.193.178.160:b
# or, in BIND master zone-file format:
# yp.to IN NS a.ns.yp.to
# yp.to IN NS b.ns.yp.to
# a.ns.yp.to IN A 131.193.178.181
# b.ns.yp.to IN A 131.193.178.160
Your computer tries the root servers in a random order. When it receives a response
from some root server, it moves to the .to servers, and tries them in a random
order. It eventually receives the answer from one of the two yp.to servers.

Reverse lookups
Suppose your computer sees the IP address 208.33.217.122 and wants to know the
corresponding computer name.

Your computer asks a series of DNS servers about the name 122.217.33.208.in-addr.arpa.
The root servers have the following information:
&33.208.in-addr.arpa:206.228.179.10:c
&33.208.in-addr.arpa:144.228.254.10:b
&33.208.in-addr.arpa:144.228.255.10:a
The DNS server at IP address 144.228.254.10 has the following information:

.33.208.in-addr.arpa:144.228.255.10:a
.33.208.in-addr.arpa:206.228.179.10:c
.33.208.in-addr.arpa:144.228.254.10:b
&217.33.208.in-addr.arpa:209.191.164.20:a
&217.33.208.in-addr.arpa:206.253.194.65:b
The DNS server at IP address 209.191.164.20 has the following information:

.217.33.208.in-addr.arpa:209.191.164.20:a
.217.33.208.in-addr.arpa:206.253.194.65:b
=mm-outgoing.amazon.com:208.33.217.122
The answer is mm-outgoing.amazon.com.
Looking up the address for a name, and then the computer name for that address, doesn't
necessarily produce the original name. Looking up the computer name for an address, and then
the address for that name, doesn't necessarily produce the original address.

What is DHCP?
The Internet is a vast source of information that is continuously updated and accessed via
computers and other devices. For a device (also referred to as a host) to connect to the Internet, it
is necessary that among other configurations, it must have an Internet Protocol (IP) address. The
IP address is the computer's address on the Internet. A common comparison of an IP address is
an individual's telephone number, which is an identifier for people to communicate with the
individual. Up until the late 1980s, configuring a computer to connect to the Internet was a
manual process. The protocol Bootstrap Protocol (BOOTP) was the first Transmission Control
Protocol/Internet Protocol (TCP/IP) network configuration tool used to prevent the task of
having to manually assign IP addresses by automating the process.
While the introduction of the BOOTP network protocol was a welcome innovation for network
administrators tasked with managing large numbers of computers on a network, it was the first
attempt and a new and improved TCP/IP network protocol soon followed. This protocol is called
Dynamic Host Configuration Protocol (DHCP). DHCP was not designed as a replacement for
BOOTP, but an extension of its functionality.
How DHCP Works
As its name indicates, DHCP provides dynamic IP address assignment. What this means is that
instead of having to rely on a specific IP address, a computer will be assigned one that is
available from a subnet or "pool" that is assigned to the network. DHCP also extends BOOTP
functionality to provide IP addresses that expire. BOOTP indirectly uses a form of leasing that
never expired, but the term wasn't actually used until the introduction of DHCP. When DHCP
assigns an IP address, it actually leases the identifier to the host computer for a specific amount
of time. The default lease is five days, but a network administrator should evaluate their own
particular circumstances to determine an appropriate lease.
In basic terms, the DHCP lease process works as follows:
1. A network device attempts to connect to the Internet.
2. The network requests an IP address.
3. The DHCP server allocates (leases) the network device an IP address, which is
forwarded to the network by a router.
4. DHCP updates the appropriate network servers with the IP address and other
configuration information.
5. The network device accepts the IP address.
6. The IP address lease expires.
7. DHCP either reallocates the IP address or leases one that is available.
8. The network device is no longer connected to the Internet.
9. The IP address becomes an available address in the network pool of IP
addresses.
To set up DHCP, you basically need a DHCP-supported client (at least one) and router, and a
DHCP server. The client is a computer or other device on a network that requires an IP address
and or other network configuration information. The router functions as a forwarding (or routing)
agent of IP address requests from the DHCP server. The DHCP server is key to the entire
operation. It is responsible for allocating, leasing, reallocating, and renewing IP addresses.
Windows and Linux both support DHCP software.

Keywords: - : How does DHCP work, DHCP IP address assignment process

Reference: - nokia.com
Author: - Surender Singh
[edit] See also
Computer
networking portal

• DHCP snooping
• IP address, especially Static and dynamic IP addresses
• Peg DHCP (RFC 2322)
• Preboot Execution Environment (PXE)
• Reverse Address Resolution Protocol (RARP)
• Rogue DHCP
• udhcpc — light version for embedded systems
• Web Proxy Autodiscovery Protocol (WPAD)
• Zeroconf — Zero Configuration Networking
• UDP Helper Address — a tool for routing DHCP requests across subnet
boundaries
• Boot Service Discovery Protocol (BSDP), a DHCP extension used by Apple's
NetBoot
• BOOTP - earlier protocol for the same purpose

[edit] Notes
1. ^ The IETF proposal provided a mechanism whereby two servers could
remain loosely in sync with each other in such a way that even in the event
of a total failure of one server, the other server could recover the lease
database and continue operating. Due to the length and complexity of the
specification, it was never published as a standard; however, the techniques
described in the specification are in wide use, with one open source
implementation in the ISC DHCP server as well as several commercial
implementations.

[edit] References
1. ^ Ralph Droms; Ted Lemon (2003). The DHCP Handbook. SAMS Publishing.
p. 436. ISBN 0-672-32327-3.
 2. ^ Bill Croft; John Gilmore (September 1985). "RFC 951 - Bootstrap Protocol".
Network Working Group. http://tools.ietf.org/html/rfc951#section-6.
3. ^ In Unix-like systems this client-level refinement typically takes place
according to the values in a /etc/dhclient.conf configuration file.
4. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil,
Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol.
IETF. I-D draft-ietf-dhc-failover-12. http://tools.ietf.org/html/draft-ietf-dhc-
failover-12. Retrieved May 09, 2010.
5. ^ a b Michael Patrick (January 2001). "RFC 3046 - DHCP Relay Agent
Information Option". Network Working Group.
http://tools.ietf.org/html/rfc3046#section-7.
6. ^ a b c d Ralph Droms (March 1997). "RFC 2131 - Dynamic Host Configuration
Protocol". Network Working Group. http://tools.ietf.org/html/rfc2131#section-
7.
7. ^ Ted Lemon (April 2002). "Implementation of RFC 3118".
http://www.ietf.org/mail-archive/web/dhcwg/current/msg00876.html.

[edit] External links

• RFC 2131 - Dynamic Host Configuration Protocol
• RFC 2132 - DHCP Options and BOOTP Vendor Extensions
• DHCP RFC - Dynamic Host Configuration Protocol RFCs (IETF)
• RFC 4242 - Information Refresh Time Option for Dynamic Host Configuration
Protocol for IPv6
• DHCP Sequence Diagram - This sequence diagram covers several scenarios
of DHCP operation.
• RFC 3046, Recommended Operation for Switches Running Relay Agent and
Option 82 describes how DHCP option 82 works
• RFC 3942 - Reclassifying Dynamic Host Configuration Protocol Version Four
(DHCPv4) Options
• RFC 4361 - Node-specific Client Identifiers for Dynamic Host Configuration
Protocol Version Four (DHCPv4)
• DHCP Protocol Messages - A good description of the individual DHCP protocol
messages.
• ISC DHCP - Internet Services Consortium's open source DHCP
implementation.
• Dynamic Host Configuration Protocol (DHCP) - Microsoft TechNet
• Interactive DHCP basic simulation
Retrieved from "http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol"
Categories: Internet standards | Application layer protocols

Hidden categories: Articles lacking reliable references from April 2010 | Articles
containing how-to sections | Wikipedia articles that are too technical from
November 2010 | Articles containing potentially dated statements from 2011 | All
articles containing potentially dated statements | Articles needing more detailed
references | All articles with unsourced statements | Articles with unsourced
statements from September 2010

Personal tools
• Log in / create account
Namespaces
• Article
• Discussion
Variants
Views
• Read
• Edit
• View history
Actions
Search
Top of Form
Special:Search

Bottom of Form
Navigation
• Main page
• Contents
• Featured content
• Current events
• Random article
• Donate to Wikipedia
Interaction
• Help
• About Wikipedia
• Community portal
• Recent changes
• Contact Wikipedia
Toolbox
• What links here
• Related changes
 • Upload file
• Special pages
• Permanent link
• Cite this page
Print/export
• Create a book
• Download as PDF
• Printable version
Languages
• Afrikaans
• ‫العربية‬
• Azərbaycanca
• Boarisch
• Bosanski
• Български
• Català
• Česky
• Dansk
• Deutsch
• Eesti
• Ελληνικά
• Español
• Euskara
• ‫فارسی‬
• Français
• 한국어
• िहनदी
• Hrvatski
• Bahasa Indonesia
• Italiano
• ‫עברית‬
• Latviešu
• Magyar
• മലയാളം
• Bahasa Melayu
• Nederlands
 • 日本語
• Norsk (bokmål)
• Polski
• Português
• Română
• Русский
• Simple English
• Slovenčina
• Slovenščina
• Српски / Srpski
• Suomi
• Svenska
• தமிழ்
• ไทย
• Türkçe
• Українська
• Tiếng Việt
• Yorùbá
• 中文
•

What is an Active Directory and How Does It Work?

An active directory is a service that is provided by Microsoft that stores information about items
on a network so the information can be easily made available to specific users through a logon
process and network administrators. By using an Active Directory it is possible to view an entire
series of network objects from a single point and obtain an overall hierarchal view of the
network.
How an Active Directory Works
An Active Directory performs a variety of tasks which include providing information on objects
such as hardware and printers and services for the end users on the network such as Web email
and other applications.
 Network Objects: Network objects are anything that is associated with the
network such as a printer, end user applications, and security applications
that are implemented by the network administrator. Network objects can also
contain additional objects within their file structure which are identified by a
folder name. Each object has its own unique identification by the specific
information that is contained within the object.
  Schemas: Since network objects each have their own identification which is
also known as a characterization schema, the type of identification is the
determining factor as to how each object will be used on the network.
 Hierarchy: The hierarchal structure determines how each object can be
viewed within the hierarchy which consists of three different levels which are
known as a forest, tree, and domain with the forest being the highest level
that allows the network administrator to see all of the objects in the active
directory. The trees are the second level of the hierarchy each of which can
hold multiple domains.

How an Active Directory is Used

Active Directories are used by network administrators to simplify network maintenance
processes within a large organization. Instead of having to perform updates manually, a network
administrator can update one object in a single process.
Active Directories are also used by network administrators to allow or deny access to specific
application by the end user through the trees in the network. Additionally, they are used to keep a
large network organized and maintained without having to perform each task through an
individual process.
Because an Active Directory supports distributed network environments they can be extremely
complex and require a network administrator who is well-versed in this type of technology.
However, without an Active Directory it would be very difficult for a large organization to
effectively store information and data on a large network.
What is Active Directory?
Active Directory (AD) is a technology created by Microsoft to provide network services
including LDAP directory services, Kerberos based authentication, DNS naming, secure access
to resources, and more. Active Directory uses a single Jet database which a variety of services
and applications can use to access and store a variety of information. Active Directory is used by
system administrators to store information about users, assign security policies, and deploy
software. AD is used in many different types and size of environments from the very small (a
dozen users) to hundreds of thousands of users in a global environment.
In this tutorial, you will learn the basic structure of Active Directory, gain an understanding of
how Active Directory works, learn how to install Active Directory, and learn the components of
AD.
This tutorial is divided into these sections:
What is Active Directory: An overview of Active Directory and its use in technology
environments.
Active Directory Structure: Learn the basics of AD, its components (such as domains, domain
controllers, trust relationships, forests, organizational units, etc), hierarchies within AD, and
DNS.
How to Install Active Directory: Active Directory installation is not complex in its process, but
can be difficult in the future if you do not plan the installation correctly. Learn the tricks and tips
you need to know to properly plan an AD installation and why administrators install AD the way
they do.
This free Active Directory tutorial is not a comprehensive one on the topic, but an introduction to
Active Directory and its structure and use.

Active Directory
From Wikipedia, the free encyclopedia

Jump to: navigation, search

Active Directory (AD) is a directory service created by Microsoft.

Active Directory uses a number of standardized protocols to provide a variety of network
services, including:
• Lightweight Directory Access Protocol LDAP, the industry standard directory
access protocol, compatible with many management and query applications.
Active Directory supports LDAPv3 and LDAPv2.
• Optional Kerberos-based authentication
• DNS-based naming and other network information
Features include:
 • Central location for network administration and security[1]
• Information security and single sign-on for user access to networked
resources[1]
• The ability to scale up or down easily[1]
• Standardizing access to application data[1]
• Synchronization of directory updates across servers[1]
Active Directory stores all information and settings for a deployment in a central database.
Active Directory allows administrators to assign policies, deploy and update software. Active
Directory networks can vary from a small installation with a few computers, users and printers to
tens of thousands of users, many different network domains and large server farms spanning
many geographical locations.

Contents
[hide]
• 1 History
• 2 Structure
○ 2.1 Objects
 2.1.1 Sites
○ 2.2 Forests, trees, and domains
 2.2.1 Organizational units
 2.2.1.1 Shadow groups
• 3 Physical matters
• 4 Replication
• 5 Database
• 6 Programmatic interface
• 7 Single server operations
• 8 Trust
○ 8.1 Terminology
• 9 Lightweight Directory Services
• 10 Unix integration
• 11 See also
• 12 Notes
• 13 External links

[edit] History
Active Directory was previewed in 1999, released first with Windows 2000 Server edition, and
revised to extend functionality and improve administration in Windows Server 2003. Additional
improvements were made in Windows Server 2003 R2, Windows Server 2008 and Windows
Server 2008 R2 and was renamed Active Directory Domain Services.
Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This
name can still be seen in some Active Directory binaries.
[edit] Structure
[edit] Objects
An Active Directory structure is a hierarchical arrangement of information about objects. The
objects fall into two broad categories: resources (e.g., printers) and security principals (user or
computer accounts and groups). Security principals are assigned unique security identifiers
(SIDs).
Each object represents a single entity—whether a user, a computer, a printer, or a group—and its
attributes. Certain objects can contain other objects. An object is uniquely identified by its name
and has a set of attributes—the characteristics and information that the object represents—
defined by a schema, which also determines the kinds of objects that can be stored in Active
Directory.
Each attribute object can be used to define multiple schema objects. The schema object allows
the schema to be extended or modified when necessary. However, because each schema object is
integral to the definition of Active Directory objects, deactivating or changing these objects can
fundamentally change and/or disrupt a deployment. Schema changes automatically propagate
throughout the system. Once created, an object can only be deactivated—not deleted. Changing
the schema usually requires planning.[2]
[edit] Sites
A Site object in Active Directory represents a geographic location that hosts networks. Sites
contain objects called subnets.[3]
[edit] Forests, trees, and domains
The Active Directory framework that holds the objects can be viewed at a number of levels. The
forest, tree, and domain are the logical divisions in an Active Directory network.
Within a deployment, objects are grouped into domains. The objects for a single domain are
stored in a single database (which can be replicated). Domains are identified by their DNS name
structure, the namespace.
A tree is a collection of one or more domains and domain trees in a contiguous namespace,
linked in a transitive trust hierarchy.
At the top of the structure is the forest. A forest is a collection of trees that share a common
global catalog, directory schema, logical structure, and directory configuration. The forest
represents the security boundary within which users, computers, groups, and other objects are
accessible.
Forest- Domain-Dallas
WidgetsCorp
OU-
Tree-Eastern Marketing

Domain- Hewitt
Boston
 Domain- Aon
NewYork

Domain- Steve
Philly
OU-Sales
Tree-Southern

Bill
Domain-
Atlanta
Ralph
Domain-
Dallas

Example of the geographical organizing of

zones of interest within trees and
domains.

[edit] Organizational units

The objects held within a domain can be grouped into Organizational Units (OUs).[4] OUs can
provide hierarchy to a domain, ease its administration, and can resemble the organization's
structure in managerial or geographical terms. OUs can contain other OUs—domains are
containers in this sense. Microsoft recommends using OUs rather than domains for structure and
to simplify the implementation of policies and administration. The OU is the recommended level
at which to apply group policies, which are Active Directory objects formally named Group
Policy Objects (GPOs), although policies can also be applied to domains or sites (see below).
The OU is the level at which administrative powers are commonly delegated, but delegation can
be performed on individual objects or attributes as well.
Organizational Units are an abstraction for the administrator and do not function as containers;
the underlying domain is the true container. It is not possible, for example, to create user
accounts with an identical username (sAMAccountName) in separate OUs, such as "fred.staff-
ou.domain" and "fred.student-ou.domain", where "staff-ou" and "student-ou" are the OUs. This
is so because sAMAccountName, a user object attribute, must be unique within the domain.
As the number of users in a domain increases, conventions such as "first initial, middle initial,
last name" will fail for common names like Smith, "Garcia" or Lee. Workarounds include adding
a digit to the end of the username or using the unique employee/student id number.
Because duplicate usernames cannot exist within a domain, account name generation poses a
significant challenge for large organizations that can not be easily subdivided into separate
domains, such as students in a public school system or university who must be able to use any
computer across the network.
[edit] Shadow groups
In Active Directory, organizational units cannot be assigned as owners or trustees.
Only groups are selectable, and members of OUs can not be collectively assigned
rights to directory objects.

OUs do not carry access rights. A common practice is to employ scripts to create and maintain a
user group for each OU. The scripts are run periodically to update the group to match the OU's
membership. Such groups are known as Shadow Groups. Microsoft refers to shadow groups in
the Server 2008 Reference documentation.[5] Once created, these shadow groups are selectable in
place of the OU in the administrative tools.
The naming of shadow groups is complicated by the fact that OUs can be nested but groups
cannot. Groups can only exist in the root of the domain, and group names are limited in length so
matching the naming of a deeply nested string of OUs for a very large domain is problematic.
The division of an organization's information infrastructure into a hierarchy of one or more
domains and top-level OUs is a key decision. Common models are by business unit, by
geographical location, by IT Service, or by object type and hybrids of these. OUs should be
structured primarily to facilitate administrative delegation, and secondarily, to facilitate group
policy application. Although OUs form an administrative boundary, the only true security
boundary is the forest itself and an administrator of any domain in the forest must be trusted
across all domains in the forest.[6]
[edit] Physical matters
Sites are physical, rather than logical, groupings defined by one or more IP subnets.[7] AD also
holds the definitions of connections, distinguishing low-speed (e.g., WAN, VPN) from high-
speed (e.g., LAN) links. Site definitions are independent of the domain and OU structure and are
common across the forest. Sites are used to control network traffic generated by replication and
also to refer clients to the nearest domain controllers. Microsoft Exchange Server 2007 uses the
site topology for mail routing. Policies can also be defined at the site level.
Physically the Active Directory information is held on one or more peer domain controllers
(DCs), replacing the NT PDC/BDC model. Each DC has a copy of the Active Directory. Servers
joined to Active Directory that are not domain controllers are called Member Servers.[8]
The Active Directory database is organized in partitions, each holding specific object types and
following a specific replication pattern. AD synchronizes changes using multi-master
replication.[9] Microsoft often refers to these partitions as 'naming contexts'.[10] The 'Schema'
partition contains the definition of object classes and attributes within the Forest. The
'Configuration' partition contains information on the physical structure and configuration of the
forest (such as the site topology). Both replicate to all domain controllers in the Forest. The
'Domain' partition holds all objects created in that domain and replicates only to Domain
Controllers within its domain. So, for example, a user created in Domain A would be listed only
in Domain A's domain controllers. A subset of objects in the domain partition replicate to
domain controllers that are configured as global catalogs. Global catalog (GC) servers provide a
global listing of all objects in the Forest.[11] Global Catalog servers replicate to themselves all
objects from all domains and hence, provide a global listing of objects in the forest. However, in
order to minimize replication traffic and to keep the GC's database small, only selected attributes
of each object are replicated. This is called the partial attribute set (PAS). The PAS can be
modified by modifying the schema and marking attributes for replication to the GC.[12] Earlier
versions of Windows used NetBIOS to communicate. Active Directory is fully integrated with
DNS and requires TCP/IP—DNS. To be fully functional, the DNS server must support SRV
resource records or service records. ..
[edit] Replication
Active Directory replication is 'pull' rather than 'push', meaning that replicas pull changes from
the server where the change was effected.[13] The Knowledge Consistency Checker (KCC) creates
a replication topology of site links using the defined sites to manage traffic. Intrasite replication
is frequent and automatic as a result of change notification, which triggers peers to begin a pull
replication cycle. Intersite replication intervals are typically less frequent and do not use change
notification by default, although this is configurable and can be made identical to intrasite
replication.
Each link can have a 'cost' (e.g., DS3, T1, ISDN etc.) and the site link topology will be altered
accordingly by the KCC. Replication may occur transitively through several site links on same-
protocol site link bridges, if the cost is low, although KCC automatically costs a direct site-to-
site link lower than transitive connections. Site-to-site replication can be configured to occur
between a bridgehead server in each site, which then replicates the changes to other DCs within
the site.
Replication of Active Directory uses Remote Procedure Calls (RPC) over IP (RPC/IP). Between
Sites you can use SMTP for replication, but only for changes in the Schema, Configuration, or
Partial Attribute Set (Global Catalog) NCs. SMTP cannot be used for replicating the default
Domain partition.[14]
[edit] Database
The Active Directory database, the directory store, in Windows 2000 Server uses the JET Blue-
based Extensible Storage Engine (ESE98) and is limited to 16 terabytes and 2 billion objects (but
only 1 billion security principals) in each domain controller's database. Microsoft has created
NTDS databases with more than 2 billion objects.[15] (NT4's Security Account Manager could
support no more than 40,000 objects). Called NTDS.DIT, it has two main tables: the data table
and the link table. In Windows Server 2003 a third main table was added for security descriptor
single instancing.[16]
[edit] Programmatic interface
The features of Active Directory may be accessed programmatically via the COM interfaces
provided by Active Directory Service Interfaces.[17]
[edit] Single server operations
Flexible Single Master Operations (FSMO, sometimes pronounced "fizz-mo") operations are
also known as operations master roles. Although domain controllers operate allow simultaneous
updates in multiple places, certain operations are supported only on a single server. These
operations are performed using the roles listed below:
Role Name Scope Description

Schema
1 per forest Schema modifications
Master

Domain
Addition and removal of domains if present in root
Naming 1 per forest
domain
Master

Provides backwards compatibility for NT4 clients for PDC

operations (like password changes). The PDC runs
domain specific processes such as the Security
PDC
1 per domain Descriptor Propagator (SDPROP), and is the master time
Emulator
server within the domain. It also handles external trusts,
the DFS consistency check, holds current passwords and
manages all GPOs as default server.

Allocates pools of unique identifiers to domain

RID Master 1 per domain
controllers for use when creating objects

Synchronizes cross-domain group membership changes.

1 per
Infrastructur The infrastructure master cannot run on a global catalog
domain/partiti
e Master server (GCS)(unless all DCs are also GCs, or
on
environment consists of a single domain.

[edit] Trust
To allow users in one domain to access resources in another, Active Directory uses trusts.[18]
Trusts inside a forest are automatically created when domains are created. The forest sets the
default boundaries of trust, and implicit, transitive trust is automatic for all domains within a
forest.
[edit] Terminology
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 allow 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
forest.

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.

Shortcut

Joins two domains in different trees, transitive, one- or two-way

Forest

Applies to the entire forest. Transitive, one- or two-way

Realm

Can be transitive or nontransitive, one- or two-way

External

Connect to other forests or non-AD domains. Nontransitive, one- or two-way.

[19]

Windows 2000 Server supports two-way transitive and one-way intransitive trusts.
Administrators can create shortcuts.
Windows Server 2003 the forest root trust. This trust can be used to connect Windows Server
2003 forests if they are operating at the 2003 forest functional level. Authentication across this
type of trust is Kerberos based (as opposed to NTLM). Forest trusts are transitive for all the
domains in the trusted forests. Forest trusts, however, are not transitive.
[edit] Lightweight Directory Services
AD LDS is a light-weight implementation of Active Directory. LDS is capable of running as a
service on computers running Microsoft Windows Server 2003 or Windows XP Professional.
LDS shares the code base with Active Directory and provides the same functionality as Active
Directory, including an identical API, but does not require the creation of domains or domain
controllers.
Like Active Directory, LDS provides a Data Store for storage of directory data and a Directory
Service with an LDAP Directory Service Interface. Unlike Active Directory, however, multiple
LDS instances can be run on the same server.
Before Windows Server 2008, LDS was named Active Directory Application Mode (ADAM).[20]
[edit] Unix integration
Varying levels of interoperability with Active Directory can be achieved on most Unix-like
operating systems through standards-compliant LDAP clients, but these systems usually do not
interpret many attributes associated with Windows components, such as Group Policy and
support for one-way trusts.
Third-parties offer Active Directory integration for Unix platforms (including UNIX, Linux,
Mac OS X, and a number of Java- and UNIX-based applications), including Centrify
(DirectControl), Computer Associates (UNAB), CyberSafe Limited (TrustBroker), Likewise
Software (Open or Enterprise), Quest Software (Authentication Services) Thursby Software
Systems (ADmitMac) and open source software Samba can act as a peer Active Directory
domain controller.[21][22]
The schema additions shipped with Windows Server 2003 R2 include attributes that map closely
enough to RFC| 2307 to be generally usable. The reference implementation of RFC 2307,
nss_ldap and pam_ldap provided by PADL.com, support these attributes directly. The default
schema for group membership complies with RFC 2307bis (proposed).[23] Windows Server 2003
R2 includes a Microsoft Management Console snap-in that creates and edits the attributes.
An alternate option is to use another directory service such as 389 Directory Server (formerly
Fedora Directory Server, FDS) or Sun Microsystems Sun Java System Directory Server, which
can perform two-way synchronization with AD and thus provide a "deflected" integration, as
Unix and Linux clients authenticate to FDS and Windows Clients authenticate to AD. Another
option is to use OpenLDAP with its translucent overlay, which can extend entries in any remote
LDAP server with additional attributes stored in a local database. Clients pointed at the local
database see entries containing both the remote and local attributes, while the remote database
remains completely untouched.[citation needed]
Active Directory can be automated[clarification needed] by Powershell.[citation needed]
[edit] See also
• FreeIPA
• Active Directory Explorer
• Directory Services Restore Mode
• Flexible single master operation
• List of LDAP software
 • AGDLP (implementing role based access controls using nested groups)

[edit] Notes
1. ^ a b c d e "Active Directory on a Windows Server 2003 Network". Active
Directory Collection. March 13, 2003. http://technet.microsoft.com/en-
us/library/cc780036(WS.10).aspx#w2k3tr_ad_over_qbjd. Retrieved December
25, 2010.
2. ^ Windows Server 2003: Active Directory Infrastructure. Microsoft Press.
2003. pp. 1–8 – 1–9. ISBN 0-7356-1438-5.
3. ^ "Managing Sites". Microsoft Corporation. http://technet.microsoft.com/en-
us/library/bb727051.aspx. "An Active Directory site object represents a
collection of Internet Protocol (IP) subnets, usually constituting a physical
Local Area Network (LAN)."
4. ^ "Organizational Units". Microsoft Corporation. 2010. "An organizational unit
in Active Directory is analogous to a directory in the file system"
5. ^ Microsoft Server 2008 Reference refers to "shadow groups" but does not
explain how to create them. http://technet.microsoft.com/en-
us/library/cc770394%28WS.10%29.aspx
6. ^ "Specifying Security and Administrative Boundaries". Microsoft Corporation.
2005-01-23. http://technet.microsoft.com/en-
us/library/cc755979(WS.10).aspx. "However, service administrators have
abilities that cross domain boundaries. For this reason, the forest is the
ultimate security boundary, not the domain."
7. ^ "Sites overview". Microsoft Corporation. 2005-01-21.
http://technet.microsoft.com/en-us/library/cc782048(WS.10).aspx. "A site is a
set of well-connected subnets."
8. ^ "Planning for domain controllers and member servers". Microsoft
Corporation. 2005-01-21. http://technet.microsoft.com/en-
us/library/cc737059(WS.10).aspx. "[...] member servers, [...] belong to a
domain but do not contain a copy of the Active Directory data."
9. ^ "Directory data store". Microsoft Corporation. 2005-01-21.
http://technet.microsoft.com/en-us/library/cc736627(WS.10).aspx. "Active
Directory uses four distinct directory partition types to store [...] data.
Directory partitions contain domain, configuration, schema, and application
data."
10.^ Andreas Luther. "Active Directory Replication Traffic". Microsoft
Corporation. http://technet.microsoft.com/en-us/library/bb742457.aspx.
Retrieved 2010-05-26. "The Active Directory is made up of one or more
naming contexts or partitions."
11.^ "What Is the Global Catalog?". Microsoft Corporation. 2009-12-10.
http://technet.microsoft.com/en-us/library/cc728188(WS.10).aspx. "[...] a
domain controller can locate only the objects in its domain. [...] The global
catalog provides the ability to locate objects from any domain [...]"
12.^ "Attributes Included in the Global Catalog". Microsoft Corporation. 2010-08-
26. http://msdn.microsoft.com/en-us/library/ms675160%28VS.85%29.aspx.
 "The isMemberOfPartialAttributeSet attribute of an attributeSchema object is
set to TRUE if the attribute is replicated to the global catalog. [...] When
deciding whether or not to place an attribute in the global catalog remember
that you are trading increased replication and increased disk storage on
global catalog servers for, potentially, faster query performance."
13.^ "What Is the Active Directory Replication Model?". Microsoft Corporation.
2003-03-28. http://technet.microsoft.com/en-
us/library/cc737314(WS.10).aspx. "Domain controllers request (pull) changes
rather than send (push) changes that might not be needed."
14.^ "What Is Active Directory Replication Topology?". Microsoft Corporation.
2003-03-28. http://technet.microsoft.com/en-
us/library/cc775549(WS.10).aspx. "SMTP can be used to transport nondomain
replication [...]"
15.^ Large AD database? Probably not this large...
16.^ Large AD database? Probably not this large...
17.^ Active Directory Service Interfaces, Microsoft
18.^ "Domain and Forest Trusts Technical Reference". Microsoft Corporation.
2003-03-28. http://technet.microsoft.com/en-
us/library/cc738955(WS.10).aspx. "Trusts enable [...] authentication and [...]
sharing resources across domains or forests"
19.^ "How Domain and Forest Trusts Work". Microsoft Corporation. 2006-06-03.
http://technet.microsoft.com/en-us/library/cc773178(WS.10).aspx. Retrieved
2010-06-01. "Defines several kinds of trusts. (automatic, shortcut, forest,
realm, external)"
20.^ "AD LDS". Microsoft. http://msdn.microsoft.com/en-
us/library/aa705886(VS.85).aspx. Retrieved 2009-04-28.
21.^ "Samba4/Releases/4.0.0alpha13". SambaPeople. SAMBA Project.
http://wiki.samba.org/index.php/Samba4/Releases/4.0.0alpha13. Retrieved
2010-11-29.
22.^ "The great DRS success!". SambaPeople. SAMBA Project. 2009-10-05.
http://people.samba.org/people/2009/10/05#drs-success. Retrieved 2009-11-
02.
23.^ RFC 2307bis

[edit]

Understanding Active Directory replication

By Brien M. Posey MCSE

February 16, 2001, 8:00am PST

Recommend

0 Votes
3 Comments

Share

more +

• Email
• Print
• Add to Favorites
• Del.icio.us
• Digg
• Facebook
• Google Buzz
• Hacker News
• LinkedIn
• Reddit
• StumbleUpon
• Technorati
• Twitter

If you’ve worked much with Windows 2000, you know just how important Active
Directory can be. Active Directory stores everything from network security
information to basic contact information for network users. As with any database of
such importance, Active Directory is subject to constant updates. Normally, rapid
database updates aren’t a problem. What makes Active Directory updates so
special is that unlike a conventional database, Active Directory isn’t stored in a
single location. Instead, it’s distributed across all of your domain controllers.
Therefore, Windows 2000 must be able to keep track of any database changes,
regardless of which server the change was made on. The process by which Windows
keeps track of these changes is called replication. In this Daily Drill Down, I’ll
discuss the concepts involved in Active Directory replication.

The multimaster model

If you’ve done much networking with Windows NT, you’re probably at least vaguely
familiar with the concept of replication. As with Windows 2000, Windows NT offers
the possibility of having multiple domain controllers in each domain. However,
Windows NT uses a much simpler replication model than Windows 2000 uses. In
Windows NT, any changes to the Security Accounts Manager (SAM) database can
occur only on the primary domain controller. Therefore, when an administrator
makes a change to an account, the change is always applied directly to the primary
domain controller, regardless of how many domain controllers actually exist on the
system.
Keep in mind that in Windows NT, each domain controller maintains a copy of the
SAM database. This copy allows any domain controller to authenticate users.
Because each domain controller contains an independent copy of the SAM
database, the copy must be updated to match changes that occur to the primary
domain controller’s copy.

To avoid overwhelming the backup domain controllers, which may already be busy
with other tasks, the primary domain controller doesn’t automatically push the
database modifications onto the backup domain controllers. Instead, the primary
domain controller simply alerts each backup domain controller to the fact that a
change has occurred. When the backup domain controllers have some idle time,
they each contact the primary domain controller and request that the changes be
replicated to them.

Windows 2000, on the other hand, uses a much more complicated replication model
called multimaster replication. In multimaster replication, any time an administrator
makes a change to Active Directory, the change can be applied directly to any
domain controller. Remember that in Windows 2000, there’s no such thing as a
primary domain controller or a backup domain controller. Instead, a server is either
a domain controller or a non-domain controller. As such, all domain controllers in
Windows 2000 are treated equally.

Given the variety of types of information that Active Directory can store, it’s easy to
see just how fast changes to Active Directory can accumulate across multiple
domain controllers in a large organization. It’s therefore necessary for Windows to
frequently synchronize the domain controllers through the replication process.

Windows 2000 accomplishes this task in a method similar to the one used by
Windows NT, with the obvious exceptions I’ve already discussed. When an
administrator makes a change that affects a domain controller’s copy of Active
Directory, the domain controller sends a notice to the other domain controllers
about the change. The other domain controllers may then request a copy of the
changes when they have idle time. Because several domain controllers may be
replicating changes at any given time, each Active Directory change is time-
stamped. This allows Windows 2000 to know which change should take precedence
in the event that contradictory changes are made within a replication cycle.

As you can imagine, the Active Directory replication process can cause considerable
network traffic when large numbers of domain controllers exist within an
organization. In a large organization, dozens of domain controllers could potentially
be replicating hundreds of Active Directory changes at any given time. This can
cause some serious congestion problems, especially on networks that are already
bogged down with excessive traffic. Replication-related network traffic can also
cause problems by bogging down wide area network (WAN) links. Fortunately,
Windows 2000 provides an Active Directory structure that you can use to reduce
the replication-related network traffic. This structure is called a site.

Intersite Active Directory replication

If your background consists primarily of working on Windows NT Servers, the
concept of sites may be new to you. You’re probably familiar with sites only if
you’ve used Exchange Server. Even so, sites created by Exchange Server are
somewhat different from sites created by Windows 2000.

So what’s a site? To put it simply, a site is a collection of domain controllers.

Typically, these domain controllers service a common group of users. To understand
why dividing a network into sites is effective, you must first understand something
about the nature of Active Directory.

As you probably already know, Active Directory is divided into all sorts of structures,
such as domains, trees, and forests. All of these structures fall under the
organization’s root level. This means that every domain controller in every level of
the organization must share Active Directory information to some extent.

For example, consider an organization that contains two domains. Even if those two
domains have almost nothing to do with each other, they share a common Active
Directory and must therefore replicate Active Directory updates between
themselves on a regular basis.

Earlier I explained how the Active Directory replication process works. In that
explanation, any Active Directory changes were replicated across the entire
organization on an as-needed basis. If a change was made to a domain controller,
the domain controller saw the need to replicate the change to every other domain
controller in the entire organization just as soon as the other domain controllers
became available.

Given the examples and explanations I’ve presented so far, you might assume that
if two domains or other organizational structures don’t have anything to do with
each other, then there’s really no need to replicate updates between them. Nothing
could be further from the truth. Your domain controllers must replicate changes
with one another to maintain Active Directory’s consistency and integrity. However,
just because you have to replicate Active Directory updates between unrelated
organizational structures, it doesn’t mean that the replication has to occur
immediately. The advantage to creating sites is that you can replicate Active
Directory changes between the sites on a scheduled basis rather than on an as-
needed basis.

Scheduling replication can greatly reduce network traffic and can relieve a
tremendous burden from WAN links. I mentioned earlier that sites were nothing
more than a collection of domain controllers that serve a common group of users.
The idea is that users within these groups need to know about Active Directory
updates that are directly related to them more quickly than they would need to
know about Active Directory updates that relate to a different office, department, or
company.

Sites are very flexible. I mentioned that a site is a collection of domain controllers
that serve a common group of users, so you may have assumed that a site exists at
the same level as a domain. However, this simply isn’t true. You can have multiple
sites within a single domain, or you can make each domain an individual site. Other
than some general guidelines, no firm rules exist governing how sites should be
implemented.

When should I implement sites?

In spite of Windows 2000’s loose control over how you implement sites, some
situations are much more appropriate for implementing sites than others. One
situation in which you’d almost always want to implement a site would be the case
of a domain spread across a WAN link. Suppose for a moment that you work for a
company that has two local offices connected by a WAN link. Now imagine that the
idiot who you inherited the network from got the bright idea to use a single domain
to cover both buildings. You could greatly improve the network’s efficiency by
setting up each building as an individual site.

The first step you’d take in such an arrangement would be to make sure that each
building has at least one domain controller. Remember that sites require domain
controllers. Even if you weren’t dividing the network into sites, it would still be a
good idea to have at least one domain controller in each building so that users in
each building could authenticate locally. After all, you don’t want to congest your
WAN link with authentication traffic.

Now, consider the reason for and the results of separating the two buildings into
individual sites. There’s a good chance that the users in each building work more
closely with one another than they do with users in the other office. Therefore, an
Active Directory change in building A would more likely affect the users in building A
than the users in building B. Because of this, you’d want to make sure that Active
Directory updates within each building continue to be replicated on an as-needed
basis. You still have to replicate the changes over to the other building but doing so
isn’t as time sensitive as replicating the update within the original building.
Therefore, you can update the other building on a scheduled basis.

You can allow Active Directory updates to accumulate for several hours before
replicating them to the other building. This means your WAN link will receive only
the occasional burst of strategically timed replication traffic rather than the
constant bombardment of traffic it would otherwise be subjected to.

I recommend timing the intersite replications to correspond with low periods of

network traffic, such as during lunch or after people start going home for the day.
Of course, if an important update is made to Active Directory, the administrator can
always force an immediate replication.

Now, suppose your entire company shares a single building. It’s still possible (and
often a good idea) to implement sites, even though no WAN link is present. You can
create a separate site for each department. Doing so can drastically cut down on
the replication-related network traffic in your organization.

How do sites work?

Now that you know what a site is, let’s take a brief look at how sites work. As you’ve
probably already figured out, the domain controllers that exist within a site continue
to replicate with one another on an as-needed basis. Only one domain controller in
each site is responsible for replicating changes with other sites, however. This
domain controller is known as the bridgehead server.

Replication occurs on an as-needed basis among the domain controllers within each
site. When it comes time for sites to replicate with one another, each site's
bridgehead server forwards all of the changes that have occurred since the last
replication cycle to the remote site's bridgehead server. When the bridgehead
server in the remote site receives the changes, it replicates those changes to the
other domain controllers within the site.

Conclusion
In this Daily Drill Down, I explained the process by which Active Directory changes
are replicated between domain controllers. I also discussed why it’s sometimes
necessary to reduce replication-related network traffic by dividing Active Directory
into multiple sites.
The authors and editors have taken care in preparation of the content contained
herein but make no expressed or implied warranty of any kind and assume no
responsibility for errors or omissions. No liability is assumed for any damages.
Always have a verified backup before making any changes.