DNSSEC: The Domain Security Step Many IT Providers Overlook

Technical article for MSPs and IT engineers

Over the past few weeks, I have been enabling and reviewing DNSSEC across several client domains. When I raise the subject with other engineers, it often becomes clear that knowledge of DNSSEC is limited. The conversation then tends to move elsewhere fairly quickly.

DNSSEC addresses a particular weakness in the way domains are resolved. When someone enters your domain into a browser, they rely on DNS to return the correct address. Without signed DNS responses, those answers can potentially be forged.

If an attacker successfully poisons a DNS lookup, they may be able to direct customers towards a convincing imitation of your website. Where HTTPS warnings are absent, bypassed or ignored, visitors could enter payment details or other sensitive information without realising they have reached the wrong destination.

DNSSEC adds digital signatures to DNS records. This allows validating resolvers to confirm that the response originated from the genuine DNS zone and has not been altered or supplied by someone impersonating it.

Understanding what DNSSEC does not do is equally important, as this is where much of the confusion begins. DNSSEC does not encrypt traffic; that remains the role of TLS. It does not replace HTTPS, nor does it replace email security measures. SPF, DKIM, DMARC and MTA-STS each address separate areas of email authentication and protection.

DNSSEC is one security layer, designed to solve one defined problem, and it needs to be configured correctly.

With Amazon Route 53, the basic process is relatively straightforward:

1. Create a customer-managed AWS KMS key.
2. Create a key-signing key for the hosted zone.
3. Publish the resulting DS record through the domain registrar.
4. Confirm that the hosted zone is correctly signed and validating.

Preparing the IAM account is an important part of the work.

During the key-creation process, almost every stage exposed an additional permission that my account did not yet have. I would grant the required permission, move to the next step and then repeat the process when another restriction appeared.

The KMS key policy also needs careful attention. Linking the wrong key or publishing an incorrect DS record may not create a conventional security incident, but it can make the domain unavailable to validating resolvers. The outcome for users can be just as serious.

For fellow MSPs and internal IT teams, DNSSEC still appears to be widely overlooked. Implementation is not always consistent because registrars and registries have different processes and limitations. Support for DNSSEC algorithms, digest types and DS record management can vary between providers.

We have seen organisations invest heavily in broader IT security and still suffer incidents through DNS settings that had never been properly reviewed.

DNSSEC will not make a domain impossible to compromise. It does, however, make DNS spoofing and cache-poisoning attacks significantly more difficult. A properly configured business domain should include a signed DNS zone. At this point, “we overlooked it” or “we did not know about it” is becoming increasingly difficult to defend.

Some useful validation commands:

# Check DS record publication

dig DS example.com @8.8.8.8 +short

# Verify the DNSKEY record

dig DNSKEY example.com @8.8.8.8 +dnssec

# Validate the complete chain

delv @8.8.8.8 example.com A +rtrace

For a visual analysis of the full DNSSEC chain, DNSViz is also useful.

Windows users may first need to install Windows Subsystem for Linux before running these commands:

wsl --install

If you manage domains for clients and are currently working through DNSSEC configuration or validation, it would be useful to compare notes.