Implement Domain Name System

Skill 1.2: Create and configure DNS zones and records

Although DNS is based on the concept of domains and subdomains, you store information about these domains and subdomains and the relationship between them in DNS zones. You can consider a DNS zone to be one or more domains and subdomains from your DNS infrastructure.

For example, the domains Adatum.com and sales.adatum.com might both be stored in a DNS zone called Adatum.com, or sales.adatum.com might be stored in a delegated zone called sales.adatum.com, while the parent domain, Adatum.com, is stored in its own zone.

You can store the zone in files on the DNS server or in the Active Directory Domain Services (AD DS) database. It is important that you know how and when to create primary and secondary zones, delegated zones, AD DS–integrated zones, and stub zones.

Overview of DNS zones

Zones are used by DNS servers to resolve client DNS queries. Usually, clients perform forward lookup queries in which a hostname must be resolved into the corresponding Internet Protocol Version 4 (IPv4) or Internet Protocol Version 6 (IPv6) address. Forward lookup queries are resolved by reference to forward lookup zones.

Forward lookup zones contain a variety of DNS record type (discussed in the next section) include:

• Host (A) records

• Alias (CNAME) records

• Records that identify which server is hosting a service, such as service (SRV) records and Mail exchanger (MX) records.

Less often, a DNS client queries a DNS server for the name of a host when it has the IPv4 or IPv6 address of the host. This is called a reverse lookup, and is satisfied by reference to a reverse lookup zone. Reverse lookup zones contain pointer (PTR) records.

Before you create your zone, you must first determine whether the zone is a forward or reverse lookup zone. Then you must determine whether the zone is primary, secondary, or AD DS–integrated. Strictly speaking, it is not the zone that is primary or secondary. Instead, it is the local copy of the zone that is primary or secondary. In other words, for there to be a secondary zone for Adatum.com, there must already exist a primary zone for Adatum.com on another DNS server from which the secondary can obtain the zone data.

When you first deploy the DNS server role in Windows Server 2016, the DNS Manager console navigation pane contains the server node, and beneath this, nodes for Forward Lookup Zones, Reverse Lookup Zones, Trust Points, and Conditional Forwarders. These nodes are all empty until you start to create zones on the DNS server.

Configure DNS zones

Windows Server 2016 supports a number of different zone types. These include primary zones, secondary zones, and Active Directory integrated zones. It’s important that you know how to create and configure these different types of zone..

Create primary zones

A primary zone is a writable copy of a DNS zone that exists on a DNS server. To create a primary zone, in the DNS Manager console, use the following procedure:

1. Right-click the Forward Lookup Zones node, and then click New Zone.

2. In the New Zone Wizard, on the Welcome To The New Zone Wizard page, click Next.

3. On the Zone Type page, select Primary Zone, as shown in Figure 1-17, and then click Next.

   

   FIGURE 1-17 Creating a primary zone

4. On the Zone Name page, in the Zone name box, type the zone name. For example, type Contoso.com. Click Next.

5. On the Zone File page:

   • If you have a DNS zone file with which to populate your zone (for example, from another DNS server), click Use This Existing File, specify the path to the file, and then click Next.

   • If you do not have an existing zone file, click Create A New File With This File Name and click Next. Figure 1-18 shows the filename that is created automatically when you choose this option.

     

     FIGURE 1-18 Defining the zone file

6. On the Dynamic Update page, shown in Figure 1-19, choose one of the following, and then click Next:

   

   FIGURE 1-19 Choosing dynamic updates

   • Allow Only Secure Dynamic Updates (Recommended For Active Directory) This option enables clients that support dynamic DNS to update their records in the DNS zone, such as when a client computer obtains a different IPv4 address from a Dynamic Host Configuration Protocol (DHCP) server. This option requires that each DNS record has an owner—the entity that registered the original record. Only the owner can update the record, which helps you secure your DNS records. This option is only available if you are creating an AD DS–integrated zone.

   • Allow Both Nonsecure And Secure Dynamic Updates This option also enables clients that support dynamic DNS to update their records in the DNS zone. It also supports nonsecure dynamic updates.

   • Do Not Allow Dynamic Updates Choose this option if you want to manually maintain all DNS records.

7. On the Completing The New Zone Wizard page, click Finish.

After you have created your primary zone, you can view the initial contents of the zone by using the DNS Manager console, as shown in Figure 1-20. It contains the Start of Authority (SOA) record and a Name Server (NS) record. These two records define which computer(s) are responsible, or authoritative, for the zone.

You can also add a primary zone by using the Add-DnsServerPrimaryZone Windows PowerShell cmdlet. For example, to complete the same process as in the preceding example by using Windows PowerShell, run the following command:

Add-DnsServerPrimaryZone -Name "Contoso.com" -ZoneFile "Contoso.com.dns"
-DynamicUpdate None

After you have created the primary zone, you can reconfigure it from the DNS Manager console by right-clicking the zone in the navigation pane and clicking Properties. You can then configure the following properties on each of the following tabs:

• General You can change the zone type, zone file name, the dynamic updates setting, and configure aging and scavenging.

• Start of Authority (SOA) Shown in Figure 1-21, you can reconfigure the SOA record. This includes the Primary server’s Fully Qualified Domain Name (FQDN), the responsible person’s contact details, and the Refresh, Retry, and Expire intervals. These intervals determine:

  

  FIGURE 1-21 Editing the Contoso.com DNS zone properties

  • Refresh interval The frequency with which other DNS servers that host the zone must refresh the zone data.

  • Retry interval The interval at which other DNS servers retry a refresh operation.

  • Expires after The length of time after failure to refresh zone data other DNS servers assume that the zone data has expired.

The Start of Authority (SOA) tab also contains the Minimum (Default) TTL value. This is the value that determines how long records in this zone can be cached by other recursive DNS servers.

• Name Servers Use this tab to add, remove, or edit the name and IP addresses of other DNS servers that host this zone.

• Zone Transfers Use this tab to configure how the zone data is transferred to other name servers hosting copies of the zone.

• WINS Use this tab to configure Windows Internet Name Service (WINS) and DNS integration. WINS supports the resolution of NetBIOS names. Less relevant today, NetBIOS names use a nonhierarchical structure based on a 16-character name. Enabling the Use WINS Forward Lookup option enables the DNS server to respond to requests for NetBIOS names without the client computer having to petition a WINS server directly.

You can configure the zone properties by using the Set-DnsServerPrimaryZone Windows PowerShell cmdlet. For example, to change the Contoso.com Primary Zone Dynamic Update settings with Windows PowerShell, run the following command:

Set-DnsServerPrimaryZone -Name "Contoso.com" -DynamicUpdate "NonsecureAndSecure"

Create and configure secondary zones

Creating a secondary zone is a different process from a primary zone. This is because a secondary zone hosts a read-only copy of a zone, which it obtains from another DNS server.

To create a secondary zone, you must know the name of the zone, and have the name and IP address of a DNS server that hosts a copy of the zone.

You can use the DNS Manager console to create a secondary zone. To do this, use the following procedure:

1. Right-click the Forward Lookup Zones node, and then click New Zone.

2. In the New Zone Wizard, on the Welcome To The New Zone Wizard page, click Next.

3. On the Zone Type page, select Secondary Zone, and then click Next.

4. On the Zone Name page, in the Zone Name box, type the zone name, and click Next.

5. On the Master DNS Servers page, in the Master Servers list, type the FQDN or IP address of the server that hosts a copy of the zone, press Enter, and then click Next, as shown in Figure 1-22.

   

   FIGURE 1-22 Defining the master server for a secondary zone

6. On the Completing The New Zone Wizard page, click Finish.

After you have added the secondary zone, it is necessary to configure the master DNS server that you specified. This is to enable zone transfers to your secondary server. To perform this step, switch to the DNS Manager console on the master server and perform the following procedure:

1. Right-click the appropriate zone, and then click Properties.

2. On the Name Servers tab, in the Name servers list, click Add to specify the FQDN and IP address of the DNS server hosting the secondary copy of the zone, as shown in Figure 1-23. Click OK.

   

   FIGURE 1-23 Configuring the Name Servers list

3. Click the Zone Transfers tab.

4. Select the Allow Zone Transfers check box. Then, as shown in Figure 1-24, choose one of the following:

   

   FIGURE 1-24 Configuring zone transfers

   • To Any Server.

   • Only To Servers Listed On The Name Servers Tab.

   • Only To The Following Servers (If you choose this option, you must click Edit to specify the list of name servers that you want to allow).

5. Click Notify.

6. In the Notify dialog box, either select Servers Listed On The Name Servers Tab, or else click The Following Servers, and then type the IP addresses of the secondary name servers you want to notify.

7. Click OK twice to complete configuration. Next, switch back to the DNS Manager console on the server hosting the secondary zone. You should see the DNS records populate into the secondary zone. If this does not happen immediately, right-click the secondary zone, and then click Transfer From Master.

You can use the Add-DnsServerSecondaryZone Windows PowerShell cmdlet to create a secondary zone. For example, the following command creates a secondary zone for the Adatum.com zone:

Add-DnsServerSecondaryZone -Name "Adatum.com" -ZoneFile "Adatum.com.dns"
-MasterServers 172.16.0.10

Configure delegation

DNS delegation is when a DNS server delegates authority over a part of its namespace to one or more other DNS servers. For example, Adatum.com and sales.adatum.com could be hosted in the same zone, Adatum.com, with the sales.adatum.com merely being a subdomain record. In this case, the authoritative DNS servers for Adatum.com and sales.adatum.com are the same. There is no need for the DNS servers in Adatum.com to refer recursive DNS servers to another domain.

Alternatively, you could create a separate zone for both Adatum.com and sales.adatum.com, each with their own DNS servers. Because one domain, sales.adatum.com, is a child domain of another domain, Adatum.com, there must exist a method to enable the authoritative name servers for the subdomain to be located. This method is called delegation, and is essentially a pointer to the authoritative name servers for a subdomain.

In Figure 1-25, you can see two DNS zones: Adatum.com, which contains a subdomain, marketing.adatum.com, and a second zone, sales.adatum.com, which contains a single domain, sales.adatum.com.

When determining whether to delegate a subdomain, consider the following:

• Your DNS zones are large, and delegation enables you to distribute the zone into smaller pieces across your organization.

• Organizational changes, such as mergers and acquisitions, mean that you have additional subdomains to manage.

• You have a distributed management structure, and want different departments or locations to be responsible for managing their own DNS namespaces.

To create a DNS delegation, in the DNS Manager console, perform the following procedure:

1. Right-click the parent zone. For example, right-click Adatum.com, and then click New Delegation. The New Delegation Wizard launches.

2. In the New Delegation Wizard, on the Welcome page, click Next.

3. On the Delegated Domain Name page, as shown in Figure 1-26, in the Delegated domain box, type the subdomain name. For example, type Sales. The suffix is added automatically. Click Next.

   

   FIGURE 1-26 Delegating the sales.Adatum.com zone

4. On the Name Servers page, click Add.

5. In the New Name Server Record dialog box, on the Server Fully Qualified Domain name (FQDN) box, type the name of the DNS server that hosts the new delegated zone, click Resolve, and then click OK.

6. On the Name Servers page, click Next, and then click Finish.

You can use the Add-DnsServerZoneDelegation Windows PowerShell cmdlet to create a delegated zone in an existing zone. For example, the following command creates the sales.adatum.com delegated zone in the existing Adatum.com zone:

Add-DnsServerZoneDelegation -Name "Adatum.com" -ChildZoneName "Sales" -NameServer
"ns1.Sales.Adatum.com" -IPAddress 172.16.0.136

After you have completed the delegation, if necessary, you should install DNS on the name server that you specified in the wizard, and create the delegated zone, in this case sales.adatum.com.

Configure Active Directory integration of primary zones

Traditional DNS zones are file-based and are stored in the local file system of the DNS server. DNS servers that host the primary copy of a zone have a writable version of the DNS zone file. Secondary servers have read-only copies of the zone file; they periodically obtain updates by using a zone transfer from their configured master, as you saw in Create and configure secondary zones.

In an AD DS environment, you have the option to create AD DS-integrated zones. In this situation, all copies of the zone data are writable. In addition, the zone data is stored securely in Active Directory and is replicated securely as part of the AD DS database.

The benefits of using AD DS-integrated zones are:

• Multimaster updates AD DS-integrated DNS zones are multimaster, and updates can be made to any copy of the zone data. This provides for redundancy in your DNS infrastructure. If your organization implements dynamic updates to the DNS zone, then geographically remote DNS clients can update their records by connecting to the nearest DNS server.

• Replicated using AD DS replication AD DS replication is based at the attribute-level. This means that only changed attributes, rather than entire records, are replicated. This means that the volume of zone transfer traffic can be reduced.

• Secure dynamic updates You can implement secure dynamic updates in an AD DS–integrated zone. This is discussed in the next section.

• Improved security You can delegate administration of AD DS-integrated zone, domains, and resource records with the AD DS object-level Access Control List (ACL) for the zone.

When you create zones on a DNS server that is also a domain controller, you have the option to install an AD DS-integrated zone. To create an AD DS-integrated DNS zone, use the following procedure:

1. On your domain controller, open DNS Manager.

2. Right-click the Forward Lookup Zones node, and then click New Zone.

3. In the New Zone Wizard, on the Welcome To The New Zone Wizard page, click Next.

4. On the Zone Type page, select Primary Zone, as shown in Figure 1-27, select the Store The Zone In Active Directory (Available Only If The DNS Server Is A Writable Domain Controller) check box, and then click Next.

   

   FIGURE 1-27 Selecting the zone type

5. On the Active Directory Zone Replication Scope page, as shown in Figure 1-28, select the appropriate zone replication option from the following:

   

   FIGURE 1-28 Specifying the preferred zone replication scope

   • To All DNS Servers Running On Domain Controllers In This Forest This option causes the zone data to replicate to all domain controllers running the DNS server role in the forest.

   • To All DNS Servers Running On Domain Controllers In This Domain This option (the default) causes the zone data to replicate to all domain controllers running the DNS server role in the current AD DS domain.

   • To All Domain Controllers In This Domain (For Windows 2000 Compatibility) This option provides backward compatibility with earlier versions of Windows Server. You would not normally select this option.

   • To All Domain Controllers Specified In The Scope Of This Directory Partition Directory partitions enable you to create an AD DS replication boundary that is not restricted to all domain controllers in the forest or local domain. The option is only available if you have created a directory partition before you configure the DNS zone.

6. Click Next.

7. On the Zone Name page, in the Zone name box, type the zone name, for example, type Contoso.com. Click Next.

8. On the Dynamic Update page, choose one of the following, and then click Next.

   • Allow Only Secure Dynamic Updates (Recommended For Active Directory)

   • Allow Both Non-Secure And Secure Dynamic Updates

   • Do Not Allow Dynamic Updates

9. On the Completing The New Zone Wizard page, click Finish.

You can also create an AD DS-integrated primary zone by using the Add-DnsServerPrimaryZone Windows PowerShell cmdlet. For example, to complete the same process as in the preceding example by using Windows PowerShell, run the following command:

Add-DnsServerPrimaryZone -Name "Contoso.com" -ReplicationScope "Domain"

On domain controllers, existing standard primary zones can be converted to AD DS–integrated zones. In DNS Manager, right-click the zone, and then click Properties. On the General page, click Change, and then select the Store The Zone In Active Directory (Available Only If The DNS Server Is A Writable Domain Controller) check box. Click OK twice.

Configure secure dynamic updates

If you have implemented an AD DS-integrated primary zone, you have the option of enabling secure dynamic updates. Dynamic updates is a feature in which DNS clients can update their own DNS records on their configured DNS server. This is particularly convenient when an organization assigns IP configuration to networked clients by using DHCP. If a client obtains a different IP address from a DHCP scope, they can register this change automatically on DNS.

With secure dynamic updates, the DNS server assigns ownership to the registered DNS records, and only the owner—the original DNS client—can update the records. To enable secure dynamic updates, you can choose one of the following options:

• Select the Allow Only Secure Dynamic Updates (Recommended For Active Directory) option on the Dynamic Updates page of the New Zone Wizard when you create an AD DS-integrated primary zone.

• After creating the AD DS-integrated primary zone, in DNS Manager, right-click the DNS zone, and then click Properties. On the General page, in the Dynamic Updates list, click Secure Only.

• After creating the AD DS-integrated primary zone in Windows PowerShell, use the Set-DnsServerPrimaryZone command. For example:

Set-DnsServerPrimaryZone -Name "Contoso.com" -DynamicUpdate "Secure"

Create and configure stub zones

You can use conditional forwarding as a means to redirect query traffic to a designated DNS server. With conditional forwarding, if a DNS query contains a specific domain name, for example Contoso.com, it is forwarded to a specific DNS server. To learn more about Conditional Forwarding, see “Configure forwarders, root hints, recursion, and delegation.”

Alternatively, you can also use a stub zones to achieve a similar result. A stub zone is used by a DNS server to help resolve names between two separate DNS namespaces, such as following a merger or acquisition. A stub zone differs from conditional forwarding in that the stub zone contains the complete list of DNS servers for the other domain.

Comparing Conditional Forwarding with stub Zones

Imagine that two DNS namespaces, Adatum.com and Contoso.com, are now owned by the A. Datum Corporation following an acquisition. For DNS clients in the Adatum.com domain to locate resources in the Contoso.com domain it requires the use of root hints by Adatum.com DNS servers.

To avoid this, in the Adatum.com domain, you could configure DNS conditional forwarding for the Contoso.com domain. With conditional forwarding, you configure to which DNS server(s) in the Contoso.com domain to forward DNS queries.

You can also use a stub zone for Contoso.com in the Adatum.com domain. This stub zone contains the complete list of DNS server that are authoritative for the foreign domain. This list of servers is updated automatically.

When considering whether to use conditional forwarding or stub zones, remember:

• You must manually maintain conditional forwarding records, while stub zones are maintained automatically.

• With conditional forwarding, you can designate the specific foreign DNS server to forward queries to, but with a stub zone, you cannot.

Creating a stub Zone

You can use the following procedure to create a stub zone. Open DNS Manager, and then:

1. Right-click the Forward Lookup Zones node, and then click New Zone.

2. On the New Zone Wizard, on the Welcome to the New Zone Wizard page, click Next.

3. On the Zone Type page, select Stub Zone, and then click Next.

4. On the Zone Name page, in the Zone name box, type the DNS domain name for the foreign domain, and then click Next.

5. On the Zone File page, if you have a DNS zone file that you use to populate your zone (for example, from another DNS server), click Use This Existing File, specify the path to the file on the Zone File page, and then click Next.

6. On the Master DNS Servers page, in the Master Servers list, type the IP address or FQDN of the DNS server in the foreign domain from which the DNS server obtains zone updates, and then click Next.

7. Click Finish to create the stub zone.

You must now populate the stub zone with the required records that includes the Start of Authority (SOA) record, and the Host (A) and NS records that pertain to the foreign DNS servers, and are retrieved from the specific master server(s). To manually perform this task, in the DNS Manager, right-click the stub zone and then click Transfer from Master.

You can use the Windows PowerShell Add-DnsServerStubZone cmdlet to create a stub zone. For example, to create a stub zone for Contoso.com, use the following command:

Add-DnsServerStubZone -Name "Contoso.com" -MasterServers "172.16.0.66" -ZoneFile
"Contoso.dns"

Configure a GlobalNames zone

Some older networked apps rely on a non-hierarchical naming standard known as NetBIOS. In the past, network clients that accessed these apps needed to be able to resolve these single-label NetBIOS names. You can use the WINS server feature to provide for NetBIOS name registration, resolution, and release.

The disadvantages of using WINS are:

• Organizations must maintain two name services, with the resultant administrative overhead.

• Network clients potentially use both DNS and WINS to resolve names, resulting in possible name resolution delay.

As an alternative to WINS, you can use the DNS GlobalNames zone in Windows Server 2016. When clients resolve single-label names, such as LON-SVR2, these names are resolved by reference to the GlobalNames zone. An organization has only a single GlobalNames zone, which you must create manually. Also, you must populate the zone with the required CNAME resource records that point to your organization’s server and app resources.

To create the GlobalNames zone, use the following procedure:

1. Open Windows PowerShell.

2. Run the Set-DnsServerGlobalNameZone –AlwaysQueryServer $true command to enable GlobalNames zone support.

3. Run the Add-DnsServerPrimaryZone –Name GlobalNames –ReplicationScope Forest command to create the GlobalNames zone.

4. Open DNS Manager and locate the GlobalNames zone node.

5. Create the required CNAME records for server resources that still use single-label names.

Configure DNS records

Zones contain DNS records that point either to name servers, hosts, services, or to other zones. After you have created your zones, you must populate them with records appropriate to your organization’s network. You must also be prepared to maintain these records to ensure the accuracy of zone data.

Create and configure DNS resource records

A DNS server exists to provide name resolution for DNS clients. In order for this to be possible, you must populate the DNZ zones that you create with appropriate DNS resource records. These resource records include:

• Host A host record—commonly given the abbreviation A—holds the IPv4 address for the specified hostname. AAAA records hold the IPv6 address for the specified hostname. These are probably the most common resource records and are found in forward lookup zones.

• Pointer Also known as PTR records, these enable a DNS client to resolve an IPv4 or IPv6 address into a hostname. These records exist in reverse lookup zones.

• Start of Authority Created when you create a primary zone, the SOA record contains information about the authoritative server for the zone, contact information for the zone, and other information, including TTL values for resource records in the zone.

• Name Server Name server (NS) records identify the authoritative name servers in the zone, including both primary and secondary servers. They also identify name servers for any delegated zones.

• Service Location Known as SRV records, these enable you to specify by service, protocol, and DNS domain name, which servers are hosting particular apps or services. If a DNS client is looking for a web server, for example, you can configure SRV records for the http service enabling clients to find all servers providing that service. Clients then use corresponding A or AAAA records to resolve the server names into IP addresses. An SRV record is more complex than many others, and contains the following fields: _Service.Proto.Name TTL Class SRV Priority Weight Port Target. For example: http._tcp.Contoso.com. IN SRV 0 0 80 www.Contoso.com. AD DS services, such as the Kerberos authentication service, use SRV records to advertise themselves to clients in an AD DS network.

• Alias CNAME records enable you to create an alias for a host. For example, the server lon-svr2.adatum.com might host a website. You can create an alias for this host with the name www by adding a CNAME record that points to the FQDN of the lon-svr2 server.

• Mail Exchanger MX records are used by Simple Mail Transfer Protocol (SMTP) hosts for transferring email around the Internet. In order for an originating SMTP host to route mail to a recipient with the email address Dave@Contoso.com, it is necessary for the originating host to know which hosts can receive the email at Contoso.com. You create MX records in the Contoso.com namespace to advertise which hosts provide this service. To help to ensure a reliable inbound email flow, you can advertise several hosts by using multiple MX records. Each can be assigned the same or different mail server priorities, or preference values. If you implement MX records with the same priority, email is routed to them randomly, distributing the load. If you use different values, the lower value is used first by the originating server, thereby enabling you to specify a preferred inbound server.

You can create these records manually from the DNS Manager console. Right-click the appropriate forward lookup zone (reverse lookup zone for PTR records), and then click the appropriate option for the record type you want to create, as shown in Figure 1-29.

Creating the resource records are straightforward, but vary slightly for each record type because you must specify different information for each separately. However, this is a very intuitive process. For example, for a new host record, you must specify the host’s name and its IP address. You can also select the option to create a PTR record for the host automatically. For an MX record, you must specify the FQDN of the host that provides SMTP email support, and a Mail server priority value.

If the record type you want is not listed on the context menu, (for example, SRV), select Other New Record from the context menu. Then select the record type you want in the Resource Record Type dialog box, and then click Create Record, shown in Figure 1-30. This list contains all record types, including those used less frequently.

You can use the Add-DnsServerResourceRecord Windows PowerShell cmdlet to create resource records. For example, the following command creates a host called lon-svr2 in the Contoso.com domain:

Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "lon-svr2"
-AllowUpdateAny -IPv4Address "172.16.0.27" -TimeToLive 01:00:00 -AgeRecord

Configure zone scavenging

Resource records often remain in a DNS zone even though the host that registered the record is no longer active. This is known as a stale record. You can use aging settings to determine when the DNS role can remove a stale record. This removal is known as scavenging.

Two parameters determine scavenging behavior:

• No-refresh Interval The no-refresh interval is the period of time that the record is not eligible to be refreshed. By default, this is also seven days.

• Refresh Interval The refresh interval is the time that the record is eligible to be refreshed by the client. The default is seven days.

Usually, a client host record cannot be refreshed for seven days after it is first registered (or refreshed). But then it must be refreshed within the following seven days. If it is not, the record becomes eligible to be scavenged.

To enable scavenging, you must enable it on both the DNS zone(s) and on the server(s) that host those zones.

To configure aging and scavenging on a DNS zone:

1. In DNS Manager, right-click the appropriate zone, and then click Properties.

2. On the General tab, click Aging.

3. In the Zone Aging/Scavenging Properties dialog box, shown in Figure 1-31, select the Scavenge Stale Resource Records check box, and then configure your preferred No-Refresh Interval and Refresh Interval values.

   

   FIGURE 1-31 Enabling and configuring zone aging and scavenging

4. Click OK twice.

You can also enable zone aging/scavenging with the Set-DnsServerZoneAging Windows PowerShell cmdlet. For example:

Set-DnsServerZoneAging Contoso.com -Aging $True -ScavengeServers 172.16.0.10

To configure scavenging on a DNS server, in the DNS Manager console:

1. Right-click the appropriate DNS server and then click Properties.

2. In the Server Properties dialog box, click the Advanced tab.

3. Select the Enable Automatic Scavenging Of Stale Records check box, and then in the Scavenging period box, specify the number of days, and then click OK.

You can enable DNS server aging/scavenging with the Set-DnsServerScavenging Windows PowerShell cmdlet. For example:

Set-DnsServerScavenging -RefreshInterval 7.00:00:00

Configure record options

You can configure a number of options for resource records, including preference, weight, priority, and tie to live.

Changing Preference, Weight, and Priority

Some resource records are assigned preference, weight, and priority values. These are used when there are multiple records that point to the same service or server and you want to control which servers are used first. For example, an AD DS domain controller registers its Kerberos authentication service DNS resource records with a priority value of 0 and a weight of 100, as shown in Figure 1-32.

You can adjust these initial values to determine which Kerberos authentication server is used by clients. DNS clients attempt to use the server with the lowest priority value. If multiple servers have the same priority value, clients use the server in proportion to their weight values. Similarly, if multiple MX records exist for an email domain name, then the server with the lowest preference value is used. You can adjust these values using the DNS Manager console or the Windows PowerShell Add-DnsServerResourceRecord or Set-DnsServerResourceRecord cmdlets using the Priority, Weight, and Preference parameters.

Changing time to Live values

All resource records have a time to live (TTL) value. The TTL is used to determine how long a record can reside in the DNS cache of a DNS client or DNS server that has recently resolved the record. These values should be representative of how frequently resource records change in your organization. If record values are fairly static, a higher TTL is acceptable. If they change frequently, then setting a TTL too high results in DNS cache being out of date, with resultant name resolution errors.

To change the TTL of a record in DNS Manager:

1. Right-click a resource record, and then click Properties.

2. In the Record Properties dialog box, in the Time to live (TTL) box, type the preferred value in days, hours, minutes, and seconds and then click OK.

Alternatively, use the Windows PowerShell Add-DnsServerResourceRecord or Set-DnsServerResourceRecord cmdlets with the -TimetoLive parameter.

Configure unknown record support

Windows Server 2016 adds support in the DNS server role for Unknown Records. Unknown Records are resource records with a format that is foreign to the Microsoft DNS server. Support for these unknown records means that you can add the unsupported record types into your zones to support specific apps that require them. The Windows DNS server does not perform record-specific processing for these unknown records, but does respond to DNS client requests for these records.

Configure round robin

You can use DNS round robin to help to distribute load across servers providing the same service. For example, if you had three web servers in your network and you wanted to distribute the client load across all three equally, one solution is to configure the same host resource record (www.contoso.com) and point it to three different IP addresses. For example:

• www.contoso.com 60 IN A 172.16.0.10

• www.contoso.com 60 IN A 172.16.0.12

• www.contoso.com 60 IN A 172.16.0.14

Round robin works by responding to each client request for the resolution of www.contoso.com with a differently ordered list of IP addresses. On the first request, the server with the IPv4 address of 172.16.0.10 is returned at the top of the list. Next, 172.16.0.12 is returned first on the list, and so on.

You configure round robin on DNS server on the Advanced server settings dialog box. It is enabled by default. You can also use the Set-DnsServer Windows PowerShell cmdlet.

Configure DNS scopes

Windows Server 2016 supports two types of DNS scopes. These are recursion scopes and zone scopes. Recursion scopes are a collection of settings that define recursion behavior in a DNS zone, while zone scopes are collections of resource records. To create, configure, and apply DNS scopes, you must use Windows Server 2016 DNS policies.

Configuring zone scopes

In Windows Server 2016, you can configure your DNS zones to have multiple zone scopes. Each zone scope contains its own set of DNS resource records. A resource record can exist in multiple zone scopes, each with different IP addresses depending on the scope. You can also use the zone scope to control zone transfers, enabling resource records from a zone scope in a primary zone to be transferred to the same zone scope in a secondary zone.

Typically, the first step in creating a zone scope is to create and configure client subnets. You do this in reference to your physical network topology. For example, to create subnet for DNS clients in New York and another for clients in London, use the following Windows PowerShell commands:

Add-DnsServerClientSubnet -Name "NYCSubnet" -IPv4Subnet "172.16.0.0/24"

Add-DnsServerClientSubnet -Name "LONSubnet" -IPv4Subnet "172.16.1.0/24"

Next, you create the DNS zone scopes for New York and London DNS clients by using the following commands:

Add-DnsServerZoneScope -ZoneName "Adatum.com" -Name "NYCZoneScope"

Add-DnsServerZoneScope -ZoneName "Adatum.com" -Name "LONZoneScope"

Configuring records in zone scopes

After you create the zone scopes, you must populate them with resource records. Again, you must do this with Windows PowerShell. To create a specific IP address record for clients in the New York City zone scope, run the following command:

Add-DnsServerResourceRecord -ZoneName "Adatum.com" -A -Name "www" -IPv4Address
"172.16.0.41" -ZoneScope "NYCZoneScope"

For clients in the London City zone scope, run the following command:

Add-DnsServerResourceRecord -ZoneName "Adatum.com" -A -Name "www" -IPv4Address
"172.16.1.22" -ZoneScope "LONZoneScope"

Configuring policies for zones

Finally, you must create the policies that instruct the DNS servers to respond to client queries based upon the previously defined factors. To configure the DNS servers to respond with resource records from the New York zone scope, create a DNS policy:

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

Similarly, for clients based in the London zone scope, you must add another policy:

Add-DnsServerQueryResolutionPolicy -Name "LONPolicy" -Action ALLOW -ClientSubnet
"eq,LONSubnet" -ZoneScope "LONZoneScope,1" -ZoneName "Adatum.com"

Now, if a client in the New York subnet petitions a DNS server for the IPv4 address of the www.adatum.com host, the DNS server responds with the IP address 172.16.0.41. If a client in London requests the same record, the client receives the IPv4 address 172.16.1.22.

Monitor DNS

Since DNS is such a critical service, providing name resolution and service location for configured clients, it is important that you ensure that DNS is running reliably and is optimized. To help you achieve this, you can use a number of monitoring and auditing tools in Windows Server.

Use DNS audit events and analytical events

Windows Server 2016 can collect a vast amount of logging data. Much of this logging is enabled by default, but features such as Debug logging (discussed in the “Configure DNS logging” section) must first be enabled before you can use them.

You can also use DNS Audit events and DNS Analytic events.

• DNS Audit Events These are enabled by default. Use to enable change tracking on your DNS servers. Every time a server, zone, or resource record is edited, an audit event is logged. Event IDs numbered 513 through 582 are logged in this regard, and are explained on the following website.

  Need More Review? Audit Events

  For more information about audit events in Microsoft DNS, refer to the Microsoft TechNet website at https://technet.microsoft.com/library/dn800669(v=ws.11).aspx#audit.

• DNS Analytic Events These are disabled by default. Windows logs an analytic event every time the DNS server sends or receives DNS information. Event IDs numbered 257 through 280 are logged in this regard, and are explained on the website listed below.

  Need More Review? Analytic Events

  For more information about analytic events in Microsoft DNS, refer to the Microsoft TechNet website at https://technet.microsoft.com/library/dn800669(v=ws.11).aspx#analytic.

Viewing Audit and Analytical Events

To view audit events, use the following procedure:

1. Open Event Viewer.

2. Expand Application And Services Logs, expand Microsoft, expand Windows, and then click DNS-Server.

3. Click the Audit folder, as shown in Figure 1-33. You can review events from here.

   

   FIGURE 1-33 Viewing Audit events for a DNS server

To view analytic events, use the following procedure:

1. Open Event Viewer.

2. Expand Application And Services Logs, expand Microsoft, expand Windows, and then click DNS-Server.

3. Right-click DNS-Server, click View, and then click Show Analytic And Debug Logs. The Analytical and Audit log folders display, as shown in Figure 1-33.

4. Right-click Analytical and then click Enable Log.

5. In the Event Viewer pop-up dialog box, click OK.

Analyze zone level statistics

Introduced in Windows Server 2012 R2, and improved in Windows Server 2016, DNS zone level statistics enable you to understand how a DNS server is being used for each authoritative zone on that server.

You can gather and view the following zone level statistics:

• Zone queries Provides the number of:

  • Queries received

  • Successful responses

  • Failed query responses

  • Name error responses

• Zone transfers Provides the number of zone transfer:

  • Requests received when operating as a primary server for a specific zone

  • Requests sent when operating as a secondary server for a specific zone

  • Requests received when operating as a secondary server for a specific zone

• Zone transfers statistics also provide the number of zone transfers

  • Received by the DNS Server service when operating as a secondary server for a specific zone

  • Sent by the DNS Server service when operating as a master server for a specific zone

• Zone updates Provides the total number of

  • Dynamic update requests received

  • Dynamic updates rejected

To access these statistics, use the Windows PowerShell Get-DnsServerStatistics cmdlet. For example:

Get-DnsServerStatistics -ZoneName "Adatum.com"

Chapter summary

• You can install the DNS server role on Windows Server 2016 and Nano Server.

• DNS forwarders, recursion, and root hints enable you to control the flow of DNS query traffic throughout your organization’s network.

• You can implement DNSSEC, DNS socket pool, cache locking, DANE, and response rate limiting to help to secure your DNS infrastructure from malicious attacks.

• DNS policies in Windows Server 2016 help you configure DNS behavior throughout your organization without needing to manually configure each DNS server.

• DNS logging can help you to pinpoint problems with the DNS servers in your organization before they can affect your users.

• The DNS server role is affected by CPU and memory resources, and proactive monitoring of these resources can be beneficial.

• Although the DNS namespace is based on domains and subdomains, the data that maintains this namespace is stored in DNS zones.

• Secondary zones receive updates via their configured master server.

• DNS delegation enables a part of your DNS namespace, such as a child domain, to be authoritatively maintained in a separate zone.

• AD DS-integrated zones provide for multimaster updates, secure replication, and secure dynamic updates.

• Conditional forwarding provides similar function to stub zones.

• DNS scopes are based on DNS policies.