Escolar Documentos
Profissional Documentos
Cultura Documentos
Naam:
Klas:
Datum:
Binnen de ICT is Engels de meest gebruikte taal. Vandaar dat het noodzakelijk is dat
je begrijpt wat je leest in het Engels.
Het verschil tussen een vertaling en een opsomming is dat een vertaling veel uitgebreider is.
Opdrachtdoel
Voor het project summary and translation is het de bedoeling dat je deel 1 vertaalt naar het
Nederlands. In Deel 2 maak je een opsomming (summary) in het Engels. In Deel 3 maak je
een opsomming in het Nederlands.
Product
Rapportage
Fase I
Fase II
Fase III
Fase IV
1. Projectblad
2. Woordenboek Engels - Nederlands. Dit kan een papieren versie zijn, maar ook op het
Internet kun je er verscheidene vinden. Typ bijvoorbeeld in het zoekvak van de
zoekmachine Google de trefwoorden woordenboek nederlands engels
3. Automatiseringswoordenboek.
Competenties
Proces
N.V.T.
Beoordeling
Wanneer je onderstaande punten hanteert kan je dit project met een voldoende afsluiten:
DEEL 1
How Domain Name Servers Work
by Marshall Brain
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
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:
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.
Creating a New Domain Name
When someone wants to create a new domain, he or she has to do two things:
The history of HowStuffWorks is typical. When howstuffworks.com was first created, it began as a
parked domain. This domain lived with a company called www.webhosting.com. Webhosting.com
maintained the name server and also maintained a machine that created the single "under
construction" page for the domain.
To create a domain, you fill out a form with a company that does domain name registration
(examples: register.com, verio.com, networksolutions.com). They create an "under construction
mail A 209.170.137.42
vip1 A 216.183.103.150
www CNAME vip1
Decoding this file from the top, you can see that:
The first two lines point to the primary and secondary name servers.
The next line is called the MX record. When you send e-mail to anyone at
howstuffworks.com, the piece of software sending the e-mail contacts the name server to get the
MX record so it knows where the SMTP server for HowStuffWorks is (see How E-mail Works for
details). Many larger systems have multiple machines handling incoming e-mail, and therefore
multiple MX records.
The next line points to the machine that will handle a request to mail.howstuffworks.com.
The next line points to the IP address that will handle a request to oak.howstuffworks.com.
The next line points to the IP address that will handle a request to howstuffworks.com (no
host name).
You can see from this file that there are several physical machines at separate IP addresses that make
up the HowStuffWorks server infrastructure. There are aliases for hosts like mail and www. There can
be aliases for anything. For example, there could be an entry in this file for
scoobydoo.howstuffworks.com, and it could point to the physical machine called walnut. There
could be an alias for yahoo.howstuffworks.com, and it could point to yahoo. There really is no limit
to it. We could also create multiple name servers and segment our domain.
As you can see from this description, DNS is a rather amazing distributed database. It handles billions
of requests for billions of names every day through a network of millions of name servers
administered by millions of people. Every time you send an e-mail message or view a URL, you are
In home networking, these DNS options are sometimes useful for advanced troubleshooting. If the
information in your DNS cache becomes corrupted or outdated, you could face difficulty accessing
certain sites on the Internet. Consider these two scenarios:
The IP address of a Web site, email server or other server changes (rare occurence). The name
and address of this site normally stay in your cache for 24 hours after your last visit. You may
need to clear your cache to access the server sooner.
ipconfig /registerdns
Similar to the above options, this option updates DNS settings on the Windows computer. Instead of
merely accessing the local DNS cache, however, this option initiates communication with both the
DNS server (and the DHCP server) to re-register with them.
This option is useful in troubleshooting problems involving connection with the Internet service
provider, such as failure to obtain a dynamic IP address or failure to connect to the ISP DNS server.
Like the /release and /renew options, /registerdns optionally takes the name(s) of specific adapters
to update. If no name parameter is specified, /registerdns updates all adapters.
Note
It is necessary to have an understanding of basic TCP/IP concepts, including working knowledge of
subnets before you can have a full understanding of DHCP. For more information about TCP/IP, see
“TCP/IP Technical Reference.”
In this section
DHCP Architecture
DHCP Protocols
DHCP Processes and Interactions
DHCP Architecture
The DHCP architecture consists of DHCP clients, DHCP servers, and DHCP relay agents on a network.
The clients interact with servers using DHCP messages in a DHCP conversation to obtain and renew IP
address leases.
DHCP provides support for client computers running any of the following Microsoft operating
systems:
Windows NT version 4.0
Windows 2000
Windows XP
Windows Server 2003
Windows 98
Windows Millennium Edition
Automatic IP Configuration
DHCP supports Automatic Private IP Addressing (APIPA), which enables computers running
Windows 2000, Windows XP, and Windows Server 2003 to configure an IP address and subnet mask
if a DHCP server is unavailable at system startup and the Automatic private IP address Alternate
Configuration setting is selected. This feature is useful for clients on small private networks, such as a
small-business office or a home office.
The DHCP Client service on a computer running Windows XP and Windows Server 2003 uses the
following process to auto-configure the client:
1. The DHCP client attempts to locate a DHCP server and obtain an IP address and
configuration.
2. If a DHCP server cannot be found or does not respond after one minute, the DHCP client
checks the settings on the Alternate Configuration tab of the properties of the TCP/IP
protocol.
If Automatic private IP address is selected, the DHCP client auto-configures its IP address
and subnet mask by using a selected address from the Microsoft-reserved Class B network,
169.254.0.0, with the subnet mask 255.255.0.0. The DHCP client tests for an address conflict
to ensure that the IP address is not in use on the network. If a conflict is found, the client
selects another IP address. The client retries auto-configuration up to 10 times.
If User Configured is selected, the DHCP client configures a static IP address configuration.
The DHCP client tests for an address conflict to ensure that the IP address is not already in
If the ping is successful, the DHCP client assumes that it is still located on the same network
where it obtained its current lease, and continues to use the lease as long as the lease is still
valid. By default the client then attempts, in the background, to renew its lease when 50
percent of its assigned lease time has expired.
If the ping fails, the DHCP client assumes that it has been moved to a network where a DHCP
server is not available. The client then auto-configures its IP address by using the settings on
the Alternate Configuration tab. When the client is auto-configured, it attempts to locate a
DHCP server and obtain a lease every five minutes.
Local Storage
Windows Server 2003 DHCP supports local storage, which allows clients to store DHCP information
on their own hard disks. Local storage is useful because it enables the client to store its last leased IP
address, so that when the client starts it first attempts to renew the lease of its previous IP address.
Local storage also enables a client to be shut down and restarted and it will use its previously leased
address and configuration, even if the DHCP server is unreachable or offline at the time that the
client computer is restarted.
Scopes
A scope must be properly defined and activated before DHCP clients can use the DHCP server for
automatic TCP/IP configuration. A DHCP scope is an administrative collection of IP addresses and
TCP/IP configuration parameters that are available for lease to DHCP clients of a specific subnet. The
network administrator creates a scope for each subnet.
Lease Durations
When a scope is created, the lease duration is set to eight days by default. However there are
situations when the administrator might want to change the lease duration. The following are
examples of adjusting the lease duration due to individual network consideration:
An organization has a large number of IP addresses available and configurations that rarely
change. The administrator increases the lease duration to reduce the frequency of lease
renewal exchanges between clients and the DHCP server. Because the DHCP clients are
renewing their leases less frequently, DHCP-related network traffic is reduced.
A limited number of IP addresses are available and client configurations change frequently or
clients move often in or out of the network. The administrator reduces the lease duration.
This increases the rate at which unused addresses are returned to the available address pool
for reassignment.
For example, consider the ratio between connected computers and available IP addresses. If 40
computers share 254 available addresses, the demand for reusing addresses is low. A long lease time,
such as a few months, might be appropriate in such a situation. However, if 230 computers must
share the same address pool, demand for available addresses is greater, and a shorter lease time, for
example a few days, is more appropriate.
Note
Although it is possible to configure a client with infinite lease duration, use infinite lease
durations with caution. Even relatively stable environments have a certain amount of client
turnover. At a minimum, computers might be added and removed, moved from one office to
another, or network adapters might be replaced. If a client with an infinite lease is removed
from the network without releasing its lease, the DHCP server is not notified, and the IP
Exclusion Ranges
When you create a new scope, immediately exclude the addresses of existing statically configured
computers from the scope. By using exclusion ranges, you can exclude specific IP address ranges
within a scope so that those addresses are not offered to clients. Assign IP addresses within exclusion
ranges to computers or devices that must have a static IP address, such as servers, firewalls, or
routers.
You can use excluded IP addresses on your network by manually configuring these addresses at
computers that do not use DHCP to obtain an address, or by configuring reservations for these
addresses.
Reservations
You can reserve IP addresses for assignment to specified computers or devices on the network.
Reservations ensure that a specified hardware device on a subnet always receives the same IP
address lease. Use reservations for DHCP-enabled devices that must always have the same IP address
on your network, such as servers that do not support Domain Name System (DNS) dynamic update.
Note
If multiple DHCP servers are each configured with scopes that cover addresses that must be
reserved, the reservations must be specified on each DHCP server. Otherwise, the client
might receive an IP address from one of the DHCP servers that does not contain the
reservation, and therefore might not receive the IP address reserved for the client.
Support is needed for DHCP clients on a single physical network segment — such as a single
Ethernet LAN segment — where multiple logical IP networks are used. When more than one
logical IP network is used on a physical network, these configurations are also known as
multinets. In a situation where multinets are used, clients might not be able to communicate
directly with each other, because the clients might be on different logical subnets, even if
they are on the same physical network segment. In this case, routing must be enabled to
allow the clients to communicate with each other. Also, a router or BOOTP/DHCP relay agent
must be configured on the subnet to allow DHCP messages to travel between the logical
subnets.
Support is needed for DHCP clients that are in a multinet located on the other side of BOOTP
relay agents.
Clients need to be migrated to a new scope.
DHCP Messages
The following list includes the eight types of messages that can be sent between DHCP clients and
servers. For more information about the structure and specifics of each of these packets, see “DHCP
Message Format” later in this section.
DHCPOffer
Broadcast by each DHCP server that receives the client DHCPDiscover message and has an IP address
configuration to offer to the client. The DHCPOffer message contains an unleased IP address and
additional TCP/IP configuration information, such as the subnet mask and default gateway. More
than one DHCP server can respond with a DHCPOffer message. The client accepts the best offer,
which for a Windows DHCP client is the first DHCPOffer message that it receives.
DHCPRequest
Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message contains the IP
address from the DHCPOffer that it selected. If the client is renewing or rebinding to a previous lease,
this packet might be unicast directly to the server.
DHCPAck
Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message. At this time,
the server also forwards any options. Upon receipt of the DHCPAck, the client can use the leased IP
address to participate in the TCP/IP network and complete its system startup. This message is
typically broadcast, because the DHCP client does not officially have an IP address that it can use at
this point. If the DHCPAck is in response to a DHCPInform, then the message is unicast directly to the
host that sent the DHCPInform message.
DHCPNack
Broadcast by a DHCP server to a DHCP client denying the client’s DHCPRequest message. This might
occur if the requested address is incorrect because the client moved to a new subnet or because the
DHCP client’s lease has expired and cannot be renewed.
DHCPRelease
Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the remaining
lease. This is unicast to the server that provided the lease.
DHCPInform
Sent from a DHCP client to a DHCP server, asking only for additional local configuration parameters;
the client already has a configured IP address. This message type is also used by DHCP servers
running Windows Server 2003 to detect unauthorized DHCP servers.
In both cases, the client begins a new cycle of DHCPDiscover messages in the background
every five minutes, using the same intervals as before (0, 4, 8, 16, and 32 seconds), until it
receives a DHCPOffer message from a DHCP server.
3. The client indicates acceptance of the offer by selecting the offered address and
broadcasting a DHCPRequest message in response.
4. The client is assigned the address and the DHCP server broadcasts a DHCPAck message in
response, finalizing the terms of the lease.
When the client receives acknowledgment, it configures its TCP/IP properties by using the DHCP
option information in the reply, and completes its initialization of TCP/IP.
In rare cases, a DHCP server might return a negative acknowledgment to the client. This can happen
if a client requests an invalid or duplicate address. If a client receives a negative acknowledgment
(DHCPNack), the client must begin the entire lease process again.
When the DHCP server and DHCP client are not on the same subnet either a router or a host on the
DHCP client’s subnet must act as a DHCP relay agent to support the forwarding of DHCP messages
between the DHCP client and the DHCP server.
Renewing a Lease
The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known
as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP
server that originally granted its lease. If the server is available, and the lease is still available, the
server responds with a unicast DHCPAck message and the lease is renewed.
If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP
server responds with a DHCPNack message, and the client immediately starts the process to obtain a
new lease. This can happen if the client has changed subnets or if the DHCP server cannot fulfill the
lease request for some other reason.
If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time has
passed (known as T2). At T2, the client enters the rebinding state, and broadcasts a DHCPRequest
message to attempt to renew the lease from any available DHCP server. If no DHCP server is available
by the time the lease expires, the client immediately unbinds itself from the existing lease and starts
the process to obtain a new lease, beginning with a DHCPDiscover message.
After the DHCP client receives a lease from the DHCP server, the client sends an Address Resolution
Protocol (ARP) request to the address that it has been assigned. If a reply to the ARP request is
received, the client has detected a conflict and sends a DHCPDecline message to the DHCP server.
The DHCP server attaches a BAD_ADDRESS value to the IP address in the scope for the length of the
Note
ARP requests do not traverse routers. Clients use ARP requests rather than pings (ICMP Echo
messages) because pings require the sender to have an IP address.
To detect conflicts, the DHCP server pings (sends an ICMP Echo message to) an IP address before
offering that address to clients in a new lease. The DHCP server only pings addresses that have not
been successfully and previously leased. If a client requests a lease on an IP address that it already
had or is requesting a renewal, the DHCP server does not ping the IP address.
If conflict detection is enabled, an administrator-defined number of pings are sent. The server waits 1
second for a reply. Because the time required for a client to obtain a lease is equal to the number of
pings used, choose this value carefully because it directly impacts the overall performance of the
server. In general, one ping is sufficient.
If a response to the ping is received, a conflict is registered and that address is not offered to clients
requesting a lease from the server. The DHCP server then attaches a BAD_ADDRESS value to that IP
address in the scope. The DHCP server then tries to lease the next available address. If the duplicate
address is removed from the network, the BAD_ADDRESS value attached to the IP address can be
deleted from the scope’s list of active leases, and then the address returns to the pool. Addresses are
marked as BAD_ADDRESS for the length of the lease for which the scope is configured. If the
BAD_ADDRESS entry is not manually removed, it will automatically be removed after a period of time
equal to the lease time for the scope.
Note
In general, use server conflict detection only as a troubleshooting aid when you suspect that
duplicate IP addresses are in use on your network. Each additional conflict detection attempt
adds to the time needed to negotiate leases for DHCP clients.
The most specific options take precedence over the least specific options. This simplifies DHCP
management and allows a flexible administration that can range from per-server default settings to
common settings for a specific subnet and individualized client settings when needed for special
circumstances. In most cases, the option values are specified in the Options dialog box on the DHCP
server, scope, or reservation.
DHCP options can be configured for specific values and enabled for assignment and distribution to
DHCP clients based on:
Server options. These options apply globally for all scopes and classes defined at each DHCP
server and any clients that it services. Configured server option values always apply unless
they are overridden by options assigned to other scope, class, or client reservation.
Scope options. These options apply to any clients that obtain a lease within that particular
scope. Configured scope option values always apply to all computers obtaining a lease in a
given scope unless they are overridden by options assigned to class or client reservation.
Class options. These options apply to any clients that specify that particular DHCP Class ID
value when obtaining a scope lease. Configured class option values always apply to all
computers configured as members in a specified DHCP option class unless they are
overridden by options assigned to a client reservation.
Reserved client options. These options apply only to the client corresponding to the
reservation. Reserved client option values override all other server, scope, or class assigned
option values.
Options are typically applied at each DHCP server at the server or scope level. To precisely manage or
customize option settings for a group or class of computers, specify either a user or vendor class
assignment that overrides the broader server or scope option defaults.
For special requirements, such as clients with special functions, assign options for specific reserved
clients.
Options can also be used to separate and distribute appropriate options for clients with similar or
special configuration needs. For example, DHCP clients on the same floor of a building can be
configured with the same DHCP Class ID value to assign them membership in the same option class.
You can then distribute additional or varied option data to that class during the lease process,
overriding any scope or globally provided default options.
Statically configured values on a client override any DHCP options of any type or level.
Many options are predefined on a DHCP server running Windows Server 2003. Other standard DHCP
options can be added as needed to support any other DHCP client software that recognizes or
requires the use of these additional options. The DHCP Server service running on Windows
Server 2003 supports all options defined in RFC 2132, although most DHCP clients use or support
only a small subset of the available RFC-specified options.
The following table contains a list of default DHCP options requested by DHCP clients running
Windows Server 2003 and Windows XP. For a complete reference of DHCP options, see “DHCP Tools
and Settings.”
1 Subnet mask
3 Router
6 DNS servers
44 WINS/NBNS servers
47 NetBIOS scope ID
51 Lease time
33 Static route
43 Vendor-specific information
Information options. You can explicitly configure these options and any associated values
provided to clients.
Protocol options. You can implicitly configure these options used by the DHCP Server service
based on server and scope property settings.
You can use the DHCP snap-in to configure these properties and set them for an entire scope or for a
single, reserved client scope.
Information Options
The following table lists the most common types of DHCP information options that can be configured
for DHCP clients. These options can be enabled and configured for each scope that you configure on
a DHCP server. Depending on your network infrastructure, some of these options can be configured
as server options, such as DNS domain name.
Code Description
3 Router
6 DNS server
44 WINS/NBNS servers
Clients can request these DHCP options, and can use the values to set their TCP/IP configurations for
the duration of the lease.
Protocol Options
The following table shows protocol options that DHCP clients can be configured to use when
communicating with a DHCP server to obtain or renew a lease.
Code Description
51 Lease time
55 Special option type used to communicate a parameter request list to the DHCP server
The values provided to clients for lease time, T1, and T2 are taken from the scope settings on the
DHCP server. The value provided for DHCP message type is automatically set depending on which
packet of the DHCP conversation is being sent.
Option Classes
Option classes allow quick introduction of custom applications for enterprise networks. DHCP option
classes provide a way to easily configure network clients with the parameters necessary to meet the
special requirements of custom applications. Equipment from multiple vendors on a network can
also use different option code numbers for different functions. The options used to support vendor
classes — the vendor class identifier and the vendor-specific option — are defined in the Internet
DHCP options standard reference, RFC 2132.
Add and configure vendor-defined classes for managing DHCP options assigned to clients
identified by vendor type.
Add and configure user-defined classes for managing DHCP options assigned to clients that
need a similar DHCP option configuration.
After options classes are defined on a DHCP server, scopes on the server can be configured to assign
options for specific user-defined and vendor-defined option classes.
Vendor Classes
Vendor-defined option classes can be used by DHCP clients to identify the client’s vendor type and
configuration when obtaining a lease from the DHCP server. The client can include the vendor class
ID option (option code 60) when it requests or selects a lease from a DHCP server to identify its
vendor class during the lease process.
The vendor class identifier information is a string of character data interpreted by the DHCP servers.
Vendors can choose to define specific vendor class identifiers to convey particular configuration or
other identification information about a client. For example, the identifier might encode the client’s
hardware or software configuration. Most vendor types are derived from standard reserved
hardware and operating system-type abbreviation codes listed in RFC 1700.
When vendor options are specified, the server performs the following additional steps to provide a
lease to the client:
The server verifies that the vendor class identified by the client request is a recognized class
defined on the server.
If the vendor class is recognized, the server checks to see if any additional DHCP options are
configured for this class in the active scope.
If the vendor class is not recognized, the server ignores the vendor class identified in the
client request, and returns options allocated to the default vendor class (which includes all
DHCP Standard options).
If the scope contains options configured specifically for use with clients in this vendor-
defined class, the server returns those options using the vendor-specific option type (option
code 43) as part of its acknowledgment message.
In most cases, the default vendor class — the DHCP Standard option class — provides a default
vendor class for any Windows DHCP clients or other DHCP clients that do not specify a vendor class
ID. In some cases, you might define additional vendor classes for other DHCP clients, such as printers
User Classes
User classes allow DHCP clients to differentiate themselves by specifying what type of client they are,
such as desktop or server computer. For computers running Windows Server 2003, Windows XP, and
Windows 2000, you can define specific user class identifiers to convey information about a client’s
software configuration, its physical location in a building, or about its user preferences. For example,
an identifier can specify that DHCP clients are members of a user class called “2nd floor, West”,
which has need for a specific set of router, DNS, and WINS server settings. An administrator can then
configure the DHCP server to include different option values depending on the user class of client
receiving the lease.
DHCP client computers can include the DHCP user class option when sending DHCP request
messages to the DHCP server. This can specifically identify the client as part of a user class on
the server.
DHCP servers running the Windows 2000 Server or Windows Server 2003 DHCP Server
service can recognize and interpret the DHCP user class option from clients and provide
additional options (or a modified set of DHCP options) based on the client’s user class
identity.
For example, shorter leases can be assigned to wireless clients. Or perhaps a particular set of clients
might need a specific set of routes, a specific DNS server, or a specific default gateway.
Note
If user classes are not specified, default settings, such as server options or scope options, are
assigned.
A user class can be either a default or custom user class. Microsoft provides three default user
classes, as described in the following table.
Default RRAS.Microsoft This class is used by the Windows 2000 Server or Windows
Routing and Server 2003 DHCP Server service to classify clients making a
Remote PPP-type connection through a remote access server. Typically,
Access class this class includes most dial-up networking clients that use
DHCP to obtain a lease, including remote access clients that
cannot be configured with a Routing and Remote Access user
class or a Routing and Remote Access user class ID.
See “DHCP and Routing and Remote Access” later in this topic
for details about the interaction between a Routing and Remote
Access server and a DHCP server and how DHCP servers identify
remote access clients.
Default BOOTP This class is used by the Windows 2000 Server or Windows
BOOTP class Server 2003 DHCP Server service to classify any clients
recognized as BOOTP clients.
Use the Microsoft default user classes to isolate specific configuration details for clients with special
needs, such as older clients or clients that use BOOTP or Routing and Remote Access. For example,
you might want to include and assign special BOOTP option types (such as option codes 66 and 67)
for clients that are BOOTP type, or shorten the lease time for remote access clients.
You can also add and configure custom user classes for use by DHCP clients running Windows 2000,
Windows XP, and Windows Server 2003. For a custom user class to work properly, the client must
use the same custom identifier when requesting options as was used when the class was defined on
the DHCP server
The user class option field permits only one ASCII text string to be used for identifying clients. This
means each client computer can be identified only as a member of a single user class by the DHCP
server. You can use additional user classes to make new hybrids from your other user classes to
Multicast scopes configured on the DHCP server define ranges of IP multicast addresses. Similar to
allocating unicast IP addresses, IP multicast addresses are allocated to MADCAP clients. A MADCAP
address is configured separately from a primary IP address. Computers that use either static or
dynamic IP configuration through a DHCP server can be MADCAP clients.
In Windows Server 2003, the DHCP Server service supports both DHCP and MADCAP, although these
services function separately. Clients of one do not depend on the use or configuration of the other.
Clients that do not support the MADCAP service or are unable to contact and obtain multicast
configuration from a MADCAP server can be configured in other ways so that they participate in
either permanent or temporary multicast groups on the network.
In all TCP/IP networks, each computer requires a unique primary unicast IP address for each network
interface. You must assign this required primary unicast IP address before you can configure a
computer to support and use secondary IP addresses such as multicast IP addresses.
DHCP Protocols
In Windows Server 2003, the DHCP Server service includes support for the Dynamic Host
Configuration Protocol (DHCP), the Multicast Address Dynamic Client Allocation Protocol (MADCAP),
and the Bootstrap Protocol (BOOTP).
DHCP
DHCP servers communicate with DHCP clients by using a series of DHCP messages. The format of
DHCP messages is based on the message format used with the BOOTP protocol.
RFC 2131 defines the format for each message sent between a DHCP client and a DHCP server. The
following table shows the possible fields in the DHCP messages.
Field
Field Friendly Length
Name Name (Octets) Description
flags Flags 2 Flags set by client. The Broadcast flag is set if the client
cannot receive unicast IP datagrams (for example, before it
is configured with an IP address).
ciaddr Client IP 4 This field is only filled in if the client has an IP address and
Address can respond to ARP requests.
yiaddr Your IP 4 Address given to the DHCP client by the DHCP server
Address
sname Server Host 64 Optional server host name. Not used in Windows
Name Server 2003
file Boot File 128 The name of the file containing the boot image for a BOOTP
Name client
options Options variable Optional parameters field. In the DHCP protocol packet,
each option begins with a single octet tag, which holds the
option code, and a second octet, which describes the option
data length, in bytes. For a complete list of the DHCP
options available by default on a DHCP server running on
Windows Server 2003, see “DHCP Tools and Settings.”
For a complete view of how these fields are used in each DHCP message, see RFC 2131 or use a
network monitoring tool, such as Netmon, to view the DHCP messages.
MADCAP
Windows Server 2003 includes a Multicast Address Dynamic Client Allocation Protocol (MADCAP)
Server service to support dynamic assignment and configuration of IP multicast addresses on TCP/IP-
based networks.
Whereas DHCP unicast scopes provide client configurations by allocating ranges of IP addresses for
point-to-point communication between two networked computers, multicast scopes provide ranges
for multicast IP addresses. These addresses are reserved for multicast operation using directed
transmission from one point to multiple points.
A multicast address is shared by many computers. A group of TCP/IP computers can use a single
multicast IP address to send directed communication to all computers with which they share the use
of the group address. An IP datagram that is sent to the multicast address is forwarded to all
members of that multicast group.
BOOTP
Bootstrap Protocol (BOOTP) is a computer configuration protocol developed before DHCP. DHCP
improves on BOOTP and resolves specific limitations that BOOTP had as a computer configuration
service. RFC 951 defines BOOTP.
Whereas BOOTP configures diskless workstations with limited boot capabilities, DHCP configures
networked computers, that have local hard drives and full boot capabilities.
Likewise, although both BOOTP and DHCP allocate IP addresses to clients during startup, they use
different methods of allocation. BOOTP typically provides fixed allocation of a single IP address for
each client, permanently reserving this address in the BOOTP server database. DHCP typically
provides dynamic, leased allocation of available IP addresses, reserving each DHCP client address
temporarily in the DHCP database.
Because of the relationship between BOOTP and DHCP, both protocols share some defining
characteristics. BOOTP and DHCP use nearly identical request messages and reply messages. Both
protocols enclose each protocol message in a single User Datagram Protocol (UDP) datagram of 576
bytes. Message headers are the same for both BOOTP and DHCP, except for the final message header
field that carries optional data. For BOOTP, this optional field is called the vendor-specific area and is
limited to 64 bytes. For DHCP, this optional field is called the options field and is at least 312 bytes
long.
Because DHCP and BOOTP messages use nearly identical format types and packet structures, and use
the same well-known service ports, BOOTP or DHCP relay agent programs usually treat BOOTP and
DHCP messages as the same message type and do not differentiate between them.
BOOTP clients do not rebind or renew configuration with the BOOTP server except when the system
restarts, whereas DHCP clients do not require a system restart to rebind or renew configuration with
the DHCP server. Instead, clients automatically enter the rebinding state at defined intervals to
renew their leased address allocation with the DHCP server. This process occurs in the background
and is transparent to the user.
BOOTP uses a two-phase bootstrap configuration process in which clients contact BOOTP servers to
perform address determination and boot file name selection, and clients also contact Trivial File
Transfer Protocol (TFTP) servers to perform file transfer of their boot image. DHCP uses a single-
phase boot configuration process whereby a DHCP client negotiates with a DHCP server to determine
its IP address and obtain any other initial configuration details it needs for network operation.
Because BOOTP clients contact TFTP servers to perform file transfer of their boot image and
Windows Server 2003 does not provide a TFTP file service, you need a third-party TFTP server to
support BOOTP clients that must boot from an image file (usually diskless workstations). You also
need to configure your DHCP server to provide supported BOOTP/DHCP options.
1 Subnet Mask
4 Time Server
5 Name Server
9 LPR Server
12 Computer Name
15 Domain Name
17 Root Path
42 NTP Servers
44 WINS Server
69 SMTP Server
70 POP3 Server
DHCP servers running Windows Server 2003 return the options in the order listed above and return
as many options as can fit in a single datagram response. For more information about individual
DHCP options, see “DHCP Tools and Settings.”
Note
BOOTP Table
Each record in the BOOTP table has three fields of information that is returned to the BOOTP client:
Boot Image. Identifies the generic file name (such as “unix”) of the requested boot file, based
on the BOOTP client’s hardware type.
File Name. Identifies the full path of the boot file (such as “/etc/vmunix”) that the BOOTP
server returns to the client by using TFTP.
File Server. Identifies the name of the TFTP server used to store the boot file.
To add entries in the BOOTP table, use the DHCP snap-in.
In Windows Server 2003, the DHCP Server service interacts with several other services, including the
Active Directory directory service, DNS, and the Routing and Remote Access service.
Note
This process of authorizing DHCP servers is useful for only DHCP servers running
Windows 2000 or Windows Server 2003. This process cannot be used for DHCP servers
running Windows NT Server 4.0, or servers running non-Windows-based DHCP Server
services. Only a member of the Enterprise Admins group can authorize or unauthorize a
DHCP server in Active Directory.
1. When the DHCP Server service starts, it sends a DHCPInform request message to the
reachable network, using the local limited broadcast address (255.255.255.255), to locate
other DHCP servers on the network.
This message includes several vendor-specific option types that are known and supported by
other DHCP servers running Windows Server 2003. These other DHCP servers will respond
with a DHCPAck containing information indicating if they are authorized domain member or
workgroup member servers.
2. When queried, other DHCP servers running Windows 2000 and Windows Server 2003 reply
with DHCPAck messages to acknowledge and answer with workgroup or domain
membership information.
3. If an Active Directory domain member DHCP server is found, then the workgroup member
server determines that it is not authorized and does not service clients. If other workgroup
servers are found, the workgroup member server determines that it is authorized to service
clients, and begins service. It then performs the check again at one-hour intervals.
Although DHCP provides a powerful mechanism for automatically configuring client IP addresses,
prior to Windows 2000, the DHCP Server service did not notify DNS to update the DNS records on
behalf of the client. Specifically, DHCP did not map the client name to an IP address and did not
update IP address-to-name mappings using DNS dynamic update.
Without a way for DHCP to interact with DNS, the information maintained by DNS for a DHCP client
might be incorrect. For example, a client can acquire its IP address from a DHCP server, but the DNS
records might not reflect the IP address acquired nor provide a mapping from the new IP address to
the FQDN.
The ability to register A and PTR resource records lets a DHCP server act as a DNS registration proxy
for clients using Windows NT 4.0, Windows 98, or Windows Millennium Edition, and possibly other
clients that are not able to register the updates on their own, as shown in the following figure.
DHCP clients running Windows 2000, Windows XP, and Windows Server 2003 interact with DNS
differently than DHCP clients running earlier versions of Windows. DHCP clients running Windows XP,
Windows 2000, or Windows Server 2003 typically update their own dynamic forward lookup names,
as shown in the following figure.
An additional DHCP option code (option code 81) enables the return of a client’s FQDN to the DHCP
server. If implemented, the DHCP server can dynamically update an individual computer’s resource
records on a DNS server by using the DNS dynamic update protocol.
For more information about DNS dynamic updates, see “DNS Technical Reference.”
Secure DNS dynamic update protects zones and resource records from being modified by
unauthorized users by allowing you to specify the users and groups that can modify zones and
resource records. By default, Windows Server 2003, Windows XP Professional, and Windows 2000
clients attempt unsecured DNS dynamic updates first. If that request fails, they attempt secure
updates.
When using multiple DHCP servers and secure DNS dynamic updates, add each of the DHCP servers
as members of the DnsUpdateProxy global security group so that any DHCP server can perform a
secure DNS dynamic update for any record. Otherwise, when a DHCP server performs a secure DNS
dynamic update for a record, that DHCP server is the only computer that can update the record.
DHCP also interacts with routers when DHCP clients and DHCP servers are on different subnets from
each other. In this situation, a router that can act as a DHCP relay agent must be present on the
subnet of the DHCP client. You can use the Windows Server 2003 Routing and Remote Access service
to act as a DHCP relay agent.
The remote access server uses the IP addresses from these leases to configure PPP clients, but
discards all options contained in the leases.
With a Windows NT 4.0–based remote access server, DHCP-allocated addresses are recorded and
reused when the remote access service is restarted. In Windows Server 2003 and Windows 2000
Server, the Routing and Remote Access service releases all DHCP-allocated IP addresses by using
DHCPRelease messages each time the service is stopped.
If the DHCP server becomes unavailable, the DHCP Client service on the Routing and Remote Access
server assigns APIPA addresses to TCP/IP-based PPP clients. APIPA addresses for remote access
connectivity work only if the network to which the remote access client is attached is also using
APIPA addresses (which is not a recommended configuration). If the local network is not using APIPA
addresses, remote access clients can only obtain point-to-point remote access connectivity.
The Routing and Remote Access service uses a specific LAN interface to obtain DHCP-allocated IP
addresses for remote access clients. You can select which LAN interface to use on the IP tab of the
Properties dialog box of a server in the Routing and Remote Access snap-in. If the Routing and
Remote Access server has more than one LAN interface installed, the Routing and Remote Access
Server Setup Wizard prompts you to select the LAN interface.
The following three figures show the three steps of the remote access server obtaining leases from
the DHCP server.
First, when the first PPP client connects to the remote access server, the remote access server
obtains 10 IP addresses from the DHCP server as shown in the following figure.
After the remote access client has an IP address, it sends a unicast DHCPInform message to request
options from the DHCP server to the remote access server. The remote access server must also be
configured with the DHCP Relay Agent routing protocol component. The remote access server, acting
in its role as a DHCP relay agent, then sends the DHCPInform message to the DHCP server. The DHCP
server responds with the options in a DHCPAck message, which is sent back to the remote access
server. Finally, the DHCP relay agent on the remote access server sends the DHCPAck message to the
remote access client, as shown in the following figure.
The following table lists the DHCP options that are requested by the client in the DHCPInform
message.
Code Description
1 Subnet mask
6 DNS servers
43 Vendor-specific information
44 WINS/NBNS servers
Most routers support acting as a DHCP relay agent. Alternatively, if a router cannot function as a
DHCP relay agent, a computer that can function as a DHCP relay agent must be configured on each
subnet to which the router is connected.
In cases where it is impractical or impossible to configure routers to act as a DHCP relay agent, you
can configure a computer running Windows Server 2003 or Windows 2000 Server, to act as a relay
agent by enabling the Routing and Remote Access service and installing the DHCP Relay Agent
routing protocol component.