The 37 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 37 high-risk 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.
Why 37 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
That's the 37. Each one is categorised as Critical, Warning, or Info based on what an attacker does with it when they find it open.
Critical: remote access
| Port | Service | Why it's critical |
|---|---|---|
| 21 | FTP | Transmits credentials in plaintext |
| 22 | SSH | Unauthorised remote shell is the highest-impact exposure there is |
| 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 an SSH port 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.
Critical: databases
| Port | Service | Why it's critical |
|---|---|---|
| 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.
Critical: containers and orchestration
| Port | Service | Why it's critical |
|---|---|---|
| 2375 | Docker API | Unauthenticated access gives remote root on the host |
| 6443 | Kubernetes API | Potential cluster takeover |
The Docker API on 2375 is probably the most dangerous single port on this list. If it's open and unauthenticated - which is the default - an attacker gets root on the underlying host in one request.
Critical: Windows infrastructure
| Port | Service | Why it's critical |
|---|---|---|
| 135 | MS-RPC | EternalBlue-era exploitation, still weaponised |
| 445 | SMB | Primary ransomware entry vector (WannaCry, NotPetya) |
If you have a Windows IP exposing 135 or 445 to the internet in 2026, you've already lost. We flag these critical because they should never, ever be public.
Critical: monitoring and ops tooling
| Port | Service | Why it's critical |
|---|---|---|
| 5601 | Kibana | Full log search across your infrastructure |
| 7474 | Neo4j | Graph database, often holding identity data |
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.
Warning: mail and directory services
| Port | Service | Why it's a warning |
|---|---|---|
| 25 | SMTP | Open relays get abused for spam within hours |
| 53 | DNS | Open resolvers enable amplification attacks |
| 389 | LDAP | Leaks directory structure and user info |
| 636 | LDAPS | Same exposure, just over TLS |
These are warning rather than critical because legitimate use cases exist - you might actually run an MX or an authoritative DNS server on these ports. But we flag them so you can verify that exposure is intentional.
Dynamic ports
If nmap finds an open port that isn't in the mapping above, we still create a warning-severity issue with a dynamic port_open_{port} type and a human-readable service name. Common dynamics we see:
- 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)
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 20-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.