Internet Systems Consortium

950 Charter Street Redwood City 94063 CA US muks@mukund.org https://www.isc.org/

Operations and Management Area Internet Engineering Task Force This document attempts to specify current DNS protocol in squashed form in a single document.

Current DNS protocol is spread over several RFCs and drafts dating back to 1987 (beginning from , , ). There is no structure and order to be found in the publication of these RFCs. The early DNS RFCs are insufficiently specified and some parts of intermediate RFCs are obsolete. The internet has changed significantly since 1987 and there are several security considerations when implementing public-facing DNS. Learning the DNS protocol pedantically for the purpose of implementing it is very very difficult, and navigating the RFCs without any consistent ordering or rationale is at best confusing to a newcomer. This document attempts to provide a single structured reference of the current "core" DNS protocol, squashing together the contents and errata of the various DNS RFCs and drafts. It also attempts to clarify DNS protocol where ambiguity exists. It is expected that implementors and anybody who is interested in protocol behavior will consult this document. Following the robustness principle ("Be conservative in what you do, be liberal in what you accept from others"), an implementation that follows the behavior in this document is expected to be compatible when talking with current implementations of DNS. As everything is described here, this document need not contain any normative references to older DNS RFCs and drafts, but for the sake of citation, the source of requirements (where applicable) is provided. This document does not attempt to describe aspects such as the history of DNS, operating system functions and API for DNS operations, DNS utilities, etc. It is meant to be a pedantic network protocol description only. 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 BCP14 when, and only when, they appear in all capitals, as shown here.

TBD.

The domain name space is a tree data structure that maps DNS names to some resource data about that name. Each node and leaf in the tree corresponds to a key-value pair, where the key is a DNS name and the value is resource data (which may be empty). The tree is used to lookup resource data corresponding to a DNS name. The DNS makes no distinctions between the uses of the interior nodes and leaves, and this document uses the term "node" to refer to both. Each node stores a label, which MUST be 1 to 63 octets in length for all nodes except the root node for which the label MUST be empty. Sibling nodes (sharing the same parent) MUST NOT have the same label, although the same label can be used for nodes which are not siblings. The DNS name of a node is the sequence of the labels on the path from the node to the root of the tree. A DNS name is printed as a concatenation left to right of the individual labels on the path from the node to the root, each label trailing with an ASCII period '.' character. Thus a complete printed DNS name ends with a period character. See (TBD: link to proper DNS name presentation formatting). In wire format, a DNS name is represented as a concatenation left to right of the individual labels on the path from the node to the root, where each label is represented starting with the label length as a single unsigned integer octet with values 0-63, and followed by the octets of the label itself. Thus, the following octets represent a DNS name "example.org." ("example" node followed by root node):

{ 0x07, 'e', 'x', 'a', 'm', 'p', 'l', 'e', 0x00 }

The total number of octets that represent a DNS name in wire format (i.e., the sum of all label lengths and label octets) MUST NOT be larger than 255. This requirement, and the other requirement that a label be between 0 to 63 octets, limit the DNS names that may be represented in the domain name space. An example of a domain name space is given below: TBD: Add tree figure from RFC 1034 section 3.4 replacing names there with modern examples from current time; describe items in the tree The octets that make up a label may contain any 8-bit value. In DNS name comparisons, when the highest-order bit of an octet of a label is 0, the value of that octet for comparison purposes is assumed to be a 7-bit ASCII character and MUST be compared without character case-sensitivity (i.e., the corresponding operand of the octet comparison operator must be transformed to ASCII lowercase first and then compared). When the highest-order bit of an octet of a label is 1, it MUST be compared directly without any character case transformations. This means that tree operations are not case-sensitive, and a tree may contain a node with label "example", or a node with label "EXAMPLE", but not both as siblings (sharing the same parent). The node could be referred to either as "example", "EXAMPLE" or "ExAmPlE" as they all corespond to the same node. A node in the domain name space MUST preserve the character case of the octets of a label as they are entered into the tree, even though tree operations are not case-sensitive. A domain in the DNS is identified by a DNS name, and consists of that part of the domain name space that is at or below the DNS name which identifies it. A DNS name is a sub-domain of another DNS name if it is contained within the latter. This relationship can be tested by seeing if the sub-domain's DNS name ends with the containing DNS name. For example, "sub.example.org." is a sub-domain of "example.org.".

TBD.

TBD.

TBD.

draft-muks-dnsop-dns-squash-00 Initial draft.