About issued.live

What this service observes, how every published figure is measured, and where the record stops.

issued.live is a Certificate Transparency and DNS observatory. It reads the public CT logs, resolves DNS from seven vantage points and loads ICANN zone files. The result is published as domain records, an API and daily files.

It is built for threat hunting, incident response and brand protection. The collection is open source and adjacent to SIGINT in shape only: bulk, continuous, and read from public logs rather than elicited from a target.

What issued.live records

Every publicly trusted certificate authority must submit the certificates it issues to append-only Certificate Transparency logs. Anyone may read them. We read all of them, continuously, and record what appears.

Certificates give the record its names. For a domain we keep the SSL certificate observed for it, its issuer and its expiry. We also keep when the name first appeared in any log.

DNS resolution runs on its own schedule. Six record types are tracked: A, AAAA, NS, CNAME, TXT and MX. We keep the addresses a name answers with, and the network and organization behind each one.

Volume, measured on one day: 21,958,719 distinct certificates covering 9,815,205 distinct domains on 2026-09-17. The corpus passed 435 million domains in September 2026, and the home page prints the current figure.

Who runs it

Tuxxin LLC operates issued.live. If a record looks wrong, tell us and include the domain and the field.

Where the data comes from

Certificate Transparency logs, read directly

Nine operators run the logs we read, and every one of those logs appears in both the Google and Apple trusted lists. On 2026-09-18 that was 69 logs, all of them reading.

Four sharded tailer services do the reading. The home page shows how many are currently reading, because a log can stall and the count should say so.

Reading runs behind the logs. On 2026-09-18 the cursors stood 1.45 billion entries short of the reported tree sizes. A certificate can exist for some time before it appears here.

Every record shows what we saw, and when.

ICANN zone files, from one source

ICANN's Centralized Zone Data Service supplies every zone file we hold. 1,080 top-level domain zones have been loaded, and 1,069 of them were refreshed within the last seven days. A typical day loads between 1,017 and 1,053 zones.

Those zones describe about 256 million domains between them. The com and net zones are not among the approvals, so names under them reach the corpus through CT and DNS instead.

A zone file proves a name exists. It supplies no registration date, and the field reads null rather than a guess until we hold one.

Our own resolvers, from seven vantage points

Seven resolvers are registered and writing: fra, nyc, dal, lax, nrd, fr-pve01 and fr-pve03. The last two sit in France and were added on 2026-09-15.

nrd is a separate lane for newly registered domains and NXDOMAIN scanning. The others run the forward sweep across the corpus.

Passive DNS products record what someone else's resolvers saw. Here the resolution is our own forward sweep, so every DNS timestamp is our observation time and is labeled that way.

The four original resolvers are single-core machines. fra runs at load 1.87 with massdns holding 88% of its one core, which is the ceiling on how often the sweep comes back around.

Around 329 million domains answer with at least one A record and 108 million with at least one AAAA. About 105 million have never resolved to an address for us at all.

Address ownership from worldip.io

worldip.io supplies the network, organization and location behind an address. Everything else on a page is our own observation.

What a hunter can do here

Read a timeline and see the automation

/api/v1/timeline/{domain} returns every dated event we hold for one domain, in order, with the gap to the previous event in seconds.

The interval is the part that reads. Bulk-provisioned infrastructure has tight, regular gaps that no human produces.

A live example found on 2026-09-17: page.plesk.103-150-186-141, whose certificates arrived 3,599, 3,607, 3,593 and 3,609 seconds apart. That is an hourly cron, and it stays invisible until the deltas are computed.

Precision travels with every event

Our sources have very different time resolution, so each event carries a precision of exact, day or observed.

A certificate's not_before is the CA's own clock, exact to the second. A registry date or a zone file gives day resolution.

A DNS or address event carries our observation time. One domain's address changes read 109,922, 147,760 and 172,931 seconds apart. That describes our sweep interval, and the domain may have moved minutes after we looked.

A consumer who fingerprints on gap_seconds without reading precision will measure our scan schedule and call it an adversary's cron. That is the single most likely way to misuse the endpoint.

The endpoint also separates "nothing observed" from "nothing happened". A 404 says we hold no registration date, certificate, address or DNS change for that domain, and says nothing about whether the domain is active.

Each reply carries cert_window_days, so a short timeline is never read as a quiet domain.

One issuance is one event

Every issuance reaches CT twice, once as a precertificate and once as the final certificate, sharing not_before. Events group on that value, so an issuance appears once instead of twice zero seconds apart.

An address rotation that swaps eight addresses at one instant is reported as one event. Emitting eight buries the timeline in the noise it exists to remove.

Gaps are computed in the handler. They lived in the query first, and a test against a different database returned every gap null. It failed silently, because a missing gap looks like a first event.

Pivot on an address, a certificate or a key

Infrastructure pivoting is what the keyed endpoints are for. An address, an address range, a name pattern, a certificate hash or an SPKI hash turns one observation into the set around it.

Reverse IP runs on its own index, and the address data is stored twice, indexed in opposite directions. That is permanent.

The measurement behind it: under the domain-ordered sort key, one address spans 29,199 granules and 239 million rows to reach 93,036 matching rows. That is 2,571 rows read for every row returned, and every alternative that was tried timed out.

What the second index buys, measured: a /24 of 256 addresses read 15.7 million rows in 365 ms. The same /24 had read 669 million rows cold minutes earlier.

Placeholder addresses stay expensive. 8.8.8.8 is a popular placeholder A record, and it spans 19,944 granules and 163 million rows. The same lookup for 157.240.17.8 reads 2,480 granules and 20.3 million rows, close to the bloom filter's false-positive floor.

Compare what each vantage point saw

A name can answer differently by geography, and the vantages confirm at very different times.

Measured on one domain on 2026-09-13: fra was one day old, lax eight, nyc twelve and dal twenty-one, all four holding the identical value. A single merged answer hides that, so the per-vantage view shows which vantage saw what, and when.

Freshness needs care for a second reason. A per-name last-scanned time advances on timeouts and NXDOMAIN too, so a dead name can display stale values as freshly confirmed. Confirmations are therefore recorded per name, record type and vantage, and only where a re-resolution returned exactly the stored values.

Treat subdomain entropy as signal

High-entropy hostnames are the most expensive strings to store and the ones worth keeping. One day holds 24.4 million distinct subdomains across 43.0 million rows, so 57% of them are unique.

Machine-generated names look like direwolf-4d0e2a5a48-7ad8e62babf3 or 103-150-186-141. DGA hosts, fast-flux C2, kit-generated hosts and lookalike names under a victim's zone all have that shape.

Typosquatting and phishing infrastructure surface the same way. The shape is a newly registered domain under a brand's pattern, a certificate minutes later, and an address that other names in the same batch also answer with.

Certificate validity is itself a fingerprint. 90 days covers 65% of all certificates, and the top eight validity values cover 90%. A 90-day certificate and a 398-day one describe different operations.

How long each dataset is kept

Dataset	Retention
Certificates in the queryable database	48 hours live; older certificates are searchable on Pro from the permanent archive
Daily certificate files	Archived permanently
Current DNS answer	Held while the name resolves
DNS change history	18 months
Registration data	No expiry
Address history and the reverse-IP index	No expiry

The live window is a decision about cost, not about what we keep. Certificates are the one dataset stored as raw observations, and holding them queryable is expensive; 48 hours covers "I just found this", which is when a hunter wants the internals interactively.

Older certificates are not gone and no longer need a file. Every closed day is archived permanently, and on Pro the same /api/v1/cert/ endpoint searches those archived days directly — seconds rather than milliseconds, but an answer rather than a download. Interactive archive coverage begins 2026-09-09.

Certificates are the one dataset stored as raw observations rather than as state plus deltas, which is why the window is short. Three 32-byte hashes are 42% of the table at roughly 10 GiB each, and hashes do not compress, so the cost scales linearly.

For contrast, 5.7 billion DNS records fit in 66 GiB. Thirteen months of hot certificates was costed at about 3.6 TB, roughly four times the whole disk, and declined.

Every daily file we publish is archived permanently. The archive begins with the files for 2026-09-17 and accumulates forward from there.

A day of change is about 70 GB compressed across ten files. That day held 770,462,245 dns_vantage rows, 708,669,426 dns rows, 451,255,814 address_history rows, 196,680,765 domains rows and 56,454,989 certificate rows.

DNS change history stays at 18 months because age and value run in opposite directions in a change log. A time-based cut would delete the slow-burn domain's twelve changes from six months ago and keep every one of a CDN's changes from last week.

The change log has limits worth knowing before you build on it. It records replace, grow and shrink, so it answers what a record became and never what was there before it.

It is also sparse. Change history covers 200.75 million keys against 5.7 billion current records, so 96.5% of current DNS has no history row at all. Most names are observed and never move.

How the published numbers are measured

Counts here come from uniq(), a HyperLogLog estimate carrying roughly 0.5% error. The domain total is an approximation, and saying so costs less than the alternative.

Counting stored rows is that alternative, and it lies. The domain table is an AggregatingMergeTree whose rows inflate before merges collapse them, measured at 2.05x. Counting them once published 12.5 million domains when the real figure was 6.1 million.

The same trap sits on addresses: 13.1 million raw rows against 1.66 million distinct addresses, an 8x overstatement. A number that is twice the truth is worse than no number.

Home page figures are precomputed every ten minutes. Six live aggregates were costing 572 GiB per hour of reads, and 78.5 million rows were read on every single request to print four numbers.

A missing, corrupt or stale snapshot falls back to the live queries, so the page degrades to slow instead of blank. A snapshot reporting zero domains is refused outright, because a zero on the public page reads as a dead pipeline.

Issuer counts run about 7% high by design. They count domain and certificate pairs, and 7.16% of certificates span a day boundary. The duplicate-safe form measured 6.6 s against a 10 s query limit.

Where a field is unknown we leave it empty rather than infer it. Registration and expiry dates appear only where we hold them, and until then they read null.

What this service does not do

No active TLS probing

Nothing here is obtained by connecting to a subject's host. We report what a log published or what a resolver answered.

JARM, TLS version, cipher, key exchange and client certificates were costed and declined. A single handshake from fra measured 35 to 187 ms, and a full JARM is ten handshakes per target at roughly 450 ms.

Covering 135 million unique addresses at 24-hour freshness needs 391 handshakes per second per node. Measured throughput was 13 per second.

No registrant identity and no WHOIS crawler

Registrant contact data is not collected, and the domain table holds no registrant column of any kind. We keep the registrar and the source of any RDAP answer.

There is no per-domain WHOIS or RDAP crawler. Registration dates come from the ICANN zone-file feed, and RDAP is fetched only on the newly-registered-domain lane.

JA4X is reported, and no search pivots on it. 235 distinct values across 20.3 million certificates mean a search on it would return a third of Let's Encrypt.

No history from before we started

What this sells is a current state plus a forward-running change history. Dated point-in-time snapshots of the past do not exist here, and the comparison page says so against the vendors that have them.

We do not issue, sell, renew or transfer domains, and we have no authority over any name. We observe certificates and validate none of them.

A page describing a domain is an observation about a third party. It carries no relationship to that domain's owner.

How domain pages are handled by crawlers

Domain pages are never listed in the sitemap. Filling a sitemap with hundreds of thousands of generated URLs is what caused a delisting on a sister site.

Domain pages never link to one another. A spiderweb of internal links between addresses, networks and organizations multiplied crawl demand enormously there.

Each domain page carries issued.live's own title and description plus an explicit line saying we are not affiliated with that domain. Reproducing a subject site's own metadata reads as impersonation, and it was flagged that way once.

How to start

The public record API is free: 1,000 requests a day per client IP, no account and no key, resetting at 00:00 UTC. A paid plan removes the daily cap entirely — what bounds it then is a per-minute ceiling, and for the advanced queries how many you may run at once.

Basic at $39 a month adds the domains and dns daily files. Plus at $99 a month adds every dataset in bulk — dns_vantage, certificates and address_history alongside the other two — and opens the keyed lookups: reverse IP and address ranges, the certificate and SPKI pivots, the extended record and the domain timeline by API. Pro at $199 a month adds the sweeps — name-pattern search, batch lookup, the newly-registered and provisioning feeds, and certificates on an address — and certificate lookup against the permanent archive.

Any paid plan unlocks the extended record for a domain you look up, Basic included. The line between Basic and Plus is whether you can query the corpus by something other than a domain name; the line between Plus and Pro is whether you can sweep it.

Start with the API documentation, the daily file reference, the download catalog or pricing.

Figures on this page were measured on 2026-09-18 unless a different date is given. Corpus counts move daily; the home page carries the live ones.

Last updated September 18, 2026.