The Domain Name System is an essential component of the functionality of most Internet services. It provides a distributed solution for services such as resolving hostnames to IP addresses and vice versa. DNS was designed around the early 1980s without any security consideration. This was mainly because at that time networks were quite small. All the hosts in the network were known beforehand and trustworthy.
There was no need for authenticity.
But as the network grew and Internet was born DNS remained unchanged. This resulted in lots of threats that target DNS due to the lack of authenticity and integrity checking of data held within the DNS. In 1994, the Internet Engineering Task Force (IETF) started working to add security extensions known as Domain Name System Security Extensions (DNSSEC) to the existing DNS protocol.
However, you can protect the DNS Server by including Several options such as DNS cache locking, DNS socket pool, and DNSSEC.
Table of Contents
DNS Cache Locking
Whenever a DNS server does not have the answer to a query within its cache, the DNS server can pass the query onto another DNS server on behalf of the client. If the server passes the query onto another DNS server that has incorrect information whether placed there intentionally or unintentionally, then cache poisoning can occur. DNS cache poisoning is a form of computer security hacking in which corrupt Domain Name System data is introduced into the DNS resolver’s cache, causing the name server to return an incorrect IP address.
For example, suppose there is a name server, known as dns.eihtech.com, servicing a network of computers as shown in figure 3.1. An application on a client system, client1, makes a DNS query that is sent to dns.eihtech.com. Then dns.eihtech.com examines its cache to see if it already has the answer to the query. Unfortunately, dns.eihtech.com is not authoritative for DNS name in the query nor does it have the answer to the query in its cache. It must send the query to another server, called unknowndns.external.org. The information on unknowndns.external.org happens to be incorrect, most commonly due to misconfiguration and the response sent back to dns.eihtech.com contains misleading information. Since dns.eihtech.com is caching responses, it caches
this misleading information and sends the response back to the client1. As long as this information exists in the cache of dns.eihtech.com, all clients, not just client1, are now susceptible to receiving this misleading information make the network and network computers vulnerable.
DNS Cache locking is a Windows Server Security feature that helps to mitigate cache poisoning. It lacks the entries in the cache. So, if someone tries to poison the cache with a replacement record, the DNS server will ignore it and thus maintain the integrity of the cached content. DNS Cache locking adds an additional layer f protection onto those entries that exist in the cache by preventing them from being overwritten for a percentage of time of the entire TimeToLive value. By default, the server Cache Locking Percent is set to 100%. For checking the cache locking percent you can be using the dnscmd command.
dnscmd /info /cachelockingpercent
To use DNS Cache Locking, you set a percentage of the TTL of records that the cached content is locked for. For example, a setting of 75 means that cached records can’t be overwritten until 75 percent of their TTL has passed. The default value is 100, which means records can’t be updated until the TTL has expired. You can configure cache locking by using the dnscmd command
dnscmd /Config /CacheLockingPercent <percent>
After executing it restart the DNS server service to apply the changes.
Also, you can configure the cache locking by using PowerShell cmdlet.
Set-DnsServerCache -LockingPercent <value>
DNS socket pool
DNS socket pool functions as a security feature that allows a DNS server to use source port randomization when it is performing queries. So instead of sending out a query on a specific source port, it will randomize which source port is being used and this protects against cache poisoning attacks. It is enabled by default on Windows Server 2016.
When a DNS server or a DNS client is making a request to a DNS server, that server or client makes the request typically over an existing well-known port. That port is most commonly TCP/53 and UDP/53.
If the DNS Server i.e. SRV1 is attempting to make a request on DNS Server i.e. SRV2, it is going to send that request on TCP/53. Now on SRV1, the source port could’ve been the same port as SRV2 and because of that, it became far too easy for some attacker to actually inject the wrong answer into that port.
Now, what DNS socket pooling does, tells the server to go ahead and randomize the source port from where the actual request is coming. So, it may be 2 or 1000 possible ports from there the actual request could come. When you have that many possible ports that the request could come from, it makes it much more difficult for the attacker to actually send the wrong information back into the listening port. You have to know the port number and more information about the exact transaction that’s occurring. DNS socket pool is enabled by default i.e. 2500 socket pool size. Increasing the size of the socket pool allows the DNS server to increase the source port randomization. It’s also possible to decrease the size of the socket pool to 0, in which case the DNS server uses a single socket for remote DNS query operations. You can modify to DNS Socket Pool size using the dnscmd.exe command-line utility. For example, to set the socket pool size of 3000, issue the following command from an elevated command prompt on the computer that hosts the DNS server role:
dnscmd /config /socketpoolsize 3000
DANE
The DNS-based Authentication of Named Entities (DANE) protocol is a new feature available in the Windows Server 2016 DNS Server role. DANE support is specified in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 6394 and 6698. DANE allows you to use TLSA (Transport Layer Security Authentication) records to provide information to DNS clients that state what Certification Authority (CA) they should expect a certificate from for your domain name. This prevents man-in0the-middle attacks where someone might corrupt the DNS cache to point to their website, and provide a certificate they issue from a different CA.
For example, suppose that your organization hosts a secure website using HTTPS at www.eihtech.com by using a certificate from a well-known authority named IINNorth. Someone might still be able to get a certificate for www.eihtech,.com from a relatively unknown, different certificate authority name INEast. At that point, an entity hosting the fake www.eihtech.com website might be able to corrupt the DNS cache of a client r server to point www.eihtech.com over to its fake site. The end-user has presented a certificate from INEast, and might unknowingly acknowledge it and connect to the fake site. With DANE, the client makes a request to the DNS server for eihtech.com asking for the TLA record and discovers that the certificate for www.eihtech.com was issued by INNorth. If offered a certificate from another CA, the connection I terminated.
DNS Security Extensions (DNSSEC)
DNS Security Extension (DNSSEC) isn’t a proprietary Microsoft technology but rather an Internet-standard extension to DNS defined in RFCs 4033, 4034, and 4035 that Microsoft has implemented as part of the Server 2016 DNS role.
DNSSEC assure the integrity of the DNS infrastructure through technologies that verify the authenticity of received data, including authenticated denial-of-existence responses. Assurance is enabled through public-key cryptography, which enables the use of digital signatures on all DNS responses. A successful digital signature validation means that the received is genuine and can be trusted. The digital signature is generated using the DNS zone’s private key which is kept secret and the content of the record and can be validated with the public key. If a packet is generated from a malicious source, its digital signature will fail; if a packet has been modified, the signature will no longer match the content.
DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record types were created or adapted to use with DNSSEC.
RPSIG (resource record signature): Contains the DNSSEC signature for a recordset. DNS resolvers verify the signature with a public key, stored in a DNSKEY-record.
DNSKEY: contains the public key that a DNS resolver uses to verify the DNSSEC signature in RRSIG-records.
DS (delegation signer): Holds the name of a delegated zone. You place the DS record in the parent zone along with the delegating ND records. It references a DNSKEY-record in the sub-delegated zone.
NSEC (next secure record): Contains a link to the next record name in the zone and lists the record types that exist for the record’s name. DNS Resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.
NSEC3 (next secure record version 3): Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 -record’s own name. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.
NSEC3PARAM (next secure record version 3 parameters): Authoritative DNS requests use this record to calculate and determine which NSEC3-records to include in responses to DNSSEC requests for non-existing names/types.
The critical element is trust. The client must trust the zone’s public key because the public key is used to authenticate the response by decrypting the signature, which was created using the private key. Ensuring that clients trust only the “real” authoritative DNS zone owner is achieved through chains of trust.
In an ideal world, this PKI hierarchy would be self-contained in the DNS hierarchy in that the root of DNS -“.” – would be DNSSEC -enabled and globally trusted by all clients, Then, the root could sign the top-level domain name (e.g. com,net,org), which could then sign their subordinate domains (e.g. company.com), thereby creating a trust path. This means that clients would need only to trust the root zone since the root zone is used to authenticate all the other child zones.
Trust anchors
A trust anchor is an authoritative entity that is represented by a public key. The Trust Anchor 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. If the DNS server is domain-controlled, Active Directory-integrated zones can distribute the trust anchors.
Name Resolution Policy Table (NRPT)
Name Resolution Policy Table (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.
Implementing DNSSEC
In DNSSEC infrastructure, Key Master i.e. primary server must server key management and key generation service to the environment. Key Master is responsible for distributing private keys, KSK, zone signing key rollovers, and zone signing for a specific zone. It also makes sure that child zones and signed delegation are syncs and up to date. key Master can be configured on any authoritative DNS server hosting the copy of the primary zone. As long as the server hosts the primary zone, that server can be designated as Key Master for Multiple zones. key Master is automatically configured when you initially create the DNSSEC Zone.
