Summary

  • IANA identifies The Gap, Inc. as sponsoring organisation for the live .gap and .athleta top-level domains. Its records publish authoritative name-server, technical-contact, and RDAP information for both delegations.
  • ICANN identifies the company as registry operator under Brand Specification 13 agreements and records 2025 renewals for both live TLDs.
  • The public lifecycle record is not limited to successful delegation. The company requested termination of .oldnavy; ICANN determined that successor transition was unnecessary for that Brand TLD, and IANA now records it as revoked and absent from the root.
  • These records prove declared authority, contract state, delegation state, and a documented exit. They do not prove uptime, control effectiveness, independence of failure domains, recovery performance, registration volume, or a customer production outcome.
  • A defensible operating model separates capability, repeatable reliability, and accepted outcomes, then includes supervision, integration, maintenance, exception handling, supplier coordination, and retirement work in the cost denominator.

The Gap, Inc. is usually assessed as a retailer. The public DNS root exposes a narrower and more technically consequential role. The company is the sponsoring organisation for two delegated generic top-level domains, .gap and .athleta, and the named registry operator under corresponding ICANN agreements. These namespaces are not ordinary domain registrations purchased from a registrar. They are entries in the global DNS root with authoritative servers, registration-data services, contractual obligations, change procedures, and continuity responsibilities.

The company also supplies a rare public comparison between retention and exit. .gap and .athleta remain delegated. .oldnavy does not. ICANN's final determination records that The Gap, Inc. requested termination of the .oldnavy registry agreement. IANA's current record states that the TLD is not present in the root zone and records its revocation. This does not show that the TLD failed. It shows that a namespace has a lifecycle, that retirement requires formal action, and that continuity decisions extend beyond keeping servers online.

That difference is the most useful part of the evidence. A brand TLD can be technically capable, contractually active, rarely visible to consumers, or deliberately retired. Each state requires different evidence and different work. A delegation proves that the root points to named authoritative servers. A registry agreement proves that an operator accepted defined obligations. A renewal proves that the agreement continued. A termination record proves that a formal exit path was used. None of those documents by itself proves the reliability of every DNS answer, the correctness of every registry entity, or the business value of the namespace.

The engineering question is therefore not whether The Gap, Inc. "owns the internet" for its brands. It does not. The question is how declared authority, running DNS, registry data, supplier responsibilities, corporate governance, and lifecycle decisions remain aligned. The root and agreement records are ledgers. Running code and observed behavior determine whether services work. Accepted outcomes require defined users, measurement windows, and evidence that the result was useful.

What the public record establishes

IANA's delegation record for .gap names The Gap, Inc. as sponsoring organisation. It lists administrative and technical contacts, authoritative name servers and their addresses, a registration-services URL, an RDAP endpoint, a registration date, and the date on which the record was last updated. The .athleta record provides the same classes of information. These are externally observable facts that can be captured, compared, and reconciled over time.

The records also expose a division between organisational sponsorship and technical operation. The company is the sponsor, while the technical contact is a specialist registry infrastructure provider. This is evidence of a declared role split. It is not evidence of the exact commercial contract, internal staffing model, operational handoff, or failure-domain design. A responsible assessment records the named parties, then asks for current responsibility and validation evidence before drawing a stronger conclusion.

ICANN's agreement indexes identify The Gap, Inc. as operator for .gap and .athleta. Each is classified as a base, non-sponsored Brand Specification 13 registry agreement. ICANN also publishes renewal records dated in 2025. These documents establish that the contractual relationship is active and that the operator remains responsible for duties defined by the agreement and its specifications.

Registry duties matter because they connect policy to running infrastructure. The agreement framework addresses registry services, data escrow, reporting, registration data, continuity, security and stability obligations, service levels, and transition under specified conditions. A contract can require these functions without revealing whether a particular control passed on a particular day. Contract evidence and operational evidence must remain separate.

The .oldnavy record establishes another class of fact. ICANN's final determination says that The Gap, Inc. notified ICANN of its intent to terminate the registry agreement. The determination says ICANN assessed whether the operation should transition to a successor and concluded that transition was unnecessary for the Brand TLD. IANA records the domain as revoked and no longer present in the root zone. These facts show an authorised lifecycle decision. They do not show an outage, security event, customer impact, or economic motive.

IANA's root-zone resources provide the broader control context. The root database records delegations and technical data. Root-zone files are operational inputs used by DNS software. The registry record therefore has two dimensions. It is a public record of declared authority, and it feeds a running distributed system. Neither dimension is sovereign. The record can be correct while a downstream system is wrong; a server can answer while ownership, access, or lifecycle records have drifted.

The company's SEC filings and annual report add organisational context. The Gap, Inc. describes cybersecurity, digital operations, technology, suppliers, governance, and business continuity as material areas of risk and management attention. Those disclosures support questions about supervision and dependencies. They are not TLD-specific reliability evidence. They do not publish a denominator for DNS availability, RDAP correctness, change success, recovery time, or customer dependence on either namespace.

Together, the sources support a bounded conclusion. The company has a real namespace control surface, two live delegations, active registry agreements, and one completed Brand-TLD exit. The public record is strong on identity and lifecycle. It is weak on measured service behavior, private operating design, and customer outcomes. That is enough for a rigorous control analysis, but not for a product rating or performance benchmark.

Capability, repeatable reliability, and customer production outcome

Capability is the narrowest layer. The Gap, Inc. is named in authoritative records. The live TLDs are delegated. Public technical endpoints are listed. Registry agreements and renewals exist. These observations support statements about declared authority and available control surfaces. They do not require access to private systems.

Repeatable reliability asks whether that capability produces correct behavior over time and under change. For authoritative DNS, relevant evidence could include expected answers from independent network perspectives, DNSSEC validation where applicable, propagation after approved changes, monitoring coverage, alert ownership, and recovery exercises. For RDAP, useful evidence could include typed query responses, entity consistency, rate-limit handling, and escalation when published data differs from approved intent.

For registry operation, evidence could include access reviews, escrow confirmations, report reconciliation, controlled changes, and supplier procedures.

The public sources do not supply that full set. A delegation page listing several name servers does not prove geographic or control-plane independence. Different IP addresses do not prove separate facilities. A specialist technical contact does not prove concentration risk, and a corporate sponsor does not prove that daily operation is internal. An agreement renewal does not prove that every service target was met.

Customer production outcome is stricter again. It starts with a defined dependent service or user. The intended result might be correct resolution of an approved name, uninterrupted access to an authenticated brand service, successful certificate validation, or an accepted registry change. The result needs a measurement window, acceptance criteria, exclusions, and an owner.

A single successful DNS query is not a customer production outcome. A web page loading once is not a registry reliability result. An RDAP root responding with a request error can show that an endpoint exists, but it does not show that a typed entity query is correct. A company report describing a security program is not proof that a TLD control worked.

This separation changes management reporting. A capability view should list authoritative entities, owners, endpoints, agreements, access roles, and declared dependencies. A reliability view should list monitored behavior, controlled changes, recovery exercises, evidence freshness, and exception age. An outcome view should list important dependent services, accepted user results, unresolved defects, and business impact.

Combining the three layers creates reassuring but ambiguous statements. "The registry is operational" could mean that an agreement exists, that one endpoint answered, that monitoring was green, or that an important service met an accepted target. Each claim needs a different evidence class.

The .oldnavy lifecycle makes the distinction concrete. Capability once existed because the TLD was delegated and an agreement was active. The later termination was not necessarily a reliability failure. It was a governance and lifecycle outcome. The important evidence is that authority, contract termination, transition assessment, and root state converged. A future assessment could still ask whether dependent names, certificates, monitoring, documentation, and internal inventories were retired cleanly, but the public record does not answer those questions.

A manual ownership and validation workflow

Before automating brand-TLD governance, a company needs a manual workflow that named owners can execute and independent reviewers can understand. Automation should reduce repetition after decision rights and evidence classes are clear. It should not conceal uncertainty.

The first step is to identify authoritative entities. The inventory should include .gap, .athleta, the historical .oldnavy record, IANA entries, ICANN agreements, intended name-server sets, registration-data endpoints, relevant DNSSEC material, controlled change accounts, and important names or services that depend on the live namespaces. Each item needs a record owner and an operational owner.

The second step is to map authority. Who may request a registry or root-zone change? Who approves it? Who can authenticate to the registry supplier or portal? Who can accept a temporary degraded state? Who can invoke legal or contractual escalation? Who decides to retain, renew, or terminate a namespace? Authority should work during an incident or organisational change, not exist only in a policy.

The third step is to freeze intended state. Reviewers need a readable baseline for delegations, addresses, contacts, endpoints, status, certificates, monitoring, supplier responsibilities, and important dependent services. The baseline should distinguish externally authoritative data from internal intent. A difference between them is a reconciliation item, not automatically an outage.

The fourth step is to observe running state independently. Checks can query authoritative DNS, inspect published registration-data behavior, validate expected security metadata, and compare results from more than one network perspective where the test design requires it. The person or supplier executing a change should not be the only source confirming success.

The fifth step is to classify evidence. An ICANN agreement is contractual evidence. An IANA record is delegation evidence. A successful query is point-in-time operational evidence. A repeated synthetic check is reliability evidence within its stated boundaries. A defined business-service result is outcome evidence. Reviewers should not promote one class into another.

The sixth step is to rehearse recovery and exit. A qualified alternate should demonstrate access, locate the intended state, identify suppliers, prepare a bounded change, and independently validate a simulated or approved low-risk result. A separate retirement rehearsal can trace dependent names, certificates, monitoring, access, records, and communication duties without terminating anything. A tabletop is useful, but it should not be reported as an executed technical recovery.

The seventh step is to close exceptions. Every temporary workaround needs an owner, expiry, compensating control, and permanent repair. Examples include an emergency access grant, a delayed contact update, a monitoring exclusion, a supplier-side manual step, or an inconsistency between public and internal records. Repeated extension turns a temporary exception into an ungoverned design.

Once the manual workflow is stable, automation can fetch public records, normalise fields, compare them with approved baselines, run bounded queries, open reconciliation tasks, and preserve evidence. It should not automatically decide that a difference is safe, infer private architecture, or execute a high-impact change without an approved authority path.

Supervision cost

Supervision is the work required to keep technical action connected to accountable decisions. The inventory appears small: two live TLDs and one historical exit. The responsibility can still span brand, legal, security, infrastructure, resilience, supplier management, application ownership, and communications. Small inventories can be expensive when specialists must remain available for rare but consequential changes.

The supervision baseline includes assigning primary and alternate owners, reviewing access, approving changes, checking evidence, maintaining escalation contacts, and deciding whether an exception is acceptable. Rare changes increase the risk of stale knowledge. A procedure last used several years ago may reference departed staff, an obsolete portal, an expired credential, or a changed contract.

Supervision also includes claims discipline. Leaders need someone to challenge statements such as "the provider handles DNS," "the TLD is renewed," or "the namespace is resilient." Which provider handles which function? Who validates the provider? What does renewal prove? Resilient against which failure and for what period? A supervisor turns broad assurance into testable claims.

The .oldnavy exit adds a decision class that ordinary DNS operations may omit. Someone had to hold authority to request termination. The company and ICANN had to address transition. Internal owners would have needed to determine whether names, certificates, integrations, monitoring, or records still depended on the namespace. The public record proves the external lifecycle decision, not the internal completeness of that work.

Supervision cost should be measured in review time, specialist availability, unresolved questions, exception age, and decision latency. Counting meetings is not enough. The useful question is whether supervision produces current evidence and timely accepted decisions without encouraging unsafe shortcuts.

Governance can be lightweight when the evidence model is clear. A compact quarterly review can reconcile public records, owner assignments, access, supplier contacts, monitoring, open exceptions, and upcoming agreement dates. Event-driven reviews should follow reorganisations, supplier changes, acquisitions, major identity changes, or a decision to retire a namespace.

Integration cost

Brand-TLD operations intersect with DNS, certificates, identity, web delivery, email security, monitoring, incident management, legal rights, supplier systems, and business-service ownership. Integration cost arises at these boundaries.

A technically correct root delegation can still fail to support an application because a certificate, redirect, access policy, or monitoring rule is wrong. A registry-data service can be reachable while an internal inventory names an obsolete owner. A supplier can complete an approved change while an application team still depends on the old state. Integration work keeps these representations aligned.

The minimum integration map should identify producers and consumers of critical fields. IANA publishes delegation data. Registry infrastructure serves DNS and registration data. Internal systems store intended state. Monitoring observes selected behavior. Certificate and application teams consume names. Security and resilience processes consume alerts and evidence. Legal and brand teams govern rights and purpose. Every handoff needs an owner, format, timing expectation, and failure path.

Integration testing should focus on transitions. What happens when a contact changes, an access role is removed, a technical supplier changes, a certificate is renewed, a name is activated, an endpoint is replaced, or a namespace is retired? Static inventories miss failures that occur only during change.

The live and retired TLDs create a useful comparison. For .gap and .athleta, the integration objective is sustained alignment between external delegation, running services, internal intent, and dependent applications. For .oldnavy, the objective shifts to removal: dependencies should disappear, monitoring should be retired deliberately, credentials and contracts should be closed, and internal records should match the revoked root state.

The public record does not show whether The Gap, Inc. used either process successfully. It only provides the external states. A careful internal review would trace each state change through applications, certificates, monitoring, support, and records before reporting completion.

Integration cost can be estimated through the number of handoffs, manual reconciliations, incompatible data formats, duplicate inventories, delayed approvals, and defects discovered after change. A low registry fee can coexist with a high lifecycle cost when integration depends on undocumented knowledge.

Maintenance cost

Maintenance keeps a correct state correct. It includes access recertification, contact review, contract tracking, monitoring upkeep, certificate lifecycle, evidence retention, supplier review, recovery practice, and retirement decisions.

Access deserves particular attention. An account that worked during the last exercise may be unavailable when needed because an employee moved, authentication changed, a certificate expired, or a supplier changed its procedure. Break-glass credentials that are never tested create theoretical capability. Testing must be controlled so it does not weaken security or trigger an unauthorised change.

Contact data creates recurring work. Public contacts, internal owners, supplier contacts, and escalation routes can drift independently. A yearly review may be limited public evidence after an organisational change. Event-driven reconciliation complements a calendar.

Monitoring requires maintenance too. A check can remain green while testing the wrong endpoint, accepting an overly broad result, or running only from infrastructure that shares the same failure domain. Owners should review what each check proves, what it cannot see, and how a reviewer distinguishes absence of evidence from evidence of availability.

Registry agreement renewal is also maintenance. Renewal preserves the legal basis for operation, but it does not automatically refresh internal ownership, access, monitoring, or recovery evidence. A renewal event should trigger reconciliation rather than be treated as a permanent pass.

Evidence retention should make future review faster. Records should include approved intent, observed result, change identifier, reviewer, timestamp, limitations, and unresolved defects. Large collections of screenshots without context create storage, not assurance.

Retirement belongs inside maintenance. The .oldnavy record shows that a Brand TLD can leave the root through a formal process. Retirement planning should identify dependent names, certificates, security controls, links, monitoring, contracts, records, and communication duties. Stopping attention before formal retirement creates risk; continuing every control indefinitely after retirement wastes resources.

Exception-handling cost

Exceptions are inevitable when external records, supplier systems, corporate governance, and urgent business needs interact. The engineering question is whether exceptions remain bounded and visible.

An exception record should state the expected rule, observed condition, impact, temporary action, owner, approver, expiry, compensating control, validation method, and permanent repair. Without these fields, an exception becomes an oral agreement that cannot be audited or handed over.

Registry exceptions can be subtle. A contact update may be delayed because an external process requires validation. An alternate account may be unavailable while the primary remains active. Monitoring may suppress a check during planned maintenance. A supplier may require a manual step that is missing from internal workflow. A retirement task may remain open after the root state changes.

The response should reflect the evidence. A delayed record update is not necessarily an outage. It is a state difference with a defined risk and deadline. A failed observation from one vantage point is not proof of global failure. It is a trigger for bounded investigation. A missing recovery exercise is not proof that recovery would fail. It is a gap in assurance.

Exception handling becomes expensive when the same condition recurs. Recurrence can indicate a weak interface, unclear ownership, inaccessible tooling, limited public evidence capacity, or a control that does not match the operating model. Tracking only whether an exception is open hides this structural cost.

Leaders should therefore review exception age, recurrence, affected entities, compensating controls, and repair lead time. The objective is not zero exceptions. It is to prevent temporary deviations from becoming invisible permanent architecture.

Failure modes and response boundaries

The following failure modes are analytical scenarios, not claims that The Gap, Inc. has experienced them.

Authority drift

Public records, supplier records, and internal ownership can disagree. A former employee may remain a contact, a new team may lack access, or an internal inventory may reference a retired endpoint.

The first response is reconciliation. Identify which record is authoritative for which field, preserve timestamps, assign an owner, and validate any change independently. Do not treat the newest or most convenient record as correct without evidence.

Delegation or DNS configuration error

A change can introduce an incorrect server, address, DNSSEC value, or zone state. Some resolvers may continue using cached data, causing inconsistent observations.

The response requires an approved baseline, independent observations, awareness of caching, a rollback path, and supplier escalation. A single successful query should not close the event.

Registration-data inconsistency

RDAP or other published registry data can differ from expected state, reject malformed queries, apply rate limits, or expose an entity through a different path than a reviewer expects.

The response begins by validating the query design. A 400 response from an untyped service root is not evidence of service failure. The reviewer should issue a valid entity query, compare expected fields, record protocol boundaries, and escalate only after distinguishing client error from service behavior.

Supplier access failure

An urgent change can be blocked by expired credentials, changed authentication, unavailable staff, or an outdated escalation path.

The response should use tested alternate access, controlled break-glass procedures, and named escalation. Restoring access is only the first step; a reviewer must validate the resulting action and close any temporary privilege.

Monitoring blind spot

A check can report green while observing the wrong entity, one network path, stale cache, or a dependency that shares the incident.

The response is to restate the claim each check supports, add an independent perspective where justified, and preserve known blind spots. More alerts do not automatically improve evidence.

Agreement and operating-state mismatch

An agreement can be active while internal ownership is stale, or a termination can be externally complete while internal dependencies remain.

The response combines legal, technical, supplier, and application evidence. Contract state and running state should converge, but neither should be used as a substitute for the other.

Retirement incompleteness

A TLD can leave the root while links, certificates, monitoring, documentation, credentials, or internal references remain. Conversely, controls can continue consuming resources after every dependency has been removed.

The response requires a retirement inventory, dependency confirmation, evidence retention, and explicit control closure. The .oldnavy public record proves revocation, not the state of every private dependency.

Evidence failure

An operation may succeed technically while evidence is missing, ambiguous, or controlled by the same actor that performed the change.

The response is not to repeat a potentially risky change only to generate a screenshot. Reviewers should gather independent observations, preserve system records where available, state limitations, and improve evidence capture for the next action.

Unit economics and accepted network outcomes

The economic question is not simply what a registry provider charges. Total lifecycle cost includes staff, supervision, legal review, supplier management, access maintenance, monitoring, integration, assurance, recovery practice, exception repair, and retirement.

A useful numerator can be expressed as:

annual registry and DNS service cost + internal labour + supplier governance + monitoring and assurance + change and exception cost + allocated continuity and exit readiness

The denominator should be an accepted network outcome, not raw activity. Possible outcomes include an approved delegation change independently validated within target, an important name resolving correctly across the required perspectives, a registration-data entity matching approved state, an alternate operator completing a controlled exercise, or a retired namespace reaching an accepted closure state.

Each outcome requires explicit criteria. "DNS is up" is too broad. A stronger result names the entity, expected answer, perspectives, period, exclusions, owner, and acceptance decision. "The provider completed the ticket" is also limited public evidence if the internal state, external delegation, or dependent service remains wrong.

Cost per accepted outcome is:

total lifecycle cost / number of accepted outcomes in the measurement period

The denominator can be small because high-impact registry changes are rare. That does not make the metric useless. It makes assumptions visible. A year with no changes still incurs readiness, access, monitoring, evidence, and contract costs. Leaders can compare that cost with the value of retained capability and avoided loss without inventing a per-query price.

Quality-adjusted cost adds repair:

(total lifecycle cost + defect repair + exception carrying cost) / accepted outcomes

This prevents a low component price from looking efficient when manual supervision and recurring exceptions dominate. It also prevents an expensive specialist service from being dismissed if it materially reduces accepted-outcome cost and preserves evidence.

Retirement has its own denominator. An accepted retirement outcome could require external revocation, removal of dependent services, closure of access and contracts, updated records, retained evidence, and owner sign-off. The public .oldnavy evidence covers only part of that model. Internal evidence would be needed for the rest.

No public source provides the values needed to calculate these metrics for The Gap, Inc. The correct conclusion is not that cost is high or low. It is that component price, company scale, and agreement renewal are inadequate substitutes for lifecycle evidence.

An accepted-outcome register should also record rejected results. If an observation lacks a valid query, independent perspective, approved baseline, or named reviewer, excluding it from the denominator is more honest than counting activity as success. Recording the rejection reason helps teams improve the next measurement without turning an incomplete check into a negative performance claim. Over time, the ratio of accepted to rejected evidence can reveal whether the operating model is becoming easier to supervise, but it should never be presented as a public reliability score without a stable method and denominator.

Alternatives, portability, and concentration

The relevant alternatives are operating models, not claims about named suppliers.

One model keeps a specialist registry operator with strong internal supervision. It can reduce the need to build uncommon technical functions internally. Its risks include access dependency, knowledge concentration, and weak customer-side validation if the company treats the provider as the only source of truth.

A second model distributes functions across multiple suppliers or internal teams. It can increase independent control but also create integration overhead, fragmented escalation, and ambiguous ownership. More vendors do not guarantee independent failure domains.

A third model retains a namespace with minimal active use. This may preserve strategic identity or future options, but it still requires contract, delegation, security, access, monitoring, and retirement decisions. Low visible traffic does not eliminate control cost.

A fourth model is formal retirement. The .oldnavy record shows that retirement is available for a Brand TLD. It is not simply abandonment. Decision rights, ICANN process, root state, dependencies, evidence, and closure must align.

Portability should be tested even when migration is unlikely. The company should be able to export intended state, identify authoritative data, locate credentials, invoke escalation, reconstruct monitoring, and assign a qualified alternate. A provider-neutral baseline reduces dependency on one portal or person's memory.

A portability rehearsal can be smaller than a migration. An alternate owner can retrieve current records, reconstruct intended state, validate access, prepare a bounded change plan, and execute a simulation using approved evidence. Defects expose where continuity depends on proprietary format, unavailable credentials, or undocumented steps.

The economic question is whether the complete operating model produces accepted outcomes at a defensible lifecycle cost while preserving supervision and exit options. Concentration can be rational when controls and portability are demonstrated. Fragmentation can be costly when responsibility becomes ambiguous.

A 30, 60, and 90-day control plan

During the first 30 days, owners can freeze a readable baseline for .gap and .athleta, record the accepted closed state for .oldnavy, and map authority, suppliers, access, monitoring, certificates, and dependent services. Public IANA and ICANN records should be reconciled with internal intent. Every difference needs a classification, owner, and deadline.

The first month should also separate evidence classes. Delegation records, agreement records, point-in-time observations, repeated monitoring, recovery exercises, and business outcomes should not share one status label. Access checks should be controlled and should not make an unauthorised production change.

By day 60, primary and alternate owners can run bounded technical and process exercises. These may include independent DNS and typed RDAP observations, an alternate-access rehearsal, a trace of a recent or simulated change, a supplier escalation exercise, and a retirement dependency review. Each exercise should state whether it was observational, simulated, low-risk production activity, or actual incident response.

The second month is also the point to inspect integration. Teams can trace how DNS, certificates, monitoring, identity, incident management, legal authority, supplier portals, and application ownership exchange state. The output should be a short list of high-consequence handoffs, not an exhaustive private architecture diagram.

By day 90, leadership should be able to review a compact evidence pack: current authority and dependency maps, reconciled records, access status, executed exercise results, exception age, monitoring boundaries, supplier escalation evidence, agreement dates, retirement closure evidence, and a lifecycle cost baseline.

The review should keep capability, reliability, and outcome findings separate. Missing evidence remains visible rather than being scored as a pass or assumed to be a failure. The 90-day decision is not automatically to retain, consolidate, migrate, or retire. It is to decide which evidence is strong enough for the next operating choice and which defects need repair.

Evidence gaps and leadership questions

The public sources do not identify the complete operating model for .gap or .athleta. They do not show the current division of responsibility among The Gap, Inc., registry infrastructure providers, DNS operators, security teams, legal owners, and application teams. They do not show access-review results, monitoring coverage, recovery-test dates, unresolved exceptions, registration volume, or measured service outcomes.

They also do not establish why .oldnavy was terminated, what private dependencies existed, what the transition cost was, or whether any users were affected. The public documents establish an authorised lifecycle event, not a failure.

Leadership can request stronger evidence without exposing sensitive topology:

  1. A current authority-and-dependency map for the two live TLDs.
  2. A reconciled baseline of IANA, ICANN, supplier, and internal records.
  3. Evidence that primary and alternate operators can authenticate and execute a bounded procedure.
  4. Independent DNS and typed registration-data observations with stated limits.
  5. The latest change trace, including approval, execution, validation, and unresolved defects.
  6. Recovery and retirement exercises distinguished from tabletop discussion.
  7. Supplier escalation evidence and continuity responsibilities.
  8. Exception age, recurrence, ownership, and repair status.
  9. A list of important services and names depending on the live TLDs.
  10. A cost model based on accepted outcomes rather than component prices.

The answer should preserve uncertainty. A missing document is not proof of control failure. A successful query is not proof of permanent reliability. A revoked TLD is not proof of an incident. The purpose is to improve the next decision.

Public sources