Wondering whether your DNS is secure? The honest answer for most domains is partly, and this self-audit shows you exactly where the gaps are. Securing DNS means four distinct things: your zone is signed with DNSSEC so answers cannot be forged, your own queries travel over encrypted DNS so nobody can snoop or tamper, your nameservers are not an open resolver that strangers can abuse, and your published records contain no leaks or dangling entries. This guide walks each check and tells you how to fix what fails.
What "secure DNS" actually covers
People use the phrase loosely, so it helps to separate the layers. DNSSEC protects the integrity of answers about your domain, proving to resolvers that a response really came from you and was not altered in transit. Encrypted DNS (DNS over HTTPS or DNS over TLS) protects the confidentiality of your own lookups from the network you are on. Resolver hygiene is about not running a server that others can weaponize. And record hygiene is about not publishing things that help an attacker. A domain can be strong on one layer and wide open on another, which is why a single-number security score is misleading.
The four-part DNS security self-audit
| Layer | What it protects | How to verify |
|---|---|---|
| DNSSEC | Integrity of answers about your domain | Confirm a DS record at the registry and a validating chain |
| Encrypted DNS | Confidentiality of your own queries | Test that the browser or OS uses DoH or DoT |
| Resolver exposure | Prevents abuse of your servers | Confirm your nameservers do not answer recursive queries for strangers |
| Record hygiene | Limits information an attacker can use | Scan for private IPs, stale CNAMEs, and over-broad SPF |
This is a check of what you already have running, which is different from setting a new domain up from scratch. If you are configuring a fresh domain, a setup-oriented hardening guide is the better starting point; this page is the audit you run on live infrastructure.
Step 1: confirm DNSSEC is actually validating
DNSSEC is only protecting you if the full chain of trust validates, not merely if you clicked enable somewhere. The parent zone must publish a DS record that matches your DNSKEY, and your records must carry valid RRSIG signatures. A common failure is enabling signing at the DNS host without ever adding the DS record at the registrar, which leaves the zone signed but unvalidated. The DNSSEC basics guide explains how DS, DNSKEY, and RRSIG connect. Verify the chain end to end rather than trusting a toggle.
Step 2: test your encrypted DNS
Encrypted DNS stops the network between you and your resolver from reading or altering your lookups. Browsers and operating systems increasingly default to DNS over HTTPS, but silent fallback to plaintext is common when the encrypted path fails. Confirm your resolver is genuinely receiving queries over an encrypted channel rather than quietly downgrading. The guide on encrypted DNS covers how DoH and DoT differ and what each protects.
Step 3: check you are not running an open resolver
An open resolver answers recursive queries for anyone on the internet. Attackers use open resolvers to amplify denial-of-service attacks, and running one can get your IP blocklisted. Authoritative nameservers for your domain should answer only authoritative queries about your zones, never recursive queries on behalf of random clients. Confirm that your public-facing DNS servers refuse recursion from outside your network.
Step 4: scan your records for leaks
Published DNS can quietly reveal more than you intend. Watch for these.
- Private IP addresses in public A records, which expose internal network structure.
- Dangling CNAMEs pointing at decommissioned cloud resources an attacker could claim and take over.
- Over-broad SPF records that authorize far more senders than you use, weakening email authentication.
- Forgotten test or staging hosts that still resolve and may run outdated software.
Run the whole audit at once
- Enter your domain in the Valla domain health check to grade DNSSEC, delegation, and mail records in one pass.
- Review the DNSSEC result and confirm a matching DS record exists at the registry.
- Test your browser and OS to confirm encrypted DNS is active and not falling back.
- Verify your authoritative servers refuse outside recursion.
- Walk the record list for private IPs, dangling CNAMEs, and over-broad SPF, and remove anything stale.
Frequently asked questions
How do I know if my DNS is secure?
Check four things: DNSSEC validates end to end, your own queries use encrypted DNS, your nameservers are not an open resolver, and your records contain no leaks. The Valla domain health check grades the DNSSEC and record side for you in one pass.
Does DNSSEC encrypt my DNS traffic?
No. DNSSEC authenticates answers so they cannot be forged or altered, but the queries themselves still travel in the clear. Encryption of your lookups is a separate layer provided by DNS over HTTPS or DNS over TLS.
What is an open resolver and why is it a risk?
An open resolver answers recursive DNS queries for anyone on the internet. Attackers abuse open resolvers to amplify denial-of-service attacks, and running one can get your addresses blocklisted. Authoritative nameservers should refuse recursion from outside clients.
My DNS host says DNSSEC is on, so am I protected?
Not necessarily. Signing at the DNS host does nothing until the matching DS record is published at your registrar to complete the chain of trust. Verify the full chain validates rather than trusting the enable toggle alone.
Can bad DNS records be a security problem even if everything resolves?
Yes. Private IPs in public records leak internal structure, dangling CNAMEs invite subdomain takeover, and over-broad SPF weakens email authentication. These issues cause no visible resolution failure, so they persist until an audit surfaces them.
Ready to see where you stand? Run your domain through the Valla domain health check and turn a vague worry into a concrete fix list.