Implement Domain Name System

  • 2/16/2017

In this sample chapter from Exam Ref 70-741 Networking with Windows Server 2016, learn how to create and manage Domain Name System (DNS) zones using the Windows Server 2016 DNS server role—and how to create and manage host and service-related records within these zones.

Typically, users and computers use host names rather than Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) network addresses to communicate with other hosts and services on networks. A Windows Server 2016 service, known as the Domain Name System (DNS) server role, resolves these names into IPv4 or IPv6 addresses.

Since many important apps and services rely on the DNS server role, it is important that you know how to install and configure Windows Server 2016 name resolution using the DNS server role. As a result, the 70-741 Networking Windows Server 2016 exam covers how to install and configure the DNS server role on Windows Server 2016.

The 70-741 Networking Windows Server 2016 exam also covers how to implement zones and Domain Name System records using the DNS server role. It is therefore important that you know how to create and manage DNS zones using the Windows Server 2016 DNS server role, and how to create and manage host and service-related records within these zones.

Skill 1.1: Install and configure DNS servers

Windows Server 2016 provides the DNS server role to enable you to provide name resolution services to devices and computers in your organization’s network infrastructure. The first stage to provide name resolution is to deploy the DNS server role on Windows Server 2016 server computers.

Overview of name resolution

Although IP addressing is not especially complex, it is easier for users to work with host names rather than with the IPv4 or IPv6 addresses of hosts, such as websites, to which they want to connect. When an application, such as Microsoft Edge, references a website name, the name in the URL is converted into the underlying IPv4 or IPv6 address using a process known as name resolution. Windows 10 and Windows Server 2016 computers can use two types of names. These are:

  • Host names A host name, up to 255 characters in length, contains only alphanumeric characters, periods, and hyphens. A host name is an alias combined with a DNS domain name. For example, the alias computer1, is prefixed to the domain name,, to create the host name, or Fully Qualified Domain Name (FQDN),

  • NetBIOS names Less relevant today, NetBIOS names use a nonhierarchical structure based on a 16-character name. The sixteenth character identifies a particular service running on the computer named by the preceding 15 characters. Thus, LON-SVR1[20h] is the NetBIOS server service on the computer named LON-SVR1.

The method in which a Windows 10 or Windows Server 2016 computer resolves names varies based on its configuration, but it typically works as shown in Figure 1-1.


FIGURE 1-1 Typical stages of name resolution in a Windows Server computer

The following process identifies the typical stages of name resolution for a Windows 10 or Windows Server 2016 computer.

  1. Determine whether the queried host name is the same as the local host name.

  2. Search the local DNS resolver cache for the queried host name. The cache is updated when records are successfully resolved. In addition, the content of the local Hosts file is added to the resolver cache.

  3. Petition a DNS server for the required host name.

Of course, name resolution in Windows Server 2016 does more than just provide for simple name to IP mapping. The DNS server role is also used by computers to locate services within the network infrastructure. For example, when a computer starts up, the user must sign-in to the Active Directory Domain Services (AD DS) domain and perhaps open Microsoft Office Outlook. This means that the client computer must locate a server that can provide authentication services in the local AD DS site, and furthermore, locate the appropriate Microsoft Exchange mailbox server for the user. These processes require DNS.

Determine DNS installation requirements

Before you can install the DNS server role, you must verify that your server computer meets the installation requirements of the role.

The DNS server role installation requirements are:

  • Security You must sign in on the server computer as a member of the local Administrators group.

  • IP configuration The server must have a statically assigned IPv4 and/or IPv6 configuration. This ensures that client computers can locate the DNS server role by using its IP address.

In addition to these server requirements, you must also be prepared to answer questions that relate to your organization’s network infrastructure. These organizational questions pertain to your Internet presence, and the registered domain names that you intend to use publicly. Although you need not define these domain names during DNS role installation, you must provide this information when you configure the DNS role.

Install the DNS server role

You can install the DNS server role by using Server Manager, or by using Windows PowerShell.

Installing DNS with Server Manager

To install the DNS server role with Server Manager, use the following procedure:

  1. Sign in to the target server as a local administrator.

  2. Open Server Manager.

  3. In Server Manager, click Manage and then click Add Roles And Features.

  4. In the Add Roles And Features Wizard’s Before You Begin page, click Next.

  5. On the Select Installation Type page, click Role-Based or Feature-Based Installation, and click Next.

  6. On the Select Destination Server page, select the server from the Server Pool list, and click Next.

  7. In the Roles list on the Select Server Roles page, select the DNS Server (see Figure 1-2).

    FIGURE 1-2

    FIGURE 1-2 Installing the DNS Server role by using Server Manager

  8. In the Add Roles And Features Wizard pop-up dialog box, click Add Features, and then click Next.

  9. On the Select features page, click Next.

  10. On the DNS Server page, click Next.

  11. On the Confirm Installation Selections page, click Install. When the installation is complete, click Close.

Installing DNS with Windows PowerShell

Although using Server Manager to install server roles and features is simple, it is not always the quickest method. To install the DNS server role and all related management tools by using Windows PowerShell, use the following procedure:

  1. Sign in to the target server as a local administrator.

  2. Open an elevated Windows PowerShell window.

  3. At the Windows PowerShell prompt, as shown in Figure 1-3, type the following command and press Enter:

    Add-WindowsFeature DNS -IncludeManagementTools

    FIGURE 1-3

    FIGURE 1-3 Installing the DNS Server with Windows PowerShell

Determine supported DNS deployment scenarios on Nano Server

Nano Server is a new Windows Server 2016 deployment option. It is similar to Windows Server Core, but has much smaller hardware requirements. Nano Server also has very limited local sign-in capabilities and local administration function, and supports only 64-bit apps, agents, and tools.

There are a number of situations when you should consider choosing Nano Server over other Windows Server deployment options. For example, Nano Server provides a good platform for a web server running Internet Information Services (IIS). Also, Nano Server is ideally suited to run the DNS server role.

To install the DNS server role on Nano Server, you can use one of the following two strategies.

  • Install the DNS server role as part of the Nano Server deployment When you deploy Nano Server with the New-NanoServerImage cmdlet, you can use the -Packages Microsoft-NanoServer-DNS-Package parameter to install the DNS server role.

  • Add the role after deployment After you have deployed Nano Server, you can add the DNS server role by using either Server Manager or Windows PowerShell. However, since Nano Server is a headless server platform with very little local management capability, you must remotely manage the server.

You can add the role to Nano server using one of the following methods:

  • From Server Manager, use the Add Other Servers To Manage option to add the Nano Server as a manageable server. Then add the DNS Server role to the server using the procedure outlined earlier in this chapter (see “Installing DNS with Server Manager”).

  • Establish a Windows PowerShell remoting session with the Nano Server by using the Enter-PSSession cmdlet. You can then use Windows PowerShell cmdlets to install the DNS server role, as described earlier in this chapter. For example, to add the DNS role to a Nano Server from a Windows PowerShell remote session, use the following command:

    Enable-WindowsOptionalFeature -Online -FeatureName DNS-Server-Full-Role

Configure forwarders, root hints, recursion, and delegation

After you have installed the DNS server role on your Windows Server 2016 server computer, you must configure it. This involves configuring forwarding, root hints, recursion, and delegation.

Configure forwarders

DNS forwarding enables you to define what happens to a DNS query when the petitioned DNS server is unable to resolve that DNS query. For example, you can configure and use DNS forwarding to control the flow of DNS requests throughout your organization so that only specific DNS servers are used to handle Internet DNS queries.

With DNS forwarding, you can:

  • Configure a DNS server only to respond to those queries that it can satisfy by reference to locally stored zone information. For all other requests, the petitioned DNS server must forward the request to another DNS server.

  • Define the forwarding behavior for specific DNS domains by configuring DNS conditional forwarding. In this scenario, if the DNS query contains a specific domain name, for example, then it is forwarded to a specific DNS server.

To configure forwarding, use the following procedure:

  1. In Server Manager, click Tools, and then click DNS.

  2. In DNS Manager, right-click the DNS server in the navigation pane and click Properties.

  3. In the Server Properties dialog box, on the Forwarders tab, click Edit.

  4. In the IP Address list located in the Edit Forwarders dialog box, enter the IP address of the server to which you want to forward all DNS queries, and then click OK. You can configure several DNS servers here; those servers are petitioned in preference order. You can also set a timeout value, in seconds, after which the query is timed out

  5. In the Server Properties dialog box on the Forwarders tab you can view and edit the list of DNS forwarders, as shown in Figure 1-4. You can also determine what happens when no DNS forwarders can be contacted. By default, when forwarders cannot be contacted, root hints are used. Root hints are discussed in the next section. Click OK to complete configuration.

    FIGURE 1-4

    FIGURE 1-4 Configuring DNS forwarding

To enable and configure conditional forwarding, use the following procedure:

  1. In DNS Manager, right-click the Conditional Forwarders node in the navigation pane, and then click New Conditional Forwarder.

  2. On the New Conditional Forwarder dialog box, in the DNS Domain box, type the domain name for which you want to create a conditional forward, as shown in Figure 1-5. Next, in the IP address of the master servers list, enter the IP address of the server to use as a forwarder for this domain; press Enter.

    FIGURE 1-5

    FIGURE 1-5 Configuring conditional DNS forwarding

  3. Optionally, specify the Number of Seconds Before Forward Queries Time Out value. The default value is 5 seconds.

  4. Click OK.

Configure root hints

If you do not specify DNS forwarding, then when a petitioned DNS server is unable to satisfy a DNS query, it uses root hints to determine how to resolve it. Before we look at root hints, it is important that you understand how an Internet DNS query is handled.

How an Internet DNS Query is Handled

A client app, such as Microsoft Edge, wants to resolve a name (like to the relevant IPv4 address. This app is referred to as a DNS client. The process used to resolve this name is described next and is shown in Figure 1-6.


FIGURE 1-6 How Internet DNS queries work

  1. The DNS client petitions its configured DNS server for the required record (for example, using a recursive query.

    • The petitioned DNS server checks to see if it is authoritative for the required record. If it is, it returns the requested information.

    • If it is not authoritative, the DNS server checks its local cache to determine if the record was recently resolved. If the record exists in cache, it is returned to the petitioning client.

  2. If the record is not cached, then the DNS server uses a series of iterative queries to other DNS servers in which it requests the petitioned record. It starts with the root server.

  3. The record returns it if the root server is authoritative for the requested record. Otherwise, the root server returns the IP address of a DNS server authoritative for the next down-level domain, in this instance .com.

  4. The original DNS server petitions the specified .com DNS server using another iterative query.

  5. The .com DNS server is not authoritative, and so returns the IP address of the DNS server.

  6. The original DNS server petitions the specified DNS server using another iterative query.

  7. The DNS server is authoritative, and so returns the required information—in this case, the IPv4 address for

  8. The original DNS server caches the record and returns the requested information to the DNS client.

How Root Hints are Used

As you can see in the preceding explanation and diagram, if a DNS server is not authoritative and holds no cache for that DNS domain, it petitions a root server to start the process of determining which server is authoritative for the petitioned record. However, without the IP address of the root name servers, this process cannot begin.

Root hints are used by DNS servers to enable them to navigate the DNS hierarchy on the Internet, starting at the root. Microsoft DNS servers are preconfigured with the relevant root hint records. However, you can modify the list of root hint servers by using the DNS Manager console or by using Windows PowerShell.

You might consider editing the root hints information if you want to configure the flow of DNS query traffic within your internal network. This is also useful between your internal network and the boundary network, which sits between your internal network and the Internet.

Editing Root Hints

To modify the root hints information using DNS Manager, use the following procedure:

  1. In Server Manager, click Tools, and then click DNS.

  2. In the DNS Manager console, locate the appropriate DNS server. Right-click the server and click Properties.

  3. In the server Properties dialog box, click the Root Hints tab, as shown in Figure 1-7.

    FIGURE 1-7

    FIGURE 1-7 Configuring root hints

  4. You can then add new records, or edit or remove any existing records. You can also click Copy From Server to import the root hints from another online DNS server. Click OK when you have finished editing root hints.

Also, you can use Windows PowerShell to modify the root hints information on your DNS server. The following cmdlets are available to manage root hints:

  • Add-DnsServerRootHint Enables you to add new root hints records.

  • Remove-DnsServerRootHint Enables you to delete root hints records.

  • Set-DnsServerRootHint Enables you to edit existing root hints records. You can also use the Get-DnsServerRootHint cmdlet to retrieve the required record for editing.

  • Import-DnsServerRootHint Enables you to copy the root hints information from another online DNS server.

For example, to update the value for the root hints assigned to, use the following two Windows PowerShell commands:

$hint = (Get-DnsServerRootHint | Where-Object {$_.NameServer.RecordData.NameServer
-eq ""} )

$hint.IPAddress[0].RecordData.Ipv4address = ""

The first command obtains the root hint and assigns it to the variable $hint. The Get-DnsServerRootHint cmdlet obtains the list of all root hints, and the Where-Object cmdlet filters the results to get only the root hint for

Configure recursion

Recursion is the name resolution process when a petitioned DNS server queries other DNS servers to resolve a DNS query on behalf of a requesting client. The petitioned server then returns the answer to the DNS client. By default, all DNS servers perform recursive queries on behalf of their DNS clients and other DNS servers that have forwarded DNS client queries to them.

However, since malicious people can use recursion as a means to attempt a denial of service attack on your DNS servers, you should consider disabling recursion on any DNS server in your network that is not intended to receive recursive queries.

To disable recursion, use the following procedure:

  1. From Server Manager, click Tools, and then click DNS.

  2. In the DNS Manager console, right-click the appropriate server, and then click Properties.

  3. Click the Advanced tab, and then in the Server options list, select the Disable Recursion (Also Disables Forwarders) check box, as shown in Figure 1-8, and then click OK.

    FIGURE 1-8

    FIGURE 1-8 Disabling recursion

Recursion Scopes

While it might seem like a good idea to disable recursion, there are servers that must perform recursion for their clients and other DNS servers. However, these are still at risk from malicious network attacks. Windows Server 2016 supports a feature known as recursion scopes, which allow you to control recursive query behavior. To do this, you must use DNS Server Policies.

For example, you might have a DNS server that should be able to perform recursive queries for internal clients within the domain, but should not accept any recursive queries from Internet-based computers. To configure this behavior, open Windows PowerShell and then run the following two commands:

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalAdatumClients" -EnableRecursion $True

The first command disables recursion for the default recursion scope, which as a result, turns off recursion. The default scope consists of the server-level recursion and forwarding settings that we previously discussed (see “Configure forwarders, root hints, recursion, and delegation,” in this chapter).

The second command creates a new recursion scope called InternalAdatumClients. Recursion is enabled for clients in this scope. Next, you must define which clients are part of the recursion scope. Use the following Windows PowerShell command to achieve this:

Add-DnsServerQueryResolutionPolicy -Name "RecursionControlPolicy" -Action ALLOW
-ApplyOnRecursion -RecursionScope "InternalAdatumClients" -ServerInterfaceIP

In this example, client requests received on the DNS server interface with the IP are evaluated as belonging to InternalAdatumClients, and recursion is enabled. For client requests received on other server interfaces, recursion is disabled.

Configure delegation

This content is covered in Chapter 1, Implement Domain Name System: “Configure delegation.”

Configure advanced DNS settings

Configuring forwarding, recursion, and root hints enables you to control the fundamentals of how DNS queries are processed within your organization. After you have configured these settings, you can move on to enable and configure more advanced settings.

Configure DNSSEC

DNSSEC is a security setting for DNS that enables all the DNS records in a DNS zone to be digitally signed so DNS clients are able to verify the identity of the DNS server. DNSSEC helps ensure that the DNS client is communicating with a genuine DNS server.

When a client queries a DNS server that has been configured with DNSSEC, the server returns any DNS results along with a digital signature. To ensure that the signature is valid, the DNS client obtains the public key of the public/private key pair associated with this signature from a trust anchor. In order for this to work, you must configure your DNS clients with a trust anchor for the signed DNS zone.

Trust Anchors

To implement DNSSEC, you must create a TrustAnchors zone. This zone is used to store public keys associated with specific DNS zones. You must create a trust anchor from the secured zone on every DNS server that hosts the zone.

Name Resolution Policy Table

Additionally, you must create, configure, and distribute a Name Resolution Policy Table (NRPT). A DNSSEC rule in the NRPT is used by clients to determine DNS client behavior and is used by DNSSEC to instruct the client to request validation through the use of a signature.

Implementing Dnssec

After installing Windows Server 2016 and deploying the DNS server role to the server, use the following procedure to implement DNSSEC:

  1. Launch the DNSSEC Configuration Wizard from the DNS Manager console to sign the DNS zone. In DNS Manager, right-click the desired zone, point to DNSSEC, and then click Sign The Zone. When you sign the zone, as shown in Figure 1-9, you can choose between three options.

    FIGURE 1-9

    FIGURE 1-9 Signing a DNS zone

    • Customize Zone Signing Parameters Enables you to configure all values for the Key Signing Key (KSK) and the Zone Signing Key (ZSK).

    • Sign The Zone With Parameters Of An Existing Zone Enables you to use the same values and options as an existing signed zone.

    • Use Default Settings To Sign The Zone Signs the zone using default values.

  2. Configure Trust Anchor Distribution Points You can choose this option if you select the Customize Zone Signing Parameters option above. Otherwise, after you have signed the zone, use the following procedure to configure trust anchor distribution points:

    1. In DNS Manager, right-click the desired zone, point to DNSSEC, and then click Properties.

    2. In the DNSSEC Properties For Selected Zone dialog box, on the Trust Anchor tab, as shown in Figure 1-10, select the Enable The Distribution Of Trust Anchors For This Zone check box, and click OK. When prompted, click Yes, and then click OK.

      FIGURE 1-10

      FIGURE 1-10 Enabling trust anchor distribution

    3. Verify that the Trust Points node exists and contains the relevant DNS KEY (DNSKEY) records. To do this, in DNS Manager, expand the Server node and then expand Trust Points. It contains sub nodes for your DNS zones, which contain two DNS KEY (DNSKEY) records.

  3. Configure the NRPT on the client computers You must distribute the NRPT to all client computers so that they know to request validation using DNSSEC. The easiest way to achieve this is to use GPO distribution:

    1. Open Group Policy Management and locate the Default Domain Policy.

    2. Open this policy for editing and navigate to Computer Configuration / Policies / Windows Settings / Name Resolution Policy, as shown in Figure 1-11.

      FIGURE 1-11

      FIGURE 1-11 Creating the NRPT GPO

    3. In the Create Rules section, type the name of your domain (for example, in the Suffix text box; doing so applies the rule to the suffix of that namespace.

    4. Select the Enable DNSSEC in this Rule check box, select the Require DNS Clients To Check That The Name And Address Data Has Been Validated By The DNS Server check box, and then click Create.

Configure DNS socket pool

You can use the DNS socket pool to enable a DNS server to use a random source port when issuing DNS queries. If you enable DNS socket pool the DNS server selects a source port from a pool of available sockets when the DNS service starts. This means that the DNS server avoids using well-known ports. This can help to secure the DNS server because a malicious person must guess both the source port of a DNS query and a random transaction ID to successfully run a malicious attack.

You can use the DNSCMD.exe command-line tool to configure the DNS socket pool size.

From an elevated command prompt, run the dnscmd /Config /SocketPoolSize <value> command and then restart the DNS server. You can configure the socket pool size from 0 through 10,000. The default pool size is 2,500.

Configure cache locking

When a DNS client queries a recursive DNS server, the server caches the result so that it can respond more quickly to other DNS clients querying the same information. The amount of time that a record resides in cache is determined by the Time To Live (TTL) value of the record.

During the TTL, a record can be overwritten if more recent data is available for the record. However, this potentially exposes a security issue. A malicious person might be able to overwrite the record in cache with information that could redirect clients to a site containing unsafe content.

To mitigate this risk in Windows Server 2016, you can use cache locking to determine when information in the DNS resolver cache can be overwritten. When you enable cache locking, the DNS server does not allow updates to cached records until the TTL expires.

To configure cache locking, on your DNS server, run the Set-DnsServerCache –LockingPercent <value> Windows PowerShell command. The <value> you enter is a percentage of the TTL. For example, if you type 75, then the DNS server does not allow updates to the cached record until at least 75 percent of the TTL has expired.

Enable response rate limiting

Another security feature you can use in Windows Server 2016 is response rate limiting, which is as a defense against DNS denial-of-service attacks. One common DNS denial-of-service attack is to fool DNS servers into sending large amounts of DNS traffic to particular DNS servers, thus overloading the target servers.

When a configured DNS server with response rate limiting identifies potentially malicious requests, it ignores them instead of propagating them. The DNS server can identify potentially malicious requests because many identical requests in a short time period from the same source are suspicious.

By default, response rate limiting is disabled. To enable response rate limiting, run the Set-DnsServerResponseRateLimiting Windows PowerShell command. This enables response rate limiting using the default values. You can also supply command parameters to customize response rate limiting.

Configure DNS-based authentication of named entities

Windows Server 2016 supports a new feature known as DNS-Based Authentication of Named Entities (DANE). This feature relies on using Transport Layer Security Authentication (TLSA) and can help reduce man-in-the-middle type attacks on your network.

DANE works by informing DNS clients requesting records from your domain from which Certification Authority (CA) they must expect digital certificates to be issued. For example, suppose a DNS client requests the IPv4 address relating to the record The DNS server provides the requested IPv4 address and related information. However, the DNS server also provides information that the certificate used to authenticate the identity of the webserver is provided by a particular CA.

Administering DNS

It is important that you know how to administer your DNS servers. You can use tools such as Windows PowerShell and the DNS Manager console to interactively administer the DNS servers in your organization. However, in large enterprise environments, it can be difficult to keep on top of administration of such a critical service. In these circumstances, you can consider implementing DNS policies, delegating DNS administration to a specialist team, and using DNS logging as an indicator of potential problems with DNS.

Implement DNS policies

DNS Policy is a new feature in Windows Server 2016 that enables you to control how a DNS server behaves in a particular set of circumstances. For example, we have already seen how you can implement recursion scopes to control DNS recursion based on certain factors; this is an example of a DNS policy in action.

You can create one or several DNS policies as your organizational needs dictate. However, common reasons for implementing DNS policies include:

  • Application high availability The DNS server redirects clients to the healthiest endpoint for an application based, for example, on high availability factors in a failover cluster.

  • Traffic management The DNS server redirects clients to the nearest server or datacenter.

  • Split-brain DNS The DNS server responds to clients based on whether the client is external or internal to your organization’s intranet.

  • Filtering The DNS server blocks DNS queries if they are from malicious hosts.

  • Forensics The DNS server redirects malicious DNS clients to a sinkhole instead of the host they are attempting to reach.

  • Time-of-day based redirection The DNS server redirects clients to servers or datacenters based on the time.

To implement DNS policies, you must use Windows PowerShell commands. However, you must first be able to classify groups of records in a DNS zone, DNS clients on a specific network, or other characteristics that can help identify the DNS clients. You can use the following DNS objects to characterize your DNS clients:

  • Client subnet The IPv4 or IPv6 subnet containing the DNS clients.

  • Recursion scope The unique instances of a group of settings that control DNS server recursion.

  • Zone scopes Contains its own set of DNS resource records. A record can exist in several scopes, each with a different IP address depending on the scope. DNS zones can have multiple zone scopes.

To implement DNS policies, you must first define one or more of the above objects to classify your DNS clients and scopes.

  1. For example, to create a subnet for DNS clients in New York, use the following command:

    Add-DnsServerClientSubnet -Name "NYCSubnet" -IPv4Subnet ""
  2. You need to create multiple client subnet objects based on the IPv4 or IPv6 subnet address.

  3. Next, you create a DNS zone scope for New York DNS clients by using the following command:

    Add-DnsServerZoneScope -ZoneName "" -Name "NYCZoneScope"
  4. Again, you would need to create multiple zone scopes based on your requirements.

  5. Next, to create a specific IP address record for clients in the New York City zone scope, run the following command:

    Add-DnsServerResourceRecord -ZoneName "" -A -Name "www" -IPv4Address
    "" -ZoneScope "NYCZoneScope"
  6. Finally, you create the policy that instructs the DNS server to respond based upon the previously defined factors:

    Add-DnsServerQueryResolutionPolicy -Name "NYCPolicy" -Action ALLOW -ClientSubnet
    "eq,NYCSubnet" -ZoneScope "NYCZoneScope,1" -ZoneName ""

Now, if a client in the New York subnet petitions a DNS server for the IPv4 address of the host, the DNS server responds with the IP address If you create other subnets and zone scopes for other locations, you could instruct the DNS server to respond with a different IP address for client queries from other locations.

Configure delegated administration

By default, the following groups have administrative capabilities over your organization’s DNS servers:

  • Domain Admins Has full permissions to manage all aspects of the DNS server in its home domain.

  • Enterprise Admins Has full permissions to manage all aspects of all DNS servers in any domain in your AD DS forest.

  • DnsAdmins Can view and modify all DNS data, settings, and configurations of DNS servers in their home domain.

In a small to medium network, it is generally acceptable to use these defaults. However, in large network environments, it can be beneficial to delegate administration for aspects of DNS management to different teams.

If you decide to delegate DNS Server administration to a different user or group, you can add that user or group to the DnsAdmins group for a given domain in the forest. To modify membership of this group, you can use Active Directory Users and Computers or the Windows PowerShell Add-ADGroupMember cmdlet.

To configure DNS administrative permissions, right-click the appropriate DNS server or DNS zone in the DNS Manager console, and then click Properties. n the Server Properties or Zone Properties dialog box, on the Security tab, you can view and modify permissions for the server or zone, as shown in Figure 1-12.


FIGURE 1-12 Delegating DNS administration

Configure DNS logging

Enabling logging can be very beneficial for proactive monitoring, especially when you are investigating poor performance or spurious and unexpected service behavior. By default, DNS records events into a DNS server log that you can review using Event Viewer. The DNS server log is located under the Application and Services Logs node, as shown in Figure 1-13.


FIGURE 1-13 Viewing the DNS server event log

This log contains common DNS related events, such as service starts and stops, zone signing events, configuration changes, and common warnings and errors.

You can also enable more detailed logging with debug logging. However, you should exercise caution when enabling debug logging as it can impose load on the DNS server that might impact service delivery. Debug logging provides the following additional details:

  • Packet direction (Outgoing or Incoming)

  • Packet contents (Queries/Transfers, Updates, or Notifications)

  • Transport protocol (UDP or TCP)

  • Packet type (Request or Response)

  • Filtering packets by IP address

  • Name and location of the log file, which defaults to the %systemroot%\System32\DNS directory

  • Log file maximum size limit

To enable debug logging, from the DNS Manager console:

  1. Right-click the relevant DNS server, and then click Properties.

  2. In the Server Properties dialog box, click the Debug Logging tab, as shown in Figure 1-14, select the Log Packets For Debugging check box, select the events for which you want the DNS server to record debug logging, and then click OK.

    FIGURE 1-14

    FIGURE 1-14 Configuring DNS Debug logging

Implement DNS performance tuning

The DNS server role, like other server roles and services, can be affected by the poor performance of your server. Poor performance is often caused by lack of server resources: memory, CPU, sufficient disk throughput, and network bandwidth. You can use general tools, such as Performance Monitor, to gauge whether these resources are sufficient in your server and to determine which resources are causing a bottleneck.

When any one or more of these resources is insufficient, a performance bottleneck is created. The solution is to identify which resource has the bottleneck, and to optimize that resource, often by adding more of that resource. The alternative is to distribute the load by adding additional DNS servers.

The two key resources in the DNS server role are CPU and memory. The DNS tab in the Server Manager console provides a Performance pane that you can use to monitor these two critical resources, as shown in Figure 1-15.


FIGURE 1-15 Monitoring DNS performance

To start monitoring these resources, click Tasks, and then click Configure Performance Alerts. In the DNS Server: Configure Performance Alerts dialog box, you can configure thresholds for alerts for both CPU (percent usage) and Memory (MB available) as shown in Figure 1-16. Click Save when you are ready.


FIGURE 1-16 Configuring DNS performance alerts

Aside from these fundamental server performance characteristics, you can configure the DNS server to help to optimize DNS responsiveness. For example, allowing a DNS server to perform recursion involves imposing additional load on the DNS server when it is unable to provide an authoritative response to a client query. By disabling recursion, you can reduce the load on that DNS server, but at the cost of preventing it from using recursion. Similarly, removing root hints prevents a server from querying the Internet DNS tree on behalf of clients, which reduces workload.

Many of the performance-related decisions you make might have a functionality impact on the way name resolution works within your organization. That means you must consider that impact carefully. To help you plan DNS optimization, you should create a standard DNS server and then perform performance monitoring on the server while it is under a typical query load. You can use tools, such as the industry standard dnsperf tool, to help determine the optimum queries per second value for your standard server.

Implement DNS global settings using Windows PowerShell and configure global settings using Windows PowerShell

So far, throughout this chapter, you have seen that you can perform many of the implementation and configuration tasks on DNS servers by using Windows PowerShell. In Skill 1.2: Create and configure DNS zones and records, you explore more Windows PowerShell cmdlets for the DNS server role.