]> Google LLC

1600 Amphitheatre Parkway Mountain View CA 94043 United States of America dschinazi.ietf@gmail.com

Web and Internet Transport MASQUE quic http datagram udp proxy tunnels quic in quic turtles all the way down masque http-ng dns 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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 (e.g., ). This document describes an extension that exchanges this information using HTTP capsules (). This document does not define any new ways to convey DNS queries or responses, only a mechanism to exchange DNS configuration information.

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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from . Where this document defines protocol types, the definition format uses the notation from . This specification uses the variable-length integer encoding from . Variable-length integer values do not need to be encoded in the minimum number of bytes necessary.

Mechanism Similar to how Proxying IP in HTTP exchanges IP address configuration information (), 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.

Nameserver Format

Each Nameserver structure contains the following fields:

Type:

An integer representing the protocol over which DNS queries and responses are sent. See below for possible values. Encoded as a variable-length integer.

Length:

The length of the following Value field, encoded as a variable-length integer.

Value:

DNS name server configuration value, depends on the Type. This is commonly an IP address, but for other protocols it can also represent a URI template or a hostname.

This document defines the following types:

• DNS over port 53. Type = 0. DNS is sent unencrypted over UDP or TCP port 53, as per . The Value is an IP address (either IPv4 or IPv6) encoded in network byte order. Length SHALL be either 32 or 128 bits.
• DNS over TLS. Type = 1. DNS is sent over TLS, as per . The Value is a hostname, optionally followed by a colon and a port. The encoding is the same as an authority without userinfo as defined in . It is encoded as ASCII, and not null-terminated. IPv4 and IPv6 addresses can be encoded using this format, though IPv6 addresses need to be enclosed in square brackets.
• DNS over QUIC. Type = 2. DNS is sent over QUIC, as per . The Value is a hostname, encoded the same as for DNS over TLS.
• DNS over HTTPS. Type = 3. DNS is sent over HTTPS, as per . The Value is a URI Template. It is encoded as ASCII, and not null-terminated.
• TODO: properly define an IANA registry with GREASE for future types.

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 ().

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 DNS name servers.

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 DNS 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.

DNS_REQUEST Capsule The DNS_REQUEST capsule (see 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 name servers or domain names in its request DNS Configuration.

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 ). 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.

DNS_ASSIGN Capsule The DNS_ASSIGN capsule (see for the value of the capsule type) allows an endpoint to send DNS configuration to its peer.

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.

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 name servers exchanged in the same DNS configuration. Sending an empty string as an internal domain indicates the DNS root; i.e., that the corresponding name server 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 server and apply received DNS configuration, whereas servers will ignore any DNS configuration sent by the client. If the IP proxy sends a DNS_ASSIGN capsule containing a DNS over HTTPS name server, then the client can validate whether the IP proxy is authoritative for the hostname in the URI template. If this validation succeeds, the client SHOULD send its DNS queries to that name server directly as independent HTTPS requests over the same HTTPS connection.

Examples

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.

Full Tunnel Example

Split-Tunnel Enterprise VPN An enterprise switching their preexisting IPsec split-tunnel VPN could use the following configuration.

Split Tunnel Example

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. 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.

IANA Considerations This document, if approved, will request IANA add the following values to the "HTTP Capsule Types" registry maintained at <>. New Capsules

Value	Capsule Type
0x1460B736	DNS_ASSIGN
0x1460B737	DNS_REQUEST

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

References Normative References This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] Informative References This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations.

Acknowledgments The mechanism is this document was inspired by and .