Jolly Host's Seven-Registry Transfer: DNS Delegation, RDAP, DPML, and Continuity Costs

Summary

• ICANN's completed-assignment ledger records seven 2026 registry-agreement assignments to Jolly Host, LLC: .onl, .safety, .circle, .got, .jot, .aero, and the internationalised top-level domain represented in ASCII as .xn--5tzm5g and in Unicode as .网站.[1]
• IANA currently identifies Jolly Host as the sponsoring organisation for .circle, .got, .jot, .onl, and .safety. The public .aero and .网站 delegation pages retain different sponsoring-organisation names while showing Identity Digital technical contacts and RDAP service. That difference is a record state to reconcile, not evidence of an outage or wrongdoing.[2][3][4][5][6][7][8]
• ICANN's registry-agreement pages present Jolly Host as operator for all seven agreements. Assignment instruments establish a legal transition and assumption of obligations; they do not, by themselves, prove that every technical function moved in-house or that every public record changed simultaneously.[9][10][11][12][13][14][15][16][17][18][19]
• A company-specific .onl Registry Services Evaluation Policy request describes Jolly Host as an Identity Digital subsidiary registry operator and proposes adding Domains Protected Marks List service through the Identity Digital backend. The filing says the change should not affect DNS resolution, zone files, registry data, or response consistency. Those are scoped design assertions, not an independent production benchmark.[20][21][22]
• The transition creates recurring supervision, integration, maintenance, and exception-handling costs across legal authority, root-zone delegation, registry provisioning, registrar contracts, registration data, DNSSEC, sponsored-policy boundaries, Unicode identity, protective blocking, supplier dependencies, and recovery evidence.

Image note: The accompanying generated editorial image shows generic registry and network operations context. It does not depict Jolly Host, Identity Digital, ICANN, IANA, any assigned top-level domain, a real facility, actual architecture, measured reliability, an incident, or customer outcomes.

Jolly Host, LLC is an unusually instructive company object because its public technical identity cannot be inferred from its name. “Host” might suggest a conventional web-hosting provider, but the retained records establish a different and more consequential role. ICANN lists the company as the assignee of seven registry agreements in 2026, and current registry-agreement pages present it as the operator for those top-level domains.[1][9]-[15] That is the precise subject of this article: a legal company object attached to namespace records and obligations at the top level of the Domain Name System.

The seven agreements did not arrive from a single assignor or on one date. .onl moved from iRegistry GmbH with an effective date of 1 February 2026. .safety moved from Safety Registry Services, LLC on 1 April. .circle, .got, and .jot moved from Amazon Registry Services, Inc. on 8 April. .aero moved from SITA Information Networking Computing USA on 1 May. .网站 moved from Global Website TLD Asia Limited on 26 May.[1] The portfolio therefore combines several transition histories, a sponsored namespace, an internationalised namespace, and multiple base non-sponsored agreements.

The public record also distinguishes legal operator identity from technical service delivery. IANA pages for five of the names list Jolly Host as sponsoring organisation, while administrative and technical contacts point to Identity Digital and the published RDAP endpoint uses an Identity Digital service domain.[2]-[6] The .aero and .网站 pages show Identity Digital technical contacts and the same RDAP service but retain other sponsoring-organisation names at the observation time.[7][8] Jolly Host's .onl service request calls the company an Identity Digital subsidiary registry operator and says participating names are serviced by the Identity Digital backend.[21]

These facts support a control-surface analysis. They do not disclose beneficial ownership in a legally complete way, the private corporate structure, internal staffing, the production architecture, the allocation of every operational task, or audited service performance. They also do not establish that a visible difference among public records caused user impact. A registry transition has multiple state stores and authorities; the engineering task is to keep them attributable and reconciled.

The distinction between authority, running code, and outcomes is essential:

1. Authority records identify the agreement holder, effective dates, permitted services, contractual duties, and policy boundaries.
2. Running records and interfaces include root-zone delegation, authoritative nameservers, DNSSEC material, RDAP and WHOIS endpoints, registry provisioning, and registrar-facing systems.
3. Production outcomes include sustained correctness, incident frequency, recovery time, registrar experience, registrant impact, and commercial results.

The source set is strong for the first layer and provides bounded observations for the second. It does not provide a longitudinal dataset for the third. A responsible assessment can therefore explain the operating burden and foreseeable failure modes without manufacturing an uptime figure, a benchmark, a customer case, or an internal architecture.

Seven assignments, one portfolio, several transition paths

ICANN describes a registry-agreement assignment as a transfer of the agreement between two entities.[1] That definition is narrower than an acquisition narrative and more useful for technical accountability. It identifies a contractual object, an assignor, an assignee, and an effective date. Each assigned agreement carries its own history, amendments, approved services, notices, and namespace-specific constraints.

The portfolio matters because common infrastructure does not make the seven names operationally identical. .circle, .got, and .jot share an assignor and effective date, and their IANA pages show a similar six-nameserver pattern with Identity Digital contacts and RDAP.[2][3][4] .onl has a different history and a current company-specific request to add DPML.[5][20][21][22] .safety came from another assignor and its IANA transfer record was updated later in the year.[6] .aero is sponsored, which adds a community and policy role that cannot be reduced to the base non-sponsored model.[7][14] .网站 is an internationalised top-level domain whose Unicode and ASCII identities must remain bound to the same object.[8][15]

An assignment instrument is important because it records who assumes the agreement. The retained instruments for .circle, .onl, .aero, and .网站 provide transaction-specific evidence rather than relying only on a summary table.[16][17][18][19] Yet a signed document is not a systems migration report. It cannot prove when credentials were rotated, which services remained on an existing backend, whether monitoring ownership changed, how runbooks were updated, or when each public directory reflected the new operator.

That gap is normal enough to design for. A transition register should separate:

• contractual effective date;
• operational handover milestones;
• registry-system account and credential changes;
• registrar notices and contract changes;
• root-zone change requests and completion;
• WHOIS and RDAP identity updates;
• DNSSEC key and signer responsibility;
• data-escrow and continuity contacts;
• security, abuse, and emergency escalation ownership;
• public website and policy-document updates;
• verification from independent public interfaces.

If these fields are collapsed into a single “transfer complete” flag, teams lose the ability to explain partial state. The contract can be effective while a public directory still shows an earlier sponsor. The backend can continue without a platform migration while legal accountability changes. A registrar can be able to provision names while a notice page is stale. Each condition calls for a different owner and repair path.

The portfolio structure also changes supervision cost. One transfer can be reviewed as a single object. Seven transfers require both per-TLD checks and portfolio-level checks. A shared backend configuration may be applied across several names, but an incorrect assumption about .aero sponsorship or .网站 representation can still create a namespace-specific failure. Reuse reduces repetitive implementation; it does not eliminate the need to bind every action to the correct agreement and top-level domain.

Registry operator is a recordkeeping role, not sovereignty

A top-level-domain registry maintains an authoritative database of registered names and supports the technical and administrative interfaces around it. That role is powerful because incorrect registry state can affect delegation, lifecycle, and registration data. It is not unlimited authority over Internet users, content, applications, or all disputes associated with a name.

The public agreement pages define Jolly Host through an operator relationship to named top-level domains.[9]-[15] The IANA pages identify sponsoring organisations, technical contacts, nameservers, and registration-data services.[2]-[8] These are records in a layered system. ICANN maintains the agreement framework. IANA coordinates root-zone delegation records. The registry operates or arranges registry services. Registrars connect registrants to the registry. DNS operators serve delegated zones. Registrants control uses within contractual and policy boundaries. Other providers operate hosting, certificates, mail, applications, and content.

This layered view prevents two opposite errors. The first is understating the registry's responsibility. A registry must protect identifiers, transaction integrity, delegation state, registration-data services, security metadata, and continuity. Calling it “only a database” ignores the operational consequences of the database. The second error is overstating its authority. A registry record does not make the operator a general regulator of speech, commerce, or online conduct.

Jolly Host's legal name creates an additional classification hazard. The retained evidence does not support treating the company as the web host for domains under its top-level domains. The company object should be evaluated as a registry operator attached to specific agreements. Identity Digital contacts and backend references show an important technical-service relationship, but they do not convert every registrant, registrar, or hosted service into a Jolly Host customer.

The practical control is exact object binding. A consequential action should identify:

• the legal entity named in the applicable agreement;
• the exact top-level domain, including ASCII and Unicode forms where relevant;
• the registrar, registrant, domain, or protected label affected;
• the policy or agreement provision authorising the action;
• the technical system that will execute it;
• the person or function accountable for verification;
• the evidence that the resulting public state matches the approved change.

Authority should be no broader than the record supporting it. A transfer instrument can authorise an agreement transition. It does not authorise arbitrary changes to registered names. A DPML amendment can permit a protective blocking service. It does not establish that every trademark claim is valid. A root-zone record can identify a delegation state. It does not prove who owns every server or controls every underlying network.

Contract state and root-zone state are different ledgers

The most useful public contrast in the Jolly Host record is between ICANN's contract pages and IANA's delegation pages. ICANN's completed-assignment ledger lists all seven agreements as assigned to Jolly Host, and the corresponding agreement pages present Jolly Host as operator.[1][9]-[15] IANA lists Jolly Host as sponsoring organisation for .circle, .got, .jot, .onl, and .safety.[2]-[6] At the observation time, the .aero page names SITA as sponsoring organisation, and the .网站 page names Global Website TLD Asia Limited.[7][8]

This article does not infer the cause of that difference. Public systems can have different update workflows, review requirements, effective dates, or publication schedules. A contract assignment may be complete before a root-zone management change is submitted or displayed. A sponsored TLD may preserve a sponsorship relationship distinct from the registry agreement holder. A page can also lag or reflect a role whose meaning differs from “operator.” Without the relevant change case and authority record, a stronger claim would be speculation.

The difference still demonstrates why reconciliation matters. A transition controller should not ask only whether “the company changed.” It should compare exact fields across independent ledgers:

Layer	Example record	What it can establish	What it cannot establish alone
Contract	ICANN agreement and assignment pages	Named agreement operator, instrument, effective date, amendments	Current DNS behavior, credential state, backend ownership, reliability
Root delegation	IANA delegation page and root-zone data	Published sponsor or manager, nameservers, service endpoints, update time	Complete contract history, private topology, continuous correctness
Registry service	EPP, RDAP, WHOIS, policy, registrar interfaces	Bounded current behavior and declared rules	Long-term availability, all client outcomes
Supplier relationship	Technical contacts and backend references	Publicly declared operational dependency	Full allocation of tasks, internal controls, exit readiness
Outcome	Defined measurements and incident evidence	Reliability and user impact within a method and time range	Universal performance outside the measured scope

Reconciliation needs a tolerance model. Some differences are expected during a controlled transition. Others are errors. The record should identify which fields must change before the effective date, which can change after it, the maximum acceptable delay, the owner of each change, and the test that closes it. Without that model, teams either treat every difference as an emergency or allow stale records indefinitely.

The running-code principle gives public behavior priority when assessing what resolvers and clients actually encounter. If the root delegates to a set of nameservers, that delegation governs DNS resolution regardless of a contract-page label. If an RDAP bootstrap points clients to a service, the endpoint's responses matter operationally. But running behavior does not erase legal accountability. The operator must still be able to show who authorised the state and why it is consistent with the agreement.

Shared backend: continuity benefit and dependency concentration

The IANA records repeatedly identify Identity Digital administrative or technical contacts and publish an Identity Digital RDAP service.[2]-[8] Jolly Host's .onl request says that participating top-level domains are serviced by the Identity Digital backend and describes Jolly Host as an Identity Digital subsidiary registry operator.[21] These statements support a shared-service model. They do not disclose its complete architecture.

A shared registry backend can reduce migration risk. If an agreement changes hands within an organisational group or service relationship while the technical platform remains stable, there may be no need to replace every nameserver, EPP endpoint, RDAP service, deployment path, or monitoring system at once. Continuity can preserve registrar integration and reduce the number of simultaneous changes.

The same design concentrates dependencies. A backend defect, configuration error, credential problem, deployment fault, or control-plane incident can affect multiple top-level domains. Shared contacts can create ambiguity about whether an issue belongs to the legal operator, the platform provider, or another affiliate. A transition that appears simple because the infrastructure stays put can still fail if accountability, data access, escalation, or exit rights are unclear.

The supervision model should therefore treat legal accountability and technical execution as separate fields. For each registry function, record:

• accountable agreement operator;
• technical service provider;
• system of record;
• write authority;
• approval authority;
• monitoring owner;
• incident commander;
• data-retention and evidence owner;
• recovery dependency;
• substitute service or exit path;
• verification performed by the operator rather than solely by the supplier.

Outsourcing does not transfer the need to understand the control surface. The operator does not need to reproduce every implementation detail, but it needs enough evidence to approve changes, investigate exceptions, verify public state, meet agreement duties, and manage a supplier transition. A contract clause without technical verification is incomplete. A monitoring dashboard without authority mapping is also incomplete.

Shared infrastructure complicates measurement. Six nameservers are not six independent failure domains merely because they have different labels. Several endpoints can share networks, software, deployment controls, credentials, or operations staff. Conversely, a common service domain does not prove all components share one failure mode. Physical and administrative diversity require evidence beyond endpoint counting.

The retained sources provide no audited topology, availability report, incident history, recovery test, or supplier service-level result. A serious article must leave those values unknown. The public record supports questions for due diligence:

1. Which registry functions are provided by Identity Digital for each assigned agreement?
2. Which credentials and change approvals are controlled by Jolly Host?
3. How does Jolly Host independently verify DNS, RDAP, WHOIS, escrow, and registrar-facing state?
4. Which dependencies are common across the seven names?
5. What evidence proves restoration can preserve object identity and recent transactions?
6. What is the bounded path if the shared provider relationship changes?

These are control requirements, not allegations that a control is absent.

DNS delegation and the cost of exact state

The IANA pages expose a concrete part of the running layer: authoritative nameserver names, IPv4 and IPv6 addresses, contacts, and registration-data endpoints.[2]-[8] For .circle, .got, .jot, and .safety, the visible nameserver pattern uses several v0n* and v2n* hosts with both address families. .onl, .aero, and .网站 show different host-name patterns.[2]-[8] That variation is enough to require per-object verification.

A delegation change can fail in several ways:

• the approved nameserver set differs from the submitted set;
• glue addresses are missing, stale, or attached to the wrong host;
• IPv4 and IPv6 paths behave differently;
• some authoritative servers serve a different zone version;
• DNSSEC material at the parent does not match the child;
• monitoring checks recursive caches rather than authoritative state;
• an operator validates the human-readable name but changes the wrong ASCII object;
• a supplier updates its platform while the root-zone request remains pending;
• rollback instructions identify servers but not the corresponding security state.

The correct model separates intended, recorded, and observed state. Intended state comes from the authorised change. Recorded state comes from registry and root-zone records. Observed state comes from protocol queries against the authoritative path. An operation closes only when the three align within an explicit tolerance.

Caching makes timing important. A correct root-zone change does not appear everywhere instantly, and an obsolete path can continue answering from caches. Evidence should record observation time, vantage point, resolver behavior, and whether the query reached authoritative servers. “It resolves” is not enough. The answer could come from a cache, omit DNSSEC validation, or represent only one address family.

Automation can perform comparisons, but it needs exact identifiers and semantic checks. A successful DNS response code does not prove the expected zone was served. A monitoring system should verify the top-level domain, authoritative server identity, expected SOA properties, DNSSEC chain where applicable, and consistency across endpoints. Negative tests should confirm that nonexistent names and malformed requests receive expected treatment.

The source pages do not provide longitudinal DNS measurements for Jolly Host. This article does not claim availability, latency, anycast coverage, query capacity, or failover performance. It identifies the state that a registry transition must supervise and the tests that would produce defensible evidence.

RDAP, WHOIS, and semantic correctness

The IANA pages publish RDAP endpoints for the assigned namespaces, and some also publish WHOIS service information.[2]-[8] These services expose registration data under policy and access constraints. They are not interchangeable with DNS. DNS answers whether a name resolves through the delegation path; RDAP and WHOIS answer questions about registry objects and events.

Transition risk appears when identity and event history are not preserved. An endpoint can return HTTP success while serving the wrong object, stale registrar information, an incorrect status, or event dates with unclear provenance. A service can be reachable but omit data required by the applicable profile. A client can follow an outdated bootstrap record. Public and authenticated views can differ by design.

Semantic monitoring should verify:

• exact queried object and top-level domain;
• response conformance and content type;
• authoritative service identity;
• registrar and status fields expected for a controlled test object;
• event ordering and timestamps;
• nameserver references;
• secure delegation data where present;
• redaction and access behavior required by policy;
• expected not-found and malformed-query responses;
• consistency with authoritative registry state.

Shared RDAP service can simplify client behavior across several names, but it increases the need for routing tests. The service must select the correct namespace and object. A configuration error that maps a TLD to the wrong policy or data store can produce plausible but incorrect output. Transport-only monitoring may miss it.

WHOIS introduces additional maintenance cost because clients, output formats, rate controls, and legacy expectations differ from RDAP. If both services remain published, operators need to define which fields should agree, which differences are policy driven, and which service is authoritative for a given question. A mismatch is not automatically a failure, but it needs an explanation.

No retained source measures Jolly Host's RDAP or WHOIS reliability or data quality across time. The published endpoints establish a service surface. They do not establish customer satisfaction, response-time distributions, abuse resistance, or correction outcomes.

DPML: declared capability, product reliability, and production results

Jolly Host's .onl RSEP request creates a useful example of how to separate three evidence categories. The request proposes adding Domains Protected Marks List service to the .onl agreement. It describes a subscription that can block exact or variant labels from general availability across participating top-level domains serviced by the Identity Digital backend.[21] ICANN's RSEP ledger shows the request as approved, and the .onl agreement inventory contains an amendment associated with the service.[20][22]

At the capability layer, the filing describes what the service is intended to do. A qualifying label can be removed from the general-availability pool across participating namespaces. A rights holder or another eligible party may later need an override or unblock path. The filing ties the service to approved-services language and reserved-name provisions.[21]

At the product-reliability layer, the filing says the service has been operated by Identity Digital since 2013 and is tested through an automated quality-assurance suite for system deployments.[21] That is a relevant company statement. It is not an independently audited reliability result. The source does not publish test cases, coverage, failure rates, false-block rates, rollback results, or incident data.

At the production-outcome layer, the filing does not provide adoption counts, customer retention, prevented abuse, missed infringements, registrar support burden, dispute volume, or economic impact. It says the primary market is the corporate registrar channel and states that the proposed addition should have no effect on competition, registration prices, registration data, or DNS behavior.[21] Those are scoped assertions made in a regulatory request, not universal observed outcomes.

The service also relocates work rather than eliminating it. A block can reduce repetitive registration activity, but it creates supervision and exception paths:

• validating eligibility and protected marks;
• generating exact and variant labels;
• applying the correct TLD participation set;
• preventing an overbroad block;
• allowing another legitimate rights holder to register;
• handling misspellings and variant disputes;
• synchronising terms and renewals;
• notifying registrars;
• preserving audit evidence;
• reversing an incorrect or expired control;
• verifying that DNS and existing registrations remain unaffected.

A control that blocks registration is consequential even if it does not change DNS for existing domains. False positives can prevent legitimate registration. False negatives can leave an expected label available. An override can be incorrectly authorised. A portfolio update can include the wrong top-level domain. A subscription can expire without the expected state change.

The request says the service should not affect DNS resolution, zone files, domain lifecycle, registry-data storage, response time, consistency, or coherence.[21] A production verification plan would translate those assertions into measurable checks before and after activation. It would compare zone and registration-data state, run positive and negative label tests, verify registrar behavior, test override authority, and confirm rollback. The public filing does not publish those results.

Registrar integration and contract change

Registry transitions and new registry services both reach registrars. The public ICANN mailing-list record includes .onl registrar-agreement amendment notices and an approval notification associated with Jolly Host.[23] That evidence shows a registrar-channel change surface; it does not reveal every registrar's implementation or production experience.

Registrar integration has at least four layers:

1. Contract and notice. Registrars need the applicable terms, effective date, and scope.
2. Protocol behavior. EPP commands, extensions, error codes, and object states must match the documented service.
3. Operational readiness. Credentials, test environments, support contacts, monitoring, and reconciliation must be current.
4. Customer workflow. Registrar interfaces must explain blocks, overrides, renewals, and exceptions accurately.

A registry can deploy a correct backend change while a registrar still mishandles it. A registrar can implement a correct interface against stale terms. A support team can understand the policy while automated clients retry an uncertain transaction incorrectly. End-to-end readiness therefore cannot be inferred from one layer.

Uncertain write outcomes are a recurring failure mode. If a client submits an EPP command and loses the response, blind retry can duplicate or conflict with the first operation. The safer path is to preserve a transaction identifier, query authoritative object state, compare it with intended state, and retry only when reconciliation supports it. The same principle applies to protective blocks and overrides.

Change windows should identify backward compatibility and fail-closed behavior. If a registrar does not recognise a new service state, should it reject the request, display a bounded explanation, or route it for review? Silent fallback can create inconsistent customer expectations. An unbounded error message can expose internal details without helping recovery.

The cost of documentation is part of production reliability. Terms, protocol documentation, test cases, support procedures, and monitoring expectations should refer to the same version and effective date. A service is not operationally mature merely because the central code accepts a command.

The .aero sponsored-policy boundary

.aero differs from the other six agreements because ICANN presents it as a sponsored top-level domain.[14] A sponsored namespace has a defined community and delegated policy responsibilities. The 2026 assignment record names Jolly Host as assignee of the agreement, while the IANA page observed for this article still names SITA as sponsoring organisation and shows Identity Digital technical contacts.[1][7][18]

Those records must not be simplified into a claim that one party “owns” the aviation namespace. The relevant roles can include agreement operator, sponsor, policy authority, technical backend, registrar, registrant, and root-zone coordinator. A change in one role does not necessarily erase the others.

Sponsored eligibility creates additional exception work. A generic registration workflow asks whether a label is available and whether the registrant meets baseline terms. A sponsored workflow can also require evidence that a registrant belongs to the defined community or qualifies for a category. That introduces policy interpretation, validation, appeals, renewals, and transitions when eligibility changes.

Automation can check structured evidence and enforce clear rules. It cannot make ambiguous policy questions disappear. If a record is incomplete, the system needs a bounded hold state rather than silently accepting or permanently rejecting it. Reviewers need the exact rule version, evidence supplied, decision, authority, and route for correction.

The sponsored boundary also matters during recovery. Restoring domain objects without restoring eligibility evidence, policy versions, or exception decisions can produce a technically valid but institutionally incomplete registry. Backup testing should include relationships and provenance, not only labels and status codes.

The retained sources do not establish .aero registration volume, policy outcomes, dispute frequency, or transition impact. They establish a distinct agreement type and a multi-role public record that requires careful reconciliation.

The .网站 IDN boundary

The seventh assigned agreement is represented by the ASCII label .xn--5tzm5g and the Unicode label .网站, meaning “website.”[8][15][19] Both representations refer to the same top-level-domain object, but software, logs, user interfaces, policies, and staff can handle them differently.

Identity errors are foreseeable:

• a ticket uses the Unicode form while an API expects ASCII;
• a log stores one form and a monitoring rule searches for the other;
• a copied string contains an unexpected code-point sequence;
• a report treats the translation “website” as a different object;
• a change is applied to a visually similar but distinct label;
• a dashboard displays Unicode without preserving the wire representation;
• an agreement page and a root-zone record are compared using inconsistent normalisation.

Every durable record should preserve the exact ASCII label, the Unicode form, the conversion method, and the canonical internal identifier. Human-readable presentation should not replace protocol identity. A transition checklist that says only “website TLD” is unsafe because the phrase can refer to the English concept rather than the delegated object.

IDN operations also involve policy and registration-data representation. Registrars need tested input rules. RDAP and WHOIS outputs need predictable identity. DNS tooling needs wire-safe names. Security reviews need to distinguish legitimate internationalisation from visually deceptive labels. These concerns do not justify treating all IDNs as risky; they justify exact engineering.

The observed ICANN contract page presents Jolly Host as operator, while the IANA page names Global Website TLD Asia Limited as sponsoring organisation and identifies Identity Digital technical contacts.[8][15] This is a particularly clear example of why legal, delegation, and technical-service records should be compared without forcing them into one simplistic owner field.

No retained source establishes IDN adoption, user experience, abuse rates, conversion-error frequency, or customer outcomes for this registry. Those require defined datasets and methods.

DNSSEC and security metadata through a transition

DNSSEC makes registry transitions more sensitive because parent security metadata must remain aligned with child signing state. The IANA delegation pages expose nameserver information and the broader root-zone context, but the retained records do not reveal private key custody, signing architecture, rollover procedures, or incident history.[2]-[8]

A transition must identify who controls:

• key-signing and zone-signing operations;
• DS submission authority;
• change approval;
• emergency rollover;
• monitoring from validating resolvers;
• recovery material and access;
• audit evidence;
• supplier escalation.

Changing legal operator identity does not necessarily require changing DNSSEC keys. Changing the technical backend might. Either decision needs an explicit record. Keeping keys can reduce simultaneous change but may preserve dependencies on prior access or procedures. Rotating keys can improve separation but creates timing and rollback risk.

The safe sequence depends on the actual design, which is not public here. General controls include dual observation of parent and child state, staged rollovers, independent validation, explicit hold times, rollback conditions, and preservation of exact key identifiers and digest material. Private keys should never appear in ordinary operational evidence.

A successful validating query proves a bounded path at one time. It does not prove continuous validation or safe recovery. Monitoring should distinguish unsigned answers, validation failures, stale data, transport errors, and authoritative inconsistency. It should also verify both address families where published.

Security metadata illustrates the difference between redundancy and independence. Multiple authoritative servers can all serve a broken signature set. Several monitors can share the same resolver or network. A reliable control requires diverse observations and an expected-state model, not simply more green indicators.

Data continuity, escrow, and recovery evidence

Registry continuity is not limited to keeping DNS online. The registry must preserve object identity, lifecycle state, registrar relationships, registration data, nameserver data, security metadata, approved services, policy provenance, and transaction history sufficiently to operate and recover within its obligations.

An agreement assignment changes who is accountable for that continuity. The assignment instruments show assumption of contractual relationships for named agreements.[16]-[19] They do not show the data-migration method or recovery test. If the same backend continues, a bulk data migration may not occur, but access, authority, escrow, and recovery ownership still need review.

Backups are not proof of recovery. A backup can be complete at the storage layer and unusable at the registry layer. It can omit recent transactions, use identifiers that no longer match public records, depend on unavailable keys, or restore into software that interprets policy differently. Recovery evidence should demonstrate:

1. exact object counts and identifiers within a bounded test set;
2. referential integrity among domains, contacts, registrars, hosts, and status events;
3. consistency of DNS and registration-data outputs after restoration;
4. preservation of security metadata and policy provenance;
5. reconciliation of transactions after the recovery point;
6. controlled re-entry to writes;
7. independent verification against public delegation and service records.

Portfolio recovery needs per-TLD boundaries. A common platform can restore several registries, but policy, agreement, IDN, sponsored, and service configurations differ. A restore that applies one namespace's configuration to another can produce syntactically valid but semantically wrong behavior.

Continuity also includes people and suppliers. Credentials, escalation contacts, legal authority, and decision rights must survive staff or corporate changes. A runbook that depends on an unavailable individual is not a recovery plan. A supplier that can restore infrastructure but cannot authorise a root-zone change cannot close the incident alone.

The public sources do not prove Jolly Host's backup schedule, escrow status, recovery-point objective, recovery-time objective, or test results. The defensible conclusion is narrower: the assigned agreements and shared service relationship create concrete continuity obligations whose evidence must span legal and running layers.

Supervision, integration, maintenance, and exception cost

The seven-registry portfolio produces four recurring cost categories.

Supervision cost covers authority and evidence. Staff must know which entity, agreement, top-level domain, service, and supplier is involved. High-impact changes need approval, separation of duties, and verification. Sponsored-policy and IDN cases require additional context. Automated blocking services require eligibility and override controls.

Integration cost covers boundaries among ICANN records, IANA delegation, registry systems, registrars, RDAP and WHOIS, DNS and DNSSEC, policy documents, and supplier interfaces. A field that is correct in one system can be stale in another. Integration work includes mapping identifiers, versions, errors, contacts, and effective dates.

Maintenance cost grows with time. Credentials expire. contacts change. agreements gain amendments. policy and service configurations evolve. certificates rotate. DNSSEC keys roll. registrars enter and leave. monitoring expectations change. Public records need review. A stable backend reduces some migration work but does not stop lifecycle drift.

Exception-handling cost covers cases that do not fit the routine path: uncertain writes, mismatched public records, incorrect label blocks, legitimate override requests, IDN representation confusion, sponsored-eligibility disputes, stale registration data, supplier incidents, broken DNSSEC, failed registrar transitions, and recovery divergence.

Automation can reduce repetitive comparison and validation. It also relocates work into rule design, expected-state maintenance, access control, monitoring, and exception review. The relevant question is not whether a task became automatic. It is whether total work and risk fell after adding the supervision required to trust the automation.

A useful cost register records volume and effort only when measured. It should not invent them. Teams can track number of transitions, mismatches, manual reviews, uncertain transactions, rollback events, and time to reconcile. Without a method and time range, a numerical claim is decoration.

The current source set provides no such internal measurements for Jolly Host. It supports a qualitative cost model and a test plan, not a quantified efficiency claim.

Failure-mode register

The following are foreseeable scenarios derived from the documented control surface. They are not claims that Jolly Host experienced these failures.

Wrong legal entity. A change is authorised using an assignor or affiliate record after the agreement effective date. Control: bind authority to the exact agreement, instrument, entity identifier, and effective time.

Contract-root mismatch. An agreement page and delegation page display different parties with no recorded explanation. Control: classify role meanings, identify expected timing, assign a reconciliation owner, and preserve the change case.

Wrong top-level domain. A portfolio-wide action includes an unintended namespace. Control: exact allowlists, per-TLD review, dry comparison, and post-change protocol verification.

Shared-backend overreach. A common configuration is assumed valid for a sponsored or IDN namespace. Control: explicit exception profiles and namespace-specific negative tests.

Uncertain provisioning result. A registrar loses the response to a write. Control: transaction evidence, authoritative state query, idempotent design, and bounded retry.

RDAP false health. The endpoint returns success for the wrong object or stale state. Control: semantic assertions, event comparison, and expected-error tests.

WHOIS/RDAP divergence. Services show inconsistent identity or lifecycle information. Control: documented field mappings, policy-aware comparison, and correction ownership.

DNS delegation error. Nameserver or glue records differ from the approved state. Control: intended-recorded-observed comparison across IPv4 and IPv6.

DNSSEC chain break. Parent and child security material no longer align. Control: staged change, independent validation, hold times, and tested rollback.

DPML false positive. A legitimate label is blocked without applicable authority. Control: eligibility evidence, exact rule version, override path, and reversible state.

DPML false negative. A protected label remains available because the participation set or variant logic is wrong. Control: positive and negative test corpus, TLD mapping checks, and renewal monitoring.

IDN object confusion. Unicode display and ASCII wire identity diverge in records or tools. Control: preserve both forms and a canonical identifier.

Sponsored-policy loss. Recovery restores domain state but not eligibility evidence or policy decisions. Control: include provenance and relationships in recovery tests.

Credential drift. Former staff or suppliers retain access, or required certificates expire. Control: ownership inventory, rotation, revocation, expiry monitoring, and transition review.

Shared dependency failure. Several TLDs are affected by one platform or control-plane fault. Control: dependency mapping, blast-radius tests, staged deployment, and bounded rollback.

Recovery divergence. Restored internal state does not match current public delegation or recent transactions. Control: transaction reconciliation and independent public-state verification before resuming writes.

Each scenario needs an owner, detection signal, evidence requirement, decision authority, remediation path, and closure test. A checklist with no accountable owner is not a control. An alert with no expected-state model is noise.

A practical review framework

For Jolly Host and dependent parties, the public evidence supports a disciplined review framework.

First, preserve exact identity. Use the company entity, agreement, TLD, ASCII and Unicode label where relevant, registrar, domain, service, and transaction identifiers. Do not infer technical role from the company name.

Second, separate ledgers. Contract, root-zone, registry-system, registrar, and supplier records answer different questions. Compare them without forcing them into one owner field.

Third, separate capability from reliability and outcomes. Agreement and RSEP documents establish authorised or declared capability. Protocol observations establish bounded current behavior. Reliability and customer outcomes require longitudinal evidence.

Fourth, map accountable and executing parties. A shared backend can provide continuity, but the agreement operator remains responsible for knowing who can approve, write, monitor, recover, and verify.

Fifth, treat transitions as state machines. Record milestones and incomplete fields rather than one completion flag. Define acceptable timing and escalation for differences.

Sixth, test meaning, not only reachability. DNS, RDAP, WHOIS, EPP, blocking, and recovery checks should verify the correct object, state, policy, and security relationship.

Seventh, preserve special cases. .aero sponsorship and .网站 internationalisation are first-class control dimensions, not labels to normalise away.

Eighth, design exception paths before deployment. Uncertain writes, record mismatches, override requests, eligibility disputes, key problems, and supplier failures will not be solved by the routine path.

Ninth, make high-impact actions reversible where possible. Protective blocks, configuration changes, and transition steps need bounded rollback and post-action verification.

Tenth, report uncertainty honestly. The absence of a public incident is not an uptime measurement. A successful request is not a customer outcome. A shared service reference is not a complete architecture.

Conclusion

Jolly Host's public record shows a real Internet control surface. ICANN records seven registry-agreement assignments to the company in 2026, covering base non-sponsored names, a sponsored namespace, and an internationalised namespace.[1][9]-[19] IANA records expose current delegation, nameserver, contact, WHOIS, and RDAP state, including differences in displayed sponsoring organisation for .aero and .网站 at the observation time.[2]-[8]

The .onl DPML request adds a company-specific service layer. It describes a protective blocking capability delivered through the Identity Digital backend, gives scoped security and stability assertions, and identifies the corporate registrar channel.[20][21][22] It does not provide independent reliability results or customer outcomes.

The engineering burden lies in keeping authority and running behavior aligned without pretending they are the same thing. That requires exact identifiers, per-TLD transition records, shared-backend dependency mapping, semantic DNS and registration-data tests, registrar change control, DNSSEC lifecycle discipline, sponsored-policy preservation, Unicode identity controls, bounded protective-block overrides, recovery evidence, and explicit exception ownership.

Public records establish the operator and control surface. They do not establish private architecture, audited uptime, incident rate, recovery performance, registration volume, revenue, adoption, or customer success. Those claims remain outside the evidence.

The featured image is generated generic infrastructure context only. It does not depict Jolly Host, Identity Digital, ICANN, IANA, any assigned top-level domain, a real facility, actual architecture, measured reliability, an incident, or customer outcomes.

Sources

1. ICANN: Completed Registry Agreement Assignments
2. IANA: Delegation Record for .CIRCLE
3. IANA: Delegation Record for .GOT
4. IANA: Delegation Record for .JOT
5. IANA: Delegation Record for .ONL
6. IANA: Delegation Record for .SAFETY
7. IANA: Delegation Record for .AERO
8. IANA: Delegation Record for .网站
9. ICANN: .circle Registry Agreement
10. ICANN: .got Registry Agreement
11. ICANN: .jot Registry Agreement
12. ICANN: .onl Registry Agreement
13. ICANN: .safety Registry Agreement
14. ICANN: .aero TLD Sponsorship Agreement
15. ICANN: .网站 Registry Agreement
16. ICANN: .circle Assignment and Assumption Agreement
17. ICANN: .onl Assignment and Assumption Agreement
18. ICANN: .aero Assignment and Assumption Agreement
19. ICANN: .网站 Assignment and Assumption Agreement
20. ICANN: Registry Services Evaluation Policy Process and Submitted Requests
21. ICANN: Jolly Host .onl DPML RSEP Request
22. ICANN: .onl DPML Registry Agreement Amendment
23. ICANN Public Registrar Agreement Notices