- DNSSEC authenticates DNS answers; DNS over HTTPS encrypts the query in transit. The DoH specification states the two are independent and each still needed.
- DNSSEC provides no confidentiality at all, and a lapsed signature takes the domain down for validating resolvers while it still works everywhere else.
- Nothing is protected until the DS record lands at the registrar, which is the half of the deployment teams most often leave undone.
Two DNS security features get treated as alternatives, and they are not. DNSSEC proves an answer really came from the domain that owns it. DNS over HTTPS hides the question from anyone watching the wire. Turn on one and the other problem is still there.
The DoH specification says so itself. The two are "independent and fully compatible protocols, each solving different problems", and "the use of one does not diminish the need nor the usefulness of the other".
What each one actually does
The confusion is understandable, because both are described as making DNS "secure". They secure different things.
| DNSSEC | DNS over HTTPS | |
|---|---|---|
| Answers the question | Is this DNS answer genuine? | Can anyone see or alter what I asked? |
| Provides | Origin authentication, data integrity, and authenticated denial of existence | TLS encryption and server authentication for the query in transit |
| Protects against | Forged or tampered DNS records | Passive surveillance of your lookups, and on-path devices diverting them |
| Does not provide | Any confidentiality; the records themselves travel in the clear | Any guarantee the answer is genuine |
| Configured by | The domain owner, at the registrar and DNS host | The client or resolver, not the domain owner |
That last row is the practical divide. DNSSEC is something you switch on for a domain you own, and it protects everyone who looks that domain up. DoH is something a browser or operating system does for its own queries, and it protects the person making them. As a business you can only decide the first one for your own domain.
What DNSSEC does not do
Three assumptions are worth clearing away before anyone sells you on it.
It does not encrypt anything. The DNSSEC specifications describe protocols that "provide origin authentication of DNS data". Authentication, not confidentiality. A signed zone's records are still readable by anyone on the path; they are merely provably unaltered.
It does not keep your zone private. Authenticated denial of existence is how a resolver proves a name does not exist. The mechanism can leak the names that do. If you assumed an obscure subdomain was hidden, it may not be.
It does nothing about availability. A signed zone under a denial of service attack is exactly as unreachable as an unsigned one. DNSSEC has no bearing on uptime. A misconfigured signature makes a domain less available, not more: validating resolvers refuse a bad answer rather than pass it on.
The failure mode that catches people
That last point is the one to plan around. An expired or mismatched signature does not quietly fall back to unsigned DNS. Validating resolvers reject the answer, and the domain goes dark for every user behind one, while resolving perfectly for everyone else. This is why DNSSEC belongs to whoever owns the renewal calendar, not to whoever set it up once.
Where the trust actually comes from
A signed zone is only trusted because its parent vouches for it. The parent zone holds a DS record pointing at your signing key. That link is what a resolver walks up to reach a trust anchor it already has. Publishing signatures without getting the DS record in at the parent achieves nothing, because nothing connects your zone to the chain.
If you have already set up SPF, DKIM and DMARC, this is the same shape of job. Records go in DNS. The real work is who owns which half.
In practice the DS record is placed through your registrar, while the signing itself happens at your DNS host. When those are two different companies, that seam is where deployments break. Confirm who owns each half before you start.
What a small team should actually do
| Step | Who does it | Watch for |
|---|---|---|
| 1. Confirm your DNS host supports signing | You | Some budget hosts still do not |
| 2. Confirm your registrar accepts DS records | You | This is the half people forget |
| 3. Enable signing at the DNS host | DNS host | One-click on most managed hosts |
| 4. Publish the DS record at the registrar | Registrar | Nothing is protected until this lands |
| 5. Put key rollover on the same calendar as domain renewal | You | The single most common outage cause |
| 6. Leave DoH to clients | Nobody | It is not yours to configure for visitors |
If your DNS host automates signing and DS maintenance end to end, steps three and four collapse into one. The ongoing risk drops sharply. That automation is worth more than the feature itself.
Is it worth it for a small business?
Honestly: it depends on what a forged answer for your domain would cost. If your domain only serves a brochure site, the exposure is low. A misconfiguration is the bigger risk there. If it carries mail, single sign-on, or anything a customer logs in to, a forged record is a real attack path. Then signing is worth the discipline it asks for.
What is not worth doing is enabling it, ticking a compliance box, and never thinking about the keys again. That converts a security feature into a scheduled outage.
Frequently asked questions
If I turn on DNSSEC, are my visitors' DNS queries private?
No. DNSSEC provides origin authentication and integrity, not confidentiality. Query
privacy comes from the client side, through DoH or DoT, and you do not control that for
your visitors.
Does using DoH mean I can skip DNSSEC?
No. The DoH specification is explicit that its HTTPS connection "does not provide the
response integrity of DNS data provided by DNSSEC". An encrypted channel to a resolver
says nothing about whether that resolver was told the truth.
What breaks if a signature expires?
Validating resolvers refuse the answer, so the domain fails for users behind them while
working normally for everyone else. That split failure is why it is often reported late.
Who should own it internally?
Whoever owns domain renewals. The failure mode is a missed date, not a missed
configuration.
Sources
RFC 9364, DNS Security Extensions (DNSSEC) · RFC 8484, DNS Queries over HTTPS. Quoted wording on what DNSSEC provides, and on the relationship between DNSSEC and DoH, is the specifications' own.
More in this section Technology →