| Internet-Draft | Network-Aware DNS | September 2023 |
| Song & Eastlake | Expires 14 March 2024 | [Page] |
This document describes a framework which extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 March 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Different application flows have different requirements on networking, such as bandwidth, delay, jitter, reliability, security, and so on. Many 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") instead of the actual measures for networks 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 how to do about them. On the other hand, due to the limitation of the commonly available network socket API, it is also difficult for applications to convey their service requirements to networks. Currently, if any service beyond "best effort" is desired, one either assumes the requirements can be expressed to network controllers through some out-of-band manner or resorts to encoding the requirements into the packets (e.g., options in IPv6 extension headers network tokens [I-D.yiakoumis-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 to network services can be incorporated into DNS queries from a host (e.g., as specified in [I-D.eastlake-dnsop-expressing-qos-requirements]) and the returned information enables access to services meeting those requirements. For example, by including new semantics representing a service commitment embedded in the returned IP addresses (i.e., semantic addressing [I-D.farrel-irtf-introduction-to-semantic-routing]).¶
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 data that help construct the packet header or headers signaling the special packet handling in networks. The application flow packets will use the existing socket API to send the packet. 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 on 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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The architecture of the Network Aware DNS is shown in Figure 1.¶
+----------+ +----------+
| | 1.registration | Network |
| DNS |<---------------+ Operator |
| | | |
+------+---+ +----+-----+
^ | 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
+----------+ +----------+
We enforce some requirements on the architecture to make it practical for incremental deployment.¶
In a more dynamic architecture, DNS queries with service requirements can be dynamically sent to the network operator when received by a resolver, allowing 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 have three methods to obtain information from the DNS to enable the application to meet its service requirements. These methods are as follows:¶
This architecture can support multiple use cases using one of the above methods. Below are some examples.¶
This document requires no IANA actions.¶
The comments and suggestions of the following are gratefully acknowledged:¶