Skip to main content
Resources

Advisory: Clarifications to the New gTLD Registry Agreement, Specification 4; and the 2013 Registrar Accreditation Agreement (RAA), Registration Data Directory Service (WHOIS) Specification

On 17 May 2018 the ICANN Board adopted a Temporary Specification for gTLD Registration Data. This page is under review and will be updated to address the Temporary Specification.


Publication date: 12 September 2014


Updated 27 April 2015 – Note: The language in this advisory has been superseded by the updated advisory posted at: https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-27-en

Updated 22 December 2014 – Note: Implementation of this advisory has been suspended and this Advisory should not be implemented until further notice from ICANN


ICANN is publishing this Advisory in response to questions from both registries and registrars regarding the applicable Registration Data Directory Services (commonly known as WHOIS) specifications. This document provides clarifications for registries and registrars to be in compliance with the Registry Agreement and Registrar Accreditation Agreement, respectively. Most of the clarifications apply to both registries and registrars; however, the clarifications described in the second section only apply to registries, while the third section only applies to registrars. ICANN recognizes these clarifications may take some time to implement in active systems, and the clarifications will not begin to be enforced until 12 February 2015. ‬ (Updated 22 December 2014 – Note: Implementation of this advisory has been suspended and this Advisory should not be implemented until further notice from ICANN.)‬‬

One of the objectives of these clarifications is to retain the ability to easily parse the output. Interested users are encouraged to consider the clarifications below when developing parsers for RDDS output.

The terms "MAY", "MUST", "MUST NOT", and "SHOULD" are used to indicate the requirement level in accordance with RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt.

  1. The following clarifications apply to both Registry and Registrar Registration Data Directory Services specifications:

    1. All fields (e.g., rows) described in section 1.4.2 of the RDDS spec of the 2013 RAA, and sections 1.5, 1.6, and 1.7 of Specification 4 of the Registry Agreement MUST be shown. For fields where no information exists in the Shared Registration System (SRS), the key (i.e., the string to the left of the colon) MUST be shown with no information in the value section (i.e., right-hand side of the colon) of the field.

      For the following fields the value section of the field can be shown as blank if there is no data corresponding to the related object:

      • Updated Date (if the domain name has not been updated)
      • Registrant/Admin/Tech Name and/or Organization – only one of: 1) name, or 2) organization can be optional (if not available)
      • Registrant/Admin/Tech Street
      • Registrant/Admin/Tech State/Province
      • Registrant/Admin/Tech Postal Code
      • Registrant/Admin/Tech Phone Ext
      • Registrant/Admin/Tech Fax
      • Registrant/Admin/Tech Fax Ext
      • Name Server
      • IP Address

      For the following fields from the 2013 RAA the value section of the field can be shown as blank if there is no data corresponding to the related object:

      • Reseller

      For example, a query for a domain name without Name Servers will generate the following field for "Name Server":

      Name Server:

      As described in RFC 3912, the WHOIS protocol (port-43) has not been internationalized. While a substitute protocol is being developed in the IETF, Registries and Registrars are encouraged to only use US-ASCII encoding and character repertoire for WHOIS (port-43) output. If the Registry Operator/Registrar uses characters outside of the US-ASCII repertoire, the output MUST be encoded in UTF-8 to maximize the chances of interoperability.

    2. The WHOIS output MAY show a translation of the name of the key in other languages, however, the first entry in the key MUST be shown as it appears in the agreement and the translation(s) MUST be shown between parenthesis (U+0028 and U+0029) with a space (U+0020) between the key of the field (as specified by the 2013 RAA or the Registry Agreement, as the case may be) and the opening parenthesis (U+0028). Different translations MUST be separated by a solidus (U+002F). The closing parenthesis (U+0029) MUST be immediately before the colon. A space or spaces MUST NOT be shown between the translation of the name of the key and the parenthesis (U+0028 and U+0029). A space or spaces MUST NOT be shown between the solidus (U+002F).

      For example, "Domain Name:" could be shown in Spanish and Portuguese as:

      Domain Name (Nombre de Dominio/Nome de Domínio): foo.example

    3. All domain name labels in the values of any of the fields described in section 1.4.2 of the 2013 RAA, and sections 1.5, 1.6, and 1.7 of Specification 4 of the Registry Agreement (e.g., Domain Name, Name Server, email) MUST be shown in ASCII-compatible form (A-Label).

      For example, a name server with an IDN label should be shown as:

      Name Server: ns1.xn--caf-dma.example

    4. If the Domain Name is an IDN, the Registry Operator/Registrar MAY show the IDN in U-Label format using the "Internationalized Domain Name:" key. For example:

      Internationalized Domain Name: café.example

    5. Domain statuses MUST conform to the mappings specified in the EPP RFCs: 5730-5734, and 3915.

    6. The date and time shown in the footer ">>> Last update of WHOIS database: <date and time> <<<" refers to the date and time (in RFC 3339 format) in which the WHOIS database was updated from the SRS database. As per the service level requirement described in section 1.4.2 of the 2013 RAA, and Specification 10 of the Registry Agreement, the WHOIS information MUST be updated within 60 minutes of any change.

    7. IP address(es) for name servers are not required to be shown in the output of WHOIS queries for domain names.

    8. In the case of WHOIS queries for name servers, IP address(es) MUST be shown for name servers for which there is at least one active domain name that requires glue data in the DNS (please see RFC 1034). For example, if the domain name "foo.example." has the name server "ns.foo.example.", then the IP address(es) for the name server must be shown in the WHOIS output of a query for the name server "ns.foo.example.". IP address(es) MAY be shown in other cases. Note: see section 1 in case that no IP addresses are shown for the name servers.

    9. "DNSSEC: signedDelegation" MUST be shown when a DS RR is published in the DNS for the domain name being queried. "DNSSEC: unsigned" MUST be shown in all other cases.

    10. Data fields MUST be outputted in the format (including the order of keys, among others) specified in the 2013 RAA (for registrars) or the Registry Agreement (for registries). If additional data fields are included in the WHOIS output, the additional data fields MUST be placed at the end of the text format outlined in the Registry Agreement or 2013 RAA. (Note: As specified in section 1.4, Specification 4 of the Registry Agreement, the Registry Operator MUST obtain approval from ICANN before adding fields to the WHOIS output.)

      For example, when querying for a domain name:

      Domain Name: xn--caf-dma.example
      Domain ID: D1234567-TLD
      WHOIS Server: whois.nic.example
      Referral URL: http://www.nic.example
      Updated Date: 2009-05-29T20:13:00Z
      Creation Date: 2000-10-08T00:45:00Z
      Registry Expiry Date: 2010-10-08T00:44:59Z
      Sponsoring Registrar: EXAMPLE REGISTRAR LLC
      Sponsoring Registrar IANA ID: 5555555
      Domain Status: clientDeleteProhibited
      Domain Status: clientRenewProhibited
      Domain Status: clientTransferProhibited
      Domain Status: serverUpdateProhibited
      Registrant ID: 5372808-ERL
      Registrant Name: EXAMPLE REGISTRANT
      Registrant Organization: EXAMPLE ORGANIZATION
      Registrant Street: 123 EXAMPLE STREET
      Registrant City: ANYTOWN
      ...
      Name Server: NS01.EXAMPLEREGISTRAR.TLD
      Name Server: NS02.EXAMPLEREGISTRAR.TLD
      DNSSEC: signedDelegation
      Internationalized Domain Name: café.example

    11. JavaScript or other client-side script code MUST NOT be added to the output of (port 43) WHOIS.

    12. The output of web-based WHOIS MUST follow the same conventions defined in section 1.4.2 of the RDDS spec of the 2013 RAA, and sections 1.5, 1.6, and 1.7 of Specification 4 of the Registry Agreement.

    13. Each field (key/value pair) MUST be terminated with ASCII CR and then ASCII LF <U+000D, U+000A>. (See Section 2 of RFC 3912, WHOIS Protocol Specification). Note: this applies to paragraphs used for legal disclaimers or any other lines shown in the WHOIS output.

    14. Key and values (where information for value exists in the SRS) MUST be separated by a colon followed by one space, ": " <U+003A,U+0020>.

      For example, a name should be shown as:

      Name Server: ns1.xn--caf-dma.example

    15. For fields where no information exists in the SRS, the key (i.e., the string to the left of the colon) MUST be shown followed by a colon (<U+003A>) followed by the field terminator (ASCII CR and then ASCII LF <U+000D, U+000A>).

      For example, a query for a domain name without Name Servers will generate the following field for "Name Server":

      Name Server:

    16. Leading or trailing space or spaces MUST NOT appear in the WHOIS output.

    17. Empty line or lines MUST NOT appear before the footer ">>> Last update of WHOIS database: <date and time> <<<".

    18. WHOIS queries for domain name data MUST return only one record per WHOIS query.

    19. All fields (e.g., rows) described in section 1.4.2 of the RDDS spec of the 2013 RAA, and sections 1.5, 1.6, and 1.7 of Specification 4 of the Registry Agreement are case sensitive. The key (i.e., the string to the left of the colon) is case sensitive and it MUST be shown as defined in section 1.4.2 of the RDDS spec of the 2013 RAA, and sections 1.5, 1.6, and 1.7 of Specification 4 of the Registry Agreement.

    20. The ASCII CR and/or ASCII LF <U+000D, U+000A> MUST only appear at the end of each field (i.e. after key and value).

    21. The value section (i.e., right-hand side of the colon) of the fields MUST comply with the format specified in the EPP RFCs: 5730-5734, and 3915. The following fields are not specified in the EPP RFCs: 5730-5734, or 3915, and are defined below:

      • "WHOIS Server" value is defined as a hostname (see RFC952 and RFC1123)
      • "Referral URL" value is defined as a URL (see RFC3986)
      • "Sponsoring Registrar IANA ID" (Registry Agreement) or "Registrar IANA ID" (RAA 2013) value is defined as a positive integer.
      • "Sponsoring Registrar" (Registry Agreement) or "Registrar" (RAA 2013) value is defined as token (see Extensible Markup Language 1.1).
      • "Fax Ext" is defined as token (see Extensible Markup Language 1.1).
      • "Phone Ext" is defined as token (see Extensible Markup Language 1.1).
      • Contact object elements for the Registrar data are defined as EPP contact objects elements.

      The following fields from the 2013 RAA are defined below:

      • "Registrar Abuse Contact Email" (as defined in the EPP RFCs)
      • "Registrar Abuse Contact Phone" (as defined in the EPP RFCs)
      • "Reseller" is defined as token (see Extensible Markup Language 1.1)
    22. Registry Operator SHOULD use fully qualified domain names when displaying domain names.

    23. Registry Operator and Registrar MAY show the Billing Contact information for the domain name as a new field as defined in section 10 of this document.

  2. The following clarifications only apply to the New gTLD Registry Agreement, Specification 4.

    1. When receiving a query for a name server object, using either the name server name or IP address as a key, that matches more than one object, the registry SHOULD return the matching ROIDs with corresponding name server name between parentheses. For example, a query for name server "203.0.113.7" that has multiple matching objects will return:

      roid1abc-examplerep (ns1.foo.bar)
      roid5jkl-examplerep (ns2.example.com)
      roid9mno-examplerep (ns1.example.net)

      Registries SHOULD support queries for name server objects using the ROID of a name server object, e.g., queries of the form: whois nameserver <roid>, where <roid> id the ROID of a nameserver.

    2. WHOIS queries for registrar data MUST return only one record per WHOIS query.

    3. When receiving a query for a name server object that matches more than one object, the Registry MUST return several records if section 24 of this document has not been implemented. Every name server object MUST be separated by a blank line, followed by the "Server Name: " key that indicates the start of a new record.

    4. Registry Operator MAY show the Phone Ext and Fax Ext elements for the contacts in the Registrar Data as new fields as defined in section 10 of this document.

    5. Registries SHOULD support queries for registrar objects using the IANA ID of the registrar, e.g., queries of the form: WHOIS registrar <IANA ID>.

  3. The following clarifications only apply to the 2013 Registrar Accreditation Agreement, Registration Data Directory Service (WHOIS) Specification.

    1. A Registrar is only REQUIRED to show WHOIS information for domain names for which the Registrar is the Sponsoring Registrar.

    2. The field "Registry Domain ID:" refers to the Repository Object Identifier (ROID) for the Domain Name object as specified in RFC 5730 (called Domain ID in Specification 4 of the Registry Agreement). For example, a Registrar could obtain the ROID from the Registry via EPP and cache the information locally after creating or gaining a domain name via a transfer.

    3. The field "Registry Admin/Tech/Registrant ID:" refers to the Repository Object Identifier (ROID) for the Contact object as specified in RFC 5733 (called Admin/Tech/Registrant ID in Specification 4 of the Registry Agreement). For example, a Registrar could obtain the ROID from the Registry via EPP and cache the information locally. The RAA 2013 defines that this information MUST be shown if available from the Registry. In the unlikely scenario that this information is not available from the Registry, the string "Not Available From Registry" MUST be shown instead.

    4. The "Updated Date:" field MUST reflect the date and time of the latest successful update known to the Registrar. Registrars are not required to constantly refresh this "Updated Date:" from the Registry.

    5. The service level requirement "RDDS update time" described in Section 2.2 of the Registration Data Directory Service (WHOIS) Specification refers only to changes initiated by the registrar.

    6. EPP statuses in the WHOIS output MUST reflect the latest known set of EPP statuses in the Registry. Registrars are not required to constantly refresh the EPP statuses from the Registry.

  4. The Pre-delegation Testing Specifications will be updated to validate these clarifications to the requirements are being implemented correctly in new gTLD registries.

    1. Prior to the effective date of this advisory (15 February 2015) the PDT specifications will be updated to validate the requirements of specification 4 of the Registry Agreement consistent with these clarifications. (Updated 22 December 2014 – Note: Implementation of this advisory has been suspended and this Advisory should not be implemented until further notice from ICANN.)

    2. From the period between the publication date of the PDT specifications and the effective date of this advisory, any non-compliance with the RDDS output specification (consistent with this advisory) will be treated as warning to the registry.

    3. Beginning on the effective date of this advisory, any non-compliance with the RDDS output specification (consistent with this advisory) will be treated as a fail condition, and the registry will not be permitted to Pass Pre-Delegation Testing until the discrepancy has been resolved.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."