DNS Monitoring: Track Record Changes, Discover Subdomains, and Prevent DNS Hijacking

DNS is the foundation of every internet-facing service you operate. When DNS records change unexpectedly — whether from a misconfiguration, an expired domain, or an active attack — the impact is immediate and often invisible until users start reporting problems. Your servers are running fine, your application is healthy, but nobody can reach it because DNS is pointing somewhere else.

With Down Device v5.2.0, we are introducing comprehensive DNS monitoring: record change detection across ten record types, automated subdomain discovery, registrar-level nameserver monitoring, and resolution failure alerts. This post explains why DNS monitoring is critical, what the new feature covers, and how it works under the hood.

Why DNS Monitoring Matters

DNS issues fall into three categories, and each one can take down your entire online presence without a single server going offline.

DNS Hijacking

DNS hijacking is the deliberate redirection of your domain's DNS records to attacker-controlled infrastructure. An attacker who gains access to your DNS provider account — or exploits a vulnerability in the provider itself — can change your A records to point to their servers, redirect your MX records to intercept email, or modify your TXT records to bypass SPF and DKIM validation. The attack is silent: your servers keep running, your logs look normal, but your users are being served phishing pages or having their credentials harvested.

High-profile DNS hijacking campaigns like DNSpionage and Sea Turtle have targeted government agencies, telecoms, and enterprises by compromising DNS registrars and hosting providers. These attacks persisted for months in some cases because the victims had no automated monitoring of their DNS records.

Unauthorized Changes

Not every DNS change is malicious. A team member updates a CNAME and accidentally breaks a subdomain. A migration script overwrites MX records. A vendor changes an API endpoint and the CNAME you pointed at no longer resolves. An intern deletes a TXT record they did not understand. Without monitoring, these changes are discovered when someone reports that email is broken or a service is unreachable — hours or days after the change was made.

Misconfiguration and Drift

DNS configurations drift over time. Old records accumulate. CAA records that restrict certificate issuance get removed during a provider migration and never get added back. SPF records exceed the ten-lookup limit after a series of additions. SOA serial numbers stop incrementing, preventing zone transfers. DNS monitoring catches this drift as it happens, not during a quarterly audit.

What We Monitor: Every Record Type That Matters

Down Device DNS monitoring covers ten record types. Each serves a different purpose in your infrastructure, and each can be independently monitored for changes.

• A / AAAA — IPv4 and IPv6 address records. The fundamental records that map your domain to server IP addresses. Changes here redirect all traffic to a different destination.
• CNAME — Canonical name records. Aliases that point one domain to another. Commonly used for CDN integration, SaaS vanity domains, and subdomain routing. A broken CNAME cascades into a resolution failure for everything that depends on it.
• MX — Mail exchange records. Control where email for your domain is delivered. Unauthorized MX changes can redirect all inbound email to an attacker's server — one of the most damaging forms of DNS hijacking.
• TXT — Text records. Used for SPF, DKIM, DMARC, domain verification, and various service-specific configurations. Monitoring TXT records catches SPF modifications that could allow email spoofing or DKIM key changes that break email authentication.
• NS — Nameserver records. Define which DNS servers are authoritative for your domain. A change to NS records is one of the most severe DNS modifications possible — it hands control of your entire zone to different nameservers.
• SOA — Start of authority records. Contains zone metadata including the primary nameserver, administrator email, serial number, and refresh/retry/expire timers. SOA changes can indicate zone transfers or administrative changes at the DNS provider level.
• CAA — Certificate authority authorization records. Restrict which certificate authorities can issue SSL/TLS certificates for your domain. Removing or modifying CAA records can allow unauthorized certificate issuance, enabling man-in-the-middle attacks.
• SRV — Service records. Used for service discovery protocols including SIP, XMPP, LDAP, and Microsoft Active Directory. Changes to SRV records can silently redirect service connections.
• PTR — Pointer records. Used for reverse DNS lookups, mapping IP addresses back to domain names. PTR records are critical for email deliverability — many mail servers reject messages from IPs without valid reverse DNS.

When you add a DNS monitor, Down Device queries all configured record types for your domain and stores the baseline values. Every subsequent check compares the current records against the baseline and flags any additions, removals, or value changes.

Record Change Detection

The core of DNS monitoring is detecting when records change and notifying you immediately. Here is how the detection works.

How It Works

On each check interval, Down Device queries authoritative nameservers for every record type configured on the monitor. The response is compared against the last known state. If any records have been added, removed, or modified, the change is logged with the exact values — what was there before and what is there now.

Change history shows the actual record data. For an A record change, you see the old IP address and the new one. For a TXT record modification, you see exactly which text value was altered. For an MX record addition, you see the new mail server and its priority. This level of detail matters when investigating whether a change was intentional or unauthorized.

TTL Normalization

One of the trickiest problems in DNS change detection is handling TTL (Time to Live) values. DNS providers frequently adjust TTL values for operational reasons — a CDN might lower TTLs before a migration, or a provider might normalize TTLs to standard intervals. Without TTL normalization, these routine TTL adjustments generate a flood of false positive change alerts.

Down Device normalizes TTL values before comparison. When evaluating whether a record has changed, the system compares the record type, name, and data values while treating TTL as metadata rather than a primary field. TTL changes are still logged for reference, but they do not trigger change alerts on their own. This means you get notified when record values actually change — not when your DNS provider adjusts caching timers.

Combined Change History

For domains with subdomain monitors, Down Device provides a combined change history view that aggregates changes from the parent domain and all monitored subdomains into a single timeline. This gives you a complete picture of DNS activity across your entire domain without switching between individual monitors. When investigating an incident, you can see at a glance whether changes happened at the apex domain, a specific subdomain, or across multiple subdomains simultaneously — which is a strong indicator of a zone-wide modification or compromise.

Interactive Response Time Charts

DNS resolution time is a performance metric that directly affects every service using your domain. Down Device tracks resolution time for each check and displays the data in interactive charts with configurable time range filters. Sudden spikes in resolution time can indicate nameserver overload, DDoS attacks against your DNS infrastructure, or a change to a more distant nameserver. Gradual increases might reveal growing zone complexity or degrading nameserver performance.

Subdomain Discovery

You cannot monitor what you do not know about. Subdomain discovery automatically identifies subdomains associated with your domain so you can bring them under monitoring without manually enumerating them.

Certificate Transparency Logs

Certificate Transparency (CT) is a framework that requires certificate authorities to publicly log every SSL/TLS certificate they issue. Down Device queries CT logs to find certificates issued for subdomains of your domain. If a certificate was issued for staging.example.com or api-v2.example.com, those subdomains appear in your discovery results — even if you did not know they existed.

CT log discovery is particularly valuable for catching shadow IT subdomains, forgotten staging environments, and unauthorized certificate issuance. If someone obtains a certificate for a subdomain of your domain that you did not authorize, CT log monitoring surfaces it.

Common Pattern Detection

Down Device also probes common subdomain patterns: www, mail, smtp, imap, pop, ftp, api, staging, dev, admin, vpn, cdn, and dozens more. For each pattern, the system performs a DNS lookup. If the subdomain resolves, it is added to your discovery results. This catches subdomains that might not have SSL certificates — internal tools, legacy services, and infrastructure endpoints that CT logs would miss.

DKIM and DMARC Discovery

Email authentication records often live on subdomains that are easy to overlook. Down Device checks for DKIM selector records (e.g., selector1._domainkey.example.com) and DMARC policies (_dmarc.example.com) as part of subdomain discovery. Changes to these records directly affect email deliverability and spoofing protection, making them critical monitoring targets.

Parent-Child Relationship Grouping

Discovered subdomains are organized in a parent-child hierarchy. Your apex domain is the parent, and each subdomain is grouped beneath it. This structure makes it straightforward to monitor an entire domain's DNS footprint from a single view. You can add discovered subdomains as monitored entities with one click, and their change histories roll up into the parent domain's combined timeline.

Nameserver Change Monitoring

Nameserver records are the keys to your entire DNS zone. Whoever controls the authoritative nameservers for your domain controls every record in the zone. A change to your NS records — whether at the registrar level or within the zone itself — is one of the most significant DNS events that can occur.

Down Device monitors NS records at both the zone level and the registrar delegation level. If your domain's nameservers change from ns1.your-provider.com to something unexpected, you receive an immediate alert. This catches scenarios that record-level monitoring alone would miss: if an attacker changes your registrar's nameserver delegation, all subsequent record queries go to the attacker's nameservers, which can return whatever records they want. Monitoring the NS delegation itself is the only way to detect this class of attack.

NS change alerts include the previous nameservers and the new ones, so you can immediately determine whether the change was a planned migration or an unauthorized modification. For organizations that rarely change DNS providers, any NS change alert warrants immediate investigation.

Resolution Failure Alerts

Beyond tracking what records contain, Down Device monitors whether your domain resolves at all. A resolution failure means that DNS queries for your domain are returning NXDOMAIN (non-existent domain), SERVFAIL (server failure), or timing out entirely.

Resolution failures have several common causes:

• Expired domain registration. Your domain registrar suspended the domain because the registration lapsed. All DNS resolution stops immediately.
• Nameserver outage. Your DNS hosting provider is experiencing an outage. The authoritative nameservers are unreachable, and cached records are expiring across resolvers worldwide.
• Zone file corruption. A malformed zone file caused the nameserver to stop serving your zone. The nameserver is running, but it returns SERVFAIL for your domain.
• Deleted zone. The zone was accidentally or deliberately removed from the nameserver configuration.

Down Device sends resolution failure alerts when your domain stops resolving and recovery alerts when resolution is restored. This provides a clear timeline of DNS outages separate from record change events. You know exactly when your domain went dark and when it came back, which is essential for incident reporting and SLA compliance.

Plan-Based Check Intervals

DNS monitoring check frequency varies by plan to match different operational needs:

Plan	Check Interval	Best For
Free	Every 60 minutes	Personal domains, low-traffic sites
Basic	Every 15 minutes	Small business domains, standard monitoring
Pro	Every 5 minutes	Production infrastructure, SLA-bound services
Enterprise	Every 5 minutes	Large-scale operations, compliance requirements

For most production domains, 15-minute checks provide a good balance between detection speed and resource usage. The 5-minute interval on Pro and Enterprise plans is designed for organizations where DNS changes have immediate security or availability implications — financial services, healthcare, e-commerce, and any environment with strict compliance requirements.

Users can configure notification preferences per monitor, choosing which alert types they want to receive (record changes, resolution failures, nameserver changes) and through which channels. This prevents alert fatigue by letting you focus on the events that matter most for each domain.

Get Started with DNS Monitoring

DNS monitoring is available now in Down Device v5.2.0 across all plans. Adding a DNS monitor takes less than a minute: enter your domain, select the record types you want to track, and Down Device handles the rest — baseline capture, subdomain discovery, and ongoing change detection.

If you are already monitoring websites, APIs, or servers with Down Device, DNS monitoring fills the gap that sits underneath all of those services. A website monitor tells you when your site is unreachable. A DNS monitor tells you why — and catches the problem before it cascades into a full outage.

Ready to add DNS monitoring to your stack? Check out our plans or contact the team if you have questions about monitoring your specific DNS infrastructure.