What is DNSSEC (Secure DNS)?

DNSSEC, or Domain Name System Security Extensions, adds cryptographic authentication and integrity protection to DNS data. A DNSSEC-validating resolver can check that a DNS answer genuinely came from the signed zone and has not been altered since it was signed. The most important distinction is that DNSSEC does not encrypt DNS queries or hide which domains you look up.

DNSSEC is therefore about trusting the answer, not making the question private. A correctly validated answer can protect against forged DNS data and cache-poisoning-style attacks, while encrypted DNS transports solve a different problem.

How does DNSSEC work?

DNSSEC works by digitally signing sets of DNS records. The zone owner keeps the signing private key secret and publishes the corresponding public key in DNS. A validating recursive resolver retrieves the DNS data, its signature and the keys needed to verify that signature.

1. The resolver asks for a DNS record such as an A or AAAA record.

2. The signed zone returns the record set together with an RRSIG digital signature.

3. The resolver retrieves the zone's DNSKEY public key records.

4. It verifies the signature over the DNS data using the appropriate DNSKEY.

5. It follows DS records in parent zones to establish a chain of trust towards a configured trust anchor, normally the DNS root.

6. If the cryptographic checks succeed, the answer is treated as secure. If a signed answer fails validation, it is treated as bogus and normally withheld from the client.

The IETF's DNSSEC specification describes this as origin authentication and integrity protection for DNS data. It explicitly states that DNSSEC does not provide confidentiality.

The DNSSEC chain of trust

The clever part of DNSSEC is not simply signing one domain. A resolver also needs a trustworthy way to decide whether the public key used for validation is itself legitimate.

• Trust anchor: the starting point the validating resolver already trusts, commonly the DNS root key.

• DNSKEY: publishes public keys for a DNS zone.

• DS record: lives in the parent zone and identifies key material for the delegated child zone.

• RRSIG: contains a digital signature covering a DNS record set.

• NSEC or NSEC3: provides authenticated denial of existence so a resolver can validate that a requested name or record type does not exist.

For a signed domain beneath a signed top-level domain, the resolver can validate each link from the root through the parent zone to the domain. If the required chain is broken or cryptographically inconsistent, the resolver cannot classify the signed answer as secure.

DNSSEC vs encrypted DNS

DNSSEC and encrypted DNS are complementary, not interchangeable. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS traffic between a client and its resolver. DNSSEC authenticates signed DNS data from the authoritative DNS hierarchy.

• DNSSEC: protects authenticity and integrity of signed DNS data. It does not conceal DNS queries.

• DoH: carries DNS inside HTTPS, protecting the client-to-resolver transport against passive observation and modification on that path.

• DoT: carries DNS over TLS, again protecting the client-to-resolver transport.

• Using encrypted DNS does not automatically mean DNSSEC validation is being performed.

• Using DNSSEC does not automatically mean the client-to-resolver query is encrypted.

This is similar to the broader distinction between authenticity and encryption: cryptographic tools can solve different security problems even when they are used together.

What does DNSSEC protect against?

DNSSEC is designed to let a validating resolver detect forged or modified DNS data for signed zones. That matters because ordinary DNS was not designed with cryptographic origin authentication.

• Forged DNS responses where an attacker attempts to substitute different DNS data.

• Cache poisoning where false records are inserted into a recursive resolver's cache.

• Tampering with signed DNS data between the authoritative source and validating resolver.

• False claims that a signed name or record type does not exist, when authenticated denial of existence is correctly used.

What DNSSEC does not protect against

DNSSEC is not a universal DNS security layer. It has deliberately limited goals.

• Privacy: DNSSEC does not encrypt the query name or response.

• A malicious or compromised authoritative source: DNSSEC proves that data matches what the signed zone published, not that the zone owner's intended destination is safe.

• Denial of service: DNSSEC does not prevent DDoS attacks and adds cryptographic work and larger DNS responses.

• Web content security: a valid DNSSEC answer does not prove that the website itself is legitimate, malware-free or correctly configured.

• Every DNS lookup: unsigned zones cannot provide the same cryptographic chain of validation as signed zones.

Secure, insecure and bogus DNSSEC answers

A validating resolver commonly needs to distinguish three important states rather than simply 'DNSSEC on' or 'DNSSEC off'.

• Secure: the resolver can validate the signed answer through an acceptable chain of trust.

• Insecure: the resolver has authenticated evidence that the relevant delegation is not signed, so ordinary unsigned DNS data can still be returned.

• Bogus: DNSSEC was expected, but the cryptographic validation failed. A validating resolver normally returns an error such as SERVFAIL instead of passing potentially false data to the client.

Why DNSSEC can break a domain when configured incorrectly

DNSSEC deliberately fails closed for bogus signed data. This is good for security, but it means a configuration error can make a domain appear unavailable to users behind validating resolvers.

• A DS record at the parent points to old or incorrect key material.

• The authoritative DNS provider changes but the old DS record remains at the registrar or registry.

• A key rollover is performed incorrectly.

• Signatures expire or are not refreshed correctly.

• Authoritative servers return inconsistent DNSSEC data.

• DNS responses are damaged or truncated by broken network equipment or DNS middleboxes.

A particularly important operational lesson is that changing DNS providers while leaving an incompatible DS record in the parent can cause validating resolvers to reject the new provider's answers.

Techie Broadband diagnostic sequence for DNSSEC problems

If a domain works through one resolver but fails through another, DNSSEC is one of the checks worth making. Do not assume the broadband line is faulty simply because a website fails to resolve.

1. Compare the domain using more than one recursive DNS resolver.

2. Check whether the failure is DNS-specific rather than a general connectivity problem.

3. Inspect the domain's DS record at the parent and DNSKEY records at the authoritative servers.

4. Confirm that the DS digest matches the intended DNSKEY and algorithm.

5. Check RRSIG validity periods and whether the relevant record sets validate.

6. Trace the chain of trust from the root through the TLD to the domain.

7. If a DNS provider was recently changed, verify that the DS record was removed or updated in the correct sequence.

8. After correcting the DNSSEC configuration, allow for cached DNS records and TTLs before assuming the fix has failed.

Does DNSSEC matter on UK broadband?

DNSSEC is independent of whether your access connection is FTTP, FTTC, cable, fixed wireless or mobile. The relevant question for an end user is whether the recursive resolver handling the query performs DNSSEC validation and whether the requested domain is correctly signed.

If you use an ISP-supplied resolver, validation behaviour depends on that resolver service. If you choose a third-party or self-hosted resolver, its configuration determines whether DNSSEC validation is performed. Changing to a different resolver can therefore change how a broken DNSSEC domain behaves without changing anything about the physical broadband connection.

DNSSEC and PKI are related ideas, but not the same system

DNSSEC uses public-key cryptography and a hierarchical chain of trust, so it shares ideas with Public Key Infrastructure (PKI). However, the Web PKI used for TLS certificates and the DNSSEC hierarchy use different trust models, records, authorities and operational processes.

Practical example: why a bad DS record causes SERVFAIL

Imagine a domain moves from DNS Provider A to DNS Provider B. Provider A's DNSKEY was represented by a DS record in the parent zone. The nameservers are changed to Provider B, but the old DS record is left behind.

1. A validating resolver sees the DS record in the parent and therefore expects a matching DNSSEC chain.

2. It queries Provider B and receives Provider B's DNSKEY and signed records.

3. The old DS record does not authenticate Provider B's key.

4. Validation fails, so the answer is classified as bogus.

5. Instead of returning the address record, the resolver normally returns SERVFAIL.

A non-validating resolver may still return the new DNS answer, which explains why a DNSSEC mistake can appear inconsistent between networks or resolvers.

Frequently asked questions

What does DNSSEC stand for?

DNSSEC stands for Domain Name System Security Extensions. It adds cryptographic authentication and integrity protection to DNS data.

Is DNSSEC the same as Secure DNS?

Secure DNS is an ambiguous marketing and interface term. It can refer to DNSSEC, encrypted DNS such as DoH or DoT, or a resolver with security filtering. The technologies should be named explicitly when the distinction matters.

Does DNSSEC encrypt DNS queries?

No. DNSSEC does not provide confidentiality. DoH and DoT are designed to encrypt DNS transport between a client and resolver.

Does DNSSEC stop DNS cache poisoning?

For correctly signed zones and validating resolvers, DNSSEC lets the resolver detect forged DNS data that fails cryptographic validation, which is the protection needed against cache-poisoning-style substitution of signed records.

Why can enabling DNSSEC make a website stop working?

If the DS record, DNSKEY, signatures or key rollover are configured incorrectly, validating resolvers can classify the answer as bogus and return SERVFAIL rather than potentially false DNS data.

Do I need DNSSEC if I use DNS over HTTPS?

They solve different problems. DoH protects the client-to-resolver transport. DNSSEC validates the authenticity and integrity of signed DNS data. A resolver can use both.

Key takeaway

DNSSEC makes DNS answers verifiable, not private. It adds digital signatures and a chain of trust so validating resolvers can authenticate signed DNS data and detect tampering. For privacy between your device and DNS resolver, encrypted DNS technologies such as DoH or DoT address a different part of the problem.

To explore the related technical concepts used in this DNSSEC (Secure DNS) guide, visit our broadband terminology guide.