The 38 ports DNS Watchdog scans, and why each one matters
One of the first questions ops and security teams ask us is: "What do you actually check?"
Port scanning is a big part of the answer. Every A record in every zone you connect gets its resolved IPs probed against a curated list of 38 ports. This post explains what those ports are, why each one is on the list, and the severity we assign when we find them open to the internet.
We don't scan everything on 0–65535. That's noise. We scan the ports that attackers actually exploit, plus the web ports your sites are meant to answer on.
Why 38 and not 1,024?
A full port scan is slow, triggers rate limits, and produces mostly false positives. What matters for DNS-driven attack surface management is a targeted list of ports that map to specific, well-understood threat models:
- Remote access (SSH, RDP, VNC, Telnet)
- Unauthenticated admin APIs (Docker, Kubernetes)
- Databases exposed without authentication
- Legacy Windows services used for lateral movement
- Email infrastructure that can be turned into a spam relay
- Log and monitoring tools that leak sensitive operational data
Each check is a plain TCP connection with a short timeout: if the port accepts the connection, it's open. We close the connection straight away - nothing is sent, nothing is exploited.
That's the 38. When one of them is open, we raise a finding graded Critical, High, Medium, or Low based on what an attacker does with it - except the five web ports, which are where your sites are supposed to answer.
Critical: the Docker API
| Port | Service | Why it's critical |
|---|---|---|
| 2375 | Docker API | Unauthenticated by design; one request gives an attacker root on the host |
Critical is reserved for findings we can confirm are exploitable right now, and the Docker API on 2375 is the one port that qualifies. It's unauthenticated by default, so reachability alone is the confirmation: an attacker gets root on the underlying host in one request. A single open Critical caps your Security Grade at a D.
High: remote access
| Port | Service | Why it's high |
|---|---|---|
| 23 | Telnet | Unencrypted data transmission; should be disabled anywhere |
| 3389 | RDP | Primary vector for ransomware; every major RDP scanner campaign hits this |
| 5900 | VNC | Remote desktop, often with weak or default passwords |
Finding RDP open on a record you thought pointed at a static site is a quiet emergency. Most port exposures are accidental - someone stood up a VM to do a migration, the migration finished, the VM was forgotten, and the DNS record still points at it.
High: databases and caches
| Port | Service | Why it's high |
|---|---|---|
| 1433 | MSSQL | Default credentials are widely known; brute-force is fast |
| 1521 | Oracle | Shouldn't be internet-facing, ever |
| 3306 | MySQL | Historical favourite for credential dumps |
| 5432 | PostgreSQL | Same story; also leaks schema via pg_hba errors |
| 6379 | Redis | Often deployed without auth; used for RCE and cryptomining |
| 6380 | Redis TLS | Same, with added "oh good, it's TLS" false confidence |
| 9042 | Cassandra | Node discovery exposes your cluster topology |
| 9200 | Elasticsearch | The source of many large dataset leaks in 2019–2021 |
| 9300 | OpenSearch | Same, cluster-internal port |
| 11211 | Memcached | Abused for amplification DDoS at 50,000× |
| 27017 | MongoDB | Remember the 2017 "MongoDB apocalypse"? This port |
A database port open to the internet is rarely intentional. It's almost always a Security Group rule someone forgot to scope down.
High: infrastructure and ops tooling
| Port | Service | Why it's high |
|---|---|---|
| 445 | SMB | Primary ransomware entry vector (WannaCry, NotPetya) |
| 6443 | Kubernetes API | Potential cluster takeover |
| 389 | LDAP | Leaks directory structure and user info |
| 5601 | Kibana | Full log search across your infrastructure |
| 7474 | Neo4j | Graph database, often holding identity data |
If you have a Windows IP exposing 445 to the internet in 2026, you've already lost. SMB should never, ever be public.
An exposed Kibana is a gift to an attacker doing reconnaissance. They get your infrastructure shape, log formats, deployed services, and often credentials leaked through poorly-filtered logs.
Medium: real weaknesses, less direct risk
| Port | Service | Why it's medium |
|---|---|---|
| 21 | FTP | Transmits credentials in plaintext |
| 22 | SSH | Often deliberate, but a forgotten VM with password auth is a brute-force target |
| 135 | MS-RPC | Windows endpoint mapper, exploited by the Blaster worm; no reason to be public |
| 636 | LDAPS | Same directory exposure as LDAP, over TLS |
These sit below High because an attacker needs a second step to turn them into access - sniffed credentials, a weak password, an unpatched service - and because some are exposed on purpose. Plenty of teams run a bastion host on 22. We flag them so you can confirm each exposure is intentional, and when it is, you can ignore port findings for that IP with the reason recorded.
Low: mail and DNS
| Port | Service | Why it's low |
|---|---|---|
| 25 | SMTP | Open relays get abused for spam within hours |
| 53 | DNS | Open resolvers enable amplification attacks |
These are Low because they're usually doing their job: your MX hosts answer on 25 and your authoritative nameservers answer on 53, and a connection check alone can't tell a well-run mail server from an open relay. We flag them so you can verify each one is a host that's meant to be serving mail or DNS.
The rest of the list
Seven ports on the list have no dedicated finding type. When one is open we still raise a Medium-severity finding with a dynamic port_open_{port} type and a human-readable service name:
- 110 / 143 / 993 / 995 - POP3 / IMAP variants
- 111 - RPCBind (leaks network topology)
- 139 - NetBIOS (pre-SMB, still exploited)
- 1723 - PPTP VPN (broken, should not be used)
The last five - 80, 443, 8080, 8443, and 8888 - are the web ports. An open web port is expected, so it raises no finding; those hosts go through the HTTP scan instead, which checks for errors, broken redirects, and HTTP that never redirects to HTTPS.
Why this matters for DNS
Here's the part that connects back to DNS attack surface management: the IP address on the other side of an A record is often something someone else is responsible for. Your DNS team doesn't own the AWS account, the firewall rules, or the VM that was stood up by a product team six quarters ago. But your DNS record is pointing there.
Port scanning at the DNS layer catches exposures that nobody is specifically looking for. The app team thinks security is handling it. Security thinks ops has monitoring. Ops didn't know the record existed.
DNS Watchdog scans every resolved IP daily. If a port opens up that shouldn't be open, you'll know within 24 hours.
Want to see what's exposed on your estate?
Book a 30-min demo and we'll walk you through a live scan using real data from a similar estate. A real look at what DNS Watchdog surfaces, not a sales deck.