On August 21, 2026, Ravi Ojha posted a screenshot of a long public result and wrote, “did I just find every single org that uses slack?! this list is over 130k lines”. The question was more interesting than the count. A large list is easy to find. A useful dataset needs provenance, repeatable snapshots, and language that does not claim more than the source can show.
SubdomainData turns that one-time discovery into a daily record. It fetches the public crt.name search for slack.com, validates the entire response, stores an immutable snapshot, and makes the current set searchable. Names first seen after the baseline receive the date SubdomainData observed them. Names already present on the first successful pull remain Unknown, because the import cannot recover when they first appeared.
The upstream list is broader than certificate transparency
The domain name crt.name suggests a certificate-transparency lookup, but the service describes a broader index. Its documented inputs include live transparency logs recognized by Chrome and Apple, retired logs recovered through the Internet Archive, Common Crawl, ICANN zone files, ProjectDiscovery Chaos, HaGeZi DNS blocklists, and a prober for common hostnames. It normalizes those observations into apex, subdomain, and first-seen records and says that it does not delete names. The source inventory is published on the crt.name site.
That mixture changes the right description of the data. A row can originate in a certificate log, a web crawl, a delegated zone, a community dataset, or a probe. SubdomainData therefore calls its input a public hostname index, not a certificate list. The distinction is small in the interface and load-bearing in the methodology.
One complete pull becomes one published snapshot
Once per UTC day, the importer requests the plaintext endpoint without a cache. It lowercases each line, removes a final dot, accepts only valid DNS labels below slack.com, excludes the slack.com apex and wildcard entries, deduplicates the result, and sorts the names. Nested names such as an enterprise.slack.com address are preserved because they are still descendants of the Slack apex.
The importer does not publish records as they stream in. It stages the complete response under an isolated attempt, checks the staged row count, and rejects an empty result, an implausibly small first result, a later result smaller than the preceding completed snapshot, or a response beyond the configured safety ceiling. Only a complete winning attempt becomes the current snapshot. A failed attempt leaves the last completed snapshot in place.
Each completed snapshot keeps its own membership. That makes the chart and a purchased export reproducible even after a later daily pull arrives. It also prevents a page of search results from quietly switching to a different snapshot halfway through pagination.
The first import has no honest date added
Suppose the first pull contains 134,000 names. SubdomainData learned all 134,000 on the same day, but that does not mean they were added to Slack, DNS, a certificate log, or crt.name that day. Some may have been public for years. Assigning the launch date would manufacture precision.
The baseline therefore stores a null date and displays Unknown. On later pulls, a name absent from every earlier SubdomainData snapshot receives its first SubdomainData observation date. The field is called first observed in explanatory copy because it records a local measurement event, not workspace creation. The distinction follows the same general rule that governs transparency logs: an auditable event has a precise meaning, and adjacent conclusions need separate evidence. RFC 9162 defines the log event and proof model for certificate transparency.
Search stays bounded; exports stay tied to a snapshot
The browser never receives the entire directory just to make search feel instant. Queries run on the server, return a bounded page, and pin later pages to the same completed import. This keeps Turso credentials and the bulk dataset out of client code while preserving keyboard search, filters, counts, and deterministic pagination.
The Notable filter is a small, checked annotation layer. An exact public-name match can be associated with a Slack customer story or another company-controlled reference. The label describes the match and its source. It is not an assertion that the named company owns that hostname. The Enterprise filter is similarly literal: it selects the enterprise.slack.com hostname form described in Slack's URL documentation, not a verified billing plan.
A $50 CSV purchase unlocks the dated SubdomainData index snapshot visible at Checkout creation. Payment confirmation grants access to that specific membership rather than whatever happens to be current at download time. The export can carry useful annotations, but the core record remains the public hostname and its SubdomainData observation date. It is not a customer census.
What the dataset is for
Public hostname datasets are useful for research, market mapping, change detection, and defensive asset inventory. Security guidance such as OWASP's Web Security Testing Guide includes certificate-transparency search in attack-surface discovery. That does not make every inferred identity true, nor does it authorize intrusive probing.
SubdomainData is best read as an inspectable measurement pipeline: this upstream source, fetched on this date, transformed by these rules, produced this set. The current count will move. The baseline will stay unknown. Claims about operation, ownership, headcount, plan, or activity require evidence the list does not contain. The next article gives a claim-by-claim guide to those limits.