Re: 70-294 next week
From: *FESWANY (alkholy2000_at_hotmail.com)
Date: 01/28/05
- Next message: *FESWANY: "Re: 70-294 next week"
- Previous message: *FESWANY: "Re: 70-294 next week"
- Maybe in reply to: *FESWANY: "Re: 70-294 next week"
- Next in thread: *FESWANY: "Re: 70-294 next week"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 28 Jan 2005 17:03:50 +0200
before registering and using a name.
Consult with your company's legal department (or a
legal service) to
ensure that the domain name is not currently being
used and that a
trademark on the name is not currently held by another
company.
CA
Planning a DNS Structure 51
Once you have found a name, the process to register it
is quite simple and
can be carried out entirely online. To start the
registration process,
connect
to rs.internic.net and follow the links for
registering a new domain
name. You will need to choose from among several
official registrars and
then follow the instructions provided.
During the rise in popularity of the World Wide Web,
many people rushed to
reserve domain names based, for example, on the names
of popular
companies.
These people (sometimes affectionately referred to as
cyber-squatters)
planned to sell the domain names to the companies that
owned the copyright
for the name. Today, however, organizations are in
place to prevent
trademarked
names from being used by third parties as domain
names. To inquire
into the process of regaining a domain name to which
you may have rights,
see rs.internic.net.
In order for your computers to be accessible via the
Internet, you will
need
to have a worldwide-registered domain name. As part of
the name
registration
process, you will be required to provide technical
information about the
DNS server(s) that will host your domain name. If you
have your own DNS
servers, you can simply provide their IP addresses.
Otherwise, you can
receive this service from many commercial ISPs (for a
fee). Figure 2.3
shows
how DNS names are resolved with company domain names.
FIGURE 2 . 3 How root domain requests are resolved
.net
.org
Root-
Level
Servers
Private
DNS
Servers
microsoft.com
www.microsoft.com rs.internic.net
utexas.edu internic.net
.com
.edu
CA
52 Chapter 2 Integrating DNS with the Active Directory
Choosing Internal and External Names
So far, we have been talking about choosing an
Internet root domain name.
This external name is designed to make computers
accessible publicly on
the
Internet. You will also need to choose a domain name
for your internal
network. The internal domain name may be the same as
the external one, or
it may be different. When you're managing internal
names, you can choose
any name that meets your own standards. You should,
however, ensure that
any
external domain name you use has been properly
registered with the
Internet
name authorities. Figure 2.4 provides an example of
how different internal
and external DNS names can be used.
FIGURE 2 . 4 Using different internal and external DNS
names
There are several pros and cons to consider when
deciding whether or not
to use the same domain name for internal and external
resources. The
advantages
of using the same name include consistency between
internal and external
resources. This means that users will be able to use
the same e-mail
address for internal and external communications.
However, having the
same name will require taking great care in naming
resources and
configuring
DNS servers. A small mistake in the naming, for
instance, may result in
an internal server being made available on the public
Internet. Similarly,
users must be told which resources are only available
from the internal
network
and which machines are accessible from the public
Internet.
Private Resources
(Inside the Firewall)
Public Resources
(Accessible from the Internet)
www Database Mail
myintranet.com
www Mail FTP
mycompany.com
Internal Namespace External Namespace
CA
Overview of DNS Zones 53
If you choose separate internal and external names,
you will be able to
easily determine which resources are publicly
accessible and which ones
are
restricted to your private network. This also
simplifies routing and DNS
settings.
However, this method requires that you reserve two
domain names
(which are getting more and more difficult to find!)
and that users have
two
different e-mail addresses (one for internal e-mail
and one for e-mail
sent by
users that are located outside of the private network
(such as Internet
users).
You should base your decision regarding whether to use
separate or
identical
internal and external namespaces on your
organization's business and
technical requirements.
Overview of DNS Zones
DNS servers work together to resolve hierarchical
names. If they
already have information about a name, they simply
fulfill the query for
the
client; otherwise, they query other DNS servers for
the appropriate
information.
The system works well as it distributes the authority
of separate parts
of the DNS structure to specific servers. A DNS zone
is a portion of the
DNS
namespace over which a specific DNS server has
authority. In this section,
we'll see how the concept of zones is used to ensure
accurate name
resolution
on the Internet.
Purpose and Function of DNS Zones
In order to ensure that naming remains accurate in a
distributed network
environment, one DNS server must be designated as the
master database for
a specific set of addresses. It is on this server that
updates to
host-name-to-
IP-address mappings can be updated. Whenever a DNS
server is unable to
resolve a specific DNS name, it simply queries other
servers that can
provide
the information. Zones are necessary because many
different DNS servers
could otherwise be caching the same information. If
changes are made, this
information could become outdated. Therefore, one
central DNS server
must assume the role of the ultimate authority for a
specific subset of
domain
names.
CA
54 Chapter 2 Integrating DNS with the Active Directory
There is an important distinction to make between DNS
zones and Active
Directory domains. Although both use hierarchical
names and require name
resolution, DNS zones do not map directly to DNS
domains.
As shown in Figure 2.5, a zone may be an entire domain
or represent only
part of one.
FIGURE 2 . 5 The relationship between DNS domains and
zones
With this information in mind, let's take a more
detailed look at the
actual
process of DNS name resolution.
DNS Name Resolution
When using the Internet, DNS queries are extremely
common. For example,
every time you click a link to visit a Web site, a DNS
query must be made.
In the simplest scenario, the client computer requests
a DNS address from
its
designated DNS server. The DNS server has information
about the IP
address for the specified host name, it returns that
information to the
client,
and the client then uses the IP address to initiate
communications with
the
host. This process is shown in Figure 2.6.
company.com DNS Zone #2
DNS Zone #1
domain1.company.com
sales.domain1
.company.com
dev.domain1
.company.com
europe.sales.domain1
.company.com
CA
Overview of DNS Zones 55
FIGURE 2 . 6 A simple DNS name resolution process
What happens, though, if the DNS server does not
contain information
about the specific host requested? In this case, the
DNS server itself
initiates
a query to another DNS server, which thereby assumes
responsibility for
ultimately resolving the name. If the second DNS
server is unable to
fulfill
the request, it, in turn, queries another. This
process is known as
recursion.
In the process of recursion, one DNS server will
contact another, which
will
then contact another until one of the servers is able
to resolve the host
name.
The name resolution process will usually begin with a
query to the
top-level
DNS servers and continue downward through the domain
hierarchy until
the resource is reached. If, at this point, the name
still cannot be
resolved, an
error is returned to the client. Figure 2.7
illustrates the process of
recursion.
Usually, DNS servers include information about the
root- and top-level DNS
servers. This information is entered in during the
initial configuration
of
the server.
Web
Server
www.microsoft.com
Server
1
3
2
Client requests
"www.microsoft.com"
DNS
Server
Server returns
IP address
Client uses IP address
to connect to server
CA
56 Chapter 2 Integrating DNS with the Active Directory
FIGURE 2 . 7 DNS name resolution through recursion
Because recursion is such an important process, let's
look at an example.
Suppose I want to connect to the DNS name Computer1.
sales.somecompany
.com. The following steps will occur to make this
happen:
1. The client requests information from its preferred
DNS server.
2. The preferred DNS server is unable to find a
resource record for this
information in its own cache and must therefore query
another server.
The DNS server first queries a root server and then
sends a query to
the top-level domain server and requests information
about the server
that has authority over the somecompany.com domain.
.com
www.
company.
com
3
Preferred DNS
Server
5 Server returns IP
address and caches name
2 Server
cannot
resolve
name
6 Client
uses IP
address
to connect
to resource
Server
forwards name
request to rootlevel
servers
4 Root-level server
resolves name
DNS
1 Client requests
IP address
CA
Overview of DNS Zones 57
3. Once the information is obtained, the preferred DNS
server then queries
the somecompany.com DNS server for information about
the
computer1 host name within the sales domain.
4. The client's preferred DNS server then returns the
IP address of the
host name to the client. It can then use the IP
address to communicate
with the host. The preferred DNS server may choose to
cache a copy
of the resource record information just in case
additional requests for
the domain name are made.
A client may also be configured to query multiple DNS
servers for names.
This process is known as iteration. Iteration is
normally used when a
client
queries DNS servers, but instructs them not to use
recursion.
Alternatively,
systems administrators may configure DNS servers,
themselves, not to
perform
recursion. For example, we may configure all DNS
servers to forward
resolution requests to one DNS server on our network.
This will direct all
DNS traffic through this one server, thereby reducing
network traffic and
allowing us to secure DNS requests.
In the iteration process, the DNS server fulfills a
request if it is able
to do
so based on the information in its own database. If it
cannot, it will
either
return an error or will point the client to another
DNS server that may be
able to resolve the name. Iteration requires the
client to remain
responsible
for ultimately resolving the name request.
Usually, the client is configured with multiple DNS
servers that are
utilized
according to a certain search order. This is useful,
for example, if
different
DNS servers are required to resolve intranet and
Internet names. For
example, a client may use one DNS server to resolve
names for a specific
department within the organization and another DNS
server to resolve
names of public Web sites. This method places the
burden of finding the
right name server on the client. In certain
configurations, though, you
may
want to reduce network traffic with DNS forwarding,
which allows you to
specify exactly which DNS servers will be used for
resolving names. For
example, if you have multiple DNS servers located on a
fast network (such
as a LAN), you may want each of them to request DNS
information from
only a few specific DNS servers that can then gain
information from other
DNS servers on the network. Figure 2.8 provides an
example of how DNS
forwarding can be used.
CA
58 Chapter 2 Integrating DNS with the Active Directory
FIGURE 2 . 8 Using DNS forwarding to reduce network
traffic
Another feature of DNS servers is their ability to
cache information. As
you can imagine, going through the recursion process
each time a DNS query
is initiated can place a significant load on servers
worldwide. In order
to limit
some of this traffic, DNS servers usually save
information about mapped
domain names in their own local database. If future
requests are made for
the same host and domain names, this cached
information is usually used.
To
ensure that the cached information is reasonably up-
to-date, a Time to
Live
(TTL) value is attached to each cached DNS record.
Typical TTL values
range from three to seven days. Once this time limit
is exceeded, the
cached
value is no longer used, and the next request for the
information will
result
in going through the entire recursion process again.
DNS
Server
(Main)
DNS
Server
#3
DNS
Server
#2
DNS
Server
#1
Forwarding Private
Network
Internet DNS
Servers
= Name
Resolution
Requests
CA
Overview of DNS Zones 59
Since DNS names are updated on a pull basis, it can
take time for some DNS
servers to update their databases. If you are required
to make changes to
a
DNS entry, be sure to allow sufficient time for all of
the name servers on
the
Internet to be updated. Usually, this should take only
a few days, but, in
some
cases, it may take more than a week.
Although the most common DNS functions involve the
mapping of DNS
names to IP addresses, certain applications might
require the opposite
functionality
.the resolution of an IP address to a DNS name. This
is handled
through a reverse lookup zone in the DNS server.
Reverse lookup zones
start
with a special Internet authority address and allow
the DNS server to
resolve
queries for specific TCP/IP addresses. As we'll see
later in this chapter,
reverse lookup zones are configured similarly to
standard forward lookup
zones.
In order to determine from which DNS server specific
information can be
found, zones must be used. Let's now examine the
process of establishing
authority for specific DNS zones.
Delegating Authority in DNS Zones
Every DNS server can be configured to be responsible
for one or more DNS
domains. The DNS server is then known as the
authoritative source of
address information for that zone. Generally, if you
are using only a
single
DNS domain, you will have only one zone. Remember that
there can be a
many-to-many relationship between domains (which are
used to create a
logical naming structure) and zones (which refer
primarily to the physical
structure of a DNS implementation).
When you add subdomains, however, you have two
options. You can
allow the original DNS server to continue functioning
as the authority for
the parent and child domains. Or, you can choose to
create another DNS
zone and give a different server authority over it.
The process of giving
authority for specific domains to other DNS servers is
known as
delegation.
Figure 2.9 shows how delegation can be configured.
CA
60 Chapter 2 Integrating DNS with the Active Directory
FIGURE 2 . 9 Delegating DNS authority to multiple DNS
servers
The main reasons for using delegation are performance
and administration.
Using multiple DNS servers in a large network can help
distribute the
load involved in resolving names. It can also help in
administering
security
by allowing only certain types of records to be
modified by specified
systems
administrators.
DNS Server Roles
One of the potential problems with configuring
specific DNS servers as
authorities for their own domains is fault tolerance.
What happens if
an authoritative server becomes unavailable? Normally,
none of the names
for the resources in that zone could be resolved to
network addresses.
This
could be a potentially serious problem for networks of
any size. For
example,
DNS
Server
#1
DNS
Server
#1
DNS
Server
#2
Domain 1
Domain 2 Domain 3
Domain 1
Domain 2
Domain 3
Zone #1
Before
Delegation
After
Delegation
Zone #1
Zone #2
CA
Overview of DNS Zones 61
if the primary server for the sales.mycompany.com zone
becomes unavailable
(and there are no secondary servers in that zone),
users will not be able
to find resources such as server1.sales.mycompany.com
or workstation1
.sales.mycompany.com. In order to prevent the
potential network problems
of a single failed server, the DNS specification
allows for supporting
multiple
servers per zone.
To maintain a distributed and hierarchical naming
system, DNS servers
can assume several different roles at once. In this
section, we'll look at
the
various roles that DNS servers can assume within a
zone. In later sections
of
this chapter, we'll see how Windows 2000 Server
computers can assume
these roles.
Primary Server
Each DNS zone must have one primary DNS server. The
primary server is
responsible for maintaining all of the records for the
DNS zone and
contains
the primary copy of the DNS database. Additionally,
all updates of records
occur on the primary server. You will want to create
and add primary
servers
whenever you create a new DNS domain. When creating
child domains,
however, you may want to use the primary server from
the parent domain.
Secondary Server
A secondary DNS server contains a database of all of
the same information
as the primary name server and can be used to resolve
DNS requests. The
main purpose of a secondary server is to provide for
fault tolerance. That
is,
in case the primary server becomes unavailable, name
resolution can still
occur using the secondary server. Therefore, it is a
good general practice
to
ensure that each zone has at least one secondary
server to protect against
failures.
Secondary DNS servers can also increase performance by
offloading some
of the traffic that would otherwise go to the primary
server. Secondary
servers
are also often located within each location of an
organization that has
high-speed network access. This prevents DNS queries
from having to run
across slow WAN connections. For example, if there are
two remote offices
within the mycompany.com organization, we may want to
place a secondary
DNS server in each remote office. This way, when
clients require name
resolution,
they will contact the nearest server for this IP
address information,
thus preventing unnecessary WAN traffic.
CA
62 Chapter 2 Integrating DNS with the Active Directory
Although it is a good idea to have secondary servers,
having too many of
them can cause increases in network traffic due to
replication. Therefore,
you should always weigh the benefits and drawbacks and
properly plan for
secondary servers.
Master Server
Master DNS servers are used in the replication of DNS
data between primary
and secondary servers. Usually, the primary server
also serves as the
master
server, but these tasks can be separated for
performance reasons. The
master server is responsible for propagating any
changes to the DNS
database
to all secondary servers within a particular zone.
Caching-Only Server
Caching-only DNS servers serve the same function as
primary DNS servers
in that they assist clients in resolving DNS names to
network addresses.
The
only difference is that caching-only servers are not
authoritative for any
DNS
zones, and they don't contain copies of the zone
files. They only contain
mappings as a result of resolved queries and in fact
will lose all of
their mapping
information when the server is shut down. Therefore,
they are installed
only for performance reasons. A caching-only DNS
server may be used at
sites that have slow connectivity to DNS servers at
other sites.
Zone Transfers
Similar to the situation with domain controllers and
the Active Directory,
it
is important to ensure that DNS zone information is
consistent between the
primary and secondary servers. The process used to
keep the servers
synchronized
is known as a zone transfer. When a secondary DNS
server is configured
for a zone, it first performs a zone transfer during
which it obtains a
copy of the primary server's address database. This
process is known as an
all-zone transfer (AXFR).
In order to ensure that information is kept up-to-date
after the initial
synchronization,
incremental zone transfers (IXFRs) are used. Through
this
process, the changes in the DNS zone databases are
communicated between
primary and secondary servers. IXFRs use a system of
serial numbers to
determine which records are new or updated. This
system ensures that the
newest DNS record is always used, even if changes were
made on more than
one server.
CA
Overview of DNS Zones 63
Not all DNS servers support IXFRs. Windows NT 4's DNS
services and earlier
implementations of other DNS services require a full
zone transfer of the
entire database in order to update their records. This
can sometimes cause
significant network traffic. As with any software
implementation, you
should
always verify the types of functionality supported
before deploying it.
Zone transfers may occur in response to the following
different events:
The zone refresh interval has been exceeded.
A master server notifies a secondary server of a zone
change.
A secondary DNS server service is started for the
zone.
A DNS zone transfer is manually initiated (by a
systems administrator)
at the secondary server.
An important factor regarding zone transfers is that
secondary servers
always initiate them. This type of replication is
commonly known as a pull
operation. Normally, a zone transfer request is made
when a refresh
interval
is reached on the secondary server. The request is
sent to a master
server,
which then sends any changes to the secondary server.
Usually the primary
server is also configured as a master server, but this
can be changed for
performance
reasons.
One of the problems with pull replication is that the
information stored
on secondary servers can sometimes be out-of-date. For
example, suppose an
IXFR occurs today, but the refresh interval is set to
three days. If I
make a
change on the primary DNS server, this change will not
be reflected on the
secondary server for at least several days. One
potential way to
circumvent
this problem is to set a very low refresh interval (
such as a few hours).
However,
this can cause a lot of unnecessary network traffic
and increased
processing
overhead.
In order to solve the problems related to keeping
resource records
up-todate,
a feature known as DNS notify was developed. This
method employs
push replication to inform secondary servers whenever
a change is made.
When secondary servers receive the DNS notify message,
they immediately
initiate an IXFR request. Figure 2.10 shows how DNS
notify is used to keep
secondary servers up-to-date. This method ensures that
compatible DNS
servers are updated immediately whenever changes are
made.
CA
64 Chapter 2 Integrating DNS with the Active Directory
FIGURE 2 . 1 0 Using DNS notify to update secondary
servers
Managing DNS Resource Records
So far, we have looked at various ways in which DNS
servers remain
synchronized
with each other. Now, it's time to look at the actual
types of information
stored within the DNS database. Table 2.2 provides a
list of the types
- Next message: *FESWANY: "Re: 70-294 next week"
- Previous message: *FESWANY: "Re: 70-294 next week"
- Maybe in reply to: *FESWANY: "Re: 70-294 next week"
- Next in thread: *FESWANY: "Re: 70-294 next week"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
