DNS Data Dictionary

Internet-Draft	DNS Data Dictionary	January 2022
Flanagan & Crocker	Expires 21 July 2022	[Page]

Abstract

Multiple applications related to the domain name system are built around a list of data elements. There is currently no unified public list of these data elements, nor is there an organized and independent change control process. This document codifies the multiple similar but not quite identical lists of data elements into a neutral DNS Data Dictionary to be maintained as an independent IANA Registry.¶

1. Introduction

The DNS Data Dictionary provides a common set of names and definitions for data elements which may be used in a DNS related protocol. The dictionary is intended to be inclusive and not obligatory. That is, the existence of a data element in this dictionary does not imply the data element must be used or recognized in any particular protocol. The items in this dictionary should represent the union for what is in existing relevant protocols, and should prevent divergence in new protocols. We also expect that each application or protocol may have additional requirements specific to the application or protocol. Such additional requirements should be documented as part of the application or protocol specification.¶

The data dictionary currently has thirty-one data elements. These data elements include the DNS records, the detailed status of a registration to the details for each of the contacts, and the account details and payment history. The proposed IANA registry lists standard data elements and their syntax for inclusion in the files.¶

We expect the DNS data dictionary to evolve to meet the needs of various applications. With the exception of correction of errors, we expect the changes to the DNS Data Dictionary to be additions as opposed to deletions or changes.¶

[Comment: We are looking for additional authors and contributors to add to and improve the data dictionary, keeping in line with the RFC Series Editor statement on authorship. https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html]¶

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. Data Element Specification

Each data element is a single unit of information that can be collected and compared during the registration process. The primary purposes of the IANA registry of data elements are to ensure that each data element is assigned a unique name and that the syntax of each data element is specified.¶

Each data element is assigned to an element type to organize the taxonomy of the data dictionary.¶

The name of the data element MUST be unique and this characteristic MUST be enforced by the registry. The character encoding recommendation for data elements is specified in Section 3.¶

The subsections below comprise an initial list of known data elements commonly being used in the templates. The title of the subsection is the data element name for the data element. The combination of data element type and data element name MUST be unique and MUST be processed as case insensitive in the IANA registry.¶

2.1. Element name: Domain Name

This is the domain name in an EPP [RFC5731] domain object and it MUST be in A-Label format.¶

2.2. Element name: Registry

The name of the registry. This data element is text/string with no naming convention enforced.¶

2.3. Element name: NS

The authoritative name server for the domain.[RFC1034]¶

See also "Authoritative server" in [RFC8499]¶

2.4. Element name: Registration Creation Date

The EPP status code (<domain:crDate>) for the domain registration creation date.[RFC5731]¶

2.5. Element name: Registration Expiration Date

The EPP status code (<domain:exDate>) for the domain registration expiration date.[RFC5731]¶

2.6. Element name: Registration Updated Date

The EPP status code (<domain:upDate>) for the domain registration updated date.[RFC5731]¶

2.7. Element name: Registration Transfer Date

The EPP status code (<domain:trDate>) for the domain registration transfer date.[RFC5731]¶

2.8. Element name: Protection

The level of protection assigned to a domain registration.¶

2.9. Element name: Nexus

The country, community, or geographic location of the account holder.¶

2.10. Element name: Person

Indication that the rules regarding this registration apply as per the registrant being a legal person or a natural person.¶

2.11. Element name: Personal

2.12. Element name: Status & Locks

The EPP Status codes (ex: clientTransferProhibited) related to domain.[RFC5731]¶

2.13. Element name: Source & Method

The back pointer from registry to registrant.¶

2.14. Element name: Payment History

Information related to the customer's financial exchanges.¶

2.15. Element name: Transaction History

[Is this same as 2.4.2?]¶

2.16. Element name: User Account ID

This is a customer ID at the registrar, reseller, or privacy/proxy provider, respectively.¶

2.17. Element name: Reserved

[this field is an artifact of prior use which was determined to not be necessary, but the field was left intact for future use]¶

2.18. Element name: Name

Individual name is represented using character strings. These strings have a specified minimum length and a specified maximum length. Individual names MAY be provided in either UTF-8 [RFC3629] or a subset of UTF-8 that can be represented in 7-bit ASCII, depending on local needs.¶

2.19. Element name: Org

Organization name is represented using character strings. These strings have a specified minimum length and a specified maximum length. Organizational names MAY be provided in either UTF-8 [RFC3629] or a subset of UTF-8 that can be represented in 7-bit ASCII, depending on local needs.¶

2.20. Element name: Street

Postal street address, formatted as per [ISO19160-4].¶

2.21. Element name: City

Postal city address, formatted as per [ISO19160-4].¶

2.22. Element name: State/Province

Postal state or province address, formatted as per [ISO19160-4].¶

2.23. Element name: Postal code

Postal code, formatted as per [ISO19160-4]. Contact postal codes are represented using character strings. These strings have a specified minimum length and a specified maximum length.¶

2.24. Element name: Country

Country code identifier. Contact country identifiers are represented using two-character identifiers specified in [ISO3166-1].¶

2.25. Element name: Phone

Telephone number structure is derived from structures defined in [ITU.E164.2005]. Telephone numbers described in this mapping are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number. An optional "x" attribute is provided to note telephone extension information.¶

2.26. Element name: Phone ext

This field is intended to represent an "extension" within the phone number to reach the specific person or role desk telephone, appropriate queue or mailbox after successfully dialing the Phone element.¶

2.27. Element name: Fax

Fax telephone number structure is derived from structures defined in [ITU.E164.2005]. Telephone numbers described in this mapping are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number.¶

2.28. Element name: Fax ext

This field is an "extension" within a phone tree or PBX that is necessary to connect to a fax machine after successfully dialing the fax element.¶

2.29. Element name: Email

Email address syntax is defined in [RFC5322].¶

2.30. Element name: Email_or_phone

There is a requirement that either the phone or email element have been confirmed reachable, which this field is intended to represent.¶

2.31. Element name: Registry UniqueID

This field represents server-unique identifiers assigned to entities, such as clients and contacts. These identifiers are character strings that typically have a specified minimum length, a specified maximum length, and a specified format.¶

3. IANA Considerations

This section describes the format of the IANA Registration Report¶

Registry, which has two tables described below, and the procedures¶

used to populate and manage the registry entries.¶

3.1. Report Specification

This registry uses the "Specification Required" policy described in [RFC8126]. An English language version of the extension specification is required in the registry, though non-English versions of the specification may also be provided.¶

The "Specification Required" policy implies review by a "designated expert". Section 5.2 of RFC 8126 describes the role of designated experts and the function they perform.¶

3.1.1. Designated Expert Evaluation Criteria

A high-level description of the role of the designated expert is described in Section 5.2 of RFC 8126. Specific guidelines for the appointment of designated experts and the evaluation of a new data element is provided here.¶

The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts, as described in Section 5.2 of RFC 8126. The pool should have a single administrative chair who is appointed by the IESG. The designated experts should use the existing regext mailing list (regext@ietf.org) for public discussion of registration requests. This implies that the mailing list should remain open after the work of the REGEXT working group has concluded.¶

The results of the evaluation should be shared via email with the registrant and the regext mailing list. Issues discovered during the evaluation can be corrected by the registrant, and those corrections can be submitted to the designated experts until the designated experts explicitly decide to accept or reject the registration request. The designated experts must make an explicit decision and that decision must be shared via email with the registrant and the regext mailing list. If the specification for a data element or report is an IETF Standards Track document, no review is required by the designated expert.¶

Designated experts should be permissive in their evaluation of requests for data elements and reports that have been implemented and deployed by at least one registry. This implies that it may indeed be possible to register multiple data elements or reports that provide the same functionality. Requests to register data elements or reports that have not been deployed should be evaluated with a goal of reducing duplication. A potential registrant who submits a request to register a new data element or report that includes similar functionality to existing data elements or reports should be made aware of the existing data elements and reports. The registrant should be asked to reconsider their request given the existence of similar data elements or reports. Should they decline to do so, perceived similarity should not be a sufficient reason for rejection as long as all other requirements are met.¶

3.1.2. Registration Procedure

The registry contains information describing each registered data element or report. Registry entries are created and managed by sending forms to IANA that describe the data element or report for the registry entry.¶

3.1.2.1. Required Information

The required information must be formatted consistently using the following registration form. Form field names and values may appear on the same line.¶

3.1.2.1.1. Data Element Definition

Name of data element type¶

MUST be unique within the registry, enforced to be unique, and MUST be processed as case insensitive¶

Name of data element¶

MUST be unique within the registry, enforced to be unique, and MUST be processed as case insensitive¶

Reference document¶

MUST define the data element, SHOULD be a URL to a RFC, and SHOULD include the section number (or other detailed internal document reference), MAY be a URL to any document available under equivalent terms¶

Registrant¶

Will be IESG for initial entries and all Standards Track specifications; otherwise as specified by the registran¶

Status¶

MUST be one of active, inactive, or unknown¶

3.1.2.2. Registration Processing

Registrants should send each registration form to IANA with a single record for incorporation into the registry. Send the form via email to iana@iana.org or complete the online form found on the IANA web site. The subject line should indicate whether the enclosed form represents an insertion of a new record (indicated by the word "INSERT" in the subject line) or a replacement of an existing record (indicated by the word "MODIFY" in the subject line). At no time can a record be deleted from the registry. On receipt of the registration request, IANA will initiate review by the designated expert(s) if appropriate, who will evaluate the request using the criteria in Section 3.1.1 in consultation with the regext mailing list.¶

3.1.2.3. Updating Report Definition Registry Entries

When submitting changes to existing registry entries, include text in the "Notes" field of the registration form describing the change. Under normal circumstances, registry entries are only to be updated by the registrant. If the registrant becomes unavailable or otherwise unresponsive, the designated expert can submit a registration form to IANA to update the registrant information. Entries can change state from "Active" to "Inactive" and back again as long as state-change requests conform to the processing requirements identified in this document. In addition to entries that become "Inactive" due to a lack of implementation, entries for which a specification becomes consistently unavailable over time should be marked "Inactive" by the designated expert until the specification again becomes reliably available.¶

3.2. Initial assignments

3.2.1. Data Element Definition in IANA Registry

--- BEGIN FORM ---¶

Name of data element:¶

Domain Name¶

Reference:¶

This RFC Section 2.1.¶

Registrant:¶

IESG, iesg@ietf.org¶

Status:¶

Active¶

--- END FORM ---¶