Summary

  • Digity, LLC is the recorded sponsoring organisation for .case and .radio, two TLDs transferred to the company through separate IANA processes; the public record establishes bounded registry responsibility rather than sovereign authority over the DNS.
  • Current root records expose different technical contacts and RDAP service paths for the two namespaces. That is evidence of distinct public control paths, not a complete private architecture or a reliability score.
  • Agreements, assignments, renewals, DNS/DNSSEC observations, RDAP objects, public registration surfaces, and protocol standards establish real capability and responsibility without proving longitudinal reliability or customer production outcomes.
  • Supervision, integration, maintenance, portability, and authorised exception response remain operating costs even when specialist providers and automation perform routine work.

Image note: The accompanying Creative Commons photograph shows generic server cabling at a Wikimedia Foundation data center. It does not depict Digity, LLC, its personnel, facilities, .case or .radio registry backends, CentralNic, CORE, customers, incidents, private architecture, measured reliability, or production outcomes.

Digity, LLC appears in the current BTW directory as a company object and in the IANA Root Zone Database as the sponsoring organisation for .case and .radio.[1][2][3] Both top-level domains reached Digity through recorded transfers rather than through an original delegation to the company. IANA published a transfer report for .case in May 2023 and a separate report for .radio in February 2026.[4][5] That history makes Digity a useful technology-company research subject because it exposes a hard operational question: how does one accountable organisation preserve accurate records and continuous service when it inherits two namespaces with different histories, public service paths, policy contexts, and technical contacts?

The public evidence establishes a real control surface.

It includes sponsoring-organisation records, authoritative DNS delegations, IPv4 and IPv6 glue, DNS Security Extensions material, WHOIS services, Registration Data Access Protocol endpoints, registry agreements, assignments, renewals, public registration interfaces, escrow duties, and emergency-continuity mechanisms.[2][3][6][7][8][9][10][11][12][13][14][15][16] It also includes standards that define how RDAP queries and responses behave and how validating resolvers process DNSSEC data.[17][18][19] The IANA RDAP bootstrap file provides the routing layer that tells clients where to send queries for each TLD.[20]

Those records do not disclose Digity's private architecture, staffing, vendor contracts, deployment topology, security controls, incident history, registration volume, or customer outcomes. The .case IANA record names CentralNic as its technical contact and points to a CentralNic RDAP base, while the .radio record names CORE Association as its technical contact and points to rdap.nic.radio.[2][3] These are visible role and endpoint differences. They are not proof of a complete backend design. A public service hostname is not a complete map of contractual or technical responsibility.

The analysis therefore keeps three layers separate:

  • Model or system capability: a protocol endpoint can answer a defined query, a delegation can publish name servers and DS data, a registry process can accept an authorised change, and an escrow process can preserve a defined data set.
  • Product reliability: those functions remain correct, reachable, secure, observable, and recoverable through maintenance, provider failure, staff change, bad input, and an operator transition.
  • Customer production outcome: a named registrar, registrant, broadcaster, application, or security team achieved a measured result attributable to the service.

The public record supports a bounded capability assessment and identifies reliability questions. It does not support a customer production outcome claim. A successful DNS or RDAP observation at one time is not a longitudinal benchmark, and a contractual obligation is not evidence that a target was met in every period. That distinction is central to evaluating a registry without inventing tests, customers, failures, or internal designs.

The main finding is that Digity's two-TLD portfolio concentrates accountability while leaving several execution paths visibly distinct. This can create useful separation, but it also creates supervision, integration, maintenance, and exception-handling costs. The relevant technology question is not whether one backend pattern is better than another. It is whether Digity can keep the authoritative record, running services, contractual responsibility, and recovery authority coherent across both namespaces as those elements change.

Identity and two separately transferred delegations

The company identity matters because root-zone change authority is tied to an exact organisation, not a loose brand. The BTW directory supplies the current company object used for this research.[1] IANA names Digity, LLC as the sponsoring organisation for both .case and .radio, but the two records show different addresses associated with the organisation and different technical contacts.[2][3] That variation is not itself an error. It is a reason to treat legal identity, current contact data, and change authority as operational state that must be reconciled.

IANA's transfer report for .case records Digity as the proposed manager and marks applicant matching, contact confirmations, technical conformance, and other processing as completed.[4] The corresponding report for .radio records the same categories of checks for a later transfer.[5] These reports establish that each request passed a defined transition gate. They do not show that every technical component moved, that every process remained unchanged, or that later operation met a particular reliability level.

The underlying assignment documents add a contractual layer. The .case assignment records the movement of agreement rights and obligations to Digity, and the .radio assignment performs the analogous function for that TLD.[10][11] An assignment is significant because it identifies the party responsible under the registry agreement. It should not be read as a diagram of software, infrastructure, staff, data migration, or provider allocation. Contractual responsibility can transfer while technical execution remains partly with specialist organisations, changes in stages, or follows different paths for different services.

The renewal documents show that the obligations continue beyond the initial assignment event.[12][13] Renewal is not merely a timestamp extension. It preserves a continuing relationship in which root-zone data, registration services, security obligations, data escrow, reporting, and continuity controls must stay aligned. The current ICANN agreement indexes provide the public inventory of agreement materials for each TLD.[6][7]

This is where the registry-as-recordkeeper principle is useful. Digity is the currently recorded registry operator responsible for these two delegations. That role is material, but bounded. Digity does not own the DNS root, become a sovereign over all uses of the labels, or erase the roles of ICANN, IANA, registrars, technical service providers, recursive resolvers, network operators, courts, and policy authorities. The operator's legitimacy in the technical system depends on accurate records, authorised change, standards-conformant running services, and continuity.

A transfer creates at least four linked inventories:

  1. Authority inventory: the legal entity, agreement, approved contacts, authenticated accounts, and people who may request or approve change.
  2. Namespace inventory: the TLD label, root delegation, glue, DS data, WHOIS and RDAP routing, reserved names, domain statuses, and registrar relationships.
  3. Dependency inventory: the providers, credentials, certificates, keys, networks, monitoring systems, data stores, escrow process, and support paths required to keep the namespace running.
  4. Evidence inventory: the records that let a reviewer reconstruct why a state is authoritative, when it changed, who approved it, and how the result was independently checked.

The public sources expose portions of the first two and contractual requirements around the third and fourth. They do not show Digity's private inventories. That is an evidence limit, not a basis for assuming either strong or weak controls.

The two transfers also arrived at different times and from different predecessor contexts. .case was originally delegated to another corporate operator before its transfer to Digity; .radio was originally associated with the European Broadcasting Union before its later transfer.[2][3][4][5] A transition plan cannot safely treat those histories as interchangeable. Policy commitments, registrar relationships, public expectations, service providers, retained data, and exception queues may differ even when the root-zone end state looks similar.

The practical control is a per-TLD transition record. It should identify which obligations and assets moved, which remained with a provider, which changed after transfer, and which evidence proves the current state. A shared corporate owner can standardise the form of that record. It should not erase the differences that matter.

Running DNS, DNSSEC, WHOIS, and RDAP control surface

The IANA pages list four authoritative name servers for each TLD: a, b, c, and d beneath the relevant nic domain, with IPv4 and IPv6 glue.[2][3] A bounded DNS observation found those four expected names for both .case and .radio, and DS records were observable for both at the capture time. These observations show that the selected public paths returned coherent delegation data then. They do not prove global reachability, independence among servers, continuous uptime, or a particular response-time target.

A root-zone listing is an authoritative record of delegation intent. It is not a physical topology. Four names do not necessarily mean four machines, sites, networks, or failure domains. Anycast can place many service instances behind one address, while several names can still depend on common control systems. It is not reasonable to infer a private architecture from the visible names, addresses, or contacts.

Running-code primacy does not mean ignoring the record. It means testing whether observable service continues to honour the record. A useful operating model compares:

  • the approved root-zone and registry record;
  • direct authoritative responses;
  • DNSSEC validation from independent paths;
  • IPv4 and IPv6 reachability;
  • route visibility and network diversity;
  • monitoring from outside the provider control plane;
  • registrar transaction behaviour;
  • RDAP discovery and response semantics;
  • customer symptoms, without assuming those symptoms locate the fault.

Each layer answers a different question. A correct root-zone page cannot prove that every authoritative instance is reachable. One successful recursive lookup cannot prove that every resolver sees the same state. A valid signature at one time cannot prove the next rollover is safe. An RDAP HTTP success cannot prove every object field is current.

DNSSEC adds a security-metadata lifecycle. RFC 4035 describes how validating resolvers authenticate DNS data and how failures can lead to insecure or bogus outcomes.[19] The parent DS record, child DNSKEY set, signatures, validity intervals, algorithms, and operational clocks must remain aligned. Automation can calculate tags, compare records, monitor expiry, and detect a mismatch. It can also repeat an incorrect intended state quickly if authority or inventory is wrong.

Safe DNSSEC operation therefore requires more than capable software. It needs key custody, explicit roles, a planned sequence, overlap, observation, rollback boundaries, and recovery access. A technically valid DS value can still be the wrong value for the intended key. A successful submission can still occur at the wrong time. A monitoring system can see failure while the only authorised responder is unreachable.

The WHOIS and RDAP paths expose a related but different control surface. IANA lists whois.nic.case and a CentralNic RDAP base for .case, while .radio uses whois.nic.radio and an RDAP base under nic.radio.[2][3] IANA's bootstrap data routes RDAP clients to the relevant registry service.[20] RFC 9082 defines query patterns and error paths; RFC 9083 defines JSON response structures, links, notices, statuses, events, entities, and error behaviour.[17][18]

At the bounded capture time, a query for nic.case returned an RDAP object with that identifier, and a query for nic.radio returned the corresponding .radio object. The services exposed different response details and status sets, as would be expected from separate objects and possibly separate operational paths. The observations establish that the two exact queries answered. They do not establish completeness, accuracy of every field, continuous availability, or equal behaviour across the two services.

Structured RDAP is a capability improvement over a presentation-oriented text response because clients can parse fields and follow links. Product reliability still depends on bootstrap accuracy, endpoint reachability, TLS, response semantics, update timing, rate controls, privacy treatment, event consistency, and useful errors. Customer production outcome would require evidence from a named user or workflow, with a baseline and measurement window. None is available here.

Registration data is not merely a directory. It is an operational record used by registrars, registrants, security teams, rights holders, researchers, and automated systems. Its useful properties include:

  • Uniqueness: a query resolves to the intended object rather than an ambiguous duplicate.
  • Accuracy: fields reflect authoritative state within a controlled update interval.
  • Provenance: a client can identify the service and authority behind a response.
  • Security metadata: statuses, events, notices, and links survive processing without silent loss.
  • Continuity: discovery and response remain available through maintenance and transition.
  • Privacy: disclosure limits are applied without corrupting object meaning.

The public protocols define how these properties may be represented. They do not prove Digity's private process for maintaining them.

Backend heterogeneity and integration boundaries

The visible .case and .radio records do not present one uniform provider chain. .case names CentralNic as the technical contact and uses a CentralNic RDAP URL. .radio names CORE Association as its technical contact and uses a different RDAP base.[2][3] The public evidence therefore supports a narrow statement: the two TLDs expose distinct technical responsibility and registration-data paths. It does not support a claim about full backend architecture, contract scope, exclusivity, capacity, or incident performance.

That visible heterogeneity matters because standardisation and separation have different benefits. A common corporate owner can use one risk vocabulary, approval model, evidence format, and continuity policy. Distinct service paths may reduce one kind of common-mode dependency. They also require the owner to preserve expertise, access, monitoring, and escalation across more than one operating context.

Integration starts at authority. The sponsoring organisation must be able to prove who is authorised to request changes for each TLD. The technical contact may perform work without owning the final approval. A provider may detect a fault without having permission to alter the root-zone record. Digity may hold contractual accountability while needing provider evidence before choosing a remediation. These separations are healthy only if the handoffs work under pressure.

Integration continues through data. Registrar transactions must create the intended registry state. That state must be reflected in WHOIS and RDAP responses, DNS publication, status codes, billing or eligibility controls, and escrow deposits as applicable. Different backends can implement the same protocol while differing in operational tooling, event timing, error detail, credential management, maintenance windows, and support escalation.

The .case public registration surface and the .radio site also imply different product contexts.[14][15] The .radio site describes a namespace aimed at the radio community and publishes eligibility and policy-oriented claims. The .case surface presents its own registration-facing material. Public marketing or policy copy defines intended use and customer-facing controls. It does not prove enforcement consistency, case volumes, registration success, abuse outcomes, or production reliability.

An operator with two distinct contexts needs a control model that preserves both common requirements and local differences. A practical design might include:

  • one corporate register of authority and contractual obligations;
  • a separate per-TLD map of provider roles, contacts, credentials, endpoints, and maintenance constraints;
  • common evidence requirements for high-consequence changes;
  • separate staging and rollback decisions where one TLD can be isolated;
  • outside monitoring that does not depend on either backend's own dashboard;
  • a normalised incident record that still retains provider-specific evidence;
  • tested paths for data export, credential recovery, and successor operation.

The existence of such controls cannot be inferred from the public sources. They are decision tests derived from the visible system.

Portability is the most concrete way to evaluate lock-in. Vendor use is not itself a defect. Specialist providers can supply protocol support, operational scale, and mature tooling. Lock-in risk appears when the accountable operator cannot recover authoritative data, establish change authority elsewhere, reproduce required services, or verify a transition independently.

A meaningful portability review asks what can be exported, in which format, with what freshness, under whose authority, and whether a different operating environment can consume it. It includes zone data, domain and contact records, statuses, registrar state, DNSSEC material or transition procedures, policy history, escrow references, support cases, monitoring expectations, and audit evidence. It also asks which knowledge exists only in staff memory or a provider-specific interface.

Transfer history makes this question practical rather than theoretical. .case and .radio have already changed sponsoring organisations.[4][5][10][11] The lesson is not that another transfer is planned. It is that namespaces are expected to outlive particular corporate and technical arrangements. Continuity depends on preserving the record and operating capability across that change.

Contract, escrow, and emergency continuity controls

The .case and .radio registry agreements create duties around registry services, registration data, data escrow, interoperability, continuity, and emergency transition.[8][9] The ICANN agreement indexes and renewal documents show the continuing contractual frame.[6][7][12][13] These documents establish obligations and fallback mechanisms. They do not prove an incident occurred or that every service level was achieved.

Data escrow addresses a difficult asymmetry. The day-to-day operator may hold the most current registry data, but a successor or emergency operator may need that data when normal access has failed. Escrow is useful only if deposits are complete, timely, correctly formatted, securely transferred, and recoverable under valid authority. A file that exists but cannot be decrypted, validated, or reconciled is not an operational recovery asset.

The Emergency Back-End Registry Operator programme describes a bounded mechanism intended to protect critical registry functions when an operator cannot provide them.[16] It is an outer safety boundary, not a replacement for routine continuity. Activation requires clear authority, usable data, current contacts, service transition, and communication. It may preserve critical functions without restoring every business process immediately.

For Digity, two transferred TLDs create a continuity question at several levels:

  1. Can each TLD be recovered independently if only one service path fails?
  2. Can shared corporate authority still act if a provider identity system is unavailable?
  3. Are escrow and export procedures compatible with the current implementation for each TLD?
  4. Can root-zone, DNSSEC, WHOIS, RDAP, registrar, and policy state be reconciled after recovery?
  5. Can an outside observer determine that the recovered state is authoritative?

The agreements provide a reason to ask these questions. They do not disclose the answers.

Continuity has a temporal dimension. A daily deposit might be adequate for one data class and too stale for another. DNS delegation, domain status, registrar transactions, abuse cases, contact records, and cryptographic material change at different rates. Recovery objectives should reflect the consequences of missing or stale state, not use one generic number.

Continuity also has a knowledge dimension. A valid backup cannot approve a root-zone change. An exported database does not explain why an exception was granted. A DNSSEC key without role and lifecycle evidence may be unusable or unsafe. A contact list does not help if the identities and authentication methods are stale. Durable operation requires data, authority, procedure, and tested access.

The featured photograph accompanying this article shows Wikimedia Foundation servers and is used only as generic cabling and maintenance context. It does not depict Digity or any registry system. The image is not evidence about Digity's facilities, vendors, reliability, or security.

Four recurring operating costs

The visible control surface generates four recurring costs that remain even when routine work is automated or delegated.

Supervision cost

Supervision cost connects a technically possible action to authorised intent. It includes role review, change approval, independent verification, access control, policy interpretation, incident command, and evidence retention. In a two-TLD portfolio, supervision must prevent a convenient shared procedure from applying the wrong assumptions to both namespaces.

The cost is not measured only by reviewer hours. It includes preserving enough expertise to challenge a green dashboard, recognise that a syntactically valid value belongs to the wrong TLD, and stop a change whose authority is unclear. It includes maintaining an outside observation path and a recovery identity that still works when the normal provider portal does not.

Integration cost

Integration cost sits between Digity, IANA, ICANN, registrars, technical contacts, backend services, escrow, monitoring, legal processes, and public users. Standards reduce format ambiguity, but they do not align credentials, clocks, maintenance windows, ownership, or escalation automatically.

The distinct .case and .radio contact and RDAP paths make this cost visible.[2][3] A common corporate status report may need evidence from two operating contexts. An incident classification may have to distinguish root delegation, authoritative DNS, DNSSEC, registrar transaction, RDAP, policy, and network causes before it reaches the correct owner.

Maintenance cost

Maintenance cost preserves capability. It covers software and dependency updates, certificate renewal, DNS and DNSSEC lifecycle, database care, monitoring changes, backup validation, escrow deposits, access review, contact updates, registrar compatibility, policy revision, and recovery tests.

Infrequent procedures can be especially costly because people and platforms change between executions. A rarely used account may expire. A runbook may describe an old service. A recovery key may exist without a usable approval path. A successful scheduled task may never have been tested through restoration.

Exception-handling cost

Exception-handling cost appears when the expected sequence does not hold. Examples include conflicting authority records, a partial DNSSEC rollover, one-family reachability, an RDAP object that is reachable but stale, a registrar transaction whose result is ambiguous, a privacy request that conflicts with a standard response, or a provider status that disagrees with outside observation.

These cases require context and restraint. Not every failed probe is an outage. Not every successful response is correct. Not every customer symptom belongs to the registry. The operator must preserve evidence, narrow scope, identify authority, and choose a response that does not make a bounded fault wider.

The four costs reinforce one another. Weak maintenance creates exceptions. Poor integration makes exceptions harder to locate. Weak supervision lets a mistaken change propagate. Slow exception handling extends impact and encourages contradictory action. A service can be inexpensive per routine transaction while remaining expensive to operate responsibly.

Failure-mode register

The public record supports a concrete failure-mode analysis without claiming that any of these events occurred at Digity.

1. Sponsoring-organisation identity drift

The legal entity, ICANN agreement, IANA sponsor record, directory object, and authenticated change account stop referring to the same organisation. A technically correct request can then fail because authority is ambiguous. Detection requires reconciliation across records; remediation requires an accountable owner, documentary evidence, and a controlled update sequence.

2. Administrative contact staleness

An email address, telephone number, postal address, or named role remains published after responsibility has changed. Routine service can continue while emergency change authority quietly degrades. A good control tests reachability and authority, not merely whether a field is non-empty.

3. Technical-contact ownership mismatch

A provider or association remains the technical contact after the scope of its work changes, or a new provider operates services without the correct escalation record. Digity may receive a report but be unable to route it to the party with diagnostic access. The remedy is a per-TLD responsibility map tied to current contracts and systems.

4. Transfer inventory omission

A transfer moves contractual responsibility but omits a credential, monitoring rule, policy exception, registrar dependency, or support history. The namespace may appear healthy until the missing item is needed. A signed handover checklist is weaker than a tested exercise that uses the transferred assets.

5. Root delegation mismatch

IANA's intended name-server or glue data differs from the operator's intended configuration or from running authoritative service. The cause could be an incomplete change, stale inventory, or an unauthorised request. Response should compare approved change evidence, direct authoritative answers, and root data before another update is attempted.

6. IPv4 and IPv6 reachability divergence

One address family reaches the authoritative service while the other fails or follows a materially different route. A monitor that tests only one family reports success. The operator needs independent dual-stack observation and a method to distinguish delegation, route, filtering, and server causes.

7. Correlated name-server failure

Four published names depend on a common control plane, software release, routing policy, credential, or upstream network. The root record looks diverse while one shared fault affects several paths. The public record cannot prove or disprove this topology; resilience testing must verify actual failure domains.

8. DNSSEC parent-child mismatch

The parent DS data and child DNSKEY set no longer form a valid chain. Validating resolvers can return a bogus result even while non-validating checks appear normal. Prevention requires staged rollover, overlap, independent validation, clock discipline, and explicit rollback conditions.

9. Signature-expiry blind spot

Zone signatures approach expiry without an effective alert, or an alert exists only inside the failing control plane. The service may remain apparently healthy until cached data ages out. Outside validation and alert-ownership tests reduce the risk.

10. Wrong-TLD automation

A common script or workflow applies .case data to .radio, or the reverse. Consistent automation then repeats a semantically incorrect action. Per-TLD identifiers, immutable review evidence, scoped credentials, and independent post-change checks are more valuable than a generic success message.

11. RDAP bootstrap drift

IANA bootstrap data points clients to a service that no longer represents the intended registry path, or a transition is only partly reflected across caches and clients.[20] Direct endpoint tests may pass while standards-based discovery fails. Both discovery and service behaviour need monitoring.

12. RDAP object staleness

An endpoint returns HTTP success and valid JSON but exposes an outdated status, event, link, or entity. Availability monitoring misses a semantic failure. Detection requires comparison with authoritative registry state and a controlled expectation for update timing.

13. RDAP error-model incompatibility

A client and server disagree on query form, status handling, notices, redirects, or error responses defined by RFC 9082 and RFC 9083.[17][18] Happy-path tests pass while investigation tools fail on an exception. Contract tests should include malformed, absent, unauthorised, and rate-limited cases without creating harmful traffic.

14. WHOIS and RDAP meaning divergence

The legacy WHOIS response and structured RDAP object describe the same domain differently enough to mislead users. The two protocols do not need identical presentation, but material status and authority should remain reconcilable. Privacy treatment can differ without making one output semantically false.

15. Registrar transaction ambiguity

A registrar times out after submitting a create, update, renew, transfer, or delete operation and cannot determine whether the registry committed it. Blind retry may duplicate work or conflict with current state. Idempotency, transaction evidence, and a clear reconciliation path are needed.

16. Public-policy enforcement gap

The .radio public surface describes eligibility and controls, but an operational case does not follow the stated path or lacks reachable ownership.[15] The presence of policy copy is capability evidence, not proof of consistent enforcement. Review needs case evidence, timelines, and lawful exception handling.

17. Escrow deposit unusability

A deposit is present but incomplete, stale, invalid, encrypted under unavailable authority, or incompatible with a recovery environment. A file count reports success while continuity fails. Validation and restoration exercises must test usable state rather than task completion.

18. Emergency-transition authority failure

A serious service problem exists, but the parties cannot establish who may activate an emergency mechanism, release data, change delegation, or communicate status.[16] Technical recovery capacity then sits idle behind an authority gap. Exercises should include approval and identity paths, not only data movement.

19. Provider control-plane outage

Public DNS continues answering from distributed instances while the portal, identity system, monitoring, or change API is unavailable. This is a partial continuity state, not full health. Digity needs outside observation, recovery access, and rules for deciding when inability to change becomes an incident.

20. Customer symptom misattribution

A website, mail system, or application fails and the registry is blamed before delegation, registrar status, authoritative DNS, resolver, route, certificate, hosting, and application layers are separated. The opposite error is also possible: a registry fault is dismissed as an application issue. A timestamped evidence ladder helps avoid both.

These failure modes are not a scorecard for Digity. They are a register derived from the publicly visible responsibilities. Their value is to turn vague resilience language into observable decision points.

Leadership decision tests and evidence limits

Technology leaders should evaluate Digity's control surface through evidence requests that preserve the boundary between accountability and private implementation.

First, ask for an exact responsibility map for each TLD. It should separate contractual accountability, root-zone authority, technical operation, DNSSEC custody, registrar support, RDAP and WHOIS operation, escrow, policy cases, incident communication, and independent verification. The .case and .radio public contacts show why a single generic provider label is insufficient.[2][3]

Second, ask how transfer evidence remains usable after the transition team has dispersed. The IANA reports show that applicant, contact, and technical-conformance gates completed.[4][5] A current operating review should show which controls preserve that result now: contact verification, access review, current dependency maps, tested export, and reconstructable change history.

Third, ask how intended state is compared with running state. The answer should include root records, direct authoritative DNS, DNSSEC validation, IPv4 and IPv6, RDAP discovery, response semantics, and outside observation. One dashboard should not be allowed to certify itself.

Fourth, ask how differences between the two service paths are controlled. Standardisation should cover evidence, approval, severity, and recovery principles. Provider-specific procedures should preserve the differences needed for safe operation. A common template is useful; a false assumption of identical backends is not.

Fifth, ask for continuity evidence rather than continuity language. Useful evidence includes validated escrow, restore results, recovery access, contact drills, DNSSEC recovery, export tests, and a scenario in which one TLD is isolated from the other. The EBERO framework provides an outer context, but routine recovery belongs to the operator and its providers.[16]

Sixth, ask for the basis of any reliability claim. Product reliability requires a defined service, metric, observation window, vantage points, exclusions, and failure handling. A bounded capture of correct DNS and RDAP objects is evidence of observable capability at that time, not an uptime result.

Seventh, ask for the basis of any customer claim. A customer production outcome needs an identified use case, baseline, time window, measurement method, attribution logic, and limitations. Public registration pages and TLD-purpose statements do not supply those elements.[14][15]

Eighth, ask whether portability is tested under realistic authority constraints. Exporting data while every normal system is available is useful but incomplete. A stronger exercise assumes that a provider account, staff role, or control plane is unavailable and tests whether Digity can still establish authority, retrieve usable state, and verify a successor path.

Ninth, ask how exceptions are prevented from becoming policy by accident. A one-off manual fix can create undocumented state that later appears authoritative. Exception records should capture evidence, authority, scope, expiry, and the change required to return to the normal path.

Finally, ask what is deliberately unknown. The public record does not reveal private topology, staffing, contracts, security design, incident response times, or customer results. A credible review should mark those fields unknown rather than fill them with inference. This makes the remaining evidence more useful, because readers can distinguish what the records establish from what only the operator could prove.

Conclusion

Digity, LLC's technology significance lies in becoming the accountable registry operator for two separately transferred top-level domains. The current IANA records, transfer reports, agreements, assignment and renewal documents, public registration surfaces, protocol standards, and bounded observations establish a real DNS, DNSSEC, WHOIS, RDAP, and continuity control surface.[2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20]

The evidence shows capability and responsibility. It does not reveal a private architecture, prove longitudinal product reliability, or establish a customer production outcome. The visible difference between the .case and .radio technical contacts and RDAP paths should be treated as an integration and continuity question, not as proof of either weakness or resilience.

Supervision keeps authorised intent attached to technical action. Integration reconciles organisations, protocols, and evidence. Maintenance preserves keys, data, software, contacts, and recovery access. Exception handling resolves the cases in which correct-looking layers disagree. Escrow and emergency transition supply an outer safety boundary, but they are useful only when data and authority remain usable.

The broader lesson is that a namespace survives corporate and technical change when its records stay accurate, its running services continue to honour those records, and an accountable operator can transfer or recover authority without inventing state. Digity's two transfer histories make that principle concrete: ownership of responsibility can move, but the operational continuity of the namespace cannot be allowed to disappear between contracts, providers, and systems.

Sources

[1] BTW Directory, "Digity, LLC": https://btw.media/en/directory/digity-llc

[2] IANA Root Zone Database, ".CASE": https://www.iana.org/domains/root/db/case.html

[3] IANA Root Zone Database, ".RADIO": https://www.iana.org/domains/root/db/radio.html

[4] IANA, "Transfer Report for case": https://www.iana.org/reports/tld-transfer/20230531-case

[5] IANA, "Transfer Report for radio": https://www.iana.org/reports/tld-transfer/20260225-radio

[6] ICANN, ".case Registry Agreement": https://www.icann.org/en/registry-agreements/details/case

[7] ICANN, ".radio Registry Agreement": https://www.icann.org/en/registry-agreements/details/radio

[8] ICANN, ".case Registry Agreement text": https://itp.cdn.icann.org/en/files/registry-agreements/case/case-agmt-html-03sep15-en.htm

[9] ICANN, ".radio Registry Agreement text": https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-agmt-html-21jul16-en.htm

[10] ICANN, ".case Assignment": https://itp.cdn.icann.org/en/files/registry-agreements/case/case-assign-pdf-08-07-2022-en.pdf

[11] ICANN, ".radio Assignment": https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-assign-pdf-05-01-2026-en.pdf

[12] ICANN, ".case Renewal": https://itp.cdn.icann.org/en/files/registry-agreements/case/case-renewal-1-11-06-2025-en.pdf

[13] ICANN, ".radio Renewal": https://itp.cdn.icann.org/en/files/registry-agreements/radio/radio-renewal-1-22-05-2026-en.pdf

[14] Digity, ".case registration services": https://www.digity.case/case

[15] dotRadio, ".radio public registry surface": https://www.nic.radio/

[16] ICANN, "Emergency Back-End Registry Operator": https://www.icann.org/en/contracted-parties/registry-operators/resources/emergency-back-end-registry-operator

[17] IETF, RFC 9082, "Registration Data Access Protocol Query Format": https://www.rfc-editor.org/rfc/rfc9082.txt

[18] IETF, RFC 9083, "JSON Responses for the Registration Data Access Protocol": https://www.rfc-editor.org/rfc/rfc9083.txt

[19] IETF, RFC 4035, "Protocol Modifications for DNS Security Extensions": https://www.rfc-editor.org/rfc/rfc4035.txt

[20] IANA, "RDAP Bootstrap Service Registry for Domain Name Space": https://data.iana.org/rdap/dns.json

[21] CentralNic RDAP, "nic.case": https://rdap.centralnic.com/case/domain/nic.case

[22] dotRadio RDAP, "nic.radio": https://rdap.nic.radio/domain/nic.radio

[23] Wikimedia Commons, "Wikimedia Foundation Servers 2015-88": https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Servers_2015-88.jpg