rfc9230v3.txt   rfc9230.txt 
Independent Submission E. Kinnear Independent Submission E. Kinnear
Request for Comments: 9230 Apple Inc. Request for Comments: 9230 Apple Inc.
Category: Experimental P. McManus Category: Experimental P. McManus
ISSN: 2070-1721 Fastly ISSN: 2070-1721 Fastly
T. Pauly T. Pauly
Apple Inc. Apple Inc.
T. Verma T. Verma
C.A. Wood C.A. Wood
Cloudflare Cloudflare
April 2022 June 2022
Oblivious DNS over HTTPS Oblivious DNS over HTTPS
Abstract Abstract
This document describes a protocol that allows clients to hide their This document describes a protocol that allows clients to hide their
IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS
(DoH) messages. This improves privacy of DNS operations by not (DoH) messages. This improves privacy of DNS operations by not
allowing any one server entity to be aware of both the client IP allowing any one server entity to be aware of both the client IP
address and the content of DNS queries and answers. address and the content of DNS queries and answers.
skipping to change at line 296 skipping to change at line 296
<Bytes containing an encrypted Oblivious DNS query> <Bytes containing an encrypted Oblivious DNS query>
4.3. HTTP Response 4.3. HTTP Response
The response to an Oblivious DoH query is generated by the Target. The response to an Oblivious DoH query is generated by the Target.
It MUST set the Content-Type HTTP header to "application/oblivious- It MUST set the Content-Type HTTP header to "application/oblivious-
dns-message" for all successful responses. The body of the response dns-message" for all successful responses. The body of the response
contains an encrypted DNS message; see Section 6. contains an encrypted DNS message; see Section 6.
The response from a Target MUST set the Content-Type HTTP header to The response from a Target MUST set the Content-Type HTTP header to
"application/oblivious-dns-message", which MUST be forwarded by the "application/oblivious-dns-message", and that same type MUST be used
Proxy to the Client. A Client MUST only consider a response that on all successful responses sent by the Proxy to the Client. A
contains the Content-Type header before processing the payload. A Client MUST only consider a response that contains the Content-Type
response without the appropriate header MUST be treated as an error header before processing the payload. A response without the
and be handled appropriately. All other aspects of the HTTP response appropriate header MUST be treated as an error and be handled
and error handling are inherited from standard DoH. appropriately. All other aspects of the HTTP response and error
handling are inherited from standard DoH.
Proxies forward responses from the Target to the Client, without any Proxies forward responses from the Target to the Client, without any
modifications to the body or status code. The Proxy also SHOULD add modifications to the body or status code. The Proxy also SHOULD add
a Proxy-Status response header with a "received-status" parameter a Proxy-Status response header with a "received-status" parameter
indicating that the status code was generated by the Target. indicating that the status code was generated by the Target.
Note that if a Client receives a 3xx status code and chooses to Note that if a Client receives a 3xx status code and chooses to
follow a redirect, the subsequent request MUST also be performed follow a redirect, the subsequent request MUST also be performed
through a Proxy in order to avoid directly exposing requests to the through a Proxy in order to avoid directly exposing requests to the
Target. Target.
skipping to change at line 862 skipping to change at line 863
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>. October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP [RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
Response Header Field", RFC 9209, DOI 10.17487/RFC9209, Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
April 2022, <https://www.rfc-editor.org/info/rfc9209>. June 2022, <https://www.rfc-editor.org/info/rfc9209>.
13.2. Informative References 13.2. Informative References
[Dolev-Yao] [Dolev-Yao]
Dolev, D. and A. C. Yao, "On the Security of Public Key Dolev, D. and A. C. Yao, "On the Security of Public Key
Protocols", IEEE Transactions on Information Theory, Vol. Protocols", IEEE Transactions on Information Theory, Vol.
IT-29, No. 2, DOI 10.1109/TIT.1983.1056650, March 1983, IT-29, No. 2, DOI 10.1109/TIT.1983.1056650, March 1983,
<https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee- <https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee-
01056650.pdf>. 01056650.pdf>.
 End of changes. 3 change blocks. 
8 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/