← Back to catalogue
Research draft

.us

vr.tr.us · INF.MED

Enable an AI agent to recognise .us as a governed DNS namespace, assess its operational and administrative state, and determine which registration, delegation or remediation actions are permitted.

Thing Registry Information and virtual systems

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 + Grok

Purpose and description

Enable an AI agent to recognise .us as a governed DNS namespace, assess its operational and administrative state, and determine which registration, delegation or remediation actions are permitted.

The Internet country-code top-level domain delegated in the DNS root for the United States (ISO 3166-1 alpha-2 US), operated as a restricted ccTLD whose registrants must satisfy a documented United States nexus, and which still exposes the RFC 1480 locality-and-function hierarchy under two-letter state labels in parallel with second-level names.

It can be Recognise .us names and classify their namespace branch before selecting a registration route; Assess a proposed registration against applicable nexus, reservation and branch-access requirements; Identify the authority and evidence needed for a .us delegation or policy change; Compare dated DNS observations with the published .us delegation to investigate namespace-level faults; Prepare an authorised registration, transfer or remediation request with unresolved prerequisites made explicit; Route nexus complaints, rights disputes and abuse reports through the applicable .us process.

Distinguishing features

Confirm that the referent is the root-level DNS label us, classified by IANA as a country-code top-level domain, rather than the country code in another identification system. [IANA delegation record](https://www.iana.org/domains/root/db/us.html)

Distinguish the namespace .us from a particular registered name ending in .us; a registrant's control of one name does not confer authority over the namespace.

Determine whether a name falls under direct registration or a locality-based hierarchy; historical .us arrangements explicitly used geographic structure. [RFC 1386](https://datatracker.ietf.org/doc/rfc1386/)

Check the .us-specific nexus and reserved-name policies before treating a syntactically valid name as registrable. [Registry policies](https://www.about.us/policies)

Do not infer government ownership, official endorsement or hosting location merely from the .us suffix; establish those properties through linked evidence.

Scope

+ The .us root delegation and the authorities responsible for its administration

+ Direct registrations, locality-based branches and specially governed portions of .us

+ Applicable nexus, naming, reservation and registration-data requirements

+ Namespace-level DNS operation and delegation integrity

+ Policy applicability, enforcement routes and conditions for authorised actions

- The United States as a country, jurisdiction or political institution

- Individual .us domain registrations and their complete ownership or renewal histories

- Websites, email services and content hosted under .us

- Registrar businesses and their commercial account-management systems

- DNS protocols and resolver implementations as general technologies

- Trademark rights and legal proceedings beyond their recorded effects on .us decisions

Characteristics

Canonical namespace identity
DNS label us; presentation .us; country-code top-level domain Fixes the referent and prevents confusion with a country, website or individual registration.
Delegated administrative authority
Dated links to the registry manager, oversight authority and delegation evidence Identifies who can authorise namespace-level changes.
Namespace branch
Direct-registration branch; locality-based branch; specially governed branch; unresolved Selects the relevant registration route and policy context.
Branch registration availability
Open; restricted; closed to new registrations; suspended; unknown, with effective date Separates continued existence of names from permission to create new ones.
Applicable nexus requirement
Versioned policy and recognised eligibility categories, linked to the applicable branch Allows an agent to assess eligibility without assuming that all applicants qualify.
Name reservation classification
Unreserved; government-reserved; other reserved; prohibited; unresolved Prevents an availability result from being mistaken for permission to register.
Authoritative DNS response success
Percentage of successful queries, with query type, vantage points and observation interval Supports a bounded assessment of .us DNS availability.
DNSSEC validation condition
Secure; insecure; bogus; indeterminate, with validation evidence and observation time Distinguishes authenticated resolution from reachability alone.
Applicable remedy
Issue type linked to policy, authorised recipient, evidence requirements and permitted outcome Routes disputes or operational faults to an authority able to act.

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 · 11 layers · 18 findings · 28 questions.

.us identity and authority Establishes which namespace is being modelled and who holds authority over it.

An agent must distinguish control of .us from control of a name within it.

Root namespace identity

Anchors the registry thing to the DNS root.

Canonical .us referent

Record the canonical label, classification and evidence connecting vr.tr.us to the root delegation.

  1. What registry or delegation evidence establishes that vr.tr.us denotes the .us country-code top-level domain? definition
  2. Does the observed identifier denote .us itself, a descendant name or a non-DNS use of US? boundary

.us authority chain

Separates registry operation, oversight and root-delegation authority.

Dated authority mandates

Record responsible organisations, the evidence for their roles and the dates over which those roles apply.

  1. Which current delegation record and governing instruments establish the operator and oversight roles for .us? provenance
  2. Whose authorisation is required for the proposed registry-policy or root-delegation change? action
.us namespace branches Distinguishes direct registrations from locality-based and specially governed branches.

Label depth alone cannot establish the registration boundary or applicable manager within .us.

Registration boundaries

Locates the administrative boundary relevant to a candidate name.

Branch and manager resolution

Record branch classification and the responsible manager without treating every descendant as independently registrable.

  1. Is the candidate in the direct-registration namespace, a state or locality hierarchy, or another specially governed branch? boundary
  2. Which current source identifies the registration boundary and manager for that branch? provenance

Branch access and legacy

Separates historical branch structure from present admission rules.

Branch lifecycle status

Record whether a branch accepts new names and what operations remain available for existing names, including the status of kids.us.

  1. What dated evidence establishes the present status of this locality-based or specially governed branch? provenance
  2. Which creation, renewal, transfer or delegation operations remain permitted for this branch? action
.us registration admissibility Captures the conditions under which an applicant and proposed name qualify.

A free label is insufficient when .us nexus, reservation or branch-specific requirements apply.

US nexus qualification

Connects eligibility categories to evidence and verification requirements.

Nexus evidence and review

Record the applicable nexus policy, claimed eligibility category and evidence needed to resolve uncertainty.

  1. Which nexus category under the applicable policy could qualify this applicant? definition
  2. What evidence and verification steps are required before the agent can treat that qualification as established? action

Label and registration-data constraints

Combines name-level admission checks with applicable registration-data obligations.

Registration preconditions

Record syntax, reservation, applicant restrictions and data-policy prerequisites for the selected registration route.

  1. Does the proposed label meet current syntax rules and avoid applicable reserved or restricted categories? boundary
  2. What registration-data, disclosure and privacy or proxy conditions must the applicant satisfy? action
.us DNS operational state Assesses the root-to-.us delegation and authoritative service.

An agent must distinguish a .us infrastructure fault from a failure confined to a descendant domain.

Root-to-.us integrity

Examines delegation consistency and authentication evidence.

Delegation and validation observations

Record observed root delegation, authoritative responses and DNSSEC validation results with timestamps.

  1. Do observed root delegation records and .us authoritative responses agree on the relevant service configuration? measurement
  2. What result does root-to-.us DNSSEC validation produce, and which observations support it? measurement

.us failure localisation

Bounds operational incidents using multiple observation points.

Namespace versus child fault

Record whether failures affect .us authoritative service, a delegated branch, an individual domain or only a resolver path.

  1. What query success rates and response times are observed across .us authoritative servers and independent vantage points? measurement
  2. Does the evidence locate the failure at .us, below a child delegation or within the observing network? boundary
.us policy actions and remedies Links proposed operations and reported violations to the applicable process.

.us nexus issues, rights disputes and technical changes require different evidence and authorities.

.us operation authorisation

Determines whether an actor may request a specific change within the applicable branch.

Permitted operation and prerequisites

Record the requested operation, actor mandate, responsible service and blocking conditions.

  1. Is the request a registration-level operation, branch-delegation change or change to .us itself? boundary
  2. Which authority, credentials and policy prerequisites must be established before submitting it? action

.us complaint routing

Selects a remedy based on the actual issue and applicable policy version.

Issue-specific remedy

Record whether a case concerns nexus, registration data, naming rights, abuse or DNS operation, and link it to the appropriate process.

  1. Which .us policy and evidence establish the appropriate process for this reported issue? provenance
  2. Who may submit the request, what outcomes can the recipient authorise, and what review route applies? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.

A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.

Reported evidence

Findings from the breadth pass, kept separate from the structural claims.

Kinds and varieties

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • Second-level registrations (name.us) sold through accredited registrars
  • Locality-based hierarchical names (locality.st.us)
  • Local-government names under ci. and co. labels
  • K-12 school names under k12.<state>.us
  • Other functional locality branches (lib, cc, tec, state, gen, cog, mus, dst)
  • kids.us (historical child-content space; discontinued)
  • Names still run by delegated locality managers versus names in the central registry
  1. Which of these kinds and varieties hold for the sense of .us this model covers, and on what evidence? provenance

Identifiers and schemes

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • IANA TLD - us - Root-zone label; conventionally written with a leading dot as .us.
  • ISO 3166-1 alpha-2 - US - Country code of which .us is the DNS delegation; the TLD label is the lower-case form used in the root.
  1. Which of these identifiers and schemes hold for the sense of .us this model covers, and on what evidence? provenance

Standards and regulation

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • RFC 1480 The US Domain (IETF / RFC Editor)
  • RFC 1591 Domain Name System Structure and Delegation (IETF / RFC Editor)
  • ISO 3166-1 country codes (International Organization for Standardization)
  • usTLD Nexus Requirements Policy (.us registry operator, under U.S. Department of Commerce / NTIA stewardship)
  • IANA Root Zone Management procedures (IANA)
  • Dot Kids Implementation and Efficiency Act of 2002 (United States Congress), which created the later-discontinued kids.us space
  1. Which of these standards and regulation hold for the sense of .us this model covers, and on what evidence? provenance

Real-world use

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • Organizations register example.us as a public signal of United States nexus, distinct from unrestricted gTLDs.
  • Many U.S. public schools still publish on hostnames under k12.<state>.us.
  • Some cities and counties still operate sites on ci.<locality>.<st>.us or co.<locality>.<st>.us rather than, or in addition to, .gov.
  • Libraries, community colleges, and technical schools appear under lib/cc/tec.<state>.us.
  • Registrars collect a nexus attestation at purchase; the registry can challenge or delete names that fail the test.
  • Search and advertising systems treat .us as a United States geo-target, similar to other ccTLDs.
  1. Which of these real-world use hold for the sense of .us this model covers, and on what evidence? provenance

Typical measurements

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • Registration term - 1-10 - year
  • DNS label length - 1-63 - octet
  • Nexus category (eligibility class, not a physical quantity) - 1-3 - category
  1. Which of these typical measurements hold for the sense of .us this model covers, and on what evidence? provenance

Failure modes and hazards

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • Nexus non-compliance: names can be suspended or deleted if the registrant cannot show a bona fide U.S. presence.
  • Abandoned locality delegations leave stale school, city, and county hostnames that still resolve or that fail unpredictably.
  • kids.us failed commercially and was shut down, stranding any remaining child-oriented names in that space.
  • WHOIS/RDAP accuracy required for nexus checks conflicts with registrant privacy expectations.
  • Cybersquatting of city, state, and civic strings in both second-level and locality trees.
  • Users treat .us as interchangeable with .com or with privately sold strings such as us.com.
  • U.S. territories are often assumed to fall under .us when they have their own ccTLDs.
  1. Which of these failure modes and hazards hold for the sense of .us this model covers, and on what evidence? provenance

Regional variation

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • Use of k12.<state>.us remains common in some states and is nearly unused in others that moved schools onto .org, .net, or district-owned gTLDs.
  • The District of Columbia is treated as dc.us in the locality tree, not as a separate ccTLD.
  • Inhabited U.S. territories are not under .us: Puerto Rico (.pr), Guam (.gu), U.S. Virgin Islands (.vi), American Samoa (.as), and Northern Mariana Islands (.mp) are separate ccTLDs.
  • Second-level opening in 2002 shifted national practice toward name.us, while remaining civic and school use is still state- and locality-shaped.
  • Military and federal civilian agencies are not the .us constituency; they use .mil and .gov.
  1. Which of these regional variation hold for the sense of .us this model covers, and on what evidence? provenance

Neighbouring kinds and how to tell them apart

Reported by the breadth pass; each item needs checking against its source before it becomes normative.

  • .com - .com is an unrestricted generic TLD with no nationality test; .us is a ccTLD whose registrant must meet U.S. nexus.
  • .gov - .gov is limited to U.S. government organizations under the federal .gov program; a civic .us name (for example ci.*.us) is not a .gov authorization.
  • .edu - .edu is restricted to accredited U.S. postsecondary institutions (Educause); K-12 and many colleges on .us sit in k12/cc/tec locality branches instead.
  • .mil - .mil is the U.S. Department of Defense namespace; it is not a .us subdomain and is not available to civilian registrants.
  • ISO 3166-1 code US - US is a country-code identifier in catalogues and addresses; .us is the DNS name delegated from that code.
  • us.com (and similar private SLDs) - us.com is a privately operated second-level domain under .com, not the United States ccTLD and not subject to usTLD nexus.
  • en-US / en_US language-region tags - BCP 47 and POSIX locale identifiers name a language-region pair; they are not DNS labels and do not register a domain.
  • Territorial ccTLDs (.pr, .gu, .vi, .as, .mp) - Those codes are separate ISO 3166 / IANA delegations for U.S. territories, not subdomains of .us.
  1. Which of these neighbouring kinds and how to tell them apart hold for the sense of .us this model covers, and on what evidence? provenance

Sources

  1. Root Zone Database: .us - Confirms .us as the IANA-listed ccTLD for the United States and the current sponsoring/registry record in the root.
  2. RFC 1480: The US Domain - Specifies the original geographically structured .us namespace, state labels, locality names, and functional branches (k12, ci, co, lib, cc, tec, and related).
  3. RFC 1591: Domain Name System Structure and Delegation - Gives the ccTLD delegation model that .us sits in: ISO 3166-derived country codes in the DNS root and the duties of a delegated manager.
  4. usTLD Nexus Requirements Policy - Defines the United States presence test (nexus categories) that restricts who may hold a .us name and is the live eligibility rule for second-level registrations.

What the second pass must settle

  • Does the originating registry evidence confirm that vr.tr.us denotes the DNS top-level domain, given that no definition was recorded?
  • Which current instruments establish the complete division of responsibility among .us oversight, registry operation and locality-based branch managers?
  • Which locality-based and specially governed branches currently accept new registrations or transfers, and what is the current disposition of kids.us?
  • What exact nexus evidence, registration-data disclosure, privacy or proxy rules and reserved-name exceptions apply to each registration route?
  • What current delegation, DNSSEC and multi-vantage operational measurements establish a defensible baseline for judging .us health?