DNSSEC What it does to protect your domain

You may be wondering what DNSSEC is and why you should care about using it. DNSSEC is a technology that uses cryptographic keys to validate the connection between a client end user and a domain name such as example.com. There is a security chain of trust that helps to protect against known vulnerabilities in DNS (Domain Name Servers) by using a series of public and private encryption keys to allow for validation of each step in the DNS resolution process, thereby protecting end users from having their web traffic and communications proxied (intercepted) or spoofed.

DNS servers act much like an operator switchboard that allows for a caller to look up a person or domain name by a friendly name and return the corresponding telephone number or IP address.

A major vulnerability associated with DNS is the potential for DNS spoofing, also known as DNS cache poisoning. An attacker can poison a targeted computer’s DNS resolver cache and reroute the compromised victim to a different IP address, thereby allowing for a MITM (Man in the Middle) attack, which can result in interception and morphing of the information while in transit between the victim client and the legitimate server. Free tools widely available such as Kali Linux can be downloaded and quickly deployed to poison a target’s DNS resolver cache that stores the mapping of domain names to IP addresses locally. A successful DNS Cache Poisoning attack can allow the attacker to intercept usernames, passwords and other private communications. Even more troublesome, is the potential for a diligent end user that wants to patch the firmware on their Dell or Apple computer to be spoofed and tricked into downloading a malicious update without knowing their connection has been diverted. None of the major software hardware providers use DNSSEC, presumably because they want to use cache servers to distribute updates (or even because our government wants to be able to intercept our own communications relating to these entities), but as a result, end users could be poisoned resulting in not getting a legitimate software or hardware update. DNSVIZ.net is a website that has a tool that allows anyone to evaluate the secure implementation of DNSSEC. Here are just a handful of computer or peripheral makers that are not presently using DNSSEC.

Simply because a domain reports an insecure DNSSEC configuration does not mean they are compromised. It means that the domain is susceptible a a remote attacker impersonating the domain, be it our own NSA or CIA, or even a script kiddie teenager using Kali Linux to attack their target. If all of these companies implemented DNSSEC, it would make it much more difficult for our own intelligence agencies to collect information on targets being surveilled. A simple solution would be for monthly updates to be available by mail on read only disk media for a nominal fee, or available at your local library or computer retailer.

I strongly recommend that any security minded organization implement DNSSEC to protect your domain name for being attacked as described previously.

Implementation of DNSSEC using strong encryption allows for the end user to have confidence that their web surfing connection or email connection is secure end to end. DNSSEC does this by using a series of private and public key combinations that starts with the top level domain (TLD), e.g, .com, then to the Trust Anchor DNS servers in the SOA (Start of Authority), onward to delegated DNS that help to cache server results. that acts to validate and tie control over a domain name to specific IP addresses of the Trust Anchor DNS servers that have control over the domain and serve as validation servers.

Chain of Trust

User types mail.google.com -> Query control starts at root with Internet Corporation for Assigned Names and Numbers (ICANN)
Control then passes to .com TLD (Top Level Domain) (Verisign controls .com)
Registrars such as Godaddy allows for controlling the SOA (Start of Authority) DNS Servers but do not serve directly in the DNSSEC chain unless specified
Then control passes to the primary domain name’s SOA DNS Servers – e.g. example.com has SOA DNS servers sns.dns.icann.org. noc.dns.icann.org
Mail routed based on SOA DNS Servers
The client can perform a series of public key validation from across all servers in the chain of trust above allowing for endpoint validation of the internet connection between client and server.

Why wouldn’t someone want to use DNSSEC?

DNSSEC places a burden on the SOA DNS Servers that must validate each initial request between a client connecting to a DNSSEC enabled server. This problem can be addressed by adding more DNS Load balancing servers and properly configuring DNSSEC. For any organization that cares about protecting email communications from being intercepted or spoofed, incorporating DNSSEC properly can help protect communications that rely in any way on the friendly domain name such as mail.google.com.

How to Test DNSSEC Security

Verisign has a free tool that can enable you to check your own DNSSEC configuration to see if your domain name is protected against DNS Cache Poisoning attacks that could allow for communications interception and compromise of authentication credentials. http://dnsviz.net/

FBI.gov – an example of secure implementation of DNSSEC by a U.S. Government Agency

An example of a U.S. Government entity that has effectively configured DNSSEC to protect communications from interception can be found at:
http://dnsviz.net/d/fbi.gov/dnssec/

The following graphic displays the Chain of Trust for the fbi.gov’s DNSSEC implementation and shows a secure implementation of DNSSEC.

A query of the FBI.gov’s DNS entries shows they are properly using encryption keys to secure the chain of trust, thereby protecting the agency from DNS Cache Poisoning attacks, either directly against the FBI, or against third parties that may be trying to communicate with the FBI via the FBI.GOV domain or subdomains.

DIG DNS QUERY AGAINST FBI.GOV Returns the following:

;; Truncated, retrying in TCP mode.
; <<>> DiG 9.8.1-P1 <<>> @localhost fbi.gov ANY +m
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36538
;; flags: qr rd ra; QUERY: 1, ANSWER: 28, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;fbi.gov. IN ANY
;; ANSWER SECTION:
fbi.gov. 1800 IN SOA a1.fbi.gov. mdnshelp.verisign.com. (
1415240285 ; serial
600 ; refresh (10 minutes)
1800 ; retry (30 minutes)
1209600 ; expire (2 weeks)
1800 ; minimum (30 minutes)
)
fbi.gov. 1800 IN RRSIG SOA 8 2 1800 20170712220426 (
20170628220426 15636 fbi.gov.
pKUmgUeNI71Td6tHvJhxICHUgRPOP9krcqlYuuKatGnE
VCEDdlwUeZXe/1h3jSz3i5hxZpXLTXBgQL5FYxQcZdWN
WbteoEOJhKNhFqejPWuT0tBGKWekEGOfq4+qd9BPn6l9
4luVav1jfuk6YlhkINQrukWp3O3340roYhmwPio= )
fbi.gov. 1800 IN NS a3.fbi.gov.
fbi.gov. 1800 IN NS a2.fbi.gov.
fbi.gov. 1800 IN NS a1.fbi.gov.
fbi.gov. 1800 IN RRSIG NS 8 2 1800 20170710092533 (
20170626092533 15636 fbi.gov.
ufNfpoAXreL31wkoLfSEPpKg3995jIzca00I8tvCDSbx
l51t1DSgFgf9DtoEWYEJ/X11EyeIm20pNxgr/x4Ik5NG
pB+yyCalSSshfZ++VrKDP/rLyUF9clpCHvlYr5AzCt1E
bpE8DTcOwrbXgAvpLptgUEot3kdOLqErG706X7E= )
fbi.gov. 300 IN NSEC3PARAM 1 0 8 4C44934802D3
fbi.gov. 300 IN RRSIG NSEC3PARAM 8 2 300 20170710092533 (
20170626092533 15636 fbi.gov.
VM/h2iBkVKPQa5Gh3Tp0K1x9nS482bp3ECYdXuDo+MFj
q/SSpn8453hPSwezuxWWBHYkgtWVdpA0oSsx2hMv/wtb
TAH2dC6tHqB81DnX25Vv8Ht1LvWrGQMLgx6zbcSfqFAl
iw9G73eYmF5p+AuGp+sPvxcd/vFfqfMCr6yOMoY= )
fbi.gov. 120 IN A 104.16.78.187
fbi.gov. 120 IN A 104.16.77.187
fbi.gov. 120 IN RRSIG A 8 2 120 20170710092533 (
20170626092533 15636 fbi.gov.
YgJL12uLLZ5aI64/v6v9v8b/n8s6wGkotmYqgdnzbDJw
cwV7GD1lpqR/LwGxeRL+Ea8cwhTmGgtLkCiO7ckcYPG3
QM07AuP6qLIE0cA/Pe8Z0ZQ9Fy40U3fTLT+bxq+sCqbr
Y2W1H+85giI40rmM2wF5Px4e9ZRqNrT/dS96qNk= )
fbi.gov. 120 IN MX 10 mx-east.fbi.gov.
fbi.gov. 120 IN RRSIG MX 8 2 120 20170710092533 (
20170626092533 15636 fbi.gov.
u1G4SKS1PMsMB2EWc7T3giEyYB88MhmU8TMTogWqkHMw
ptAFUdEeyDkXcl+QRqovBEqkWYDDfto9U/n0T11Fk+kH
PHrPISd/5Yo6MfUeiEZkD8vYsIh+Gj6ddD+81mu1P904
VMWzJLV9Ettx4AvxuhTaC2/8Av2BxijpfbSbhxQ= )
fbi.gov. 1800 IN TXT “ublrZj1CzpSEiwtiRFKDAyiek8hRqkqaTTApxvhwai14i8JqVBOauW4cA06i39H5Lhl3HnALCM/xfTxIPEXEpA==”
fbi.gov. 1800 IN TXT “v=spf1 +mx ip4:153.31.0.0/16 -all”
fbi.gov. 1800 IN TXT “google-site-verification=L8cauHJF4MANoTCkMbrLkAVfHBta28ctva9n1IDekTo”
fbi.gov. 1800 IN TXT “625558384-8740534”
fbi.gov. 1800 IN TXT “MS=ms39271050”
fbi.gov. 1800 IN TXT “google-site-verification=6UEk-jfg1xPNjz_rQGcRFJOBGxMy1aARDZUTXgSNAqw”
fbi.gov. 1800 IN TXT “globalsign-domain-verification=ojb05FqimxLsWXiucPx99rxG1FOKPV-Ym-rqatrz-q”
fbi.gov. 1800 IN RRSIG TXT 8 2 1800 20170710092533 (
20170626092533 15636 fbi.gov.
X38WNsmluiFT2kz175fLFXQMS5mpufJw6+1b9vcDuMTD
GWy4EHbsjsSiKOymM/0dbaeAuJW32WmYaBZfW3pzRPe+
7RaiW6uumS08+Skx1dpRqSD5EqraFpNOyT9Mj4XhDKY4
1brYzlerzI1Z47wrcW/tOoiFzStYyFKGHuUhbmA= )
fbi.gov. 60 IN AAAA 2400:cb00:2048:1::6810:4ebb
fbi.gov. 60 IN AAAA 2400:cb00:2048:1::6810:4cbb
fbi.gov. 60 IN RRSIG AAAA 8 2 60 20170710092533 (
20170626092533 15636 fbi.gov.
ky50SpSklhfwbKCtdF2IDWPjWrBHk2QiRD1FMsR42n1j
ep4+xbYdldHOTe1Sd7V4xgkyigIfc3UGsjUgzGAsKUz3
W/8uev6EuMB9fRyOpJYhydxNMgu/n+XalM7MI5pxj97H
l3OzH0y1Y0QcSxVZrQ7O+QBETPyO6vyFzssiNwI= )
fbi.gov. 3600 IN DNSKEY 256 3 8 (
AwEAAeh5lPrKMFRYJJEC43Qb3xK1gr5lc8iO1qYq3jPt
O8/RGVCHUzcMfIPmSwidWMdYnP/QnIl6oPfdZKiBFnwx
CzozBfSqcq5PKkGCCITdgXsV9t7QdjqpA5yWUyk07jf8
wu9NduHgsf918vOCuZ0OxwDRa7/cNnP271iDwu7IaPgT
) ; key id = 15636
fbi.gov. 3600 IN DNSKEY 257 3 8 (
AQPFuOiUlNUJKCVTFZgQFrk0sYJqPk1w+MIlS26S7mR8
V3HhZMSjAsbdVqEAwwioWE72HMTGIyE1084mbkFtH6Ag
U33YImnT+FdCzPrWuE4EFlO6sjhK/yaIOXCjJgc4Edf4
Vd1JognyCldDikVaRdARxHnmSeB9ew+q4Yw2xiBUsdyH
qJ2AGH7YaY5IovMyhaubPjYWcLKinjswq692EZvKnxfd
26KsVVn2vlxvqdiR8qIMqb8raOQNmOjhfEerqjUAj2E7
+c/sM57dzZHZuvweg4gjo6LgjWamQ6XsM2svESsiv78B
DTxzgqY8ssIs92LwyEBQ3Oi6BXwFX3o/Ulr1
) ; key id = 5781
fbi.gov. 3600 IN RRSIG DNSKEY 8 2 3600 20170710092533 (
20170626092533 15636 fbi.gov.
sRZL+kgsze4OLaiWOV/uVrG4XsQdEZ1LWSnflSNTmXMZ
AxlByR6c+uUWgALMQZidtJX/V1N7bUKM+Ru8kjK0OsD9
dXQfCADM8EGHKlfHnm8WdMAI5aqH2qvCRgRTMEOBCGbW
afRm1T1QWeFswLLpGgQuoGrIU0niEVY5s0z1BrA= )
fbi.gov. 3600 IN RRSIG DNSKEY 8 2 3600 20170710092533 (
20170626092533 5781 fbi.gov.
HDUBNR9Y6VjUr69E/AT1r2vqPOwBQy64FaHwvUzqaQCy
mkEEPz5ee4VncXCuyisU4moudsxficI4550Hxd4ZGwtL
FQXsEoqoFhtlDP+S1X7QgFbwQljZILmO4WaslXmJVQOR
ezQH226oJQ/nHUFNCuqjZiqOO4hHVSwKepetwGnp78x/
1wxKJ/RaMarnEX5WbTctFhQVjJALqHVUw1Fior/dZL/h
dER2iOvjlimaw+q4tS9pXT5E3y3fgG+GofbFpm2xQDYX
5tkvGVQfQekFUSeDQpmCFQbcxpvlUK9YG72azXxjjbU+
1REIfTKBf7oBohhTnq5qiygBV5xEfvoYbg== )
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jun 30 16:48:41 2017
;; MSG SIZE rcvd: 2772

What this all means?

The RRSIG above is a cryptographic signature that is used to validate connections between client and any fbi.gov DNS mapping and helps to ensure secure connections and communications. The DS Contains the hash of a DNSKEY record. These various pieces allow for an end client to validate the connection to any fbi.gov domain as authentic. The MX record mapping for email connected to the FBI.gov domain uses a unique RRSIG cryptographic signature to help ensure communications can’t be intercepted by a DNS Cache Poisoning attack.

Problems Remain and Governments Around the World Continue to be Compromised

Unfortunately, many Government agencies still have not securely implemented DNSSEC, which leaves our government vulnerable to the types of attacks described herein.

Just last week, news reports indicated that the UK Parliament email servers were subjected to a cyber attack.

A review of the the impacted Parliament.uk’s DNSSEC configuration shows that DNSSEC for parliament.uk is not securely implemented, which may lead to further such attacks on the UK Parliament’s email accounts. People need to get the word out on this so all of the attacks against our government and our allies around the world can be curtailed.

See the following link which as of this post shows a insecure DNSSEC configuration for parliament.uk: http://dnsviz.net/d/parliament.uk/analyze/

The screenshot below was taken from the prior hyperlink, and shows that the TLD .uk is not using public and private encryption keys to protect and validate the DNS chain of trust, and as a result, the parliament.uk domain still remains vulnerable to further attacks.

Interestingly enough, gov.uk (The main UK governmental domain) is using an apparently secure implementation of DNSSEC. http://dnsviz.net/d/gov.uk/dnssec/

Why one branch of government chooses to securely configure their domain with DNSSEC and another does not, remains a mystery to me. I think it is most likely because the topic is complex and their aren’t enough people with needed cyber security skills working in government due to historically non-competitive compensation, and because government agencies often operate as silos without readily sharing information amongst themselves. I have reported concerns about the lack of widespread DNSSEC implementation and have not seen action on this, or even a reply of justification for why an entity concerned with security does not implement DNSSEC. Hopefully this blog post will help to bring about needed changes to protect the public and private sectors from these types of attacks.

I am happy to report that I have implemented DNSSEC securely for my own website. http://dnsviz.net/d/leeneubecker.com/dnssec/

Anyone concerned about protecting the integrity of their email communications as well as web access to their domain should implement DNSSEC without further delay.

I am hoping that this post helps illuminate the potential threat and problems posed by not implementing DNSSEC in a secure manner.

If you have time, visit http://dnsviz.net and check out your own domain name’s implementation of DNSSEC to see if you are potentially vulnerable to DNS Poisoning attacks that could compromise your domain.

If you want to learn more about DNSSEC, I found a reasonably short video that explains DNSSEC in more detail at https://www.youtube.com/watch?v=MrtsKTC3KDM

Facebook Comments

Lee Neubecker

CISSP, MBA, Cyber Security Professional & Computer Forensics Expert