MASQUE D. Schinazi Internet-Draft Google LLC Intended status: Standards Track 18 October 2024 Expires: 21 April 2025 DNS Configuration for Proxying IP in HTTP draft-ietf-masque-connect-ip-dns-01 Abstract Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information. This document describes an extension that exchanges this information using HTTP capsules. This mechanism supports encrypted DNS transports. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ietf-wg- masque.github.io/draft-ietf-masque-connect-ip-dns/draft-ietf-masque- connect-ip-dns.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-masque-connect- ip-dns/. Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (mailto:masque@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/masque/. Subscribe at https://www.ietf.org/mailman/listinfo/masque/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip-dns. 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/. Schinazi Expires 21 April 2025 [Page 1] Internet-Draft CONNECT-IP DNS October 2024 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 21 April 2025. Copyright Notice Copyright (c) 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Domain Structure . . . . . . . . . . . . . . . . . . . . 4 2.2. Nameserver Structure . . . . . . . . . . . . . . . . . . 4 2.3. DNS Configuration Structure . . . . . . . . . . . . . . . 6 2.4. DNS_REQUEST Capsule . . . . . . . . . . . . . . . . . . . 7 2.5. DNS_ASSIGN Capsule . . . . . . . . . . . . . . . . . . . 7 3. Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Full-Tunnel Consumer VPN . . . . . . . . . . . . . . . . 8 4.2. Split-Tunnel Enterprise VPN . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Schinazi Expires 21 April 2025 [Page 2] Internet-Draft CONNECT-IP DNS October 2024 1. Introduction Proxying IP in HTTP ([CONNECT-IP]) allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism doesn't offer a mechanism for communicating DNS configuration information inline. In contrast, most existing VPN protocols provide a mechanism to exchange DNS configuration information (e.g., [IKEv2]). This document describes an extension that exchanges this information using HTTP capsules ([HTTP-DGRAM]). This document does not define any new ways to convey DNS queries or responses, only a mechanism to exchange DNS configuration information. Note that this extension is meant for cases where connect-ip is used like a Remote Access VPN (see Section 8.1 of [CONNECT-IP]), but not for cases like IP Flow Forwarding (see Section 8.3 of [CONNECT-IP]). This specification uses Service Bindings ([SVCB]) to exchange information about nameservers, such as which encrypted DNS transport is supported. This allows support for DNS over HTTPS ([DoH]), DNS over QUIC ([DoQ]), DNS over TLS ([DoT]), unencrypted DNS over UDP port 53 ([DNS]), and potential future DNS transports. 1.1. Conventions and Definitions 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. This document uses terminology from [QUIC]. Where this document defines protocol types, the definition format uses the notation from Section 1.3 of [QUIC]. This specification uses the variable-length integer encoding from Section 16 of [QUIC]. Variable-length integer values do not need to be encoded in the minimum number of bytes necessary. In this document, we use the term "nameserver" to refer to a DNS recursive resolver as defined in Section 6 of [DNS-TERMS], and the term "domain name" is used as defined in Section 2 of [DNS-TERMS]. Schinazi Expires 21 April 2025 [Page 3] Internet-Draft CONNECT-IP DNS October 2024 2. Mechanism Similar to how Proxying IP in HTTP exchanges IP address configuration information (Section 4.7 of [CONNECT-IP]), this mechanism leverages capsules to request DNS configuration information and to assign it. Similarly, this mechanism is bidirectional: either endpoint can request DNS configuration information by sending a DNS_REQUEST capsule, and either endpoint can send DNS configuration information in a DNS_ASSIGN capsule. These capsules follow the format defined below. 2.1. Domain Structure Domain { Domain Length (i), Domain Name (..), } Figure 1: Internal Domain Format Each Domain contains the following fields: Domain Length: Length of the following Domain field, encoded as a variable-length integer. Domain Name: Fully Qualified Domain Name in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label ([IDNA]). 2.2. Nameserver Structure Nameserver { Service Priority (16), IPv4 Address Count (i), IPv4 Address (32) ..., IPv6 Address Count (i), IPv6 Address (128) ..., Nameserver Domain (..), Service Parameters Length (i), Service Parameters (..), } Figure 2: Nameserver Format Each Nameserver structure contains the following fields: Service Priority: The priority of this attribute compared to other Schinazi Expires 21 April 2025 [Page 4] Internet-Draft CONNECT-IP DNS October 2024 nameservers, as specified in Section 2.4.1 of [SVCB]. Since this specification relies on using Service Bindings in ServiceMode (Section 2.4.3 of [SVCB]), this field MUST NOT be set to 0. IPv4 Address Count: The number of IPv4 Address fields following this field. Encoded as a variable-length integer. IPv4 Address: Sequence of IPv4 Addresses that can be used to reach this nameserver. Encoded in network byte order. IPv6 Address Count: The number of IPv6 Address fields following this field. Encoded as a variable-length integer. IPv6 Address: Sequence of IPv6 Addresses that can be used to reach this nameserver. Encoded in network byte order. Nameserver Domain: A Domain structure (see Section 2.2) representing the domain name of the nameserver. This MAY be empty if the nameserver only supports unencrypted DNS (as traditionally sent over UDP port 53). Service Parameters Length: Length of the following Service Parameters field, encoded as a variable-length integer. Service Parameters: Set of service parameters that apply to this nameserver. Encoded using the wire format specified in Section 2.2 of [SVCB]. Service parameters allow exchanging additional information about the nameserver: * The "port" service parameter is used to indicate which port the nameserver is reachable on. If no "port" service parameter is included, this indicates that default port numbers should be used. * The "alpn" service parameter is used to indicate which encrypted DNS transports are supported by this nameserver. If the "no- default-alpn" service parameter is omitted, that indicates that the nameserver supports unencrypted DNS, as is traditionally sent over UDP port 53. In that case, the sum of IPv4 Address Count and IPv6 Address Count MUST be nonzero. If Nameserver Domain is empty, the "alpn" and "no-default-alpn" service parameter MUST be omitted. * The "dohpath" service parameter is used to convey a relative DNS over HTTPS URI Template, see Section 5 of [SVCB-DNS]. Schinazi Expires 21 April 2025 [Page 5] Internet-Draft CONNECT-IP DNS October 2024 * The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams, as they are superseded by the included IP addresses. 2.3. DNS Configuration Structure DNS Configuration { Request ID (i), Nameserver Count (i), Nameserver (..) ..., Internal Domain Count (i), Internal Domain (..) ..., Search Domain Count (i), Search Domain (..) ..., } Figure 3: Assigned Address Format Each DNS Configuration contains the following fields: Request ID: Request identifier, encoded as a variable-length integer. If this DNS Configuration is part of a request, then this contains a unique request identifier. If this DNS configuration is part of an assignment that is in response to a DNS configuration request then this field SHALL contain the value of the corresponding field in the request. If this DNS configuration is part of an unsolicited assignment, this field SHALL be zero. Nameserver Count: The number of Nameserver structures following this field. Encoded as a variable-length integer. Nameserver: A series of Nameserver structures representing nameservers. Internal Domain Count: The number of Domain structures following this field. Encoded as a variable-length integer. Internal Domain: A series of Domain structures representing internal domain names. Search Domain Count: The number of Domain structures following this field. Encoded as a variable-length integer. Search Domain: A series of Domain structures representing search domains. Schinazi Expires 21 April 2025 [Page 6] Internet-Draft CONNECT-IP DNS October 2024 2.4. DNS_REQUEST Capsule The DNS_REQUEST capsule (see Section 6 for the value of the capsule type) allows an endpoint to request DNS configuration from its peer. The capsule allows the endpoint to optionally indicate a preference for which DNS configuration it would get assigned. The sender can indicate that it has no preference by not sending any nameservers or domain names in its request DNS Configuration. DNS_REQUEST Capsule { Type (i) = DNS_REQUEST, Length (i), DNS Configuration (..), } Figure 4: DNS_REQUEST Capsule Format When sending a DNS_REQUEST capsule, the sender MUST generate and send a new non-zero request ID that was not previously used on this IP Proxying stream. Note that this request ID namespace is distinct from the one used by ADDRESS_ASSIGN capsules (see Section 4.7.1 of [CONNECT-IP]). An endpoint that receives a DNS_REQUEST capsule SHALL reply by sending a DNS_ASSIGN capsule with the corresponding request ID. That DNS_ASSIGN capsule MAY be empty, that indicates that its sender has no DNS configuration to share with its peer. 2.5. DNS_ASSIGN Capsule The DNS_ASSIGN capsule (see Section 6 for the value of the capsule type) allows an endpoint to send DNS configuration to its peer. DNS_ASSIGN Capsule { Type (i) = DNS_ASSIGN, Length (i), DNS Configuration (..), } Figure 5: DNS_ASSIGN Capsule Format When sending a DNS_ASSIGN capsule in response to a received DNS_REQUEST capsule, the Request ID field in the DNS_ASSIGN capsule SHALL be set to the value in the received DNS_REQUEST capsule. Otherwise the request ID MUST be set to zero. Schinazi Expires 21 April 2025 [Page 7] Internet-Draft CONNECT-IP DNS October 2024 3. Handling Note that internal domains include subdomains. In other words, if the DNS configuration contains a domain, that indicates that the corresponding domain and all of its subdomains can be resolved by the nameservers exchanged in the same DNS configuration. Sending an empty string as an internal domain indicates the DNS root; i.e., that the corresponding nameserver can resolve all domain names. As with other IP Proxying capsules, the receiver can decide whether to use or ignore the configuration information. For example, in the consumer VPN scenario, clients will trust the IP proxy and apply received DNS configuration, whereas IP proxies will ignore any DNS configuration sent by the client. If the IP proxy sends a DNS_ASSIGN capsule containing a DNS over HTTPS nameserver, then the client can validate whether the IP proxy is authoritative for the origin of the URI template. If this validation succeeds, the client SHOULD send its DNS queries to that nameserver directly as independent HTTPS requests. When possible, those requests SHOULD be coalesced over the same HTTPS connection. 4. Examples 4.1. Full-Tunnel Consumer VPN A full-tunnel consumer VPN hosted at masque.example could configure the client to use DNS over HTTPS to the IP proxy itself by sending the following configuration. DNS Configuration = { Nameservers = [{ Service Priority = 1, IPv4 Address = [], IPv6 Address = [], Nameserver Domain = "masque.example", Service Parameters = { alpn=h2,h3 dohpath=/dns-query{?dns} }, }], Internal Domains = [""], Search Domains = [], } Figure 6: Full Tunnel Example Schinazi Expires 21 April 2025 [Page 8] Internet-Draft CONNECT-IP DNS October 2024 4.2. Split-Tunnel Enterprise VPN An enterprise switching their preexisting IKEv2/IPsec split-tunnel VPN to connect-ip could use the following configuration. DNS Configuration = { Nameservers = [{ Service Priority = 1, IPv4 Address = [192.0.2.33], IPv6 Address = [2001:db8::1], Nameserver Domain = "", Service Parameters = {}, }], Internal Domains = ["internal.corp.example"], Search Domains = [ "internal.corp.example", "corp.example", ], } Figure 7: Split Tunnel Example 5. Security Considerations Acting on received DNS_ASSIGN capsules can have significant impact on endpoint security. Endpoints MUST ignore DNS_ASSIGN capsules unless it has reason to trust its peer and is expecting DNS configuration from it. This mechanism can cause an endpoint to use a nameserver that is outside of the connect-ip tunnel. While this is acceptable in some scenarios, in others it could break the privacy properties provided by the tunnel. To avoid this, implementations need to ensure that DNS_ASSIGN capsules are not sent before the corresponding ROUTE_ADVERTISEMENT capsule. The requirement for an endpoint to always send DNS_ASSIGN capsules in response to DNS_REQUEST capsules could lead it to buffer unbounded amounts of memory if the underlying stream is blocked by flow or congestion control. Implementations MUST place an upper bound on that buffering and abort the stream if that limit is reached. 6. IANA Considerations This document, if approved, will request IANA add the following values to the "HTTP Capsule Types" registry maintained at . Schinazi Expires 21 April 2025 [Page 9] Internet-Draft CONNECT-IP DNS October 2024 +===========+==============+ | Value | Capsule Type | +===========+==============+ | 0x818F79E | DNS_ASSIGN | +-----------+--------------+ | 0x818F79F | DNS_REQUEST | +-----------+--------------+ Table 1: New Capsules Note that, if this document is approved, the values defined above will be replaced by smaller ones before publication. All of these new entries use the following values for these fields: Status: provisional (permanent if this document is approved) Reference: This document Change Controller: IETF Contact: masque@ietf.org Notes: None 7. References 7.1. Normative References [CONNECT-IP] Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A., Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP", RFC 9484, DOI 10.17487/RFC9484, October 2023, . [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [DNS-TERMS] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [DoQ] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . Schinazi Expires 21 April 2025 [Page 10] Internet-Draft CONNECT-IP DNS October 2024 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [HTTP-DGRAM] Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, . [IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [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, . [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [SVCB-DNS] Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, . 7.2. Informative References [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . Schinazi Expires 21 April 2025 [Page 11] Internet-Draft CONNECT-IP DNS October 2024 [IKEv2-DNS] Pauly, T. and P. Wouters, "Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8598, DOI 10.17487/RFC8598, May 2019, . [IKEv2-SVCB] Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov, "Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS", RFC 9464, DOI 10.17487/RFC9464, November 2023, . Acknowledgments The mechanism in this document was inspired by [IKEv2], [IKEv2-DNS], and [IKEv2-SVCB]. The author would like to thank Alex Chernyakhovsky, Tommy Pauly, and other enthusiasts in the MASQUE Working Group for their contributions. Author's Address David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: dschinazi.ietf@gmail.com Schinazi Expires 21 April 2025 [Page 12]