ZDNS Names Eight DNS Locations, but Public Evidence Cannot Assign It a Single Rack

Summary

• Public records support a Medium evidence grade for ZDNS’s network and logical-service footprint: the company appears in the 2026 ICANN evaluation record, names eight location dependencies, operates a visible dual-stack routing surface and serves identifiable top-level-domain delegations.
• Evidence for ZDNS-attributable physical capacity and usable failover headroom is Weak. The public 732-rack annex describes a host facility, not ZDNS’s allocation, and no reviewed material supplies installed inventory, spare inventory, site load or a largest-site-loss result.
• A serious buyer should ask for dated evidence that joins sites to functions, equipment, traffic, withdrawal behavior, restore tests, DNSSEC emergencies, escrow validation and achieved recovery objectives. Anycast, daily deposits and documented controls are useful capabilities, but none alone demonstrates recovery.

The important question begins after “the network exists”

There is ample public material with which to establish that ZDNS operates a real and consequential internet-facing service. The 2026 evaluated-applications list records ZDNS as cleared for Main, DNS, DNSSEC and Proxy service types, including support for internationalized domain names. The related ICANN programme page explains the setting in which that evaluation sits. ZDNS’s own pages describe registry functions and a broad DNS portfolio, while routing observations show a live dual-stack surface. Those are meaningful signals. They answer the basic existence question.

They do not answer the harder operating question: what remains usable when a major dependency disappears?

That distinction matters because a globally visible DNS answer can be produced by a surprisingly thin slice of an overall system. Routing can direct a query toward an available endpoint without revealing the number of servers behind it, the power reservation supporting those servers, the spare ports at the site, or the ability of the control plane to recover from damaged state. A registry can deposit data every day without proving that a recovery team has recently decrypted, loaded and reconciled the deposit. A location list can name eight rows without showing eight independent failure domains.

A certificate can describe hundreds of racks without establishing that ZDNS occupies even one of them.

The right diligence question is therefore not “Does ZDNS have global infrastructure?” The public record gives enough support to say that it has a globally visible logical and network presence. The better question is: how much of that presence can be tied to ZDNS-attributable physical assets, available failover capacity and demonstrated recovery?

That framing produces two different evidence grades, and they should remain separate. Network and logical-service evidence is Medium. ZDNS-attributable physical capacity and usable failover headroom evidence is Weak. Combining them into a single reassuring “capacity” label would conceal the largest information gap. It would allow reachability to stand in for reserves, and service descriptions to stand in for tested survivability.

This is not a claim that ZDNS lacks equipment or resilience. It is a claim about what an outside buyer can establish from the reviewed public record. Absence of disclosed inventory is not proof of absent inventory. It is, however, a rational reason to withhold a stronger conclusion until the operator supplies dated, site-specific evidence.

Attribution comes before arithmetic

Capacity analysis fails quickly when the identity of the asset holder, network holder and service operator is blurred. The directory label for this company preserves “Resrarch,” the spelling visible in the APNIC RDAP record for AS38345. The current ICANN application uses the corrected legal name and the DBA ZDNS, while the company’s contact page supports the contemporary identity. The spelling difference is not a basis for inventing a second company. It is a record-keeping wrinkle that should be preserved where the directory contract requires it and handled cautiously in narrative analysis.

Timing creates a second wrinkle. AS38345 registration predates ZDNS’s stated 2013 establishment, and the older APNIC Whois view retains KNET contacts. ZDNS’s corporate overview describes the company and its service direction, but the available facts do not establish an acquisition, predecessor arrangement or ownership chain that would reconcile every historical field. A careful assessment should not manufacture that history.

Instead, attribution should be made one layer at a time. A route originated by AS38345 supports an inference about a network surface associated with that autonomous system at the time observed. It does not automatically establish who owns the server reached through the route. A data-centre attachment submitted with an application supports the existence of a disclosed dependency. It does not establish rack title, lease quantity or exclusive use. A technical-contact entry in a delegation supports an operational role around the delegated namespace. It does not disclose the contractual division of responsibility behind the endpoint.

These distinctions are more than legal niceties. They control every later calculation. If a facility total is treated as an operator allocation, then rack count, power and generator capacity become inflated before analysis starts. If each route origin is treated as a separately owned site, network diversity becomes physical diversity by assumption. If a shared authoritative naming pattern is treated as dedicated customer infrastructure, isolation is asserted without evidence.

The disciplined method is to ask three questions for every number or label. What exactly does the record describe? Which entity can it be attributed to? What operating conclusion does that evidence permit? Under that method, the ZDNS record is strongest at the logical-service and network layers. It becomes much thinner at the layers of installed hardware, reserved resources and surviving capacity.

Eight location rows describe dependencies, not eight independent sites

The most concrete geography comes from the ZDNS data-centre attachment. It lists eight rows: CSNET Beijing; Jiuxianqiao in Beijing; Chengdu; HKIX in Hong Kong; and Cogent locations in Los Angeles, Chicago, Frankfurt and New York. The attachment associates Beijing, Hong Kong, Los Angeles, Chicago, Frankfurt and New York with anycast, while Jiuxianqiao and Chengdu are associated with unicast services.

That is useful disclosure. It shows a design that depends on facilities and networks across several cities and regions. It provides more substance than a marketing phrase such as “global coverage.” It also makes it possible to ask concrete follow-up questions about which service functions live in which rows.

Yet a row is not a node count, and a node is not necessarily a failure domain. The attachment does not state how many servers occupy each location, whether the same control plane feeds all of them, how much query load each carries, or which links share physical conduits. It does not map public addresses to particular rows. It does not show whether the four Cogent entries are purchased under one arrangement, whether their upstream dependencies converge elsewhere, or whether some rows perform narrower roles than others.

The labels themselves reinforce the need for restraint. The HKIX public operations site describes an exchange environment; it does not establish the equipment, capacity or contractual terms ZDNS has there. The Cogent network map describes a broad network; it does not turn four city names into four ZDNS-owned facilities. A dependency on an exchange or carrier location can be operationally valuable, but the public label alone cannot reveal reserved headroom or physical independence.

Even the split between anycast and unicast requires care. Anycast can make multiple sites present the same address and allow routing to select a nearby or preferred path. Unicast exposes a more location-specific address relationship. Neither label supplies the missing equipment schedule. Neither says which row hosts registry databases, signing systems, log stores, monitoring, customer administration or authoritative serving. Neither quantifies the share of ordinary traffic at the largest site.

For buyers, the eight rows should be treated as the beginning of a dependency map. The next document should be a site-and-function matrix: each row, each service role, each address family, each routing mode, the installed and spare equipment, ordinary and peak load, network commits and the dependencies shared with other rows. Until that matrix is available, “eight locations” remains a statement about named dependencies, not a count of eight equal, independent and fully replaceable units.

The 732-rack figure belongs to a host facility, not to ZDNS

One number in the attachment is especially likely to travel farther than its evidentiary limits allow. A certificate annex for Beijing M5 Phase III covers 732 racks across three rooms. It also lists two 3,517 kW chillers, two 84 cubic-metre chilled-water tanks and five 2,500 kVA diesel units. Those figures sound like a substantial infrastructure base, and they are evidence that the disclosed host dependency has material facility systems.

They are not ZDNS capacity totals.

The annex describes the host facility’s certified scope. It does not say how many racks ZDNS occupies, leases, reserves or can obtain during an emergency. It does not assign either chiller, either tank or any diesel unit to ZDNS. It does not give ZDNS’s contracted power, measured draw or allocation by room. Network and cabling are outside the certificate scope, so the document also cannot demonstrate diverse entrances, independent carrier paths or spare cross-connects for the DNS operation.

The same rule applies to the Huairou description. The material covers roughly 20,000 square metres and more than 1,000 cabinets. The CNIC institutional overview supplies context for the institution, but the aggregate area and cabinet figures cannot be assigned to ZDNS. A large host environment may offer favourable conditions, but it cannot be added to the tenant’s balance of usable capacity without allocation evidence.

This is where infrastructure narratives often slide from dependency to possession. The host has a generator, therefore the tenant “has” that generator. The building contains 732 racks, therefore the tenant “has access to” 732 racks. The campus contains more than 1,000 cabinets, therefore the service has enormous reserve. None of those conversions is supported here. Shared facility systems can benefit ZDNS while remaining neither owned by nor exclusively available to it.

The distinction also affects failure analysis. A facility-wide generator total says little about the runtime available to a particular load, fuel replenishment arrangements, maintenance state or whether the tenant’s distribution path is within the tested scope. Chiller totals do not show how much cooling remains after a component failure at the tenant’s actual density. Rack totals do not show powered and networked spare capacity. The 732-rack figure is therefore evidence of a host dependency and its aggregate certified systems. It is not evidence of 732 racks of ZDNS capacity, and it should never be presented that way.

Tier language sets a design expectation, not a spare-capacity measurement

The Main RSP application asserts at least two independent data centres at Tier III or equivalent, along with backup, monitoring, recovery controls and a 24-hour on-call response. These are relevant commitments. At face value, they describe a design intended to avoid dependence on a single facility and to support continuous operations.

Tier terminology has a narrower job than it is often asked to perform. The Uptime Institute tier overview provides the general framework, but a tier level is not an answer to “How much of my service survives the busiest-site failure?” Facility topology and maintainability are not the same as service-level reserve. Two suitable buildings can still contain an application whose ordinary load is concentrated in one location. They can share a database dependency, a signing dependency, a carrier path, an administrative control or an error domain.

Nor does the public assertion reveal the denominator. There is no disclosed installed server count, spare server count, port commit, DDoS reserve or largest-site share. There is no table showing that the remaining locations can absorb the withdrawn site’s normal and peak load while retaining safety margin. “At least two” establishes a minimum architectural claim; it does not quantify capacity inside either location.

Independence also needs to be demonstrated at the service level. Buildings may be geographically separate while software release, key management or registry data remains coupled. Power systems may be independent while a route-control mistake affects both. Carrier names may differ while physical conduits converge. Conversely, a service can obtain meaningful resilience from carefully engineered shared infrastructure. The point is not to infer weakness from every shared element. It is to make shared elements visible enough that their consequences can be tested.

A buyer evaluating the Tier III-or-equivalent claim should request the facility designation or equivalence basis, then connect it to ZDNS’s actual deployment. Which rooms contain the equipment? Which power paths feed it? What network components are inside and outside the assessed scope? How much load was transferred during maintenance or a simulated loss? What capacity remained afterward? Without those links, tier language supports confidence in the stated design direction, but it cannot close the evidence gap around usable failover headroom.

AS38345 shows a live dual-stack surface, not a hardware inventory

Routing evidence is among the strongest parts of the public record. During the research observations, AS38345 announced 24 IPv4 /24 prefixes and 12 IPv6 /48 prefixes, with broad collector visibility. The RIPEstat AS overview, announced-prefixes view and routing-status view provide different windows onto that surface. Cloudflare Radar’s AS38345 page offers another routing-oriented view.

Together, those observations support a measured conclusion: AS38345 was visibly announcing a meaningful set of IPv4 and IPv6 routes. That is good evidence of a live dual-stack network presence. It is not evidence of a particular server count, traffic ceiling or geographic distribution.

BGP tells the internet how to reach prefixes. It does not publish a bill of materials behind them. The same prefix might be served from multiple anycast locations, or its observed path might terminate in a smaller set of active nodes. A collector can see a route while the application behind that route is unhealthy. Broad visibility can coexist with a shared physical bottleneck. Conversely, a modest number of prefixes can front a substantial service. Prefix arithmetic is therefore a poor substitute for equipment and load evidence.

The related ASN-neighbours data and routing-consistency data help describe routing relationships and observations. They still cannot show whether two apparent paths enter a building through separate conduits, whether edge routers have spare ports, or whether a scrubbing arrangement has reserve for a large attack. Logical path diversity is valuable, but physical path diversity must be established separately.

RPKI samples need the same restraint. One sampled AS38345 prefix returned valid in the 150.242.156.0/24 validation view, while another returned unknown in the 1.8.1.0/24 validation view. Two observations are not a permanent score for the autonomous system, and “unknown” is not evidence of hijacking. They are samples that justify a broader, dated route-origin review, not a sweeping verdict.

The routing record deserves its Medium evidence grade because it is observable, specific and relevant. It remains a network-layer record. Treating it as physical-capacity proof would ask BGP to answer questions it was never designed to answer.

Delegations expose an operational pattern without revealing the machines

Root-zone delegation records connect ZDNS to identifiable authoritative-DNS responsibilities. The IANA pages for .baidu, .icbc and .unicom identify ZDNS as a technical contact and expose a shared pattern in authoritative endpoints. This is concrete evidence that ZDNS is not merely describing a hypothetical DNS service. It has a visible role in delegated top-level domains.

The records nevertheless describe delegation, not the physical implementation underneath it. They do not show which city answers a particular query, how many nodes serve each top-level domain, whether customers share hosts, or how capacity is divided among them. They do not reveal whether a name-server label maps to one platform or several operationally isolated groups. A technical-contact role also does not disclose every contractual boundary among the registry operator, DNS operator, facility and network.

Selected address observations reinforce the mixed-origin picture. Network information for 203.99.24.1, 116.169.54.111, 223.72.199.37 and 2401:8d00:2::1 showed selected authoritative addresses from AS38345, AS4837, AS56048 and AS24149. Multiple origins can be consistent with a distributed service and varied dependencies.

They do not, by themselves, prove separate facilities or diverse conduits. Route origin does not settle server ownership, lease terms or responsibility for operation. It also does not show that the different origins have equal capacity, common data freshness or independent control. A robust design may intentionally use several networks, but the resilience conclusion should follow from a tested service map rather than the count of autonomous-system numbers.

Secondary-DNS design guidance in RFC 2182 underscores why diversity matters: authoritative service should avoid easily shared failure modes. The public delegations and origins give buyers a useful starting point for that inquiry. They cannot finish it. The missing bridge is a mapping from customer-facing delegation to serving groups, networks, facilities, capacity shares and tested failure behavior.

One brand spans several operating surfaces

ZDNS’s public materials describe more than one product. The company’s TLD platform page discusses registry-oriented functions and performance claims. Its cloud DNS page describes hosted DNS capabilities. Its core equipment page presents a separate deployable-appliance line. The broader portfolio includes escrow, DNSSEC, WHOIS/RDAP, authoritative DNS, GSLB, HTTPDNS and BGP/anycast. The ICANN Base Registry Agreement supplies relevant registry context, but it does not collapse those products into one operating surface.

This breadth is commercially useful and analytically dangerous. “ZDNS service” can refer to at least three distinct arrangements: registry functions operated as part of a top-level-domain platform; hosted authoritative or cloud DNS delivered over shared internet infrastructure; and equipment deployed in a customer-controlled environment. Each arrangement has a different asset boundary, dependency chain and recovery responsibility.

An appliance installed at a customer site should not be counted as spare capacity for the hosted DNS cloud. A globally routed authoritative node should not be assumed to contain the registry database. A registry escrow commitment should not be treated as proof that a hosted enterprise DNS zone can be restored through the same mechanism. DNSSEC key custody may differ by customer and service type. The public record does not support a universal legal or operational assignment for every deployment.

The same care applies to performance. A query-rate figure attached to WHOIS/RDAP says little about the signing system’s ceiling. A signing-transaction claim does not tell us the authoritative service’s attack reserve. Two billion daily DNS resolutions is a volume statement, not a topology statement. Combining them can produce an impressive but meaningless total.

A buyer should therefore define the service boundary before asking for resilience evidence. Which functions are in scope? Which are shared? Which remain on customer premises? Where are registry data, zone data, logs, backups and keys stored? Who can change routes? Who can restore the database? Who owns the recovery objective? Only after those questions are answered can the location and capacity evidence be matched to the service actually being purchased.

This layered view also explains why a single company-wide evidence grade would be misleading. ZDNS has enough public evidence to support a Medium assessment of the visible network and logical-service footprint. The specific physical assets and spare capacity available to any one product remain weakly evidenced. Different products may perform better or worse than that public baseline, but the reviewed material does not quantify the difference.

Marketing capacity is not surviving capacity

ZDNS markets several striking performance numbers: 3,000 signing transactions per second, 15,000 key pairs, WHOIS/RDAP throughput between 16,000 and 27,000 queries per second, two billion DNS resolutions per day, and availability above 99.999 percent. These figures are relevant because they indicate the scale and service qualities ZDNS wants buyers to associate with its platforms.

They cannot be converted directly into available failover headroom.

First, the public claims lack a dated measurement method. The record does not define the test workload, response mix, cache behavior, entity size, transport conditions or duration behind each number. It does not say whether the values were measured on one appliance, a cluster, a lab configuration or a deployed fleet. It does not supply concurrency, latency percentiles or error thresholds. Without that context, values that look comparable may describe entirely different conditions.

Second, there is no utilization denominator. A system capable of a stated peak may ordinarily run at a small fraction of it, leaving ample reserve, or it may run close to the practical ceiling once real traffic, defensive controls and maintenance are included. The public record does not disclose ordinary load, observed peak load or a safety margin by site. Two billion resolutions per day is roughly a volume description across a day; it does not disclose the highest second, the busiest node or the largest customer concentration. No additional arithmetic can recover those missing facts.

Third, capacity under normal conditions is not capacity after failure. If the largest site carries a substantial share of ordinary queries, surviving sites must accept that load while retaining protection against peaks and attacks. Database work, signing, monitoring and route changes may become bottlenecks before authoritative query handling does. A claimed 99.999-percent availability level does not show the incident population, measurement window, exclusions or customer cohort behind it. It also cannot identify how the system behaves in the particular scenario a buyer cares about.

Fourth, availability and recoverability are different. A distributed DNS edge may continue answering while a registry database is impaired. A control plane may recover while stale or inconsistent data remains at the edge. An appliance may meet a local throughput number while the hosted service has a separate dependency. The performance claim must be attached to the exact component and failure scenario.

The missing evidence is straightforward to describe: installed inventory, spare inventory, ordinary and peak load, network commits, mitigation reserve, largest-site share and the measured result of removing that site. Those values would allow a buyer to calculate surviving load and residual margin. In their absence, the marketed figures remain claims about potential or achieved performance under undisclosed conditions. They should not be presented as proof that the service can absorb a major site loss.

Anycast is a routing tool, not a recovery certificate

Anycast is central to the disclosed design. Several location rows are associated with it, and the technique is well suited to authoritative DNS. Multiple locations can announce the same address, allowing internet routing to select a path. When a failed node cleanly withdraws its route and healthy locations have enough capacity, traffic can shift away from the problem. RFC 4786 describes the operational characteristics and cautions that make anycast useful but not magical.

The favourable scenario contains two conditions that public location counts do not prove: the bad route must disappear, and surviving sites must be able to accept the displaced load. If an unhealthy node continues advertising, traffic can keep reaching it. If withdrawal is slow or uneven, some networks may continue selecting the failed path. If the surviving nodes lack spare query, network or mitigation capacity, a clean withdrawal can simply move overload elsewhere.

Anycast also does not repair state. It cannot restore a corrupted registry database, reverse a bad global configuration, recreate lost signing material or reconcile conflicting data. A common change can damage every location even when the locations are physically independent. A key-management fault can affect signing without interrupting every authoritative answer. A monitoring error can delay withdrawal. These are shared logical failure modes, and adding cities does not automatically remove them.

The right test is observable. Withdraw one location’s service route under controlled conditions. Measure convergence from representative networks. Track error rate, latency and load at every surviving site. Confirm that the route does not linger where it should not. Then restore the location and verify that re-entry does not create inconsistent service. Repeat for the largest site, not only for the easiest or smallest node.

The public record does not provide a dated result from that exercise. It therefore supports a statement about capability: ZDNS describes and visibly uses the ingredients of a distributed routing design. It does not support a statement about demonstrated headroom: the reviewed sources do not quantify how much traffic can be displaced, how quickly it moves or what margin remains afterward.

That is why anycast strengthens the Medium network and logical-service grade but cannot lift the Weak physical-capacity and failover-headroom grade on its own.

DNSSEC and escrow controls need executed results

Recovery evidence is more than equipment evidence. ZDNS’s KSK management attachment describes annual and emergency key-signing-key rollover, HSM and intrusion-detection monitoring, out-of-band communication, tabletop exercises and a postmortem design. These are sensible control elements. They indicate that key events, emergency coordination and learning after incidents have been considered.

The document is still a description of how work is intended to be performed. It does not disclose the most recent executed emergency rollover, its duration, the problems encountered or the objective achieved. It does not establish that every customer uses the same custody arrangement. A general control description cannot answer which legal entity holds which keys, how quorum is formed for a specific service, or whether backup material was successfully used in the last test.

Escrow has a similar evidence boundary. The Main application says full registry escrow deposits occur daily and failed deposits are retried. Daily cadence is useful. It reduces the intended interval between full deposits and creates an explicit response to a failed submission. Yet a successful transfer is only one link in a recovery chain. Completeness, integrity, decryptability and compatibility with the restore environment still need to be established. The restored registry must then be reconciled and made operational.

An achieved recovery point objective cannot be inferred from “daily.” The newest deposit may omit or fail validation; transaction timing may create a different effective point; restore teams may discover that the usable deposit is older. Likewise, an achieved recovery time objective cannot be inferred from an on-call commitment. The clock includes access, decision-making, data retrieval, decryption, restoration, validation, routing and service acceptance.

For a buyer, the decisive evidence would be a dated test record. It should identify the service, failure condition, starting state, personnel roles, data set, key material, elapsed stages, errors, final integrity checks and measured RTO/RPO. A DNSSEC emergency record should show the rollover or recovery path actually exercised. An escrow record should show a deposit successfully validated and restored into a clean environment. A database exercise should show consistency checks and application readiness, not only file recovery.

None of the reviewed public material supplies that complete result set. The documented controls should therefore be credited as design evidence, not dismissed. But they should not be upgraded into proof of recent successful recovery.

A local DNS answer does not establish local data custody

ZDNS’s authoritative service has a global public-data-plane surface. Anycast is designed to make an address reachable from multiple places, often steering a user toward a network-preferred instance. That can improve latency and fault tolerance. It can also create a misleading intuition: if the answer arrived quickly from a nearby network location, the user’s underlying data must have stayed nearby.

The public record does not support that conclusion.

An authoritative DNS response can be served from a local or nearby node while registry data, customer configuration, query logs, backups, keys or administrative controls reside elsewhere. The edge may hold a copy of a zone while updates originate from a remote control plane. Monitoring and incident access may cross borders even when query serving does not. A backup or escrow deposit can occupy a different jurisdiction from the active serving copy. Key custody can have its own location and legal boundary.

The eight-row location attachment helps identify possible data-plane dependencies, but it does not disclose the placement of these other data classes. It does not map registry databases to cities, identify log retention locations, name backup jurisdictions or show where HSM-backed keys are held. The split between anycast and unicast says nothing by itself about data residency.

This matters differently to different customers. A registry operator may focus on registration data, escrow and signing authority. An enterprise DNS customer may care about zone content, query telemetry and administrative access. A registrant may be affected by policies at the registry and registrar layers. A downstream user may care mainly about resolution availability. One locality statement cannot satisfy all of those concerns.

A defensible locality representation should therefore be data-specific and function-specific. It should state where authoritative copies are served, where the source of truth is stored, where logs are retained, where backups are kept, where keys are controlled and from which jurisdictions administrators can act. It should distinguish ordinary operation from disaster recovery, because emergency restoration may use a different location.

Without that map, ZDNS’s global routing surface proves global reach, not local custody. Buyers should resist both extremes: a nearby response is not proof of local storage, but a globally distributed DNS edge is not by itself proof that every data class is globally replicated. The evidence supports neither shortcut.

The dependency chain has several kinds of users

The consequences of a DNS or registry failure cannot be reduced to a single customer count. Registry operators, registrars, registrants, recursive resolvers, enterprise DNS customers and downstream users depend on different layers of the system. Their exposures overlap, but they are not interchangeable.

A registry operator relies on core registry functions, delegation data, signing and escrow arrangements. Registrars depend on registry interfaces and consistent data. Registrants depend on both the registrar relationship and the registry’s continued operation. Recursive resolvers depend on authoritative availability and correctness. Enterprise DNS customers may rely on hosted authoritative service, HTTPDNS or traffic-management functions. Downstream users encounter the final effect through applications and domains they attempt to reach.

This layered chain is why an apparently narrow incident can have broad consequences. An authoritative serving issue can impair resolution while registry records remain intact. A registry database issue can impede changes while cached and existing DNS answers continue. A signing problem can create validation failures for some users even when packets still reach the authoritative service. A shared bad configuration can affect several locations at once. The visible symptom does not always identify the failed layer.

It is also why public customer or domain totals, if available, would not translate cleanly into affected people or critical services. One domain may be lightly used; another may support a heavily depended-upon application. One customer may have independent secondary DNS; another may not. Recursive caching changes timing and reach. Criticality depends on what uses the domain and what alternatives exist, not only on how many names are under management.

For diligence, the useful unit is the service dependency. Buyers should identify which ZDNS layer they consume, which other organizations sit in the path, what data or key state is required, and what fallback exists outside the same failure domain. That mapping turns a vague “DNS risk” into testable scenarios and prevents unrelated headline numbers from being used as a proxy for impact.

The proof package a serious buyer should request

The gaps in the public record can be closed, but only with evidence that joins architecture to operation. A strong diligence package would begin with a dated site-and-function matrix. Every disclosed row should appear: CSNET Beijing, Jiuxianqiao Beijing, Chengdu, HKIX Hong Kong, Los Angeles, Chicago, Frankfurt and New York. For each row, the matrix should identify authoritative serving, registry database, DNSSEC, WHOIS/RDAP, GSLB, HTTPDNS, monitoring, administrative and backup roles as applicable. It should distinguish anycast from unicast and map the relevant address families and serving groups.

Second, the package should contain attributable inventory. That means ZDNS-controlled or contractually available servers, network devices, HSMs, storage, powered racks, ports and spares by site. Host-facility totals should be shown separately. If a shared facility control benefits the service, the evidence should state the contracted service level and the tenant path it protects. The 732 racks, chillers, tanks and diesel units must remain facility figures unless an allocation document connects some defined share to ZDNS.

Third, buyers need load and reserve data. For each service and site, ZDNS should provide ordinary load, observed peak, practical ceiling, planned safety margin and largest-site share over a stated period. Network commits and defensive capacity should be included where relevant. The figures should use a workload definition that makes the marketed signing, key, WHOIS/RDAP, DNS-resolution and availability claims interpretable. A capacity number without current utilization cannot establish headroom.

Fourth, routing resilience should be demonstrated. A controlled route-withdrawal exercise should record the selected site, prefixes, start time, observation points, convergence, error rate, latency, displaced load and residual margin. An unhealthy-but-still-advertising scenario should be considered because it tests detection and withdrawal rather than merely routing’s response to a clean disappearance. Re-entry should also be observed.

Fifth, the largest-site-loss exercise should cross layers. It should remove the location carrying the largest relevant load and show that authoritative service, registry functions, administration, monitoring and signing continue as designed. If some functions intentionally recover rather than continue, the measured objective should be explicit. Surviving sites should be measured under load long enough to expose thermal, network, state or queueing limits.

Sixth, restoration evidence should cover both database and escrow paths. A clean environment should receive the chosen backup or deposit, decrypt it, load it, reconcile it and pass application-level checks. The record should state the data point achieved and the elapsed recovery time. A deposit receipt without a restore result is not sufficient. A file restore without functional registry checks is not sufficient.

Seventh, DNSSEC emergency evidence should show an executed scenario involving the relevant keys, HSM controls, authorization, out-of-band communications, publication steps and validation outcome. The exercise should disclose whether it was a tabletop or a technical execution; both are useful, but they prove different things. Any issue found should be connected to a corrective action and later retest.

Finally, the package should state service and locality boundaries. It should identify which evidence applies to registry operations, hosted DNS and customer-premises equipment. It should map authoritative copies, source-of-truth data, logs, backups, keys and administrative access by jurisdiction. That prevents a global edge footprint from being mistaken for a universal data-location claim.

None of this requires disclosing sensitive diagrams publicly. A buyer can review controlled evidence, redacted records or independent attestations. What matters is that the record is dated, scoped and tied to the purchased service. The goal is not a larger document pile. It is a chain from physical and contractual resources to observed behavior under the failure that matters most.

What the two evidence grades actually mean

The network and logical-service evidence grade is Medium. That grade is supported by several independent forms of visibility. ZDNS appears in the 2026 ICANN evaluation material for Main, DNS, DNSSEC and Proxy services with IDN support. Its application and first-party pages describe registry and DNS functions. The location attachment names eight dependencies and identifies anycast and unicast associations. AS38345 presents a visible IPv4 and IPv6 routing surface. IANA delegations connect ZDNS to identifiable top-level domains, and selected authoritative addresses show a multi-origin pattern.

“Medium” is intentionally not “Strong.” The evaluation is a review of a submission, not continuous certification of every live deployment. The location rows lack a public function and address map. Route visibility does not disclose application health or physical diversity. Delegations do not disclose customer isolation or hardware. The evidence is real and mutually reinforcing, but it leaves consequential implementation details unmeasured.

The ZDNS-attributable physical-capacity and usable-failover-headroom evidence grade is Weak. No reviewed public source provides the installed or spare hardware by site. There is no attributable rack count, power allocation, network-port schedule, mitigation reserve or current utilization table. There is no largest-site share and no dated result showing that surviving locations carried the displaced load with margin. The available recovery descriptions do not provide the most recent achieved RTO/RPO.

“Weak” does not mean the service is necessarily weak. It means the public evidence is weak for that particular conclusion. ZDNS may possess substantial equipment and well-tested reserves that are not publicly disclosed. The responsible response to undisclosed evidence is a request for controlled proof, not an allegation that the assets do not exist.

The two grades must not be averaged. A visible global network cannot fill an empty equipment schedule. A 732-rack host certificate cannot be used to strengthen ZDNS’s attributable capacity. A daily escrow statement cannot raise the route-withdrawal result that was never published. Each form of evidence belongs to its own claim.

This separation is valuable for procurement because it identifies the next decision gate. A buyer does not need to relitigate whether ZDNS has a visible service. The buyer needs to verify the amount, independence and tested usability of the resources behind the relevant service. If ZDNS can provide the site matrix, inventory, load data and executed recovery records, the Weak grade can change. Until then, it should remain Weak.

The decision is not “trust or reject,” but “verify the missing layer”

ZDNS’s public footprint is substantial enough to deserve a serious assessment. The evidence supports a real registry and authoritative-DNS operation with globally visible routing, disclosed location dependencies, identifiable delegated domains and documented control intentions. It would be inaccurate to reduce that record to marketing alone.

It would be equally inaccurate to convert that visibility into an asset claim. None of the reviewed material lets an outsider book any portion of the 732-rack Beijing facility to ZDNS. None quantifies the company’s equipment at the other listed locations. None shows the spare capacity that remains after the largest site is removed. None supplies a complete, dated result set for route convergence, cross-site load absorption, database restoration, DNSSEC emergency handling, escrow validation and achieved RTO/RPO.

That leaves a clear procurement posture. Credit what is observable. Treat the network and logical-service layer as Medium evidence. Keep attributable physical capacity and usable failover headroom at Weak. Ask ZDNS to close the gap with scoped records rather than broad assurances. Match each record to the registry, hosted DNS or customer-premises surface being purchased.

The most revealing question is simple: show the last time the largest relevant site was made unavailable, where its work moved, how much margin remained, and whether the data and signing state were independently recoverable. A satisfactory answer would connect the eight-row geography, the routing design, the facility dependencies and the recovery controls into one measured operating story.

Until that story is available, ZDNS can reasonably be described as globally visible. It cannot, from public evidence alone, be assigned the host’s racks or credited with demonstrated failover headroom.