Dead MX, private IPs, dangling nameservers: the DNS records pointing at nothing

DNS is a set of pointers: this name resolves to that host. The quiet danger is a pointer that aims at something which no longer exists, or never should have been public. The record still resolves, the entry is still there, but the destination is gone, internal, or claimable. These aren't loud failures. The site loads, mail mostly works, and the broken pointer sits in your zone until someone, often an attacker, notices it's broken in a useful way.

Three of these are worth catching, and they sit on a spectrum from "your mail is silently dropping" to "someone can take this over."

A mail server that points at a host that doesn't exist

Your MX records name the servers that receive mail for your domain. If an MX exchange host hard-fails to resolve, NXDOMAIN on both A and AAAA, the host simply doesn't exist, then two things follow, and the second is the security one.

First, mail aimed at that record bounces or silently drops. A sending server tries to deliver, can't find the host, and the message dies. You lose inbound mail and may not realize it for weeks. Second, and more dangerous: a non-existent MX host is an impersonation and hijack target. The name is unclaimed. Depending on how it dangles, an attacker who can register or claim the host the MX points to can start receiving mail meant for you, password resets, invoices, anything sent to your domain. It's the email cousin of a subdomain takeover, and the scanner rates it high for exactly that reason.

A private IP published in public DNS

This one is pure information leak. Sometimes a public DNS record, an A or AAAA for your scanned host, resolves to a private IP: an RFC1918 address (10.x, 192.168.x, 172.16-31.x), a ULA, or a link-local address. These addresses only mean anything inside a network; on the public internet they route nowhere. So the record doesn't help anyone connect, it just tells the world a fragment of your internal addressing.

That's low-severity, and the scanner grades it low, but it's recon: it confirms internal network ranges, hints at your topology, and occasionally reveals a host that was meant to be internal-only and got a public DNS name by mistake. It's the DNS version of an internal IP leaking into your page source, a small fact that helps an attacker draw the map.

A nameserver delegation that dangles

The third one is the most takeover-flavored, and it's the same broken-pointer idea aimed at your NS records. If one of the nameservers your domain delegates to hard-NXDOMAINs while the others still answer, part of your DNS authority points at a host that's gone, and if its name is registrable, someone can claim it and start answering for your domain. It's serious enough, and distinct enough, to have its own walkthrough: a dangling nameserver delegation and what it lets an attacker do, with two real examples from sites we scanned.

; MX names a host that no longer resolves
yourdomain.com.  MX  10 mail.old-host.com.   ; NXDOMAIN
; a public record leaking an internal address
db.yourdomain.com.  A  10.0.1.14            ; RFC1918, public
; a delegated nameserver that's gone
yourdomain.com.  NS  ns2.lapsed-domain.com.  ; NXDOMAIN

The cures are housekeeping with teeth: repoint or remove the dead MX (and own whatever it points at), pull internal IPs out of public DNS (use split-horizon DNS so internal names resolve only inside), and audit your NS set so every delegated nameserver actually exists and is yours. Where a dead pointer leads to a claimable name, fix it with urgency, that's the takeover window.

Reading it from outside

All three of these live in public DNS, readable by anyone, which is why an attacker spots them and why a scanner can check them with no access to your systems. SurfaceCheckr does plain DNS reads, no zone transfer, no crafted query, and reasons about what resolves: it checks whether each MX exchange host actually exists, whether your public records leak a private IP, and whether any delegated nameserver hard-NXDOMAINs while the rest survive. It only flags hard, unambiguous failures, so a transient glitch doesn't cry wolf. These are the pointers-to-nothing that turn from "untidy" into "exploitable" the moment a lapsed name becomes registrable, which is exactly why finding them first matters. The closest read is subdomain takeover via a dangling CNAME, the same broken-pointer pattern aimed at a different record type.