Domain Registration: From ICANN to Your Browser

DNS resolution explains how a name becomes an IP address. Domain registration explains how the name gets into the system in the first place. Every domain you’ve ever typed into a browser exists because of a chain of contracts, protocols, and databases stretching from a non-profit in Los Angeles to a zone file regenerated every few minutes.

The Three-Tier Model

Domain registration is a hierarchy with clear separation of concerns:

graph TD
  ICANN["<b>ICANN</b><br/>Policy maker. Accredits registrars,<br/>manages root zone, negotiates<br/>registry agreements."]
  Registry["<b>Registry</b> (e.g. Verisign for .com)<br/>Operates one TLD. Maintains the<br/>authoritative database. Publishes<br/>the zone file. Runs TLD<br/>nameservers and RDAP/WHOIS."]
  Registrar["<b>Registrar</b> (GoDaddy, Namecheap, Cloudflare)<br/>Customer-facing. Sells domains.<br/>Sends EPP commands to the registry<br/>to create, renew, transfer, delete."]
  Registrant["<b>Registrant</b><br/>You. The person or entity that<br/>registered the domain."]

  ICANN -->|contracts + accreditation| Registry
  Registry -->|EPP protocol| Registrar
  Registrar -->|web interface / API| Registrant

┌──────────────┐
│    ICANN      │  Policy maker. Accredits registrars, manages root zone,
│               │  negotiates registry agreements.
└──────┬───────┘
       │ contracts + accreditation
┌──────┴───────┐
│   Registry    │  Operates one TLD. Maintains the authoritative database
│  (e.g.,       │  of all domains under that TLD. Publishes the zone file.
│   Verisign    │  Runs TLD nameservers and RDAP/WHOIS.
│   for .com)   │
└──────┬───────┘
       │ EPP protocol
┌──────┴───────┐
│  Registrar    │  Customer-facing. Sells domains. Sends EPP commands to
│  (GoDaddy,    │  the registry to create, renew, transfer, and delete
│   Namecheap,  │  registrations.
│   Cloudflare) │
└──────┬───────┘
       │ web interface / API
┌──────┴───────┐
│  Registrant   │  You. The person or entity that registered the domain.
└──────────────┘

ICANN (Internet Corporation for Assigned Names and Numbers) is the non-profit that coordinates the namespace. It decides what TLDs exist, contracts with each TLD’s registry operator, accredits registrars, and manages the IANA functions (IP allocation, AS numbers, protocol parameters, root zone KSK). ICANN doesn’t sell domains. It sets the rules.

Registries operate the infrastructure for a TLD. Verisign runs .com and .net. Donuts operates many newer gTLDs. Each registry is a monopoly for its namespace — there’s exactly one operator per TLD. The registry maintains the canonical database, generates zone files, runs TLD nameservers, and exposes RDAP endpoints.

Registrars are the competitive layer. Dozens of registrars can sell .com domains, all talking to the same Verisign registry behind the scenes. They handle billing, customer support, DNS hosting, and the web interfaces you actually interact with.

Registry vs. Registrar — Why It Matters

The distinction isn’t academic. It determines where data lives and who controls what.

When you query a registry’s RDAP server, you get authoritative data about whether a domain exists, its status flags, its nameservers, and its dates. When you query a registrar’s RDAP server, you get richer registrant and contact information.

Thick vs. Thin Registries

Historically, .com was a “thin” registry — Verisign stored only the domain name, registrar, nameservers, status, and dates. All detailed registrant information lived at the registrar. If you wanted contact data, you had to query the registrar’s WHOIS separately.

In February 2020, .com transitioned to a “thick” registry. Verisign now stores full registrant contact data. In practice, this is somewhat academic because GDPR redaction means most registrant contacts show only the registrar’s identity. But the data is technically there, centralized at the registry level.

Most newer gTLDs were thick from the start.

EPP: How Registrars Talk to Registries

The Extensible Provisioning Protocol (EPP, RFC 5730-5734) is the XML-over-TCP protocol that every registrar uses to communicate with every registry. When you click “Register” on your registrar’s website, the sequence is:

sequenceDiagram
  participant U as You
  participant R as Registrar
  participant V as Verisign (registry)
  participant Z as .com zone file
  participant DNS as DNS / RDAP

  U->>R: Click "Register example.com"
  R->>V: EPP <create>
  V->>V: Create domain in registry DB
  V->>Z: Add NS records (next generation cycle)
  Z-->>DNS: Domain resolvable in DNS
  V-->>DNS: Domain appears in RDAP queries

You click "Register example.com"
  → Registrar sends EPP <create> to Verisign
  → Verisign creates domain in registry database
  → Verisign adds NS records to the .com zone file (next generation cycle)
  → Domain becomes resolvable in DNS
  → Domain appears in RDAP queries

You never touch EPP directly — it’s a registrar-to-registry protocol. But understanding it explains the latency you sometimes see. The gap between an EPP <create> command and the domain actually resolving in DNS is typically seconds to minutes, depending on when the registry next regenerates its zone file. Verisign regenerates the .com zone multiple times per day.

EPP also handles renewals, transfers between registrars, status changes, and deletions. Every lifecycle transition described below is ultimately an EPP command.

Domain Lifecycle

A domain passes through well-defined states from registration to deletion. The timelines are set by ICANN policy and registry rules.

stateDiagram-v2
  direction TB
  [*] --> REGISTERED
  REGISTERED: <b>REGISTERED</b> (active)<br/>Resolves. Auto-renew or manual.<br/>Duration 1–10 years
  EXPIRED: <b>EXPIRED</b> (auto-renew grace)<br/>May still resolve. Registrar can renew at normal price.<br/>0–45 days (registrar policy)
  RGP: <b>REDEMPTION GRACE PERIOD</b> (RGP)<br/>Removed from zone — stops resolving.<br/>Recoverable at penalty fee ($80–$200+).<br/>30 days (ICANN mandated for gTLDs)
  PENDING: <b>PENDING DELETE</b><br/>Queued for deletion.<br/>Cannot be renewed or recovered by anyone.<br/>5 days
  AVAILABLE: <b>AVAILABLE</b> (dropped)<br/>First-come-first-served

  REGISTERED --> EXPIRED: registration expires, not renewed
  EXPIRED --> RGP: grace period ends, not renewed
  RGP --> PENDING: RGP ends, not redeemed
  PENDING --> AVAILABLE: deletion completes
  AVAILABLE --> [*]

┌──────────────────┐
│   REGISTERED      │  Normal state. Domain resolves. Auto-renew or manual.
│   (active)        │  Duration: 1-10 years
└────────┬─────────┘
         │ registration expires, not renewed
┌────────┴─────────┐
│   EXPIRED         │  Grace period. Domain may still resolve.
│   (auto-renew     │  Registrar can renew at normal price.
│    grace period)  │  Duration: 0-45 days (registrar policy, typically 30-40)
└────────┬─────────┘
         │ grace period ends, not renewed
┌────────┴─────────┐
│   REDEMPTION      │  Domain removed from zone — stops resolving.
│   GRACE PERIOD    │  Registrant can still recover, but at a penalty fee
│   (RGP)           │  ($80-200+ depending on registrar).
│                   │  Duration: 30 days (ICANN mandated for gTLDs)
└────────┬─────────┘
         │ RGP ends, not redeemed
┌────────┴─────────┐
│   PENDING DELETE   │  Queued for deletion by the registry.
│                   │  Cannot be renewed or recovered by anyone.
│                   │  Duration: 5 days
└────────┬─────────┘
         │ deletion completes
┌────────┴─────────┐
│   AVAILABLE        │  Domain dropped. First-come-first-served.
│   (dropped)       │
└───────────────────┘

The critical details:

• Auto-renew grace varies wildly by registrar. Some give 40 days. Some give none. Check your registrar’s policy before assuming you can lapse and recover cheaply.
• Redemption is expensive by design — the fee discourages speculative letting-expire-and-reregistering. $80 is the low end; some registrars charge $200+.
• Pending delete is the point of no return. Once a domain enters this state, the current registrant cannot recover it. It will be deleted in exactly 5 days.
• Available doesn’t mean you’ll get it. More on that below.

Status Flags

Domains carry EPP status codes that control what operations are permitted and whether the domain appears in the DNS zone. These flags show up in RDAP responses.

The client* flags are set by the registrar (at the registrant’s request or as default policy). The server* flags are set by the registry (usually for legal or policy reasons). Most registrars set clientTransferProhibited by default on new domains to prevent unauthorized transfers.

The Hold Trap

clientHold and serverHold are the flags that trip people up. A domain on hold is still registered — it has an owner and an expiry date — but it’s removed from the zone file. It returns NXDOMAIN to DNS queries, which looks identical to “this domain doesn’t exist.”

If you’re checking domain availability by DNS lookup alone, held domains look available. They’re not. The only way to know the difference is to check the registry’s RDAP, where the domain will show up as registered with a hold status.

Drop Catching: The Five-Day Race

When a domain enters pendingDelete, the clock starts. In 5 days, the registry will delete it and the domain becomes available for fresh registration. This window creates an industry.

Professional drop-catching services monitor pendingDelete domains and queue automated registrations timed to fire the instant the registry deletes the domain. Multiple services compete for the same domain, sending EPP <create> commands within milliseconds of deletion.

For commodity domains (long names, obscure TLDs, no traffic), you might register one normally after it drops. For premium expired domains — short names, dictionary words, domains with existing traffic or backlinks — drop catchers win nearly every time. Services like SnapNames, DropCatch, and NameJet run auctions for high-value expiring domains, and the winner’s registration fires automatically.

What this means in practice: knowing a domain is in pendingDelete gives you roughly 5 days of lead time. Whether you can actually register it when it drops depends entirely on whether anyone else wants it. The infrastructure exists to catch desirable domains within milliseconds.

The Full Picture

The path from “I want a domain” to “it resolves in browsers worldwide” crosses every layer:

1. ICANN sets the rules and accredits your registrar
2. Your registrar sends an EPP <create> to the registry
3. The registry adds the domain to its database and generates NS records in the next zone file
4. TLD nameservers pick up the new zone file and start responding to queries for your domain
5. Recursive resolvers walk the hierarchy, find your domain’s nameservers, and cache the result
6. Your browser gets an IP address and opens a connection

The entire chain — from EPP command to resolvable domain — typically completes in minutes. The governance structure behind it took decades to build.

Sources

• RFC 5730 — Extensible Provisioning Protocol (EPP)
• RFC 5731 — EPP Domain Name Mapping
• ICANN Registrar Accreditation
• Verisign Domain Name Industry Brief