Implementing and Managing DNS


DNS is a hierarchical database that contains names and addresses for IP networks and hosts and that is used almost universally to provide name resolution. This fact was not lost on Microsoft as Windows Server 2003 (as Windows 2000 Server was before it) is completely dependent on DNS as its name resolution method for Windows Server 2003 rather than WINS, as in the days of Windows NT.

The Windows Server 2003 DNS service supports three types of zones:

  • Forward lookup zones Forward lookup zones provide the hostname-to-IP address resolution for which DNS is most frequently used.

  • Reverse lookup zones Reverse lookup zones resolve IP addresses to hostnames.

  • Stub zones In Windows Server 2003, Microsoft introduced support for stub zones for the first time. A stub zone contains only those resource records that are necessary to identify the authoritative DNS servers for that zone. Such resource records include Name Server (NS), Start of Authority (SOA), and possibly glue host (A) records. (Glue host records provide A record pointers to ensure that the master zone has the correct name server information for the stub zone.)

Stub zones are frequently used for the following:

  • To keep delegated zone information up to date Because a stub zone is used to provide pointers to a delegated zone, updating the stub zone causes the DNS server that is hosting both the parent zone and the stub zone to maintain a current list of authoritative DNS servers for the delegated zone.

  • To improve name resolution performance Because a stub zone enables a DNS server to perform recursive resolution by using the stub zone's list of name servers, the DNS server making the request does not need to query any Internet name servers or internal name servers to get the resolution.

With zone delegation, one DNS server can assign the administration of a domain to another DNS server.

A zone transfer involves the copying of the zone database from one DNS server to another. This is typically done to ensure name resolution availability and DNS server fault tolerance.

A DNS server can perform several roles, based on its configuration and the requirements of the site or network to which the server is connected. These server roles include the following:

  • Primary master server

  • Secondary master server

  • Caching-only server

  • DNS forwarder

  • DNS slave server

A DNS name server resolves a name to an IP address by using the following process:

  1. The client computer makes a request to the local DNS server. This generally occurs when an application tries to make a connection by using a hostname. For example, this request to the DNS server occurs when you enter www.quepublishing.com into a Web browser and the resolution is not found in the client's DNS cache.

  2. The DNS server looks in a local memory cache for names it has recently resolved. If the requested name is found in the local cache, the name server returns the IP address that the client computer requires. Most DNS servers cache both local and remote domain names in memory, so even a DNS request for a host on the local network may be in cache.

  3. The name server looks in the DNS server's host tables to see if there is a static entry (or, in the case of DDNS, a dynamic entry) for the hostname-to-IP address lookup. If an entry exists, the DNS server forwards the IP address to the client computer.

  4. If the request has not been resolved, the name server refers the request to a root name server. (Root name servers support the root of the namespace hierarchy.) At present, 13 computers support the root domain.

  5. The root name server refers the request to a name server for the Top Level Domain (TLD) in the hostname. (For example, if you have requested a host address for the quepublishing.com domain, the root name server forwards the request to the quepublishing.com DNS server.) The TLD name server refers the request to a name server for the second-level domain in the hostname, and so on, until a name server is encountered that can resolve the complete hostname.

  6. The first name server that can resolve the hostname to an IP address reports the IP address to the client computer.

Several common DNS record types are described in Table 9.

Table 9. Common DNS Record Types

Record Type

RFC

Description

CNAME

RFC 1035

Canonical Name record. A CNAME entry indicates an alias domain name for a name already specified as another resource type in this zone. CNAME is the acronym for canonical name.

ATMA

RFC 2601

ATM Address record. An ATMA record maps a DNS name to an ATM address.

A

RFC 1035

Address record. An A record maps a DNS name to an IPv4 address.

AAAA

RFC 1886

AAAA record. An AAAA record is similar to the A record. It is used to map a DNS name to an IPv6 address.

ISDN

RFC 1183

ISDN record. An ISDN record maps a DNS name to an ISDN telephone number.

MX

RFC 1035

Mail Exchanger record. An MX record is used to provide message routing to a specific mail exchanger host for a specific DNS name.

MINFO

RFC 1035

Mailbox or Mailing List Information record. An MINFO record specifies a domain mailbox name to contact. It can also specify a mailbox for error messages.

PTR

RFC 1035

Pointer record. A PTR record maps an IP address to a DNS name. This is typically used for reverse lookups or IP-address-to-DNS-name lookups.

RP

RFC 1183

Responsible Person record. An RP record specifies the domain mailbox for a responsible person for which text (TXT) records exist.

TXT

RFC 1035

Text record. A TXT record is used to hold a string of characters that serve as descriptive text to be associated with a specific DNS name.

SRV

RFC 2052

Service record. An SRV record allows administrators to use several servers for a single DNS domain, to easily move a TCP/IP service from host to host, and to designate primary and backup service hosts.

WKS

RFC 1035

Well-known service record. A WKS record is used to describe well-known TCP/IP services supported by a particular protocol (that is, TCP or UDP) on a specific IP address.

SOA

RFC 1035

Start of Authority record. An SOA is the first resource record in every correctly configured zone. It contains information about the zone and tells the DNS server that it is authoritative for a zone.


Windows Server 2003's DNS contains several significant improvements over standard DNS (including Windows NT's implementation of DNS). The improvements include the following:

  • Integrated zone tables

  • Incremental zone transfers

  • Secure DNS updates

  • DNS/DHCP integration

  • Support for stub zones

  • Conditional forwarding

  • Enhanced debug logging

  • DNSSEC extensions

  • Additional round-robin DNS capabilities

  • Support for application directory partitions

You can use the following tools to troubleshoot the basic operation of DNS:

  • ping

  • nslookup

  • The DNS server service monitoring tool

  • A Web browser

  • The Event Viewer

  • The Performance console

Standard DNS zone information is stored in flat text files located in the %systemroot%\system32\dns directory on your DNS server. Active Directory-integrated DNS zones actually store the DNS zone information within an Active Directory application partition. This makes the DNS zone information available to all Domain Controllers within a domain or even a forest that have the DNS service running on them. By using Active Directory-integrated DNS zones, every DNS server then becomes a master server for that zone, increasing security, reliability, and redundancy of that zone information. A standard DNS zone can be converted into an integrated zone after its creation, or you can create new integrated zones from scratch.

As you've no doubt noticed by now, DNS is an important network service. Active Directory, as you've also likely noticed by now, is the heart and soul of a Windows Server 2003 network infrastructure. Thus, it only stands to reason that Active Directory absolutely cannot function without a reliable and functional DNS implementation in place.

Here are some key points that emphasize the importance of DNS to Active Directory:

  • Without a properly working DNS infrastructure, Domain Controllers will not be able to replicate information about the domain among themselves.

  • Without a properly working DNS infrastructure, Windows 2000 and Windows XP client computers will experience very long logon times or possibly the inability to log on at all.

  • Without a properly working DNS infrastructure, Exchange Server 2003 and Exchange 2000 Server will not be able to work, and servers will likely fail to start critical services properly.

In short, without DNS, you won't have an Active Directory implementation.

Aging and scavenging of resource records will be important to you if you have clients that come and go from your network or have clients that have IP address changes. In all reality, that statement describes almost 100 percent of all networks that use DNS today, so aging and scavenging are useful for almost every DNS implementation to help keep records clean and up to date. By default, aging and scavenging are not enabled or configured on a newly installed Windows Server 2003 DNS server, so you'll need to perform those tasks yourself or run the risk of slowly poisoning your DNS information with outdated and conflicting resource records.

In terms of DNS, aging is the process of placing a timestamp on a dynamically created resource record and then tracking the age of that record. Scavenging, in DNS, is the process of deleting any resource records that have timestamps on them that are found to be outdated. As a result, scavenging can occur only when aging has been enabled and properly configured. In order for aging and scavenging to work correctly, they must be configured on the DNS server and also on any zones residing on that DNS server for which you want aging and scavenging to occur.

When configuring aging and scavenging for your DNS servers, you will need to understand how these options come into play:

  • No-Refresh Interval This option controls the time between the most recent refresh of a record's time stamp and when the time stamp can be refreshed again. In a very dynamic network where computers come on and leave frequently, you might want to lower this from the default, which is 7 days.

  • Refresh Interval This option sets the time between the earliest moment that a record time stamp can be refreshed and the earliest moment a record can be scavenged.

You can perform two simple tests of your DNS server's operation within the Properties tab of the server itself:

  • Simple (iterative) query A simple query, also called an iterative query, is one in which the name server provides the best response based on what that server knows from local zone files or from caching. If a name server doesn't have any information with which to answer the query, it simply sends a negative response.

  • Recursive query A recursive query forces a DNS server to respond to a request with either a failure response or a success response. With a recursive query, the DNS server must contact any other DNS servers it needs to contact in order to resolve the request. This is a much more resource-intensive query mechanism than the simple query.

Although Active Directory-integrated zones with secure dynamic updates are fairly secure, there are some more advanced configuration changes that can be made in the interest of further securing the server. While not a complete listing of items by any means, the following list presents some of the more common items that you can use to increase security:

  • Network interfaces If your DNS server has multiple network interfaces, the DNS service will by default listen for and respond to name resolution queries on all of them. You can add some security to your DNS server installation by configuring it so that it listens only on the IP address that DNS clients will be using to contact it.

  • Disabling recursion Recursion is enabled by default in Windows Server 2003 DNS, which allows the DNS server to perform recursive queries to other DNS servers on behalf of its DNS clients and other DNS servers that have forwarded queries to it for resolution. If a DNS server is not intended to perform recursive queries, you should disable them to prevent recursion from being used as an attack vector on the DNS server.

  • Securing the cache against pollution This advanced server option is enabled by default to aid in ensuring that a server's DNS cache is secured against pollution. Cache pollution can result when a DNS query response returns incorrect, nonauthoritative, or malicious data. By keeping this option enabled, the DNS server will not accept resource records in a query response that were not requested in the original query. You should not disable this protection.

  • Removing root hints If you have configured an internal DNS root in your DNS infrastructure, configure the root hints on all of your other internal DNS servers to point only to your internal DNS root server. By removing the ability for the other DNS servers to contact root servers on the Internet, you remove the possibility of accidentally disclosing your private internal information on the Internet.

  • Use a private DNS namespace If your network clients will never need to communicate with the Internet, you can use a private DNS namespace, such as quepublishing. corp, along with an internal root DNS server and applicable firewall configuration to prevent DNS-related traffic from ever leaving your organization. Note, simply using a private DNS namespace does not eliminate the ability to communicate with the Internet.

  • Use a split DNS namespace If your network clients will need to communicate with the Internet, consider using a split DNS namespace. In this model, the Internet namespace may be something like quepublishing.com while the internal namespace is something like corp.quepublishing.com. Each section of the DNS namespace should be hosted on separate DNS servers located on the applicable side of your corporate firewall. Requests made by clients internally should be forwarded to your external DNS servers if the internal DNS servers cannot provide the requested query answer. Forwarding would be accomplished by configuring your internal DNS servers to forward requests only to your external DNS servers. Additionally, you should configure your external DNS servers to forward requests only to your ISP's trusted DNS servers.

  • Use firewall rules You can configure and implement a firewall rule on your packet filtering firewall that allows TCP and UDP traffic on port 53 only between your internal and external DNS servers.

  • Harden servers You can get detailed information and assistance on hardening Windows Server 2003 servers from the Windows Server 2003 Security Guide.




MCSA(s)MCSE 70-291(c) Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure
MCSA/MCSE 70-291: Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (Exam Prep)
ISBN: 0789736497
EAN: 2147483647
Year: 2006
Pages: 196
Authors: Will Schmied

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net