serverHold pulled t.me from the zone, no CVE fired

The WHOIS record for t.me, pulled on 2026-10-15, carries four status codes: clientDeleteProhibited, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited. All four are client-side locks set by the registrar, GoDaddy. The domain still delegates to four Google Cloud DNS name servers, ns-cloud-b1 through ns-cloud-b4.googledomains.com. The delegation is intact and no hold has pulled the name from the zone.

That split matters because of how EPP status codes assign responsibility. Codes prefixed with “client” are applied by the registrar and can be removed by the registrar. They block the common hijack paths: an unauthorized transfer to another registrar, a deletion, a nameserver swap, a renewal change. Codes prefixed with “server” are applied by the registry operator and sit above the registrar. serverHold is one of those. When a registry sets serverHold, it drops the domain’s delegation from the zone and the name stops resolving regardless of what the registrar or registrant wants. The t.me record shows no server-side codes.

The domain was created on 2010-05-20 and the registry expiry is 2035-05-20. The record was last updated on 2026-08-11. The registrant is shielded behind Domains By Proxy, GoDaddy’s privacy service, so the public record names no operator; t.me is the link domain Telegram uses for public handles and join links. DNSSEC is unsigned.

The lock set here is the standard protection for a high-value name. The four client prohibitions stop the registrar-level attacks behind most domain takeovers: someone social-engineers a transfer, or gets into the registrar account and repoints the nameservers. With clientTransferProhibited and clientUpdateProhibited in place, both paths need the lock lifted first, which adds a step and a log line.

The locks do not cover the resolution path. With DNSSEC unsigned, the delegation to Google Cloud DNS is not cryptographically validated, so a resolver has no way to tell a forged answer for t.me from a real one. For a domain that fronts a large share of Telegram’s public links, the registration is locked down while the answers it hands out are not authenticated.

If you run high-value domains, this record is a reasonable baseline. Set the four client prohibitions. For names you cannot afford to lose, ask the registrar about a registry lock, which applies the server-side equivalents (serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited) and requires out-of-band verification to lift. Then sign the zone with DNSSEC so resolvers can validate the delegation that the registrar locks leave unprotected.