Topic
DNS Delegation Power
Within the Topic facet, DNS Delegation Power topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.
CASE FILE
The Signal Was Signed. The Delegation Was Not Yet Secure: CDS/CDNSKEY and the Authority to Publish DS
A child zone can publish a perfectly signed request for a new DNSSEC secure entry point and still lack the one chain that would validate it. CDS/CDNSKEY makes parent coordination machine-readable; it does not collapse operational control, registrant authority, parent admission…
CASE FILE
The Catalog Was Valid. The Deletion Was Not: DNS Catalog Zones and the Authority to Provision
An authenticated DNS transfer can deliver a perfectly formed catalog whose operational consequence is to remove every zone from a secondary fleet. The transport may be trustworthy and the syntax impeccable while the decision encoded inside it is still wrong. DNS Catalog Zones…
Europe and Middle East Cloud Services Trends
The regional boundary behind Genesis Cloud’s GPU capacity
Genesis Cloud’s accelerator inventory becomes useful capacity only when networking, data placement, images, security controls and recovery procedures can support the intended workload. Its documented regional boundaries therefore turn a catalogue question into an architectural…
History
A Detour Could Not Also Be a Destination: The Design of DNS CNAME
DNS could let an old name lead to a new destination, but only by making the old node surrender every ordinary answer of its own. CNAME turned that apparent limitation into a reliable instruction: cache the detour, restart the question, and keep authority over the alias separate…
CASE FILE
The Answer Had Expired. The Failure Had Not: DNS Serve-Stale and the Authority Beyond TTL
A DNS answer can outlive its ordinary freshness without becoming current again. Serve-stale is the resolver's narrow authority to prefer a known old answer over a fresh failure, but only after the source has been consulted, the failure has been bounded and the age of the…
IETF
Joe Abley and the Trust Anchor That Had to Declare Where Trust Began
DNSSEC can prove a chain only after a resolver has decided where the chain starts. Joe Abley's work on the root trust-anchor publication format makes that first decision unusually legible: a signed file can prove where data came from, but it cannot order an operator to believe…
Story
K-root Says It Meets Every Expectation. The Evidence Is Uneven
RIPE NCC has answered the root-server community's operating expectations one by one. That makes K-root easier to question than a service hidden behind a general assurance of competence. Yet RIPE-859 also reveals a governance gap: a public metric, a control description and the…
IETF
Ray Bellis and the DNS Connection That Became a Session
A TCP socket can remain open without anyone agreeing what state it carries. RFC 8490 made that distinction explicit for DNS: the connection is transport; the session is a mutually recognized set of rights, timers and obligations. Ray Bellis and his co-authors turned persistence…
CASE FILE
The Registration Began with a Surname; Later Use Still Had a Separate Record: Nissan Motor v Nissan Computer
The label stayed the same while the page behind it changed. That difference—between the provenance of `nissan.com` and the later uses made of it—became the organising fact of a dispute that lasted through preliminary relief, a sweeping injunction, appeal and remand.
CASE FILE
The Zone Went Dark. The Resolver Made the Outage Louder
When authoritative DNS stops answering, the first failure belongs to the zone. The next thousand queries may belong to the resolver. RFC 9520 draws a narrow but consequential line between the two: silence is not proof that a name does not exist, yet a resolver that has exhausted…
IETF
Ray Bellis and the Proxy That Had to Forward the Unknown
A small gateway often presents itself as a helpful DNS interpreter: one address for the household, one upstream resolver, one place to cache an answer. RFC 5625, authored by Ray Bellis, starts from the more difficult premise. The gateway cannot know what DNS will mean after its…
CASE FILE
The Handshake Succeeded. The DNS Question Was Already Exposed
RFC 9539 lets a recursive resolver encrypt its next hop to an authoritative server without waiting for the server to advertise a new policy or present a verifiable identity. That modest bargain can hide many DNS questions from passive observers. It also creates an unusually…
CASE FILE
The TLS Session Resumed. The DNS Subscription Did Not
DNS Push can make a changing RRset look continuously current by stopping the client’s TTL clock and replacing polling with a server’s promise to send changes. That promise belongs to one accepted subscription on one live DSO session. A resumed TLS channel is cheaper to rebuild…
CASE FILE
The Record Expired. The Resolver Kept It Alive
DNS Serve Stale can preserve service when authorities cannot answer. It can also keep a retired address or denial alive after the publisher's ordinary freshness claim has ended. The difference lies in who owns the exception and whether its evidence survives.
IETF
DNS Serve-Stale Lets the Recursive Resolver Decide When Expired Data Is Better Than Failure
A DNS record reaches the end of its TTL just as every authoritative server becomes unreachable. The old address may still preserve a working service—or it may lead users back to infrastructure the zone owner meant to retire. Serve-stale keeps resolution alive by giving the…
CASE FILE
Two Answers Said NOERROR. Only One Carried the New Zone
RFC 9660 can bind a DNS answer to the zone version that produced it. That makes a mismatch visible without pretending that one version token proves the zone is correct, the fleet has converged or users saw the same path.
CASE FILE
The Service Vanished. Its DNS Lease Did Not
A DNS Update Lease can make stale records expire without a cleanup command. It can also keep an authoritative answer valid long after the advertised service has stopped, because the server—not the requester—sets the operative publication horizon.
CASE FILE
The Catalog Went Empty. The Servers Obeyed
A DNS catalog zone can turn one compact, authenticated change into a new operating perimeter for an entire authoritative fleet. That efficiency is precisely why the catalog must be governed as executable authority rather than treated as a harmless list.
History
The Prefix the Resolver Sent on Someone Else’s Behalf: EDNS Client Subnet
A recursive resolver usually speaks to an authoritative server from its own address. EDNS Client Subnet changed the message: the resolver could send part of a client's network instead, asking the authority to tailor an answer for someone who had not made that upstream query. The…
CASE FILE
The signed chain skipped a delegation that still existed
NSEC3 Opt-Out allows a large parent zone to leave eligible insecure delegations out of its signed hash chain. That omission can be fully valid. It is also why the chain cannot serve as a complete delegation register: the proof authenticates a limited statement about a hash…