NETWORKING AND COMUNICATIONS II

Secure Windows Server DNS

Windows Server
Learn how to secure Windows Server DNS to help protect your network name resolution
infrastructure and also learn how to implement DNS policies.

Learning objectives
After completing this module, you'll be able to:

- Describe split-horizon DNS and explain how to implement it.

- Create DNS policies.
- Implement DNS policies.
- Describe the options for protecting the DNS server role.
- Implement DNS security.

Prerequisites
To get the best learning experience from this module, you should have knowledge and experience
of:

- AD DS concepts and technologies.

- Windows Server DNS role.
- Core networking technologies.
- Basic security best practices.
- Windows PowerShell basics.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Implement split-horizon DNS

In Windows operating systems, DNS has two major functions: to resolve IP addresses to names (and
vice versa), and to facilitate domain-level communications and authentication for AD DS. The ability
to store SRV records allows domain-member clients to find domain controllers for domain
authentication and security while load balancing access to the various domain controllers by using
DNS round-robin functionality.

However, internet-level untrusted users from outside the firewall should never be able to access
the SRV records and other sensitive AD DS information from the internal DNS servers. That data
must remain separate and inaccessible from outside the firewall. At the same time, DNS records of
servers and services hosting internet level resources, such as web, mail, and proxy servers, must
remain accessible.

This is the problem facing the infrastructure engineers at Contoso. They must determine a
convenient way to manage around this problem.

What is split DNS?

Split DNS, also known as split-horizon DNS, uses the same DNS domain name for both internet and
internal domain-member resources. However, the DNS server role is assigned to separate servers:
one or more servers for the internet, and the other server(s) for the AD DS domain. Deploying DNS
this way requires extra steps to ensure that sensitive information found on the AD DS domain side
is separated from the internet side, and to ensure that only the DNS server deployed on the internet
side, that is, outside the inner firewall, can be accessed by queries from outside the firewall.

Note

Because DNS is such a vital function for AD DS, the DNS server role is usually included with domain
controllers when they're deployed.

You can integrate the DNS role into AD DS so that DNS records are stored as Active Directory objects
and attributes. The DNS zone type in this instance is referred to as Active Directory-integrated.
Active Directory-integrated zones replace DNS zone transfers with AD DS replication and can ensure
secure dynamic updates of client records to the zone. In a domain, using Active Directory-integrated
DNS is a best practice.

With split DNS, internal clients are only configured with the IP addresses of the Active Directory-
integrated DNS servers, which are domain controllers. All client DNS dynamic updates are written
to the domain controllers. All DNS queries from internal clients go only to these DNS servers.

If any name resolution is needed beyond the internal domain, such as for internet web servers, you
must either create those records manually, or else use DNS policies to determine how those queries
are resolved.

Note

You typically deploy internet-facing DNS servers in the perimeter network between the firewalls.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Although the internet-facing DNS servers have the same domain name as the Active Directory-
integrated DNS servers, the internet-facing DNS servers don't store the same data. All records in the
internet-facing DNS server zone are created manually.

Tip

Normally, the internet-facing DNS server zone only contains records for itself and other servers that
are located in the perimeter network and need to be accessed from the internet.

When a query to the internet-facing DNS server comes in from the internet requesting a resolution
on any domain-level resource, such as an SRV record, the internet-facing DNS server rejects the
query because it doesn't have any of the SRV records—these are only stored in the domain Active
Directory-integrated DNS servers. Because it considers itself authoritative for the zone, the internet-
facing DNS server does not make an iterative query to the Active Directory-integrated DNS servers.

Tip

To further enhance security, you can set a firewall rule on the inside firewall, that is, the firewall
between the internal and perimeter networks, to reject all DNS (TCP and UDP port 53) queries from
the perimeter to the internal network, while still allowing DNS replies.

Implement split DNS

Using the same namespace internally and externally simplifies resource access from the perspective
of users, but it also increases management complexity. You should not make internal DNS records
available externally, but some synchronization of records for external resources typically is required.
For example, both your internal and external namespaces might use the name Contoso.com.

Using unique namespaces for the internal and public namespaces provides a clear delineation
between internal and external DNS, and avoids the need to synchronize records between the
namespaces. However, in some cases, having multiple namespaces might lead to user confusion.
For example, you might choose the external namespace of Contoso.com and the internal
namespace of Contoso.local.

Tip

When you implement a unique namespace configuration, you're no longer tied to using registered
domain names.

Using a subdomain of the public namespace for AD DS avoids the need to synchronize records
between the internal and external DNS servers. Because the namespaces are linked, users typically
find this structure easy to understand. For example, if your public namespace is Contoso.com, you
might choose to implement your internal namespace as the subdomain AD, or as AD.Contoso.com.

Considerations for split DNS

Having a matching internal and external DNS namespace can pose certain problems. However, split
DNS can provide a solution to these problems. Split DNS is a configuration in which your domain has
two root-server zones that contain domain-name registration information.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Your internal network hosts are directed to one zone, whereas external hosts are directed to
another for name resolution. For example, in a non-split DNS configuration for the domain
contoso.com, you might have a DNS zone that looks like the example in the following table.

When a client computer on the internet wants to access the SMTP relay by using the published name
of relay.contoso.com, it queries the DNS server that returns the result 131.107.1.201. The client
then establishes a connection over SMTP to that IP address.

However, the client computers on the organization’s intranet also use the published name of
relay.contoso.com. The DNS server returns the same result: a public IP address of 131.107.1.201.
The client now attempts to establish a connection to the returned IP address by using the external
interface of the publishing computer. Depending on the client configuration, this might or might not
be successful.

By configuring two zones for the same domain name―one on each of the two DNS servers―you
can avoid this problem.

The internal zone for Contoso.com would contain the information in the following table.

The external zone for Contoso.com would contain the information in the following table.

Now client computers in the internal and external networks can resolve the name
relay.contoso.com to the appropriate internal or external IP address.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Create DNS policies

The infrastructure team at Contoso posed you a question: "How can Windows Server DNS handle
the fact that we want different results to the same query to be returned to DNS resolvers based on
their location?" They explained that for users in Seattle, the query for the FQDN www.Contoso.com
should return a different IP address than for users in London.

Scenarios for using DNS policies

You can use DNS policies to manipulate how a DNS server manages queries based on different
factors. As an example, you might create a DNS policy to respond to queries asking for the IP address
of a web server to respond with a different IP address based on the closest datacenter to the client.

Note

This differs from other approaches, such as netmask reordering, because the client doesn't have the
same local subnet address as the web server, but the particular web server is closer than others,
from the perspective of the client.

You can create several DNS policies depending on your needs. There are various factors that might
benefit from creating a DNS policy, based on the following scenarios:

- Application high availability. Clients are redirected to the healthiest endpoint for an
application, where "healthiest" is determined by high availability factors in a failover cluster.
- Traffic management. Clients are redirected to the closest datacenter or server location.
- Split DNS. Clients receive a response based on whether they are internal or external, and
the DNS records are split into different zone scopes.
- Filtering. DNS queries are blocked if they are from a list of malicious IP addresses or FQDNs.
- Forensics. Malicious DNS clients are redirected to a sink hole instead of the computer they
are trying to reach.
- Time-of-day based redirection. Clients are redirected to datacenters based on the time of
the day.

DNS policy objects

To use the previously mentioned scenarios to create policies, you must identify groups of records in
a zone, groups of clients on a network, or other elements. You can identify the elements by the DNS
policy objects described in the following table.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Implement DNS policies

You create DNS policies based on level and type. You can use query-resolution policies to define
how to manage client name resolution queries, and use zone-transfer policies to define zone
transfers.

Tip

You can apply both policy types at the server or zone level.

You can create multiple query resolution policies at the same level if they have a different value for
the processing order. Recursion policies are a special type of server-level policy. They control how a
DNS server performs query recursion, if at all. Recursion policies only apply when query processing
reaches the recursion path. You can choose a value of DENY or IGNORE for recursion for a given set
of queries. Otherwise, you can choose a set of forwarders for a set of queries.

Create and manage DNS policies

The high-level steps to resolve a host record differently for users from a specific IP address range
are:

- Create a DNS server client subnet for the IP address range.

- Create a DNS server zone scope for the zone containing the host record.
- Add a host record to the zone that is specific to the zone scope.
- Add a DNS server query resolution policy that allows the DNS server client subnet to query
the zone scope for the zone.

The following is an example of the steps used to configure the DNS policy by using Windows
PowerShell:

# Create the required subnets

Add-DnsServerClientSubnet -Name "LondonSubnet" -IPv4Subnet "172.16.18.0/24"

Add-DnsServerClientSubnet -Name "SeattleSubnet" -IPv4Subnet "172.16.10.0/24"

# Create the DNS server zone scopes

Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "LondonZoneScope"

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "SeattleZoneScope"

# Add the required host records

Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address

"172.16.10.41" -ZoneScope "SeattleZoneScope"

Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address

"172.16.18.17" -ZoneScope "LondonZoneScope"

# Create the DNS server query resolution policies

Add-DnsServerQueryResolutionPolicy -Name "LondonPolicy" -Action ALLOW -ClientSubnet

"eq,LondonSubnet" -ZoneScope "LondonZoneScope,1" -ZoneName "Contoso.com"

Add-DnsServerQueryResolutionPolicy -Name "SeattlePolicy" -Action ALLOW -ClientSubnet

"eq,SeattleSubnet" -ZoneScope "SeattleZoneScope,1" -ZoneName Contoso.com

Demonstration
The following video demonstrates how to implement DNS policies by using Windows PowerShell.
The main steps in the process are:

1.-Open Server Manager and open the DNS console.

2.-Create a new alias record for an existing server in the Contoso.com zone.

3.-Switch to a client computer and verify what IP address is returned when the alias is tested with
NSLookup.

4.-On a server, open an elevated Windows PowerShell window.

5.-Run the $s = New-PSSession –ComputerName <target server> and then the Enter-PSSession $s
command to connect to the <target server> with PowerShell remoting.

6.-Create the required subnets by running the Add-DnsServerClientSubnet cmdlet.

7.-Create the DNS server zone scopes by running the Add-DnsServerZoneScope cmdlet.

8.-Add the required host records by running the Add-DnsServerResourceRecord cmdlet.

9.-Create the DNS server query resolution policies by running the Add-
DnsServerQueryResolutionPolicy cmdlet.

10.-Switch back to the client, purge the resolver cache, and then test name resolution for the
www.Contoso.comrecord.

VIDEO:

https://www.microsoft.com/en-us/videoplayer/embed/RWxDP5?postJsllMsg=true

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Secure Windows Server DNS

Because DNS is a critical network service, IT infrastructure staff at Contoso are concerned about
securing the DNS service. Windows Server DNS provides several options for protecting the DNS
server role, including:

- DNS cache locking.

- DNS socket pool.
- DNS-Based Authentication of Named Entities (DANE).
- Response rate limiting (RRL).
- Unknown record support.
- Domain Name System Security Extensions (DNSSEC).

DNS cache locking

Cache locking is a Windows Server security feature that you can use to control when information in
the DNS cache can be overwritten. When a recursive DNS server responds to a query, the server
caches the results so that it can respond quickly if it receives another query requesting the same
information.

The period of time that the DNS server keeps information in its cache is determined by a resource
record’s TTL value. Information in the cache can be overwritten before the TTL expires if updated
information about that resource record is received. If a malicious user successfully overwrites
information in the cache, then the malicious user might be able to redirect your network traffic to
a malicious site.

When you use cache locking, the DNS server prohibits cached records from being overwritten for
the duration of the TTL value.

You configure cache locking as a percentage value. For example, if the cache locking value is set to
50, the DNS server will not overwrite a cached entry for half of the duration of the TTL. By default,
the cache locking percentage value is 100. This means that cached entries will not be overwritten
for the entire duration of the TTL.

You can configure cache locking by using the running dnscmd /Config /CacheLockingPercent
<percent> at an elevated command prompt.

Tip

You can also use the Windows PowerShell Set-DnsServerCache –LockingPercent cmdlet

DNS socket pool

The DNS socket pool enables a DNS server to use source port randomization when issuing DNS
queries. When the DNS service starts, the server chooses a source port from a pool of sockets that
are available for issuing queries. Instead of using a predicable source port, the DNS server uses a
random port number that it selects from the DNS socket pool.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

The DNS socket pool makes cache-tampering attacks more difficult because a malicious user must
correctly guess both the source port of a DNS query and a random transaction ID to successfully run
the attack.

Note

The DNS socket pool is enabled by default in Windows Server.

The larger the value, between 0 and 10,000, the greater the protection you will have against DNS
spoofing attacks.

Note

The default size of the DNS socket pool is 2,500.

You can configure the DNS socket pool size by running dnscmd /Config /SocketPoolSize <value> from
an elevated command prompt.

DANE
The DANE protocol is a feature available in the Windows Server DNS Server role. DANE allows you
to use Transport Layer Security Authentication (TLSA) records to provide information to DNS clients
that state the Certification Authority (CA) from which clients should expect a certificate for your
domain name. This prevents man-in-the-middle attacks, where someone might corrupt the DNS
cache to point to their website, and provide a certificate they issued from a different CA.

For example, suppose that your organization hosts a secure website using HTTPS at
www.Contoso.com by using a certificate from a well-known authority named CANorth. Someone
might still be able to get a certificate for www.Contoso.com from a relatively unknown, different
certificate authority named CAEast.

At that point, an entity hosting non-legitimate www.Contoso.com website might be able to corrupt
the DNS cache of a client or server to point www.Contoso.com over on its fake site. The end user is
presented a certificate from CAEast and might unknowingly acknowledge it and connect to the non-
legitimate site.

With DANE, the client makes a request to the DNS server for Contoso.com asking for the TLSA record
and discovers that the certificate for www.Contoso.com was issued by CANorth. If offered a
certificate from another CA, it terminates the connection.

RRL
RRL is an enhancement of the DNS protocol that can help mitigate DNS amplification attacks. An
amplification attack is a type of Distributed Denial of Service (DDoS) where attackers use publicly
accessible open DNS servers to flood a target system with DNS response traffic. The main method
involves an attacker sending a DNS name lookup request to an open DNS server with the source
address spoofed to be the target’s address.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

When the DNS server sends the DNS record response, it is sent to the target instead. You can avoid
this by enabling RRL on your DNS servers. RRL constantly monitors client DNS queries and if a lot of
queries originate from a single source asking for similar names within a specified short period, RRL
flags them as potentially malicious. RRL can simply ignore the queries or reply to them in truncation,
which forces the client to negotiate a TCP three-way handshake for confirmation.

Unknown record support

Records that are not explicitly supported by the Windows DNS server can be added in a Windows
Server DNS zone by using the unknown record functionality. This means that you can add the
unsupported record types to the Windows DNS server zones in a binary format. A Windows Server
DNS server will not do any record-specific processing for the unknown records, but will send the
resolution back in responses if queries are received for that record.

Implement DNSSEC
Intercepting and tampering with an organization’s DNS query response is a common attack method.
If malicious hackers can alter responses from Contoso's DNS servers, or send spoofed responses to
point client computers to their own servers, they can gain access to Contoso's sensitive information.
Any service that relies on DNS for the initial connection—such as e-commerce web servers and email
servers—is vulnerable.

What is DNSSEC?
DNSSEC protects clients that are making DNS queries from accepting false DNS responses. When a
DNS server that is hosting a digitally signed zone receives a query, the server returns the digital
signatures along with the requested records. A resolver or another server can obtain the public key
of the public/private key pair from a trust anchor, and then validate that the responses are authentic
and haven't been tampered with. To do this, you must configure the resolver or server with a trust
anchor for either the signed zone or a parent of the signed zone.

The high-level steps for deploying DNSSEC are:

1.- Sign the DNS zone.

2.- Configure the trust anchor distribution.

3.- Configure the name resolution policy table (NRPT) on client computers.

Resource records
DNS response validation is achieved by associating a private/public key pair (as generated by the
administrator) with a DNS zone, and then defining additional DNS resource records to sign and
publish keys.

Resource records distribute the public key, while the private key remains on the server. When the
client requests validation, DNSSEC adds data to the response that enables the client to authenticate
the response.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

The following table describes the additional resource records used with DNSSEC.

Sign the DNS zone

Windows Server includes the Zone Signing Wizard in DNS manager to simplify the configuration and
signing process, and to enable online signing. The wizard allows you to choose the zone-signing
parameters. If you choose to configure the zone-signing settings rather than use parameters from
an existing zone or use default values, you can use the wizard to configure settings such as the
following:

- Key Signing Key options.

- Zone Signing Key options.
- Trust anchor distribution options.
- Signing and polling parameters.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Trust anchors distribution

A trust anchor is an authoritative entity that is represented by a public key. The TrustAnchors zone
stores preconfigured public keys that are associated with a specific zone. In DNS, the trust anchor is
the DNSKEY or DS resource record. Client computers use these records to build trust chains. You
must configure a trust anchor from the zone on every domain DNS server to validate responses from
that signed zone. All DNS servers hosting a zone need to have the same DNSKEY key records to
provide the information required to validate the RRSIG records.

Name Resolution Policy Table

The NRPT contains rules that control the DNS client behavior for sending DNS queries and processing
the responses from those queries. For example, a DNSSEC rule prompts the client computer to check
for validation of the response for a particular DNS domain suffix. As a best practice, Group Policy is
the preferred method of configuring the NRPT. If no NRPT is present, the client computer accepts
responses without validating them.

Review or change settings

After you've completed zone signing, you can review or change the settings by using this procedure:

1.- In DNS Manager, right-click or activate the context menu for zone, select DNSSEC, and then select
Properties.

2.- Use the DNSSEC properties for zonename zone dialog box to review and edit the settings.

3.- Select OK when done.

MWCO-Technet
NETWORKING AND COMUNICATIONS II

Demonstration
The following video demonstrates how to configure DNSSEC in Windows Server DNS using the DNS
console. The main steps in the process are:

1.-Open Server Manager, and then open DNS Manager.

2.-Locate the appropriate forward lookup zone, right-click the zone or activate its context menu,
select DNSSEC, and then select Sign the Zone.

3.-Use the Zone Signing Wizard to complete the process.

4.-In DNS Manager, expand Trust Points. Ensure that the DNSKEY resource records exist and that
their status is valid.

5.-Open Group Policy Management.

6.-Open a suitable GPO for editing.

7.-In the Group Policy Management Editor, under Computer Configuration, navigate to Policies >
Windows Settings > Name Resolution Policy.

8.-In the Create Rules section, in the Suffix text box, enter the appropriate domain suffix.

9.-Select Enable DNSSEC in this rule, select the Require DNS clients to check that the name and
address data has been validated by the DNS server, and then select Create.

VIDEO

https://www.microsoft.com/en-us/videoplayer/embed/RWxT9k?postJsllMsg=true

MWCO-Technet