Active Directory–integrated zones

Active Directory–integrated zones can be replicated to all domain controllers in a domain, all domain controllers in a forest, or all domain controllers enrolled in a specific Active Directory partition. You can create an Active Directory–integrated zone only on a writable domain controller, but you can also configure primary and stub zones as Active Directory–integrated zones. Domain controllers with DNS servers that host Active Directory–integrated zones can process updates to those zones.

When you choose to make a zone Active Directory–integrated, you have the option to configure a replication scope. You can configure the zone to be replicated, so that it is present on all domain controllers in the domain, in the forest, or within the scope of a custom Active Directory partition. When determining the appropriate replication scope, consider which clients need regular, direct access to the zone and which clients only require occasional, indirect access.

You can use custom directory partitions to replicate a zone to some, but not all, domain controllers. You can only select this option if there is an existing custom DNS application directory partition. You can use the Add-DNSServerDirectoryPartition cmdlet to create a directory partition. For example, to create a DNS Server directory partition called Tasmania on a subset of your organization’s domain controllers, execute this command:

Click here to view code image

Add-DNSServerDirectoryPartition –Name Tasmania

Active Directory–integrated zones use multimaster replication, meaning any domain controller that hosts the DNS zone can process updates to the zone. When creating a DNS zone, you must specify whether the zone supports dynamic updates, which allow clients to update DNS records. This is useful in environments in which clients change IP addresses on a regular basis. When a client gets a new IP address, it can update the record associated with its host name in the appropriate DNS zone. There are three dynamic update configuration options:

• Allow Only Secure Dynamic Updates. You can use this option only with Active Directory–integrated zones. Only authenticated clients can update DNS records.

• Allow Both Non-Secure And Secure Dynamic Updates. With this option, any client can update a record. Although this option is convenient, it is also insecure because any client can update the DNS zone, which could potentially redirect clients that trust the quality of the information stored on the DNS server.

• Do Not Allow Dynamic Updates. When you choose this option, all DNS updates must be performed manually. This option is very secure, but it is also labor-intensive.

An Active Directory–integrated zone can replicate to a read-only domain controller (RODC). With this configuration, the RODC-hosted zone is read only and the RODC cannot process updates to the zone, which is also the case with a traditional writable domain controller. When you replicate an Active Directory–integrated zone to an RODC, the RODC forwards any client that wants to update the zone to a writable domain controller.

You can create an Active Directory–integrated primary zone by using the Add-DnsServerPrimaryZone cmdlet with the ReplicationScope parameter. For example, to create the Active Directory–integrated zone cpandl.com so that it replicates to all domain controllers in the forest, issue this command:

Click here to view code image

Add-DnsServerPrimaryZone –Name cpandl.com –ReplicationScope Forest

When you first install Active Directory, the installation process ensures that the DNS zone associated with the root domain is automatically configured as an Active Directory–integrated zone. This root domain zone is automatically replicated to all domain controllers in the forest.

Primary and secondary zones

In traditional DNS implementations, a single server hosts a primary zone, which processes all zone updates, and a collection of secondary servers replicate zone data from the primary zone. One drawback to this model is that if the primary server fails, no zone updates can occur until the primary zone is restored.

Windows Server 2019 supports two types of primary zones: Active Directory–integrated zones and standard primary zones. Active Directory–integrated zones can only be hosted on computers that also function as domain controllers. Computers running Windows Server 2019 that do not function as domain controllers, however, can host standard primary zones. When you create a primary zone on a computer that is not a domain controller, the wizard does not enable you to specify a replication scope for the zone.

A secondary zone is a read-only copy of a primary zone. Secondary zones cannot process updates and can only retrieve updates from a primary zone. Also, secondary zones cannot be Active Directory—integrated zones, but you can configure a secondary zone for an Active Directory–integrated primary zone. Prior to configuring a secondary zone, you need to configure the primary zone that you want it to replicate from to enable transfers to that zone. You can do this on the Zone Transfers tab of the Zone Properties dialog box. Secondary zones work best when the primary zone that they replicate from does not update frequently. If the primary zone does update frequently, it is possible that the secondary zone might have out-of-date records.

Use the Add-DNSServerSecondaryZone cmdlet to create a secondary zone. For example, to create a secondary zone for the australia.contoso.com zone, where a DNS server hosting the primary zone is located at 192.168.15.100, issue the following command:

Click here to view code image

Add-DnsServerSecondaryZone -Name "australia.contoso.com" -ZoneFile "australia.contoso.com.dns" -MasterServers 192.168.15.100

Reverse lookup zones

Reverse lookup zones translate IP addresses into FQDNs. You can create IPv4 or IPv6 reverse lookup zones, and you can also configure reverse lookup zones as Active Directory–integrated zones, standard primary zones, secondary zones, or stub zones. The domain controller promotion process automatically creates a reverse lookup zone based on the IP address of the first domain controller promoted in the organization.

Reverse lookup zones are dependent on the network ID of the IP address range that they represent. IPv4 reverse lookup zones can only represent /8, /16, or /24 networks, which are the old Class A, Class B, and Class C networks. You can’t create a single reverse lookup zone for IP subnets that doesn’t fit into one of these categories, and the smallest reverse lookup zone you can create is for subnet mask /24, or 255.255.255.0.

Use the Add-DNSPrimaryZone cmdlet and the NetworkID parameter to create a reverse lookup zone. For example, to create an Active Directory–integrated reverse lookup zone for the 192.168.15.0/24 subnet, issue the following command:

Click here to view code image

Add-DnsServerPrimaryZone -NetworkID “192.168.15.0/24” -ReplicationScope “Forest”

Zone delegation

Zone delegations function as pointers to the next subordinate DNS layer in the DNS hierarchy. For example, if your organization uses the contoso.com DNS zone and you want to create a separate australia.contoso.com DNS zone, you can perform a zone delegation so that the DNS servers for the contoso.com DNS zone point to the DNS servers for the australia.contoso.com DNS zone. When you create a new child domain in an Active Directory forest, zone delegation occurs automatically. When you are performing a manual delegation, create the delegated zone on the target DNS server prior to performing the delegation from the parent zone.

Although you can delegate several levels, remember that the maximum length of a FQDN is 255 bytes, and the maximum length of a FQDN for an Active Directory Domain Services domain controller is 155 bytes.

Use the Add-DnsServerZoneDelegation cmdlet to add a delegation. For example, to add a delegation for the australia.contoso.com zone to the contoso.com zone pointing at the name server ausdns.australia.contoso.com, which has the IP address 192.168.15.100, use the following command:

Click here to view code image

Add-DnsServerZoneDelegation -Name "contoso.com" -ChildZoneName "australia" -NameServer "ausdns.australia.contoso.com" -IPAddress 192.168.15.100 -PassThru
-Verbose

Forwarders and conditional forwarders

Forwarders and conditional forwarders enable your DNS server to forward traffic to specific DNS servers when a lookup request cannot be handled locally. For example, you might configure a conditional forwarder to forward all traffic for resource records in the tailspintoys.com zone to a DNS server at a specific IP address. If you don’t configure a forwarder or if a configured forwarder can’t be contacted, the DNS Server service forwards the request to a DNS root server and the request is resolved normally.

Forwarders

When you want to have a specific DNS server on the Internet handle your organization’s DNS resolution traffic, you are likely to use a DNS forwarder rather than have your DNS server just use the root server. Most organizations configure their ISP’s DNS server as a forwarder. When you do this, the ISP’s DNS server performs all the query work, returning the result to your organization’s DNS server. Your organization’s DNS server then returns the result of the query back to the original requesting client.

You configure forwarders on a per-DNS server level. You can configure a forwarder using the DNS Manager. You can do this by editing the properties of the DNS server and then configuring the list of forwarders on the Forwarders tab.

You can create a DNS forwarder by using the Add-DnsServerForwarder cmdlet. For example, to create a DNS forwarder for a DNS server with 10.10.10.111 as the IP address, issue this command:

Click here to view code image

Add-DnsServerForwarder 10.10.10.111

You can’t create a forwarder on one DNS server and then have it replicate to all other DNS servers in the forest or the domain; however, this is possible with conditional forwarders and stub zones.

Conditional forwarders

Conditional forwarders only forward address requests from specific domains rather than forwarding all requests that can’t be resolved by the DNS server. When configured, a conditional forwarder takes precedence over a forwarder. Conditional forwarders are useful when your organization has a trust relationship or partnership with another organization. You can configure a conditional forwarder that directs all traffic to host names within that organization instead of having to resolve those host names through the standard DNS-resolution process.

You can create conditional forwarders using the Add-DnsServerConditionalForwarderZone PowerShell cmdlet. For example, to create a conditional forwarder for the DNS domain tailspintoys.com that forwards DNS queries to the server at IP address 10.10.10.102 and also replicates that conditional forwarder to all DNS servers within the Active Directory forest, issue this command:

Click here to view code image

Add-DnsServerConditionalForwarderZone –MasterServers 10.10.10.102 –Name tailspintoys.com –ReplicationScope Forest

Stub zones

A stub zone is a special zone that stores authoritative name server records for a target zone. Stub zones have an advantage over forwarders when the address of a target zone’s authoritative DNS server changes on a regular basis. Stub zones are often used to host the records for authoritative DNS servers in delegated zones. Using stub zones in this way ensures that delegated zone information is up to date. If you create the stub zone on a writable domain controller, it can be stored with Active Directory and replicated to other domain controllers in the domain or forest.

You can add a stub zone using the Add-DnsServerStubZone cmdlet. For example, to add a DNS stub zone for the fabrikam.com zone using the DNS server at 10.10.10.222 and to also replicate that stub zone to all DNS servers in the forest, execute this command:

Click here to view code image

Add-DnsServerStubZone –MasterServers 10.10.10.222 –Name fabrikam.com –ReplicationScope Forest –LoadExisting

GlobalNames zones

GlobalNames zones are a single-label, name-resolution replacement for WINS that can utilize existing DNS infrastructure. Deploying GlobalNames zones enables organizations to retire their existing WINS servers. You can use GlobalNames zones as long as your organization’s DNS servers are running Windows Server 2008 or later.

Your organization should consider deploying GlobalNames zones instead of WINS in the following situations:

• Your organization is transitioning to IPv6. WINS does not support IPv6, and you need to support single-label name resolution.

• Single-label name resolution is limited to a small number of hosts that rarely change. GlobalNames zones must be updated manually.

• You have a large number of suffix search lists because of a complex naming strategy or disjoined namespace.

Entries in the GlobalNames zones must be populated manually. GlobalNames zone entries are alias (CNAME) records to existing DNS A or AAAA records. The existing DNS A and AAAA records can be dynamically updated, with these updates flowing on to records in the GlobalNames zone.

To deploy a GlobalNames zone in a forest, perform the following steps:

1. On a domain controller that is configured as a DNS server, create a new Active Directory–integrated forward lookup zone and configure it to replicate to every domain controller in the forest using the New Zone Wizard.

2. On the Zone Name page, enter GlobalNames as the zone name. You can also accomplish the same task by running the following Windows PowerShell command:

   Click here to view code image

   Add-DnsServerPrimaryZone –Name GlobalNames –ReplicationScope Fores

3. Next, activate the GlobalNames zone on each authoritative DNS server hosted on a domain controller in the forest. To do this, execute the following Windows PowerShell command. (where DNSServerName is the name of the domain controller hosting DNS):

   Click here to view code image

   Set-DnsServerGlobalNameZone –ComputerName DNSServerName –Enable $True

4. To populate the GlobalNames zone, create alias (CNAME) records in the GlobalNames zone that point to A or AAAA records in existing zones.

Peer Name Resolution Protocol

Peer Name Resolution Protocol (PNRP) provides IPv6 with a peer-to-peer name resolution method. Devices that are connected to the Internet and are assigned an IPv6 address can publish their peer name/address combination and provide it to peers. These name combinations include both FQDN and single-label names. Other devices query peers to learn IPv6 addressing information. For example, imagine that there are computers named Sydney, Melbourne, Canberra, Adelaide, Brisbane, Hobart, and Perth. Computer Sydney needs to know the IPv6 address of Perth. Sydney is near Canberra, Melbourne, and Brisbane. Sydney queries Canberra, Melbourne, and Brisbane, one after the other, to determine whether any of them knows Perth’s IPv6 address. Rather than using a central server, such as DNS or WINS, PNRP uses the information that each individual computer knows about all the other computers to determine address information. PNRP has the following properties:

• Does not require a centralized infrastructure. Servers are required only for bootstrapping.

• Can scale to billions of names and is fault tolerant. Multiple computers can host copies of the same PNRP record.

• Names are updated in real time and PNRP is designed to not return stale addresses.

• Can be used to name services rather than just computers.

• Names can be published in a secure or insecure manner. When published in a secure manner, PNRP uses public key cryptography to validate records.

• Installed as a feature.

PNRP peer groups are termed clouds. When installed, PNRP can use the following clouds:

• Global cloud. Uses the global IPv6 address scope and represents all computers and devices connected to the Internet. There is a single global cloud.

• Link-local cloud. Uses all addresses in the link-local IPv6 address scope. It roughly corresponds to the local subnet. An organization can have multiple link-local clouds.

Resource records

DNS supports a large number of resource records. The most basic resource record maps an FQDN to an IP address. More complex resource records provide information about the location of services, such as SMTP servers and domain controllers.

Host records

Host records are the most common form of record and can be used to map FQDNs to IP addresses. There are two types of host records:

• The A record, which is used to map FQDNs to IPv4 addresses

• AAAA records, which are used to map FQDNs to IPv6 addresses

You can add a new host record to a zone by right-clicking the zone in DNS Manager and then clicking New Host (A or AAAA). You also have the option of creating a pointer (PTR) record in the appropriate reverse lookup zone, if one exists. You can add host records with the Add-DnsServerResourceRecordA cmdlet and AAAA records with the Add-DnsServerResourceRecordAAAA cmdlet.

Alias (CNAME)

An alias—or CNAME—record enables you to provide an alternate name when there is an existing host record. You can create as many aliases for a particular record as you need. To create a new alias in a zone, right-click the zone in DNS Manager and then click New Alias (CNAME). When you create an alias, you must point the alias to an existing host record. You can use the Browse button to navigate to the target host record or enter it manually. You can also add an alias record to a zone from Windows PowerShell by using the Add-DnsServerResourceRecordCName cmdlet.

Mail exchanger

Mail exchanger (MX) records are used to locate mail gateways. For example, when a remote mail gateway wants to forward an email message to an email address associated with your organization’s DNS zone, it performs an MX lookup to determine the location of the mail gateway. After that determination has been made, the remote mail gateway contacts the local gateway and transmits the message. MX records must map to existing host records. To create an MX record, right-click the zone in DNS Manager, click New Mail Exchanger (MX), and enter information in the New Resource Record dialog box. The Mail Server Priority field is available to allow for the existence of more than one MX record in a zone and is often used when organizations have multiple mail gateways. This is done so that if an organization’s primary mail gateway fails, remote mail servers can forward message traffic to other mail gateways. You can add MX records using the Add-DnsServerResourceRecordMX PowerShell cmdlet.

Pointer record

Pointer (PTR) records enable you to connect IP addresses to FQDNs and are hosted in reverse lookup zones. When you create a host record, a PTR record is automatically created by default if an appropriate reverse lookup zone exists. To create a PTR record, right-click the reverse lookup zone in DNS Manager, click New Pointer (PTR), and enter the PTR record information in the New Resource Record dialog box. You can create a PTR record from Windows PowerShell by using the Add-DnsServerResourceRecordPtr cmdlet.

Zone aging and scavenging

Aging and scavenging provide a technique to reduce the incidence of stale resource records in a primary DNS zone. Stale records are records that are out of date or no longer relevant. If your organization has zones that relate to users with portable computers, such as laptops and tablets, those zones might end up accumulating stale resource records. This can lead to the following problems:

• DNS queries return stale rather than relevant results.

• Large zones can cause DNS server performance problems.

• Stale records might prevent DNS names from being reassigned to different devices.

To resolve these problems, you can configure the DNS Server service to do the following:

• Time stamp resource records that are dynamically added to primary zones. This occurs when you enable aging and scavenging.

• Age resource records based on a refresh time period.

• Scavenge resource records that are still present beyond the refresh period.

After you configure the DNS Server service, aging and scavenging occurs automatically. It is also possible to trigger scavenging by right-clicking the DNS server in DNS Manager and then clicking Scavenge Stale Resource Records. You can also configure aging and scavenging using the Set-DnsServerScavenging cmdlet. For example, to enable stale resource record scavenging on all zones of a DNS server and to set the Scavenging and Refresh Intervals to 10 days, issue this command:

Click here to view code image

Set-DnsServerScavenging –ApplyOnAllZones –RefreshInterval 10.0:0:0 –ScavengingInterval 10.0:0:0 –ScavengingState $True

DNSSEC

Domain Name System Security Extensions (DNSSEC) add security to DNS by enabling DNS servers to validate the responses given by other DNS servers. DNSSEC enables digital signatures to be used with DNS zones. When the DNS resolver issues a query for a record in a signed zone, the authoritative DNS server provides both the record and a digital signature, enabling validation of that record.

To configure DNSSEC, perform the following steps:

1. Right-click the zone in DNS manager, click DNSSEC, and then click Sign The Zone.

2. On the Signing Options page, select Use Default Settings To Sign The Zone.

When you configure DNSSEC, three new resource records are available. These records have the following properties:

• Resource Record Signature (RRSIG) record. This record is stored within the zone, and each is associated with a different zone record. When the DNS server is queried for a zone record, it returns the record and the associated RRSIG record.

• DNSKEY. This is a public key resource record that enables the validation of RRSIG records.

• Next Secure (NSEC/NSEC3) record. This record is used as proof that a record does not exist. For example, the contoso.com zone is configured with DNSSEC. A client issues a query for the host record tasmania.contoso.com and if there is no record for tasmania.contoso.com, the NSEC record returns, which informs the host making the query that no such record exists.

In addition to the special resource records, a DNSSEC implementation has the following components:

• Trust anchor. This is a special public key associated with a zone. Trust anchors enable a DNS server to validate DNSKEY resource records. If you deploy DNSSEC on a DNS server hosted on a domain controller, the trust anchors can be stored in the Active Directory forest directory partition. This replicates the trust anchor to all DNS servers hosted on domain controllers in the forest.

• DNSSEC Key Master. This is a special DNS server that you use to generate and manage signing keys for a DNSSEC-protected zone. Any computer running Windows Server 2012 or later that hosts a primary zone, whether standard or integrated, can function as a DNSSEC Key Master. A single computer can function as a DNSSEC Key Master for multiple zones. The DNSSEC Key Master role can also be transferred to another DNS server that hosts the primary zone.

• Key Signing Key (KSK). You use the KSK to sign all DNSKEY records at the zone root. You create the KSK by using the DNSSEC Key Master.

• Zone Signing Key (ZSK). You use the ZSK to sign zone data, such as individual records hosted in the zone. You create the ZSK by using the DNSSEC Key Master.

You can configure group policy to ensure that clients only accept records from a DNS server for a specific zone if those records have been signed using DNSSEC. You do this by configuring the Name Resolution Policy Table, which is located in the Computer ConfigurationPoliciesWindows SettingsName Resolution Policy node of a GPO. You create entries in the table—for example, requiring that all queries against a specific zone require DNSSEC validation. You can configure the NRPT by using Group Policy or through Windows PowerShell.

DNSSEC is appropriate for high-security environments, such as those where IPSec and authenticating switches are in use. DNSSEC protects against attacks where clients are fed false DNS information. In many small- to medium-sized environments, the likelihood of such an attack is minimal; however, in high-security environments, enabling DNSSEC is a prudent precaution.

DNS event logs

The DNS server log is located in the Applications And Services Logs folder in Event Viewer. Depending on how you configure event logging on the Event Logging tab of the DNS server’s properties, this event log can record information including:

• Changes to the DNS service, such as when the DNS server service is stopped or started.

• Zone loading and signing events.

• Modifications to the DNS server configuration.

• DNS warning and error events.

By default, the DNS server records all these events. It’s also possible to configure the DNS server to only log errors, or you can have it log errors and warning events. The key with any type of logging is that you should only enable logging for information that you might need to review at some point in time. Many administrators log everything “just in case,” even though they are only ever interested in a specific type of event.

In the event that you need to debug how a DNS server performs, you can enable Debug Logging on the Debug Logging tab of the DNS server’s Properties dialog box. Debug logging is resource intensive, and you should only use it when you have a specific problem related to the functionality of the DNS server. You can configure debug logging to use a filter, so that only traffic from specific hosts is recorded, instead of recording traffic from all hosts that interact with the DNS server.

DNS options

In high-security environments, there are a number of steps that you can take to make a DNS server more secure from attackers who attempt to spoof it. Spoofing can cause the server to provide records that redirect clients to malicious sites. While DNSSEC provides security for zones hosted on the server, most DNS server traffic involves retrieving information from remote DNS servers and passing that information on to clients. In this section, you learn about settings that you can configure to ensure that the information relayed to clients retains its integrity in the event that a nefarious third party attempts to spoof your organization’s DNS servers.

DNS socket pool

DNS socket pool is a technology that makes cache-tampering and spoofing attacks more difficult by using source port randomization when issuing DNS queries to remote DNS servers. To spoof the DNS server with an incorrect record, the attacker needs to guess which randomized port was used as well as the randomized transaction ID that was issued with the query. By default, the DNS server running on Windows Server 2012 or later uses a socket pool of 2,500. You can use the dnscmd command-line tool to change the socket pool size to a value between 0 and 10,000. For example, to set the socket pool size to 4,000, issue the following command:

Click here to view code image

Dnscmd /config /socketpoolsize 4000

You must restart the DNS service before you can use the reconfigured socket pool size.

DNS cache locking

DNS cache locking provides you with control over when information stored in the DNS server’s cache can be overwritten. For example, when a recursive DNS server responds to a query for a record that is hosted on another DNS server, it caches the results of that query so that it doesn’t have to contact the remote DNS server if the same record is queried again within the Time to Live (TTL) value of the resource record. DNS cache locking prevents record data in a DNS server’s cache from being overwritten until a configured percentage of the TTL value has expired. By default, the cache-locking value is set to 100 percent, but you can reset it by using the Set-DNSServerCache cmdlet with the LockingPercent option. For example, to set the cache-locking value to 80 percent, issue the following command and then restart the DNS server service:

Click here to view code image

Set-DNSServerCache –LockingPercent 80

DNS recursion

By default, DNS servers on Windows Server 2012 and later perform recursive queries on behalf of clients. This means when the client asks the DNS server to find a record that isn’t stored in a zone hosted by the DNS server, the DNS server then goes out and finds the result of that query and passes it back to the client. It’s possible however, for nefarious third parties to use recursion as a denial-of-service attack vector, which could slow a DNS server to the point where it becomes unresponsive. You can disable recursion on the Advanced Tab of the DNS server’s properties, or you can configure it by using the Set-DNSServerRecursion cmdlet. For example, to configure the recursion retry interval to 3 seconds, use the following command:

Click here to view code image

Set-DNSServerRecursion -RetryInterval 3 -PassThru

Netmask ordering

Netmask ordering ensures that the DNS server returns the host record on the requesting client’s subnet, if such a record exists. For example, imagine that the following host records exist on a network that uses 24-bit subnet masks:

10.10.10.105 wsus.contoso.com

10.10.20.105 wsus.contoso.com

10.10.30.105 wsus.contoso.com

If netmask ordering is enabled and a client with the IP address 10.10.20.50 performs a lookup of wsus.contoso.com, the lookup always returns the record 10.10.20.105 because this record is on the same subnet as the client. If netmask ordering is not enabled, the DNS server returns records in a round-robin fashion. If the requesting client is not on the same network as any of the host records, the DNS server also returns records in a round-robin fashion. Netmask ordering is useful for services, such as WSUS, that you might have at each branch office. When you use netmask ordering, the DNS server redirects the client in the branch office to a resource on the local subnet when one exists.

Netmask ordering is enabled by default on Windows Server 2012 and later DNS servers. You can verify that netmask ordering is enabled by viewing the Advanced Properties of the DNS server.

Response rate limiting

Distributed denial-of-service attacks against DNS servers are becoming increasingly common. One method of ameliorating such attacks is by configuring response rate limiting; this setting determines how a DNS server responds to clients sending an unusually high number of DNS queries. You can configure the following response rate limiting settings:

• Responses Per Second. Determines the maximum number of times an identical response can be returned to a client per second.

• Errors Per Second. Determines the maximum number of error responses returned to a client per second.

• Window. The timeout period for any client that exceeds the maximum request threshold.

• Leak Rate. Determines how often the DNS server responds to queries if a client is in the suspension window. The leak rate is the number of queries it takes before a response is sent. A leak rate of 42 means that the DNS server only responds to one query out of every 42 when a client is in the suspension window period.

• TC Rate. Tells the client to try connecting with TCP when the client is in the suspension window. The TC rate should be below the leak rate to give the client the option of attempting a TCP connection before a leak response is sent.

• Maximum Responses. The maximum number of responses that a DNS server issues to a client during the timeout period.

• White List Domains. Domains that are excluded from response rate limiting settings.

• White List Subnets. Subnets that are excluded from response rate limiting settings.

• White List Server Interfaces. DNS server interfaces that are excluded from response rate limiting settings.

DANE

DNS-based Authentication of Named Entities (DANE) allows you to configure records that use Transport Layer Security Authentication (TLSA) to inform DNS clients of which certificate authorities (CA) they should accept certificates from for your organization’s domain name DNS zone. DANE blocks attackers from using attacks where a certificate is issued from a rogue CA and is used to provide validation for a rogue website when a DNS server is compromised. When DANE is implemented, a client requesting a TLS connection to a website, such as www.tailspintoys.com, knows that it should only accept a TLS certificate from a specific CA. If the TLS certificate for www.tailwindtraders.com is from a different CA, the client knows that the website that appears to be at www.tailwindtraders.com might have been compromised or that the client might have been redirected by an attacker corrupting a DNS cache.

DNS Policies

You use DNS policies to control how DNS servers respond to queries based on the properties of that query. You can configure DNS policies to achieve the following:

• Application load balancing. Allows you to weight which endpoint is returned when multiple endpoints exist for an address. For example, returning one IP address 75 percent of the time and another IP address 25 percent of the time. This differs from DNS round robin where multiple IP addresses associated with a specific addresse would be returned to clients on an equal basis (netmask ordering being the exception).

• Traffic management. The DNS server provides a response to the client that directs them to the datacenter closest to them. For example, clients making DNS requests from Australia are redirected to an application endpoint in Australia, and clients making DNS requests from Canada are redirected to an application endpoint in Canada.

• Split Brain DNS. DNS records can be segmented into zone scopes. Records can be placed in different scopes. This allows external clients to query the DNS zone and be only able to access a specific number of DNS records that are members of a scope designed for external clients. Internal clients have access to a more comprehensive internal scope.

• Filtering. Allows you to block DNS queries from specific IP addresses, IP address ranges, or FQDNs.

• Forensics. Redirects malicious clients to a sinkhole host rather than to the host they are trying to reach. For example, if clients appear to be attempting a denial-of-service attack, redirect them to a static page rather than the site they are attempting to attack.

• Time of day–based redirection. Allows you to configure a policy where clients are redirected to specific hosts based on the time of day when the query is received.

To accomplish most of these tasks, you create a zone scope, which is a collection of records within a zone. For example, in a split-brain scenario, you’d create a zone scope for the internal records. You’d then use the Add-DNSServerQueryResolutionPolicy cmdlet to create a policy that allowed all queries from the DNS server’s internal network interface to have access to records in the internal zone scope; queries that came through any other interface on the DNS server would only have access to the Default scope, which would only be composed of those records in the zone to which you wanted public clients to have access. Similarly, in the time of day–based redirection scenario, you’d create scopes for each period of time and then create policies that were triggered based on the time of day that would direct clients to records within the particular scope associated with that period of time.

Delegated administration

In some larger environments, you might want to separate administrative privileges, so that the people responsible for managing your organization’s DNS servers don’t have other permissions, such as the ability to create user accounts or reset passwords. By default, members of the Domain Admins group can perform all DNS administration tasks on DNS servers within a domain. Members of the Enterprise Admins group can perform all DNS administration tasks on any DNS server in the forest.

You can use the DNSAdmins domain local group to grant users the ability to view and modify DNS data, as well as view and modify server configurations of DNS servers within a domain. Add users to this group when you want to allow them to perform DNS-administration tasks without giving them additional permissions. You can assign permissions that allow users or security groups to manage a specific DNS server on the Security tab of the server’s Properties dialog box.

You can also configure permissions at the zone level. To do this, assign security principal permissions on the Security tab of the zone’s Properties dialog box. You might do this when you want to allow a specific person to manage host records without assigning them any other permissions. Today, most organizations allow DNS records to be updated dynamically. This means that the only zones where you might need to configure special permissions to allow manual management are ones for which security is especially important, such as those that are accessible to clients on the Internet.

Managing DNS with PowerShell

You can manage almost all aspects of DNS server operations using the DNSServer module of Windows PowerShell. Table 5-1 lists the DNS server PowerShell cmdlets.

DHCP

DHCP is a network service that most administrators barely pay attention to after they’ve configured it. The main concern that most administrators have with DHCP is up until the release of Windows Server 2012, it had been difficult to configure as a highly available service. While DNS became highly available through its ability to be hosted on any domain controller, the problem with making DHCP highly available was ensuring that when multiple DHCP servers were in play, that duplicate addresses were not being assigned to separate clients. Windows Server 2012 introduced highly available DHCP servers, allowing two servers to share a scope, rather than having to split the scope according to the old 80/20 rule.

Scopes

A DHCP scope is a collection of IP address settings that a client uses to determine its IP address configuration. You configure a DHCP scope for every separate IPv4 subnet to which you want the DHCP servers to provide IP address configuration information. When configuring an IPv4 scope, specify the following information:

• Scope Name. The name of the scope. The name should be descriptive enough that you recognize which hosts the scope applies to. For example, Level 2, Old Arts Building.

• IP Address Range. This is the range of IP addresses encompassed by the scope, and it should be a logical subnet.

• IP Address Exclusions. This includes which IP addresses within the IP address range you do not want the DHCP server to lease. For example, you could configure exclusions for several computers that have statically assigned IP addresses.

• Delay. This setting determines how long the DHCP server waits before offering an address. This provides you with a method of DHCP server redundancy, with one DHCP server offering addresses immediately and another only offering addresses after a certain period of time has elapsed.

• Lease Duration. The lease duration determines how long a client has an IP address before the address returns to the lease pool.

• DHCP Options. There are 61 standard options that you can configure. These include settings, such as DNS server address and default gateway address, that apply to leases in the scope.

You can add a DHCP server scope using the Add-DHCPServer4Scope or Add-DHCPServer6Scope PowerShell cmdlets. For example, to create a new scope for the 192.168.10.0/24 network named MelbourneNet, enact the following PowerShell command:

Click here to view code image

Add-DHCPServerv4Scope -Name “MelbourneNet” -StartRange 192.168.10.1 -Endrange 192.168.10.254 -SubnetMask 255.255.255.0

Server and scope options

DHCP options include additional configuration settings, such as the address of a network’s default gateway or the addresses of DNS servers. You can configure DHCP options at two levels: the scope level and the server level. Options configured at the scope level override options configured at the server level.

Common scope options include:

• 003 Router. The address of the default gateway for the subnet.

• 006 DNS Servers. The address of DNS servers that the client should use for name resolution.

• 015 DNS Domain Name. This is the DNS suffix assigned to the client.

• 058 Renewal time. This determines how long after the lease is initially acquired that the client waits before it attempts to renew the lease.

You can configure IPv4 scope options using the Set-DHCPServer4OptionValue cmdlet. For example, to configure the scope with ID 192.168.10.0 on DHCP server dhcp.contoso.com with the value for the DNS server set to 192.168.0.100, issue the following command:

Click here to view code image

Set-DhcpServerv4OptionValue -Computername dhcp.contoso.com -ScopeID 192.168.10.0
-DNSServer 192.168.0.100

Reservations

Reservations allow you to ensure that a particular computer always receives a specific IP address. You can use reservations to allow servers to always have the same address, even when they are configured to retrieve that address through DHCP. If you don’t configure a reservation for a computer, it can be assigned any available address from the pool. Although you can configure DHCP to update DNS to ensure that other hosts can connect using the client’s hostname, it is generally a good idea to ensure that a server retains the same IP address.

There are two ways to configure a DHCP reservation. The simplest way is to locate an existing IP address lease in the DHCP console, right-click it, and then select Add To Reservation. This then ties that specific network adapter address to that IP address. The only drawback of this method is that the reservation is for the assigned IP address, and you cannot customize it.

If you know the network adapter address of the computer for which you want to configure a reservation, you can right-click the Reservations node under the scope that you want to configure the reservation under, and then click New Reservation. In the New Reservation dialog box, enter the Reservation Name, IP Address, and Network Adapter Address, and then click Add to create the reservation. You can also configure a reservation using the Add-DhcpServerv4Reservation cmdlet. For example, to configure a reservation, issue the following command:

Click here to view code image

Add-DhcpServerv4Reservation -ScopeId 192.168.10.0 -IPAddress 192.168.10.8 -ClientId A0-FE-C1-7A-00-E5 -Description "A4 Printer"

DHCP filtering

You can configure DHCP filtering on the Filters tab of the IPv4 Properties dialog box in the DHCP console. DHCP filtering is used in high-security environments to restrict the network adapter addresses that can utilize DHCP. For example, you can have a list of all network adapter addresses in your organization and use the Enable Allow List option to lease only IP addresses to this list of authorized adapters. This method of security is not entirely effective because it is possible for unauthorized people to fake an authorized adapter address as a way of gaining network access. You can add a specific network adapter to the allowed list of MAC addresses using the Add-DHCPServerv4Filter cmdlet. For example, to allow a laptop with the MAC address D1-F2-7C-00-5E-F0 to the authorized list of adapters, issue the command:

Click here to view code image

Add-DhcpServerv4Filter -List Allow -MacAddress D1-F2-7C-00-5E-F0 Description
"Rooslan's Laptop"

Superscopes

A superscope is a collection of individual DHCP scopes. You might create a superscope when you want to bind existing scopes for administrative reasons. For example, imagine that you have a subnet in a building that is close to fully allocated. You can add a second subnet to the building and then bind them into a superscope. The process of binding several separate logical subnets on the same physical network is known as multinetting.

There needs to be at least one existing scope present on the DHCP server before you can create a superscope. After you have created a superscope, you can add new subnets or remove subnets from that scope. It’s also possible to deactivate some subnets within a scope while keeping others active. You might use this technique when migrating clients from one IP address range to another. For example, you could have both the source and destination scopes as part of the same superscope and activate the new scope and deactivate the original scope as necessary when performing the migration. You can create superscopes using the Add-DHCPServerv4Superscope cmdlet. For example, to add the scopes with ID 192.168.10.0 and 192.168.11.0 to a superscope named MelbourneCBD, run the following command:

Click here to view code image

Add-DhcpServerv4Superscope -SuperscopeName "MelbourneCBD" -ScopeId 192.168.10.0, 192.168.11.0

Multicast scopes

A multicast address is an address that allows one-to-many communications on a network. When you use multicast, multiple hosts on a network listen for traffic on a single multicast IP address. Multicast addresses are in the IPv4 range of 224.0.0.0 through to 239.255.255.255. Multicast scopes are collections of multicast addresses. You can configure a Windows Server 2016 DHCP server to host multicast scopes. Multicast scopes are also known as Multicast Address Dynamic Client Allocation Protocol (MADCAP) scopes because applications that require access to multicast addresses support the MADCAP API.

The most common use for multicast addresses using the default Windows Server 2019 roles is for Windows Deployment Services. You can, however, configure the WDS server with its own set of multicast addresses, and you don’t need to configure a special multicast scope in DHCP to support this role.

Split scopes

A split scope is one method of providing fault tolerance for a DHCP scope. The idea behind a split scope is that you host one part of the scope on one DHCP server and a second, smaller part of the scope on a second DHCP server. Usually, this split has 80 percent of the addresses on the first DHCP server and 20 percent of the addresses on the second server. In this scenario, the DHCP server that hosts the 20-percent portion of the address space is usually located on a remote subnet. In the split-scope scenario, you also use a DHCP relay agent configured with a delay so that most addresses are leased from the DHCP server that hosts 80 percent of the address space. Split scopes are most likely to be used in scenarios where your DHCP servers aren’t running on Windows Server 2012 or later operating systems. If you want to provide fault tolerance for scopes hosted on servers running Windows Server 2019, you should instead implement DHCP failover.

Name protection

DHCP name protection is a feature that allows you to ensure that the host names a DHCP server registers with a DNS server are not overwritten in the event that a non-Windows operating system has the same name. DHCP name protection also protects names from being overwritten by hosts that use static addresses that conflict with DHCP-assigned addresses.

For example, imagine that in the tailwindtraders.com domain there is a computer running the Windows 10 operating system that has the name Auckland and receives its IP address information from a Windows Server 2019 DHCP server. The DHCP server registers this name in DNS and creates a record in the contoso.com DNS zone that associates the name Auckland.tailwindtraders.com with the IP address assigned to the computer running Windows 10. A newly installed computer running a distribution of Linux is also assigned the name Auckland. Because name protection has been enabled, this new computer is unable to overwrite the existing record with a new record that associates the name Auckland.tailwindtraders.com with the Linux computer’s IP address. If name protection had not been enabled, it is possible that the record would have been overwritten.

You can enable name protection on a scope by clicking Configure on the DNS tab of the IPv4 or IPv6 Properties dialog box. You can also do this by using the Set-DhcpServerv4DnsSetting or the Set-DhcpServerv6DnsSetting cmdlet. For example, to configure the DHCP server on computer MEL-DC so that name protection is enabled on all IPv4 scopes, issue the following command:

Click here to view code image

Set-DhcpServerv4DnsSetting –Computer MEL-DC –NameProtection $true

DHCP failover

DHCP failover allows you to configure DHCP to be highly available without using split scopes. You have two options when configuring DHCP failover:

• Hot Standby mode. This relationship is a traditional failover relationship. When you configure this relationship, the primary server handles all DHCP traffic unless it becomes unavailable. You can configure DHCP servers to be in multiple separate relationships, so it’s possible that a DHCP server can be the primary server in one relationship and a hot standby server in another relationship. When configuring this relationship, you specify a percentage of the address ranges to be reserved on the standby server. The default value is 5 percent. These 5 percent of addresses are instantly available after the primary server becomes unavailable. The hot standby server takes control of the entire address range when the figure specified by the state switchover interval is reached. The default value for this interval is 60 minutes.

• Load Sharing mode. This is the default mode when you create a DHCP failover relationship. In this mode, both servers provide IP addresses to clients according to the ratio defined by the load balance percentage figure. The default is for each server to share 50 percent of the load. The maximum client lead time figure enables one of the partners to take control of the entire scope in the event that the other partner is not available for the specified time.

Prior to configuring DHCP failover, you need to remove any split scopes between the potential partners. You can also choose a shared secret to authenticate replication traffic, but you don’t have to enter this secret on the partner DHCP server.

Administration

DHCP servers need to be authorized in Active Directory before they start leasing addresses. DHCP servers on Microsoft operating systems must always be authorized before they start working, simply because this reduces the chance that a rogue DHCP server might start leasing IP addresses. Only the following can authorize DHCP servers:

• Members of the Enterprise Admins group

• Members of the Domain Admins group in the forest root domain

• Accounts delegated the ability to add, modify, or delete new objects of the DHCP class type on the NetServices folder in Active Directory

When you deploy the DHCP server role, the following local groups are created. You can use membership of these groups to delegate DHCP server–management permissions to users or groups:

• DHCP Administrators. Members of this group can view or modify any DHCP server settings, including configuring DHCP options, failover, and scopes.

• DHCP Users. Members of this group only have read-only access to the DHCP server. They can view, but not modify, DHCP server settings, including scope information and data.

Managing DHCP with PowerShell

You can manage the DHCP role by using the PowerShell cmdlets listed in Table 5-2.

IPAM

IPAM allows you to centralize the management of DHCP and DNS servers. Rather than managing each server separately, you can use IPAM to manage them from a single console. You can use a single IPAM server to manage up to 150 separate DHCP servers and up to 500 individual DNS servers. Also, it can manage 6,000 separate DHCP scopes and 150 separate DNS zones. You can perform tasks, such as creating address scopes, configuring address reservations, and managing DHCP and DNS options globally, instead of having to perform these tasks on a server-by-server basis. IPAM supports both Active Directory and file-based DNS zones. IPAM can also be integrated into System Center Virtual Machine Manager (VMM) and can keep track of VMM IP address pools.

Deploy IPAM

You can only install the IPAM feature on a computer that is a member of an Active Directory domain. You can have multiple IPAM servers within a single Active Directory forest. You are likely to do this if your organization is geographically dispersed. It’s important to note that IPAM cannot manage a DHCP or DNS server if the role is installed on the same computer that hosts IPAM. For this reason, you should install the IPAM feature on a server that doesn’t host the DNS or DHCP roles. IPAM is also not supported on computers that host the Domain Controller server role. Additionally, if you want to use the IPAM server to manage IPv6 address ranges, you need to ensure that IPv6 is enabled on the computer hosting the IPAM server.

Configure server discovery

Server discovery is the process by which the IPAM server checks with Active Directory to locate Domain Controllers, DNS servers, and DHCP servers. You select which domains to discover on the Configure Server Discovery dialog box. After you’ve completed server discovery, you need to run a special PowerShell cmdlet that creates and provisions group policy objects that allow these servers to be managed by the IPAM server. When you set up the IPAM server, you choose a GPO name prefix. Use this prefix when executing the Invoke-IpamGpoProvisioning Windows PowerShell cmdlet that creates the appropriate GPOS.

If you use the GPO prefix IPAM, the three GPOS are named:

• IPAM_DC_NPS

• IPAM_DHCP

• IPAM_DNS

Until these GPOs apply to the discovered servers, these servers are listed as having an IPAM Access status of blocked. After the GPOs are applied to the discovered servers, the IPAM Access status is set to Unblocked. After the discovered service has an IPAM Access Status set to Unblocked, you can edit the properties of the server and set it to Managed. After you do this, you can use IPAM to manage the selected services on the server.

IPAM supports managing DNS and DHCP servers in forests where a two-way trust relationship has been configured. You perform DHCP and DNS server discovery in a trusted forest on a per-domain basis.

IPAM Administration

You can delegate administrative permissions by adding user accounts to one of five local security groups on the IPAM server. By default, members of the Domain Admins and Enterprise Admins groups can perform all tasks on the IPAM server. The nine following local security groups are present on the IPAM server after you deploy the role, and they allow you to delegate the following permissions:

• DNS Record Administrator. Members of this role can manage DNS resource records.

• IP Address Record Administrator. Members of this role can manage IP addresses, but not address spaces, ranges, subnets, or blocks.

• IPAM Administrators. Members of this role can perform all tasks on the IPAM server, including viewing IP Address tracking information.

• IPAM ASM Administrators. ASM stands for Address Space Administrator. Users added to this group can perform all tasks that can be performed by members of the IPAM Users group, but they are also able to manage the IP address space. They cannot perform monitoring tasks and are unable to perform IP address tracking tasks.

• IPAM DHCP Administrator. Members of this role can manage DHCP servers using IPAM.

• IPAM DHCP Reservations Administrator. Members of this role can manage DHCP reservations using IPAM.

• IPAM DHCP Scope Administrator. Members of this role can manage DHCP scopes.

• IPAM MSM Administrators. MSM stands for Multi-Server-Management. Members of this role can manage all DNS and DHCP servers managed by IPAM.

• IPAM DNS Administrator. Members of this role can manage DHCP servers using IPAM.

Managing the IP address space

The benefit of IPAM is that it allows you to manage all the IP addresses in your organization. IPAM supports the management of IPv4 public and private addresses, whether they are statically or dynamically assigned. IPAM allows you to detect whether there are overlapping IP address ranges defined in DHCP scopes on different servers; determine IP address utilization and whether there are free IP addresses in a specific range; create DHCP reservations centrally without having to configure them on individual DHCP servers; and create DNS records based on IP address lease information.

IPAM separates the IP address space into blocks, ranges, and individual addresses. An IP address block is a large collection of IP addresses that you use to organize the address space that your organization uses at the highest level. An organization might only have one or two address blocks: one for its entire internal network and another smaller block that represents the public IP address space used by the organization. An IP address range is part of an IP address block. An IP address range cannot map to multiple IP address blocks. Generally, an IP address range corresponds to a DHCP scope. An individual IP address maps to a single IP address range. IPAM stores the following information with an IP address:

• Any associated MAC addresses

• How the address is assigned (static or DHCP)

• Assignment date

• Assignment expiration

• Which service manages the IP address

• DNS records associated with the IP address

IP address tracking

One of the most important features of IPAM is its ability to track IP addresses by correlating DHCP leases with user and computer authentication events on managed domain controllers and NPS servers. IP address tracking allows you to figure out which user was associated with a specific IP address at a particular point in time, which can be important when trying to determine the cause of unauthorized activity on the organizational network.

You can search for IP address records using one of the following four parameters:

• Track by IP address. You can track by IPv4 address, but IPAM does not support tracking by IPv6 address.

• Track by client ID. You can track by client ID in IPAM, which allows you to track IP address activity by MAC address.

• Track by host name. You can track by the computer’s name as registered in DNS.

• Track by user name. You can track a user name, but to do this, you must also provide a host name.

Naturally, you can only track data that has been recorded since IPAM has been deployed. So, while it is possible to store several years of data in the Windows Internal Database that IPAM uses, you are limited to only being able to retrieve events recorded after IPAM was configured.

Microsoft estimates that the Windows Internal Database IPAM uses is able to store 3 years of IP address utilization data for an organization that has 100,000 users before data must be purged.

You can use IPAM to locate free subnets and free IP address ranges in your existing IP address scheme. For example, if you need 50 consecutive free IP addresses for a project, you can use the Find-IpamFreeRange PowerShell cmdlet to determine whether such a range is present in your current environment.

Managing IPAM with PowerShell

You can manage IPAM with Windows PowerShell cmdlets that are contained in the IPAMServer module. Table 5-3 outlines the functionality of these cmdlets.