Operations | Monitoring | ITSM | DevOps | Cloud

Enterprise teams can now add a Syslog alert channel: every DNS Spy alert delivered as an RFC 5424 message over TLS (or TCP/UDP), formatted as JSON or ArcSight CEF, with syslog priorities mapped from real alert severity. All deliveries originate from one documented static IP, so getting through your collector's firewall is a single allowlist rule.

GoDaddy manages more domains than any registrar on earth, so it has always been near the top of our provider integration list. There was just one problem: in May 2024, GoDaddy restricted its API to accounts holding ten or more domains — fifty for some endpoints. Overnight, certificate renewals broke, dynamic DNS scripts died, and every small business with one or two domains was locked out of automating anything.

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.