Before we get into the meat of DNSSec, you may want to watch this introductory video that provides a basic overview of what DNSSec does.
The original design of the Domain Name System (DNS) did not include security. The DNS protocol is vulnerable to attack due to an inherent lack of authentication and integrity checking of DNS data that is exchanged between DNS servers, or provided by DNS Servers upon request to DNS clients.
DNSSEC was designed to protect Internet resolvers (i.e. protect the DNS clients or other recursing DNS Servers) from being presented with forged DNS data.
Typical DNS Threats:
DNS spoofing is a type of attack that involves the impersonation of DNS server responses in order to introduce false information. In a spoofing attack, a malicious user attempts to guess that a DNS client or server has sent a DNS query and is waiting for a DNS response. A successful spoofing attack will insert a fake DNS response into the DNS server’s cache, a process known as Cache Poisoning. A spoofed DNS server has no way of verifying that DNS data is authentic, and will reply from its cache using the fake information. An attacker can also set the time to live (TTL) on fake DNS data to a very long interval, causing the DNS server cache to remain poisoned for many hours or days. It is also possible to send a DNS spoofing attack directly to a DNS client, however these attacks are less persistent than cache poisoning attacks.
From the view of an attacker, an ISP's DNS Server or the Internet Root DNS Servers are the perfect targets for attack. The attacker only needs to poison one DNS Server with false DNS data, and all queries for all the users/systems of that DNS Server can get false DNS data that may divert the users actions to the attackers compromised machines.
How DNSSec Secures DNS Data:
DNSSec uses asymmetric Public/Private key cryptography to provide Digital Signature Validations, just like in Windows PKI. With DNSSEC, every individual Resource Record within a DNS Zone, of every type (A, AAAA, MX, CName etc), is accompanied by both a Delegation Signer (DS) record, which is a Hash value of that record, and a Resource Record Signature (RRSIG) record, which is an encrypted copy of the Hash value (encrypted using the DNS Servers’ private key stored on a DNSSec enabled DNS Server)
Note: Essentially, a Hash is a value computed using an encryption algorithm such as Message Digest (MD2, MD4, MD5) or the Secure Hash Algorithm (SHA) applied to the original data - the Resource Record in this case.
When a resolver (i.e. a client system or another DNS Server) issues a DNS query for resource record information from a DNSSec enabled DNS Server, the Digital Signature (RRSIG) and Delegation Signer (DS) records are returned to the resolver along with the usual DNS data requested.
The resolver then uses a Public Key (called a DNSKEY) it has obtained from the DNS Server provider to decrypt the RRSIG record it gets and compares the result from this decryption with the DS it also has from the DNS Server. If the result of the decryption carried using the DNSKey on the RRSIG data out matches the DS, the DNS data is approved as being from a valid source.
Before you can perform any of these DNS Signature validations, all involved parties must trust a common "authority" at a higher level, in order to create a trust path beforehand. This "authority" is known as a Trust Anchor, which is similar to the Certificate Authority (CA) in the PKI concept.
On the Internet the common DNS Trust Authority are the DNS Root Servers. Thus trusting DNS responses starts with the root DNS Servers on the Internet and key to protecting our DNS queries for external/Public DNS data would be to ensure the validity of root DNS servers on the Internet.
Because everyone trusts this common Anchor Point, any clients would also trust other "child zones/domains" vouched for by this "authority". Just like with a PKI CA, it is also able to sign next-level child zones, such as child.abc.com if the Trust Anchor is on abc.com. Thus, we have a chain of Trust.
Thus, if all Public Root DNS Servers have all of their zones/domains digitally signed, then any resolver (i.e. your client systems, Internal DNS Servers, or other DNS Servers) that can hold a copy of the Public Keys (DNSKEY and DS key) provided by the Internet Root DNS Servers, can validate Public DNS data.
Note: As of May 5th, 2012 all Internet Root DNS Servers have been digitally signed in order to limit opportunities for DNS attacks.
Windows Server 2008 R2 (limited to static DNS zones), or more appropriately, Windows 2012 support the configuration of Trust Anchors/Trust Points, allowing them to store Root DNS Server Public Keys. These Public keys get stored either in the forest directory partition in Active Directory Domain Services (when the DNS Server is AD-integrated), which allows them to be replicated to all domain controllers in the forest, or for standalone DNS servers (i.e. non AD-integrated), in a file named TrustAnchors.dns located at %windir%\System32\DNS.
A DNS server will perform validation for DNS data requests from resolvers (i.e. client systems and other DNS Servers) as long as it has been pointed to a Trust Anchor/Trust Point, and that Trust Anchor/Trust Point has a stored copy of the Public Keys it needs for the DNS zone it is trying to obtain DNS data from, or for a parent zone if present. This DNSSec process happens no matter if the client issuing the query indicates knowledge of DNSSEC or not. This behavior ensures that DNSSEC-unaware clients are protected.
Making Use of DNSSEC Security:
As the Domain Name System (DNS) is a crucial part of the core infrastructure of the Internet and is also key to internal Domain environments, it is useful to be able to make use of it within our network environment.
Making use of DNSSec security has 2 aspects to it:
On the DNS Server side – imposing DNSSec on DNS Servers authoritative for DNS zones/domains by digitally signing those DNS zones/domains.
On the Client Side – Enabling clients to obtain DNS data from DNS Servers that have had their DNS zones/domains digitally signed.
Normally, unless we are hosting our own Public DNS Servers we will only be concerned about the second of these aspects of using DNSSec which is to ensure that any requests for DNS data from our client systems are met with valid DNS data by only using DNS Servers that have had their zones digitally signed.
Our network based clients of course will typically be requesting 2 types of DNS data :
DNS data from our Internal/Private DNS Servers
DNS data from External/Public DNS Servers
On our own Internal\Private DNS Servers when simply dealing with internal requests from our local Domain Client systems or transferring DNS data between internal DNS Servers within our own controlled Domain, it would be safe to say that all DNS information exchanged should be valid, and DNS security is not such an issue.
Thus, on your Windows Domain you are unlikely to need to implement digital signing of any of your Internal DNS Server zones on for dealing with internal/private DNS data exchange between your internal/private DNS Servers or for dealing with internal/private DNS requests from your internal/private clients, unless you also believe there could be an internal DNS data poisoning threat.
When our internal clients need to access external/public resources (i.e. a public web site, a public ftp site, send e-mail to an external e-mail server), they will need access to external DNS data.
For these external/public DNS activities, it is most likely you have set up your local internal\private DNS Server(s) on your domain with DNS forwarders to external/public DNS Servers (probably provided by your ISP), or if you have no forwarders, your internal/private DNS will directly use the DNS Root Hints Servers list it has for external/public DNS data.
If you use forwarders to your ISP's DNS Servers from within one or more of your internal/private DNS servers, or rely on directly using the Root Hints file data, you will need simply to have a Trust Anchor/Trust Point that holds a copy of the public keys from the Internet Root DNS Servers to ensure DNS data vaildation.
Remember, the DNS Servers belonging to the ISPs also just need to have been pre-configured with a Trust Anchor/Trust Point of the Internet Root DNS Servers - much like the Web browsers on your desktops that are pre-configured to trust the public certificates of such as those of Verisign & Thawte. You can ask your ISP if their DNS Servers are DNSSec ‘tuned’ with such a Trust Anchor/Trust Point.
Obtaining and Importing Public Keys:
The Internet Root DNS Server public keys, respectively, can be obtained from IANA (Internet Assigned Numbers Authority) at:
Getting the Internet Root keys is more difficult than it should be (you cannot just download and import the keys into your internal/private Windows 2012 DNS Server Trust Point), since the Microsoft DNS Server does not recognize the format of the trust anchor keys as they are published by IANA.
It is easier to let your Windows 2012 DNS Server get the correct Trust Anchors using a command prompt of:
dnscmd /RetrieveRootTrustAnchors
or dnscmd /ImportRootTrustAnchor
Running the latter will import the root from the ICANN (Internet Corporation for Assigned Names and Numbers) authority using https as well as enabling validation for responses. Once you have the acquired the Public Keys this way, they will show up within your Trust Points section of your Windows DNS Server. These Public keys\Trust Anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and will be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named "TrustAnchors.dns" in %windir%\System32\DNS
The following screenshots show the process of importing root DNSSec public keys into a private DNS server using DNS Manager.
It is suggested, that you may well not even need to import the Trust Anchors as just shown, as it is suggested that Windows Server DNS servers that are configured to either forward queries to other DNS servers or to recurse queries to the Internet Root Servers, will automatically retrieve the additional Resource Records required to perform DNSSEC validation (i.e. the DNSKEY and DS key) and will validate responses received. Ideally though, Import the Trust Anchors if possible as the above cannot be relied upon.
Once the Trust Point has been set and Internet DNS Root Public keys have been imported into your Internal\Private DNS Server(s), all external DNS data should be authenticated.
DNSSec Firewall Issues:
Most problems with DNSSEC are related to firewalls - two types in particular:
The first involves the TCP protocol. There is a misconception among firewall vendors and security administrators that DNS queries use the User Datagram Protocol (UDP) and that zone transfers use TCP. Unfortunately, this assumption is not entirely true. DNS queries first try UDP, but revert to TCP if no response is received for the initial UDP query or if the response lacks important information because it is truncated. The possibility of something in the path blocking the response to the initial query is much higher with DNSSEC because of the increased size of the responses. For DNSSEC to work correctly without Firewall issues, it is mandatory that you open your firewall for both TCP and UDP over port 53.
The second problem is related to DNSSec data being larger than 512 bytes. Thus, you must configure your firewall to allow for DNS data packets larger than 512 bytes over UDP and TCP.
Testing DNS Data Has Been Validated:
To check that your Clients and Internal DNS Servers are using valid DNS data from an external website for example you can use the Powershell command:
Where Website_URL is such as www.bbc.co.uk and DNS_Server_Name is the name of the DNS Server (i.e. your ISPs DNS Sever IP address or name) used to retrieve the DNS data (i.e. the website IP address) from.
However, this resolve-dnsname command unfortunately does not display the state of the AD (Authenticated Data) Flag in the external DNS response header. This AD flag will tell us if external DNSSEC validation is working or not.
As an alternative, we can download the BIND for Windows software (BIND is a DNS Service hosted on Unix\Linux systems) and rather than installing a new DNS Server, install ‘Tools Only', which installs the Unix command dig (among other tools) on Windows. With dig we can see the AD flag on signed external DNS Servers, and therefore validate that DNSSEC validation is indeed working.
To use the dig command to validate DNSSec is being used, type:
dig Domain_Name +dnssec + multi
Domain_Name = any chosen public domain to test DNS Sec resolution against to ensure that you are on a system\LAN environment where date from DNS queries is DNSSec validate. On your own Internal\Private DNS Server that forwards DNS queries on for you, ensure the DNS Server cache is cleared and similarly, on a client system (if the dig command is being run from a client rather than the Internal\Private DNS Server) use ipconfig /flushdns to clear the local cache prior to running the dig command.
Note: There are also other Third Party tools such as the ‘Check DNSSec Signatures’ Tool which can be used to test DNSSec validation for DNS queries from your LAN to the outside world.
Digitally Signing Internal/Private DNS Server Zone Data:
If you also wish to ensure that all Internal\Private DNS activity is also secured in addition to the External\Public DNS data, you can also digitally sign your Internal\Private DNS zones and let self signed certificates be created for the DNS Zones.
Selecting "Sign the Zone" launches the zone signing wizard.
Once your Internal\Private DNS Zones have been signed, the DNSSec record types are automatically created within the zone as follows:
RRSIG (Resource Read Signature)
DNSKEY (A Public Key)
DS (Delegation Signer)
NSEC (Next Secure)
NSEC3 (Next Secure 3)
Note: NSEC and NSEC3 are records are used for robust resistance against spoofing (Their use is explained later).
Once your Internal\Private DNS Zones have been signed and the certificates created you simply need to ensure that the generated certificates (in %windir%\system32\dns) are added\listed as Trust Anchors for the zone, by simply importing them into the Trust Points section of the DNS Management Console.
You now have an Internal\Private DNS Server that can authenticate its own DNS Data when queried by DNS resolvers (i.e. your domain client systems and other Internal\Private DNS Servers).
If this signed DNS Server is AD integrated all other Internal\Private Windows DNS Servers that can work with DNSSec (essentially Windows Server 2012 only) will receive the updated signed zone data. For the internal Trust Anchor you would simply import this into each Internal\Private DNS Server from the %windir%\system32\bin folder on this first signed DNS Server. If this DNS Server is not AD integrated zone replication will update the zones.
To force DNS resolvers (i.e. your domain client systems and other Internal\Private DNS Servers) to only accept require DNS data that has been verified, you can use Group Policy settings to create a Name Resolution Policy Table (NRPT).
Apply the Group Policy to a specific AD Org. Unit that contains Domain Client Systems and then test the application of the Policy by first clearing all cached DNS data on any client system where this is being tested using ipconfig /flushdns
Then using Windows Powershell (which is available in Windows 7\8 by simply typing Powershell in the run command prompt) type in:
Resolve-dnsname FQDN_Name_of_a_Domain_System –Server DNS_Server_IP_address -DNSSecOK
Where FQDN_Name_of_a_Domain_System is such as Server1.Testing.local, Client1.Testing.local etc and
DNS_Server_IP_address is the IP address of the Internal\Private DNS Server that has had its zones signed.
Note that the data returned from the signed Internal\Private DNS Server includes a signature and RRSIG data.
DNSSec in a Mixed Windows Environment:
Windows implementations of DNSSEC will interoperate with older versions of Windows that do not use DNSSEC as well as other operating systems. The following are guidelines for DNSSEC deployment in a mixed environment:
All servers authoritative for a DNSSEC-signed zone must be a DNSSEC-aware server (such as Windows Server 2008 R2 or Windows 2012).
A DNSSEC-aware Windows client that requests DNSSEC data and validation must be configured to issue DNS queries to a DNSSEC-aware and (optionally) IPsec-compatible DNS server that is configured with trust anchors (such as Windows Server 2008 R2 or Windows 2012).
Non-DNSSEC-aware Windows clients can be configured to issue DNS queries to DNSSEC-aware servers.
A DNSSEC-aware server can be configured to recurse queries to a non-DNSSEC-aware DNS server.
Additional Notes:
What if a DNS query is for a domain or record that does not exist? If the DNS server responds that no record was found, this response also needs to be validated as authentic. However, since there is no resource record, then there is no RRSIG record. The answer to this problem is the Next Secure (NSEC) record. NSEC records create a chain of links between signed resource records. To create NSEC records, the zone is sorted and NSEC records are created such that each NSEC record has a pointer to the next NSEC record. The last NSEC record points back to the first record. When a query is submitted for a nonexistent record, the DNS server returns the NSEC record prior to where the nonexistent record would have been in the order. This allows for something called authenticated denial of existence.
NSEC3 is a replacement or alternative to NSEC that has the additional benefit of preventing “zone walking” which is the process of repeating NSEC queries in order to retrieve all the names in a zone. A DNS server running Windows Server 2012 supports both NSEC and NSEC3. A zone can be signed with either NSEC or NSEC3, but not both.
