top-level domain
Enable an AI agent to recognise a top-level domain, assess its delegation and operational state, and determine which naming or administrative actions are supported and authorised.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex
Purpose and description
Enable an AI agent to recognise a top-level domain, assess its delegation and operational state, and determine which naming or administrative actions are supported and authorised.
It can be Identify a TLD from a domain name using an explicit root context and verified label representation.; Verify delegation and compare published administrative records with observed DNS behaviour.; Evaluate a proposed descendant registration against the TLD's hierarchy and eligibility rules.; Assess TLD DNS availability, DNSSEC validation and application acceptance using bounded observations.; Prepare and, where authorised, submit delegation, nameserver, DS-record or operator-change requests.; Track transition or retirement conditions and identify dependent namespaces requiring follow-up..
Distinguishing features
Its domain node is immediately below the DNS root in the recorded namespace; example.com is below a TLD, while com is a TLD. [RFC 9499](https://www.rfc-editor.org/rfc/rfc9499.html)
A public suffix can contain multiple labels, such as co.uk; top-level status depends on root-relative position rather than the registration boundary. [RFC 9499](https://www.rfc-editor.org/rfc/rfc9499.html)
A claim of current public-root delegation must be supported by root-delegation evidence, rather than the string merely appearing at the end of a name. [IANA Root Zone Database](https://www.iana.org/domains/root/db)
The TLD is a namespace domain; its registry operator is a related organisation whose identity can change. [IANA Root Zone Management](https://www.iana.org/domains/root)
The TLD domain includes its descendants, whereas its authoritative DNS zone stops at delegated zone boundaries. [RFC 9499](https://www.rfc-editor.org/rfc/rfc9499.html)
Scope
+ Canonical TLD label, internationalised representations and root context
+ Root delegation status and authoritative service relationships
+ TLD manager, technical operator and applicable administrative authority
+ Registration hierarchy, eligibility and namespace restrictions
+ TLD-level DNS health, DNSSEC condition and application compatibility
+ Delegation changes, operator transitions and retirement
- Individual descendant domain registrations, ownership and renewal histories
- Websites, email services and content hosted under descendant domains
- Registry and registrar organisations beyond their roles for this TLD
- DNS server infrastructure inventories and implementation details
- Root-zone governance beyond its decisions affecting this TLD
- Browser cookie and site-boundary rules beyond their relationship to this TLD
Characteristics
- Canonical label
- Canonical DNS label; Unicode and ASCII-compatible representations where applicable Supports consistent identification without treating display variants as separate TLDs.
- Root context
- Identified public, private or alternative DNS root Prevents identical labels in different namespaces from being conflated.
- Administrative classification
- Source-attested classification and scheme, such as country-code, generic or infrastructure; unknown Directs the agent to the applicable administrative and lifecycle procedures.
- Root delegation state
- Present, absent, conflicting evidence or unknown, with observation time Separates observed delegation from proposals, historical records and administrative intent.
- Lifecycle stage
- Proposed, approved awaiting delegation, operating, transitioning, retiring, retired or unknown, with evidence Determines whether provisioning or change requests are appropriate.
- Responsible parties
- TLD manager, registry service provider and change-authorising parties, each with effective dates Identifies responsibility and authority without assuming one organisation performs every role.
- Registration boundary and eligibility
- Permitted registration levels, eligible applicants, reserved branches and applicable policy version Determines whether and where a proposed descendant name can be registered.
- Authoritative query success
- Percentage of successful authoritative queries, with sample size, query types, vantage points and time window Provides bounded evidence of TLD DNS availability.
- DNSSEC validation condition
- Secure, insecure, bogus or indeterminate, with trust anchor, queried data and observation time Distinguishes authenticated operation, unsigned delegation and validation failures.
- Application acceptance
- Acceptance rate across a named test set of applications and TLD representations, with test date Reveals whether technically valid names are rejected by relevant user-facing systems.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 12 layers · 12 findings · 24 questions.
TLD identity Establish which root-level domain is being modelled and how its label is represented.
A suffix string alone cannot establish namespace identity or public delegation.
Root-relative identity
Locate the domain directly beneath a specified DNS root.
Root and label
Record the canonical label and root context needed to identify this TLD.
- What canonical label and DNS root jointly identify this top-level domain? definition
- What evidence establishes its position directly beneath that root, and is it currently delegated there? provenance
Label representations
Separate equivalent encodings from distinct labels and related variants.
Encoding and variants
Record usable label forms and the evidence for equivalence or variant relationships.
- Which ASCII and Unicode forms represent this same TLD label, and under which conversion rules? definition
- Which similar or variant labels are separate TLDs, reserved labels or blocked labels rather than equivalent representations? boundary
Delegation and authority Connect the root delegation to the parties and procedures responsible for this TLD.
An agent must establish both delegation evidence and authority before proposing administrative changes.
Root delegation evidence
Record dated evidence of the TLD's presence and referral data in its root.
Published delegation
Establish the observed root delegation and reconcile it with administrative records.
- Which dated root-zone observations establish the TLD's delegation, nameservers and any associated glue or DS records? provenance
- Do the delegation records and the responsible registry's published information agree, and which differences remain unresolved? measurement
Management mandate
Identify accountable parties and the specific authority governing TLD changes.
Manager and change rights
Distinguish the recognised TLD manager, technical provider and authorised change requesters.
- Who is recognised as the TLD manager, who supplies registry and DNS services, and what dated records establish those roles? provenance
- Which TLD-specific procedure and authorisations are required to change its delegation or responsible manager? action
Registration namespace Describe how this TLD partitions its descendants and permits new registrations.
Top-level delegation does not establish where registration is possible or who may register.
Registration hierarchy
Identify registration levels and branches administered under different rules.
Registrable boundaries
Record where applicants can obtain names and which branches have separate policies.
- Are registrations available directly beneath this TLD, beneath designated second-level branches, or through both arrangements? definition
- Which descendant branches have separate registration authorities, and how do those boundaries relate to relevant public-suffix rules? boundary
Registration admissibility
Capture the rules that make a proposed applicant and label eligible.
Applicant and label rules
Establish applicable eligibility, reservation and internationalised-label constraints.
- Which current policies govern applicant eligibility, reserved names, supported scripts and variant treatment for the proposed registration branch? provenance
- Given an applicant and proposed label, which checks and registration channel are required before a registration request is admissible? action
Authoritative DNS condition Assess whether the delegated TLD is served coherently and validates as expected.
Published delegation alone does not establish usable or correctly authenticated DNS service.
Authoritative service
Measure the behaviour of the TLD's delegated authoritative service.
Reachability and consistency
Record query results with enough context to distinguish persistent faults from bounded observations.
- Across which times, network vantage points, transports and address families do the delegated servers return appropriate authoritative responses? measurement
- Do parent referrals, apex nameserver records and observed zone versions reveal persistent inconsistency or expected propagation? measurement
Delegation authentication
Assess the DNSSEC chain between the selected root and TLD zone.
DNSSEC chain condition
Record validation outcomes and the evidence needed for safe key or DS changes.
- Using which trust anchor and observation time do the parent DS records, TLD DNSKEY records and signed responses validate or fail? measurement
- What verified rollover stage, timing constraints and authorisations govern the next DNSKEY or parent DS change? action
Resolution and application boundaries Determine where names under this TLD resolve and are accepted by relevant applications.
A TLD may have different practical usability across resolver contexts and application implementations.
Resolution context
Separate public-root behaviour from local overrides, filtering and conflicting namespaces.
Context-dependent results
Record resolution differences without interpreting every local failure as a TLD outage.
- Does the same fully qualified name produce different results through the public root, private resolvers or alternative roots? measurement
- Which observed differences arise from local naming, filtering or caching rather than the TLD's authoritative service? boundary
Application acceptance
Test whether relevant software handles this TLD and its label representations correctly.
TLD recognition in applications
Identify TLD-specific rejection, parsing and display problems in a defined application set.
- Which tested applications accept valid domain names or email addresses under this TLD, using each applicable label representation? measurement
- What evidence distinguishes a TLD-recognition or encoding defect from a failure of the particular descendant service? boundary
TLD transition and retirement Track changes to the TLD's operational mandate, service provision and continued delegation.
TLD changes can affect many descendant namespaces and require explicit continuity conditions.
Operator and service transition
Distinguish changes in managerial responsibility from changes in technical service provision.
Transition readiness
Record the authorised transition and evidence that namespace service can continue.
- Is the proposed change a transfer of TLD management, a technical-provider migration or a delegation-data update, and what establishes its effective date? definition
- Which continuity checks, DNSSEC coordination steps and recovery arrangements must be satisfied before this transition proceeds? action
Retirement and removal
Capture the grounds, stages and consequences of ending the TLD's operation.
Retirement obligations
Establish the applicable retirement decision and distinguish administrative milestones from observed removal.
- What authoritative decision or policy establishes retirement, registration restrictions and any planned root-removal date? provenance
- Which descendant namespaces and service dependencies require notification, migration or continued support before delegation can end? action
What the second pass must settle
- Does the registry intend this entry to include TLDs in private and alternative DNS roots, or only the public DNS root?
- Should proposed, reserved and special-use root-level labels be represented as lifecycle cases here or linked to neighbouring naming-designation models?
- Which authoritative sources and precedence rules should reconcile administrative records, live root observations and operator statements when they disagree?
- Which per-TLD rules govern internationalised variants, and which relationships imply coordinated operation rather than identity?
- What observation windows and evidence thresholds should classify TLD-wide degradation, application incompatibility and readiness for transition or retirement?