The Architecture of Network-Aware Domain Name System (DNS)

Different application flows have different requirements on networking, such as bandwidth, delay, jitter, reliability, security, and so on. Many of these requirements are critical for the quality of service. Users are more willing to pay for premium services (e.g., Virtual Reality (VR)) than before. Meanwhile, today's networks have advanced beyond the best-effort model and are capable of providing per-flow services to meet various application requirements (e.g., QoS) by means of programmability, resource management (e.g., network slicing), traffic engineering, and path regulation (e.g., segment routing and service function chaining). However, a clear gap exists. Applications usually only care about the abstract requirements ("WHAT") rather than the actual measures networks take to meet such requirements ("HOW"). So far there is no direct means for networks to tell applications their capabilities, because the applications do not know what to do about them. On the other hand, due to the limitations of the commonly available network socket API, it is also difficult for applications to convey their service requirements to the network. Currently, if any service different from "best effort" is desired, one either assumes the requirements can be expressed to network controllers through some out-of-band means or resorts to encoding the requirements into the packets (e.g., options in IPv6 extension headers network tokens). We need a simpler and more extensible way to set up the service contract. We define a framework to support network awareness through DNS. Requirements for network services can be incorporated into DNS queries from a host (e.g., as specified in ), and the returned information enables access to services meeting those requirements. For example, new semantics representing a service commitment can be embedded in the returned IP addresses (i.e., semantic addressing ). Alternatively, a richer way to express how to obtain the desired service is to query for a Service Binding (SVCB) RR . 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. In a nutshell, the application's service requirements are embedded into the DNS queries from a host. The DNS replies either provide semantic IP addresses or provide data that helps construct the packet header or headers signaling special packet handling in the network. The application flow packets may use the existing socket API to be sent. Network devices, after capturing such packets, would decode the semantics and apply any special packet handling accordingly. This document describes the architecture, requirements, and use cases of the Network-Aware DNS. The details of DNS query encoding and semantic addressing/data in DNS replies will be described in other documents.

The following terminology and acronyms are used in this document. 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. Application Programming Interface Domain Name System Resource Record . The unit of data stored in the DNS. Encoding extra semantics beyond the destination ID in an address

The architecture of the Network-Aware DNS, where the required DNS reply information is statically stored in the DNS, is shown in .

| Network +-------------> | | socket API | | requirements +----------+ +----------+ ]]> The architecture of the Network-Aware DNS, where the required DNS reply information is dynamically computed, is shown in .

| | | | 3B. query | | | | | | | |<----------------| | +------+---+ 4B. reply +----+-------+ ^ | 4. | 2. 3.| | r | p q | | e | o u | | p | l e | | l | i r | | y | c y | V V y +--+-------+ +----------+ | | 5.pkt thru | | 6.pkt w/ met | Host +---------------->| Network +-------------> | | socket API | | requirements +----------+ +----------+ ]]> The procedure steps are explained as follows: The network operator registers the semantic addresses/data associated with a name in authoritative DNS servers in the form of RRs. In addition to the location, the semantics represent the commitments for the network to meet certain service requirements. The semantic addresses or data can be dynamically computed or statically configured by the network operator. Meanwhile, the packet processing policy corresponding to each semantic address/data is configured on the network devices, such as routers. How the network meets the service requirements is opaque to host applications. A host application, when conducting a DNS query for a name, would also express its service requirement. A host application can also be ignorant of this service-requesting scheme; in this case, the normal DNS query is used and the best-effort results are returned. In the static case, this is answered directly by a normal DNS server. In the dynamic case, the query is redirected, through a CNAME or zone referral, to a network controller that can emulate a DNS server and that dynamically computes the response. If the query with service requirements can be satisfied by some RRs in DNS, the result is returned to the host, either directly in the static case or from the network controller in the dynamic case; otherwise, a normal DNS response, either an error or the best-effort result, is returned. Once the host application receives the reply, assuming the reply is not an error, it simply uses the address (or assembles the header fields as directed by the semantic data) to forward the packet through a standard socket API. The semantic address or data may be cached at the host for the lifetime of the flow. Alternatively, the DNS response TTL may indicate the period of time for which the semantic address will provide the service assurances, and the application may query the DNS again at or shortly before the end of that time to refresh the semantic address/data or to obtain a new address or data that will be effective for a future interval; however, it is not common for TTL information to be returned to an application performing a DNS query. The network devices would process the packets based on the configured policies if the packets carry semantic addresses and/or header fields. Using a semantic address/data other than for the best-effort service might be subject to extra cost based on some service agreement. We impose some requirements on the architecture to make it practical for incremental deployment. No new protocol is introduced to enable the architecture. As an infrastructural system and protocol, DNS is stable. No change to the DNS architecture and protocol is made. However, within the DNS framework, we explore the freedom to introduce new semantics and new RR types to encode semantic data. Similarly, it is hard to change the ubiquitous network socket APIs, so we simply rely on the existing ones. The system would be better used in limited domains where the network operator owns not only the networks but also the relevant name servers. In some cases, it is also possible to extend the scope to multiple domains if the packet processing that meets the service requirements can be coordinated across domains. The semantic address or data should be per-application or per-flow. So each application or flow may need its own DNS name resolution, even for the same service. Most applications can still use the conventional best-effort service without noticing any change. In the more dynamic architecture, DNS queries with service requirements can, when received by a resolver, be dynamically sent to a controller maintained by the network operator, allowing the network operator to generate on-demand semantic addresses or data for the name server, which will eventually return the information back to the host application.

A host application can use three methods to obtain information from the DNS to meet its service requirements. These methods are as follows: It sends a requirement-encoded name to ask for an IP-address-type RR (e.g., AAAA) and expects the semantics that meet the requirements to be embedded in the returned addresses. The encoding method is described in . It sends a normal name to ask for a different type of RR, and the semantic data in the returned RRs represents the means to meet the service requirements (e.g., ). Combining methods 1 and 2, it sends a requirement-encoded name to ask for a different type of RR, which might be in addition to, or lead to (such as the SRV type RR), an IP-address-type RR, and the semantic data in the RR represents the means to meet the service requirements. This architecture can support multiple use cases using one of the above methods. Below are some examples. This use case may use method 2. We can support true end-to-end SRv6 service where a Segment List (SL) is acquired from DNS using the RR Type specified in and an SRH (Segment Routing Header) is directly inserted in the IPv6 packet header. While the SRH determines the packet's forwarding path, different packet handling and QoS treatment can also be applied to the packet along the path. This use case may use method 1. Due to the abundance of IPv6 addresses, each name can be assigned multiple addresses, each representing some special network service. As the network devices are configured or programmed to interpret and process the semantics embedded in addresses, different services can be applied to flows destined for the same destination. The details are described in a companion draft. This use case may use method 3. Some service-defining header fields (e.g., the DSCP in the IPv4 header, and the Traffic Class and Flow Label in the IPv6 header) can be used to indicate QoS or other service requirements. Such semantic data can also be provided by DNS replies in the form of RRs. The details are described in a companion draft. This use case may apply method 2 or 3. Some services may have other means of being encapsulated into a packet (e.g., an IPv6 extension header). The required information can also be returned by a DNS reply as semantic data.

TBD

This document requires no IANA actions.

The comments and suggestions of the following are gratefully acknowledged: TBD