Scanner policy

How to identify our traffic

Active probes — the ones that open a socket to your infrastructure — leave from one machine, in one place, with two fixed addresses:

• IPv4: 209.71.105.67 (reverse DNS ip-209-71-105-67.customer.flyio.net)
• IPv6: 2a09:8280:e601:1:0:190:4889:0
• Location: Amsterdam, Netherlands, hosted on Fly.io
• User agent: dotvitals/1.0 (+https://www.dotvitals.com/scanner/)

Those addresses are ours alone and are not shared with other customers of the hosting provider. If you want to allow-list dotvitals, or block it, they are the addresses to use — and blocking them is a legitimate thing to do that we will not try to work around.

One warning, because it will otherwise be reported to us as a bug: the commercial IP-geolocation databases place 209.71.105.67 in the United States. The machine is physically in Amsterdam, Netherlands. For any question about where processing happens, the machine's location is the answer, and it is the answer the privacy policy gives too.

Some checks do not use that machine. The plain HTTPS ones — fetching your homepage to read its headers, reading DNS-published email policy over DNS-over-HTTPS, querying RDAP — run at the edge on Cloudflare's network and therefore leave from Cloudflare addresses shared with every other site Cloudflare serves. Identify those by the user agent above, not by address. We say so rather than publishing a list we do not control.

What dotvitals probes

When someone runs a check against a domain on dotvitals, the scanner performs a small, bounded set of read-only operations against that domain, roughly equivalent to what a normal browser visit, DNS lookup or mail-server connection already does:

• DNS queries for standard record types (A, AAAA, MX, TXT, NS, SOA, CAA, DNSSEC-related records) and the DNS-based email authentication records (SPF, DKIM selectors, DMARC, BIMI, MTA-STS, TLS-RPT), sent to your authoritative nameservers and to public resolvers.
• One HTTP GET of the homepage to read security headers, cookies, CORS configuration and the redirect chain.
• A small number of TLS handshakes on port 443 to read the certificate and the supported protocol versions.
• An SMTP connection that sends EHLO and STARTTLS and then disconnects, to check mail-transport security — never a message, and never MAIL FROM or RCPT TO.
• A connect-only check against a short, published list of common ports (the kind of ports a browser, mail client or database client would normally connect to) — one TCP connection attempt per port, and nothing is sent on it at all: not a byte, not a protocol probe, not a login. The connection is opened and closed. Where a server volunteers a greeting of its own the moment a connection completes, as SSH, SMTP, FTP and MySQL do, we read the first kilobyte of it and disconnect. Each host is checked on one of its addresses, and the report says which.
• For the performance check, one page load in a real Chromium browser we run ourselves on that machine: it requests your page and its subresources the way a visitor's browser would, once, and then closes.
• Passive lookups that never touch your infrastructure at all: WHOIS/RDAP registration data, and DNS blocklist lookups about your mail server's address, sent to the blocklist operators rather than to you.

Heavier checks — a wider port range, or results an anonymous visitor is not given — require the domain owner to verify ownership first.

What dotvitals never does

• It never attempts to exploit a vulnerability, brute-force a login, or password-guess anything.
• It never sends an email, an SMS, or any message to a real recipient.
• It never scans arbitrary IP ranges or CIDR blocks, and it never scans an IP address on its own without a user-supplied hostname behind it, other than the specific reverse-DNS and TLS-by-IP checks a user explicitly requests.
• It never probes ports outside the published common-ports list without the domain owner having verified ownership.
• It never performs SYN scans, UDP floods, or any technique designed to look like an attack rather than a diagnostic check; every port probe is a full TCP connect, single attempt, at a pace closer to a browser than a scanner.
• It never targets an internal, private, loopback, link-local, carrier-NAT or cloud-metadata address. Every address is validated before the connection is made and again after every DNS lookup and every redirect, and the probe machine's own firewall refuses the same ranges a second time — so a bug in the first check is not enough to get a packet out.

Read-only and rate limited

Every check above is read-only: it observes what a server presents to any ordinary client and does not attempt to modify, disrupt or overload anything.

Checks against a given domain are rate limited platform-wide, not just per visitor: a common set of checks against the same domain is served from a short cache rather than re-run for every visitor, so a domain cannot be checked more than a small, bounded number of times in a short window regardless of how many different people request it.

Anonymous use is also limited per visitor and per network, with a step-up human-verification challenge and, if abusive patterns continue, temporary blocks. dotvitals may also simply refuse a request — because of load on the service, because a target has opted out, or because the request pattern looks like reconnaissance rather than diagnosis.

Why was my server probed?

Every scan dotvitals runs is tied to a scan id, shown on the corresponding result page. If the person who ran the scan shares that id with you, write to abuse@dotvitals.com with it and we can confirm what that specific scan did and roughly when.

We cannot tell you who requested it. Scans are anonymous: there is no account, and the only requester-derived value stored with a scan is a salted hash of a truncated network prefix, which is not reversible to a person or to an address. That is a deliberate design choice and it cuts both ways — it also means there is nothing to hand over to you, or to anybody else.

Scan records are deleted 30 days after they are created, so a question about an older probe can be answered only in general terms.

Opting a domain out of active checks

If you would rather dotvitals never ran active checks against a domain you own, write to abuse@dotvitals.com and ask for it to be opted out. Once a domain is opted out, dotvitals refuses to run active checks against it and tells whoever asked that the owner has opted out.

We will ask you to prove you control the domain before acting, because an opt-out anybody could request for anybody else's domain would be a censorship tool rather than a protection. Either write from an address at that domain, or publish a DNS TXT record we give you.

Two things worth being honest about. Opt-outs are applied by a person, not by an automated endpoint, so they take as long as a reply to email takes — if you need the traffic to stop immediately, block the two addresses at the top of this page, which works instantly and needs nothing from us. And an opt-out stops dotvitals; it does not stop anyone else, and it does not remove information about your domain that is public in DNS or in the registry.

Opt-outs remain in effect until you ask for them to be removed; there is no expiry.

If you monitor dotvitals

If you run an uptime or synthetic-monitoring service and want dotvitals to recognize your monitor rather than rate-limit it like ordinary traffic, write to abuse@dotvitals.com with your service's published IP ranges or user agent so it can be allow-listed for non-scan traffic.