DNS monitoring tool

DNS is the first thing that breaks when a domain is attacked, misconfigured, or left to expire — and it is often the last thing teams think to monitor. An unexpected change to an A record can silently redirect your traffic to the wrong server. A missing MX record means your email stops being delivered without any error visible to senders. A CNAME pointing to an abandoned third-party service becomes a subdomain takeover vulnerability. DNS monitoring catches these state changes the moment they happen, not hours later when users start reporting problems.

DNS monitoring works by resolving each configured record on a schedule and comparing the result against the last known value. The comparison is exact: the same record type, the same set of values, the same TTL. Any difference — a new IP in the A record, a removed entry in the MX list, a CNAME value that changed — triggers an alert. This is fundamentally different from uptime monitoring, which checks whether an HTTP endpoint responds. DNS monitoring checks the DNS layer independently, before any TCP connection is made.

A and AAAA records are the most critical to monitor. They map your hostname to an IP address. An unexpected change to an A record — whether from a DNS hijacking attack, a registrar account compromise, or a misconfigured Terraform run — sends your traffic to a server you do not control. Detecting this within minutes rather than hours limits the window for traffic interception, data exposure, and reputational damage. Monitoring both A (IPv4) and AAAA (IPv6) records separately ensures you catch changes on either protocol family.

MX records control where email is delivered. When an MX record is removed or changed, inbound email stops arriving silently — senders receive no error, the mail just queues and eventually bounces. This is particularly damaging for transactional email flows: password reset emails, invoice notifications, onboarding sequences. MX monitoring catches the change before the queue builds up and customers start contacting support asking why they never received a confirmation email.

TXT records carry SPF, DKIM, and DMARC policies. An SPF record change that removes an authorised sender causes your outbound email to be classified as spam or rejected outright. A DMARC policy relaxation — from p=reject to p=none — removes email authentication enforcement without anything visible in your application. These changes often happen accidentally during DNS migrations and are only caught weeks later during a deliverability audit. TXT record monitoring gives you an alert at the moment of change.

CNAME records on subdomains are a common attack surface for subdomain takeovers. If a CNAME points to a third-party service (a Heroku app, a GitHub Pages site, a Fastly origin) that has since been deprovisioned, an attacker can claim that third-party resource and serve content under your subdomain. DNS monitoring detects when a CNAME value changes — whether a legitimate reconfiguration or an unexpected redirect — and flags it for review immediately.

NS records define which nameservers are authoritative for your domain. A change to NS records — the highest-impact DNS change possible — means someone has redirected control of your entire domain's DNS to a different provider. This is the target of the most severe domain hijacking attacks. Monitoring NS records ensures you see this change within minutes of it propagating, before any downstream damage can occur.

DNS monitoring integrates naturally with SSL certificate monitoring. Certificate issuance relies on DNS: ACME DNS-01 challenges write TXT records during Let's Encrypt renewals; CAA records restrict which CAs can issue certificates for your domain. A missing CAA record allows any CA to issue a certificate for your domain. Running DNS monitoring and SSL monitoring together closes the full attack surface at both layers.