DNS errors and DNS security – DNSSEC, protection against DNS attacks and DNS management errors

Why DNS is critical for availability and security

The Domain Name System (DNS) is the backbone of the Internet. Every user connection to an application, service, or cloud platform begins with translating a human-friendly domain name into an IP address. Without this process, all domain-based communication would come to a halt. This makes DNS both a critical point for availability and a vector of risk in security.

DNS as the foundation of services

• Name resolution: applications and users rarely operate on IP addresses – DNS enables convenient mapping of domains to addresses.

• Chain of dependencies: recursive resolver → root servers → TLD → authoritative server → response to the client. Each element must work properly.

• Performance: DNS latency directly translates into page load times and application responsiveness.

Consequences of a single point of failure

A lack of redundancy in DNS infrastructure can mean that even a small outage cuts users off from services.

DNS in the context of security

DNS is often underestimated as a defensive component. In practice:

• Compromised DNS allows an attacker to take control of traffic and redirect it to their own servers.

• DNS attacks often bypass other security layers (firewalls, WAF) because they occur before a proper connection is established.

• Misconfigured DNS opens the door to phishing, impersonation of services, and manipulation of responses.

DNS and SLA, business continuity

For critical systems such as online banking, e-commerce platforms, or SaaS, the correct operation of DNS directly impacts:

• SLA (Service Level Agreement) – guaranteed service availability time.

• RTO and RPO – recovery time objective and recovery point objective in case of failure.

• Regulatory compliance – for example, requirements in the financial and telecommunications sectors.

DNS is not just technical name resolution, but a fundamental infrastructure service that combines availability and security. Every error or gap in this layer must be treated as a real threat to the entire organization.

The most common DNS errors and DNS management errors in configuration and zone management

Incorrect configuration of name servers is one of the main reasons for service unavailability and susceptibility to attacks. Many issues stem from seemingly minor oversights, which in practice turn into critical vulnerabilities.

Typical problems found in production environments

• Lack of redundancy and diversification
  A single NS server or no geographic distribution leads to a situation where an outage cuts users off from services.

• Lame delegations and incorrect glue records
  If the delegation points to a server that is not authoritative for the zone, or if the glue record is incorrect, resolvers cannot find the proper source.

• Incorrect SOA parameters
  Too long or too short refresh, wrong serial number, or lack of consistency between servers may lead to unsynchronized data and inconsistent responses.

• Improper TTL values
  Extremely low TTL causes excessive load on resolvers, while too high values make it difficult to quickly propagate changes.

• Problematic CNAME
  Using CNAME records at the zone apex or creating chains of references generates delays and risk of errors.

• Open zone transfers (AXFR)
  Lack of access control for zone transfers allows attackers to obtain the full list of records and analyze the system structure.

• Recursion on authoritative servers
  A classic DNS error that exposes infrastructure to amplification attacks and abuse.

• IPv6 handling issues
  Missing AAAA records, inconsistent reverse delegations, or missing PTR records reduce trust, for example, in mail servers.

• EDNS response fragmentation
  Oversized responses, lack of TCP support, and incorrect EDNS settings may lead to packet loss and hard-to-diagnose failures.

• Orphaned records
  Leftover subdomains after migrations, pointing to non-existent resources, can be taken over by attackers (subdomain takeover).

• Weak management processes
  Lack of access control to registrar panels, weak passwords, no domain lock at registrar level – these are classic DNS management errors that lead to domain hijacking.

Specific errors related to DNSSEC

• Missing DS record at the parent – no full trust chain.

• Unsynchronized RRSIG signatures or expired records – users get SERVFAIL errors.

• Failed key rollovers (KSK/ZSK) – the zone becomes unsigned or unverifiable.

Split-horizon without proper control

Incorrectly configured split-horizon leads to leakage of private records or conflicts between public and internal zones.

The most common DNS errors result not from lack of technology, but from operational negligence and poor processes. This is why regular configuration audits and automation of zone management are crucial.

Operational and business consequences of poor DNS configuration

Incorrect configuration of name servers or delegations is not only a technical issue. Every DNS error can trigger consequences that an organization will feel financially and reputationally.

The most obvious effect is service unavailability. Just one incorrect glue record, lack of server redundancy, or expired DNSSEC signatures is enough for users to see SERVFAIL or NXDOMAIN messages instead of a website. From a business perspective, this means direct revenue loss and SLA violations.

Another often underestimated area is customer trust. When a subdomain is taken over or records point to the wrong place, users start to suspect phishing or intentional deception. Rebuilding brand reputation after such incidents is usually harder and more costly than the technical fix itself.

Email systems are also affected. Inconsistent MX records, missing PTR, or misconfigured SPF/DKIM/DMARC cause messages to land in spam folders or not be delivered at all. As a result, the company loses its ability to communicate with customers and partners, and in the case of transactional services — risks losing critical operations.

Operational costs should not be ignored either. Every incident caused by DNS management errors requires IT team intervention. When errors are frequent and processes manual, technical support consumes more and more resources. Worse still, without consistent logs and monitoring, identifying the root cause takes hours, increasing losses and extending recovery time.

Regulatory risk is also significant. In regulated industries such as finance or telecommunications, downtime and DNS errors may lead not only to dissatisfied customers but also to penalties from regulators or sanctions arising from contracts.

Every DNS error should be viewed in terms of business risk. It is not just about technical correctness, but about revenue stability, brand reputation, and regulatory compliance. This is why DNS security should be an integral part of business continuity strategy.

Typical DNS attack vectors and how to recognize them — a practical guide “what to do when it happens”

DNS is a place where attackers can get the highest return on effort — by hijacking traffic, exfiltrating data, or generating spam. Below we describe the most important DNS attacks, how to recognize them in telemetry, and how to respond immediately.

1) Cache poisoning / response manipulation

What it is: fake responses inserted into a resolver’s cache, redirecting clients to malicious addresses.
How to recognize: sudden spikes in A/AAAA records pointing to new, unknown IP addresses; unexpected changes visible in passive DNS; users reporting redirections. In telemetry: increase in queries to unusual authoritative addresses.
Quick defense: DNSSEC validation at the resolver layer, monitoring passive DNS, blocking suspicious IPs in the firewall.
Note: DNSSEC makes this attack much harder, but misconfiguration can cause mass SERVFAIL.

2) Recruitment and use of open resolvers (amplification, DDoS)

What it is: attackers use open (recursive) servers to send large amounts of traffic to a victim (reflection/amplification) by using IP spoofing.
How to recognize: sudden surge in QPS from many sources; high proportion of UDP (and TCP in case of truncation); large response sizes (EDNS). In logs: many ANY queries or records producing oversized answers.
Quick defense: disable recursion on authoritative servers; in resolvers: RRL (response rate limiting), source filtering, edge rate limiting, anycast for authoritative servers.
Long-term: close open resolvers, use ACLs and TSIG for zone transfers.

3) Subdomain takeover

What it is: orphaned records point to a resource in an external service (S3, Heroku, Azure); once the original resource is removed, attackers can register the free endpoint.
How to recognize: A/CNAME records pointing to inactive or expired hosting; spike in NXDOMAIN on subdomains; sudden appearance of new certificates for a subdomain in public repositories.
Quick defense: record audits, removal of unused entries, using short TTL before migration, monitoring passive DNS and certificates.
Remediation: immediately edit/remove orphaned records, block uncontrolled creation of wildcards.

4) DNS tunneling (data exfiltration via DNS)

What it is: hiding data in query/response fields (TXT, long labels) — command and control channel or data exfiltration.
How to recognize: many queries with long, high-entropy labels; unusual TXT/NULL patterns; specific query intervals. In telemetry: growth in unique subdomains generated by a single source.
Quick defense: analyze QNAME entropy, block long/unusual record types, use DPI/IDS with DNS tunneling detection.
Long-term: block uncommon outbound record types, enforce strict recursion policies, separate internal resolvers from public ones.

5) Domain hijacking / registrar attack

What it is: compromise of a registrar account leads to changes in NS delegation or domain transfer.
How to recognize: sudden NS change in passive DNS, unauthorized DS changes, registrar/WHOIS alerts about transfer.
Quick defense: MFA and domain transfer lock at the registrar, immediate registrar contact, instant DNS rollback.
Preventive: strong registrar account security policies, escalation contacts on file.

6) Cache snooping and reconnaissance

What it is: attackers probe which records are cached in resolvers (e.g. to discover session values or internal subdomains).
How to recognize: series of queries for improbable, random names with analyzed responses; rise in NXDOMAIN from unusual sources.
Defense: QNAME minimization, response-minimization policies, limiting details in DNS responses.

Quick comparison (Attack → Fast detection → First steps)

Short, practical incident playbook (6 steps — “what to do now”)

1. Identify and block — cut off traffic to suspicious IPs/subdomains at firewalls and CDN.

2. Isolate components — separate public resolvers from internal ones; disable recursion where not needed.

3. Verify signatures and DS — check DNSSEC status and RRSIG validity.

4. Check registrar — confirm no unauthorized NS changes or domain transfers.

5. Analyze telemetry — QPS, NXDOMAIN, SERVFAIL, TCP/UDP ratio, QNAME entropy, number of unique subdomains.

6. Communicate — inform application teams, share status and remediation steps; if necessary, send notice to customers.

DNSSEC protects against fundamental manipulation (cache poisoning), but it is also a double-edged sword: misconfigured, it can cause immediate service unavailability. This illustrates the core issue: DNS security is not just about technology; it is about processes, monitoring, and readiness to react quickly.

Runbook: detection and response to DNS log anomalies

1. Spike in NXDOMAIN – potential random subdomain attack or tunneling

Goal: identify hosts generating massive amounts of non-existent names.

• BIND (querylog enabled):

  grep NXDOMAIN /var/log/named/query.log | awk '{print $8}' | sort | uniq -c | sort -nr | head


• dnstap (if used):

  dnstap-read capture.dt | grep NXDOMAIN


Check: whether a single client is generating thousands of unique subdomains in a short time.
Quick response: block the IP in the firewall or resolver; verify it is not a false positive (e.g., dev testing).

2. QNAME entropy analysis – indicates DNS tunneling

Goal: detect long, random labels in queries.

• Zeek (bro):

  event dns_request(c: connection, msg: dns_msg, query: string)
{
if (|query| > 50 && entropy(query) > 4.0)
print fmt("POSSIBLE DNS TUNNELING: %s -> %s", c$id$orig_h, query);
}


• Logstash/Elastic: add an “entropy_score” field and create alerts for values >4.5.

Check: repetitive long queries of TXT, NULL, or unusual record types.
Quick response: block records on DNS firewall (dnsdist/unbound) or apply a “drop” policy for the domain.

3. Sudden delegation change – signal of domain hijacking

Goal: monitor NS/DS records for own domains.

• dig with cron (bash):

  dig +short NS my-domain.com >> /var/log/ns-check.log
dig +short DS my-domain.com >> /var/log/ds-check.log


• Compare with previous values (e.g., using diff).

Quick response: in case of unexpected change, immediately contact registrar and enforce rollback.

4. Surge in ANY queries – classic amplification

Goal: identify sources abusing the resolver.

• BIND query log:

  grep "ANY" /var/log/named/query.log | awk '{print $5}' | sort | uniq -c | sort -nr | head


• dnstap + jq:

  dnstap-read capture.dt | jq 'select(.message.query_type == "ANY")'


Quick response:

• enable minimal-responses yes; in BIND,

• configure Response Rate Limiting (RRL),

• block top-volume source addresses.

5. Monitoring DNSSEC signature expiration

Goal: prevent SERVFAIL due to expired RRSIG.

• ldns-dane-check:

  ldns-verify-zone my-zone.zone


• Nagios/Prometheus exporter: monitors RRSIG expiration dates and alerts at <48h.

Quick response: force re-signing of the zone, verify DS at parent, confirm propagation is correct.

Practical tip: establish a baseline of normal DNS traffic (average NXDOMAIN count, record type distribution, average QNAME entropy). Without it, it is difficult to tell whether an anomaly is an attack or just unusual application behavior.

DNSSEC in practice — how to implement cryptographic trust without blocking your own services

DNSSEC is designed to protect the domain name system from fake responses. Cryptographic signatures allow the resolver to verify the authenticity of a record and reject tampered packets. This provides real protection against cache poisoning and other DNS attacks. But the same feature that provides security also makes DNSSEC unforgiving: if a signature is invalid or the DS record is missing at the parent, the entire domain becomes unavailable to users.

Where problems most often occur

In practice, administrators usually stumble in three areas:

• Inconsistent DS at the parent — the KSK is changed, but the DS record in the registry is not. The validating resolver no longer trusts the answers.

• Expired signatures (RRSIG) — lack of automatic renewal makes records appear “outdated” and they are rejected.

• Poorly planned key rollover — ZSK or KSK rollover done without a plan causes some responses to become unverifiable.

Each of these scenarios ends the same way: the resolver returns SERVFAIL, and users report that “the site is not working.”

Lesson from the market

This is not just theory. In March 2015, HBO NOW experienced availability issues among customers using validating resolvers. The cause? Misconfigured DNSSEC. Some users could not access the service at all, and the emergency solution was to disable signatures and later reimplement them properly. This showed that lack of a contingency plan can be just as dangerous as lack of DNSSEC itself.

How to implement safely

Here, processes are more important than individual configuration commands. It is worth keeping in mind a few rules:

• Automated signing — manual renewals of signatures will fail sooner or later.

• Key rollover schedule — ZSK should change more often, KSK less often, but every rollover must be synchronized with the registry.

• Monitoring critical metrics — number of SERVFAIL responses, RRSIG expiration dates, presence of DS at the parent.

• Contingency plan — who contacts the registrar, how quickly a new DS can be published, when and how to use a negative trust anchor on resolvers.

DNSSEC genuinely raises the level of DNS security, but it requires a mature approach. It is not “set and forget,” but a continuous process: automation, monitoring, rollovers, and contingency testing. The benefit is protection against some of the most dangerous DNS attacks, and the cost is the need to maintain robust procedures.

Best practices: TTL, recursion, authoritativeness, zone transfers, and split-horizon

In DNS there are no “small” settings. Innocent-looking TTL values, open recursion, or an accidentally exposed zone transfer can become the starting point of serious incidents. It’s a bit like aviation: a small mistake in the take-off checklist can lead to catastrophe. That’s why DNS management comes with the idea of operational hygiene — a set of rules that are not complicated in themselves, but demand discipline and consistency.

TTL — a strategic decision, not just a technical detail

Imagine an online store migrating to a new hosting provider. If the A record has a TTL set to 48 hours, some users will still be directed to the old infrastructure even two days after the migration. This means not only service disruption but also accounting issues: orders placed in the “old” system may never reach the new database.

On the other hand, a TTL that is too short creates unnecessary load on resolvers and authoritative servers, and at global scale — real costs. This is why companies usually apply a mixed policy:

• stable records (NS, MX, SPF) → TTL in hours or days,

• dynamic records (A/AAAA for cloud apps, load balancers) → TTL in minutes,

• during migrations → TTL temporarily lowered to ensure fast propagation of changes.

Recursion and authoritativeness — don’t mix roles

History has seen dozens of cases where an administrator left recursion enabled on an authoritative server. The result? The server became an “open resolver” and, in attackers’ hands, a machine for DDoS amplification.

Best practice is a strict separation of roles:

• authoritative servers — only answer for their zones, no recursion,

• recursive resolvers — run separately, in a controlled network, ideally restricted to queries from the organization itself.

This model not only increases security but also makes troubleshooting easier. If the resolver is choking, the problem is on the user side, not in the authoritative infrastructure.

Zone transfers — convenience vs. risk of revealing your network map

AXFR and IXFR are like backups for secondary servers. But an open AXFR is like publishing the entire infrastructure diagram. An attacker learns all subdomains, records, and service servers in seconds.

The practice is clear:

• limit transfers only to trusted addresses,

• use authentication (TSIG),

• prefer IXFR, which sends only differences rather than the entire zone.

This is one of the simplest changes that drastically reduces the risk of data leaks.

Split-horizon — two worlds in one DNS

Split-horizon is tempting: the same domain can return different answers depending on where the query comes from. Internal employees see intranet.company.com pointing to a private IP address, while external users get a completely different answer.

The problem arises when the two worlds mix. Misconfiguration can cause internal records to leak externally, giving attackers a ready-made service map. An even worse scenario is name conflicts — some users land on the “public” version of a service, others on the internal one, producing errors that are hard to track.

That’s why split-horizon requires special care:

• regular consistency tests of different views,

• a clear naming plan (so internal domains don’t collide with public ones),

• monitoring to detect record leaks.

DNS best practices may seem boring compared to flashy DNS attacks, but they form the first line of defense. TTL, recursion, transfers, and split-horizon are not “configuration details,” but decisions that define system stability and resilience. Many major incidents in history started with neglect of these basics.

Monitoring and response: logs, telemetry, alerts, and DNS security integrity tests

There is no secure DNS without monitoring. Even the best-configured zone can in an instant become the target of a DNS attack, and the administrator finds out about the problem… from frustrated users. That is the worst-case scenario. This is why true DNS security starts with a proactive approach: continuous visibility, measurement, and rapid response.

DNS as the network’s “black box”

DNS logs record attempted abuses, early signs of infection, and anomalies that reveal data tunneling. Administrators often say, “who controls DNS, sees everything.” But seeing is not enough — you need to know what to look at.

What to monitor daily

Instead of collecting all data chaotically, it is better to focus on a few key metrics:

• Response quality: share of NXDOMAIN, SERVFAIL, REFUSED codes – spikes signal outages or attacks.

• Response time: increased latency is the first sign of issues with authoritative servers.

• Query size and characteristics: long, high-entropy labels point to possible tunneling.

• DNSSEC validation: time to RRSIG expiration, presence of DS at the parent.

Each of these indicators should have a defined alarm threshold — otherwise, monitoring turns into collecting statistics that no one uses.

“Red flag” scenarios

• NXDOMAIN flood – may indicate a random subdomain attack designed to overwhelm resolvers.

• Sudden rise in SERVFAIL responses – usually DNSSEC signature problems or incorrect delegation.

• Disproportionately high share of TCP queries – possible amplification attacks, UDP congestion, or EDNS issues.

• Rapid increase in unique subdomains – a classic symptom of tunneling or scanner activity.

Integrity tests – crash tests for DNS

Monitoring alone is not enough. You need to actively check whether everything works as intended:

• Zone linting – automated tools detect orphaned records, incorrect NS, or SOA issues.

• Recursion simulation – tests from different locations show whether answers are globally consistent.

• Split-horizon control – verification that internal records are not “leaking” into the public view.

Response culture – from alert to action

The biggest difference is made not by detection itself, but by the speed of response. That is why SOC/NOC teams should operate with runbooks:

• Who receives the alert – is there an on-call engineer, or does everyone wait until “someone notices”?

• What is checked first – e.g., DS status, resolver logs, test from an external vantage point.

• Who is informed – application teams, helpdesk, registrar.

• How the issue is communicated to customers – not every DNS error needs a technical explanation, but lack of information is even worse.

Remediation plan and continuous audit: how not to fall into the same DNS errors twice

The biggest sin in DNS management is not the error itself, but the failure to learn from the incident. Organizations often put out the fire, restore the service, and then… go back to old practices. The result? Another crisis a month later. That’s why an effective strategy is not one-off fixes, but continuous audit and automation.

Why audits matter

DNS changes are often small and frequent: a new subdomain, hosting migration, enabling DNSSEC, split-horizon testing. Each such change can introduce new risks. Regular audits allow problems to be caught before customers do. It’s like a car inspection — better to replace brake pads in the shop than during emergency braking on the highway.

Elements of an effective remediation plan

• Risk prioritization
  Close the most dangerous gaps first: open AXFR, recursion on authoritative servers, expired DNSSEC signatures.

• Change management
  Every DNS modification should have a rollback plan. Example: before migrating services, lower TTL so that in case of failure the previous configuration can be restored faster.

• DNS as code
  Treat zones like source code. Store them in a repository, review changes, automate tests before publication.

• Recovery tests
  Once a quarter, check if you can restore the entire configuration from backup. This exercise reveals whether documentation and copies are actually complete.

• Periodic audits
  Regularly verify: TTL values, ACL lists, split-horizon consistency, expiration of DS and RRSIG records.

Automation — your best ally

Manual DNS management is like driving without a seatbelt. At small scale it “sort of works,” but with more zones and subdomains it ends in errors. Automating zone signing, monitoring RRSIG validity, or checking DS records minimizes the risk of human error.

Post-mortem culture

After each DNS incident, it’s worth writing a short post-mortem:

• what happened,

• how long the problem lasted,

• what the business impact was,

• what process changes were made to prevent recurrence.

Without this, the organization runs in circles, and DNS management errors keep coming back like a boomerang.

A remediation plan and continuous audit are not bureaucracy. They are a strategy that turns DNS from a “point of failure” into a predictable and resilient element of infrastructure. The key is consistency: risk prioritization, process automation, recovery testing, and a culture of learning from mistakes. Then, even if an incident occurs, it will be a short episode — not a business disaster.