Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

4. Deploying and Configuring Core Networ... > Objective 4.3: Deploy and configure ...

Objective 4.3: Deploy and configure the DNS service

DNS is a crucial element of both Internet and Active Directory communications. All TCP/IP communication is based on IP addresses. Each computer on a network has at least one network interface, which is called a host in TCP/IP parlance, and each host has an IP address that is unique on that network. Every datagram transmitted by a TCP/IP system contains the IP address of the sending computer and the IP address of the intended recipient. However, when users access a shared folder on the network or a website on the Internet, they do so by specifying or selecting a host name, not an IP address. This is because names are far easier to remember and use than IP addresses.

This objective covers how to:

  • Configure Active Directory integration of primary zones

  • Configure forwarders

  • Configure root hints

  • Manage DNS cache

  • Create A and PTR resource records

Understanding the DNS architecture

For TCP/IP systems to use these friendly host names, they must have a way to discover the IP address associated with the name. In the early days of TCP/IP networking, each computer had a list of names and their equivalent IP addresses, called a host table. At that time, the small number of computers on the fledgling Internet made the maintenance and distribution of a single host table practical.

Today, there are millions of computers on the Internet, and the idea of maintaining and distributing a single file containing names for all of them is absurd. Instead of a host table stored on every computer, TCP/IP networks today use DNS servers to convert host names into IP addresses. This conversion process is referred to as name resolution.

At its core, the DNS is still a list of names and their equivalent IP addresses, but the methods for creating, storing, and retrieving those names are very different from those in a host table. The DNS consists of three elements:

  • The DNS namespace The DNS standards define a tree-structured namespace in which each branch of the tree identifies a domain. Each domain contains a collection of resource records that contain host names, IP addresses, and other information. Query operations are attempts to retrieve specific resource records from a particular domain.

  • Name servers A DNS server is an application running on a server computer that maintains information about the domain tree structure and (usually) contains authoritative information about one or more specific domains in that structure. The application is capable of responding to queries for information about the domains for which it is the authority and also of forwarding queries about other domains to other name servers. This enables any DNS server to access information about any domain in the tree.

  • Resolvers A resolver is a client program that generates DNS queries and sends them to a DNS server for fulfillment. A resolver has direct access to at least one DNS server and can also process referrals to direct its queries to other servers when necessary.

In its most basic form, the DNS name resolution process consists of a resolver submitting a name resolution request to its designated DNS server. When the server does not possess information about the requested name, it forwards the request to another DNS server on the network. The second server generates a response containing the IP address of the requested name and returns it to the first server, which relays the information to the resolver, as shown in Figure 4-14. In practice, however, the DNS name resolution process can be considerably more complex, as you will learn in the following sections.

DNS servers relay requests and replies to other DNS servers.

Figure 4-14. DNS servers relay requests and replies to other DNS servers.

DNS communications

Although all Internet applications use DNS to resolve host names into IP addresses, this name resolution process is easiest to see when you’re using a web browser to access an Internet site. When you type a URL containing a DNS name (for example, www.microsoft.com) into the browser’s Address box and press the Enter key, if you look quickly enough, you might be able to see a message that says something like “Finding Site: www.microsoft.com.” Then, a few seconds later, you might see a message that says “Connecting to,” followed by an IP address. It is during this interval that the DNS name resolution process occurs.

From the client’s perspective, the procedure that occurs during these few seconds consists of the application sending a query message to its designated DNS server that contains the name to be resolved. The server then replies with a message containing the IP address corresponding to that name. Using the supplied address, the application can then transmit a message to the intended destination. It is only when you examine the DNS server’s role in the process that you see how complex the procedure really is.

To better explain the relationships among the DNS servers for various domains in the namespace, the following procedure diagrams the Internet name resolution process.

  1. A user on a client system specifies the DNS name of an Internet server in an application such as a web browser. The application generates an application programming interface (API) call to the resolver on the client system, and the resolver creates a DNS recursive query message containing the server name, which it transmits to the DNS server identified in computer’s TCP/IP configuration, as shown in Figure 4-15.

    The client resolver sends a name resolution request to its DNS server.

    Figure 4-15. The client resolver sends a name resolution request to its DNS server.

  2. The client’s DNS server, after receiving the query, checks its resource records to see if it is the authoritative source for the zone containing the requested server name. If it is not, which is typical, the DNS server generates an iterative query and submits it to one of the root name servers, as shown in Figure 4-16. The root name server examines the name requested by the client’s DNS server and consults its resource records to identify the authoritative servers for the name’s top-level domain. The root name server then transmits a reply to the client’s DNS server that contains a referral to the top-level domain server addresses.

    The client’s DNS server forwards the request to a root name server.

    Figure 4-16. The client’s DNS server forwards the request to a root name server.

  3. The client’s DNS server, now in possession of the top-level domain server address for the requested name, generates a new iterative query and transmits it to the top-level domain server, as shown in Figure 4-17. The top-level domain server examines the second-level domain in the requested name and transmits a referral containing the addresses of authoritative servers for that second-level domain back to the client’s DNS server.

    The client’s DNS server forwards the request to a top-level domain server.

    Figure 4-17. The client’s DNS server forwards the request to a top-level domain server.

    Note

    COMBINING STEPS

    In the DNS name resolution process just described, the process of resolving the top-level and second-level domain names is portrayed in separate steps, but this is often not the case. The most commonly used top-level domains, such as com, net, and org, are actually hosted by the root name servers. This eliminates one referral from the name resolution process.

  4. The client’s DNS server generates another iterative query and transmits it to the second-level domain server, as shown in Figure 4-18. If the second-level domain server is the authority for the zone containing the requested name, it consults its resource records to determine the IP address of the requested system and transmits it in a reply message back to that client’s DNS server.

    The client’s DNS server forwards the request to a second-level domain server.

    Figure 4-18. The client’s DNS server forwards the request to a second-level domain server.

  5. The client’s DNS server receives the reply from the authoritative server and transmits the IP address back to the resolver on the client system, as shown in Figure 4-19. The resolver relays the address to the application, which can then initiate IP communications with the system specified by the user.

The client’s DNS server responds to the client resolver.

Figure 4-19. The client’s DNS server responds to the client resolver.

Depending on the name the client is trying to resolve, this process can be simpler or considerably more complex than the one shown here. On one hand, if the client’s DNS server is the authority for the domain in which the requested name is located, no other servers or iterative requests are necessary. On the other hand, if the requested name contains three or more levels of domains, additional iterative queries might be necessary.

This procedure also assumes a successful completion of the name resolution procedure. If any of the authoritative DNS servers queried returns an error message to the client’s DNS server stating, for example, that one of the domains in the name does not exist, then this error message is relayed back to the client and the name resolution process is said to have failed.

DNS server caching

The DNS name resolution process might seem long and complex, but in many cases it isn’t necessary for the client’s DNS server to send queries to the servers for each domain specified in the requested DNS name. This is because DNS servers are capable of retaining the information they learn about the DNS namespace in the course of their name resolution procedures and storing it in a cache on the local drive.

A DNS server that receives requests from clients, for example, caches the addresses of the requested systems and the addresses for authoritative servers of particular domains. The next time a client requests the resolution of a previously resolved name, the server can respond immediately with the cached information. In addition, if a client requests another name in one of the same domains, the server can send a query directly to an authoritative server for that domain rather than to a root name server. Thus, the names in commonly accessed domains generally resolve quickly because one of the servers along the line has information about the domain in its cache, whereas names in obscure domains take longer, because the entire request/referral process is needed.

Caching is a vital element of the DNS architecture because it reduces the number of requests sent to the root name and top-level domain servers, which, being at the top of the DNS tree, are the most likely to act as a bottleneck for the whole system. However, caches must be purged eventually, and there is a fine line between effective and ineffective caching.

Because DNS servers retain resource records in their caches, it can take hours or even days for changes made in an authoritative server to be propagated around the Internet. During this period, users might receive incorrect information in response to a query. If information remains in server caches too long, then the changes administrators make to the data in their DNS servers take too long to propagate around the Internet. If caches are purged too quickly, then the number of requests sent to the root name and top-level domain servers increases precipitously.

The amount of time that DNS data remains cached on a server is called its time to live (TTL). Unlike most data caches, the TTL is not specified by the administrator of the server where the cache is stored. Instead, the administrators of each authoritative DNS server specify how long the data for the resource records in their domains or zones should be retained in the servers where it is cached. This enables administrators to specify a TTL value based on the volatility of their server data. On a network where changes in IP addresses or the addition of new resource records is frequent, a lower TTL value increases the likelihood that clients will receive current data. On a network that rarely changes, a longer TTL value minimizes the number of requests sent to the parent servers of your domain or zone.

To modify the TTL value for a zone on a Windows Server 2012 DNS server, right-click the zone, open the Properties sheet, and click the Start Of Authority (SOA) tab, as shown in Figure 4-20. On this tab, you can modify the TTL for this record setting from its default value of one hour.

The Start Of Authority (SOA) tab on a DNS server’s Properties sheet.

Figure 4-20. The Start Of Authority (SOA) tab on a DNS server’s Properties sheet.

DNS referrals and queries

The process by which one DNS server sends a name resolution request to another DNS server is called a referral. Referrals are essential to the DNS name resolution process.

As you noticed in the process described earlier, the DNS client’s only involvement in the name resolution process is sending one query and receiving one reply. The client’s DNS server might have to send referrals to several servers before it reaches the one that has the information it needs.

DNS servers recognize two types of name resolution requests, as follows:

  • Recursive query In a recursive query, the DNS server receiving the name resolution request takes full responsibility for resolving the name. If the server possesses information about the requested name, it replies immediately to the requestor. If the server has no information about the name, it sends referrals to other DNS servers until it obtains the information it needs. TCP/IP client resolvers always send recursive queries to their designated DNS servers.

  • Iterative query In an iterative query, the server that receives the name resolution request immediately responds with the best information it possesses at the time. DNS servers use iterative queries when communicating with each other. In most cases, it would be improper to configure one DNS server to send a recursive query to another DNS server. The only time a DNS server sends recursive queries to another server is in the case of a special type of server called a forwarder, which is specifically configured to interact with other servers in this way.

DNS forwarders

One of the scenarios in which DNS servers send recursive queries to other servers is when you configure a server to function as a forwarder. On a network running several DNS servers, you might not want all the servers sending queries to other DNS servers on the Internet. If the network has a relatively slow connection to the Internet, for example, several servers transmitting repeated queries might use too much of the available bandwidth.

To prevent this, most DNS implementations enable you to configure one server to function as the forwarder for all Internet queries generated by the other servers on the network. Any time a server has to resolve the DNS name of an Internet system and fails to find the needed information in its cache, it transmits a recursive query to the forwarder, which is then responsible for sending its own iterative queries over the Internet connection. Once the forwarder resolves the name, it sends a reply back to the original DNS server, which relays it to the client.

To configure forwarders on a Windows Server 2012 DNS server, right-click the server node, open the Properties sheet, and click the Forwarders tab, as shown in Figure 4-21. On this tab, you can add the names and addresses of the servers that you want your server to use as forwarders.

The Forwarders tab on a DNS server’s Properties sheet.

Figure 4-21. The Forwarders tab on a DNS server’s Properties sheet.

Reverse name resolution

The name resolution process described earlier is designed to convert DNS names into IP addresses. However, there are occasions when it is necessary for a computer to convert an IP address into a DNS name. This is called a reverse name resolution.

Because the domain hierarchy is broken down by domain names, there is no apparent way to resolve an IP address into a name by using iterative queries, except by forwarding the reverse name resolution request to every DNS server on the Internet in search of the requested address, which is obviously impractical.

To overcome this problem, the developers of the DNS created a special domain called in-addr.arpa, specifically designed for reverse name resolution. The in-addr.arpa second-level domain contains four additional levels of subdomains. Each of the four levels consists of subdomains that are named using the numerals 0 to 255. For example, beneath in-addr.arpa, there are 256 third-level domains, which have names ranging from 0.in-addr.arpa to 255.in-addr.arpa. Each of those 256 third-level domains has 256 fourth-level domains beneath it, also numbered from 0 to 255, and each fourth-level domain has 256 fifth-level domains, as shown in Figure 4-22. Each of those fifth-level domains can have up to 256 hosts in it, also numbered from 0 to 255.

The DNS reverse lookup domain.

Figure 4-22. The DNS reverse lookup domain.

By using this hierarchy of subdomains, it is possible to express the first three bytes of an IP address as a DNS domain name and to create a resource record named for the fourth byte in the appropriate fifth-level domain. For example, to resolve the IP address 192.168.89.34 into a name, a DNS server would locate a domain called 89.168.192.in-addr.arpa in the usual manner and read the contents of a resource record named 34 in that domain.

Note

REVERSE LOOKUP ADDRESSES

In the in-addr.arpa domain, the IP address is reversed in the domain name because IP addresses have the least pertinent bit (that is, the host identifier) on the right, but DNS fully qualified domain names (FQDNs) have the host name on the left.

Deploying a DNS server

The process of deploying a DNS server on a Windows Server 2012 computer is just a matter of installing the DNS Server role by using the Add Roles and Features Wizard in Server Manager. The actual installation requires no additional input; there are no additional pages in the wizard and no role services to select.

Once you install the DNS Server role, the computer is ready to perform caching-only name resolution services for any clients that have access to it. The role also installs the DNS Manager console, which you use to configure the DNS server’s other capabilities. To configure the server to perform other services, consult the following sections.

Creating zones

A zone is an administrative entity you create on a DNS server to represent a discrete portion of the DNS namespace. Administrators typically divide the DNS namespace into zones to store them on different servers and to delegate their administration to different people. Zones always consist of entire domains or subdomains. You can create a zone that contains multiple domains as long as those domains are contiguous in the DNS namespace. For example, you can create a zone containing a parent domain and its child, because they are directly connected, but you cannot create a zone containing two child domains without their common parent, because the two children are not directly connected, as shown in Figure 4-23.

Valid zones must consist of contiguous domains.

Figure 4-23. Valid zones must consist of contiguous domains.

You can divide the DNS namespace into multiple zones and host them on a single DNS server if you want, although there is usually no persuasive reason to do so. The DNS server in Windows Server 2012 can support as many as 200,000 zones on a single server, although it is hard to imagine a scenario that would require that many. In most cases, an administrator creates multiple zones on a server and then delegates most of them to other servers, which then become responsible for hosting them.

Every zone consists of a zone database, which contains the resource records for the domains in that zone. The DNS server in Windows Server 2012 supports three zone types, which specify where the server stores the zone database and what kind of information it contains. These zone types are as follows:

  • Primary zone Creates a primary zone that contains the master copy of the zone database, where administrators make all changes to the zone’s resource records. If the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain Controller) check box is cleared, the server creates a primary master zone database file on the local drive. This is a simple text file that is compliant with most non-Windows DNS server implementations.

  • Secondary zone Creates a duplicate of a primary zone on another server. The secondary zone contains a backup copy of the primary master zone database file, stored as an identical text file on the server’s local drive. You can only update the resource records in a secondary zone by replicating the primary master zone database file, by using a process called a zone transfer.

  • Stub zone Creates a copy of a primary zone that contains the key resource records that identify the authoritative servers for the zone. The stub zone forwards or refers requests. When you create a stub zone, you configure it with the IP address of the server that hosts the zone from which you created the stub. When the server hosting the stub zone receives a query for a name in that zone, it either forwards the request to the host of the zone or replies with a referral to that host, depending on whether the query is recursive or iterative.

DNS was designed long before Active Directory, so most of the Internet relies on primary and secondary zones using text-based database files. The most common DNS server implementation on the Internet is a UNIX program called BIND that uses these databases.

However, for DNS servers supporting internal domains, especially AD DS domains, using the Windows DNS server to create a primary zone and store it in Active Directory is the recommended procedure. When you store the zone in the AD DS database, you do not have to create secondary zones or perform zone transfers, because AD DS takes the responsibility for replicating the data, and whatever backup solution you use to protect Active Directory also protects the DNS data.

Tip

EXAM TIP

Exam 70-410 covers only the process of creating a primary zone stored in Active Directory. The procedures for creating text-based primary and secondary zones and configuring zone transfers are covered on Exam 70-411, “Administering Windows Server 2012,” in Objective 3.1, “Configure DNS zones.”

Using Active Directory–Integrated Zones

When you are running the DNS server service on a computer that is an Active Directory Domain Services domain controller and you select the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain Controller) check box while creating a zone in the New Zone Wizard, the server does not create a zone database file. Instead, the server stores the DNS resource records for the zone in the AD DS database. Storing the DNS database in Active Directory provides a number of advantages, including ease of administration, conservation of network bandwidth, and increased security.

In Active Directory–integrated zones, the zone database is replicated automatically to other domain controllers, along with all other Active Directory data. Active Directory uses a multiple master replication system so that copies of the database are updated on all domain controllers in the domain. You can modify the DNS resource records on any domain controller hosting a copy of the zone database, and Active Directory will automatically update all the other domain controllers. You don’t have to create secondary zones or manually configure zone transfers, because Active Directory performs all database replication activities.

By default, Windows Server 2012 replicates the database for a primary zone stored in Active Directory to all the other domain controllers running the DNS server in the AD DS domain where the primary domain controller is located. You can also modify the scope of zone database replication to keep copies on all domain controllers throughout the enterprise or on all domain controllers in the AD DS domain, regardless of whether they are running the DNS server. You can also create a custom replication scope that copies the zone database to the domain controllers you specify.

Active Directory conserves network bandwidth by replicating only the DNS data that has changed since the last replication and by compressing the data before transmitting it over the network. The zone replications also use the full security capabilities of Active Directory, which are considerably more robust than those of file-based zone transfers.

Creating an Active Directory Zone

To create a new primary zone and store it in Active Directory, use the following procedure.

  1. Log on to the Windows Server 2012 domain controller using an account with Administrative privileges. The Server Manager window opens.

  2. Click Tools > DNS to open the DNS Manager console.

  3. Expand the server node and select the Forward Lookup Zones folder.

  4. Right-click the Forward Lookup Zones folder and, from the shortcut menu, select New Zone. The New Zone Wizard starts.

  5. Click Next to bypass the Welcome page and open the Zone Type page.

  6. Leave the Primary Zone option and the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain Controller) check box selected and click Next. The Active Directory Zone Replication Scope page opens.

  7. Click Next. The Zone Name page opens.

  8. Specify the name you want to assign to the zone in the Zone Name text box and click Next. The Dynamic Update page opens.

  9. Select one of the following options:

    • Allow Only Secure Dynamic Updates

    • Allow Both Nonsecure And Secure Dynamic Updates

    • Do Not Allow Dynamic Updates

  10. Click Next. The Completing the New Zone Wizard page opens.

  11. Click Finish. The wizard creates the zone.

  12. Close the DNS Manager console.

Once you have created a primary zone, you can proceed to create resource records that specify the names of the hosts on the network and their equivalent IP addresses.

Creating resource records

When you run your own DNS server, you create a resource record for each host name that you want to be accessible by the rest of the network.

There are several different types of resource records used by DNS servers, the most important of which are as follows:

  • SOA (Start of Authority) Indicates that the server is the best authoritative source for data concerning the zone. Each zone must have an SOA record, and only one SOA record can be in a zone.

  • NS (Name Server) Identifies a DNS server functioning as an authority for the zone. Each DNS server in the zone (whether primary master or secondary) must be represented by an NS record.

  • A (Address) Provides a name-to-address mapping that supplies an IPv4 address for a specific DNS name. This record type performs the primary function of the DNS: converting names to addresses.

  • AAAA (Address) Provides a name-to-address mapping that supplies an IPv6 address for a specific DNS name. This record type performs the primary function of the DNS: converting names to addresses.

  • PTR (Pointer) Provides an address-to-name mapping that supplies a DNS name for a specific address in the in-addr.arpa domain. This is the functional opposite of an A record, used for reverse lookups only.

  • CNAME (Canonical Name) Creates an alias that points to the canonical name (that is, the “real” name) of a host identified by an A record. Administrators use CNAME records to provide alternative names by which systems can be identified.

  • MX (Mail Exchanger) Identifies a system that will direct email traffic sent to an address in the domain to the individual recipient, a mail gateway, or another mail server.

Tip

EXAM TIP

Exam 70-410 covers only the process of creating A and PTR resource records. The procedures for creating other resource record types are covered on Exam 70-411, “Administering Windows Server 2012,” in Objective 3.2, “Configure DNS records.”

To create a new Address resource record, use the following procedure.

  1. Log on to Windows Server 2012 using an account with Administrative privileges. The Server Manager window opens.

  2. Click Tools > DNS to open the DNS Manager console.

  3. Expand the server node and select the Forward Lookup Zones folder.

  4. Right-click the zone in which you want to create the record and, from the shortcut menu, select New Host (A or AAAA). The New Host dialog box appears, as shown in Figure 4-24.

    The New Host dialog box.

    Figure 4-24. The New Host dialog box.

  5. In the Name text box, type the host name for the new record. The FQDN for the record appears.

  6. In the IP Address text box, type the IPv4 or IPv6 address associated with the host name.

  7. Select the following check boxes, if necessary:

    • Create Associated Pointer (PTR) Record Creates a reverse name lookup record for the host in the in-addr.arpa domain

    • Allow Any Authenticated User To Update DNS Records With The Same Owner Name Enables users to modify their own resource records

  8. Click Add Host. The new resource record is created in the zone you selected.

  9. Close the DNS Manager console.

To create a PTR record for a new host, you can select the Create Associated Pointer (PTR) Record check box in the New Host dialog box, but that will only be effective if a reverse lookup zone already exists on the server. To create the zone, you follow the same procedure described earlier, this time selecting the Reverse Lookup Zones folder.

When you elect to create an IPv4 reverse lookup zone, a Reverse Lookup Zone Name page opens, like the one shown in Figure 4-25, in which you supply the Network ID that the wizard will use to create the zone.

A Reverse Lookup Zone Name page in the New Zone Wizard.

Figure 4-25. A Reverse Lookup Zone Name page in the New Zone Wizard.

Once the zone is created, you can either create PTR records along with A or AAAA records or create a new PTR record by using the New Resource Record dialog box.

Configuring DNS server settings

Once you have installed a DNS server and created zones and resource records on it, there are many settings you can alter to modify its behavior. The following sections describe some of these settings.

Configuring Active Directory DNS Replication

To modify the replication scope for an Active Directory–integrated zone, open the zone’s Properties sheet in the DNS Manager console and, on the General tab, click Change for Replication: All DNS Servers In The Active Directory Domain to display the Change Zone Replication Scope dialog box, shown in Figure 4-26. The options are the same as those in the New Zone Wizard.

The Change Zone Replication Scope dialog box.

Figure 4-26. The Change Zone Replication Scope dialog box.

Configuring Root Hints

Every DNS server must be able to contact the root name servers to initiate name resolution processes. Most server implementations, including Microsoft DNS Server, are preconfigured with the names and addresses of multiple root name servers. These are called root hints.

The 13 root name server names are located in a domain called root-servers.net and are named using letters of the alphabet. The servers are scattered around the world on different subnets to provide fault tolerance.

To modify the root hints on a Windows Server 2012 DNS server, right-click the server node, open the Properties sheet, and click the Root Hints tab, as shown in Figure 4-27. On this tab, you can add, edit, or remove root hints from the list provided.

The Root Hints tab on a DNS server’s Properties sheet.

Figure 4-27. The Root Hints tab on a DNS server’s Properties sheet.

Objective summary

  • DHCP is a service that automatically configures the IP address and other TCP/IP settings on network computers by assigning addresses from a pool (called a scope) and reclaiming them when they are no longer in use.

  • TCP/IP networks today use DNS servers to convert host names into IP addresses. This conversion process is referred to as name resolution.

  • DNS consists of three elements: the DNS namespace, name servers, and resolvers.

  • The hierarchical nature of the DNS namespace is designed to make it possible for any DNS server on the Internet to locate the authoritative source for any domain name by using a minimum number of queries.

  • In a recursive query, the DNS server receiving the name resolution request takes full responsibility for resolving the name. In an iterative query, the server that receives the name resolution request immediately responds with the best information it possesses at the time.

  • For Internet name resolution purposes, the only functions required of the DNS server are the ability to process incoming queries from resolvers and send its own queries to other DNS servers on the Internet.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the Answers section at the end of this chapter.

  1. Which of the following resource record types contains the information a DNS server needs to perform reverse name lookups?

    1. A

    2. CNAME

    3. SOA

    4. PTR

  2. Which of the following would be the correct FQDN for a resource record in a reverse lookup zone if the computer’s IP address is 10.75.143.88?

    1. 88.143.75.10.in-addr.arpa

    2. 10.75.143.88.in-addr.arpa

    3. in-addr.arpa.88.143.75.10

    4. arpa.in-addr.10.75.143.88

  3. Which of the following is not one of the elements of DNS?

    1. Resolvers

    2. Relay agents

    3. Name servers

    4. Namespace

  4. In which of the following DNS transactions does the querying system generate a recursive query?

    1. A DNS client sends the server name www.adatum.com from a URL to its designated DNS server for resolution.

    2. A client’s DNS server sends a request to a root domain server to find the authoritative server for the com top-level domain.

    3. A client’s DNS server sends a request to the com top-level domain server to find the authoritative server for the adatum.com domain.

    4. A client’s DNS server sends a request to the adatum.com domain server to find the IP address associated with the server name www.

  5. Which of the following contains the controls used to modify DNS name caching?

    1. The Forwarders tab of a server’s Properties sheet

    2. The Start of Authority (SOA) tab of a zone’s Properties sheet

    3. The Root Hints tab of a server’s Properties sheet

    4. The New Zone Wizard

Thought experiment

In the following thought experiment, apply what you’ve learned about this objective to predict what steps you need to take. You can find answers to these questions in the Answers section at the end of this chapter.

Alice is an enterprise administrator for Wingtip Toys, which has recently expanded its Customer Service division by adding 100 workstations. All the workstations on the company network are configured to use a server on the perimeter network as their primary DNS server and a server on their ISP’s network as a secondary server. As a result of the expansion, Internet performance has slowed noticeably, and a Network Monitor trace indicates that there is a disproportionate amount of DNS traffic on the link between the perimeter network and the ISP’s network.

With this in mind, answer the following question:

What are two ways that Alice can reduce the amount of DNS traffic passing over the Internet connection?

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint