denyfirst.

What the inventory reads,
and what it cannot see.

This page lists the names under a domain that appear in publicly logged certificates and in the domain's own published records, and says which of the two named each one. It is the only part of this installation that produces a list of hosts rather than a verdict about one, and the difference decides how the list should be read.

Where the names come from

Two sources, and neither is complete. A certificate transparency monitor holds the names somebody obtained a publicly trusted certificate for: every such certificate is submitted to append-only logs before a browser will accept it, and the names it covers are written inside it. Your domain's own records hold the hosts its mail, its sender policy and its delegation have to name, because those records exist to be read by strangers.

A third, where this installation was given one: a passive register. Resolvers around the world write down the answers they saw, so a name anything ever resolved can be found there — and it is the only source that sees behind a wildcard certificate, which names no host by design. It is off unless an operator configures one, because the key is their own account with a company they chose.

What a register holds is observation rather than publication, and that makes it worth less per name than the other two. A name in it may never have existed: a typo somebody typed once, a name that resolved for an hour years ago, an internal name that leaked out of a laptop on a hotel network. A host nobody outside ever looked up is not in it at all.

And a fourth, where this installation was told to: the hosts themselves. Each name that answers is asked for the certificate it presents, and the names written in it are kept. That is how a name a private authority issued reaches an inventory at all — no public log holds such a certificate, because nothing submitted it and nothing would accept it. A handshake is made and closed, nothing is requested over it, and the certificate is read rather than judged.

A fifth, where you are the one asking: the reverse records of an address range you name, which finds a machine from the other direction. A domain can be proven with a record in its zone and an address range cannot, so a copy anybody can reach refuses a range even from somebody who proved a domain — while a copy only you can reach, or one behind a password you set, reads it, because there the person asking is you. This demonstration is the first kind, so the field is not on its page; your own copy shows it, and so does porch-scan -check names -ranges 203.0.113.0/24 example.com, for a domain proven to it. A range wider than a /20 (a /116 for IPv6), or ranges holding more than 4,096 addresses between them, are refused rather than cut short: a walk that quietly stopped would report on addresses nobody was told were left out.

And the names you already have, taken as given. They are typed one to a line or separated by commas, or read from a text file; blank lines and lines beginning with # are skipped. The file is read in your browser and never uploaded, but the names in it are what it is for: they leave the page in the same request as the domain, and each is then resolved by this installation's resolver like any name a source found. Up to 1,000 names; a longer list is refused rather than cut short, because a list that long is a wordlist rather than an estate, and this mode does not try wordlists. The demonstration's estate is compiled in, so the field is only on your own copy.

Every name says which of them named it, and that column is the one to read first. A name only a log has is a host somebody obtained a certificate for — if nothing answers there, the certificate is the thing to look at. A name only your records have is a host you publish yourself, which may be plain HTTP or a mail server that never needed a certificate. A name both have is the ordinary, well-kept case, and it is the line nobody needs to spend time on.

Each source also reports for itself. A monitor that is unreachable and a domain that publishes nothing produce the same empty list, so the inventory says, per source, what it named or why it established nothing. A short inventory must never read like a complete one.

What is sent to your domain

Three lookups, and not one invented name. The certificate half sends your domain nothing at all: it is read out of a public register. The other half asks your domain for the three records it publishes for anybody — its mail exchangers, its sender policy and its delegation — which is the same reading any mail server does before delivering to you. Nothing is sent to the hosts those records name.

No name is guessed. There is no wordlist, no attempt at mail, dev, staging or old. A tool that tried those would be enumerating an estate, which is a different instrument with a different argument for existing — and it would send that guessing to your servers. The boundary is written into this project as N7 and it is not moved for this page.

Who is asked, and what they learn

A monitor this project does not run: crt.sh, or SSLMate's index, whichever this installation was started with. Your own records are read by this installation's resolver, which is the one it already uses for every other check, so no third party is added by that half. The monitor's question contains your domain, so what it learns is that somebody is looking at it. The certificates themselves are already public — that is what transparency means — so nothing about the domain is disclosed by asking. What is disclosed is the asking.

That is why an installation produces an inventory only for a domain it has been shown control of. Everything else here measures how a host answers, which is what any visitor learns and which the scanned party can see happening. This produces the shape of an estate, and the scanned party cannot see it happen at all, so a copy answering it for strangers would be an anonymous reconnaissance service.

Every copy asks, including one only you can reach, and so does the command line. A copy on this machine's own loopback was once let off, on the ground that nobody else could reach it; another user on the machine, another container, and a web application with a request forgery in it all reach loopback too, and since 2026-09-29 nothing is let off. A record published once covers every check under the domain for as long as it is there.

What it cannot show

This is not a list of your hosts, and reading it as one is the mistake it is built to prevent. Three kinds of name are missing from it and no amount of searching will produce them.

Two incomplete sources make a longer list, not a complete one. That is why each name carries what named it and each source says what it could not see, rather than both being poured into one list with a single number at the top.

Every one of those is a name a port scan would find and this will not. The two methods answer different questions, and a report that let its reader forget which one it answered would be worse than no report: a list of forty names, handed to a security team as an estate inventory and then shown to be short by a scan, costs whoever handed it over more than the list was worth. The limits are printed under every inventory for that reason, including the short tidy ones where a reader is most inclined to believe the list is complete.

Nothing here is graded

No document says which names an estate ought to have, so a verdict would be a threshold this project invented — and a threshold nobody can argue with is one nobody can correct either. There is no rule set behind this page and no version to compare between two runs. What there is, is a list, the dates each name was covered between, and the sentence saying what the list is missing.

The dates are worth reading. A name whose newest certificate expired two years ago is either gone or is now covered by a wildcard, and an operator reading an inventory of their own estate is usually looking for exactly those. Which of the two it is, this does not say: it has asked the host nothing, and saying would be inventing the answer.