Sunday, 24 February 2019

Securing DNS Theory

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 host names to IP address 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.

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, servicing a network of computers as shown in figure 3.1. An application on a client system , client1, make a DNS query that is sent to Then examines its cache to see if it already has the answer to the query. Unfortunately, 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 The information on happens to be incorrect, most commonly due to misconfiguration and the response sent back to contains misleading information. Since is caching responses, it caches


this misleading information and sends the response back to client1. As long as this information exists in the cache of, 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 cache content. DNS Cache locking adds an additional layer f protection onto those entries 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 using the dnscmd command.
dnscmd /info /cachelockingpercent

To use DNS Cache Locking, you set a percentage of the TTL of records that the cache 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 configured 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 send that request on TCP/53. Now on SRV1 the source port could've been the same port as of 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, it tells the server to go ahead and randomize the source port from where the actual request is coming. So, it maybe 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 hots the DNS server role:
dnscmd /config /socketpoolsize 3000


The DNS-based authentication of Name 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 you 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 issues from a different CA.
For example, suppose that your organization hosts a secure website using HTTPS at 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 website might be able to corrupt the DNS cache of a client r server to point over to its fake site. The end user is 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 asking for the TLA record, and discovers that the certificate for 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 type were created or adapted to use with DNSSEC.

RPSIG (resource record signature): Contains the DNSSEC signature for a record set. 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 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 the 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., 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 anchors 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 a 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 make sure that child zones and signed delegation are sync and up to date. key Master can be configured on any authoritative DNS server hosting the copy of 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.

No comments:

Post a Comment