Summary

  • DNSViz is an open project for diagnosing, visualising and measuring DNS and DNSSEC. Casey Deccio created and maintains it; DNS-OARC operates the public instance under dnsviz.net. Hosting and software authority are not the same thing.
  • The central result is a graph of authentication and delegation relationships. It connects DS records in the parent zone, DNSKEY records in the child zone, RRSIG signatures and NSEC or NSEC3 proofs, and shows which link appears missing, outdated, contradictory or cryptographically invalid.
  • DNSViz is a suite, not just a website. The command-line workflow separates collection, analysis and presentation throughprobe,grokandgraph. This makes it possible to retain observations, automate checks and run analyses from private or controlled networks.
  • A result is evidence from a particular place at a particular time, not a universal certificate. Anycast, split-horizon DNS, resolver caches, trust anchors, algorithm rules, temporary packet loss and rapid rollovers can produce differing observations.
  • DNSViz does not repair a zone automatically, and a warning does not by itself determine business damage. A green graph does not guarantee that every resolver will succeed; a red graph describes a technical state without proving malicious intent.
  • The April 2025 release extended evaluation of multi-signer operation, CDS/CDNSKEY signals, negative-answer consistency and further modern cases. This reflects the growing complexity of provider changes and automated parent–child changes.
  • Repeated public diagnoses have also created a research corpus. A 2025 study used numerous DNSViz snapshots from 2020 to 2024 to examine DNSSEC errors at scale. Selection, scan schedule and retention nevertheless limit representativeness.
  • DNSViz matters because domain operators, authoritative providers, registrars, registries and resolver teams can all look at the same error explanation. Long-term value depends on release continuity, maintenance succession, clear service rules and combination with logs, individual queries and change records.

When a secured domain suddenly appears as “bogus”

A DNSSEC failure often reaches operations as a heavily abbreviated verdict: a validating resolver marks the answer asbogus, an application can no longer resolve a name, or monitoring reports that a signed domain has become unreachable. Such a report can be technically correct and yet operationally poor. It says that a chain of evidence was not validated, but does not immediately show which organisation, which record or which step of a change caused the interruption.

The problem lies in distributed responsibility. The parent zone publishes information about the child zone, the child zone publishes keys and signatures, authoritative servers deliver the data, and resolvers apply trust anchors and local rules. An outdated DS can make a correctly signed child zone invalid; an expired signature can break a correct delegation; a negative answer can fail even though the name really does not exist. DNSViz expands the terse verdict, collects authoritative data, reconstructs the relationships and marks the suspected break.

It does not make DNSSEC simple, but it makes the complexity visible enough for the next check to become recognisable.

DNSSEC spreads a decision across several organisations

Ordinary DNS resolution already crosses several systems; DNSSEC adds a cryptographic dependency to the administrative one. Parent and child zones do not merely delegate responsibility. They must publish records whose mathematical relationship remains consistent during key changes, provider migrations and cache lifetimes. No party necessarily controls the entire path. That is why a fault can persist even when every organisation considers its own subsystem correct.

The parent zone usually expresses its role through a DS that refers to the hash of a DNSKEY in the child zone. The child zone publishes DNSKEYs and signs record sets with RRSIG; the resolver follows this evidence from a trust anchor to the target name. When registrar, registry, signer and DNS provider are different parties, contractual responsibility also fragments. DNSViz does not decide who is responsible, but places the observed records and links in a common frame. That is more useful than exchanging isolated command outputs between teams.

The protocol is already a graph, even when tools output it line by line

Classic DNS tools are indispensable because they show precise records and response fields. Their presentation, however, is usually linear: one query, one answer and one record after another. The operator has to assemble the dependencies mentally — from the parent-zone delegation through the child-zone keys and signatures to the proofs for non-existent names. During a rollover or a multi-provider migration this reconstruction quickly becomes confusing.

DNSViz makes the dependency structure the main entity. Names, keys, record sets and trust relationships become nodes and edges; warnings attach to the affected connection. The visualisation is not decoration but reflects the shape in which validation actually proceeds. From a faulty link the user can descend to the underlying records. The graph makes collaboration between specialists and general operations easier without replacing expertise; dense diagrams remain dense, and colour must never crowd out the records themselves.

A DS record is the parent zone’s promise about the child zone

The DS is small but consequential. It sits in the parent zone and identifies a hash derived from a DNSKEY in the child zone. It thereby connects authenticated parent-zone data with the child-zone signing material. If hash, key tag or algorithm no longer match, the chain can break even though both zones continue to answer ordinary DNS queries.

Such discrepancies often arise during key changes, provider migrations or incomplete rollbacks. The child zone may remove an old key before the corresponding DS disappears, or the parent zone may publish a new DS before all authoritative servers show the expected key. DNSViz compares the observed DS and DNSKEY material, but it does not know the planned sequence. A temporary overlap can be intentional; a permanent discrepancy is not. The graph must therefore be read together with change tickets, provider documentation and expected propagation times.

DNSKEY records divide signing roles but do not remove operational risk

A signed zone can publish several DNSKEY records to separate roles, ease rollovers or support several signers. Some keys secure the key set itself, others the zone data; implementations and operating models organise this division differently. The architecture becomes more flexible, while the number of states that must remain consistent grows.

DNSViz shows which keys exist, which signatures depend on them and how they connect to the parent zone’s DS. This makes visible a key without an expected signature, a signature for a missing key, or a server with an older key set. The graph describes publication, not custody of private keys or the quality of internal processes. A zone can be technically green and organisationally poorly run; a temporary overlap can be entirely legitimate in a clean rollover.

RRSIG validity depends on time, coverage and the right key

RRSIG turns a record set into a verifiable statement. Each signature names the covered type, the algorithm, the key tag and a validity window. Verification can fail because the cryptography does not fit, the corresponding DNSKEY is missing, the wrong record set was signed, or the observation time lies outside the window.

Time therefore belongs to diagnosis. A wrong clock, late renewal or uneven publication on different servers can produce temporary or persistent errors. DNSViz links signature, key and record and shows time problems in the same model. Nevertheless the probe’s clock, the measurement time and the resolvers’ cache states all matter. Operators should record the analysis time and compare it with the signing schedule.

NSEC and NSEC3 prove absence — and make error explanation harder

DNSSEC does not only authenticate existing data. It must also prove that a name or record type does not exist. NSEC and NSEC3 form signed proofs over ranges of the name space. If the proof does not cover the query, a valid signature is missing, or it does not fit the delegation, a resolver can still reject a substantively correct negative answer.

DNSViz examines these relationships and shows why a “not present” was not accepted. NSEC3 adds parameters, hashing and options such asOpt-out, which create further edge cases. The April 2025 output improved checking of negative-answer consistency and shows that this area needs ongoing care. The aim is not to squeeze all the cryptography into a picture, but to connect the concrete proof with the name it is supposed to cover.

Casey Deccio developed DNSViz where protocol theory met operational confusion

DNSViz emerged from Casey Deccio’s work at Sandia National Laboratories, when DNSSEC deployments exposed problems that were hard to explain with a list of individual records. The task was not merely to determine pass or fail, but to present the reasoning so that an operator can find the broken dependency and act carefully.

The project should be distinguished from Deccio’s whole career and from his original institution. Sandia was the research environment; Deccio later maintained the suite; DNS-OARC operates the public instance. This distributed history mirrors the system itself: no single body sums up the whole project. Precise attribution honours the individual origin without deriving from it exclusive legal or institutional ownership.

The 2012 Sandia work turned validation into an explanatory model

The 2012 report documented a visual approach to DNSSEC analysis. It invented neither the records nor the validation procedure, but arranged the evidence as observable relationships. This made it possible to locate the error and to provide a richer explanation than a single error code.

The research origin shapes the method: collect data, build a model and preserve enough detail for others to check the judgement. It also sets an editorial boundary. A report by those involved is a strong primary source for the design, but not proof of universal use or effect in every network. The later development into a downloadable suite, a public service and a research corpus shows how a prototype became shared infrastructure.

Portability turned a website into reusable infrastructure

Between 2013 and 2014 DNSViz was reworked for portability and extensibility. Its presentation at a DNS-OARC workshop brought the project into the operator community; the command-line package allowed execution outside a single web demo. Software, hosted service and the data of a concrete observation were thereby more clearly separated.

This separation enables automated measurements, stored results and analyses in private networks. It supports reproducibility as long as version, time, query conditions and parameters are recorded. The architecture makes this discipline possible but does not enforce it: results from different versions can apply different rules. Operational value therefore depends as much on the procedure around the tool as on the code.

proberecords what the authoritative system actually says

Collection queries the delegation path and relevant servers for NS, DS, DNSKEY, RRSIG, NSEC, NSEC3 and associated metadata. That is different from asking a resolver for the final application output: the probe gathers the parts that a validator would have to connect.

probeseparates this observation from the later analysis. Operators can store the output, compare points in time, or measure from a network that sees an internal view. Researchers can re-evaluate the same data after a zone change. The measurement remains dependent on packet loss, filters, anycast selection and temporary silence. An unobserved answer therefore does not always prove a persistent authoritative state.

grokshapes observations into a reasoned dependency model

Raw answers are necessary but not yet a diagnosis. It must be checked whether a DS matches the key, whether signatures cover the right records and are valid, and whether a non-existence proof covers the query.grokapplies the protocol rules to the collected evidence and constructs the model of delegation and authentication.

This is where DNSViz changes from collector to analyser. It can mark missing signatures, incompatible algorithms, expired data, faulty delegations or contradictory answers. The result is an interpretation of a particular software version, not a neutral transcript. Raw data and analysis version should therefore be preserved; no warning colour is true independently of the rules that produced it.

graphlets the chain be checked without hiding the records

The presentation stage turns the analysis into a graph for browser or file. It must reduce the cognitive load of the chain while preserving enough detail for specialists to follow the judgement. DNSViz’s value lies in connecting an understandable view with records, keys and signatures, not in replacing them with a score.

Nodes and edges show which entities delegate or authenticate others; annotations point to the problematic relationship. The operator can start at the broken path and open the underlying evidence. With multi-signer zones, overlapping rollovers or inconsistent servers the picture becomes dense because the real state is dense. Good visualisation helps navigation and leaves open the possibility that the right conclusion is: more evidence is needed.

DNS-OARC keeps the public service running without owning the whole project

A public diagnostic tool becomes infrastructure only when someone keeps it available, updates dependencies and responds to outages or abuse. DNS-OARC gives dnsviz.net this operational home and ties the service to a community that works daily with authoritative servers, resolvers and DNS measurements. This continuity should be distinguished from code maintenance and standard-setting.

The sources are clear: Casey Deccio develops and maintains DNSViz, DNS-OARC operates the public instance. A discussion from 2021 repeated this division of roles in connection with support for newer algorithms. It prevents every software decision from being attributed to DNS-OARC, but requires coordination on releases and incidents. A dedicated budget, a complete public SLA or a detailed succession plan have not been disclosed; the visible stability therefore rests on institutional work whose framework is only partially documented.

Public endpoint and local suite answer different questions

The website quickly provides an outside view. An operator can check a name without installing anything, share the graph with another organisation and use it in an incident as a common reference. The low entry barrier also has educational value: someone who does not master every DNS tool can still follow a chain that would otherwise be spread across many individual queries.

A local installation meets other needs. It runs in private networks, can be built into deployment processes, stores raw observations and pins the version used. It can also see split-horizon views that remain hidden from the public service. This is not merely convenience versus aspiration: the public endpoint provides independence from one’s own network, while local execution provides access and control. A robust investigation can use both and compare them with real resolver behaviour.

A DNSViz result belongs to a place and a time

Every active measurement has an observation point. The probe sends queries from a particular network, reaches concrete authoritative instances and records their answers under the routing conditions of that moment. DNS distributes services deliberately; DNSSEC adds time-bound signatures and cached delegation data. The graph is therefore a situational observation, even though the interface shows it as a single picture.

This limit does not weaken the statement but makes it honest. DNSViz can explain why the observed chain appears valid, insecure or broken according to its rules. It cannot confirm that every user received the same records. The sensible response is comparison data: another location, authoritative logs, resolver traces and a fresh measurement after the cache expires. The graph opens this comparison; it does not close it.

Anycast can make an authoritative service look like several systems

Many DNS providers announce the same address from several locations using anycast. Routing sends different queries to different sites, which improves latency and resilience but can also expose not fully aligned zones, versions or key states. Two users can query the same IP and receive different DNSSEC material when one site holds an old key or has not yet received a signature.

DNSViz shows the evidence of the site it reached, not of all sites. If a key appears on some servers and not others, the graph should trigger measurements from several networks and a per-site rollout check. In DNSSEC, inconsistency is especially consequential because resolvers do not simply tolerate different content; they need a valid chain for the content they receive. Anycast explains the possibility of divergence but does not legitimise its permanent state.

Split-horizon DNS marks the boundary of every public diagnosis

Split-horizon DNS returns different answers depending on the client network. Internal users may see private addresses or names that do not appear in the public zone; external users receive a reduced view. This may be intentional, but it means that a public analyser only knows the internal view if it is authorised and placed there.

A green public result therefore says nothing certain about an application with a different delegation; a red result for a purely internal name can be irrelevant. The local suite brings the same model to the place where the private view is visible and avoids sending sensitive names to a public service. Openness makes this control easier, but does not replace the organisation’s access, storage and data-protection rules.

A green graph is evidence, not a universal availability certificate

A successful graph shows that the observed relationships appear consistent at that place and time. That is strong evidence about the collected authoritative data, but not proof that every resolver reaches the domain. Other users can experience different routes, caches, trust anchors, algorithm rules or network faults.

Resolvers also implement local restrictions that a general diagnostic tool does not reproduce. An implementation can disable an old algorithm, hold a negative answer in cache or fail to reach a site; above DNS, TLS, transport or the application can fail. The robust formulation is: the observed chain validated under this version, rule and time. DNSViz narrows the error space, but does not automatically dismiss user reports outside its view.

A red graph describes a state, not an attacker

A missing key, outdated DS or invalid RRSIG can result from an attack, but just as easily from a hasty rollover, registrar delay, incomplete migration or software error. The graph shows which relationship does not fit; it does not prove who intended that state.

Security teams should not confuse visual severity with attribution. An expired signature is important but not proof of compromise; an unexpected DS can belong to an authorised change. Assessment requires change history, registrar records, authoritative logs and responsible contacts. This care prevents both rolling back a legitimate migration and overlooking a hostile change. DNSViz supplies a technical finding that must be correlated with further evidence.

Multi-signer DNS creates choice and a denser diagnostic graph

A zone can distribute signing or authoritative service across several providers to increase resilience, ease migrations or reduce dependency. The systems must publish compatible keys, signatures and delegation data; at the same time the number of legitimate transitional states grows. The commercial benefit is paid for with additional cryptographic and operational coordination.

The April 2025 release extended multi-signer analysis and comparison of authoritative answers. The models described by the IETF coordinate keys and signatures differently; a dense graph therefore does not prove bad design, but shows the coordination cost of resilience. Operators need documented roles, tested rollovers and criteria to distinguish planned overlap from a stuck migration. DNSViz shows the state; the team must supply the intent.

Provider migrations create legitimate states that look like errors

A change of authoritative or signing provider rarely happens atomically. New servers and keys are added before old ones are removed, while the parent zone’s DS changes at a different pace. Several key sets and signatures can temporarily coexist correctly; a tool that only expects the end state could mark this safe overlap as an error.

The opposite is more dangerous: the transition gets stuck in a state that was planned only for the short term. A provider continues to serve an old key, a registrar change does not reach the registry, or a rollback removes records in the wrong order. DNSViz shows the entire observed relationship. Evaluation belongs in the migration plan: measure before and after each step, preserve results, and define how long a warning is permissible. The same finding can be expected within a window and a reason for escalation outside it.

CDS and CDNSKEY automate delegation changes and shift risk into policy

CDS and CDNSKEY allow the child zone to signal desired changes to the parent zone’s DS. Automation can reduce manual work and errors during rollovers, but creates a new trust relationship: registry or registrar must decide when and under what conditions they accept the signal.

DNSViz compares the signals with the child zone’s DNSKEYs and the parent zone’s DS; the April 2025 release extended this evaluation. The tool can show that a relationship is consistent or incomplete, but cannot impose a uniform acceptance policy. Control questions remain open: who authorises the initial trust, how are deletion signals handled, and what happens when a provider publishes unexpectedly? Security depends as much on policy and investigability as on the correct record.

The April 2025 release brought modern operating models into the graph

A diagnostic tool ages when infrastructure changes faster than its rules. Modern deployments use newer algorithms, several providers, automated delegation signals and more complex negative answers. The April release closed part of this gap with multi-signer analysis, CDS/CDNSKEY checks and improved consistency handling.

Release notes prove existing code, not the upgrade of every environment and not the solution of every edge case. The public service may run one version, local packages another, and distributions follow their own schedules. When comparing historical snapshots with current diagnoses, the version must be preserved. The release also shows that relevance does not rest on a one-off invention: the project must continually translate new practice into diagnostic logic.

Longitudinal snapshots turn fault-finding into measurement infrastructure

A single graph helps in an incident; a sequence shows whether an error persists, how a rollover progresses and how quickly a chain is repaired. When many names are repeatedly observed with the same model, a research corpus emerges instead of merely a collection of individual queries.

The separation of collection and analysis makes storage, grouping and comparison possible. This archive is a second form of infrastructure: it documents how DNSSEC works in operation, not only how standards describe it. Historical data, however, must be treated cautiously. A snapshot can capture a transition that was repaired minutes later; problem-laden names can be over-represented; retention rules determine which trajectories survive. Methodological consistency does not automatically make a sample representative.

The 2025 study shows what a consistent diagnostic corpus can reveal

The 2025 research used a large collection of DNSViz results from 2020 to 2024 to examine DNSSEC errors at scale. Its importance lies in going beyond individual anecdotes: a standardised analyser can recognise recurring categories, measure their duration and check whether the same errors occur again.

The explanatory structure matters as much as the volume. A dataset of bare success and failure marks would say less about whether delegation, signature, non-existence proof or server consistency was affected. DNSViz supplies a taxonomy from its graph model. The study is nevertheless not a statement about every signed domain. Submissions, scan schedules and sampling define the population. Large numbers become credible only when it is understandable how they entered the corpus.

Anycast and observation point can pull two honest measurements apart

Authoritative providers often announce the same server address from several locations. Routing sends the query to a site depending on network state, so two observers under the same IP can reach different machines. If the sites are not fully synchronised, a DNSViz probe may see different keys or signatures than a resolver in another network.

Filters, fragmentation, transport mode and temporary loss also change the result. The system can retry and preserve metadata, but it does not see every relevant path. An external result is therefore strongest as a controlled observation that is compared with further evidence. For a distributed service measured from another distributed network, a divergence should initially raise questions about place, time and the instance reached — not the accusation that the tool or the operator is wrong.

Caches preserve old truths after the authoritative configuration has changed

Resolvers store DNS data to reduce latency and load. During a repair, the authoritative servers may already publish a new, consistent chain while some resolvers still use old DS, DNSKEY or RRSIG data until TTL expiry. DNSViz then shows the current authoritative state without necessarily reproducing the view of an affected user.

The opposite is also possible: a resolver holds a previously valid answer even though the current publication is broken, and delays the visible damage. The incident proceeds in stages and depends on cache history. Change time, TTLs, stored records and negative caches must be correlated. The graph supplies the authoritative relationship at a known time; resolver logs and cache inspection distinguish a continuing publication error from pure propagation time.

Resolver policy and trust anchors determine a result that the authoritative graph does not fully predict

Every validator starts with trust anchors and applies decisions of its implementation and its operator. In public DNS the root anchor is usual; private environments can set additional anchors. Algorithm support, exception handling, clock and software version also differ. A chain acceptable under one policy can fail under another.

DNSViz uses its own observation and analysis process. It is a strong independent control, but not a copy of every resolver. When results diverge, the operator should identify implementation and version, read validation logs and compare the cache with the graph. Usefulness does not require universal equality, but evidence that can be reproduced, disputed or supplemented. Open code and local execution support precisely this examination.

Protocol severity and business impact are different measurements

A broken DNSSEC relationship can go back to an attack, but equally to misconfiguration, delayed propagation, failed automation or human error. A non-matching DS proves that parent and child state do not form the expected trust path; it does not reveal whether someone acted maliciously, operated a registrar interface wrongly, or a rollover was observed in the middle.

Red can feel narratively stronger than the finding. DNSViz should record facts: which records were seen, which relationship failed and when. Attribution needs change history, account data, registrar records, provider evidence and possibly a broader security investigation. Warnings must also be classified: some describe risk or operational advice, not invalidity. Colour leads to the spot; the records determine the action.

DNSSEC validity does not check the rest of the application path

A valid chain shows that the observed DNS data can be authenticated over the expected trust path. It does not prove that the returned IP belongs to the application, that BGP reaches the server, that the TLS certificate is valid, that a firewall permits the traffic or that the application is healthy. DNSViz can rule out one layer while the cause remains elsewhere.

Even within DNS, an apex check does not necessarily cover aliases, service records, separate API names, mail policy or third-party domains. Operators must choose the names and types that the failing workflow actually uses. This limit does not reduce the value but forces precise statements. DNSViz answers about observed DNSSEC relationships and is most useful when it is not asked to vouch for systems it does not see.

The graph belongs in change checking before it appears in the incident room

The safest use of DNSViz begins before and after a planned change. For a rollover, registrar transfer, provider migration or multi-signer introduction, the team can run the command-line suite in a controlled environment, save the expected graph and define permissible intermediate states. Every production step is then compared with this plan.

Diagnosis thereby becomes a change-control instrument. The check can confirm that the new key is published, signatures are present, parent signals match and old material is removed only after the necessary overlap. A failed rule can stop the operation before users are affected. The project documentation enables automation, but release and recovery belong to the organisation. A context-free traffic-light signal is not enough; rule, entities and justification of the transitional state must be stored.

Incident response improves when all parties point at the same broken edge

A DNSSEC incident can involve the domain owner, DNS provider, registrar, registry, resolver operator and application team. Each party sees only a part and may initially report that its own system works. The graph creates a shared entity: it can show that the child zone’s keys exist but the parent zone’s DS is old, or that one authoritative server lacks another’s signature.

Shared evidence does not erase remits. The registrar can change the parent zone but not the signer; the DNS provider can correctly publish a key wrongly supplied by the customer; the resolver discovers the error without being able to repair it. The value lies in a precise request to each party. Result, time, version and detailed queries should be preserved so that everyone checks the same state and confirms its disappearance after correction.

Safe automation needs evidence, release and a way back

Connecting diagnosis directly to repair is tempting, but DNSSEC crosses caches and institutions that the tool does not control. Removing a DS, publishing a key or withdrawing a signature can repair one site and break another if the overlap was still needed. High diagnostic confidence does not automatically make a hard-to-reverse action safe.

Observation can be largely automated: collect, compare, warn and block a change when prerequisites are missing. Larger corrections need several observation points, confirmation of the target state, named release and a return path tested against TTLs. The audit trail must also contain the evidence that justified the action. DNSViz explains; whoever controls keys, accounts and policy retains authority.

Open source makes the method checkable, not maintenance automatic

The public repository allows investigation of how data is collected, interpreted and presented. An organisation can run locally, pin a version, check a rule and propose corrections. This traceability is central because the tool turns raw records into a diagnostic judgement.

The licence guarantees no releases, readiness, eternal compatibility or enough reviewers. The code can remain available while knowledge of difficult decisions sits with a few people. Anyone embedding DNSViz in production should treat it as a real dependency: pin versions, maintain reference tests, follow changes and contribute where possible. Open source creates capacity to act, but not automatic assumption of responsibility.

A small maintainer base carries knowledge that many operators use indirectly

DNSViz is not a large company with a published budget, headcount and commercial roadmap. The documentation names Casey Deccio as creator and maintainer, further contributors in the repository, and DNS-OARC as operator of the service. The exact number of active release owners and a complete succession plan are not public.

The spread of benefit contrasts with the size of the institution: domain owners, registries, registrars, providers, resolvers, researchers and security teams can use the same graph. The benefit is distributed, while the duty around edge cases, releases and public operation is concentrated. Risk does not arise automatically from smallness, but when dependency grows faster than knowledge transfer. Tests, documentation and additional reviewers are the appropriate safeguard.

DNSViz has no single competitor because DNS faults have several layers

dig,delvanddrillshow precise records; Zonemaster and Internet.nl run broader tests; RIPE Atlas distributes measurements; resolver logs explain real decisions. DNSViz differs through the authentication and delegation graph, but does not replace these perspectives.

The most sensible competition is complementarity. A detailed query confirms the RRSIG on an edge, a distributed measurement shows anycast differences and a log explains local policy. The graph orders the question; other tools deepen or contradict it. Making it the sole referee would weaken the method. Its authority comes from transparency and a cleanly limited claim.

The project makes cryptographic infrastructure readable without claiming control

DNSViz’s lasting achievement is bringing formal protocol and practical incident work together. Delegations, keys, signatures and non-existence proofs become an entity that several organisations can examine together. This shortens the path from abogusreport to the next useful question.

DNSViz manages no zones, publishes no parent-zone DS, determines no resolver policy and does not guarantee every user’s experience. Even public operation and code maintenance are separate. This institutional restraint allows autonomous actors to share the same evidence. The future lies not in an absolute judgement, but in a maintained model, sustainable governance and procedures in which human intent remains checkable.