RTGWG F. Yang Internet-Draft China Mobile Intended status: Standards Track 12 December 2025 Expires: 15 June 2026 DNS driven traffic steering draft-yang-rtgwg-dns-driven-traffic-steering-00 Abstract The Internet provides best-effort service, and for users with quality assurance requirements, selecting an Internet acceleration service provider to gareentee network access quality is a common choice. This document proposes a possible mechanism for leveraging DNS to automatically steer application’s traffic onto an SRv6 network. Status of This Memo 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 15 June 2026. Copyright Notice Copyright (c) 2025 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. Yang Expires 15 June 2026 [Page 1] Internet-Draft DNS driven traffic steering December 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. DNS driven traffic steering . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Internet provides best-effort service, and for users with quality assurance requirements, selecting an ISAP (Internet Acceleration Service Provider) to gareentee network access quality is a common choice. This document proposes a possible mechanism for leveraging DNS to automatically steer application’s traffic onto an SRv6 network. As shown in Figure 1, IASPs typically deploy an Overlay network plane to accelerate user traffic. This network plane consists of PoPs (Points of Presence) and routers, where PoPs are responsible for accessing user traffic and connecting to CSPs (Content Service Provider). Routers and PoPs are usually virtualized devices deployed in the cloud. Typically, when SRv6 is deployed in this network plane for path programming, ACLs are required to classify user traffic and steer it onto SRv6 Policies. Due to the need for extensive ACLs configuration manually, it is quite challenging to apply this approach on a large scale. Thus, how to efficiently steer user traffic becomes an interesting problem. 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. Terminology CSP: Content Service Provider, provides content-related services, e.g. gaming, video services. Yang Expires 15 June 2026 [Page 2] Internet-Draft DNS driven traffic steering December 2025 IASP: Internet Acceleration Service Provider, provides gareenteed internet network access quality for latency, loss sensitive applications, e.g. gaming、video services. PoP: Points of Presence, network forwarding element in order to accessing user traffic or exchange traffic with internet service provider. 3. DNS driven traffic steering On IASP perspective, the SRv6 Policy is defined by . To achieve differentiated transport, it is necessary to map applications to the corresponding SRv6 Policy. On user application perspective, the first interaction with network would be DNS request, which will finally resolve the domain name to destination address. The idea is to get IASP’s network snoop the user DNS interaction process in order to steer the user’s traffic with that destination to IASP’s network. Thereby achieving network quality of service assurance. Certainly, the IASP needs to configure the mapping between domain names and SRv6 policy colors on the controller in advance. Figure 1 illustrates the necessary network components. User: DNS server SHOULD be set to IASP’s uPoP. uPoP: For accessing user. It is endpoint of SRv6 policy. DNS relay is needed. It SHOULD check whether the domain name in the DNS request from application is subscribed by the user. Then it SHOULD relay the DNS request to DNS proxy. cPoP: For connecting to CSP. It is endpoint of SRv6 policy. It will enable NAT for user traffic to ensure that the downstream traffic passes through the cPoP. DNS Proxy: it will handle the DNS resolution from uPoP. There is one extension for DNS proxy. Once the domain name gets resolved, it SHOULD send domain name, destination address of DNS response packet and application destination address list inside the DNS response packet to controller via DNS-response notification. The DNS-response notification DNS proxy sent to the controller can be defined by json, xml. Below is json example: Yang Expires 15 June 2026 [Page 3] Internet-Draft DNS driven traffic steering December 2025 { "message": { "application_destinations": [addr1, addr2], "dns_response_destination": "addr3", "domain_name": "example.com" } } Controller: once received DNS-response notification, it will resolve and then get the corrsponding SRv6 policy programmed to uPoP. The source is destination address of DNS response packet in the notification, because it is the address of the uPoP. The ISAP definitely knows the CSP’s domain name and service addresses. So the cPoP connected to the CSP can be resolved by looking up application destination address. The application destinations and the DNS response destination address can be used in ACL in upstream and downstream SRv6 policy steering direction, respectively. Now it is ready to find or create an existing SRv6 policy. And then program the steering rule to cPoP and uPoP. For sure, the ACL on both PoPs SHOULD count the number of packets it has been steered, and that can be used as ACL aging mechanism. Note, with this proposed mechanism, there will be a short period of time for the steering ACL policies get programmed. In this period, the IASP will only provide best effort service. +-----------+ +----------+ | DNS Proxy |-------|Controller| +-----------+ +----------+ | +-------------------------------------------+ | +-----+ | | /|Rtr3 |\ | | / +-----+ \ | | / \ | +------+ | +-----+ +-----+ +-----+ +-----+ | +---------+ | APP |-|-|uPoP |---|Rtr1 |-------|Rtr2 |---|cPoP |-|-| CSP | +------+ | +-----+ +-----+ +-----+ +-----+ | +---------+ | SRv6 Domain | +-------------------------------------------+ Figure 1: Architecture 4. IANA Considerations This document has no IANA actions. Yang Expires 15 June 2026 [Page 4] Internet-Draft DNS driven traffic steering December 2025 5. Security Considerations The security requirements and mechanisms described in [RFC5625] also apply to this document. The DNS Proxy and the controller should be deployed within a protected data center. To minimize the impact of network attacks on the communication channel between the DNS Proxy and the controller, the DNS Proxy and the controller should not be interconnected via the Internet. The DNS response should be carefully validated in order to avoid DDoS attack. The falsified DNS response can carry long list of application destination. One mechanism is to record all of the active DNS reqeust on DNS proxy, and only send DNS-response notification to controller ony if the DNS request has been received by the DNS proxy. 6. References 6.1. Normative References [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, . Author's Address Feng Yang China Mobile China Yang Expires 15 June 2026 [Page 5] Internet-Draft DNS driven traffic steering December 2025 Email: yangfeng@chinamobile.com Yang Expires 15 June 2026 [Page 6]