What Are Domain Name System Security

Extensions DNSSEC? – Dante Leo

Domain name system security extensions (DNSSEC) are a set of protocols that add a
layer of security to the domain name system (DNS) lookup and exchange processes,
which have become integral in accessing websites through the Internet. While DNSSEC
cannot protect how data is distributed or who can access it, the extensions can
authenticate the origin of data sent from a DNS server, verify the integrity of data and
authenticate nonexistent DNS data.

Understanding DNS
Understanding DNSSEC first requires a basic knowledge of how website addresses work.
The actual Internet protocol (IP) addresses used by websites are a series of numbers
separated by dots. Although this address system is very efficient for computers to read
and process, it is extremely difficult for people to remember. To solve this problem,
domain names are attached to the numeric IP addresses. What has come to be known as
website addresses are actually domain names.

Domain name information is stored and accessed on special servers, known as domain
name servers, that convert domain names into IP addresses and vice versa. The top level
of the DNS resides in the root zone where all IP addresses and domain names are kept in
databases and sorted by top-level domain name, such as .com, .net and .org.

DNSSEC Development
When DNS was first implemented, it did not include any security, and soon after being
put into use, several vulnerabilities were discovered. As a result, a security system was
developed in the form of extensions that could be added to existing DNS protocols. This
system was later vetted, modified and approved as a standard by the Internet Engineering
Task Force (IETF).

After several test deployments, beginning in 2007, DNSSEC was officially deployed on
the root level in 2010 for addresses using the .org top-level domain. In late 2010 and
2011, .com, .net and .edu top-level domains were updated for DNSSEC, and
implementation continues for country-specific top-level domains. By November 2011,
over 25 percent of all top-level domains had been included.

How DNSSEC Works

The original purpose of DNSSEC was to protect Internet clients from counterfeit DNS
data by verifying digital signatures embedded in the data. If the digital signatures in the
data match those that are stored in the master DNS servers, then the data is allowed to
continue to the client computer making the request.
DNSSEC uses a system of public keys and digital signatures to verify data. These public
keys can also be used by security systems that encrypt data as it is sent through the
Internet and then decrypt it when it is received by the intended recipient. However,
DNSSEC cannot protect the privacy or confidentiality of data because it does not include
encryption algorithms. It only carries the keys required to authenticate DNS data as
genuine or genuinely not available.

The implementation of DNSSEC required several new types of records to be created for
DNS. These record types are as follows:

 DS
 DNSKEY
 NSEC
 RRSIG

The RRSIG record is the digital signature, and it stores the key information used for
validation of the accompanying data. The key contained in the RRSIG record is matched
against the public key in the DNSKEY record. The NSEC family of records, including
NSEC, NSEC3 and NSEC3PARAM, is then used as an additional reference to thwart
DNS spoofing attempts. The DS record is used to verify keys for subdomains.

The specific process used for a DNSSEC lookup varies by the type of server used to
make or send the query. Recursive name servers, often operated by Internet service
providers (ISPs), use a unique process for DNSSEC validation. Servers running
Microsoft Windows use what are known as stub resolvers, which also require a specific
process.

No matter which process is used, the verification of DNSSEC keys requires starting
points called trust anchors. Trust anchors are included in operating systems or other
trusted software. After a key is verified through the trust anchor, it must also be verified
by the authoritative name server through the authentication chain, which consists of a
series of DS and DNSKEY records.

Issues with DNSSEC

While DNSSEC dramatically increases Internet security, recent discoveries have shown
that it may cause a new vulnerability, which is known as zone enumeration. DNS zone
data has traditionally been kept private because it includes network information for
specific websites and servers. Anyone who can obtain this information would have a
much simpler time preparing and implementing an Internet attack.

The original DNSSEC required that DNS servers reveal all DNS zone data so that a
definitive report could be generated when a domain name is not found. However, newer
versions of DNSSEC use one or more workarounds, which often make use of the NSEC3
records.
DNS Socket Pool
Applies To: Windows Server 2008 R2 - 2016

Source port randomization is a method that can be used to protect against DNS cache
poisoning attacks. With source port randomization, the DNS server will randomly pick a
source port from a pool of available sockets that it opens when the service starts. Instead
of using a predicable source port when issuing queries, the DNS server uses a random
port number selected from this pool, known as the socket pool. The socket pool makes
cache poisoning attacks more difficult because an attacker must correctly guess the
source port of a DNS query in addition to a random transaction ID to successfully
complete the attack.

Note

Ports numbers that are reserved for the socket pool depend on the operating system. For more
information about the range of port numbers reserved, see Microsoft Knowledge Base article
956188: You experience issues with UDP-dependent network services after you install DNS
Server service security update 953230 (MS08-037)
(http://go.microsoft.com/fwlink/?LinkId=165771).

Socket pool will increase memory utilization by the DNS server service. The amount of memory
used is dependent on the value of SocketPoolSize, the CPU number, and whether or not both
IPv4 and IPv6 addressing is enabled. For more information, see Memory allocation for the
socket pool.

The default size of the socket pool is 2500. When you configure the socket pool, you can
choose a size value from 0 to 10000. The larger the value, the greater protection you will
have against DNS spoofing attacks. If you configure a socket pool size of zero, the DNS
server will use a single socket for remote DNS queries. If the DNS server is running
Windows Server® 2008 R2, you can also configure a socket pool exclusion list.

Membership in the Administrators group, or equivalent, is the minimum required to

complete this procedure. Review details about using the appropriate accounts and group
memberships at Local and Domain Default Groups
(http://go.microsoft.com/fwlink/?LinkId=83477).
Configuring the socket pool

Tip

The command line utility DnsCmd.exe is the recommended method for configuring the socket
pool.

 Using a command line

 Using the Windows interface

To configure the socket pool size using a command line

1. Open an elevated command prompt.

2. Type the following command, and then press ENTER:
3. dnscmd /Config /SocketPoolSize <value>
4. Restart the DNS Server service.

To view the current value of the SocketPoolSize registry key, type the following
command and press ENTER:

Dnscmd /Info /SocketPoolSize

To configure the socket pool exclusion list using a command line
Important
To configure the socket pool exclusion list, the DNS server must be running Windows
Server 2008 R2 and later.

1. Open an elevated command prompt.

2. Type the following command, and then press ENTER:
3. dnscmd /Config /SocketPoolExcludedPortRanges <excluded port
ranges>
4. Restart the DNS Server service.

Parameter Description

dnscmd The command-line tool for managing DNS servers.

Required. Allows the user to change a value in the
/Config
Windows Registry.
/SocketPoolSize Required. Specifies the SocketPoolSize registry key.
Optional. Specifies the size of the socket pool in
<socket pool size> decimal format. If no value is entered, the socket pool
size is reset to 0.
 Optional. Specifies the
/SocketPoolExcludedPortRanges
SocketPoolExcludedPortRanges registry key.
Optional. Specifies one or more numeric port ranges
for which listen sockets will not be opened by the DNS
server. Range values must start with a number smaller
or equal to the ending value, and are inclusive. To
specify a single port, enter the same starting and
ending port number. Enter multiple port ranges
<excluded port ranges>
separated by a space. For example: 4000-5000 34000-
34000. Port numbers must be positive integers less
than or equal to 65535. You must supply all port
ranges in the exclusion list each time you run the
command. If no value is entered, the list will be
cleared.

Tip

Use the /Info command to view the current value of a registry key, for example: Dnscmd /Info
/SocketPoolSize and Dnscmd /Info /SocketPoolExcludedPortRanges.

To configure the socket pool size using the Windows interface

1. Click Start, click Run, type regedit.exe, and then press ENTER.
2. In Registry Editor, open
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Par
ameters.
3. If the SocketPoolSize registry key is not present, right-click Parameters, click
New, click DWORD (32-bit) Value, and then type SocketPoolSize for the name
of the new registry key.
4. Double-click the SocketPoolSize registry key.
5. Under Base, choose Decimal, under Value data type a value from 0 to 10000 for
the size of the socket pool, and then click OK.
6. Close Registry Editor.
7. Restart the DNS Server service.

To configure the socket pool exclusion list using the Windows interface

1. To configure the socket pool exclusion list, the DNS server must be running
Windows Server 2008 R2.
2. Click Start, click Run, type regedit.exe, and then press ENTER.
3. In Registry Editor, open
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Par
ameters.
 4. If the SocketPoolExcludedPortRanges registry key is not present, right-click
Parameters, click New, click Multi-String Value, and then type
SocketPoolExcludedPortRanges for the name of the new registry key.
5. Double-click the SocketPoolExcludedPortRanges registry key.
6. Under Value data, type the list of port ranges using a separate line for each range,
and then click OK. Range values must start with a number smaller or equal to the
ending value, and are inclusive. Port numbers must be positive integers less than
or equal to 65535. To specify a single port, enter the same starting and ending
port number. For example: 34000-34000.
7. Close Registry Editor.
8. Restart the DNS Server service.

Memory allocation for the socket pool

By default, the DNS server opens a pool of 5000 UDP sockets: 2500 for 1Pv4 and 2500
for IPv6. On Windows Server 2008 R2, approximately 2.5 KB of memory is allocated for
each socket, plus 7.2 KB of memory per receive buffer. The number of receive buffers is
two on a single or dual processor server, and equal to the number of CPUs if more than
two are present. This means that the DNS server service uses approximately 2.5 x 5000 =
18 MB of additional memory for sockets plus 2 x 5000 x 7.2 = 72 MB for buffers or a
total of 90 MB of additional memory on a single or dual processor server when socket
pool is used with default settings. Memory use is half the amount if only IPv4 is enabled.
To calculate the number of CPUs, open Task Manager and click the Performance tab. A
CPU Usage History graph is displayed for each CPU.

DNS Cache Locking

Cache locking is a new security feature available with Windows Server® 2008 R2 - 2016
that allows you to control whether or not information in the DNS cache can be
overwritten.

What are the major changes?

Cache locking is a new feature available if your DNS server is running Windows
Server 2008 R2. When you enable cache locking, the DNS server will not allow cached
records to be overwritten for the duration of the time to live (TTL) value. Cache locking
provides for enhanced security against cache poisoning attacks. You can also customize
the settings used for cache locking.

What does cache locking do?

When a recursive DNS server responds to a query, it will cache the results obtained so
that it can respond quickly if it receives another query requesting the same information.
The period of time the DNS server will keep information in its cache is determined by the
Time to Live (TTL) value for a resource record. Until the TTL period expires,
information in the cache might be overwritten if updated information about that resource
record is received. If an attacker successfully overwrites information in the cache, they
might be able to redirect traffic on your network to a malicious site.

Who will be interested in this feature?

This feature will be of interest to IT professionals who manage Active Directory®
Domain Services (AD DS) and DNS, as well as to security administrators.

Are there any special considerations?

Cache locking is configured as a percent value. For example, if the cache locking value is
set to 50, then the DNS server will not overwrite a cached entry for half of the duration of
the TTL. By default, the cache locking percent value is 100. This means that cached
entries will not be overwritten for the entire duration of the TTL. The cache locking value
is stored in the CacheLockingPercent registry key. If the registry key is not present, then
the DNS server will use the default cache locking value of 100.

What settings have been added or changed?

The following registry keys can be used to configure the cache locking. However, the
recommended method for configuring cache locking settings is with the dnscmd.exe
command line tool. For more information about configuring the Socket Pool, see
Configure Cache Locking.

Registry settings

Defa Possi
ult ble
Setting name Location
valu value
e s

CacheLocking HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ 0 to
100
Percent services\DNS\Parameters 100

Tip

To apply changes to settings for cache locking, you must restart the DNS service.

Which editions include this feature?

This feature is available in all editions.
Deploying a GlobalNames Zone
Applies To: Windows Server 2008 R2 - 2016

A common requirement in computer networks is the ability to resolve simple, single-label

names. The use of single-label names makes it possible for a computer to access hosts
such as file and Web servers by using short, easy-to-remember names instead of the fully
qualified domain names (FQDNs) that form the default naming convention for Domain
Name System (DNS). To make the use of single-label names possible, many networks
deploy Windows Internet Name Service (WINS) technology and servers in their
environment. As a name resolution protocol, WINS is an alternative to DNS. It is an
older service that uses NetBIOS over TCP/IP (NetBT). WINS and NetBT do not support
Internet Protocol version 6 (IPv6) protocols; therefore, they are being phased out in many
networks.

To help network administrators migrate to DNS for all name resolution, the DNS Server
role in Windows Server 2008 supports a specially named zone, called GlobalNames. By
deploying a zone with this name, you can have the static, global records with single-label
names, without relying on WINS. These single-label names typically refer to records for
important, well-known and widely-used servers—servers that are already assigned static
IP addresses and that are currently managed by IT-administrators using WINS.

The GlobalNames zone is not designed to be a complete replacement for WINS. You
should not use the GlobalNames zone to support the name resolution of records that are
dynamically registered in WINS, records which typically are not managed by IT
administrators. Support for these dynamically registered records is not scalable,
especially for larger customers with multiple domains or multiple forests.

Deciding if you need to deploy a GlobalNames zone

Consider deploying a GlobalNames zone if:

 You are retiring WINS or you are planning to deploy only IPv6 in your environment, so
that all name resolution will depend on DNS.

 Your need for single-label name resolution is limited to important servers or Web sites
that can be statically registered in DNS. (Typically, these names are also configured
statically and globally in the WINS database.) Host names cannot be registered in the
GlobalNames zone by dynamic updates.

 You cannot rely on the suffix search lists on client computers to provide single-label
name resolution; for example, because the number of target domains is too great or the
domains cannot be centrally managed to guarantee that host names will be unique. For
more information about using suffix search lists, see Understanding DNS Client Settings.

 All the DNS servers that are authoritative for your zones are servers running Windows
Server 2008. To resolve names that are registered in the GlobalNames zone, all DNS
 servers that are authoritative for a zone and that serve client query requests must be
running Windows Server 2008 and they must either be configured with a local copy of
the GlobalNames zone or they must be able to contact remote DNS servers that host the
GlobalNames zone.

We also recommend that the GlobalNames zone be integrated with Active Directory
Domain Services (AD DS). This integration with AD DS ensures easier management and
future scalability.

Deploying a GlobalNames zone

The specific steps for deploying a GlobalNames zone can vary somewhat, depending on
the AD DS topology of your network.

Step 1: Create the GlobalNames zone

The first step in deploying a GlobalNames zone is to create the zone on a DNS server that
is a domain controller running Windows Server 2008. The GlobalNames zone is not a
special zone type; rather, it is simply an AD DS-integrated forward lookup zone that is
called GlobalNames. For information about creating a primary forward lookup zone, see
Add a Forward Lookup Zone.

Step 2: Enable GlobalNames zone support

The GlobalNames zone is not available to provide name resolution until GlobalNames
zone support is explicitly enabled by using the following command on every authoritative
DNS server in the forest:

dnscmd <ServerName> /config /enableglobalnamessupport 1

where ServerName is the DNS name or IP address of the DNS server that hosts the
GlobalNames zone. To specify the local computer, replace ServerName with a period (.),
for example, dnscmd . /config /enableglobalnamessupport 1.

Step 3: Replicate the GlobalNames zone

To make the GlobalNames zone available to all DNS servers and clients in a forest,
replicate the zone to all domain controllers in the forest, that is, add the GlobalNames
zone to the forest-wide DNS application partition. For more information, see Change the
Zone Replication Scope.

If you want to limit the servers that will be authoritative for the GlobalNames zone, you
can create a custom DNS application partition for replicating the GlobalNames zone. For
more information, see Understanding DNS Zone Replication in Active Directory Domain
Services.
Step 4: Populate the GlobalNames zone

For each server that you want to be able to provide single-label name resolution for, add
an alias (CNAME) resource record to the GlobalNames zone. For more information, see
Add an Alias (CNAME) Resource Record to a Zone.

Step 5: Publish the location of the GlobalNames zone in other forests

If you want DNS clients in other forests to use the GlobalNames zone for resolving
names, add service location (SRV) resource records to the forest-wide DNS application
partition, using the service name _globalnames._msdcs and specifying the FQDN of the
DNS server that hosts the GlobalNames zone. For more information, see Add a Resource
Record to a Zone and Service Location (SRV) Resource Record Dialog Box.

In addition, you must run the dnscmdServerName/config /enableglobalnamessupport 1

command on every authoritative DNS server in the forests that do not host the
GlobalNames zone.

Additional considerations

 By default, an authoritative DNS server uses local zone data first to respond to a query,
before trying the GlobalNames zone to see if the name exists. If there is no relevant
data in the GlobalNames zone and resolution using suffixes fails, resolution fails over to
WINS. Querying local zone data first is a performance optimization.

 Dynamic updates that are sent to an authoritative DNS server are checked against
GlobalNames zone data first before being checked against local zone data. This ensures
that GlobalNames zone names remain unique.

 No software updates are required for clients to enable them to resolve the names that
are configured in the GlobalNames zone. Primary DNS suffix, connection-specific
suffixes, and the DNS suffix search list continue to work as usual.

 DNS client registration is not affected unless a computer tries to register a name that is
already configured in the GlobalNames zone.