Your IP Inventory and Your DNS Zones Disagree: Keeping Forward, Reverse, and Reality in Sync

At two in the morning, something at 10.20.30.44 starts hammering the file server, and you do what anyone would do: ask DNS who lives there. DNS (the Domain Name System) is the service that turns names like ipcraft.io into the numbers computers actually dial, and it works in the other direction too, turning numbers back into names. Tonight it answers with complete confidence: backup-nas-old. That would be useful information, except the old backup NAS (network-attached storage, a box of hard drives that lives on the network) was unplugged, wiped, and sent to the recycler two years ago. Whatever machine holds that address now, DNS is describing its predecessor, and your troubleshooting session has just been handed a map with a ghost on it.

Every network keeps at least three descriptions of itself. There is the inventory, the record of what you intended: which subnets exist, which IP (Internet Protocol) addresses are assigned, and what each one is for. There is DNS, the record of what the network tells everyone who asks. And there is reality, the set of machines that actually answer when you knock. On a well-run network the three agree so completely that nobody thinks of them as separate documents. On most networks they drift apart quietly, each on its own schedule, and the drift stays invisible until a night like this one, when you need all three to agree and discover they never did.

The forward direction of DNS is the famous one. A forward lookup starts with a name and ends with an address, courtesy of an A record (the A stands for address), or an AAAA record for the longer addresses of IPv6 (Internet Protocol version 6, the newer numbering system with room for effectively unlimited devices). Forward records stay reasonably honest for a simple reason: when they break, the breakage is loud. If the A record for the company website points somewhere wrong, the phones start ringing within minutes, and someone fixes it the same hour. Loud failure is a wonderful preservative.

The reverse direction answers the opposite question: given the number, what is the name? That answer lives in a PTR record (short for pointer), stored in a dedicated corner of the DNS tree built by writing the address backwards, so the PTR for 10.20.30.44 lives at a spot called 44.30.20.10.in-addr.arpa. The backwards spelling looks bizarre until you learn that DNS delegates authority from right to left, so reversing the address lets each organization control the names for its own block of address space. IPv6 has an equivalent under ip6.arpa, spelled out one hexadecimal digit at a time, and if those longer addresses are unfamiliar territory, our guide to IPv6 address planning covers the landscape. The standard query tool, a command-line program called dig, wraps the whole scheme in a single flag: dig -x takes an address and returns whatever name the reverse zone holds for it. (A zone, while we are defining things, is the set of DNS records one organization manages for one slice of the naming tree.)

Forward and reverse, telling two different stories

$ dig +short app-server-01.corp.example.com
10.20.30.44

$ dig +short -x 10.20.30.44
backup-nas-old.corp.example.com.   ← decommissioned two years ago

Nothing in DNS forces those two answers to match. Forward and reverse records live in different zones, frequently on different servers, sometimes under different teams, and each is edited separately, with no referee ever comparing them. The drift follows the lifecycle of every machine. On the day a server is born, someone creates the A record immediately, because colleagues need to reach the machine by name. The PTR is a second chore in a second place, and it gets done if the person remembers, which is to say sometimes. On the day the server is retired, the A record gets deleted or the name gets reused, while the PTR quietly survives, pointing at a name that no longer points back. A stale PTR breaks nothing anyone can see: no user complains, no dashboard turns red, and so the reverse zone becomes the network's attic, where nothing was thrown away deliberately and nothing was kept deliberately either.

Automation helps and complicates in equal measure. DHCP (Dynamic Host Configuration Protocol), the service that hands out addresses to devices automatically, can be configured to update DNS as leases come and go, and when both directions are wired up, the laptop-and-phone population stays perfectly current with no human effort at all. Half-configured setups update only the forward zone, which manufactures disagreement at machine speed. Static infrastructure, the servers and printers and switches whose addressing our guide to DHCP, static, and reservations sorts out, depends entirely on humans remembering both directions. And for public addresses in the cloud, the reverse zone belongs to the provider: AWS (Amazon Web Services) and its peers will happily publish a PTR for your address, but only after you request one through their console, which is one more step that almost nobody's launch checklist includes.

What stale records cost depends on who consults them, and more systems consult them than most people realize. Troubleshooting tools lean on reverse DNS constantly: traceroute, the tool that lists every router between you and a destination, decorates each hop with its PTR name; logging pipelines stamp events with whatever the reverse zone said at the moment of writing; monitoring systems label their alerts the same way. Each stale record is a small lie injected directly into the evidence, at exactly the moment evidence matters most. The genuinely dangerous case is the reassigned address: the PTR still names the old server, that old name now resolves to the replacement machine in a different subnet, and an engineer following the trail confidently signs into the wrong live system. A duplicate-address conflict at least announces itself with dropped connections and angry users. A stale PTR misdirects you while everything appears to work.

The consumer with the highest stakes is email. Receiving mail servers treat reverse DNS as a character reference, and many run the full test known as FCrDNS (forward-confirmed reverse DNS): take the address of the connecting server, look up its PTR, then look up that name's forward record, and expect to arrive back at the original address. A sender that fails the round trip looks indistinguishable from a compromised machine on a residential line, and its mail lands in the spam folder or is refused outright. Whole afternoons have been lost to deliverability mysteries whose entire cause was a PTR nobody created, or a PTR pointing at a name whose forward record was deleted in a tidy-up years before.

The round trip a receiving mail server expects

$ dig +short -x 203.0.113.25
mail.corp.example.com.

$ dig +short mail.corp.example.com
203.0.113.25          ← forward confirms reverse: the loop closes

Finding out how far your own zones have drifted takes one deliberate evening, and the procedure is a pleasant kind of tedious. Take a single subnet from your inventory (if that inventory is a spreadsheet, the exercise doubles as a demonstration of what the spreadsheet workaround costs) and walk every address in it, asking four questions: does the inventory have an entry, does a PTR exist, does the PTR agree with the inventory's name, and does that name's forward record point back at the address? For spot checks without leaving the browser, our free DNS lookup and reverse DNS lookup tools answer the two directions one address at a time. Every address you walk lands in one of four buckets, and each bucket has its own meaning.

The third bucket deserves the most curiosity, because it splits into two very different discoveries. A PTR pointing at a machine that left years ago is simple cleanup, five seconds of deletion and done. A live, answering machine that has DNS records and no inventory entry is a small archaeology project, and if that bucket keeps filling up, the inventory itself has lost touch with the network and may need the ground-up rebuild covered in our guide to building an IP inventory from scratch. Either way, the walk converts a vague sense that the zones are probably fine into a list of specific, fixable disagreements.

Repairing the drift once is satisfying, and it is also temporary, because the same lifecycle that produced the drift resumes the next morning. Keeping the three descriptions aligned is a design decision: give every fact exactly one home, and make everything else a copy. The record that says an address is allocated should be the same record that says what name the address is supposed to carry, both forward and reverse, and the zones should be updated from that record rather than edited freelance. The industry converged on the same conclusion long ago and named the category DDI, short for DNS, DHCP, and IPAM (IP Address Management, the discipline of tracking address space), bundled as one product family precisely because the three datasets describe a single set of facts and rot whenever they are maintained separately. The same principle rewrites the decommissioning checklist: retiring a machine means removing the A record, the PTR, and the inventory entry in one motion, because any step that depends on somebody remembering it later is how the attic filled up the first time.

This is the gap the address records in IPCraft were built to close. Every address entry carries a hostname field and a separate PTR record field, so a single row states what the forward zone and the reverse zone are each supposed to say, including the legitimate mismatches, like a web server whose forward name is www while its PTR carries the machine's canonical name. The evening-with-dig audit becomes a diff: export your zones, compare them against the inventory, and every disagreement surfaces on its own, a comparison the API (application programming interface, the doorway that lets scripts read and write the same records) can run on a schedule. Full-text search answers "which address is supposed to be mail.corp.example.com" from one box, and the activity log remembers who changed a hostname and when, which turns the next audit from archaeology into review.

The reward arrives on the next bad night. Something misbehaves, you ask DNS who lives at the address, and the answer agrees with the inventory, which agrees with the machine that answers your knock. Three descriptions, one network, no ghosts. The retired backup NAS finally gets to rest in peace, and so, a couple of hours earlier than last time, do you.