Secure DNS Provider: Choosing a Resolver and Protecting Your Own Domain

There are two completely different questions hiding behind this search, and mixing them up is why the answers you find never quite fit: securing the DNS you look things up with, and securing the DNS that answers for a domain you own.

The first is about privacy and filtering on the resolver side. Your device asks a resolver where a hostname lives, and whoever runs that resolver sees every domain you visit. The second is about authority. Someone else’s device asks where your domain lives, and if an attacker can change or forge that answer, they own your traffic, your certificates and your email.

Both matter. They involve different products and different controls, so this covers each in turn.

The resolver side: who sees your queries
Filtering resolvers, and where they stop working
The authoritative side: your own domain
DNSSEC, and an honest account of its limits
The records that protect your name from being used elsewhere
What to actually do this week
How this fits the rest of the stack
FAQ

The resolver side: who sees your queries

Every hostname you visit becomes a DNS query, and by default that query is unencrypted and goes to whichever resolver your network handed you, usually your internet provider’s.

That is a complete browsing history in plain text, visible to the resolver operator and to anyone in a position to watch the wire. Encryption fixes the second problem and moves the first to whoever you choose instead.

Three transports, in the order they arrived:

DNS over TLS on port 853. Encrypted, on a dedicated port, which makes it easy to identify and easy for a network to block.
DNS over HTTPS on port 443. Encrypted and indistinguishable from ordinary web traffic, which is either the feature or the problem depending on whether you are the user or the network administrator.
DNS over QUIC. The newest, lower latency, less universally supported.

The choice between operators comes down to the logging policy and who audits it. Encryption stops the network from reading your queries; it does nothing about the resolver, which reads all of them by design. A resolver promising no logs is making a policy commitment, and the meaningful differentiator is whether an independent auditor has checked.

Worth naming the trade honestly: switching to a public resolver moves your query history from your provider to a company that is usually better resourced and more accountable. It does not make the history disappear.

Filtering resolvers, and where they stop working

Some resolvers block known malicious domains before your device connects. This is genuinely effective against phishing links, malware callbacks and a good share of tracking, and it costs nothing to enable at the network level.

It is also easy to overestimate. A filtering resolver blocks by domain name, which means:

Content reached by address rather than name is unaffected.
An application shipping its own resolver, which many browsers now do, bypasses your network setting entirely.
Malicious content on a legitimate hosting domain is not blocked, because the domain is not malicious.
New domains are blocked only after somebody classifies them, and phishing infrastructure rotates quickly.

Treat it as one cheap layer, not a control you rely on. On a network you administer, enforce it: block outbound port 53 to everything except your chosen resolver, otherwise a device that ignores your setting simply goes elsewhere.

The authoritative side: your own domain

This half is where the actual business risk lives. If somebody changes the DNS records for a domain you own, they can serve your website, obtain a valid certificate for your name, and receive your email. Domain hijacking is quiet, complete and hard to reverse quickly.

The controls, in the order worth doing them:

Multi-factor authentication on the registrar account. This is the single highest-value control in the list and it takes two minutes. Every hijacking story starts with registrar account access.
Registrar lock. A status that blocks transfers until you deliberately unlock. Verify it is on rather than assuming.
A shared, monitored contact address. A domain tied to one person’s inbox goes missing when that person does, and expiry notices go to a mailbox nobody reads.
Auto-renew on, and the payment card current. Domains expire and are re-registered by others. It is a boring failure and it is permanent.
Access control on the DNS provider. Separate accounts, least privilege, and audit logging. Records get changed by insiders and contractors far more often than by attackers.

DNSSEC, and an honest account of its limits

DNSSEC signs DNS responses so a validating resolver can detect a forged answer. It addresses cache poisoning and on-path tampering, which are real if uncommon attacks.

Enabling it is usually two steps: turn on signing at your DNS provider, then publish the resulting DS record at your registrar. The second step is the one people forget, and without it the chain of trust is not established and you have gained nothing.

Two honest caveats. First, DNSSEC provides authenticity, not confidentiality; queries and answers are still readable. Second, it is a genuine footgun. A signing key that expires or a DS record that no longer matches makes your domain disappear entirely for validating resolvers, which is a harder outage than most because half the internet can reach you and half cannot.

If you enable it, monitor the signature validity the way you monitor a certificate expiry, from outside your own infrastructure.

The records that protect your name from being used elsewhere

Three record types stop other people abusing your domain, and they are cheap to publish.

; Which hosts may send mail as you. Everything else is unauthorised.
example.com.  IN TXT  "v=spf1 include:_spf.provider.example -all"

; What receivers should do with failures, and where to report.
_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

; Which certificate authorities may issue for this domain.
example.com.  IN CAA  0 issue "letsencrypt.org"

SPF and DMARC stop your domain being used for phishing, which protects your customers and your deliverability. Start DMARC at p=none to collect reports, read them for a few weeks, and only then move to p=reject once you know every legitimate sender is covered. Going straight to reject silently drops mail from a system you forgot about.

A CAA record limits which authorities may issue certificates for your domain, which narrows the mis-issuance surface considerably for the cost of one line.

One more that matters and is often missed: remove stale records. A CNAME pointing at a service you no longer use is a subdomain takeover waiting to happen, because whoever claims that name at the provider inherits your subdomain and can serve content under it. Audit your zone for records pointing at things you have decommissioned.

What to actually do this week

Ordered by risk reduced per minute spent:

Turn on multi-factor authentication at your registrar and confirm the registrar lock is enabled.
Check the domain expiry date and that auto-renew is on against a card that has not expired.
Audit the zone for records pointing at decommissioned services.
Publish SPF and DMARC at p=none, then tighten once the reports are clean.
Add a CAA record naming the authorities you actually use.
Set an encrypted resolver on your own devices and network.
Consider DNSSEC, and only enable it if you will monitor it.

The first two take five minutes and remove most of the realistic risk. The rest is worth an hour. The custom domains documentation covers the records involved in pointing a domain at a deployed service, which is the next step once the domain itself is locked down.

How this fits the rest of the stack

DNS is the layer where a small mistake has an outsized blast radius, and it sits alongside the certificate handling and the routing that make a deployed service reachable at all. Getting those to be defaults rather than tasks is worth something concrete, and the RunxBuild hosting calculator is the quickest way to see what the rest of a deployment costs once the domain and its certificate are handled as part of the setup.

Useful related references:

FAQ

Does using an encrypted DNS resolver make me anonymous?

No. It stops your network operator and anyone on the path from reading your queries, but the resolver you switch to sees all of them by design. You are choosing who holds your query history, not eliminating it. Read the operator’s logging policy and check whether it has been independently audited.

Is DNSSEC worth enabling?

It depends on whether you will monitor it. DNSSEC protects against forged responses, which is a real if uncommon attack. It also fails hard: an expired signature or a mismatched DS record makes your domain unreachable for validating resolvers. Enable it if you will monitor signature validity externally, and skip it if you will not.

What is the single most important DNS security control?

Multi-factor authentication on your registrar account, followed by confirming the registrar lock is enabled. Domain hijacking almost always begins with registrar account access, and these two controls take a couple of minutes between them.

What is a subdomain takeover?

It happens when a DNS record points at a third-party service you no longer use. Someone else claims that resource at the provider and inherits your subdomain, letting them serve content under your name and often obtain a valid certificate for it. Audit your zone regularly and delete records for anything decommissioned.

Should I use my registrar for DNS hosting too?

Either is defensible. Keeping them together means one account to secure and one place to look; separating them means a compromise of one does not immediately give control of the other. What matters more than the choice is that both accounts have multi-factor authentication and that access is not tied to a single person’s inbox.