IANA, the Internet Assigned Numbers Authority, is the function that coordinates the globally unique identifiers the Internet depends on: the DNS root zone, the top-level pools of IP addresses and autonomous system numbers, and the registries of protocol parameters such as port numbers. In Internet governance it is the operational registry layer, carrying out policies made by other bodies rather than setting policy itself.
Since 2016 the IANA functions are performed by Public Technical Identifiers (PTI), an affiliate of ICANN, under agreements with the communities it serves. The function predates ICANN by decades and grew out of the registry work that Jon Postel began in the early days of ARPANET.
The three IANA function areas
IANA work is divided into three function areas, each with its own policy source and customers. The separation matters, because a change in one area, for example a new top-level domain, follows a completely different process from a new protocol code point.
| Function area | What IANA maintains | Policy source |
|---|---|---|
| Domain names | DNS root zone contents, .int and .arpa, root DNSSEC trust anchor | ICANN multistakeholder policy process |
| Number resources | Global pools of IPv4, IPv6 and AS numbers | Global policies from the regional registries |
| Protocol parameters | Thousands of code-point registries | IETF standards and RFC instructions |
In each area IANA acts as a neutral record keeper. It checks that a request follows the applicable policy and is technically correct, records it, and publishes the result, but it does not decide which policies should exist.
How IANA manages the DNS root zone
For every top-level domain, IANA keeps the root zone database listing the operator, contacts, name servers and DNSSEC delegation signer records. When a TLD manager requests a change, IANA verifies authority and technical readiness before passing the change on.
Root zone management is a shared process. IANA processes and approves change requests, while the root zone maintainer, currently Verisign, edits, signs and distributes the zone file to the independent root server operators that answer queries.
| Role | Responsibility | Performed by |
|---|---|---|
| TLD manager | Requests changes for its top-level domain | Registry operators and country-code managers |
| IANA functions operator | Validates and approves changes | PTI |
| Root zone maintainer | Builds, signs and publishes the zone | Verisign |
| Root server operators | Serve the root zone to resolvers | 12 independent organizations |
| Root KSK manager | Holds the DNSSEC key-signing key | IANA, through key ceremonies |
The root key-signing key used for DNSSEC is managed in public key signing ceremonies held at secure facilities, with trusted community representatives present. The first root KSK rollover was completed in 2018 after a delay caused by concerns about resolvers with outdated trust anchors.
Number resources and protocol parameters
IANA does not assign IP addresses to companies or users. It allocates large blocks to the five regional Internet registries, which in turn assign space to Internet providers and end organizations under their own regional policies.
IANA allocated its last IPv4 /8 blocks in February 2011, which marked global IPv4 depletion at the top level. Today it holds only small recovered IPv4 amounts, while the IPv6 pool remains vast, with allocations to registries typically made in /12 blocks.
| Registry | Example entries | Registration rule |
|---|---|---|
| Service names and port numbers | 443 for HTTPS, 25 for SMTP | Expert review or IETF review by range |
| DNS resource record types | A, AAAA, MX, HTTPS | Expert review |
| HTTP status codes | 200, 404, 503 | IETF review |
| Media types | application/json, image/webp | Specification or expert review |
| TLS cipher suites | TLS_AES_128_GCM_SHA256 | Specification required |
Port numbers show how ranges carry different registration rules: system ports 0-1023 require IETF review, user ports 1024-49151 can be registered through expert review, and dynamic ports 49152-65535 are never assigned.
Accountability and common misunderstandings
Until 2016 the IANA functions were performed under a contract with the United States National Telecommunications and Information Administration. The stewardship transition ended that role and placed oversight with the communities themselves, through a Customer Standing Committee, service level agreements and periodic reviews.
| Body | Primary role | Relationship to IANA |
|---|---|---|
| IANA | Maintains unique identifier registries | The reference concept |
| ICANN | Coordinates name policy, parent of PTI | Operates IANA through PTI |
| IETF | Develops protocol standards | Instructs IANA through RFCs |
| Regional Internet registries | Assign addresses in their regions | Receive blocks from IANA |
| W3C | Develops web standards | Uses IANA registries such as media types |
- IANA does not control Internet content or decide which websites exist.
- IANA does not operate root servers; independent operators do.
- IANA does not sell domains; registries and registrars do.
- IANA is not a regulator; its authority is limited to accurate, policy-compliant registry maintenance.
In plain words
The Internet needs certain numbers and names to be unique everywhere, much like the world needs one agreed list of country dialing codes. IANA is the central record keeper for these lists.
It keeps the top-level directory of domain endings such as .com or .de, hands out big blocks of Internet addresses to regional registries, and records technical codes so that different software can understand each other. It follows rules set by others, and its job is to keep the lists accurate and trustworthy.
A real-world example
An engineering team at a messaging company designs a new application protocol and wants it to run on a fixed, well-known port so that firewalls can recognize it. After publishing a specification, the team submits a port request; an expert reviewer checks whether an existing port could be reused and whether the request is justified.
The review concludes that the protocol can run over HTTPS on port 443 with a registered ALPN identifier instead, and IANA records that identifier in the relevant registry. The outcome saves a scarce system port, and other implementers can now find the authoritative registry entry when building compatible clients.