Standards

We answer for our own zones over UDP and TCP, with the authoritative bit set. No recursion, no forwarding.

A first-class transport, not a fallback. Required for answers that do not fit a UDP packet, which signed responses often will not.

We advertise a 1232-byte payload, the DNS Flag Day 2020 figure, and honour the requester's, truncating with TC rather than sending a packet that will be fragmented or dropped.

NODATA and NXDOMAIN are distinguished, each carrying the zone SOA in the authority section so a resolver knows how long to remember the absence.

IPv6 addresses are ordinary records on every plan, and our nameservers answer over IPv6 as well as IPv4.

Publishable under any hostname you hold, through the API. Up to ten records per hostname; a value longer than 255 bytes is split across several character-strings, up to 2048 bytes in total, which is what a 2048-bit DKIM key needs.

Served in ServiceMode, with the parameters validated rather than passed through: the list has to be in ascending key order with no duplicates, and `mandatory` may not name a key the record does not carry. AliasMode is refused, because it exists to alias a zone apex and a hostname here is never an apex. This is also the only way to publish an Encrypted ClientHello config, which has no other delivery mechanism in DNS.

Publishable under any hostname you hold. The null MX is accepted too, at preference 0 with a root exchange, which is the only way a name can say it accepts no mail at all.

Served, with the owner name validated as _<service>._<proto>. The service and protocol live in the name rather than the rdata, so a record at any other name is one no client will look up.

An SSH host key fingerprint in DNS, SHA-1 or SHA-256, so a client can verify the key on first connect rather than trusting it. On a signed zone that verification is worth something, which is why it is offered beside DNSSEC rather than on its own.

Every domain we operate publishes one, naming the CAs we use plus an address for violation reports. We do not restrict the challenge type, so your own HTTP-01 keeps working. You can publish CAA on your own hostname too, and it replaces ours for that name - a CA reads the closest set and ignores the rest, so what you write is what applies.

We sign zones and publish the DS at the registrar through their API, so a validating resolver checks our signatures and gets an authenticated answer. Signing is deliberate per domain rather than automatic, and some inventory we bought before we ran our own registrar accounts cannot carry a DS at all. The admission gate keeps that inventory out of service; it is being replaced rather than assigned to anyone.

We sign with ECDSA P-256 and SHA-256 (algorithm 13), and run NSEC3 at zero iterations with no salt, which is current guidance.

Served, with the owner name validated as _<port>._<proto>. You can publish one on a signed domain whose DS the registry has accepted; on any other we refuse it with a 409. A TLSA record says which certificate to trust, and in a zone a resolver treats as unsigned, anything that can forge the answer can forge the binding with it - so accepting one there would hand you a guarantee we could not keep.

Opaque rdata is served verbatim with the correct type code, which is how DNSSEC records reach the wire without the nameserver parsing them.

The DNS half of the challenge. A per-hostname credential publishes _acme-challenge TXT records, which is what wildcards and machines on private networks need.

For hostnames registered as certificate: "managed" we run the client ourselves - order, DNS-01 challenge, finalize, and renewal - and hand the certificate back over the API. Nothing is pushed to you.

Managed renewals ask the CA when to renew and take a random instant inside the window it suggests, rather than renewing at a fixed fraction of the lifetime. Renewals coordinated this way do not consume issuance limits, and the jitter keeps every certificate on a domain from coming due in the same minute.

Our DNS-01 API speaks it, so a client built for acme-dns works against a credential we mint. No recipe we publish needs one any more: Caddy and cert-manager use modules we maintain, lego and Traefik their built-in httpreq provider, and certbot a hook script. lego and Traefik auto-register against acme-dns when their storage is empty, which we do not support, and that is the reason to prefer httpreq there.

Per-client-prefix budgets for answers and errors, with truncated-response slipping so a legitimate resolver behind a noisy prefix still gets served over TCP.

Google sign-in verifies the id_token audience and requires a verified email. Email sign-in links are single-use and expire. This is us consuming somebody else's authorization; the entry below is us being one.

An MCP server at /mcp over the Streamable HTTP transport, so an agent can mint a hostname, repoint it and diagnose it mid-task rather than needing a person to have written the config first. Stateless and POST-only, because a tools-only server never initiates anything and so has no stream to resume. The protocol version is negotiated at initialize and carried on every request after it; one we do not speak is refused rather than guessed at.

How /mcp authenticates a connector, because Claude and ChatGPT can be given a URL and nothing else. Clients register themselves (7591) and are never auto-approved - anyone can register, so consent is always a screen somebody reads. PKCE is S256 only (7636). A token names the resource it was issued for and is refused anywhere else (8707), which is why an access token cannot be used as an API key. Refresh rotates and revocation takes the whole family with it (7009). A machine with no browser on it uses the device flow (8628): it prints a short code, a person approves it from a browser elsewhere, and nothing is decided on the machine. Both discovery documents are published (8414, 9728), and a 401 carries WWW-Authenticate so a client that has only been given a URL can find them. OAuth 2.1 is an IETF draft that consolidates these; the RFCs are what is implemented.

The whole v1 API is described at /openapi.json, and the same reference is published as plain text for language models at /llms-full.txt.

Every domain we register is signed and its DS published at the registry before it serves a hostname. Both are admission gates: a domain with an unsigned zone, or a signed zone whose DS is not live, does not enter service. That second half is the one usually missed - a signed zone nobody can find the DS for is not protected, and a resolver has no way to know it was meant to be.

You can publish TLSA under your hostname. We refuse to publish one on a zone that is not signed, because an unsigned TLSA record is a certificate binding nobody can verify - it reads as protection and provides none. The refusal is only possible because signing is not optional here.

Waiting on resolvers rather than on us, and the number is the argument. Measurement at OARC 45 found 44 probes behind resolvers using encrypted transport to authoritative servers - almost all Quad9 - and zero using QUIC. If we shipped DoT tomorrow Quad9 would use it and everyone else would keep sending plaintext over UDP, so an observer reads the rest and learns the same things about the same customers. Encrypting a rounding error of an observable channel buys no privacy. What changes this is resolver adoption, not our appetite, so we watch it rather than pre-build for it.

An identity for an agent published in DNS rather than in a registry someone else operates. We already run authoritative DNS for the name, so this is closer to us than to anyone selling a directory. What holds it up is not the DNS work - it is that an identity record is only worth as much as the accountability behind whoever registered it, and we have not answered that question yet. It is worth saying that waiting here has a cost, unlike most of this list.

A challenge scoped to an ACME account rather than to a name, which removes the last reason a shared validation record is worth attacking. Small change on our side and pointless before a CA validates it, so this waits on Let's Encrypt shipping support rather than on us.

We submit DS records through the registrar API instead. These exist to remove the registrar from key rotation, and rotation is already one API call every few years.

There are no secondaries to transfer to. Nameservers replicate from the control plane's database and serve from memory, so a zone transfer would be a second, weaker path to the same data.

Refused, and not on preference. RFC 9539 - the experimental RFC for encrypted recursive-to-authoritative DNS - excludes DoH by name, because a client has to know the path part of the endpoint URL and a resolver has no way to discover it. A DoH listener on a nameserver of ours would be one that nothing on the internet knows how to find. DoH is a stub-to-resolver protocol and we do not occupy that position.

Records change through the authenticated HTTP API, which is scoped per hostname and per key. UPDATE would be a second write path with a weaker authorisation model.

We refuse NS records below a zone apex. A delegation means the answers stop being ours to stand behind, and every abuse and reputation control we have assumes they are.

Separate from the one we run, which is listed above. A remote MCP server is an HTTPS endpoint a client keeps. Mint a hostname, serve the transport from it, and move the server between machines or regions with one PUT - clients holding the URL keep working, because the address was never in the name.

An IETF draft advertising an MCP server in a TXT record at _mcp under a domain: endpoint, transport, an Ed25519 key and a capability profile, as a resolver-cached bootstrap that skips the HTTPS round trip. It requests no new record type, so the DNS half already works here: POST a TXT record named _mcp on a hostname and it is served. A draft rather than an RFC. A record carrying a key is longer than one 255-byte string, which the TXT API handles by splitting it across several.

Discovery starts with an Agent Card served over HTTPS, at /.well-known/agent-card.json since v1.0 and the older /.well-known/agent.json for clients that have not caught up. The hostname is part of that contract rather than a deployment detail, so repointing it does not invalidate a cached card.

An OWASP specification with a v2 draft at the IETF. It resolves an agent name to an endpoint, and a minted hostname is an endpoint a registration can name. The v2 draft expects records published under the agent hostname, including TLSA - those are the record types we serve.

SPIRE puts a DNS name in the certificate it issues, with spire-server entry create -dns. A workload can hold a SPIFFE ID and a minted hostname at once: the ID says which workload it is inside a trust domain, the hostname is how anything outside that domain reaches it. We are not a trust domain and do not issue SVIDs.

Every discovery convention above resolves to a path under a host you control. That is the same requirement stated four ways, and it is why the hostname outliving the address matters more than any of the individual specs.