What DNSSEC is

DNSSEC stands for DNS Security Extensions. It was designed many years ago as a way to cryptographically sign DNS records so that when a DNSSEC enabled resolver looks up a DNSSEC signed domain the response is mathematically guaranteed to be valid.

What exactly does DNSSEC protect?

DNSSEC cryptographically guarantees that the response to a DNS query has not been altered or spoofed. This protects clients from various attack vectors such as cache poisoning, DNS spoofing or BGP hijacks/BGP leaks and name server hijacks. When you query a DNSSEC signed domain you know that the result is real and that it originated from the real name servers for a signed domain.

What is the current status of DNSSEC deployment?

The DNS root (“.”) was signed in 2010 and nearly all of the 1500+ deployed TLDs are now signed. The number of unsigned TLDs are a small minority. This means that there is no longer any technical limitation precluding signing your zones in most of the available TLDs.

All major DNS resolver services are DNSSEC enabled for lookups, this includes:

  • Google Public DNS

  • Quad9

  • Cloudflare’s

Most major name server daemons support DNSSEC out-of-box and can typically be enabled with a single configuration option such as enable-dnssec yes; (in the case of BIND). Nameserver daemons which support DNSSEC include:

  • BIND

  • PowerDNS

  • NSD

  • KnotDNS

Is DNSSEC backward compatible with non-DNSSEC enabled name servers?

Yes. If a resolver is not DNSSEC-aware then it simply queries your domains in the usual fashion (it won’t set the “do” flag in the query) and the nameserver will simply reply back with the normal response records and not with the accompanying RRSigs. Everything proceeds normally (unless, of course, the reply has been forged or altered :)

Why everybody hates it

In the olden days (before easyDNSSEC), signing one’s zones was not exactly “set-and-forget”. Doing so requires several steps:

  1. Generating a Zone Signing Key (ZSK)
  3. Generating a Key Signing Key (KSK)
  5. Signing every RRSet within your zone with the ZSK
  7. Signing the DNSKEYs with the KSK
  9. Creating a Delegation Signer (DS) from the KSK
  11. Getting the DS record into the domain’s parent TLD

Then you would have to re-sign the zone every time any record within it changed.

Further, it was originally recommended (although not as strenuously now), that one rollover their keys every so often, like monthly or annually. The problem here is that key rollovers are non-trivial. You have to take in account that some resolvers may have the old key cached while receiving fresh data signed with the new keys. If you screwed up a key rollover, your zone would go dark to DNSSEC enabled resolvers.

This has happened so often that there is even a website which tracks major outages (like entire TLDs) that have gone offline because of botched key rollovers.

Why you need it

Love it or hate it, DNSSEC is now necessary to protect one’s mission critical domains from the very real spectre of BGP hijacks or BGP leaks. Until recently, DNS cache poisoning was considered by some to be remote or hard to execute because even without DNSSEC, name servers started using mechanisms such as source-port randomization which made poisoning hard.

But starting in early 2018 a novel twist was made on an old attack vector: BGP hijacks (a.k.a BGP leaks) were used to hijack IP address space of target websites, or the name servers for those target websites. In the case of the latter, fake nameservers were stood up sending victims to imposter websites (in one notable case, a crypto-currency wallet site was hijacked in this manner and victims had their wallets drained).

There is no real defense against BGP hijacks as there is no formal, technical mechanism that validates or authenticates who can originate routing updates for a given block of address space. It’s a trust-reliant system that is subject to malicious or negligent actions that can hijack routes and their associated address space at any time.

Now that there have been successful BGP hijacks that have netted attackers actual money, there will be more. Until something happens at the routing level (like RPKI, which is a long way from being ubiquitous and according to some, won’t scale anyway); the main line of defence you can implement to protect your domains right now is to enable DNSSEC.

How DNSSEC works

DNSSEC uses cryptographic keys to sign your DNS zone data and then creates what are called “chains-of-trust” or “trust chains” to prove that these records are authentic (otherwise you could just sign faked records with your own DNSKEYs and prove nothing).


These are a DNS RRtype which are used as Zone Signing Keys or Key Signing Keys. Some implementations use a single key called the Combined Signing Key (CSK).
The ZSK signs each RRSet in your zone (MX, NS, A, SOA, etc)
The KSK signs the DNSKEYs themselves, and is used to generate a hash for your Delegation Signer (DS).


RRSet will be signed by the ZSK and generate an RRSig

$ dig +multi +dnssec -tns
    ; <<>> DiG 9.8.3-P1 <<>> +multi +dnssec -tns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43897
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags: do; udp: 512
;                IN NS

;; ANSWER SECTION:         10800 IN NS         10800 IN NS         10800 IN NS         10800 IN RRSIG NS 8 2 10800 20180624203519 (
                                20180525193519 7260

DS Records

The DS record takes a hash of the KSK and is inserted into the zone’s parent TLD. How does one get the DS key into the parent? Typically you do this via your domain registrar, but not all registrars support doing this, and for those that do in many cases it’s a manual process. Once the DS record goes into the parent, DNSSEC is “live” on your zone. From that moment on DNSSEC aware resolvers will look for, and authenticate all responses.

Trust chains

The chain-of-trust is the process of each zone putting their own DS record into the parent zone all the way up to the Internet Root, which is signed with its own KSK. Because of this chain of trust, DNSSEC aware resolvers can be absolutely certain that the DNSSEC signed responses they are receiving are authentic and unmodified.

How DNSSEC compares to DNSCurve, DNSCrypt and DNS-over-TLS

DNSCurve encrypts the communications channel between a nameserver and a resolver, DNSCrypt and DNS-over-TLS encrypts the channel between you and your resolver. The common feature about all these are that they secure your communications channels against eavesdropping, so for example, your ISP cannot see what hostnames and websites you are looking up.

This is different from DNSSEC, in that they protect a different aspect of your security. These mechanisms protect you from eavesdropping, DNSSEC protects you from fake data. Think of it as the difference between using TLS ( which protects your session from eavesdropping, and using GPG to sign your email, which proves to your recipient that the email they receive from you hasn’t been altered.


easyDNSSEC™ is our new and improved DNSSEC implementation automates everything outlined above. All you have to do is login to manage your domain and press the button:

  • It generates your keys, both ZSK and KSK

  • Then signs your zones with the ZSK

  • Signs the DNSKEYs with the KSK

  • Generates the DS record

  • Automagically uploads the DS to the parent registry

  • Schedules your rollovers as per your preferences

  • Maintains the zone with inline signing every time it changes

easyDNSSEC™ means that securing your zones with DNSSEC has never been easier, safer and more accessible. If your domain is mission critical, if it holds up another part of the internet or if your customers, clients and uses rely on it being online at all times, if they could lose money or data if somebody spoofed your domain, then you need to turn this on.

easyDNSSEC™ is included with all service levels

We need be your registrar for this to work.


As we do with all new features, easyDNSSEC has been deployed in beta mode:

  • Your beta flag must be enabled in your client settings.

  • Start with a non-critical domain

Real Time Web Analytics