Like many internet protocols, the Domain Name System (DNS) was invented quite a long time ago in the 1980’s. And like many of the original protocols, they were flawed in some ways and not entirely secure, or were not created with the same sort of requirements in mind that we might have when designing a new protocol today.
For example, to ensure privacy and data integrity, SSL certificates were made of use to secure protocols like HTTP and FTP, and we now have HTTPS and FTPS. Previously, and by default, DNS was also an unencrypted protocol. There was no layer of trust when it came to DNS – that means, when a DNS request is made, it assumes that the response it receives back is trusted and from a legitimate source. This opens up DNS to things like ‘DNS cache poisoning’, also known as ‘DNS spoofing’ – which allows a malicious party to quietly redirect users somewhere else when they try to visit a website. They may redirect them to a website that looks exactly like the one they intended to go to, but is actually just a dupe, with the intention of collecting sensitive information or financial gain.
One of the simplest ways that a malicious party might do this is by gaining access to the domain’s nameservers or DNS configuration, and then either updating a domain’s nameservers, or updating where the nameserver itself points to. This is where DNSSEC comes in to help secure DNS. DNSSEC effectively adds a series of new DNS records, which help to secure a domain. If you’re familiar with how DKIM works to prevent against email spoofing, DNSSEC is quite similar.
Multiple new DNS records were created for the purpose of DNSSEC. These records are just like the same records you may already know, such as A, CNAME, and MX, except that they’re exclusively used for DNSSEC. The records that are required for DNSSEC to operate are as follows (bear with us here, the descriptions get a little on the technical side!):
- RRSIG – 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 signatures in RRSIG records.
- DS – Holds the name of a delegated zone. References a DNSKEY record in the sub-delegated zone. The DS record is placed in the parent zone along with the delegating NS records.
- NSEC and NSEC3 – For explicit denial-of-existence of a DNS record.
- CDNSKEY and CDS – For a child zone requesting updates to DS record(s) in the parent zone.
DNSSEC, like SSL, uses public-key cryptography. That is, a private/public key pair. Public-key cryptography works by having a public key that is available to the public (as the name suggests), and a private key. The private key is used to decrypt information that has been encrypted using a matching public key. This is the same method that SSH keys use. You can read more on public-key cryptography on its wikipedia page, or by doing some googling if you’re interested.
When any DNS requests are made, for example when visiting https://www.digitalpacific.com.au, a request is made to look up the A record for this domain. If a domain has DNSSEC enabled, another request is made at the same time for the DNSSEC key that’s associated with the DNS zone. That DNSSEC key will be able to verify that the response it received about the IP address in the A record matches the one on the nameserver. If it does not, the domain will not resolve and the site will not be displayed.
How To Setup DNSSEC
Both your domain name registrar, and where you host your DNS records, need to support DNSSEC. If you’re not sure if your registrar or hosting provider support DNSSEC or not, you may need to reach out to them for further information.
The steps for how to setup DNSSEC for your own domain will differ from provider to provider, however at its core, there are two steps:
- You will need to first generate your DNSSEC records on your nameservers.
- Once that’s done, you will need to enable DNSSEC on your domain name itself. Once DNSSEC has been enabled, you will be able to add in the keys that were generated by your nameservers.
Be extremely careful when making these changes and make sure to do your research first, as any mistakes will cause your domain to no longer resolve.
Is DNSSEC Worth It For Your Average Business?
While DNSSEC may sound necessary and like a good idea, it’s important to look at whether it’s likely that the extra maintenance and potential downsides are worthwhile. Typically, DNS MITM (man in the middle) attacks like ‘DNS spoofing’ are extremely, extremely rare. In fact, it’s far more likely for a website to go down from misconfigured DNSSEC, than it would be from a DNS-related attack. It also makes it more difficult to make nameserver changes on your domain if and when you need to, as you’ll need to generate a new set of DNSSEC records each time.
Arguably the biggest downside of DNSSEC, is that it increases DNS lookup times. Results have shown as much as a 300ms increase in DNS query time when DNSSEC is in use. While 300ms might not sound like much, when we’re looking at around ~50-100ms for a typical DNS query, it’s quite large. DNSSEC is also one more thing to manage, increasing your regular maintenance tasks.
If security is your chief concern, you’re confident in setting DNSSEC up, and you don’t mind the extra maintenance and load times, then DNSSEC is something you may want to look into. But for an average online business, your security efforts may be better focussed elsewhere.
Whatever action you choose, hopefully this post has been useful in getting you more acquainted with the basics of DNSSEC and the options available to you.
As always, if you have any questions about this post or our shared hosting, VPS, reseller or dedicated server plans, simply call us on 1300 MY HOST (694 678) during business hours, or submit a ticket through our Support Portal and one of the crew will be in touch!
