Beijing Qihu Keji's Four-TLD Registry Control Surface: DNS

Summary

ICANN lists Beijing Qihu Keji Co., Ltd. as the operator of .anquan, .shouji, .xihuan, and .yun. Each is a base, non-sponsored registry agreement dated 8 January 2015.[5][6][7][8]
A company-specific ICANN renewal letter dated 18 October 2024 says the four agreements would enter successive ten-year terms beginning 8 January 2025. The letter preserves the agreement terms; it is evidence of contractual continuity, not an uptime certificate or production benchmark.[13]
IANA publishes separate delegation records for all four top-level domains. Those records expose the operational boundary through sponsoring-organisation fields, administrative and technical contacts, authoritative nameservers, WHOIS and RDAP services, and DNSSEC delegation material.[1][2][3][4]
The executed agreements define a durable control surface around registry data, registrar provisioning, DNS, registration-data services, security, continuity, escrow, reporting, and emergency transition. They do not disclose Beijing Qihu's private architecture or prove that every obligation is performed in-house.[9][10][11][12]
The recurring cost is not simply server capacity. It is the human and software work required to approve changes, preserve exact subject identity, reconcile independent ledgers, validate protocol semantics, manage supplier and registrar dependencies, investigate partial failures, test recovery, and retain evidence over a long contract life.

Image note: The accompanying generated editorial photograph provides generic registry and network-operations context. It does not depict Beijing Qihu Keji, ICANN, IANA, Tele-info, any real facility, actual architecture, measured reliability, an incident, or customer outcomes.

Four agreements define four operational entities

Beijing Qihu appears in the public evidence as the registry operator for four strings: .anquan, .shouji, .xihuan, and .yun.[5][6][7][8] The agreement pages show the same operator, agreement date, and base non-sponsored form. The 2024 renewal letter groups the four agreements for a common renewal action and gives each a successive-term start date of 8 January 2025.[13] That grouping is operationally convenient, but it does not turn the four namespaces into one entity.

Each top-level domain has its own root-zone delegation, agreement history, nameserver set, security metadata, registration-data endpoint, policy inventory, reporting trail, and potential exception queue. A common operator can use shared software and shared personnel, yet an authorised change still needs an exact target. A deployment intended for .yun should not alter .anquan. A registrar transaction should update the correct domain entity under the correct registry. A DNSSEC key event must be attached to the corresponding parent delegation. A restoration must preserve the right namespace and recent transaction history.

This makes subject identity the first reliability requirement. A registry control system should bind at least:

the legal entity named in the agreement;
the exact top-level-domain string;
the agreement and current term;
the authoritative registry database;
registrar and transaction identifiers;
the domain entity and lifecycle state;
authoritative nameservers and parent delegation;
DNSSEC keys, signatures, and parent-side DS material;
WHOIS and RDAP service identities;
data-escrow deposits and continuity contacts;
the human authority that approved a consequential change.

The four strings are short words transliterated from Chinese, but this article does not assign marketing meaning or customer intent to them. The official records establish identifiers and operator relationships. They do not establish adoption, user demographics, registration volume, revenue, or commercial success. Those would require separate datasets with defined dates and methods.

The same caution applies to the directory entity's summary. A company can hold a registry agreement without acting as a sovereign regulator of everything done under the namespace. Registry authority is specific: it concerns the database, protocol interfaces, agreement duties, and bounded policies. It does not confer general authority over applications, hosting providers, content, users, or every dispute involving a domain.

Contract continuity is not production reliability

The renewal letter is unusually useful because it sets a clear time boundary. It says the agreements would renew for successive ten-year periods and that their terms would not change merely because of renewal.[13] This supports the conclusion that Beijing Qihu remained the named operator into the next term. It does not show whether a server answered every query, whether registrar transactions succeeded, whether a recovery exercise worked, or whether a user experienced an outage.

Contract capability, product reliability, and production outcomes are separate layers.

Contract capability describes what the operator is authorised and obligated to do. The executed agreements address registry services, technical specifications, service levels, data escrow, reporting, emergency transition, security, and compliance.[9][10][11][12] These documents are authoritative for obligations and boundaries.

Product reliability concerns whether the registry platform and operating process perform those duties repeatedly. It includes transaction integrity, availability, semantic correctness, state consistency, access control, monitoring, change safety, and recovery. The public agreement documents do not provide a complete implementation or longitudinal reliability record.

Production outcomes concern what registrars, registrants, resolvers, and other users actually experience. Relevant measures would include end-to-end completion rates, failed transaction rates, DNS correctness, RDAP response quality, incident duration, correction work, and cost per accepted change. The retained source set contains no independently audited series for those outcomes.

Confusing these layers creates false confidence. A service-level clause is not measured performance. A reachable endpoint is not necessarily semantically correct. A successful renewal is not proof of operational maturity. Conversely, the absence of public performance data is not proof that the system is unreliable. The defensible conclusion is narrower: the records establish a substantial, long-lived control surface whose reliability should be measured through repeatable protocol and workflow tests.

Ten-year terms also change the engineering problem. A demonstration can be rebuilt for a launch. A registry must survive staff turnover, software upgrades, cryptographic changes, supplier transitions, policy amendments, evolving security threats, and forgotten assumptions. Long-term reliability depends as much on maintenance discipline and recoverable records as on initial implementation.

Registry authority is a ledger function

A registry maintains the authoritative record of registered names under a top-level domain and provides the interfaces through which registrars and public users interact with that record. The authority is consequential because a wrong state can prevent a domain from resolving, expose incorrect registration data, interrupt a transfer, or leave a security event unresolved. It is still a ledger and operations role rather than unlimited sovereignty.

The distinction can be expressed through four layers:

Agreement layer. ICANN records identify the operator, contract, amendments, notices, and obligations.[5][6][7][8]
Root and delegation layer. IANA records identify the top-level-domain manager or sponsor, contacts, authoritative nameservers, service endpoints, and DNSSEC material.[1][2][3][4]
Registry transaction layer. EPP or equivalent workflows create, renew, transfer, update, suspend, restore, and delete domain entities according to policy and authorisation.
Application layer. Registrants and service providers use domains for websites, mail, APIs, identity, and other systems outside the registry's direct operation.

An operator can be accountable for the integrity of the first three layers without controlling the fourth. This boundary matters during abuse complaints, security events, court orders, and policy disputes. A registry should be able to identify the domain entity, registrar, applicable rule, requested action, authorising evidence, execution record, and rollback path. It should not treat a broad allegation as permission to rewrite unrelated records.

The ledger model also clarifies what automation can and cannot do. Software can compare desired and observed delegation, validate transaction schemas, check DNSSEC chains, detect expired credentials, and flag inconsistent registration data. It cannot decide every ambiguous authority question without human review. A request may identify the wrong entity, conflict with another order, omit a required scope, or require interpretation of policy and contract. Automation can route and constrain the case; accountable people still need to resolve uncertainty.

The operating cost therefore includes both routine processing and exception governance. Routine paths should be deterministic, logged, and reversible. Exceptional paths should preserve evidence, restrict privileges, require explicit approvals, and expose uncertainty. A system that automates the common case but hides exceptions can move work from registrar staff to senior incident and legal teams rather than reducing total work.

Independent records must be reconciled, not flattened

The four ICANN pages and four IANA pages answer related but different questions.[1][2][3][4][5][6][7][8] ICANN's pages organise contractual records. IANA's pages present delegation and service information. A registry platform maintains its own state. Monitoring observes network behavior. These ledgers can change on different schedules and use different role labels.

A mature control system should not flatten them into one “active” flag. It should preserve source, timestamp, authority, and semantics for each field:

Record	Useful evidence	Important limitation
Registry agreement	Named operator, agreement form, term, amendments, notices	Does not prove current DNS behavior or private implementation
IANA delegation record	Published nameservers, contacts, WHOIS/RDAP endpoints, DNSSEC delegation	Point-in-time public record, not a complete incident or contract history
Registry database	Domain lifecycle and registrar transaction state	Private state requires access control and independent verification
Protocol observation	What DNS, RDAP, WHOIS, or EPP returns at a time and vantage point	A sample does not establish continuous performance
Escrow or recovery evidence	Ability to reconstruct authorised state	A deposit is not useful until completeness and restoration are tested

Reconciliation should produce typed exceptions rather than generic alarms. An agreement contact difference is not the same as a nameserver mismatch. A root-zone update pending within an approved window is not the same as an unauthorised delegation. A reachable RDAP server returning the wrong entity is more serious than a cosmetic website error. Severity should follow the affected authority, exposure, and recovery path.

The workflow begins with an intended-state record. A change request should contain the exact TLD, field, old value, new value, authority, owner, review requirement, planned time, dependencies, validation method, and rollback condition. After execution, the system should compare the registry, root, service, and observed states. Closure requires evidence that the intended entity changed and unrelated entities did not.

This approach adds supervision work, but it prevents a more expensive class of silent errors. Without reconciliation, a team may believe a change succeeded because one system accepted it. A resolver may still see an old delegation. A registration-data endpoint may answer but route to stale data. A monitoring tool may query a cache. A rollback may restore DNS while leaving DNSSEC inconsistent. Exact multi-ledger verification turns these possibilities into explicit checks.

DNS delegation is the running-code boundary

The IANA records make DNS delegation visible for each of the four top-level domains.[1][2][3][4] They publish authoritative nameserver information and related contact and service fields. These records are a stronger guide to what the public DNS is configured to use than a marketing page or a general corporate statement.

Delegation reliability has several distinct components:

the parent zone contains the intended nameserver set;
required glue addresses are correct;
IPv4 and IPv6 paths reach authoritative service;
each authoritative server serves the intended zone;
servers agree on relevant zone state;
responses have correct authority and negative-answer behavior;
DNSSEC material forms a valid chain when enabled;
monitoring distinguishes authoritative responses from cached recursive answers;
changes are attributable to an approved case;
rollback includes both delegation and security metadata.

A simple “DNS returned an answer” check covers only a fraction of this surface. It may query one resolver, one address family, and one cached entity. It may not verify the authoritative server or DNSSEC. It may accept a response for the wrong zone. Repeated-task evaluation should vary vantage point, protocol family, record type, positive and negative query, and authoritative endpoint.

The minimum useful reliability report would state the observation interval, query method, locations, endpoints, success definition, semantic checks, retries, exclusions, and incident attribution. Without those fields, an availability percentage can look precise while measuring the wrong thing. The public records used here do not provide such a longitudinal report for Beijing Qihu, so this article does not publish an uptime, latency, anycast, or capacity claim.

Shared infrastructure can reduce repetitive work across the four TLDs, but it also creates correlated risk. A common deployment system, key-management service, configuration template, credential store, monitoring stack, or operations team can propagate one error to several namespaces. The public evidence does not reveal which components are shared, so the appropriate conclusion is a due-diligence requirement rather than an architectural assertion.

For each component, an operator should know the failure domain, owner, substitute, recovery dependency, and independent verification path. Four differently named authoritative servers do not necessarily represent four independent systems. Conversely, a common service domain does not prove a single failure domain. Independence must be demonstrated through design and test evidence.

RDAP and WHOIS must be semantically correct

The IANA pages publish registration-data service information for the four TLDs.[1][2][3][4] Reachability is the easiest property to test and one of the least sufficient. A service can return HTTP success while presenting the wrong entity, stale lifecycle state, malformed events, inconsistent nameserver data, or privacy handling that does not match policy.

Semantic testing should use a controlled corpus that includes:

a known active domain;
a nonexistent domain;
a domain in each supported lifecycle state;
internationalised input where applicable;
registrar, entity, and nameserver lookups;
malformed requests;
rate-limit behavior;
redacted and public fields;
event chronology;
links and notices;
consistency with the authoritative registry entity.

For every case, the test should verify not only schema validity but identity and meaning. The returned handle must refer to the intended entity. Status values should correspond to registry state. Event timestamps should be coherent. Nameserver relationships should match the domain. Error responses should distinguish absence, invalid syntax, unauthorised access, and temporary failure.

WHOIS and RDAP can coexist during a transition in registration-data systems. That creates a comparison burden. Differences may be expected because the protocols and disclosure models differ, but unexplained differences in subject identity or lifecycle state deserve investigation. A migration plan needs explicit parity rules rather than a blanket requirement that every byte match.

Registration-data reliability also has an abuse and privacy dimension. Over-disclosure can harm registrants, while under-disclosure or stale contact paths can obstruct legitimate operational and security work. The registry must implement applicable rules, but published evidence here does not establish how Beijing Qihu handles every request or exception. Claims about compliance quality, response time, or abuse outcomes would require case-level evidence.

The human cost lies in maintaining test fixtures, interpreting policy changes, reviewing exceptional disclosures, managing rate limits, investigating semantic drift, and coordinating with registrars and service providers. Automation can detect schema and comparison failures. It cannot safely decide every contested disclosure or authority question without accountable review.

EPP and registrar integration turn policy into transactions

A top-level-domain registry does not serve registrants through a website alone. Registrars need a controlled transaction interface for checking names, creating and renewing domains, changing contacts and nameservers, transferring sponsorship, applying status codes, and responding to exceptional cases. The registry agreement framework makes this operational relationship material even though the public documents do not disclose Beijing Qihu's private implementation.[5][6][7][8][9][10][11][12]

The useful distinction is between protocol capability and transaction reliability. Supporting an EPP command is a capability. Processing authorised commands consistently, preserving entity state, rejecting invalid requests correctly, and recovering from partial failure are reliability properties. A registrar's successful registration campaign or lower support cost would be a production outcome. The public sources establish the contractual and delegation context, but they do not establish a benchmark for either reliability or customer outcome.

An integration review should therefore begin with the state machine rather than a list of commands. For each domain lifecycle action, the operator and registrar need to agree on:

preconditions and authorisation;
entity and credential identity;
idempotency or safe retry behavior;
synchronous and asynchronous responses;
server and client transaction identifiers;
status changes and their meanings;
linked billing or credit effects;
notification and polling behavior;
timeout and ambiguity handling;
reconciliation after an interrupted session;
rollback, compensation, or escalation when direct reversal is impossible.

A timeout is a classic exception. If a registrar sends a create command and loses the connection before receiving the response, retrying blindly can produce a duplicate charge or a confusing rejection. Treating the request as failed can lead the registrar to tell the customer a name is unavailable even though the entity was created. The correct response is an identity-based reconciliation: query the entity, compare transaction references and timestamps, determine whether the intended state exists, and only then retry or compensate.

Bulk operations multiply this risk. A maintenance window, product launch, renewal cycle, or registrar migration can generate a concentrated transaction load. Capacity planning should use declared workload assumptions: operation mix, entity count, concurrency, session limits, retry policy, response-size distribution, and acceptable completion time. A single peak throughput number without those assumptions is not a reliable planning input. No such workload evidence appears in the public record reviewed here, so this article makes no throughput claim.

Policy changes also become software changes. A new registration rule may affect input validation, reserved names, lifecycle status, billing, notification, data retention, dispute handling, and reporting. Registrars need versioned documentation and a test environment that reflects the production contract closely enough to expose incompatibilities before deployment. The registry needs a compatibility policy that distinguishes additive changes from breaking changes and gives operators enough time to update.

The hidden cost is not only code. It includes test-domain management, credential rotation, certificate renewal, registrar onboarding, support escalation, incident replay, billing reconciliation, and exception review. Shared tooling across the four TLDs can reduce duplicated integration work, but shared defects can also spread. An operator should test common components once at depth and then verify TLD-specific policy, namespace, and configuration independently.

DNSSEC and security metadata need lifecycle control

The IANA records include DNSSEC information for the delegated zones.[1][2][3][4] That makes security metadata part of the observable control surface, not a decorative feature. A valid chain at one moment is useful evidence, but operational confidence depends on how keys, signatures, delegation signer records, timing, and emergency procedures are managed over repeated changes.

DNSSEC introduces linked state across at least the child zone, signing system, parent delegation, monitoring system, and recovery material. A change can fail while each individual system appears locally healthy. A new key may be published in the child but never become trusted at the parent. A parent record may change before the child is ready. Old signatures may expire before caches have moved to the new state. A rollback may restore zone data without restoring a coherent trust chain.

The change plan should specify:

the current and intended key state;
the exact records expected at child and parent;
propagation and cache assumptions;
observation points and validation commands;
the threshold for continuing or pausing;
the owner for every external handoff;
the rollback state and the latest safe reversal time;
evidence retained after completion.

Key custody deserves separate review. The relevant questions concern role separation, access approval, signing authority, backup protection, recovery testing, credential expiry, emergency access, and auditability. A buyer should not infer strong custody from the mere presence of DNSSEC. Conversely, absence of public architecture details is not evidence that controls are weak. It means the controls require confidential due diligence or independently scoped assurance.

Monitoring needs semantic depth. A resolver reporting NOERROR does not prove the answer validated. A monitoring system should inspect the chain from a clean vantage point, exercise positive and negative answers, check signature timing, detect unexpected algorithm or key changes, and separate authoritative defects from recursive-cache behavior. Alarms should identify the affected TLD and state transition instead of collapsing every validation problem into “DNS down.”

Emergency response creates a governance tension. A team needs a way to restore service when a normal credential or process fails, but an unrestricted emergency path can become the least controlled way to change an important namespace. Break-glass access should be narrow, attributable, time-limited, independently reviewed, and followed by reconciliation. The speed of recovery matters, but so does proof that the response did not create a second unauthorised state.

The four-TLD renewal letter shows that the contractual relationship was renewed for terms beginning in January 2025.[13] It does not prove that any specific key ceremony, monitoring platform, hardware design, or recovery test exists. Those are implementation claims and should be evaluated with implementation evidence.

Escrow, continuity, and recovery evidence

Registry continuity is different from ordinary website backup. The valuable entity is not merely a set of files. It is a coherent, authorised record of domain entities, registrar relationships, lifecycle states, transaction history, DNS configuration, contacts, security metadata, and other data required to restore or transition service. The registry agreements frame continuity obligations at a general level, while the public documents do not disclose Beijing Qihu's private recovery architecture.[5][6][7][8][9][10][11][12]

Three questions should be separated:

Can the data be reconstructed? This requires complete, timely, parseable, and internally consistent recovery material.
Can the service be restarted? This requires systems, credentials, keys, configuration, network reachability, qualified people, and dependency access.
Can authority be transferred or exercised lawfully? This requires a clear trigger, authenticated decision, documented scope, and coordination among the operator, registrars, ICANN, IANA functions, and other relevant parties.

A successful backup job answers none of these questions by itself. Recovery evidence should include validation of deposited data, restoration into an isolated environment, reconciliation against a known checkpoint, exercise of representative registration and lookup paths, and documented treatment of gaps. The test should be repeatable by people who were not the original system authors.

Recovery-time and recovery-point targets need workload context. Restoring a database snapshot is not equivalent to restoring authoritative DNS, registration-data services, transaction processing, and secure operator access. A recovery plan should identify which capabilities return first, what degraded modes are acceptable, how registrars learn the current state, how queued transactions are reconciled, and when normal service can resume.

Dependencies can dominate recovery. DNS hosting, cloud or colocation capacity, certificate authorities, hardware support, key custody, monitoring, identity systems, payment or credit systems, network transit, and human approval may each become a critical path. A continuity review should map these dependencies and test loss scenarios, including loss of a primary site, a privileged identity provider, a signing component, a vendor account, or a key person.

The public evidence does not establish that Beijing Qihu experienced a continuity failure, nor does it establish a measured recovery result. The appropriate research conclusion is that continuity is an essential evaluation category for an operator of four delegated namespaces. Claims of proven resilience require dated exercise reports, scope, observed results, unresolved findings, and evidence that corrective actions were closed.

Supervision, integration, maintenance, and exception costs

The operating burden of a registry control surface is easy to underestimate because many normal transactions are automated. Automation lowers marginal effort only when the rules, data, credentials, dependencies, and exceptions remain controlled. Four cost categories should be estimated explicitly.

Supervision cost. People must approve sensitive changes, review privileged access, inspect anomaly reports, verify recovery exercises, interpret policy, and decide ambiguous cases. Alert volume and false-positive rate matter because an overloaded review queue can become a hidden availability risk. The useful measure is not headcount alone but review demand by severity, required skill, time zone, and maximum acceptable delay.

Integration cost. Registrars, DNS systems, IANA-facing processes, registration-data services, security tooling, billing, reporting, and support systems exchange state. Every interface needs version control, test fixtures, credential management, observability, and failure reconciliation. Integration cost rises when identifiers differ, semantics are implicit, or an operation succeeds in one system but fails in another.

Maintenance cost. Protocol versions, certificates, keys, dependencies, operating systems, data schemas, policies, contact records, monitoring probes, and documentation change over time. Maintenance includes planned upgrades and the regression testing required to show that a change did not disturb unrelated TLDs. Deferred maintenance may lower a quarterly budget while increasing incident and migration cost later.

Exception-handling cost. The most expensive cases are often neither fully normal nor fully catastrophic: ambiguous transaction outcomes, conflicting authority, stale public records, partial DNS propagation, a registrar with invalid credentials, inconsistent registration data, abuse complaints lacking scope, or a security change near expiry. These cases need evidence collection, senior review, communication, and sometimes manual compensation.

A practical cost model should quantify transaction volume and exception rate separately. Suppose a routine operation is cheap but one in several thousand requires hours of specialised review. At scale, the exception queue may dominate labour and response time. The correct response is not to automate every judgment. It is to reduce ambiguity through better identifiers, typed errors, reconciliation tooling, scoped permissions, and clear escalation.

Costs also shift between organisations. A registry may simplify its interface by moving reconciliation to registrars. A registrar may reduce support by imposing more manual checks on registrants. A security control may reduce abuse while increasing false positives and exception appeals. A procurement review should ask where the work moved, who owns failures, and whether the change improves total reliability rather than one party's dashboard.

Product-reliability evidence should therefore report more than successful requests. Useful measures include semantic error rate, ambiguous-timeout rate, reconciliation backlog, privileged-change review time, recovery-test findings, stale-record duration, registrar escalation age, and repeated failure recurrence. Customer production results require another layer: whether registrars or registrants experienced fewer harmful errors, faster legitimate recovery, or lower total operational cost. Those outcomes need customer or independently verifiable evidence and are not asserted here.

Failure-mode register

The public records support a structured failure analysis, not a claim that any listed event occurred. A registry operator and its counterparties can use a register like the following to decide what evidence is required.

Failure mode	Observable symptom	Immediate containment	Evidence required before closure
Unauthorised or incorrect delegation	Parent nameserver or glue differs from approved state	Freeze related changes, preserve records, validate authority	Approved request, before/after IANA and authoritative observations, dependency review
DNSSEC chain inconsistency	Validating resolvers fail while unsigned checks appear healthy	Halt rollover, evaluate last safe state, coordinate parent and child actions	Child and parent key state, signature timing, vantage-point validation, rollback proof
Partial zone deployment	Authoritative servers disagree	Remove unsafe server from service if scoped and authorised; stop further rollout	Per-server serial and record comparison, deployment logs, cache-aware validation
Registration-data semantic drift	RDAP or WHOIS is reachable but returns stale or wrong entity state	Isolate affected path, compare authoritative registry entity	Controlled test corpus, entity identities, timestamps, protocol-specific parity rules
Ambiguous EPP transaction	Registrar times out without knowing whether a command committed	Prevent blind retry; reconcile by entity and transaction identity	Server/client references, entity history, billing effect, final state and communication
Credential or certificate expiry	Registrar, service, or operator access fails near expiry	Activate scoped renewal or alternate credential process	Inventory, ownership, expiry alert history, replacement and revocation proof
Shared configuration error	Several TLDs exhibit the same incorrect behavior	Stop common rollout and separate affected entities	Versioned config, blast-radius map, independent per-TLD validation
Escrow or backup gap	Deposit or restore validation is incomplete	Preserve current state and close data-generation gap	Completeness report, parse validation, restored checkpoint, unresolved-field register
Dependency outage	Registry component is healthy but transit, identity, signing, or hosting dependency fails	Invoke documented alternate and prioritise essential services	Dependency status, failover result, degraded-mode scope, reconciliation after recovery
Conflicting authority request	Two instructions claim incompatible control over the same entity	Pause irreversible action and restrict access	Authenticated orders, scope analysis, accountable decision, audit trail
Monitoring false assurance	Dashboard is green while authoritative or semantic checks fail	Switch to independent probes and manual verification	Probe target, resolver versus authoritative path, test corpus, observation timestamps
Recovery introduces new inconsistency	Service returns but DNS, data, billing, or transaction state diverges	Limit new writes and reconcile checkpoints	Restore source, replay boundaries, cross-system comparison, approved return-to-service

Each row has a different closure condition. “Service restored” is limited public evidence when authority, data consistency, or transaction ambiguity remains unresolved. A useful post-incident review should identify the earliest detectable signal, the control that should have acted, why it did not, the affected entities, the recovery sequence, residual uncertainty, and the owner and due date for corrective work.

Repeated-task testing should sample these failure modes before an incident. A test program might exercise an invalid transaction, a network timeout after commit, a stale RDAP replica, a DNSSEC rollover pause, a recovery from escrowed data, and a lost privileged credential. The purpose is not to manufacture a benchmark. It is to show whether procedures and evidence are sufficient to make a safe decision.

Unit economics and realistic alternatives

The four TLDs create both common-work opportunities and portfolio risk. Shared monitoring, registrar tooling, security operations, documentation, and recovery exercises can spread fixed cost across multiple namespaces. TLD-specific policy and delegation checks still require separate evidence. The economic question is not “one platform or four”; it is which controls can be shared without obscuring entity-level accountability.

A due-diligence model can divide cost into:

fixed governance and compliance work;
per-TLD delegation, DNSSEC, policy, and reporting work;
per-registrar onboarding and support work;
per-transaction processing cost;
exception and incident cost;
vendor and infrastructure commitments;
continuity testing and retained recovery capacity;
migration and exit cost.

The model should use ranges tied to observable units rather than a single total. Relevant units include delegated TLDs, registrar connections, domain entities, transaction mix, authoritative query demand, registration-data queries, privileged changes, policy releases, and exception cases. Sensitive commercial values can remain confidential while the method, assumptions, and control points are reviewed.

Alternatives should be evaluated realistically. An operator may run core systems directly, use specialist registry infrastructure, outsource selected network or security functions, or combine these approaches. Outsourcing can buy expertise and scale, but it does not transfer accountability automatically. The operator still needs evidence access, change control, incident rights, exit procedures, and the ability to reconcile the public and contractual records.

Migration is a first-class cost. Domain entities, registrar credentials, transaction state, DNS and DNSSEC data, registration-data services, escrow, reporting, monitoring, and support procedures must move without breaking authority or continuity. A low operating quote can be misleading if data portability is weak, interfaces are proprietary, or the exit plan has never been rehearsed.

There is also a credible option to keep a stable system and improve evidence rather than replace it. Better independent monitoring, typed exception queues, recovery exercises, credential inventory, registrar test coverage, and change reconciliation may address the real risk at lower disruption. Replacement is justified when the incumbent cannot meet required controls, evidence access, lifecycle support, or recovery needs, not merely because a newer product advertises more features.

A repeatable review framework

A buyer, regulator, registrar, or internal risk owner can review the Beijing Qihu control surface in seven stages.

1. Establish identity and scope. Confirm the exact legal and operational entity, the four TLDs, the applicable agreements and renewal instruments, and the distinction between registry, registrar, registrant, DNS operator, and root-zone roles.[1][2][3][4][5][6][7][8][13]

2. Build an authority map. For every changeable entity, record who can request, approve, execute, observe, and reverse a change. Include delegation, DNSSEC, domain lifecycle, registrar access, registration-data disclosure, and emergency actions.

3. Reconcile public and private records. Compare contract records, IANA delegation data, registry state, protocol observations, and recovery evidence without treating any one source as complete. Preserve source and time for every comparison.

4. Test repeated operations. Exercise representative EPP lifecycle actions, DNS changes, DNSSEC transitions, RDAP and WHOIS semantics, credential rotation, monitoring alarms, and reconciliation after uncertain outcomes. Define pass criteria before the test.

5. Test exceptional operations. Run controlled scenarios for lost credentials, conflicting authority, dependency failure, partial deployment, stale data, and recovery. Verify that privileges narrow during the event and that final state is reconciled.

6. Quantify total cost. Estimate supervision, integration, maintenance, and exception handling alongside infrastructure and licence spend. Identify which organisation bears each cost and how correlated failures change the risk.

7. Demand outcome evidence carefully. Separate supported protocol capability from observed service reliability and customer production result. Require methodology, period, denominator, exclusions, and independent corroboration for any quantitative claim.

The resulting decision should state what is known, what is observed only at a point in time, what remains private, which assumptions are material, and what evidence would change the conclusion. This structure is more useful than a generic maturity score because it keeps authority, running behavior, and operational outcome distinct.

Conclusion

Beijing Qihu's public record provides an unusually clear bounded entity for technology-company research: four delegated top-level domains, four registry agreement records, four executed agreements, and a renewal instrument covering terms beginning in 2025.[1][2][3][4][5][6][7][8][9][10][11][12][13] Those records establish operator identity, contractual continuity, and observable namespace-control surfaces. They do not establish private architecture, uptime, capacity, incident history, or customer results.

The most important operating principle is that a registry is an accountable recordkeeper for unique namespace entities. Reliability depends on the agreement, delegation, registry database, transaction interface, registration-data services, security metadata, and recovery evidence remaining coherent. Running DNS and protocol behavior deserves priority over descriptive claims, but running behavior must still be interpreted against authority and policy.

For Beijing Qihu and its counterparties, the practical work is disciplined reconciliation: verify every material change across authoritative records, test semantic outcomes rather than reachability alone, preserve transaction identity through ambiguous failures, constrain exceptional authority, and exercise recovery before it is needed. Shared systems may lower recurring cost across four TLDs, while increasing correlated risk if evidence remains aggregated.

A sound procurement or oversight decision should therefore ask four questions. What can the system do? How reliably does it do it under a declared method? What production result has been demonstrated for registrars and registrants? What supervision, integration, maintenance, and exception cost was required to achieve that result? The public record answers the first question only in part and frames the controls needed to answer the others.

Beijing Qihu Keji's Four-TLD Registry Control Surface: DNS Delegation, RDAP, and Continuity Costs