CHAPTER 9
Domain Name System, WINS, and DNSSEC

Name resolution is a key component in any network operating system (NOS) implementation. The capability of any one resource to locate other resources is the centerpiece of a functional network. Consequently, the name-resolution strategy chosen for a particular NOS must be robust and reliable, and it ideally will conform to industry standards.

Windows Server 2016 utilizes the domain name system (DNS) as its primary method of name resolution, and DNS is a vital component of any Active Directory implementation. Windows Server 2016’s DNS implementation was designed to be compliant with the key Request for Comments (RFCs) that define the nature of how DNS should function. This makes it particularly beneficial for existing network implementations because it allows Windows Server 2016 to interoperate with other types of RFC-compliant DNS implementations.

DNS in Windows Server 2016 remains mostly unchanged. A couple of new features are listed as follows:

You can configure setup a DNS server to responds to certain DNS queries. For example, you can specify DNS responses to be based on client IP address (location), time of the day, and various other parameters.

DNS has been hardened against malicious attacks. These include a new feature called Response Rate Limiting (RRL) prevents possibility of malicious systems using your DNS servers to initiate a denial of service attack on a DNS client.

You also now have DNS-based Authentication of Named Entities (DANE), which you will use with TLSA (Transport Layer Security Authentication) records to advise clients what CA they should expect will be delivering the certificate for your domain name. This prevents man-in-the-middle attacks where a hacker hijacks the DNS cache and points the client to a server that will issue a certificate the hacker has control over.

You can now add records that are not specifically supported by the Windows DNS server. These records are specified as “unknown” record functionality.

IPv6 root hints are finally here, letting you use native IPV6 root hints support to perform Internet name resolution against IPV6 root servers.

There are also a number of new PowerShell commandlets that are available for DNS Server.

IPv6 is rapidly gaining traction in the IT world and is an integral feature of the Windows Server 2016 operating system. Windows Server 2016 supports IPv4 fully in roles such as DNS, Dynamic Host Configuration Protocol (DHCP), and Internet Information Services (IIS). Windows Server 2016 even includes additional features such as the GlobalNames zone (GNZ) to support single-label names with IPv6.

The second type of name resolution, mapping legacy Microsoft NetBIOS names into IP addresses, is provided by Windows Internet Naming Service (WINS). Although it is technically possible (and ideal) to create a Windows Server 2016 environment free of NetBIOS name resolution, the truth is that divorcing a network from WINS dependency is very difficult, so it will likely remain an active part of network services in most organizations, at least for many more years. You can find more information about WINS in the “Reviewing the Windows Internet Naming Service” section later in this chapter.

Windows Server 2016 includes both enhanced DNS Security Extensions (DNSSEC) and enhanced PowerShell support. Introduced to the platform in Windows 2008, DNSSEC in Windows 2016 includes online signing and automated key management to allow signing of Active Directory integrated zones and easier management. PowerShell offers you feature parity with the traditional DNSCMD.EXE tool, allowing administrators to switch to PowerShell for all DNS administration and automation.

This chapter details the key components of DNS in general and provides an overview of Windows Server 2016’s implementation of DNS. A particular emphasis is placed on the role of DNS in Active Directory Domain Services (AD DS) and the way it fits in standard and nonstandard configurations. Step-by-step instructions outline how to install and configure specific DNS components on Windows Server 2016. In addition, troubleshooting DNS issues and specific Active Directory design scenarios help to give a hands-on approach to your understanding of DNS.

Name resolution for computer systems works in a similar way. A user-friendly name is translated into a computer-identifiable number. TCP/IP uses a number scheme that uniquely identifies each computer interface on a network by a series of numbers, such as 10.1.2.145, known as an IP address. Because most humans are not interested in memorizing several of these types of numbers, they must be easily resolvable into user-friendly names such as www.microsoft.com.

DNS, in its simplest form, provides for name resolution in a distributed fashion, with each server or set of servers controlling a specified zone and with entries for each resource called resource records (RRs) that indicate the location of a particular object.

A good analogy for DNS can be found in telephone books. Each city or metropolitan area (namespace) publishes a separate phone book (zone) that contains many listings (resource records) that map people’s names to their phone numbers (IP addresses). This simple example illustrates the basic principle behind DNS. When you understand these basics, further drilling down into the specifics, especially with regard to Windows Server 2016’s DNS, is possible.

In 1983, in direct response to this problem, the RFCs for the DNS were drawn up, and this form of name resolution was implemented on a large scale across the Internet. Instead of a small number of static HOSTS files, DNS servers formed a hierarchical method of name resolution, in which servers resolved only a certain segment of hosts on the Internet and delegated requests that it did not manage. This allowed the number of records held in DNS to scale enormously, without a subsequently large performance decrease.

Microsoft developed its own implementation of DNS in Windows NT 4.0, which was based on the RFC standards on which DNS was founded. With the introduction of Windows 2000, Microsoft adopted DNS as the principle name-resolution strategy for Microsoft products. Older, legacy name-resolution systems such as WINS are slowly being phased out. Since that time, the DNS implementation used by Microsoft has evolved to include a number of key benefits that distinguish it from standard DNS implementations (for example, UNIX BIND). To understand these improvements, however, you first need a basic understanding of DNS functionality.

The top of the hierarchy is known as the root, and is represented by a single . (dot). Moving down the DNS hierarchy, the next layer in the model is made up of top-level domain (TLD) names, which are .com, .net, .gov, .fr, and similar domain namespaces that loosely define the particular category that a domain namespace fits into. The Internet Assigned Numbers Authority (IANA) oversees the global root zone management and management of the TLDs. The IANA is operated by the Internet Corporation for Assigned Names and Numbers (ICANN). The official list of all generic TLDs maintained by IANA is given in Table 9.1.

For example, educational institutions are commonly given .edu extensions, and commercial businesses are given .com extensions. These extensions form the first set of branches to the DNS tree. The .biz, .com, .info, .name, .net, and .org are all open TLDs, meaning any individual or entity can register the domains. Other TLDs have restrictions based on the intended use.

In addition to the generic TLDs, the IANA maintains country-code TLDs. These country codes are the two-letter codes specified in International Organization for Standardization (ISO) 3166 standard. For example, .co is maintained for Colombia and .fr is maintained for France. Interestingly, all the country-code TLDs listed in ISO 3166 are maintained, but some are unused, such as the Saint Martin (.mf). There are also a handful of exceptions, such as the listing for United Kingdom, which is listed in the ISO 3166 standard as .gb, but .uk is used instead.

The second level in the DNS hierarchy commonly contains the business name of an organization, such as companyabc in Figure 9.1. This level is normally the first area in the DNS hierarchy where an organization has control over the records within the domain and where it can be authoritative.

Subdomains can easily be, and often are, created in the DNS hierarchy for various reasons. For example, sales.microsoft.com is a potential domain that could exist as a sublevel of the microsoft.com domain. The DNS hierarchy works in this way, with multiple levels possible.

Installation of DNS on Windows Server 2016 is straightforward, and no reboot is necessary. To install and configure the DNS role on a Windows Server 2016 computer, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the Dashboard section and click the Add Roles and Features link.

3. Click Next on the Before You Begin page.

4. Leave the default selection Role-Based or Feature-Based Installation and click Next.

5. Select the server from the server pool to add the DNS role to and click Next.

6. Select the DNS Server Role check box and click Add Features.

7. Click Next to skip the Features selection.

8. Click Next on the Introduction to DNS Server page.

9. Click Install on the Confirmation page to install the DNS role.

10. Click Close to exit the Add Roles and Features Wizard.

The DNS role can also be installed locally on a server core installation using PowerShell with the following command:

Click here to view code image

Install-WindowsFeature–Name DNS-Server-Full-Role

The DNS role has been installed on the Windows Server 2016 server, but has not been configured. To configure the role, complete the following steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select Action, Configure a DNS Server.

6. On the Welcome page for the Configure a DNS Server Wizard, click Next to continue.

7. Select Create Forward and Reverse Lookup Zones (Recommended for Large Networks), and then click Next.

8. Select Yes, Create a Forward Lookup Zone Now (Recommended), and then click Next.

9. Select the type of zone to be created—in this case, choose Primary Zone—and click Next. If the server is a writable domain controller, the Store the Zone in Active Directory check box is available.

10. If storing the zone in Active Directory, select the replication scope and click Next.

11. Type the FQDN of the zone in the Zone Name box, and then click Next.

12. At this point, if creating a non-AD-integrated zone, you can create a new zone text file or import one from an existing zone file. In this case, choose Create a New File with This File Name, and accept the default. Click Next to continue.

13. The subsequent page allows a zone to either accept or decline dynamic updates. For this example, leave dynamic updates disabled by selecting the Do Not Allow Dynamic Updates option button and clicking Next.

14. The next page allows for the creation of a reverse lookup zone. Here, select Yes, Create a Reverse Lookup Zone Now, and then click Next.

15. Select Primary Zone for the reverse lookup zone type, and then click Next.

16. If storing the zone in Active Directory, select the replication scope and click Next.

17. Accept the default IPv4 Reverse Lookup Zone, and then click Next.

18. Type in the network ID of the reverse lookup zone, and then click Next. (The network ID is usually the first set of octets from an IP address in the zone. If a Class A IP range of 10.1.0.0 with a subnet mask of 255.255.0.0 is in use on a network, you enter the values 10.1, as illustrated in Figure 9.2.)

19. Again, if creating a non-AD-integrated zone, you are offered the option to create a new zone file or to use an existing file. For this example, choose Create a New File with This File Name, and click Next to continue.

20. Again, you are presented the option for dynamic updates. For this example, leave dynamic updates disabled by selecting the Do Not Allow Dynamic Updates option button and clicking Next.

21. The next page deals with the setup of forwarders, which is described in more detail in the “Understanding DNS Zones” section later in this chapter. In this example, choose No, It Should Not Forward Queries, and click Next to continue.

22. The final window displays a summary of the changes that will be made and the zones that will be added to the DNS database. Click Finish to finalize the changes and create the zones.

Several key resource records exist in most DNS implementations, especially in those associated with Windows Server 2016 AD DS. A general familiarity with these specific types of RRs is required to gain a better understanding of DNS.

An SOA record is automatically created when DNS is installed for AD DS in Windows Server 2016 and is populated with the default TTL, primary server, and other pertinent information for the zone. After installation, however, these values can be modified to fit the specific needs of an organization.

The vast majority of RRs in DNS are A records because they are used to identify the IP addresses of most resources within a domain.

AAAA—Maps a standard IP address into a 128-bit IPv6 address. This type of record will become more prevalent as IPv6 is adopted. See Chapter 11, “DHCP, IPv6, IPAM” for more details on IPv6.

ISDN—Maps a specific DNS name to an ISDN telephone number.

KEY—Stores a public key used for encryption for a particular domain.

RP—Specifies the person responsible for a domain.

WKS—Designates a particular well-known service.

MB—Indicates which host contains a specific mailbox.

It is important to understand that any section or subsection of DNS can exist within a single zone. For example, an organization might decide to place an entire namespace of a domain, subdomains, and subsubdomains into a single zone. Or specific sections of that namespace can be divided up into separate zones. In fact, the entire Internet namespace can be envisioned as a single namespace with . as the root, which is divided into a multitude of different zones.

As shown in Figure 9.7, the stub zone effectively serves as a placeholder for a zone that is authoritative on another server. It allows a server to forward queries that are made to a specific zone to the list of name servers in that zone.

You can easily create a stub zone in Windows Server 2016 after the need has been established for this particular type of functionality. To create a stub zone, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Select Action, New Zone.

7. Click Next on the Welcome page.

8. Select Stub Zone from the list of zone types. Because this zone will not be AD integrated, uncheck the Store the Zone in Active Directory check box if it is checked, and then click Next to continue.

9. Type in the name of the zone that will be created, and click Next to continue.

10. Select Create a New File with This File Name and accept the defaults, unless migrating from an existing zone file. Then click Next to continue.

11. Type in the IP address of the server or servers from which the zone records will be copied. Press Enter for each server entered, and they will be validated, as shown in Figure 9.8. Click Next to continue.

12. Click Finish on the Summary page to create the zone.

The newly created stub zone will hold only the SOA, NS, and glue records for the domain at which it is pointed.

Primary DNS servers can be configured to notify secondary DNS servers of changes to a zone and to begin a zone transfer. They can also be configured to perform a zone transfer on a scheduled basis. To set up a secondary server to pull zone transfers from a forward lookup zone, follow this procedure:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Right-click the name of the zone and choose Properties.

7. Choose the Zone Transfers tab.

8. Check Allow Zone Transfers and select Only to Servers Listed on the Name Servers Tab. This is normally the default setting.

9. Select the Name Servers tab.

10. Click Add, type in the FQDN of the server that will receive the updates, and click the Resolve button. The server will be validated, as shown in Figure 9.9. Because the server is not yet an authoritative server for the zone, the error message “The server with this IP address is not authoritative for the required zone” appears. This will be done in the next section. The error can be safely ignored. Click OK to save.

11. Click OK to save the changes.

Now that the primary zone on the primary DNS server has been configured to allow transfers, the secondary zone has to be configured on the secondary DNS server. To create the secondary zone and begin zone transfers, complete the following steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Select Action, New Zone.

7. Click Next on the Welcome page.

8. Select Secondary Zone from the list of zone types. Secondary zones cannot be AD-integrated and the options will be grayed out. Click Next to continue.

9. Type in the name of the zone that will be created (this should match the primary zone name), and click Next to continue.

10. Type in the IP address or FQDN of the server or servers from which the zone records will be transferred. Press Enter for each server entered, and they will be validated. Click Next to continue.

11. Click Finish on the Summary page to create the zone.

After the last step, the zone will automatically transfer from the primary DNS server to the secondary DNS server.

IXFR zone transfers are accomplished by referencing a serial number that is stored on the SOA of the DNS server that holds the primary zone. This number is incremented upon each change to a zone. If the server requesting the zone transfer has a serial number of 45, for example, and the primary zone server has a serial number of 55, only those changes made during the period of time between 45 and 55 will be incrementally sent to the requesting server via an IXFR transfer. However, if the difference in index numbers is too great, the information about the requesting server is assumed to be stale, and a full AXFR transfer will be initiated. For example, if a requesting server has an index of 25, and the primary zone server’s index is 55, an AXFR zone transfer will be initiated, as illustrated in Figure 9.10.

In the example shown in Figure 9.11, Client1 in CompanyABC opens a web browser and attempts to browse to the website for www.microsoft.com. A recursive query is initiated to the default name server; in this case, Server1 is contacted. Because Server1 is authoritative only for the companyabc.com namespace, and no entries exist for microsoft.com, the query is sent to an “upstream” DNS server that is listed in the root hints of the DNS server. That server, Server2, is not authoritative for microsoft.com but sends a referral back to Server1 for Server3, which is a name server for the .com namespace. Server3 knows that Server4 handles name-resolution requests for microsoft.com and sends that information back to Server1. A final iterative query is then sent from Server1 to Server4, and Server4 successfully resolves www to the proper IP address. Server1, with this information in hand, returns Client1’s original recursive query with the proper IP address and Client1’s browser successfully resolves www.microsoft.com.

This type of functionality lies at the heart of the distributed nature of DNS and allows DNS lookups to function as efficiently as they do.

It is important to note that only Windows 2000/XP and higher clients support dynamic updates and that down-level (NT/9x) clients must have DHCP configured properly for them to be updated in DNS. There are, however, security issues associated with this functionality that are detailed in subsequent sections of this chapter and are described further in Chapter 11.

In the example from the “Performing Iterative Queries” section, if Client1 already requested the IP address of www.microsoft.com, and the information was returned to the DNS server that showed the IP address, it would make sense that that IP address would not change often and could, therefore, be cached for future queries. The next time another client requests the same information, the local DNS server will give that client the IP address it received from the original Client1 query so long as the TTL has not expired. This helps to reduce network traffic and improve DNS query response time.

The TTL for a response is set by the name server that successfully resolves a query. In other words, you might have different TTLs set for items in a cache, based on where they were resolved and the TTL for the particular zone they originated from.

The TTL setting for a zone is modified via the SOA record. The procedure for doing this in Windows Server 2016 is as follows:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Select the zone node.

7. Find the SOA record for the zone and double-click it.

8. Modify the Minimum (Default) TTL entry to match the TTL you want, as shown in Figure 9.12.

9. Click OK to accept the changes.

If you’re using DHCP to provide secure updates on behalf of DHCP clients, one important caveat is that DHCP servers should not be located on the domain controller, if possible, because of specific issues in regard to secure updates. The reason for this recommendation is that all DHCP servers are placed in a group known as DNSUpdateProxy. Any members of this group do not take ownership of items that are published in DNS. This group was created because DHCP servers can dynamically publish updates for clients automatically, and the clients would need to modify their entries themselves. Subsequently, the first client to access a newly created entry would take ownership of that entry. Because domain controllers create sensitive SRV records and the like, it is not wise to use a domain controller as a member of this group, and it is by extension not wise to have DHCP on domain controllers for this reason. If establishing DHCP on a domain controller is unavoidable, it is recommended to disable this functionality by not adding the server into this group.

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Right-click the server name and choose Properties.

6. Select the Advanced tab.

7. Check the Enable Automatic Scavenging of Stale Records check box.

8. Select a scavenging period, as shown in Figure 9.13, and click OK to save your changes.

Scavenging makes a DNS database cleaner, but overly aggressive scavenging can also remove valid entries. Therefore, if you’re using scavenging, it is wise to strike a balance between a clean database and a valid one.

The Hints file should be updated on a regular basis to ensure that the servers listed are still relevant. This file is located in \%systemroot%system32DNScache.dns and can be updated on the Internet at the following address:

Click here to view code image

ftp://ftp.internic.net/domain/named.cache

At the time of writing, the latest root hints file, or root name servers, was dated Jun 8, 2011. The contents are shown in Listing 9.1. You can see the root server names (for example, A.ROOT-SERVER.NET) and their A records (for example, 192.41.0.4).

LISTING 9.1 Root Hints File Contents

Click here to view code image

---

;       This file holds the information about root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  <file>"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC
;       under anonymous FTP as
;           file                /domain/named.cache
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;
;       last update:    Jun 8, 2011
;       related version of root zone:   2011060800
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
; FORMERLY NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
;
; FORMERLY C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; FORMERLY TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2D::D
;
; FORMERLY NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2F::F
;
; FORMERLY NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::803F:235
;
; FORMERLY NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7FE::53
;
; OPERATED BY VERISIGN, INC.
;
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:C27::2:30
;
; OPERATED BY RIPE NCC
;
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7FD::1
;
; OPERATED BY ICANN
;
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:3::42
;
; OPERATED BY WIDE
;
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
M.ROOT-SERVERS.NET.      3600000      AAAA  2001:DC3::35
; End of File

---

You can see the root hints for a Windows Server 2016 DNS server by doing the following:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Right-click the server name and choose Properties.

6. Select the Root Hints tab.

The name servers should match those in the root hints file retrieved from the InterNIC FTP site.

In conditional forwarding, queries that are made to a specific domain or set of domains are sent to a specifically defined forwarder DNS server. This type of scenario is normally used to define routes that internal domain resolution traffic will follow. For example, if an organization controls the companyabc.com domain namespace and the companyxyz.com namespace, it might want queries between domains to be resolved on local DNS servers, as opposed to being sent out to the Internet just to be sent back again so that they are resolved internally.

Forward-only servers are never meant to do iterative queries, but rather to forward all requests that cannot be answered locally to a forwarder or set of forwarders. If those forwarders do not respond, a failure message is generated.

If you plan to use forwarders in a Windows Server 2016 DNS environment, you can establish them by following these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Right-click the server name and choose Properties.

6. Select the Forwarders tab.

7. Click Edit to create forwarders.

8. Type in the IP address or FQDN of the server or servers that will be forwarders. Press Enter for each server entered, and they will be validated. Click OK when you have finished.

9. If this server will be configured only to forward, and to otherwise fail if forwarding does not work, uncheck the Use Root Hints If No Forwarders Are Available check box.

10. Click OK to save the changes.

To enable WINS to assist with DNS lookups, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Expand the Forward Lookup Zones nodes.

6. Select the zone node.

7. Right-click the zone in question and choose Properties.

8. Choose the WINS tab.

9. Check the Use WINS Forward Lookup check box.

10. Enter the IP address of the WINS servers, click the Add button, and then click OK to save the changes.

Windows Server 2016, like Windows Server versions before it, utilizes AD-integrated zones, but with one major change to the design: Instead of storing the zone information directly in the naming contexts of Active Directory, it is stored in the application partition to reduce replication overhead. You can find more information about this concept in the following sections.

With the application partition concept, replication loads are now reduced while important zone information is delegated to areas of the network where they are needed.

Microsoft DNS fixed this problem in Windows Server 2003 and above. Windows Server 2016 DNS first changes its host records on a sufficient number of other authoritative servers within DNS so that the IP changes made will be successfully replicated, thus eliminating this island problem. As a result, it is no longer necessary to point a root DNS server to another DNS server for updates, as was previously recommended as a method of resolving this issue.

In Windows Server 2016, _msdcs is a separate zone in DNS, as shown in Figure 9.14. This zone, stored in the application partition, is replicated to every domain controller that is a DNS server. This listing of SRV records was moved mainly to satisfy the requirements of remote sites. In Windows 2000, these remote sites had to replicate the entire DNS database locally to access the _msdcs records, which led to increased replication time and reduced responsiveness. If you delegate the SRV records to their own zone, only this specific zone can be designated for replication to remote site DNS servers, saving replication throughput and increasing the response time for clients.

Active Directory uses a hierarchical X.500-based structure that was designed to map into the DNS hierarchy, hence the similarities. In addition, Active Directory utilizes DNS for all internal lookups, from client logons to Global Catalog lookups. Subsequently, strong consideration into how DNS integrates with Active Directory is required for those considering deploying or upgrading AD.

For this and other reasons, installing a redundant DNS infrastructure in any AD DS implementation is strongly recommended. Even smaller environments should consider duplication of the primary DNS zone, and nearly as much emphasis as is put into protecting the Global Catalog AD index should be put into protecting DNS.

Security considerations for the DNS database should not be taken for granted. Secure updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a domain controller can also help to secure DNS (see previous sections of this chapter for more details on this concept). In addition, limiting administrative access to DNS will help to mitigate problems with unauthorized “monkeying around” with DNS.

For environments that use older versions of DNS or are not able (or willing) to host Active Directory clients directly in their databases, Active Directory DNS can simply be delegated to a separate zone in which it can be authoritative. The Windows Server 2016 systems can simply set up forwarders to the foreign DNS implementations to provide for resolution of resources in the original zone.

Because each tree in a peer-root model is composed of independent domains that might not have security privileges in the other domains, a mechanism will need to be in place to allow for lookups to occur between the two trees. The creation of secondary zones in each DNS environment will provide a solution to this scenario, as illustrated in Figure 9.15. Windows Server 2016 supports the option of replicating these separate trees to all DNS servers in the forest, reducing the need for secondary zones. Replicating secondary zones outside of a forest is still sometimes necessary, however. Conditional forwarding and stub zones can also be used in certain cases to achieve a similar result without the need for data replication.

Subdomains for each site are created in this zone; they indicate which resource is available in those specific sites, as shown in Figure 9.16. In a nutshell, if an SRV record in the specific site subdomain is incorrect, or another server from a different site is listed, all clients in that site are forced to authenticate in other sites. This concept is important because a common problem is that when Active Directory sites are created before they are populated with servers, an SRV record from the hub location is added to that site subdomain in DNS. When a new server is added to those sites, their SRV records join the other SRV records that were placed there when the site was created. These records are not automatically deleted, and they consequently direct clients to servers across slow wide-area network (WAN) links, often making logon times very slow.

In addition to the site containers, the root of these containers contains a list of all domain controllers in a specific domain. These lists are used for name resolution when a particular site server does not respond. If a site domain controller is down, clients randomly choose a domain controller in this site.

However, with the advent of IPv6, WINS will no longer be supported as the new addressing is deployed throughout the organization. There are also many advantages of DNS over WINS, including reducing administrative overhead, single name-resolution repository, security, and open standards.

Windows Server 2016 provides a feature that was introduced in Windows Server 2008 to address this problem, specifically the GlobalNames zone (GNZ). This zone provides single-label name resolution via a DNS zone, similar to WINS. The zone is a normal forward lookup zone, albeit with a special name (GlobalNames), and is used by the DNS server in a special way. If the DNS server is unable to resolve an address in its local zones, it will then resolve the single-label address against the GNZ.

The GNZ holds out the promise of finally doing away with WINS and NetBIOS naming.

To configure the GNZ, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Select Action, New Zone.

7. Click Next on the Welcome page.

8. Select Primary Zone and make sure that the Store the Zone in Active Directory check box is checked. Click Next.

9. Select To All DNS Servers in This Forest, and then click Next.

10. Enter the Zone name GlobalNames and click Next.

11. Leave the default Dynamic Update setting and click Next.

12. Click Finish to create the zone.

13. Open a PowerShell command prompt and enter the command Set-DnsServerGlobal NameZone -Enable $true. This command must be run on each DNS server that is expected to resolve global names, regardless of if the zone is replicated to them already.

Now the GNZ is ready to respond to queries. For any server that needs to respond to single-label queries, enter a CNAME record in the GNZ with the appropriate FQDN for the resource. The DNS server will try the GNZ after trying other local zones.

For more advanced event log diagnosis, you can turn on Debug Logging on a per-server basis. It is recommended that this functionality be turned on only as required, however, as this can affect server performance and the log files can fill up fast. To enable Debug Logging, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Right-click the server name and choose Properties.

6. Select the Debug Logging tab.

7. Check the Log Packets for Debugging check box.

8. Configure any additional settings as required, and click OK.

By default, the log file is named dns.log and is saved in The C:WindowsSystem32dns directory. Listing 9.2 shows the debug of the DNS server dc1.companyabc.com of a lookup of the record www.cco.com from the server at 10.1.2.13. You can see from the log that the request was forwarded to the DNS server at 12.222.165.144 and that the results were then sent to the requesting server at 10.1.1.1.

LISTING 9.2 DNS Log File

Click here to view code image

---

5/28/2016 6:48:32 PM 067C PACKET  000000BDAFD158A0 UDP Rcv 10.1.1.1        3b60
   Q [0001   D   NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:32 PM 067C PACKET  000000BDB0216410 UDP Snd 12.222.165.144  ebfc
   Q [0000       NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:32 PM 067C PACKET  000000BDB0D8FF80 UDP Rcv 12.222.165.144  ebfc
 R Q [8084 A  R  NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:32 PM 067C PACKET  000000BDAFD158A0 UDP Snd 10.1.1.1        3b60
 R Q [8081   DR  NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:58 PM 067C PACKET  000000BDB0A2B5B0 UDP Rcv 10.1.2.13       0006
   Q [0001   D   NOERROR] A      (3)www(3)cco(3)com(10)companyabc(3)com(0)
5/28/2016 6:48:58 PM 067C PACKET  000000BDB0A2B5B0 UDP Snd 10.1.2.13       0006
 R Q [8385 A DR NXDOMAIN] A      (3)www(3)cco(3)com(10)companyabc(3)com(0)
5/28/2016 6:48:58 PM 067C PACKET  000000BDB01CFCE0 UDP Rcv 10.1.2.13       0007
   Q [0001   D   NOERROR] AAAA   (3)www(3)cco(3)com(10)companyabc(3)com(0)
5/28/2016 6:48:58 PM 067C PACKET  000000BDB01CFCE0 UDP Snd 10.1.2.13       0007
 R Q [8385 A DR NXDOMAIN] AAAA   (3)www(3)cco(3)com(10)companyabc(3)com(0)
5/28/2016 6:48:58 PM 067C PACKET  000000BDB0D8FF80 UDP Rcv 10.1.2.13       0008
   Q [0001   D   NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:58 PM 067C PACKET  000000BDAFD158A0 UDP Snd 128.8.10.90     d511
   Q [0000       NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDAFD27B40 UDP Rcv 128.8.10.90     d511
 R Q [0080       NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDAFD158A0 UDP Snd 192.55.83.30    9b01
   Q [0000       NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDB09D48F0 UDP Rcv 192.55.83.30    9b01
 R Q [0080       NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDAFD158A0 UDP Snd 12.222.165.144  c2da
   Q [0000       NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDAF446E30 UDP Rcv 12.222.165.144  c2da
 R Q [8084 A  R  NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDB0D8FF80 UDP Snd 10.1.2.13       0008
 R Q [8081   DR  NOERROR] A      (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDB0A2B5B0 UDP Rcv 10.1.2.13       0009
   Q [0001   D   NOERROR] AAAA   (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDB0D8FF80 UDP Snd 12.222.165.144  7b4a
   Q [0000       NOERROR] AAAA   (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDB0F3BB90 UDP Rcv 12.222.165.144  7b4a
 R Q [8084 A  R  NOERROR] AAAA   (3)www(3)cco(3)com(0)
5/28/2016 6:48:59 PM 067C PACKET  000000BDB0A2B5B0 UDP Snd 10.1.2.13       0009
 R Q [8081   DR  NOERROR] AAAA   (3)www(3)cco(3)com(0)

---

The DNS log can be very detailed and tedious to read, but provides a wealth of information about exactly what the DNS server is doing. You can get even more detail by selecting the Details check box on the Debug Logging tab, which also enables you to see the data that was returned. Logging does add significantly to the load of the DNS server, so it should only be enabled when troubleshooting and disabled immediately afterwards.

By default, all clients have a file named HOSTS that provides for a simple line-by-line resolution of names to IP addresses. This file is normally located in \%Systemroot% System32Driversetc. Problems can occur when these manual entries conflict with DNS, and it is, therefore, wise to ensure that there are not conflicts with this HOSTS file and the DNS database when troubleshooting.

1. Open a command prompt instance by choosing Start, All Programs, Accessories, Command Prompt.

2. Type nslookup and press Enter.

3. Type set query=mx and press Enter.

4. Type domainname and press Enter.

5. Type set query=soa and press Enter.

6. Type domainname and press Enter.

Nslookup’s functionality is not limited to these simple lookups. Performing an nslookup /? lists the many functions it is capable of. Nslookup is a tool of choice for many name-resolution problems and is a must in any troubleshooter’s arsenal.

ipconfig /flushdns—If you experience problems with the client-side cache, the cache itself can be “flushed” through the invocation of the flushdns flag. This removes all previously cached queries that a client might be storing and is particularly useful if a server name has just changed IP addresses and particular clients have trouble connecting to it.

ipconfig /registerdns—The registerdns flag forces the client to dynamically reregister itself in DNS, if the particular zone supports dynamic updates.

ipconfig /displaydns—An interesting but not well-known parameter is displaydns. This flag displays the contents of the client-side cache and is useful for troubleshooting specific issues with individual records.

LISTING 9.3 DNSCMD Command Options

Click here to view code image

---

Usage: DnsCmd <ServerName> <Command> [<Command Parameters>]

<ServerName>:
  IP address or host name    -- remote or local DNS server
  .                          -- DNS server on local machine
<Command>:
  /Info                      -- Get server information
  /Config                    -- Reset server or zone configuration
  /EnumZones                 -- Enumerate zones
  /Statistics                -- Query/clear server statistics data
  /ClearCache                -- Clear DNS server cache
  /WriteBackFiles            -- Write back all zone or root-hint datafile(s)
  /StartScavenging           -- Initiates server scavenging
  /IpValidate                -- Validate remote DNS servers
  /EnumKSPs                  -- Enumerate available key storage providers
  /ResetListenAddresses      -- Set server IP address(es) to serve DNS requests
  /ResetForwarders           -- Set DNS servers to forward recursive queries to
  /ZoneInfo                  -- View zone information
  /ZoneAdd                   -- Create a new zone on the DNS server
  /ZoneDelete                -- Delete a zone from DNS server or DS
  /ZonePause                 -- Pause a zone
  /ZoneResume                -- Resume a zone
  /ZoneReload                -- Reload zone from its database (file or DS)
  /ZoneWriteBack             -- Write back zone to file
  /ZoneRefresh               -- Force refresh of secondary zone from master
  /ZoneUpdateFromDs          -- Update a DS integrated zone by data from DS
  /ZonePrint                 -- Display all records in the zone
  /ZoneResetType             -- Change zone type
  /ZoneResetSecondaries      -- Reset secondary otify information for a zone
  /ZoneResetScavengeServers  -- Reset scavenging servers for a zone
  /ZoneResetMasters          -- Reset secondary zone’s master servers
  /ZoneExport                -- Export a zone to file
  /ZoneChangeDirectoryPartition -- Move a zone to another directory partition
  /ZoneSeizeKeymasterRole    -- Seize the key master role for a zone
  /ZoneTransferKeymasterRole -- Transfer the key master role for a zone
  /ZoneEnumSKDs              -- Enumerate the signing key descriptors for a zone
  /ZoneAddSKD                -- Create a new signing key descriptor for a zone
  /ZoneDeleteSKD             -- Delete a signing key descriptor for a zone
  /ZoneModifySKD             -- Modify a signing key descriptor for a zone
  /ZoneValidateSigningParameters -- Validate DNSSEC online signing parameters for a
zone
  /ZoneSetSKDState           -- Set Active and/or Standby keys for a signing key
descriptor for a zone
  /ZoneGetSKDState           -- Retrieve dynamic state for a signing key descriptor
for a zone
  /ZonePerformKeyRollover    -- Trigger a key rollover in a signing key descriptor
for a zone
  /ZonePokeKeyRollover       -- Trigger a key rollover in a signing key descriptor
for a zone
  /ZoneSign                  -- Signs the zone using DNSSEC online signing
parameters
  /ZoneUnsign                -- Removes DNSSEC signatures from a signed zone
  /ZoneResign                -- Regenerate DNSSEC signatures in a signed zone
  /EnumRecords               -- Enumerate records at a name
  /RecordAdd                 -- Create a record in zone or RootHints
  /RecordDelete              -- Delete a record from zone, RootHints or cache
  /NodeDelete                -- Delete all records at a name
  /AgeAllRecords             -- Force aging on node(s) in zone
  /TrustAnchorAdd            -- Create a new trust anchor zone on the DNS server
  /TrustAnchorDelete         -- Delete a trust anchor zone from DNS server or DS
  /EnumTrustAnchors          -- Display status information for trust anchors
  /TrustAnchorsResetType     -- Change zone type for a trust anchor zone
  /EnumDirectoryPartitions   -- Enumerate directory partitions
  /DirectoryPartitionInfo    -- Get info on a directory partition
  /CreateDirectoryPartition  -- Create a directory partition
  /DeleteDirectoryPartition  -- Delete a directory partition
  /EnlistDirectoryPartition  -- Add DNS server to partition replication scope
  /UnenlistDirectoryPartition -- Remove DNS server from replication scope
  /CreateBuiltinDirectoryPartitions -- Create built-in partitions
  /ExportSettings            -- Output settings to DnsSettings.txt in the DNS server
database directory
  /OfflineSign               -- Offline signing zone files, including key
generation/deletion
  /EnumTrustPoints           -- Display active refresh information for all trust
points
  /ActiveRefreshAllTrustPoints -- Perform an active refresh on all trust points now
  /RetrieveRootTrustAnchors  -- Retrieve root trust anchors via HTTPS

<Command Parameters>:
  DnsCmd <CommandName> /? -- For help info on specific Command

---

In future versions of Windows, Microsoft might remove dnscmd.exe.

If you currently use dnscmd.exe to configure and manage the DNS server, Microsoft recommends that you transition to Windows PowerShell.

To view a list of commands for DNS server management, type Get-Command -Module DnsServer at the Windows PowerShell prompt. Additional information about Windows PowerShell commands for DNS is available at http://go.microsoft.com/fwlink/?LinkId=217627.

Feature parity with the user interface and DNSCmd.

DNS Server role installation/removal using Windows PowerShell.

Windows PowerShell client query with DNSSEC validation results.

Server configuration is enabled for computers running older operating systems.

You can view the full functionality of this utility by typing Get-Command -Module DnsServer at the PowerShell command line, as shown in Listing 9.4.

LISTING 9.4 PowerShell DNS Commandlets

Click here to view code image

---

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Alias           Export-DnsServerTrustAnchor                        DnsServer
Function        Add-DnsServerConditionalForwarderZone              DnsServer
Function        Add-DnsServerDirectoryPartition                    DnsServer
Function        Add-DnsServerForwarder                             DnsServer
Function        Add-DnsServerPrimaryZone                           DnsServer
Function        Add-DnsServerResourceRecord                        DnsServer
Function        Add-DnsServerResourceRecordA                       DnsServer
Function        Add-DnsServerResourceRecordAAAA                    DnsServer
Function        Add-DnsServerResourceRecordCName                   DnsServer
Function        Add-DnsServerResourceRecordDnsKey                  DnsServer
Function        Add-DnsServerResourceRecordDS                      DnsServer
Function        Add-DnsServerResourceRecordMX                      DnsServer
Function        Add-DnsServerResourceRecordPtr                     DnsServer
Function        Add-DnsServerRootHint                              DnsServer
Function        Add-DnsServerSecondaryZone                         DnsServer
Function        Add-DnsServerSigningKey                            DnsServer
Function        Add-DnsServerStubZone                              DnsServer
Function        Add-DnsServerTrustAnchor                           DnsServer
Function        Add-DnsServerZoneDelegation                        DnsServer
Function        Clear-DnsServerCache                               DnsServer
Function        Clear-DnsServerStatistics                          DnsServer
Function        ConvertTo-DnsServerPrimaryZone                     DnsServer
Function        ConvertTo-DnsServerSecondaryZone                   DnsServer
Function        Disable-DnsServerSigningKeyRollover                DnsServer
Function        Enable-DnsServerSigningKeyRollover                 DnsServer
Function        Export-DnsServerDnsSecPublicKey                    DnsServer
Function        Export-DnsServerZone                               DnsServer
Function        Get-DnsServer                                      DnsServer
Function        Get-DnsServerCache                                 DnsServer
Function        Get-DnsServerDiagnostics                           DnsServer
Function        Get-DnsServerDirectoryPartition                    DnsServer
Function        Get-DnsServerDnsSecZoneSetting                     DnsServer
Function        Get-DnsServerDsSetting                             DnsServer
Function        Get-DnsServerEDns                                  DnsServer
Function        Get-DnsServerForwarder                             DnsServer
Function        Get-DnsServerGlobalNameZone                        DnsServer
Function        Get-DnsServerGlobalQueryBlockList                  DnsServer
Function        Get-DnsServerRecursion                             DnsServer
Function        Get-DnsServerResourceRecord                        DnsServer
Function        Get-DnsServerRootHint                              DnsServer
Function        Get-DnsServerScavenging                            DnsServer
Function        Get-DnsServerSetting                               DnsServer
Function        Get-DnsServerSigningKey                            DnsServer
Function        Get-DnsServerStatistics                            DnsServer
Function        Get-DnsServerTrustAnchor                           DnsServer
Function        Get-DnsServerTrustPoint                            DnsServer
Function        Get-DnsServerZone                                  DnsServer
Function        Get-DnsServerZoneAging                             DnsServer
Function        Get-DnsServerZoneDelegation                        DnsServer
Function        Import-DnsServerResourceRecordDS                   DnsServer
Function        Import-DnsServerRootHint                           DnsServer
Function        Import-DnsServerTrustAnchor                        DnsServer
Function        Invoke-DnsServerSigningKeyRollover                 DnsServer
Function        Invoke-DnsServerZoneSign                           DnsServer
Function        Invoke-DnsServerZoneUnsign                         DnsServer
Function        Register-DnsServerDirectoryPartition               DnsServer
Function        Remove-DnsServerDirectoryPartition                 DnsServer
Function        Remove-DnsServerForwarder                          DnsServer
Function        Remove-DnsServerResourceRecord                     DnsServer
Function        Remove-DnsServerRootHint                           DnsServer
Function        Remove-DnsServerSigningKey                         DnsServer
Function        Remove-DnsServerTrustAnchor                        DnsServer
Function        Remove-DnsServerZone                               DnsServer
Function        Remove-DnsServerZoneDelegation                     DnsServer
Function        Reset-DnsServerZoneKeyMasterRole                   DnsServer
Function        Restore-DnsServerPrimaryZone                       DnsServer
Function        Restore-DnsServerSecondaryZone                     DnsServer
Function        Resume-DnsServerZone                               DnsServer
Function        Set-DnsServer                                      DnsServer
Function        Set-DnsServerCache                                 DnsServer
Function        Set-DnsServerConditionalForwarderZone              DnsServer
Function        Set-DnsServerDiagnostics                           DnsServer
Function        Set-DnsServerDnsSecZoneSetting                     DnsServer
Function        Set-DnsServerDsSetting                             DnsServer
Function        Set-DnsServerEDns                                  DnsServer
Function        Set-DnsServerForwarder                             DnsServer
Function        Set-DnsServerGlobalNameZone                        DnsServer
Function        Set-DnsServerGlobalQueryBlockList                  DnsServer
Function        Set-DnsServerPrimaryZone                           DnsServer
Function        Set-DnsServerRecursion                             DnsServer
Function        Set-DnsServerResourceRecord                        DnsServer
Function        Set-DnsServerResourceRecordAging                   DnsServer
Function        Set-DnsServerRootHint                              DnsServer
Function        Set-DnsServerScavenging                            DnsServer
Function        Set-DnsServerSecondaryZone                         DnsServer
Function        Set-DnsServerSetting                               DnsServer
Function        Set-DnsServerSigningKey                            DnsServer
Function        Set-DnsServerStubZone                              DnsServer
Function        Set-DnsServerZoneAging                             DnsServer
Function        Set-DnsServerZoneDelegation                        DnsServer
Function        Show-DnsServerCache                                DnsServer
Function        Show-DnsServerKeyStorageProvider                   DnsServer
Function        Start-DnsServerScavenging                          DnsServer
Function        Start-DnsServerZoneTransfer                        DnsServer
Function        Suspend-DnsServerZone                              DnsServer
Function        Sync-DnsServerZone                                 DnsServer
Function        Test-DnsServer                                     DnsServer
Function        Test-DnsServerDnsSecZoneSetting                    DnsServer
Function        Unregister-DnsServerDirectoryPartition             DnsServer
Function        Update-DnsServerTrustPoint                         DnsServer

---

The Set-DnsServerGlobalNameZone PowerShell commandlet was used to enable the global names resolution earlier in the chapter.

There are a series of IETF RFCs that specify the DNSSEC extensions to DNS:

RFC 4033—DNS Security Introduction and Requirements

RFC 4034—Resource Records for the DNS Security Extensions

RFC 4035—Protocol Modifications for the DNS Security Extensions

RFC 5155—DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

RFC 5702—Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

RFC 5011—Automated Updates of DNS Security (DNSSEC) Trust Anchors

There are also several other supporting IETF RFCs. Together, these RFCs modify and extend the DNS protocol. The DNSSEC extensions provide the following:

Origin authority

Data integrity

Authenticated denial of existence

In a nutshell, DNSSEC allows clients to know that the DNS information is coming from a valid server, wasn’t changed, and that a given host exists or doesn’t exist. Windows Server 2016 supports all DNSSEC RFCs.

Active Directory DNSSEC support is a critical feature in Windows Server 2016, allowing secure DNS to be extended to Active Directory integrated DNS zones. Windows Server 2016 supports DNSSEC for Active Directory integrated DNS by supporting the following:

Dynamic updates to zone records

Multimaster DNS model for DNSSEC zones

Use of AD for secure key and trust anchor distribution

Windows Server 2008 supported DNSSEC for AD-integrated zones, but did not support dynamic updates. This was a critical limiting factor in preventing rollout of DNSSEC to organizations because dynamic updates are a critical feature of AD-integrated zones and AD fault tolerance. Windows Server 2016 support for dynamic updates with DNSSEC allows AD-integrated zones to be fully utilized and organizations to realistically deploy DNSSEC.

Administration on DNSSEC in earlier versions of Windows Server was very manual, required a lot of steps, and required significant expertise. Windows Server 2016 supports the DNSSEC administration with the Zone Signing Wizard, allowing best practices defaults to be easily deployed and DNSSEC signed zones to be easily scaled out. Much of the administrative effort is automated, including the following:

Automated re-signing on static and dynamic updates

Automated key rollovers

Automated signature refreshes

Automated updates of secure delegations

Automated distribution and updating of trust anchors

The ease of administration and automation brings DNSSEC in Windows Server 2016 to a production-ready capacity.

Zone Signing Key (ZSK) is the encryption key used to sign the zone, essentially a public and private key combination stored in a certificate. The Key Signing Key (KSK) is the key used to sign the ZSK to validate it, essentially a public and private key combination as well.

The DNSKEY record is a DNSSEC record type used to store a public key. The KSK and the ZSK public keys are stored in the DNSKEY records to allow the zone signatures to be validated.

The Next Secure (NSEC) record is a DNSSEC record type used to prove the nonexistence of a DNS name. This allows DNS clients to be sure that if a record is not retrieved in a DNS lookup, the record does not exist in the DNSSEC zone.

The Resource Record Signature (RRSIG) record is used to hold the signature for a DNS record. For each A record, there will be a corresponding RRSIG record. For each NSEC record, there will also be a corresponding RRSIG record.

The Delegation Signer (DS) record is used to secure delegations to other DNS servers and confirm their validity. This prevents man-in-the-middle DNS servers from breaking the security chain during recursive lookups.

A nonvalidating security-aware stub resolver is a security-aware stub resolver that trusts one or more security-aware DNS servers to perform DNSSEC validation on its behalf. All Windows DNS clients are nonvalidating security-aware stub resolvers, meaning they do not actually do the DNSSEC validation.

The Windows DNS client is nonvalidating, meaning that the Windows DNS client does not check to see whether the DNS records are secured but instead implicitly trusts the DNS server. The Windows DNS client flags the DNS request based on the NRPT table and expects the DNS server to perform the check for it. The DNS server returns the results regardless and indicates whether the check for DNSSEC was successful. If the check was successful, the Windows DNS client passes the results to the application requesting the DNS lookup.

Some impacts to consider when deploying DNSSEC are as follows:

Increased memory requirements—A DNSSEC zone may require as much as five times the memory on the Windows Server 2016 server as an unsigned zone.

Increased network traffic—A response to a DNS query against a DNSSEC zone will return additional DNSSEC records as compared to a unsigned zone and will increase the network traffic accordingly.

Increased processor utilization—The additional workload of validating DNSSEC zone data during queries can increase the processor load on the Windows Server 2016 server hosting the DNSSEC zone.

Increased number of DNS records—A DNSSEC zone will have up to four times the number of records as an unsigned zone. For large zones, this can be a significant factor.

It is important to ensure that adequate server-level resources are available when deploying DNSSEC, especially into existing Windows Server 2016 servers. For well-tuned virtual servers that are running at capacity, the additional workload to support DNSSEC on large zones can be a significant increase.

The DNSSEC configuration and management is done using the DNS Manager utility. To sign a DNS zone, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Select the zone to sign.

7. Right-click the zone and select DNSSEC and then Sign the Zone.

8. At the Zone Signing Wizard screen, click Next.

9. Choose the desired setting to sign the zone, then click Next.

10. Review the settings, and then click Next to sign the zone.

11. Click Finish to exit the wizard.

The zone companyabc.com is now encrypted. Figure 9.19 shows the zone records after encryption.

There are four records for each previous entry now:

Standard A Record

RR Signature (RRSIG) Record for the Standard Record

Next Secure (NSEC) Record

RR Signature (RRSIG) Record for the Next Secure Record

To distribute the trust anchor for the DNSSEC zone, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Select the zone to sign.

7. Right-click the zone and select DNSSEC and then Properties.

8. Select the Trust Anchor tab.

9. Check the Enable the Distribution of Trust Anchors for This Zone box.

10. Click OK to save the changes.

11. Click Yes to confirm the change.

12. Click OK when the setting is complete.

After the setting, there will be a new folder named Trust Points that contains a pair of records for the zone of type DNS KEY. These contain the public key for the trust anchor for the signed zone.

Without any additional configuration, the DNS clients blissfully ignore the DNSSEC for the zone. To have the clients use the DNSSEC properties of the DNS zone, they must be configured to request secure DNS entries. This is done by configuring a Name-resolution Policy Table (NRPT) policy for clients.

The NRPT policy can be configured through group policy. To create a NRPT group policy for the secure.companyabc.com zone, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select Tools and then Group Policy Management.

3. Expand Forest: companyabc.com, Domains, and select companyabc.com.

4. Right-click companyabc.com and select Create a GPO in This Domain, and Link It Here.

5. Enter NRPT Group Policy Object and click OK.

6. Right-click the NRPT Group Policy Object link and select Edit.

7. Expand Computer Configuration, Policies, Windows Settings, and select Name-resolution Policy.

8. In the To Which Part of the Namespace Does This Rule Apply? Field, select Suffix and enter companyabc.com.

9. On the DNSSEC tab, check the Enable DNSSEC in This Rule box.

10. Check the Validation box Require DNS Clients to Check That Name and Address Data Has Been Validated.

11. Figure 9.20 shows how the record should look. Click the Create button to create the record in the Name-resolution Policy Table at the bottom of the screen.

12. Close the GPMC editor to save the changes.

Now, all domain DNS clients will request that DNS servers check the validity of the lookups for domain companyabc.com using DNSSEC.

WINS provided a central database that can be referenced when a client system is looking up another system by hostname, and that is the key difference between WINS and DNS, hostname versus fully qualified name. As an example of this, a server named SERVER10 in the companyabc.com domain would have a WINS record named SERVER10 and a DNS record in the companyabc.com DNS zone named server10.companyabc.com.

WINS is considered legacy in the Microsoft world because NetBIOS resolution is being phased out in favor of the domain name system (DNS) form of name resolution. However, it is difficult to divorce WINS from modern networks because of the reliance on WINS by down-level (pre-Windows 2000) clients, legacy applications, and even some Microsoft services, such as the Distributed File System (DFS), that utilize NetBIOS resolution by default. Also, many Independent Software Vendors, or ISVs, develop their software for Microsoft networks, but their test networks sometimes only include a single network with no firewalling between systems. When these software applications are deployed on enterprise networks, they can fall short in name-resolution results, and deploying WINS might be the only viable solution.

As mentioned previously in this chapter, the new DNS GlobalNames feature is designed to remove the need for WINS.

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the Dashboard section and click the Add Roles and Features link.

3. Click Next on the Before You Begin page.

4. Leave the default selection Role-Based or Feature-Based Installation and click Next.

5. Select the server from the server pool to add the DNS role to and click Next.

6. Click Next to skip the Roles selection.

7. Select the WINS Server Feature check box, click Add Features button, and then click Next.

8. Click Install on the Confirmation page to install the WINS feature.

9. Click Close to exit the Add Roles and Features Wizard.

The DNS role can also be installed locally on a server core installation using PowerShell with the following command:

Click here to view code image

Install-WindowsFeature –Name WINS

A push partner for a particular WINS server is the server that “pushes” WINS database information to a receiving or pull partner. A pull partner is a WINS server from which changes are “pulled.” In a nutshell, if Server1 has Server2 configured as a push partner, Server2 must have Server1 configured as a pull partner, and vice versa.

A WINS push/pull topology should roughly map to an organization’s network topology. For example, if an organization is composed of two main offices that serve as network hubs, and several branch offices, each with its own WINS servers, the WINS push/pull topology could look something like Figure 9.21. In many organizations, however, if network connectivity is reliable between locations, it is a best practice to deploy only two WINS servers for the entire organization. This reduces WINS database replication and administration. Remote or branch office WINS servers should only be deployed on networks where network and/or firewall administrators block WINS traffic from remote networks.

1. Install WINS on two designated servers as previously outlined. For our example, we will use DC1 and DC2.

2. On one of the servers, log on and open the WINS console (Server Manager, Tools, and select WINS). If prompted, click Continue to confirm the action.

3. Expand the WINS server in the console tree, and then choose Replication Partners. The right pane will display any existing replication partners.

4. If the desired replication partner is not already defined, in the console tree, right-click Replication Partners and select New Replication Partner.

5. Enter the name of the desired WINS server and click OK. This adds the designated WINS server as a push/pull partner, meaning that these servers will replicate and synchronize their database with one another.

6. In the WINS console tree, right-click the WINS node and choose Add Server.

7. Type in the name of the WINS server previously defined as a replication partner.

8. After the second WINS server is added to the console, repeat the preceding steps to add the first server as a replication partner.

WINS replication partners need to be defined on both systems before replication will function.

WINS replication partners replicate their database information with one another every 30 minutes by default. If you, the WINS administrator, want to change this replication schedule, complete the following steps:

1. Open the WINS console (Server Manager, Tools, and select WINS). If prompted, click Continue to confirm the action.

2. Expand the WINS server in the console tree, and then choose Replication Partners.

3. Right-click Push/Pull Partner (if one does not exist, it will have to be created) and choose Properties.

4. In the replication partner property pages, select the Advanced tab, and change the replication interval time to the desired length, as indicated in Figure 9.22, and click OK to save the settings.

5. Repeat this process on the other replication partner.

This can also be used to change other partner replication settings, such as number of retries, start replication at service startup, persistent connections, and other pertinent replication information.

In addition to the local cache, clients by default always parse an LMHOSTS file, if one exists, before contacting a WINS server. If the LMHOSTS file contains erroneous information, it will impede proper name resolution. Always check to see whether this file is populated (it is usually located in %Systemroot%System32Driversetc on clients) before beginning to troubleshoot the WINS server.

Migration of an existing WINS environment is most easily accomplished through the procedure described in this section. This procedure allows for the migration of an entire WINS database to a new set of servers, but without affecting any clients or changing WINS server settings. Figure 9.23 illustrates a WINS migration using this procedure.

In Figure 9.23, the existing servers, OldServer1 and OldServer2, handle WINS traffic for the entire network of fictional CompanyABC. They are configured with IP addresses 10.1.1.11 and 10.1.1.12, which are configured in all client IP settings as Primary and Secondary WINS, respectively. OldServer1 and OldServer2 are configured as push/pull partners.

The new servers, NewServer1 and NewServer2, are added to the network with the WINS service installed and configured as push/pull partners for each other. Their initial IP addresses are 10.1.1.21 and 10.1.1.22. OldServer1 and NewServer1 are then connected as push/pull partners for the network. Because the servers are connected this way, all database information from the old WINS database is replicated to the new servers, as illustrated in step 1, shown in Figure 9.23.

After the entire WINS database is replicated to the new servers, the old servers are shut down (on a weekend or evening to minimize impact), and NewServer1 and NewServer2 are immediately reconfigured to take the IP addresses of the old servers, as illustrated in step 2, shown in Figure 9.24.

The push/pull partner relationship between NewServer1 and NewServer2 is then reestablished because the IP addresses of the servers changed. The entire downtime of the WINS environment can be measured in mere minutes, and the old database is migrated intact. In addition, because the new servers assume the old IP addresses, no client settings need to be reconfigured.

There are a few caveats with this approach, however. If the IP addresses cannot be changed, WINS servers must be changed on the client side. If you’re using DHCP, you can do this by leaving all old and new servers up in an environment until the WINS change can be automatically updated through DHCP. Effectively, however, WINS migrations can be made very straightforward through this technique, and they can be modified to fit any WINS topology.

This functionality must be enabled on the DNS server because it is not configured by default. This feature is configured on a zone-by-zone basis; however, if the forward lookup zone is an AD-integrated zone, each Windows Server 2016 DNS server hosting this zone will copy this WINS setting. To enable WINS resolution on a DNS server, follow these steps:

1. Launch Server Manager from a Windows 2016 server with a full GUI.

2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.

3. Right-click the DNS server to configure and select DNS Manager.

4. Select the DNS server name to configure.

5. Select the Forward Lookup Zones node.

6. Right-click the zone in question and click Properties.

7. Choose the WINS tab.

8. Check the Use WINS Forward Lookup check box.

9. Enter the IP address of the WINS servers to be used for resolution of names not found in DNS, and click Add to save the changes, as illustrated in Figure 9.26.

10. If you are replicating this zone between DNS servers that are not running Windows Server 2016 DNS services, make sure to check the Do Not Replicate This Record box. This prevents the records from being replicated to other servers during zone transfers.

11. Click OK to finish and return to the DNS Manager page.

Whether using DNS for a full-fledged AD DS implementation or simply setting up an Internet DNS presence, Windows Server 2016’s DNS continues on a successful, road-tested base to provide for a functional, reliable, enterprise name-resolution strategy.

Windows Server 2016 DNS whenever possible to support AD DS. If you must use a non-Windows DNS to host the AD zone, ensure that it supports SRV records, such as with BIND version 8.1.2 or later.

Establish a caching-only server in small branch office situations to alleviate large amounts of client query traffic across the network and to eliminate the need to replicate entire DNS zones to remote locations.

Configure DHCP to dynamically update DNS information for down-level clients if dynamic records are necessary.

Identify the sources of dynamically updated information to prevent problems with reliability.

Configure a DNS server to point to itself for DNS queries rather than to another DNS server.

Make any DNS implementation compliant with the standard DNS character set so that you can support zone transfers to and from non-Unicode-compliant DNS implementations such as UNIX BIND servers. This includes a–z, A–Z, 0–9, and the hyphen (-) character.

Use the GNZ to reduce the reliance on WINS in the enterprise.

Turn on Debug Logging on a per-server basis for more advanced DNS event log diagnosis only when required, and turn off this functionality when it’s no longer necessary.

When deploying DNSSEC, ensure that sufficient server resources are allocated to support the increased memory, network and processor requirements that signing the zones will create.

Implement redundant WINS servers by configuring servers as push/pull partners.

Limit the number of WINS servers on the network to reduce WINS server replication and administration and to simplify WINS troubleshooting.