Operations | Monitoring | ITSM | DevOps | Cloud

When you add a domain to a DNS monitor, the first question is simple: which records should it watch? Until now there were two answers, and both had a catch. Autodiscovery probes hundreds of common names — www, mail, _dmarc, the usual suspects — and it catches most of what real zones contain. But if you named a record something unusual, no wordlist in the world is going to guess it.

Somewhere out there, a domain that looks almost exactly like yours may already be registered. Maybe it swaps one letter. Maybe it uses a Cyrillic character that is visually identical to a Latin one. Maybe it just adds the word "login" or "secure" to your brand. These lookalike domains are the raw material of phishing, and most companies have no idea how many exist for their brand until something goes wrong.

DNS TTL is one of those settings nobody thinks about until it bites them. Then they think about it a lot. This guide explains what DNS TTL is, how it works in plain language, and how to pick the right value for your records. By the end you will know what to set, when to change it, and why it matters when you migrate to a new server.

DNS monitoring should be simple. You want to know if something changed. You want to know if a record propagated. You want to know if a phishing site just went live with your brand name in the domain. But in practice it takes work. You log in to a dashboard. You click through menus. You run a check, copy the output, paste it somewhere else. You repeat that process every time someone on the team asks a question. AI assistants like Claude and ChatGPT could help.

The FBI published a warning last week. Threat actors have registered more than 498 fake domains tied to the 2026 FIFA World Cup. Fake ticket sites. Fake job listings. Fake merchandise stores. All live in DNS right now. Every one of those domains is catchable. Not after victims report fraud. Before anyone gets hurt. That is what DNS Spy’s Phishing Sentinel is built to do.

A new attack technique called Underminr was disclosed this week. It slips past protective DNS by abusing shared CDN edge IPs. The DNS query looks clean. The connection lands on malware. This post walks through what Underminr is, why protective DNS misses it, what actually stops it, and the OTHER DNS layer most teams forget to watch.

Today we are launching the DNS Spy DNS Propagation Checker. It is free. It works on any domain. It shows you what is happening in more places, in more detail, and faster than the tools you have been using. You can try it right now: dnsspy.io/dns-tools/dns-propagation-checker.

If you run an MSP, this is the call that ages you. The fix is almost always small. A record was edited at the registrar. A vendor changed an MX target. A new tool added a TXT record and pushed SPF over the lookup limit. None of that should reach a client. With the right monitoring, none of it does. Here is a real one. A 40-person law firm renews their EV certificate. The vendor needs a CAA record cleaned up.

Here are the three records most teams forget to monitor — and what happens when they break.

The Start of Authority record is the first record in any DNS zone file. It's the record that says "this zone exists, this is the primary nameserver in charge, and here are the timing rules that govern how this zone behaves." A full SOA record looks like this when you query it: Each of those numbers does something different. The one that triggered your warning is the Expire value, the fourth number. In this example, 1209600 seconds, which is exactly 14 days.