Why DNSSEC is required to stop your domain from being hijacked

25 Feb 2026, by Slade Baylis

As many of our long-time readers will know, security is a topic that we cover often – that’s because, whilst it’s always been important to be secure, the number and frequency of cyberattacks has almost never been higher.

As we’ve covered in our previous article about AI Voice Cloning, phishing attacks have now reached the point and sophistication that they can impersonate loved ones in order to extort you.  But that’s not all, advancements in AI have unfortunately empowered and increased all forms of cyberattacks.  From just increasing the grammatical accuracy of previously malformed and badly worded phishing emails, all the way to crafting fully targeted “spear phishing” attacks that can specifically target individuals with information pulled directly from all of their public ally facing information on social media.  It’s a scary cyberworld!  Which is why we’re so vigilant in warning our clients about what the latest threats are and how best to avoid becoming the next victim to them.

This month we’ll be focusing on domain names - more specifically the Domain Name System, abbreviated to DNS, that allows devices to translate domain names into IP Addresses – which are the unique identifiers that identify servers and devices around the world.  We’ll be talking on a relatively recent introduction that has been created in order to address a long-standing vulnerability in the DNS system as a whole, one that left domain name resolution open to “man-in-the-middle” attacks.

What is DNS?

Before we start on talking about that vulnerability and how it was addressed, we’ll first need to introduce the concept of DNS – including what it is and what problem it was created to solve.  Put simply, DNS stands for Domain Name System and it was created to solve the problem of how best to have people identify what servers they were and wanted to connect to. 

We specify “people” here for a reason, as computers don’t have the same issues identifying between different devices that people do.  Each computer or device on a network is identified by a unique numerical identifier that helps differentiate it from every other device on the network.  This is known as an IP address – which is short for Internet Protocol address. 

For computers, servers, routers, and other network devices – unlike for people – identifying between two different devices with two different IP addresses is easy, such as identifying between one device with an IP of 123.123.123.123 and another with an IP of 123.123.123.124.  However, for people it’s different - if one of those IPs was used for accessing Facebook and the other used for accessing your bank’s website, how easily would you be able to tell from memory which to type in to access them?  How confident would you be that you had remembered the right IP for each different website you needed to access? 

That’s why an easier way of identifying between systems was created, one that is much easier for people to identify between, that being DNS, wherein grammar-based “domain names” are used to identify servers and services instead of IP addresses directly.  In this new system, instead of needing to know the unique IP address for each service you wanted to access, a system would be created that would allow you to type out a much more understandable address – a human-readable address such as micron21.com – and then have your computer do the work translating this into the IP address that ultimately points through to our systems.

What is the vulnerability that DNS is susceptible to?

Unfortunately, much like with the earliest forms of email, DNS – without some form of protection – is susceptible to “man-in-the-middle” attacks.  A “man-in-the-middle” attack is one wherein when a user is interacting with or requesting information with a system, the information is – unknowingly to the user – either viewed or modified in transit.  Within DNS, a system wherein domain names are requested and then IP addresses are returned for your devices to connect to, a “man-in-the-middle” attack could intercept that request and return a different IP, one controlled by the attacker.

This isn’t just limited to cyber-criminals, but has also been used by state-actors to restrict access to particular domains.  For example, one of the most well-known cases of nation-state censorship of the internet, that of China’s “Great Firewall” (GFW), uses DNS spoofing and cache poisoning to return alternate IP addresses for well-known sites.  This includes major platforms such as Facebook, Twitter, and Dropbox – with the GFW interrupting requests for these sites and redirecting user to alternate government-approved sites instead.

As you can see, without some way of verifying that the DNS response you’ve received - and ultimately the IP address within that response - is the correct one, then not only is DNS spoofing possible, but it’s also undetectable to the end-user. 

When did things start to change?

When DNS was designed back in the 1980s, the primary focus – as with much of the internet - was on functionality rather than security.  However, this changed when in the 1990s it was discovered - by security researchers at the time, such as engineers in the Internet Engineering Task Force (IETF) and Computer Science Professor Steven M. Bellovin – that DNS was vulnerable to the previously mentioned DNS spoofing attacks, also known as DNS cache poisoning. 

However, it wasn’t until 2008 that action against this vulnerability really starting gaining momentum, with a demonstration of a cache poisoning attack by security researcher Dan Kaminsky, in what is now known as the “Kaminsky Bug”.  In this bug he demonstrated a flaw in DNS that allowed attackers to guess the transaction ID in DNS responses, due to the limited possible number of transaction ID combinations.  This allowed attackers to flood DNS resolvers with fake DNS responses with randomised transaction IDs.  If the ID matched the ID of a recently made DNS request by the resolver, it would accept it as legitimate and then cache it for future requests by other users, directing them to whichever IP address the attacker had specified.

That particular bug was made much harder to exploit via security updates that were applied shortly afterwards. These security updates used port randomisation and other techniques to increase the authentication of responses, but it demonstrated that some mechanism for verifying the veracity of DNS responses was needed within DNS, which as a result lead to the increased adoption of DNSSEC.

What is DNSSEC?

DNSSEC stands for Domain Name System Security Extensions. As the name suggests, it extends the original DNS to increase its security, specifically solving the veracity verification problem.  It does this by adding cryptographic signatures to existing DNS records, stored inside the DNS zone alongside other common record types (such as A, CNAME, MX, and more).  

Much like other public/private key cryptographic authentication methods, by checking these DNS zone responses using the public ally available key, you are able to verify that the response is legitimate and came from the authoritative name-server for that request, preventing man-in-the-middle/DNS spoofing attacks.  However, if in-transit you believe that the zone is being interfered with, how do you establish that the public key that you’ve received from that very same zone is also valid?  The answer is in the chain of trust.

As we’ve covered in our previous Deep Dive - What is DNS? article, every DNS query involves a chain of requests to different nameservers that each know where next to send the request to retrieve the information you’re after.  With regards to DNSSEC and the chain of trust, you’re able to verify that the public key from a name-server is valid by comparing it to an associated hashed version of the key in the parent’s name-servers above it, which flows all the way up to the root name-servers.  Each nameserver in the chain is able to validate that the keys contained in its child’s nameservers are valid, establishing trust. 

For those interested and are after a more in-depth breakdown of how DNSSEC is implemented at a technical level, we recommend taking a look at this How does DNSSEC work? article from Cloudflare.

Why is DNSSEC important?

As DNSSEC is required to ensure that your domain isn’t susceptible to DNS spoofing, and it’s something we highly recommend you implement to protect your visitors.  It’s not too difficult to implement, and without it you’re leaving your domain open to potentially being pointed to external maliciously crafted phishing websites.

However, DNSSEC is not something that’s implemented by default. It requires you to opt-in by taking proactive steps to set it up – which is why we highly recommend all our clients look into implementing it in order to protect themselves and their visitors.

How do I implement DNSSEC?

The way to implement DNSSEC on your domain will vary depending on your domain registrar and your DNS hosting environment, so we recommend asking your provider for their specific recommendations.

For all of our readers using our Shared Web Hosting (SWH) services, here are the steps to get this implemented on your domains DNS zone:

1. Log into your cPanel hosting environment.
2. Navigate to the "Zone Editor" tool in the "Domains" category.
3. Find the domain you'd like to add DNSSEC to in the list and click the "DNSSEC" button.
4. Click the "+Create Key" button.
5. You can choose to customise the settings by clicking the "Customize option".  However, we only recommend doing so if you have been instructed to do so.
6. Click the "Create" button to complete the setup of DNSSEC.
7. On the "DNSSEC Key Details" page, note down the following information just below and email it to the Micron21 Support team so that they can finalise the configuration.
   1. Domain Name:
   2. Key Tag:
   3. Digest Type: We suggest using SHA-256 (Algorithm 2) unless otherwise instructed.
   4. Digest: Ensure you copy the full code in plain text using the "Copy" button.
8. We'll reach out to you once the changes have been completed.

Have any questions about DNSSEC?

If you would like to learn more about DNSSEC or security more generally, let us know!  We’re more than happy to have a chat about how to help improve the security on your domains as well as improve your cybersecurity posture more generally.

You can reach us on 1300 769 972 (Option #1) or via email at sales@micron21.com.