What Is ICANN, and What Role Does It Play in Domain Registration?

Every time you register a domain, you pay a small fee to an organization you never deal with directly, agree to rules you probably did not read, and gain rights you may not know you have. That organization is ICANN, the Internet Corporation for Assigned Names and Numbers. ICANN does not sell domains, host websites, or run your DNS, yet almost every rule that governs a .com, .org, or .shop registration traces back to it. This article explains what ICANN is, how it is organized, what it actually controls (and what it does not), and how its policies affect you when you buy, renew, transfer, or dispute a domain. If you are still fuzzy on the companies sitting between you and ICANN, start with the difference between a registry and a registrar.

What Is ICANN?

ICANN is a not-for-profit public-benefit corporation, founded in 1998 and headquartered in Los Angeles, California. Its job is to coordinate the internet's unique identifiers so that the global namespace stays consistent: a name like example.com must point to the same place no matter where in the world you look it up.

Concretely, ICANN coordinates three kinds of identifiers:

• Domain names — the top-level domains (TLDs) in the DNS root zone, and the policies for generic TLDs like .com, .net, .org, and the newer gTLDs.
• IP addresses — the large blocks of IPv4 and IPv6 address space that ICANN allocates to the five Regional Internet Registries (RIRs), such as ARIN and RIPE NCC.
• Protocol parameters — the registries of port numbers, protocol codes, and other values that standards from the IETF rely on.

The first two are handled through the IANA functions (Internet Assigned Numbers Authority), which ICANN has performed since its creation. Since 2016, these functions have been carried out by PTI (Public Technical Identifiers), an affiliate of ICANN.

A useful way to remember ICANN's role: it is a coordinator and policy maker, not an operator of your domain. It writes and enforces the rules; registries and registrars do the day-to-day work.

A Short History of ICANN

Before ICANN existed, much of the DNS was coordinated informally. The IANA function was run largely by Jon Postel at the University of Southern California, and Network Solutions operated the .com, .net, and .org registries under a contract with the US government. There was a single company selling the most popular domains, and no common rulebook for competition.

ICANN was created in 1998 to move this coordination into a private, international, multistakeholder organization. Some milestones:

Year	Milestone
1998	ICANN incorporated as a California nonprofit
1999	Competitive registrar market introduced; the Uniform Domain-Name Dispute-Resolution Policy (UDRP) adopted
2000	First new gTLDs approved, including .info and .biz
2012	New gTLD Program opens, eventually adding well over a thousand new TLDs such as .app, .shop, .blog
2013	Updated Registrar Accreditation Agreement (2013 RAA) with stronger registrant protections
2016	The IANA stewardship transition ends the US government's contractual oversight of the IANA functions
2025	gTLD registries and registrars are no longer required to run port 43 WHOIS; RDAP becomes the standard

ICANN has also planned a next application round for new gTLDs, so the list of available extensions will keep growing.

How ICANN Is Organized

ICANN uses a multistakeholder model. Rather than governments alone, or companies alone, setting the rules, policy is developed by groups representing different interests and then approved by ICANN's Board.

Supporting Organizations (Policy Developers)

• GNSO (Generic Names Supporting Organization) — develops policy for gTLDs. Registries, registrars, businesses, intellectual property interests, and noncommercial users all have seats. Transfer rules, registration data rules, and UDRP reviews come from here.
• ccNSO (Country Code Names Supporting Organization) — a forum for country-code TLD managers on global ccTLD issues. It does not dictate how individual ccTLDs operate.
• ASO (Address Supporting Organization) — advises on global IP address policy, working with the Regional Internet Registries.

Advisory Committees

• GAC (Governmental Advisory Committee) — governments and intergovernmental organizations giving advice on public-policy aspects.
• ALAC (At-Large Advisory Committee) — represents individual internet users.
• SSAC (Security and Stability Advisory Committee) — advises on DNS security and stability.
• RSSAC (Root Server System Advisory Committee) — advises on the operation of the root server system.

The Board and the Organization

The ICANN Board approves policies and oversees the organization. ICANN org (the staff) implements policies, manages contracts, runs the compliance function, and operates services such as one of the root server identities (L-root).

Anyone can participate. Public comment periods are open to everyone, and ICANN holds public meetings several times a year.

What ICANN Actually Controls

The Root Zone

The DNS is a tree, and the root zone is its top: a list of every TLD and the name servers responsible for it. Through the IANA functions, ICANN (via PTI) processes changes to that list, for example when a TLD changes its name servers or DNSSEC keys. You can see the result yourself by asking a root server who is responsible for .com:

dig NS com. @a.root-servers.net +norecurse

The answer lists the .com name servers (a.gtld-servers.net and friends) in the authority section. That delegation is what the root zone records.

IANA also publishes a public record for each TLD, showing the registry operator and its technical contacts. You can query it with whois:

whois -h whois.iana.org com

Look for the organisation lines (the registry operator) and the whois: line, which tells you which server holds registration data for that TLD.

Contracts With gTLD Registries

Every gTLD registry operator signs a Registry Agreement with ICANN. It covers how the registry must operate: technical requirements, uptime, data escrow, registration data services, treating registrars equally, and paying ICANN fees. If a registry fails, data escrow lets ICANN move the TLD to an emergency back-end operator so existing domains keep resolving.

Registrar Accreditation

Any company that wants to sell gTLD domains directly through the registries must be ICANN-accredited and sign the Registrar Accreditation Agreement (RAA). The 2013 RAA requires registrars to, among other things:

• Verify registrant contact details, including validating the email address
• Keep records of registrations
• Escrow registration data so it survives a registrar failure
• Respond to abuse reports
• Publish the registrant benefits and responsibilities and follow ICANN consensus policies

Resellers (companies that sell domains through an accredited registrar) are not accredited themselves, but the accredited registrar remains responsible for them.

You can confirm a registrar's accreditation by its IANA ID, which appears in RDAP and WHOIS output. This command uses the public rdap.org bootstrap redirector to fetch a domain's registrar and its IANA ID:

curl -sL https://rdap.org/domain/example.com \
  | jq '.entities[] | select(.roles | index("registrar"))
        | {name: (.vcardArray[1][] | select(.[0] == "fn") | .[3]),
           ianaId: (.publicIds // [] | map(.identifier))}'

The same IANA ID appears in ICANN's public list of accredited registrars.

Consensus Policies

ICANN consensus policies apply to every gTLD registry and accredited registrar. The ones you will meet as a domain owner are:

Policy	What it means for you
Transfer Policy	Your right to move domains between registrars, auth codes, transfer locks, and change-of-registrant rules
UDRP	A fast, mostly online process for trademark owners to recover domains registered in bad faith
Expired Registration Recovery Policy	Required renewal reminders and a window to renew after expiration
Registration Data Policy	What contact data is collected and what is published or redacted in RDAP and WHOIS
Registrar transfer dispute rules	How registrars resolve disputes about transfers between them

These policies are why the transfer process looks the same at every .com registrar, and why you can always get an authorization code. For details, see how to transfer a domain to another registrar and what an EPP authorization code is.

Registration Data (WHOIS and RDAP)

ICANN sets the rules for gTLD registration data services. After the GDPR took effect in 2018, ICANN required registrars and registries to redact most personal data from public output, and later replaced the temporary rules with a permanent Registration Data Policy. ICANN also made RDAP (Registration Data Access Protocol) mandatory and, from early 2025, allowed the older port 43 WHOIS service to be switched off for gTLDs. You can read more in what WHOIS is and what RDAP is.

Contractual Compliance

ICANN runs a Contractual Compliance department that accepts complaints about registries and registrars. If a registrar refuses to give you your auth code, ignores your transfer request without a valid reason, or fails to send required renewal notices, you can file a complaint. Compliance cannot decide who owns a domain, but it can push a registrar to follow its contract, and in serious cases ICANN can terminate a registrar's accreditation.

What ICANN Does Not Do

Plenty of confusion comes from expecting ICANN to do things it does not. ICANN does not:

• Sell domains or set retail prices. Registrars set retail prices; registries set wholesale prices (in some cases subject to limits in their registry agreements).
• Host websites or DNS zones for your domain. Your DNS host does that.
• Resolve ownership disputes directly. UDRP cases are decided by independent providers such as WIPO, and other disputes go to courts.
• Control most ccTLDs. Country-code TLDs like .uk, .de, or .ca are managed by local operators under local policy. IANA records who manages them in the root zone, but their registration rules, transfer processes, and dispute policies are set locally.
• Police website content. ICANN's remit is the identifier system. Content complaints usually go to the registrar, the host, or law enforcement.
• Run the internet. Routing, standards, and most infrastructure are handled by network operators, the IETF, and others.

How ICANN Affects You as a Domain Owner

The ICANN Fee

For gTLD domains, registries and registrars pay ICANN fees, and registrars usually pass a small per-domain-year fee on to you, often shown as an "ICANN fee" line on your invoice. It is a fraction of a dollar per year, but it is why the price at checkout can be slightly higher than the headline price. ccTLD registrations generally do not carry it.

Your Rights as a Registrant

Because of ICANN policy, for gTLD domains you have a right to:

• Transfer to another registrar, subject to defined exceptions, and receive your auth code within a set time
• Receive renewal reminders before expiration and a period to renew after expiration
• Accurate information about how your registration data is handled
• Use the UDRP if someone registers a domain in bad faith that infringes your trademark

You also have responsibilities: keep your contact information accurate, respond to verification emails, and renew on time. Failing to verify your email can lead to the domain being suspended, which looks like an outage.

Rules You Will Hit in Practice

Many everyday surprises come from ICANN policy:

• A newly registered domain often cannot be transferred to another registrar for 60 days.
• Changing the registrant name or organization can trigger a 60-day transfer lock unless you opt out.
• Your registrar will email you to verify your contact address, and an unverified domain can be suspended.
• Expired domains go through grace and redemption periods before deletion.

If any of these are blocking you right now, why you can't transfer your domain walks through each block and how to clear it.

A Quick Script to See the ICANN Chain for a Domain

This Python script uses only the standard library. For a given domain, it finds the RDAP server for the TLD from IANA's bootstrap file, then prints the registrar, its IANA ID, and the domain's status codes. It shows the chain of ICANN-coordinated parties behind any gTLD domain.

import json
import sys
import urllib.request

BOOTSTRAP = "https://data.iana.org/rdap/dns.json"


def fetch(url):
    req = urllib.request.Request(url, headers={"Accept": "application/rdap+json"})
    with urllib.request.urlopen(req, timeout=20) as resp:
        return json.load(resp)


def rdap_base_for(tld, bootstrap):
    for tlds, urls in bootstrap["services"]:
        if tld in tlds:
            return urls[0].rstrip("/") + "/"
    return None


def main(domain):
    domain = domain.lower().strip(".")
    tld = domain.rsplit(".", 1)[-1]
    base = rdap_base_for(tld, fetch(BOOTSTRAP))
    if not base:
        print(f"No RDAP service listed for .{tld} (likely a ccTLD outside the bootstrap)")
        return

    data = fetch(f"{base}domain/{domain}")
    print(f"Domain:   {data.get('ldhName', domain)}")
    print(f"Registry: RDAP at {base}")

    for entity in data.get("entities", []):
        if "registrar" in entity.get("roles", []):
            name = next(
                (v[3] for v in entity.get("vcardArray", [None, []])[1] if v[0] == "fn"),
                "unknown",
            )
            ids = [p["identifier"] for p in entity.get("publicIds", [])]
            print(f"Registrar: {name} (IANA ID: {', '.join(ids) or 'n/a'})")

    print("Status:   " + ", ".join(data.get("status", [])))


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "example.com")

Run it with python3 icann_chain.py yourdomain.com. For a .com domain, the output shows Verisign's RDAP server as the registry, your registrar with its IANA ID, and statuses like client transfer prohibited.

---

ICANN FAQ

Conclusion

ICANN sits at the top of the domain system without ever touching your domain directly. It coordinates the root zone and other unique identifiers through the IANA functions, signs contracts with every gTLD registry, accredits the registrars that sell those domains, and develops the consensus policies that decide how transfers, renewals, disputes, and registration data work. Many of the rules that frustrate domain owners, such as 60-day transfer locks or email verification, come from ICANN policy, and so do many of the protections, like guaranteed access to your auth code and mandatory renewal reminders.

Knowing where ICANN's authority starts and stops saves time. Pricing problems belong to your registrar, content complaints go to hosts or registrars, ccTLD issues go to the local registry, and contract breaches by gTLD registrars can be escalated to ICANN Compliance. With that map in mind, you can resolve most domain problems by going to the right party first.

Here are some useful references for going deeper on ICANN and its role:

1. ICANN: icann.org — the official site, with policies, public comments, and the compliance complaint forms.
2. IANA: Root Zone Database — every TLD in the root zone with its registry operator.
3. ICANN: Transfer Policy — the consensus policy governing transfers between registrars and changes of registrant.
4. ICANN: 2013 Registrar Accreditation Agreement — the contract every accredited gTLD registrar signs.
5. RFC Editor: RFC 2860: Memorandum of Understanding Concerning the Technical Work of IANA — the agreement defining IANA's protocol parameter role with the IETF.