DNS Protection

What is DNS protection?

DNS protection is the set of controls that keep the Domain Name System trustworthy and available: protecting your domain's records from tampering, making sure resolvers return genuine answers, keeping name servers up under load, and filtering lookups to known-bad domains. DNS translates names such as example.com into IP addresses, so if it is hijacked, poisoned or unreachable, users end up at the wrong server or nowhere. No single feature covers all of this; each control addresses one risk.

What can go wrong

• DNS hijacking: an attacker changes your records or name server delegation, usually through a stolen registrar or DNS provider login, and sends traffic to their own servers.
• Cache poisoning: forged answers get stored in a resolver's cache, so its users are sent to the wrong address until the entry expires.
• Availability attacks: floods of queries overwhelm name servers or are reflected at a victim. See DNS DDoS attacks and DNS amplification attacks.
• Malicious lookups: users or malware resolve phishing, malware or command-and-control domains.
• Eavesdropping: plain DNS queries are readable on the network path.

Controls, and what each one does and does not do

Protect the account that edits your records

CISA's advisory on DNS infrastructure hijacking recommends changing passwords on accounts that can modify DNS records, enabling multifactor authentication on registrar accounts, auditing public DNS records and searching for certificates issued for your domains (CISA AA19-024A). A registry or registrar lock adds protection against unauthorized transfers or changes.

DNSSEC

DNSSEC signs DNS data so validating resolvers can check where an answer came from and that it was not altered (RFC 4033). It also proves that a name does not exist. It does not provide confidentiality, and RFC 4033 states that it provides no protection against denial of service attacks. It also does not stop hijacking through a stolen account, because the attacker can publish valid signed records.

Encrypted DNS (DoH and DoT)

DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858, port 853) encrypt queries between a client and its resolver, which stops on-path eavesdropping and tampering. They do not by themselves validate the answer: RFC 8484 notes that DoH does not provide response integrity and that DNSSEC is a separate mechanism. The resolver operator still sees your queries.

Resolver hardening

If you run a recursive resolver, do not leave it open to the whole internet. RFC 5358 describes how to stop default-configured recursive servers from being used as reflectors in denial of service attacks. Restrict recursion to your own clients and apply response rate limiting on authoritative servers.

Availability for your own zone

Use at least two name servers on separate networks, ideally with a provider that spreads them across locations, and set TTLs deliberately: short enough to change fast, long enough to survive a provider hiccup. The wider approach is covered in how to stop DDoS attacks.

Protective DNS filtering

A filtering resolver blocks lookups of domains known for phishing or malware. It reduces exposure for users but does nothing for the integrity of your own zone.

Example

A company enables MFA and a registrar lock, signs its zone with DNSSEC, runs two independent authoritative providers and sets an alert on any change to its A and MX records. If an attacker steals a password, the lock and the alert shrink the window. If one provider is hit by a flood, the other keeps answering.

Common mistakes

• Believing DNSSEC protects against DDoS. It does not, as RFC 4033 says explicitly.
• Believing DoH makes lookups tamper-proof end to end. It protects the hop to the resolver only.
• Leaving registrar accounts on shared passwords with no MFA, the easiest route to hijack.
• Running an open recursive resolver that attackers can use as a reflector.
• Keeping all name servers with one provider or on one network.
• Letting DNSSEC signatures or DS records expire or mismatch. Validating resolvers then return failures, and the domain looks down.

DNS protection, testing and monitoring

You cannot protect what you do not watch. LoadFocus API monitoring includes DNS monitors with record checks and alerts: they confirm your records resolve to the right values from 25 regions, which also catches propagation problems after a change. LoadFocus is a monitoring and testing tool, not a DNS protection or security product. For tool options, see best API monitoring tools, and for the general practice network monitoring.

FAQ

What is the difference between DNS protection and DNSSEC?

DNS protection is the whole set of measures. DNSSEC is one of them: it authenticates DNS data and detects tampering, but it does not encrypt queries or defend against denial of service.

Does DNSSEC stop DDoS attacks?

No. RFC 4033 says DNSSEC provides no protection against denial of service attacks. Availability comes from redundancy, capacity, rate limiting and a well-run resolver setup.

What is DNS over HTTPS and is it enough?

DNS over HTTPS sends DNS queries inside HTTPS to a resolver, which hides them from the local network. It does not validate answers or protect your domain's records, so it complements DNSSEC and account security rather than replacing them.

How do I prevent DNS hijacking?

Secure the registrar and DNS provider accounts with unique passwords and multifactor authentication, enable a registrar lock, audit your records regularly and alert on changes.

How do I know if my DNS records changed unexpectedly?

Monitor them. A DNS check that compares the resolved values with what you expect, run on a schedule from several locations, alerts you when they differ.