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 Registrant Was Abroad; the Dot-Com Registry Was in Virginia: CNN v CNNews.com
The Registrant Was Abroad; the Dot-Com Registry Was in Virginia: CNN v CNNews.com intelligence summary explains the development, the public evidence available to readers, the organisations involved, the regional context, market exposure, and the infrastructure consequences that…
IETF
A Resolver Can Choose Encryption Before DNS Operators Coordinate
Encryption between a user and a recursive DNS resolver does not protect the next hop. The resolver may still send the resulting query in cleartext to an authoritative server, exposing another part of the path to passive observation. RFC 9539 proposes an experimental compromise…
IETF
Catalog Zones Turn a DNS Member List into Fleet-Wide Provisioning Authority
An empty file is usually absence. An empty DNS catalog can be an instruction. If a generator accidentally publishes a catalog without its members, every consumer that originally provisioned those zones from that catalog may begin removing them and their associated state. RFC 9432…
ICANN
A Zone File Is Shared Access, Not Permission to Republish the Namespace
At 09:00, an approved researcher downloads a gTLD zone file through ICANN's Centralized Zone Data Service. The archive is complete enough for the contracted transfer, and its checksum matches. Those facts establish delivery. They do not establish who owns every listed domain, why…
IETF
One Delete Command Can Break Someone Else's Domain: RFC 9874 and EPP Dependency Control
A destructive EPP transition is not necessarily local to the client that requests it. When a subordinate host is still associated with domains sponsored by other clients, deleting that host can alter their DNS dependencies, consistency, and ability to resolve. RFC 9874 is a…
CASE FILE
Sixty Names Were Defendants; the Statute Still Defined the Claim: Harrods v Sixty Internet Domain Names
The caption did something unusual: it named sixty domain names as defendants. That procedural choice made a dispute over the Harrods name look, for a moment, like a dispute over things rather than people. The Fourth Circuit’s answer was narrower. The names could be before the…
IETF
ZONEMD Lets a Secondary Verify the Zone After the Transfer Ends
A completed zone transfer proves that a delivery procedure finished. It does not, by itself, prove that the receiver assembled the exact zone the publisher intended. ZONEMD adds a digest over the zone as a whole, creating a verification boundary after transport and before a…
ICANN
ICANN Picks One Provider for Two Name Panels With Different Fee Rules
Analysys Mason will handle geographic and reserved-name reviews in the 2026 gTLD round. For applicants, however, those two desks do not produce the same bill.
IETF
A Negative Trust Anchor Lets the Resolver Suspend DNSSEC Without Changing the Zone
When a signed domain breaks, a validating recursive resolver can either preserve the failure or create a narrow local exception. A negative trust anchor restores reachability without repairing the zone, but it transfers temporary authority over DNS authentication to the resolver…
ICANN
ccNSO Draws a Boundary for ICANN’s IDN Follow-Up
The Council’s July answer permits enquiries prompted by a reasonable basis, while rejecting active compliance policing. A September Board discussion will consider the next steps for the still-pending recommendations.
ICANN
An ISO Change Can Trigger an IDN ccTLD Exit. It Does Not Give ICANN a Territory Verdict.
An identifier system needs stable references. It also needs to know when a reference has changed. Those two necessities become dangerous when a technical process quietly starts to sound like it has decided the political fact from which its reference was drawn.
CASE FILE
The Tag Resolved. The Aircraft Was Not Located: RFC 9886
The reverse-DNS answer arrived in milliseconds: a public key, a registration certificate and a static Remote ID record. The airspace display was still empty. RFC 9886 explains why both screens can be correct — it makes an aircraft-related identifier resolvable without turning…
History
The Codes Aligned. The Circuit Still Needed Permission: RFC 1394
A two-letter domain, a telex answerback and a telephone prefix could all point toward the same country and still leave a message nowhere to go. RFC 1394 made those correspondences useful by placing them in one table. It also marked the table's limits: values could be wrong…
ICANN
ICANN’s Diacritics Plan Would Tie Registry Exits Together
A new GNSO report would let certain ASCII and Latin-diacritic top-level domains operate together. The price of that exception is a shared operating future: related suffixes would move together when providers or control change, while removal would follow a different set of rules.
History
The Domain Entry Pointed to the Organisation. It Was Not the Organisation: RFC 1279
The most disciplined line in RFC 1279 was not about search speed or a grand replacement for DNS. It was about identity. A domain and an organisation were different entities; a mailbox and a person were different entities. The proposed directory could connect them, but it was not…
IETF
Wes Hardaker and the DNS Server That Had to Outlive Two TTLs
The new nameserver was answering perfectly. The old one was quiet. An operator shut it down after the child zone's TTL elapsed—and a minority of users vanished, because their resolvers were still keeping time from the parent.
History
The Name Was Local. The Number Still Needed a Record: RFC 1101’s DNS Mapping Boundary
In 1989, DNS could already distribute host information, but it did not yet offer a standard way to ask what a network number was called. RFC 1101 proposed a small answer: use PTR records, host-zero names and masks in `IN-ADDR.ARPA`. Its lasting discipline is equally small. A…
IETF
Tobias Fiebig and the Four DNS Reachability Receipts
A zone can display two A records, two AAAA records and a reassuring “dual stack” label while still withholding names from an IPv6-only resolver. RFC 10001 replaces that label with four bounded claims: two authoritative services must answer over IPv4 and two must answer over IPv6…
History
The Name Service Was Almost a Negotiator: How RFC 830 Separated Domains from Capabilities
A file-transfer program asks for NIFTP. The destination has no NIFTP implementation, but it does offer FTP. In the architecture proposed by RFC 830, that mismatch did not have to end the attempt. One part of the name service found the destination domain; another part asked what…
IETF
David Lawrence and the DNS Answer That Outlived Its TTL
When a DNS answer reaches the end of its TTL, a recursive resolver normally discards or refreshes it. RFC 8767 allows a narrower choice during failure: preserve the expired copy for a bounded time, return it only after a real refresh attempt cannot produce usable data, and keep…