Stale A Record Detection

RedScore queries the A record at the apex (yourdomain.tld), takes the first IP returned, and attempts a TCP connection to port 80 and port 443 with a 3-second timeout. The check passes if either port accepts the connection. It warns (no fail tier) if both ports are closed, or if there is no apex A record to probe. No HTTP request is made, no content is fetched, and no other hosts are checked.

What this means in practice: a pass tells you the apex is up and accepting connections on at least one standard web port. A warn means either the apex IP is unreachable on web ports from the scanner's vantage (firewall, dead host, IP reassigned without DNS update, etc.), or there is no apex A record at all.

How the verdict maps to evidence

• Pass: TCP connect to port 80 or 443 succeeded within 3 seconds. Evidence shows tcp_80_reachable and tcp_443_reachable booleans plus the sample_ip that was probed.
• Warn: both ports failed within 3 seconds.
• Warn: no apex A record returned by DoH.

Warn: no apex A records

If yourdomain.tld has no A or AAAA records, no web traffic resolves to the apex. Two common cases:

• Intentional. The apex is not used for web (mail-only domain, marketing redirect at www only). The warn is acceptable; consider publishing an explicit redirect or holding page at the apex anyway, since users typing the bare domain expect to reach you.
• Misconfiguration. The apex used to have an A record but it was removed by accident. Republish the A record pointing at your real apex host (or use the DNS provider's CNAME-at-apex feature to point at a managed CDN or load balancer).

Warn: both web ports closed on the apex IP

The apex resolves but neither port 80 nor port 443 accepts a TCP connection from the scanner. This does not prove the host is stale, but it means the scanner cannot reach standard web ports there. Investigate in this order:

• Test from another network. Run nc -zv <ip> 80 and nc -zv <ip> 443 (or curl -vI http://<ip>) from a different vantage point. If both succeed elsewhere, your firewall is blocking the scanner; allow-listing scanner traffic is one option, accepting the warn is another.
• Check whether the host is up at all. ping the IP, or check the host status in your hosting provider's console. If the host is down or terminated, the IP is stale.
• Check for IP reassignment. Cloud IPs are recycled. If you released an EC2 instance, Cloud Run service, or Droplet without removing the DNS record, the IP may now belong to someone else's resource.
• Check whether you actually serve on standard web ports. If the apex is intentionally not a web server (mail server, API on a non-standard port), consider whether the apex A record should exist at all.

If the IP is stale, fix the DNS rather than the host

When an IP is dead or reassigned, do not try to revive it; update DNS to point at a host you actually control:

• If the apex should serve a website: update the A record to point at your current web host (or use the DNS provider's CNAME-at-apex feature for a managed CDN or load balancer).
• If the apex should not serve a website: remove the A record and consider publishing a null MX (see MX Presence & Hygiene) so the domain's intent is explicit.
• If you migrated to a managed host: use whatever target hostname or anycast IP that host documents.

Verify the fix

• Run dig +short A yourdomain @1.1.1.1 and confirm the IP is what you expect.
• Run nc -zv <ip> 80 and nc -zv <ip> 443 from outside your network. At least one should succeed.
• Re-run the RedScore lookup. Pass requires at least one port reachable.

Common pitfalls

• Treating warn as proof the IP is stale. The check explicitly cannot prove that. A warn means the scanner could not connect on standard web ports. Investigate before assuming stale.
• Subdomains not covered. The check only probes the apex. Subdomains pointing at stale IPs are not detected here. Audit subdomain DNS records manually until the broader version of this check ships.
• Multi-IP A records ignored beyond the first. If the apex returns multiple IPs (anycast, round-robin), the check probes only the first. Other IPs may have different reachability.
• TCP reachability without HTTP. A successful TCP connect does not mean the host serves a working web page. It only means port 80 or 443 accepts a TCP handshake. Actual web content quality lives in Web Application Security checks.
• Firewall scope. If you allow-list the RedScore scanner to bypass this warning, remember the warning was a signal that any external user is also blocked. Allow-listing the scanner masks the underlying problem.