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.

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 anybody else can reach 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.

A copy nobody else can reach is a different thing: it is the command line with a browser in front of it, and the command line has never asked an operator to prove they own their own domain. Publishing a DNS record to prove that to yourself, on a service only you can reach, is friction bought with no safety — and friction bought with no safety is how a rule comes to be turned off altogether. Where verification is configured it is enforced wherever the service listens, because setting it up is an operator saying what they want.

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.

A host with no publicly trusted certificate. Plain HTTP, a service that is not HTTPS at all, or anything behind a private authority leaves no trace in a public log.
Anything behind a wildcard, unless a register was read. *.example.com in a log says the hosts exist and nothing about what they are called, which is exactly what a wildcard is for. The report counts the wildcards it found, because that count is the measure of how much it could not see.
A name dropped from a monitor's history, or logged before that monitor's records begin.
A host your own records have no reason to name. They name what they must: the machines that take your mail, the hosts allowed to send as you, and the servers that answer for the zone. A web server that takes no mail, sends none and answers for no zone is in none of 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.