DNS and domain trust — DNSSEC, encrypted DNS, WebPKI, and certificate transparency

The internet’s domain name system is not just an address book. It is the substrate of much of the trust we extend to identifiers on the web: the name is how a relying party decides who it is talking to, and the machinery that protects the name — and binds keys and certificates to it — is what makes that decision safe or unsafe. This section covers that machinery: how DNS data is authenticated (DNSSEC), how DNS queries are kept private in transit (DoH and DoT), how certificates are bound to domains (the WebPKI), and how that binding is kept honest (Certificate Transparency).

It is foundational for the rest of the library. STIR’s certificate model borrows its architecture from the WebPKI; VESPER bridges telephone-number authority into domain-based trust; the ENUM-plus-encrypted-DNS conversations lean directly on DoH mechanics; and the certificate hierarchy behind SHAKEN is a domain-PKI pattern applied to telephone numbers. The domain-trust layer is also where one genuinely unsettled question sits — whether, and how, DNS anchors identity for AI agents — which the closing section takes up honestly rather than predicting a winner.

DNSSEC — authenticating the data, not the query

DNSSEC adds origin authentication and integrity to DNS. Zone operators sign their records, and a chain of signatures runs from the root zone down through each delegation, so a validating resolver can confirm that an answer genuinely came from the zone that owns the name and was not altered in transit. It is the mechanism that lets DNS carry security-relevant data — not just addresses, but keys and fingerprints (DANE/TLSA, SSHFP, and the like) — with some assurance the answer is authentic.

What DNSSEC is not is equally important. It provides authentication and integrity, not confidentiality: a validating resolver can trust the answer, but the query and response still travel in the clear absent one of the transports below. It authenticates the data, not the user. And its guarantees only hold where the chain is actually signed and actually validated — which is the deployment problem. Signing is uneven across zones, validation is uneven across resolvers, and a name that is unsigned simply falls back to unauthenticated DNS rather than failing closed. The result is a mechanism that is architecturally sound and partially deployed, which is why the library treats DNSSEC as a dependency to check rather than assume: where a trust design leans on it, whether the relevant zones are signed and the relevant resolvers validate is a real question, not a given.

Encrypted DNS — DoH and DoT

DNS over TLS (DoT) and DNS over HTTPS (DoH) close the confidentiality gap DNSSEC leaves open: they encrypt the query and response between the client and the resolver so that a network observer cannot see, or tamper with, which names are being looked up. DoT runs DNS over a dedicated TLS port; DoH tunnels it inside ordinary HTTPS, which makes it indistinguishable from web traffic and therefore much harder to block. The two solve the same privacy problem with different visibility and policy properties.

The trade-offs are where it gets interesting, and they are policy as much as protocol. Encrypting queries protects users from local surveillance and manipulation, but routing them to a small number of large DoH providers concentrates a sensitive stream of behavioral data and can bypass the network operator’s own DNS — which is precisely how some enterprises, schools, and parental-control regimes enforce policy. The same property that protects an individual from an untrusted network disrupts a legitimately trusted one. This is the recurring shape of the domain-trust layer: a mechanism is rarely simply “more secure,” it moves control and visibility from one party to another, and the interesting question is always which party ends up holding it. The ENUM work in the library touches this directly, since resolving numbers to URIs over encrypted DNS inherits exactly these placement questions.

The WebPKI — binding certificates to domains

The WebPKI is the certificate ecosystem the web actually runs on: the set of certificate authorities browsers and operating systems trust, the domain-validated certificates they issue, and the trust stores that decide whose signatures count. When a site presents a certificate, the relying party trusts it because it chains to a CA in the trust store and the CA attests that the key belongs to the domain. This is the model STIR’s certificate design borrows from — a trust anchor, a delegation chain, and a relying party checking the chain — reapplied so that the “name” being certified is a telephone number or a service-provider code rather than a domain, as the SHAKEN certificate hierarchy lays out.

The WebPKI’s structural weakness is the one worth carrying into any design that imitates it: historically, any trusted CA could issue a certificate for any domain, so the security of every name depended on the weakest CA in the store. Domain validation proves control of a name at issuance time, but it does not stop a different CA — compromised, coerced, or simply mistaken — from issuing a competing certificate for the same name. That single-weak-link property is why the transparency layer below exists, and why any telephone-number or agent PKI modeled on the WebPKI has to answer the same question: what stops a legitimate issuer from issuing something it shouldn’t, and how would anyone find out.

Certificate Transparency — making misissuance visible

Certificate Transparency answers that question with append-only public logs. CAs submit every certificate they issue to logs that cannot be edited retroactively, and relying parties can require proof of log inclusion (a signed certificate timestamp) before accepting a certificate. It does not prevent misissuance; it makes misissuance discoverable — a domain owner monitoring the logs can see a certificate they never requested, which turns a silent compromise into a visible event. Transparency substitutes detectability for prevention, which is often the more achievable guarantee.

That pattern — an append-only, publicly auditable log of who attested what — recurs across the trust work in this library and beyond it. The STIR certificate-transparency draft applies the CT model to telephone-identity certificates; SCITT applies the same append-only transparency idea to the software supply chain; and the digital-identity hub treats transparency logs as one of the recurring primitives that show up in every domain of verifiable identity. Learning CT here is learning a mechanism that reappears everywhere the library goes.

Where the telephone network meets domain trust

These mechanisms are not adjacent to the caller-authentication work; they are its architectural ancestors. STIR certificates are X.509 certificates in a delegation hierarchy, validated the way WebPKI certificates are, with a governance arrangement deciding the trust anchors. The idea of making misissuance visible through transparency logs crosses straight over from CT into the STIR certificate-transparency work. And VESPER is the most direct bridge of all: it takes telephone-number authority and expresses it as domain-bound, verifiable evidence, so that a claim about a number can be checked through the same domain-trust machinery the web already relies on. (VESPER is developing quickly in the STIR working group; this page keeps to the settled bridge framing and leaves the current specifics to the VESPER topic as that work lands.)

The through-line is that the telephone network did not invent its trust model — it borrowed the domain world’s, adapted it to numbers, and added the governance the web never centralized. Understanding the original is what makes the adaptation legible.

Agent identity and DNS — an open question, not a design

There is real interest in whether DNS should play a role in identifying AI agents — using the name system, which already provides delegation, caching, and a global resolution path, to help answer “what is this agent and who stands behind it.” It is an intuitive idea: DNS is the internet’s existing naming and delegation substrate, and agent identity needs naming and delegation.

But it is early, and it is genuinely unsettled. The IETF is only beginning to take up these discussions, and there is no consensus — no settled draft, no agreed mechanism, and no clear answer to whether DNS is even the right layer for the problem versus the credential, attestation, and discovery primitives being profiled elsewhere (which the digital-identity hub covers under agentic identity). Earlier framings that treated a specific DNS-based agent identifier as the emerging path now look premature: the field has not picked an approach, and it would be misleading to present one as leading. This page therefore flags the question as open and worth watching, and declines to name a front-runner. When the discussion produces something with real working-group traction, it earns a proper treatment here; until then, the honest statement is that the DNS-and-agent-identity connection is a live topic without a settled shape.

Where this fits

This section is the domain-trust substrate beneath much of the library. The STIR/SHAKEN framework and its certificate hierarchy apply this PKI pattern to telephone numbers; VESPER bridges number authority into domain trust; ENUM resolves numbers through DNS itself; and the digital-identity hub places DNSSEC, WebPKI, and transparency logs among the recurring primitives that show up across every industry now building verifiable identity. The planned sub-pages will take each mechanism — DNSSEC, encrypted DNS, the WebPKI, and Certificate Transparency — down to the level a working engineer needs: what it is, what it solves, what it does not, and where it fits.