Summary

  • A NANOG mailing-list reply at 15:47 UTC corrected the active control point in a court-directed .com lock: the Texas Attorney General's account names Verisign, the registry operator, rather than a registrar.
  • ICANN says registrars set client EPP status codes, registries set server codes, and server codes take precedence. A serverHold means the domain is not activated in DNS.
  • Verisign's live RDAP record later exposed server hold plus server-side delete, transfer and update prohibitions. That confirms the layer involved, but not when each status began.
  • The operational lesson is not that registrars are irrelevant. It is that registrar access alone cannot remove a registry-set status; recovery plans need registry visibility, a legal escalation path and dependencies that survive loss of one domain.

A registrar account can be healthy while a domain has disappeared from DNS.

That distinction became the useful technical result of a NANOG mailing-list exchange on Sunday. The thread began as an argument about a Texas court action against a website outside the state. It became operationally sharper when David Conrad corrected where the reported control had been exercised: according to the government announcement, Verisign placed the .com name under a registry-level restriction. It was not simply a registrar taking a customer offline.

The message is an individual contribution to the NANOG list, not an official NANOG position. Its value is still concrete. It moves the response question from “Can we reach our registrar?” to “Which organisation controls the server-side status, under which legal jurisdiction, and how does our registrar escalate to it?”

The same domain has two administrative control layers

The Texas Attorney General's office said on 1 July that it had obtained a court-ordered writ directing Verisign, which maintains the .com registry, to put motherless.com on a “registry lock, hold, or similar status.” That wording is the office's account of the order; the underlying writ was not part of this review, and the press release should not be treated as the court's own explanation.

ICANN's EPP status guide provides the cleaner technical boundary. Client status codes are set by a registrar. Server status codes are set by a registry and take precedence over client codes. ICANN describes serverHold as a registry-operator status under which a domain is not activated in DNS.

The .com registry agreement page identifies VeriSign, Inc. as the operator. A later lookup in Verisign's own RDAP service returned four server-side statuses for the name: server hold, server delete prohibited, server transfer prohibited and server update prohibited. The lookup establishes the observed state, not the time at which each restriction was applied.

This stack matters because “the domain is locked” is an imprecise incident description. A voluntary registry-lock product used to protect a valuable name against hijacking is not the same thing as serverHold, and neither phrase should silently stand in for all four status codes. Operators need the exact RDAP or WHOIS state and the authority that set it.

A registrar remains necessary but may not be sufficient

ICANN's guidance does not tell a registrant to bypass its registrar. Even for a server status, the normal support path starts with the registrar, which must work with the registry operator. The correction therefore does not remove the registrar from the incident chain. It shows why the chain cannot end there.

Changing registrars is not a cure for a registry-set transfer prohibition or hold. A registrar support team may be able to explain the status, authenticate the registrant and forward a request, but it cannot unilaterally clear a code controlled at the registry. A response plan that assumes account recovery, a registrar transfer or a nameserver edit will always restore resolution is incomplete.

For a .com operator, the relevant dependency stack includes at least the registrant account, the registrar, Verisign's registry, the authoritative DNS service and the legal authorities able to compel or contest action. The same map will differ under another top-level domain because the registry operator, contract and jurisdiction may differ.

Monitor the registry record, not only the DNS symptom

The first visible symptom may be a failed lookup, but a DNS probe alone does not identify the control point. Nameserver records can still exist in registration data while a server hold prevents delegation from being activated. Moving authoritative DNS providers or changing zone content cannot repair a parent-side hold.

Operators should therefore preserve timestamped RDAP results alongside resolver traces. The status record distinguishes a registry restriction from a broken zone, expired registration, registrar-side client hold, DNSSEC failure or authoritative-server outage. It also gives legal, security and operations teams one shared statement of the state they are trying to change.

Monitoring should alert on changes to server hold, server transfer, server update and server delete status—not merely on expiry date or nameserver drift. The alert needs an owner who can authenticate to the registrar, reach counsel and identify the registry escalation route before an incident. A premium-domain protection service is useful against unauthorised changes, but it should not be confused with immunity from a lawful registry action.

One domain often controls more than the website

Loss of delegation can reach further than a homepage. Corporate email, password resets, SSO callbacks, API endpoints, software-update channels, certificate validation and incident communications may all depend on the same name. If the recovery mailbox itself uses the affected domain, the organisation can lose the channel needed to prove control at the moment it needs it most.

A stronger plan inventories those dependencies before a dispute. It keeps registrar and registry contacts outside the affected domain, records who can authorise legal and DNS changes, and tests an alternate public communications path. Critical services may need independently controlled names or channels, but that is a resilience choice rather than a promise that a second domain will preserve brand trust, search ranking or contractual identity.

Using multiple registrars can reduce compromise and support concentration. It does not diversify the registry behind names in the same top-level domain. Using different TLDs can diversify that layer, but introduces different operators, policies, abuse processes and jurisdictions. None of these designs makes an organisation immune to valid orders; they make the failure boundary visible and the response less improvised.

The watchpoint is who can change the parent-side state

The NANOG thread does not settle the legal merits of the Texas action, the proper reach of state law or the future governance of .com. Those questions require the court record and legal analysis beyond a network-operations briefing.

What the new reply does settle is narrower and immediately useful. The control surface was not accurately described by saying a registrar took a domain down. The government named the .com registry operator, ICANN's status model gives registries precedence over client codes, and the registry record showed server-side restrictions.

For operators, the next exercise should begin with one question: if a server status removes our name from DNS tonight, who can see it, who can escalate it, and which essential functions still work while the registry—not the registrar—holds the switch?

Sources