MCSA Windows Server 2012 R2 Complete Study Guide. Panek William

and iterative queries. In this example, a client within the Microsoft Corporation is querying its DNS server for the IP address for www.whitehouse.gov.

FIGURE 2.5 A sample DNS query

      Here’s what happens to resolve the request:

      1. The resolver sends a recursive DNS query to its local DNS server asking for the IP address of www.whitehouse.gov. The local name server is responsible for resolving the name, and it cannot refer the resolver to another name server.

      2. The local name server checks its zones, and it finds no zones corresponding to the requested domain name.

      3. The root name server has authority for the root domain, and it will reply with the IP address of a name server for the .gov top-level domain.

      4. The local name server sends an iterative query for www.whitehouse.gov to the Gov name server.

      5. The Gov name server replies with the IP address of the name server servicing the whitehouse.gov domain.

      6. The local name server sends an iterative query for www.whitehouse.gov to the whitehouse.gov name server.

      7. The whitehouse.gov name server replies with the IP address corresponding to www.whitehouse.gov.

      8. The local name server sends the IP address of www.whitehouse.gov back to the original resolver.

      Inverse Queries

      Inverse queries use pointer (PTR) records. Instead of supplying a name and then asking for an IP address, the client first provides the IP address and then asks for the name. Because there’s no direct correlation in the DNS namespace between a domain name and its associated IP address, this search would be fruitless without the use of the in-addr.arpa domain. Nodes in the in-addr.arpa domain are named after the numbers in the dotted-octet representation of IP addresses. However, because IP addresses get more specific from left to right and domain names get less specific from left to right, the order of IP address octets must be reversed when building the in-addr.arpa tree. With this arrangement, administration of the lower limbs of the DNS in-addr.arpa tree can be given to companies as they are assigned their Class A, B, or C subnet address or delegated even further down thanks to Variable Length Subnet Masking (VLSM).

      Once the domain tree is built into the DNS database, a special PTR record is added to associate the IP addresses with the corresponding hostnames. In other words, to find a hostname for the IP address 206.131.234.1, the resolver would query the DNS server for a PTR record for 1.234.131.206.in-addr.arpa. If this IP address is outside of the local domain, the DNS server will start at the root and sequentially resolve the domain nodes until arriving at 234.131.206.in-addr.arpa, which would contain the PTR record for the desired host.

      Caching and Time to Live

      When a name server is processing a recursive query, it may be required to send out several queries to find the definitive answer. Name servers, acting as resolvers, are allowed to cache all of the received information during this process; each record contains information called time to live (TTL). The TTL specifies how long the record will be held in the local cache until it must be resolved again. If a query comes in that can be satisfied by this cached data, the TTL that’s returned with it equals the current amount of time left before the data is flushed.

      There is also a negative cache TTL. The negative cache TTL is used when an authoritative server responds to a query indicating that the record queried doesn’t exist, and it indicates the amount of time that this negative answer may be held. Negative caching is quite helpful in preventing repeated queries for names that don’t exist.

      The administrator for the DNS zone sets TTL values for the entire zone. The value can be the same across the zone, or the administrator can set a separate TTL for each RR within the zone. Client resolvers also have data caches and honor the TTL value so that they know when to flush.

      Choosing Appropriate TTL Values

      For zones that you administer, you can choose the TTL values for the entire zone, for negative caching, and for individual records. Choosing an appropriate TTL depends on a number of factors, including the following:

      ■ Amount of change you anticipate for the records within the zone

      ■ Amount of time you can withstand an outage that might require changing an IP address

      ■ Amount of traffic you believe the DNS server can handle

      Resolvers query the name server every time the TTL expires for a given record. A low TTL, say 60 seconds, can burden the name server, especially for popular DNS records. (DNS queries aren’t particularly intensive for a server to handle, but they can add up quickly if you mistakenly use 60 seconds instead of 600 seconds for the TTL on a popular record.) Set a low TTL only when you need to respond quickly to a changing environment.

      A high TTL, say 604,800 seconds (that’s one week), means that if you need to make a change to the DNS record, clients might not see the change for up to a week. This consideration is especially important when making changes to the network, and it’s one that’s all too frequently overlooked. I can’t count the number of times I’ve worked with clients who had recently made a DNS change to a new IP for their email or website only to ask why it’s not working for some clients. The answer can be found in the TTL value. If the record is being cached, then the only thing that can solve their problem is time.

      You should choose a TTL that’s appropriate for your environment. Take the following factors into account:

      ■ The amount of time that you can afford to be offline if you need to make a change to a DNS record that’s being cached

      ■ The amount of load that a low TTL will cause on the DNS server

      In addition, you should plan well ahead of any major infrastructure changes and change the TTL to a lower value to lessen the effect of the downtime by reducing the amount of time that the record(s) can be cached.

      Introducing DNS Database Zones

      As mentioned earlier in this chapter, a DNS zone is a portion of the DNS namespace over which a specific DNS server has authority. Within a given DNS zone, there are resource records (RRs) that define the hosts and other types of information that make up the database for the zone. You can choose from several different zone types. Understanding the characteristics of each will help you choose which is right for your organization.

       The DNS zones discussed in this book are all Microsoft Windows Server 2012 / 2012 R2 zones. Non-Windows (for example, Unix) systems set up their DNS zones differently.

      In the following sections, I will discuss the different zone types and their characteristics.

      Understanding Primary Zones

      When you’re learning about zone types, things can get a bit confusing. But it’s really not difficult to understand how they work and why you would want to choose one type of zone over the other. Zones are databases that store records. By choosing one zone type over another, you are basically just choosing how the database works and how it will be stored on the server.

      The primary zone is responsible for maintaining all of the records for the DNS zone. It contains the primary copy of the DNS database. All record updates occur on the primary zone. You will want to create and add primary zones whenever you create a new DNS domain.

      There are two types of primary zones:

      ■ Primary zone

      ■ Primary zone with Active Directory Integration