Demultiplexing Streamed DNS from HTTP/1.x
draft-dkg-dprive-demux-dns-http-03
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Daniel Kahn Gillmor | ||
| Last updated | 2017-11-18 (Latest revision 2017-05-17) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
DNS over TCP and HTTP/1.x are both stream-oriented, client-speaks- first protocols. They can both be run over a stream-based security protocol like TLS. A server accepting a stream-based client can distinguish between a valid stream of DNS queries and valid stream of HTTP/1.x requests by simple observation of the first few octets sent by the client. This can be done without any external demultiplexing mechanism like TCP port number or ALPN. Implicit multiplexing of the two protocols over a single listening port can be useful for obscuring the presence of DNS queries from a network observer, which makes it relevant for DNS privacy. Widespread adoption of the described approach could constrain evolution of the stream-based variants of both DNS ([RFC1035]) and HTTP/1.x ([RFC7230]) by ossifying existing distinguishing bit patterns in early octets sent by the client. However, this draft explicitly rules out multiplexing in this form with HTTP/2, so it should place no constraints on it or any higher version of HTTP.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)