Operations | Monitoring | ITSM | DevOps | Cloud

Enterprise teams can now add a Webhook alert channel that POSTs every DNS Spy alert — DNS record changes, domain outages, security check failures, WHOIS updates, phishing look-alike detections — to any HTTPS endpoint as structured JSON. Requests are optionally HMAC-signed, every delivery is logged and retried, and a Send Test button verifies your integration end to end.

When we launched DNS provider sync with six providers, one name came up in nearly every "what about..." email: Amazon Route 53. That makes sense. Route 53 runs DNS for an enormous share of production infrastructure, and it does not support zone transfers — so until now, monitoring a Route 53 zone meant relying on autodiscovery's educated guesses. Today that gap closes.

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.