Exposure Scanning
Your DNS records are a map of your infrastructure, and anyone can read it. DNS Watchdog scans everything the map points at and tells you what an attacker would find.
Reconnaissance is the first step of every attack, and your DNS hands it over for free: a public, enumerable list of names pointing at your infrastructure. Someone will scan everything your records resolve to sooner or later; the goal is to see what they see before they act on it.
Every resolved IP is checked against 38 ports, and an open port on 33 of them is raised as a graded finding. An exposed Docker API, which hands out root on the host with no authentication, is Critical; internet-facing databases and caches - MySQL, PostgreSQL, MSSQL, Oracle, MongoDB, Cassandra, Elasticsearch, Redis, Memcached - remote access over RDP, VNC, or Telnet, exposed Kubernetes APIs, Kibana dashboards, and SMB shares are High; commonly intentional services such as SSH and FTP are Medium. Findings are raised per IP with every affected domain attached, so twenty records behind one load balancer produce a single finding rather than twenty alerts.
The scan does not stop at ports. Every web hostname is probed for HTTP problems - 4xx and 5xx errors, connection failures, broken redirect chains, and HTTP endpoints that fail to redirect to HTTPS - and IPs answering on no ports at all are flagged as inactive before the address gets reassigned to someone else while your records still point at it. Coverage follows your DNS automatically: connect a provider and everything it resolves is in scope, with no configuration to maintain.
How it works
- ResolveEvery record across every zone is resolved daily, and the resulting IPs are deduplicated into a scan target list that always matches your live DNS.
- Scan portsEach IP is checked against 38 ports covering databases, remote access, container and orchestration APIs, directory services, and infrastructure, using lightweight connection checks with strict timeouts and rate limiting.
- Probe HTTPEvery web-serving hostname is requested like a browser would request it: status codes, redirect chains, and HTTPS behaviour are all recorded.
- Check livenessIPs with no responding services are flagged as inactive: stale records that will eventually point your name at someone else's server.
- Grade and raiseFindings are raised as issues from Informational to Critical, each linked to the records and zones affected, and auto-closed when the exposure is gone.
What you get
- 38 ports scanned on every resolved IP, with 33 of them graded as findings
- An exposed Docker API raised as Critical
- Internet-facing databases, Redis, Memcached, RDP, and Kubernetes APIs graded High
- One finding per IP with every affected domain attached
- HTTP 4xx/5xx errors, broken redirects, and missing HTTPS redirects surfaced
- Inactive IPs flagged before the address is reassigned
Why it matters
See what attackers see
The scan runs from outside, against your live DNS, which is the same view an adversary starts with. It needs no agent and no asset list, so there is no gap between what you meant to expose and what you actually did.
Catch shadow infrastructure
The dangerous exposures are rarely on the systems you harden deliberately. They are on the forgotten test box and the service someone stood up in an afternoon, which the DNS-driven scan covers automatically.
Prioritised by real risk
An unauthenticated container API and an open DNS resolver are not the same problem. Severity grading from Critical to Informational means the queue sorts itself.
Noise under your control
Known-safe addresses such as CDN edges, shared hosting, or an intentional bastion host can have their port findings ignored per IP, with the reason recorded, so future detections file themselves away instead of demanding review.
FAQ
Is the scanning safe for my infrastructure?
Yes. DNS Watchdog performs lightweight TCP connection checks with strict timeouts and rate limiting to determine whether a port answers, and requests HTTP endpoints the way a browser would. Nothing is exploited, brute-forced, or load-tested.
Why do open ports matter if the services require authentication?
Authentication is one bug, one leaked credential, or one misconfiguration away from not mattering. Exposed databases and admin APIs are the entry point in a large share of real breaches, and several - Docker, Redis, Memcached - historically ship with no authentication at all.
What about IPs where open ports are expected?
You can ignore all port findings for a specific IP - a CDN edge, shared hosting, a deliberate bastion - with the reason recorded for the audit trail. Future detections on that IP are automatically filed as ignored instead of appearing for review.