How it works
How Perimeter works — and what it will never do
Every signal Perimeter surfaces comes from public data that anyone on the internet can already read. It does not scan, probe, fingerprint, or send unsolicited traffic to any host — including yours.
The three public sources
Perimeter pulls from exactly three data sources, all of them open and keyless:
- Certificate Transparency logs via crt.sh — every publicly-trusted TLS certificate
is logged to an append-only CT log within minutes of issuance. crt.sh indexes these logs and exposes
a JSON search API. Querying it reveals every subdomain of your domain that has ever received a certificate,
along with the cert's
not_after(expiry) timestamp. This is public data; a typosquatter, a competitor, or a phishing actor could already be running the same query against your domain. - DNS resolution — standard recursive DNS lookups (A, AAAA, MX, NS, TXT) against public resolvers. No traffic is sent to the resolved hosts. The records themselves are public by design — that is what DNS is.
- RDAP/WHOIS — the Registration Data Access Protocol is the successor to WHOIS. Perimeter queries the RDAP bootstrap registry to determine whether a candidate lookalike domain is registered. RDAP is a public, rate-limited HTTP API; it does not involve contacting the registrant or the hosted servers.
What Perimeter will never do
This is the constraint that makes the tool safe to use on a shared VPS where an abuse complaint can take down your entire box alongside every other tenant:
Perimeter never port-scans, service-fingerprints, banner-grabs, vuln-probes, directory brute-forces, or sends any unsolicited traffic to any host — including hosts that appear in your CT or DNS records. Discovering a hostname via CT does not constitute authorisation to connect to it. We read the log; we do not knock on the door.
Concretely, Perimeter will never:
- Connect to port 22, 80, 443, or any other port on a discovered hostname
- Fetch the HTTP response from a newly-seen subdomain
- Identify the web server, CMS, or framework running on any host
- Test for known vulnerabilities, misconfigurations, or exposed admin panels
- Enumerate directories or files on any web server
- Attempt any form of authentication, fuzzing, or injection
- Send ICMP pings, TCP SYN packets, or UDP probes to any address it resolves
If you self-host on a shared VPS — a Hetzner or DigitalOcean box running Caddy + systemd — an abuse report from a neighbouring tenant can trigger a host-level review that takes down every service on the machine, not just yours. Passive-only is not a marketing claim; it is the constraint that makes Perimeter safe to run in that environment.
The one active check
There is a single exception: a TLS handshake to a hostname you have verified you control,
performed solely to read the live leaf certificate's not_after field. This is a standard
TLS handshake — tls.connect in Node — that sends no application data. The handshake
completes, the certificate is read, and the connection is closed. No HTTP request is made. No data
about your server's behaviour is recorded beyond the cert expiry date.
This check only ever targets a hostname that belongs to an active, verified subscription. Verification happens first (see below). If a domain's verification lapses, the TLS check is disabled with it.
Domain ownership verification
Before Perimeter enables continuous monitoring for a domain — and before the TLS handshake check is ever used — you must prove you control it. Two methods are supported:
DNS TXT record
Recommended
Add a TXT record with the value perimeter-verify=<token>
at the name _perimeter.yourdomain.com.
Click Verify in your dashboard — Perimeter performs a single
resolveTxt lookup. On success, the domain is marked verified.
The token is unique to your account and rotates if you request a new one. No traffic is ever sent to any IP address your domain resolves to.
HTTP file
Serve the token string at
https://yourdomain.com/.well-known/perimeter-challenge.txt.
Perimeter performs a single HTTPS GET to confirm the token, then marks the domain verified.
This is the only outbound HTTP request Perimeter ever makes to a customer host, and it is explicitly authorised by the act of serving the token.
The free one-shot report does not require verification — it only queries public data sources (crt.sh, DNS, RDAP) and never touches your servers. Verification is required only to enable continuous monitoring and the cert-expiry TLS check.
The four signals
What Perimeter watches for
New subdomain via CT info
Every TLS certificate issued to a hostname under your apex domain is logged to public Certificate Transparency logs within minutes of issuance. Perimeter queries crt.sh for all CT-logged names under your domain and diffs the result against your saved baseline. When a new name appears — staging.acme.dev, an admin panel you forgot, anything — you get an alert with the exact hostname and the cert's not_after date.
Cert expiry warn
CT records already carry not_after timestamps. For verified, monitored hostnames Perimeter may additionally perform a TLS handshake — the one sanctioned active check — to read the live leaf cert's expiry. Alerts fire at 14 days out and again at 3 days. The TLS handshake sends no data beyond the standard handshake; it only reads the certificate.
DNS drift info
Perimeter baselines your apex domain's A, AAAA, MX, NS, and TXT records at first scan. On each subsequent scan it resolves the same set and diffs against baseline. A changed MX record can mean your mail is being redirected. A new TXT record might indicate a service you didn't authorise. DNS drift catches the quiet changes that don't produce a CT log entry.
New lookalike domain critical
Perimeter generates a bounded set of typosquat permutations of your apex — adjacent-key typos, character omissions, homoglyph swaps (rn vs m, 0 vs o), TLD swaps (.com/.net/.co/.io/.app), and insertion variants. Each candidate is checked against RDAP (to see if it's registered) and crt.sh (to see if a cert has been issued). A newly-registered look-alike domain that matches your brand signals an active phishing preparation.
Rate limiting and source courtesy
crt.sh and RDAP are public, shared infrastructure. Perimeter rate-limits its outbound calls to both and retries gently with backoff. The lookalike candidate set is capped (≤ ~60 candidates per domain) to bound RDAP volume. If a source is temporarily unavailable, that one signal is skipped for that scan run rather than failing the whole job — you'll see the partial result annotated with the source that was unreachable.
The free report enforces a per-IP rate limit (3 reports per hour) to prevent automated scraping of crt.sh and RDAP through our infrastructure.
Questions?
If you have a specific question about what Perimeter does or does not do — especially if you are evaluating it for a security-sensitive environment — email thomas@thomaspeng.ca. You will get a direct answer, not a support ticket.
See what the internet already knows about your domain
No account, no credit card — a free one-shot report in seconds, built entirely on public data.