Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries

The Domain Name System (DNS) is a distributed database that stores data under hierarchical domain names and supports redundant servers, data caching, and security features. The data is formatted into resource records (RRs) whose content type and structure are indicated by the RR Type field. A typical use of DNS is that, by running the DNS protocol, a host gets the IP addresses stored at a domain name from DNS servers through a DNS resolver. Many other types of data besides IP addresses can be stored in and returned by the DNS. There are instances where different DNS answers are desired depending on the type of destination service to be connected to and/or the communication protocol to be used for that communication. This can be signaled in a query through the use of designated initial labels beginning with the underscore codepoint ("_", 0x5F). This was initially specified for the SRV RR Type . It has been extended with additional types of leading-underscore labels for use with the TLSA, URI, TXT, and other RR Types . Similarly, there is a need to encode different communication service quality requirements in DNS queries. Then different DNS answers can be returned depending, for example, on whether high bandwidth or low delay is the most important factor in the communication. Different answers could cause packets to be differently handled, constructed, or addressed which in turn could affect the path taken and/or the behavior of network switches along the communications path so as to make the communications more likely to satisfy the desired communication service requirements. Such encoding into the name being queried ensures that requirements will be forwarded by any recursive DNS servers between the querying application and the responding authoritative server. It also avoids any change in DNS protocol messages or application program interfaces (APIs). This document specifies how service requirements may be encoded in DNS queries through inclusion of the requirements in one or more labels of the name being queried enabling an authoritative server to take such requirements into account in determining its answers.

The following terminology and acronyms are used in this document. General familiarity with DNS terminology is assumed. 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 when, and only when, they appear in all capitals, as shown here. Augmented Backus-Naur Form . Application Program Interface Domain Name System Letters, Digits, and Hyphen (DNS label) Restricted LDH (DNS label) Resource Record . Ths unit of data stored in the DNS. Type, Length, Value.

This section specifies how to encode communication services quality requirements in one or more domain name labels and discusses why some alternatives methods of including requirements in a DNS query were rejected.

There exist methods to include information in a DNS request that are conveyed only from a resolver to a server, that is one hop. These are primarily through the inclusion of "meta-RRs" in the Additional Information section of a DNS request including the OPT meta-RR which can carry an extensible set of options. These methods are generally not suitable to use for the inclusion of QoS requirements for two reasons: Typical APIs do not provide for meta-RRs to be specified on a query or retrieved from a response. Because meta-RRs designate transient data associated with a particular DNS message. Thus, if a query is forwarded by a recursive DNS server, such requirements will be lost. Other methods of including information in a DNS query that are preserved when a query is forwarded are the Name, Class, and RR Type. Class is an additional dimension of DNS data besides Name and RR Type. However, only the "IN" or Internet Class has significant deployment or utilization and DNS messages specifying other Classes are frequently blocked by middle-boxes. Thus this dimension is not useful in practice. RR Type is only 16-bits and is already used to indicate the type of RRs being requests. This leaves only the name being queried for the encoding of service requirement as specified below.

Domain names consist of a sequence of labels, with labels further to the right being a higher level in the name hierarchy and labels to the left of a particular label identifying nodes in the hierarchical tree of nodes below that particular label. Each label is limited to 63 octets in length and the zero length null label is reserved to identify the root node. In a complete valid domain name, the sum of the length of each label in the name plus one octet of overhead per label (including the terminating null label) may not exceed 255 octets. Communication service requirements are encoded into names being queried. This is done by including a service label, constructed as described below, in the name usually as the first label. A service label consist of a special prefix followed by a sequence of one or more encoded TLVs indicating the service requirements. The use of such a special prefix which affects the interpretation of the remainder of the label is similar to the "xn--" prefix to indicate internationalized domain names .

Each TLV expressing a service requirement can be thought of as being binarily encoded as shown in .

4-bit unsigned integer indicating the type of service requirement. 4-bit unsigned integer indicating the length of the value associated with the service requirement in bytes. The presence of an explicit length makes it possible to skip unknown/unimplemented service requirements. The value associated with the service requirement. Although the DNS does not constraint the octet values within a label, for ease in use and due to user interface restrictions label octets are commonly limited to a subset of printing ASCII character values. Furthermore, for name matching purposes, the DNS does not distinguish between octets having the upper case and lower case codes for an ASCII letter and in some cases the storage of a label in the DNS and/or its later retrieval may change the value of an octet in that label between the values for upper and lower case version of an ASCII letter . To avoid possible problems with this DNS case insensitivity or possibly problematic byte values such as zero, the TLV or sequence of TLVs is included in the DNS name label in hexadecimal notation. There are more compact encoding that avoid these problems, such as a customization of Bootstring similar to Punycode or Base32 but for simplicity and to make the encoding into names more easily readable for debugging and other purpose hexdecimal was chosen.

The following types of service requirement are initially defined: A general indication of the most important service being sought encoded as a one byte integer patterned after the IPv4 ToS (Type of Service) value specified in . (This is "coarse" in contrast with the more precise service requirements defined below.) The following values are defined: Normal service. Minimize cost. Maximize reliability. Maximize throughput. Minimize delay. Minimize jitter. The bandwidth requirement is encoded as a float32 (32-bit IEEE floating point format number). The unit is bits per second. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored. The delay requirement is encoded in 24-bit integer format. The unit is microseconds. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored. The jitter (i.e., delay variation) is encoded in 24-bit integer format. The unit is microsecond. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored. This lost rate (i.e., the percentage of packet loss) is encoded in 24-bit integer format. The basic unit is 0.0000001% (i.e., one packet drop per 1 billion packets), where (2^24 - 2) = 1.6777214% is the largest possible loss rate defined, 2^24-1 means no loss rate requirement, and 0 means the drop rate should be smaller than 0.0000001%. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored. Using IEEE 32-bit floating point for the values when appropriate provides a compact notation that can encode up to approximately 10^38 and down to approximately 10^-38 with 6 to 9 significant digits of precision .

The on-the-wire encoding of a domain name beginning with a service requirement label would be as shown in below. (In the DNS wire encoding, each label is preceded by a length.)

Alternatively, service requirements could split among a sequence of two or more labels in a DNS name to be queried, as shown in .

The display presentation of a DNS name requesting a coarse QoS requirement for minimum delay for communication with example.com would be as shown in

TBD

This section conforms to . IANA is requested to create the following registries.

IANA is requested to create a registry on the Domain Name System (DNS) Parameters webpage as follows:

Name: DNS QoS Requirements Label Type Codes Registration Procedure: IETF review. Reference: [this document] Code Description Reference ------ ------------- ----------------- 0 reserved 1 Coarse QoS [this document] 2 Bandwidth [this document] 3 Delay [this document] 4 Jitter [this document] 5 Loss Rate [this document] 6-14 unassigned 15 extended

LDH labels are specified in as consisting of letters, digits, and hyphen but not beginning or ending with a hyphen. That is, strings of length from 1 through 63 that match the ABNF (Augmented Backus-Naur Form ) expression for LDH below. LD = ( a-z / 0-9 ) ;letter or digit (case insensitive) HYPH = %x2D ;hyphen / minus LDH = LD / HYPH LDH-LABEL = LD / LD 0*61LDH LD R-LDH (Restricted LDH) labels are specified in as the subset of LDH-LABELs that begin with two letters/digits followed by two hyphens. That is, they are LDH-LABELs that match the ABNF regular expression below. R-LDH-LABEL = 2LD HYPH HYPH 0*58LDH LD

IANA is requested to create a registry on the Domain Name System (DNS) Parameters webpage as follows:

Name: DNS Restricted LDH (R-LDH) Label Prefixes Registration Procedure: Expert review. Reference: [this document] Prefix Description Reference ------ --------------------- ----------- qs-- QoS Requirements [this document] xn-- Internationalization [RFC5820]

In reviewing applications for the assignment of an R-LDH prefix, the Expert should keep in mind the following guidance: The use of labels with the requested prefix must meet the following criteria: be documented in an Internet Draft, not significantly duplicate the use of any other R-LDH prefix, and not require any changes to DNS protocol messages or DNS mechanisms such as the handling of CNAME or DNAME RRs or wildcards. Assignment of more than one R-LDH for a purpose is prohibited. If it is necessary to distinguish sub-uses under an R-LDH prefix, this should be done by encoding within the R-LDH label after the prefix or by a further label or labels before the R-LDH label, such as a label beginning with underscore ("_"). Prefixes where the first or second character is any of the digits "0", "1", and "5"or the letters "O", "I", "L", and "S" should not be assigned, due to the possibilities of confusion, unless there are strong reasons to use these characters.

The suggestions of the following are gratefully acknowledged: TBD