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.
ICANN
Challenging a .jp Registration Just Got Easier: What the 2026 JP-DRP Rules Revision Actually Changed
Japan's procedure for disputing ownership of a .jp domain name was quietly modernised this spring — but its most consequential limits were left exactly where they were.
CASE FILE
The Printer Kept Its Name After the Reset. The Key That Owned It Did Not
RFC 9665 makes automatic service registration workable by letting the first accepted device key defend a DNS-SD name. That useful continuity is narrower than identity: a valid signature can preserve a name while the owner, registrar, published answer or service behind it has…
IETF
The configuration arrived. The public zone did not: RFC 9527
RFC 9527 can deliver the domain and manager coordinates an automated Homenet Naming Authority needs. The harder claim begins after that success: whether the delegated name is authoritative, signed, current and reachable from outside the home.
IETF
The proxy exposed the alias chain. It did not authenticate the host: RFC 9532
RFC 9532 gives an HTTP intermediary a precise way to disclose the DNS aliases it encountered on the way to its next hop. That visibility can reveal cloaking and explain routing, but it remains the proxy’s account of one resolver view—not a credential for the resource behind the…
ICANN
Who Holds the Keys to .jp: An Instrument-by-Instrument Audit of JPRS's Registry Authority
Japan Registry Services Co., Ltd. (JPRS) operates the .jp country-code top-level domain, but the company's public profile as a registry says little about where its authority actually comes from, who can challenge it, and what has changed on that control surface recently. This…
Global Institutional Trends
AS210764: who can change the ISC-AGP1 record, and what the maintainer chain says about ISC stewardship
AS210764: who can change the ISC-AGP1 record, and what the maintainer chain says about ISC stewardship intelligence summary explains the development, the public evidence available to readers, the organisations involved, the regional context, market exposure, and the…
Global Institutional
BIND 9 repair ends where ISC's support boundary begins
Internet Systems Consortium draws three lines that decide whether a BIND 9 defect becomes a repair: which release branches stay in support, which severity earns a public advisory, and which single monthly release carries the patch. Dated records from ISC, from Debian's packaging…
ICANN
ICANN Can Declare Its Own Breach. The Remedy Still Needs Someone Else to Act.
A finding of breach is binding. The repair is only a recommendation. The .WEB record and one terminated community petition show where ICANN's accountability stops being automatic.
Story
ARIN Closed the DS Automation Suggestion. The Parent-Side Handoff Is Still a Question
A DNS operator can publish a signal that a key should change, but it cannot by that act alone alter the parent zone. In January, ARIN agreed that automatically updating DNSSEC delegation-signer records would be useful and closed the request into its planning process. The…
ICANN
Ghana’s DNSSEC Rate and Nigeria’s Signed Zone Are Different Kinds of Progress
ICANN’s latest account of African DNS security puts mobile-network resolvers beside a country-code registry. The gains are real but belong to different operators and measure different parts of a secure lookup.
History
The Company Register Was Supposed to Settle the Domain Name. It Only Moved the Boundary: RFC 2352
In 1998, an independent RFC proposed giving each legally registered organisation a domain path derived from its formal name, legal form and jurisdiction. The promise was clean: let company and trademark authorities decide entitlement, then let DNS carry the result. The attached…
IETF
The Key Matched the DNS Record. The Application Still Had to Say Yes
Revision 14 of the DANE client-authentication draft gives a TLS server a DNSSEC-backed way to match a client certificate or raw public key to a client-supplied DNS name. That is a useful cryptographic receipt, but it does not decide who may use the service or what the application…
ICANN
Who Can Stop a New gTLD Application, and What an Applicant Can Actually Win
ICANN can refuse, defer or condition a new generic top-level domain application — but the two remedies an unsuccessful applicant can pursue do not hand it the string. One returns the question to the same Board. The other produces a declaration about whether the Board kept to its…
Story
Stork’s DNS Serial Comparison Begins With the Zones It Could Fetch
APNIC 62 showed a useful cross-server mismatch signal. Its meaning begins one step earlier: which daemons, views and zone configurations entered the cache, when they were fetched, and what the fetch could not observe.
IETF
RFC 9874: A Successful EPP Delete Can Break Another Client’s DNS
The dangerous EPP deletion is not necessarily the one that fails. It is the one that succeeds for the requesting client while changing name-server state relied on by domains sponsored by somebody else. RFC 9874 turns that hidden dependency into an operational question. The…
IETF
The Transfer Was Encrypted. The Zone Still Needed a Custodian: RFC 9103
Encrypting AXFR or IXFR removes a powerful observer from the path: anyone who could read the transfer in cleartext. RFC 9103 makes that result precise—and, just as importantly, leaves authorization, replica custody and the rest of the DNS exposure surface as separate questions.
IETF
The Backup Nameserver Answered. The Cached Key Did Not Fit: RFC 8901
A second authoritative DNS provider can keep answering after the first one fails and still leave validating resolvers without an acceptable answer. RFC 8901 shows why DNSSEC redundancy is a synchronization contract across signers, not a count of nameservers.
ICANN
4.3 Million IDNs Are a Registration Count, Not a Universal Acceptance Result
A name can exist in the DNS, appear in a registry total and still be rejected by the first sign-up form that asks for its email address. ICANN’s new annual report makes both sides visible: multilingual identifiers are widely available, while the software path that must use them…
IETF
The Root Queries Went Quiet. The Traffic Bill Did Not
LocalRoot can keep ordinary root questions inside a resolver and away from the Root Server System. It also creates a different network obligation: discover a publication source, check for change, fetch zone data, verify it, activate it and retreat before it expires. A four-day…
ICANN
ICANN Mapped AFRALO’s Requests Without Adopting Them
The most important phrase in the AFRALO-AfrICANN submission is not in the Board Chair’s reply. It is in the cover note: the statement was sent to the ICANN Board “for information purposes.” Six pages of recommendations then met a two-page response that acknowledged the problem…