root server instance
An individual server that responds to Domain Name System queries that are directed to the Internet Protocol (IP) address of one of the servers that is authoritative for the root zone. For example, an “instance of the ICANN Managed Root Server" refers to a root server that answers queries sent to the IP address of the authoritative name server operated by ICANN.
Hundreds of root server instances exist around the world. When a resolver submits a query to a root server, anycast routing relays the query packet to the nearest (in terms of routing layout) root server instance. If a local instance is unavailable (perhaps due to a power outage or a network problem), routers automatically redirect the query to the next nearest instance.
Root Server System Advisory Committee(RSSAC)
The Advisory Committee that advises the ICANN Board and the ICANN community on matters relating to the operation, administration, security, and integrity of the Internet’s Root Server System. The RSSAC consists of representatives from the root server operator organizations and liaisons from other ICANN groups and the partner organizations involved in the technical and operational management of the root zone.
Root Server System Advisory Committee Caucus(RSSAC Caucus)
The group within the RSSAC that is responsible for the essential work of the RSSAC. The RSSAC Caucus produces advisories, reports, and other technical documents for approval by the RSSAC. The RSSAC Caucus consists of RSSAC members and individual Domain Name System and root server system experts appointed by the RSSAC.
The collective services provided by all of the anycast instances managed by the root server operators. The root service responds to Domain Name System queries about the root zone. It does not matter which root server instance responds to a query. All root servers with the same version or edition of the root zone provide identical answers. Answers received from the root service can be validated using the Domain Name System Security Extensions.
root trust anchor
The authoritative key at the top of the chain of trust for the Domain Name System Security Extensions (DNSSEC). The authority of the root trust anchor is conferred through parameter settings on DNSSEC-aware resolvers. It is not derived from other keys.
The root trust anchor consists of a public-private key pair. The private key is used to sign the zone signing key (ZSK) for the root zone. DNSSEC-aware resolvers use the public key to verify the authenticity of data in the root zone.
Root Zone Administrator(RZA)
The entity responsible for managing the data contained within the root zone. The Root Zone Administrator works with the operators of top-level domains (TLDs) and maintains technical and administrative details about the TLDs.
root zone database
Root Zone Evolution Review Committee(RZERC)
The group that reviews proposed architecture changes to the contents of the Domain Name System root zone and makes recommendations regarding the changes to the ICANN Board. The RZERC consists of nine members:
- ICANN Board member
- Senior representative of the Internet Assigned Numbers Authority (IANA) functions operator
- Chair or delegate of the Security and Stability Advisory Committee
- Chair or delegate of the Root Server System Advisory Committee
- Chair or delegate of the Address Supporting Organization
- Chair or delegate of the Internet Engineering Task Force
- Representative selected by the Registry Stakeholder Group of the Generic Names Supporting Organization
- Representative selected by the Country Code Names Supporting Organization
- Representative of the organization identified to serve as the Root Zone Maintainer
root zone key signing key
The public-private key pair that is the secure entry point for the root zone and serves as the root trust anchor for the Domain Name System Security Extensions (DNSSEC). The root trust anchor uses its private key to digitally sign the zone signing key (ZSK) for the root zone. DNSSEC-aware resolvers use the root trust anchor’s public key to verify the authenticity of the data in the root zone.
Root Zone Key Signing Key Operator(RZ KSK Operator)
The RZ KSK Operator is responsible for:
- Generating and protecting the private component of the RZ KSK.
- Securely importing public key component from the Root Zone Zone Signing Key Operator (RZ ZSK) Operator.
- Authenticating and validating the public RZ ZSK keyset.
- Securely signing the RZ ZSK keyset.
- Securely transmitting the signed RZ ZSK key set to the RZ ZSK Operator.
- Securely exporting the RZ KSK public key components.
- Issuing an emergency key rollover within a reasonable time if any private key component associated with the zone is lost or suspected to be compromised.
The RZ KSK Operator role is performed by Public Technical Identifiers (PTI) as part of its contracts with ICANN to perform the Internet Assigned Numbers Authority (IANA) functions. PTI is an affiliate of ICANN.
root zone key signing key rollover(KSK rollover)
Root Zone Label Generation Rules(RZ-LGR)
Root Zone Maintainer(RZM)
The entity that accepts root zone data from the Root Zone Administrator, cryptographically signs the root zone data using the zone signing key, and places the signed data in the root zone distribution system. The RZM also serves as the Zone Signing Key Operator for the root zone.
root zone management
The Internet Assigned Numbers Authority (IANA) function related to the stewardship of the root zone. Root zone management involves maintaining the authoritative registry of the top-level domains (TLDs), coordinating with the operators of the TLDs, and managing the root zone’s key signing key (KSK).
Root Zone Zone Signing Key Operator(RZ ZSK Operator)
The RZ ZSK Operator is responsible for:
- Generating and protecting the private component of the RZ ZSK.
- Securely exporting and transmitting the public RZ ZSK component to the RZ Key Signing Key (KSK) Operator.
- Securely importing the signed RZ ZSK keyset from the RZ KSK Operator.
- Signing the root zone's resource records.
- Issuing an emergency key rollover within a reasonable amount of time if any private key component associated with the zone is lost or suspected to be compromised.