Exam Objectives Fast Track

Planning for Host Name Resolution

• The design of your DNS namespace will have an effect on the security of your DNS infrastructure and the amount of effort required to administer it. At a minimum, the internal DNS namespace should either be registered or based on a registered name you own.

• The internal DNS namespace mirrors the AD domain tree. However, DNS and AD are separate from one another.

• The number of child domains or subdomains should be limited to five or fewer.

• Secondary zones can increase fault tolerance and availability, but zone transfer traffic can consume unacceptable amounts of bandwidth in some circumstances.

• Lame delegations are one of the most common sources of name resolution problems with a DNS infrastructure. As an alternative to using NS and glue address records to delegate authority, consider using stub zones or conditional forwarding.

• Conditional forwarding can reduce the amount of DNS referral traffic on the network.

• Conditional forwarding is a good alternative to using secondary or stub zones in many circumstances.

• DNS servers used for internal name resolution should never be accessible to Internet clients.

• Public DNS servers that are used to resolve name mappings for your Web and mail servers should not be able to perform recursion.

• Primary DNS servers should be configured to replicate only with a configured list of IP address or servers listed on the Name Servers tab.

• Cache pollution protection should be enabled on all DNS servers to protect against attacks.

• Publicly available DNS servers should be placed behind firewalls that have access rules controlling acceptable source and destination ports and addresses.

• Active Directory-integrated zones configured to accept authenticated updates only provide the highest level of security for dynamic updates.

Planning for NetBIOS Name Resolution

• WINS servers are capable of handling large numbers of client registrations; Microsoft recommends that as few WINS servers as possible be deployed to provide a desired level of service.

• To avoid problems with replication and name resolution, WINS servers should not be installed on multihomed computers.

• The TCP/IP stack on a WINS server should be configured so that the WINS server registers with itself.

• By default, WINS replication partnerships are set up as push/pull replication partnership. Limited partnerships (push-only and pull-only) are possible but should be avoided unless there is an overriding need to use them, such as extremely limited bandwidth.

• Push replication is triggered by a configurable number of updates in the WINS database. Push replication is used in situations where there is ample bandwidth, such as on a LAN or high-speed WAN.

• Pull replication is triggered by a configurable schedule. In general, pull replication is used in low-bandwidth situations where it is desirable to control the timing of replication traffic.

• Convergence time is the amount of time it takes an updated record to propagate to every WINS server.

• A hub-and-spoke topology is the most efficient for a replication environment involving multiple WINS servers.

• Enabling burst handling can alert administrators to the presence of possible DoS attacks because the events appear in Event Viewer.

• Static mappings should be avoided, unless they are used as a means to prevent redirection of name mappings of mission-critical servers.

Troubleshooting Name Resolution Issues

• Troubleshooting name resolution issues is more effective if a systematic approach is used to isolate the components and processes that may be causing the problem. Generally, this means troubleshooting from the bottom of the OSI model to the top.

• Client configurations are the most common source of name resolution issues and should be verified first.

• Before troubleshooting name resolution problems on the client, it is a good idea to clear the appropriate cache (DNS or NetBIOS) to eliminate that as the source of the problem.

• After the name resolution problem has been tracked down to the specific service—WINS or DNS—troubleshooting strategies appropriate to each can be employed.

• Troubleshooting tools for DNS include Ipconfig, Netdiag, NSLookup, Dnscmd, and DNSLint.

• Troubleshooting tools for WINS include Ipconfig, Netdiag, and the nbstat command.