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.
Story
A Backup DNS Plan Is Not a Second Resolver
A 9 September APNIC Blog account turns a household outage into a precise infrastructure lesson: resilience begins only when an alternative service is running, reaches the clients that depend on it, survives a controlled failure and can be rolled back.
Story
RIPE NCC’s K-root Refresh Needs Three Acceptance Records, Not One Batch Status
Amsterdam can be refreshed while the three-site programme remains in progress. That is not a contradiction; it is a warning about the unit of evidence. RIPE NCC has named three K-root core sites whose seven-year-old routers and servers were due for replacement. The useful public…
Global Institutional Trends
ISC’s control chain: what public evidence shows about prevention, detection and durable repair
ISC’s public record presents a recognizable operational control chain: vulnerability information is coordinated, supported software releases are published, high-availability behavior is documented and tested, service status is exposed, and F-Root operations are described across…
IETF
A `_for-sale` Record Is a Listing Signal, Not Proof of Seller Authority
RFC 10023 gives a domain holder a public, machine-readable way to say that a name is available. The signal can open a negotiation; it cannot establish who may bind the seller, whether the stated price still applies, or whether a registrar will complete the transfer. Those states…
IETF
Standards Become Infrastructure When Operators Must Carry Their State
IETF standards do not operate networks. They define the state machines, security dependencies and recovery procedures that networks must implement if they are to interoperate. That distinction matters when a protocol becomes part of the Internet’s operating surface: continuity no…
IETF
DNSOP Adopted the Multi-Algorithm Problem, Not the UNIVERSAL Label
One sentence in a Working Group chair’s message does two jobs. It records “clear support” for taking on a DNSSEC draft, then preserves concerns about the complexity of its mechanism. The first clause changed the document’s process state. The second stopped that state change from…
Story
LACNIC's RDAP delegationSigned Records Parent DS Presence, Not DNSSEC Validation
A boolean in a registry response can look like a verdict on the security of a DNS chain. LACNIC's RDAP `delegationSigned` field answers a narrower question: whether the registration view reports DS records in the parent. It does not run a resolver, test the child keys or prove…
IETF
One Shared Nameserver Is a Continuity Test, Not Proof of Delegation Control
A resolver looks again at a delegation it has cached. The parent now lists a mostly different set of nameservers, but one familiar name survives. That intersection can be enough to treat the delegation as continuous, provided any relevant signer overlap also holds. It is a useful…
IETF
Dry-Run DNSSEC Tests a Resolver Cohort, Not the Internet
A zone is signed, a validator finds the signature wrong, and the user still gets an answer. That apparent contradiction is the point of dry-run DNSSEC. Failure is exposed to an operator without yet becoming failure for the ordinary client. The rehearsal can reveal a broken…
IETF
DNSSEC Recovery Runs on Clocks No Signer Controls Alone
The private key is unusable. The zone is still answering, and yesterday’s signatures still validate. That is not recovery; it is borrowed time. A new DNSOP draft explains how to use that interval without destroying the trust that remains. Its harder lesson is institutional: the…
IETF
A Self-Signed Delegation Update Proves a Key, Not Its Authority
A DNS message can prove that its sender holds a private key and still leave the decisive question unanswered: who entitled that key to alter a child’s delegation? A DNSOP proposal for rapid child-to-parent updates makes that distinction explicit. Its lasting value will depend on…
CASE FILE
A Registry-Lock Quorum Counts Approvals, Not Independent Authority
Two approval messages can look like two-person control while both are recoverable through the same compromised mailbox. A proposed EPP registry-lock extension can count authorising contacts; the harder task is proving that the authorities behind those contacts were genuinely…
CASE FILE
A Successful EPP Server Validation Is a Dated Policy Verdict, Not a Health Certificate
The word “success” can survive on a dashboard long after the observation that produced it has expired. A new EPP proposal would make the result portable; governance begins by refusing to make it timeless.
CASE FILE
The EPP Same-Entity Set Turns an External Policy Into an Atomic Boundary
A registrar can submit a command naming one domain while the repository must decide whether that command reaches a set too large to list. The protocol message is visible; the rule that draws its boundary may sit somewhere else.
IETF
One CA Name, Several Ways to Issue
A buyer reviewing certificate operations asks a simple question: if DNS authorizes one certification-authority name with an account and a validation method, does that restriction govern every issuing system behind the name? RFC 8657 makes the answer consequential. A shared CA…
CASE FILE
A DNS Filtering Notice Is a Chain of Three Decisions, Not One Explanation
A link that explains why a name was filtered looks like a simple act of transparency. By the time it reaches a user, however, a resolver, an application and the user have each made a different decision. The record must preserve all three.
CASE FILE
A Public Sponsor for a Private Namespace
An enterprise can need outside confirmation of an internal DNS arrangement without wanting to publish its internal directory. RFC 9704 offers a way to separate those disclosures. The difficult decisions concern what remains visible, how much authority one approval covers, and who…
History
The Parent Named the Server. The Server Still Had No Zone: RFC 1912 and Lame Delegation
The referral worked exactly as configured. A resolver asked the parent where to find a child domain, received two name-server names and sent a query to one of them. Only then did the system reveal its mistake: the selected machine had no child zone to serve. The directory entry…
IETF
Deletion Is the Hard Test as DNSOP’s Integration Draft Reaches Its Last Call Deadline
A DNS name can be easy to attach to an application and surprisingly hard to detach. As DNSOP’s integration draft reaches its scheduled Working Group Last Call deadline, its most consequential test is not whether a user can prove control once. It is whether the application can…
IETF
Sara Dickinson and the Resolver Promise Encryption Cannot Prove
The padlock beside a DNS resolver name is reassuring because it proves something useful: the client has protected its conversation on the way to a particular service. It is also dangerously easy to ask that icon to prove the rest. Sara Dickinson’s co-authored RFC 8932 follows the…