Public Analysis UI

The public analysis UI is served at /analysis/. It is read-only and backed by public analysis endpoints under /pub/api/v1/analysis/.

Operators create tags, cohorts, batches, and snapshots through the admin UI or admin API. Public visitors only browse published cohort data.

Web Surfaces

Block / and /api/v1/ at the public reverse proxy. See ../server/public-api-and-proxy.md .

What It Shows

The UI presents one cohort and one snapshot at a time. Visitors can browse:

• overview metrics
• domains
• nameservers
• endpoints
• ASNs and prefixes
• finding tags
• testcases
• snapshot trends
• snapshot diffs

Clicking an entity such as a domain, nameserver, ASN, prefix, finding tag, or testcase opens a filtered detail view.

URL State

dataset_tag selects the cohort. snapshot pins the snapshot.

/analysis/?dataset_tag=tld&snapshot=2026-04-20-strict

The UI preserves the active snapshot as visitors click through detail pages. Shared links should include snapshot when the numbers must remain stable.

Some views add their own parameters: the diff tab, the trends focused bucket key and scale scale, and the domains list filters search, worst_level, grade, and dnssec_posture. Back, forward, and shared links reproduce the same view.

dnssec_posture takes one of unsigned, signed, nsec, nsec3, mixed. mixed means different servers of the same zone answered with NSEC and with NSEC3, so the zones serving NSEC3 anywhere are nsec3 plus mixed.

Overview

The overview page opens with stat tiles for the cohort: total domains, the share with no warnings, the share graded A or A+, and the share that is signed. Each tile shows the change since the previous snapshot and a small sparkline across snapshots. Below the tiles it lists the top issues and the main nameservers, ASNs, and prefixes, including the leading provider’s share of domains. A movers card lists the domains that improved or regressed most since the previous snapshot.

Distribution bars below the cards partition the cohort by domain health, grade, DNSSEC posture, DNSKEY algorithm, and IPv6 coverage. Health, grade, and posture segments link to the domains list filtered to that bucket. The other bars carry no link, since the domains list has no matching filter.

A posture segment matches no domains on a snapshot captured before the posture column existed. Rebuilding that snapshot’s views fills it in.

Trends

The trends page shows how the grade, severity, DNSSEC, and DNSKEY algorithm mix changes over time, one stacked bar per snapshot.

Click a bucket in the legend to focus it: the bars are replaced by a single line chart of that bucket across snapshots. key holds the focused bucket and scale switches between share and absolute count. Click the bucket again or press Escape to go back. A top-movers panel lists the finding tags that changed most between the first and last snapshot shown.

Snapshot Diffs

The diff view compares two snapshots of a cohort. A summary strip counts how many domains regressed, improved, were added, or removed. The change lists link each domain, and a grade-transition matrix shows how grades moved. Use the swap button to reverse the two snapshots; tab selects the active list so a shared link opens on the right one. When only a “to” snapshot is chosen, the snapshot before it is used as “from”.

Alongside the per-domain changes it shows a tag-level summary: which finding tags appeared, cleared, or changed severity cohort-wide, with domain counts. This makes a regression explainable, for example “14 domains regressed; DS02_NO_MATCHING_DS appeared on 12 of them”.

The Report

The page leads with a provenance banner naming both engine versions, both profile names, the tag vocabulary delta and the scoring configuration state. Below it, cohort-change tag rows render inline, while engine-driven rows and unattributable rows sit behind their own disclosures with their counts visible. A Movers tab lists each moving domain with its score delta, the part of that delta its findings account for, a cause chip and a cause filter. A clusters table names the domains that moved together behind a shared nameserver, ASN, prefix or software version.

What the classifications and the categories mean is in cohort-report.md .

“Export Markdown” writes the whole report as a Markdown document, and a print stylesheet makes the page print as the report.

The page degrades rather than failing. A server that predates the report keeps the engine banner and the tag tables it had; a snapshot with no materialized tag view shows a short notice rather than an error.

Latency

The nameserver, address, and ASN lists show a Latency column with the median (p50) and 95th-percentile response time aggregated from the queries the snapshot already recorded (no extra probing). The column only appears when the snapshot has latency data; snapshots captured before latency aggregation show no column until they are re-materialized (admin “Rebuild aggregates” or a cohort rebuild).

The queries were made from wherever the instance runs, so the figures describe one network vantage point rather than the entity’s latency everywhere. The column header and a footnote under the table repeat that caveat, as does the overview’s response-time card. When the operator sets analysis.vantage_label the caveat names the location (“Measured from Stockholm, SE; a single vantage point.”); otherwise it stays generic. See configuration.md .

Each sample is the response time of one answered query, so the figures cover the authoritative exchange only. Unanswered queries are excluded and counted separately, retried attempts never enter the sample, and the queries behind a snapshot mix query types and both UDP and TCP. Two snapshots are only comparable when they ran the same profile, since fast-fail, the latency budget, and retry degradation change which queries are made at all.

Entity History

The nameserver, ASN, tag, and domain detail pages show a small sparkline of how the entity moved across the cohort’s captured snapshots (domain count for nameserver/ASN/tag, score for a domain). It is fed by GET /pub/api/v1/analysis/cohorts/{dataset_tag}/history?entity=&key= and only appears when at least two snapshots carry the entity, so single-snapshot cohorts and brand-new entities show nothing rather than a flat line.

Reference Links

Every detail page carries an “Elsewhere” block linking the entity to its authoritative external reference. A top-level domain links to the IANA root zone database, its ICANNWiki page, and IANA’s RDAP service; any other domain links to an RDAP record for it. Addresses, prefixes, and ASNs link to RIPEstat.

The links are plain navigations: nothing is requested from a third party until a visitor clicks one. They open in a new tab with rel="noopener noreferrer", so the snapshot URL never reaches the target site.

Registry Data

When the server runs with external data enabled (see configuration.md ), the domain detail page adds a “Registry” card with the domain’s registration record: registrar, registry organisation, handle, status, registration, expiry and last-change dates, delegated nameservers, and whether the delegation is signed. The card names the RDAP service it came from and the time it was retrieved, and the RDAP link in the “Elsewhere” block then points at that service instead of a generic web client.

Registry data is not part of the snapshot. A snapshot records one measurement and never changes; a registration record changes on the registry’s own timeline, so it is fetched separately, cached, and labelled with its own retrieval time. It never feeds a fact, a bar, or an aggregate.

The server never fetches on the request path. The first visit to a domain the server has not fetched yet shows a one-line notice and the record appears on reload. Domains whose top-level domain publishes no RDAP service show that no data is available.

Keyboard Shortcuts

Press ? for the list of shortcuts. g followed by a letter jumps between sections (for example g d for domains, g t for tags), / focuses the search box, and Escape closes the help. Shortcuts keep the current cohort and snapshot.

Exports

The list pages export CSV and JSON. An export covers the whole filtered set, up to the server’s 500-row limit, not just the rows on screen. A note next to the buttons says how many rows it will include, and the file name marks an export that hit the limit.

Empty States

If the UI is empty after a batch finishes, check:

• the cohort has analysis_enabled=true
• the cohort has public_enabled=true
• the batch used the cohort source tag
• the batch was marked as snapshot-intent when it should publish
• GET /api/v1/analysis/status has no cohort error

If “Last analyzed” does not move, check server logs for analysis projection errors and inspect last_materialization_error on the cohort.