RFC 8490
DNS Stateful Operations
8. Summary Highlights
This section summarizes some noteworthy highlights about various aspects of the DSO protocol.8.1. QR Bit and MESSAGE ID
In DSO request messages, the QR bit is 0 and the MESSAGE ID is nonzero. In DSO response messages, the QR bit is 1 and the MESSAGE ID is nonzero. In DSO unidirectional messages, the QR bit is 0 and the MESSAGE ID is zero. The table below illustrates which combinations are legal and how they are interpreted: +------------------------------+------------------------+ | MESSAGE ID zero | MESSAGE ID nonzero | +--------+------------------------------+------------------------+ | QR=0 | DSO unidirectional message | DSO request message | +--------+------------------------------+------------------------+ | QR=1 | Invalid - Fatal Error | DSO response message | +--------+------------------------------+------------------------+
8.2. TLV Usage
The table below indicates, for each of the three TLVs defined in this document, whether they are valid in each of ten different contexts. The first five contexts are DSO requests or DSO unidirectional messages from client to server, and the corresponding responses from server back to client: o C-P - Primary TLV, sent in DSO request message, from client to server, with nonzero MESSAGE ID indicating that this request MUST generate response message. o C-U - Primary TLV, sent in DSO unidirectional message, from client to server, with zero MESSAGE ID indicating that this request MUST NOT generate response message. o C-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from client to server. o CRP - Response Primary TLV, included in response message sent back to the client (in response to a client "C-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO- TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV in the request. o CRA - Response Additional TLV, included in response message sent back to the client (in response to a client "C-P" request with nonzero MESSAGE ID indicating that a response is required) where the DSO-TYPE of the Response TLV does not match the DSO-TYPE of the Primary TLV in the request. The second five contexts are their counterparts in the opposite direction: DSO requests or DSO unidirectional messages from server to client, and the corresponding responses from client back to server. o S-P - Primary TLV, sent in DSO request message, from server to client, with nonzero MESSAGE ID indicating that this request MUST generate response message. o S-U - Primary TLV, sent in DSO unidirectional message, from server to client, with zero MESSAGE ID indicating that this request MUST NOT generate response message. o S-A - Additional TLV, optionally added to a DSO request message or DSO unidirectional message from server to client.
o SRP - Response Primary TLV, included in response message sent back
to the server (in response to a server "S-P" request with nonzero
MESSAGE ID indicating that a response is required) where the DSO-
TYPE of the Response TLV matches the DSO-TYPE of the Primary TLV
in the request.
o SRA - Response Additional TLV, included in response message sent
back to the server (in response to a server "S-P" request with
nonzero MESSAGE ID indicating that a response is required) where
the DSO-TYPE of the Response TLV does not match the DSO-TYPE of
the Primary TLV in the request.
+-------------------------+-------------------------+
| C-P C-U C-A CRP CRA | S-P S-U S-A SRP SRA |
+------------+-------------------------+-------------------------+
| KeepAlive | X X | X |
+------------+-------------------------+-------------------------+
| RetryDelay | X | X X |
+------------+-------------------------+-------------------------+
| Padding | X X | X X |
+------------+-------------------------+-------------------------+
Note that some of the columns in this table are currently empty. The
table provides a template for future TLV definitions to follow. It
is recommended that definitions of future TLVs include a similar
table summarizing the contexts where the new TLV is valid.
9. Additional Considerations
9.1. Service Instances
We use the term "service instance" to refer to software running on a host that can receive connections on some set of { IP address, port } tuples. What makes the software an instance is that regardless of which of these tuples the client uses to connect to it, the client is connected to the same software, running on the same logical node (see Section 9.2), and will receive the same answers and the same keying information. Service instances are identified from the perspective of the client. If the client is configured with { IP address, port } tuples, it has no way to tell if the service offered at one tuple is the same server that is listening on a different tuple. So in this case, the client treats each different tuple as if it references a different service instance. In some cases, a client is configured with a hostname and a port number. The port number may be given explicitly, along with the hostname. The port number may be omitted, and assumed to have some default value. The hostname and a port number may be learned from the network, as in the case of DNS SRV records. In these cases, the { hostname, port } tuple uniquely identifies the service instance, subject to the usual case-insensitive DNS comparison of names [RFC1034]. It is possible that two hostnames might point to some common IP addresses; this is a configuration anomaly that the client is not obliged to detect. The effect of this could be that after being told to disconnect, the client might reconnect to the same server because it is represented as a different service instance. Implementations SHOULD NOT resolve hostnames and then perform the process of matching IP address(es) in order to evaluate whether two entities should be determined to be the "same service instance".
9.2. Anycast Considerations
When an anycast service is configured on a particular IP address and port, it must be the case that although there is more than one physical server responding on that IP address, each such server can be treated as equivalent. What we mean by "equivalent" here is that both servers can provide the same service and, where appropriate, the same authentication information, such as PKI certificates, when establishing connections. If a change in network topology causes packets in a particular TCP connection to be sent to an anycast server instance that does not know about the connection, the new server will automatically terminate the connection with a TCP reset, since it will have no record of the connection, and then the client can reconnect or stop using the connection as appropriate. If, after the connection is re-established, the client's assumption that it is connected to the same instance is violated in some way, that would be considered an incorrect behavior in this context. It is, however, out of the possible scope for this specification to make specific recommendations in this regard; that would be up to follow- on documents that describe specific uses of DNS Stateful Operations.
9.3. Connection Sharing
As previously specified for DNS-over-TCP [RFC7766]: To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top of TCP (for example, if the resolver was using TLS). However, it is noted that certain primary/secondary configurations with many busy zones might need to use more than one TCP connection for zone transfers for operational reasons (for example, to support concurrent transfers of multiple zones). A single server may support multiple services, including DNS Updates [RFC2136], DNS Push Notifications [Push], and other services, for one or more DNS zones. When a client discovers that the target server for several different operations is the same service instance (see Section 9.1), the client SHOULD use a single shared DSO Session for all those operations. This requirement has two benefits. First, it reduces unnecessary connection load on the DNS server. Second, it avoids the connection startup time that would be spent establishing each new additional connection to the same DNS server. However, server implementers and operators should be aware that connection sharing may not be possible in all cases. A single host device may be home to multiple independent client software instances that don't coordinate with each other. Similarly, multiple independent client devices behind the same NAT gateway will also typically appear to the DNS server as different source ports on the same client IP address. Because of these constraints, a DNS server MUST be prepared to accept multiple connections from different source ports on the same client IP address.
9.4. Operational Considerations for Middleboxes
Where an application-layer middlebox (e.g., a DNS proxy, forwarder, or session multiplexer) is in the path, care must be taken to avoid a configuration in which DSO traffic is mishandled. The simplest way to avoid such problems is to avoid using middleboxes. When this is not possible, middleboxes should be evaluated to make sure that they behave correctly. Correct behavior for middleboxes consists of one of the following: o The middlebox does not forward DSO messages and responds to DSO messages with a response code other than NOERROR or DSOTYPENI. o The middlebox acts as a DSO server and follows this specification in establishing connections. o There is a 1:1 correspondence between incoming and outgoing connections such that when a connection is established to the middlebox, it is guaranteed that exactly one corresponding connection will be established from the middlebox to some DNS resolver, and all incoming messages will be forwarded without modification or reordering. An example of this would be a NAT forwarder or TCP connection optimizer (e.g., for a high-latency connection such as a geosynchronous satellite link). Middleboxes that do not meet one of the above criteria are very likely to fail in unexpected and difficult-to-diagnose ways. For example, a DNS load balancer might unbundle DNS messages from the incoming TCP stream and forward each message from the stream to a different DNS server. If such a load balancer is in use, and the DNS servers it points to implement DSO and are configured to enable DSO, DSO Session establishment will succeed, but no coherent session will exist between the client and the server. If such a load balancer is pointed at a DNS server that does not implement DSO or is configured not to allow DSO, no such problem will exist, but such a configuration risks unexpected failure if new server software is installed that does implement DSO. It is of course possible to implement a middlebox that properly supports DSO. It is even possible to implement one that implements DSO with long-lived operations. This can be done either by maintaining a 1:1 correspondence between incoming and outgoing connections, as mentioned above, or by terminating incoming sessions at the middlebox but maintaining state in the middlebox about any long-lived operations that are requested. Specifying this in detail is beyond the scope of this document.
9.5. TCP Delayed Acknowledgement Considerations
Most modern implementations of the Transmission Control Protocol (TCP) include a feature called "Delayed Acknowledgement" [RFC1122]. Without this feature, TCP can be very wasteful on the network. For illustration, consider a simple example like remote login using a very simple TCP implementation that lacks delayed acks. When the user types a keystroke, a data packet is sent. When the data packet arrives at the server, the simple TCP implementation sends an immediate acknowledgement. Mere milliseconds later, the server process reads the one byte of keystroke data, and consequently the simple TCP implementation sends an immediate window update. Mere milliseconds later, the server process generates the character echo and sends this data back in reply. The simple TCP implementation then sends this data packet immediately too. In this case, this simple TCP implementation sends a burst of three packets almost instantaneously (ack, window update, data). Clearly it would be more efficient if the TCP implementation were to combine the three separate packets into one, and this is what the delayed ack feature enables. With delayed ack, the TCP implementation waits after receiving a data packet, typically for 200 ms, and then sends its ack if (a) more data packet(s) arrive, (b) the receiving process generates some reply data, or (c) 200 ms elapse without either of the above occurring. With delayed ack, remote login becomes much more efficient, generating just one packet instead of three for each character echo. The logic of delayed ack is that the 200 ms delay cannot do any significant harm. If something at the other end were waiting for something, then the receiving process should generate the reply that the thing at the other end is waiting for, and TCP will then immediately send that reply (combined with the ack and window update). And if the receiving process does not in fact generate any reply for this particular message, then by definition the thing at the other end cannot be waiting for anything. Therefore, the 200 ms delay is harmless. This assumption may be true unless the sender is using Nagle's algorithm, a similar efficiency feature, created to protect the network from poorly written client software that performs many rapid small writes in succession. Nagle's algorithm allows these small writes to be coalesced into larger, less wasteful packets.
Unfortunately, Nagle's algorithm and delayed ack, two valuable efficiency features, can interact badly with each other when used together [NagleDA]. DSO request messages elicit responses; DSO unidirectional messages and DSO response messages do not. For DSO request messages, which do elicit responses, Nagle's algorithm and delayed ack work as intended. For DSO messages that do not elicit responses, the delayed ack mechanism causes the ack to be delayed by 200 ms. The 200 ms delay on the ack can in turn cause Nagle's algorithm to prevent the sender from sending any more data for 200 ms until the awaited ack arrives. On an enterprise Gigabit Ethernet (GigE) backbone with sub- millisecond round-trip times, a 200 ms delay is enormous in comparison. When this issues is raised, there are two solutions that are often offered, neither of them ideal: 1. Disable delayed ack. For DSO messages that elicit no response, removing delayed ack avoids the needless 200 ms delay and sends back an immediate ack that tells Nagle's algorithm that it should immediately grant the sender permission to send its next packet. Unfortunately, for DSO messages that *do* elicit a response, removing delayed ack removes the efficiency gains of combining acks with data, and the responder will now send two or three packets instead of one. 2. Disable Nagle's algorithm. When acks are delayed by the delayed ack algorithm, removing Nagle's algorithm prevents the sender from being blocked from sending its next small packet immediately. Unfortunately, on a network with a higher round- trip time, removing Nagle's algorithm removes the efficiency gains of combining multiple small packets into fewer larger ones, with the goal of limiting the number of small packets in flight at any one time. The problem here is that with DSO messages that elicit no response, the TCP implementation is stuck waiting, unsure if a response is about to be generated or whether the TCP implementation should go ahead and send an ack and window update. The solution is networking APIs that allow the receiver to inform the TCP implementation that a received message has been read, processed, and no response for this message will be generated. TCP can then
stop waiting for a response that will never come, and immediately go ahead and send an ack and window update. For implementations of DSO, disabling delayed ack is NOT RECOMMENDED because of the harm this can do to the network. For implementations of DSO, disabling Nagle's algorithm is NOT RECOMMENDED because of the harm this can do to the network. At the time that this document is being prepared for publication, it is known that at least one TCP implementation provides the ability for the recipient of a TCP message to signal that it is not going to send a response, and hence the delayed ack mechanism can stop waiting. Implementations on operating systems where this feature is available SHOULD make use of it.
10. IANA Considerations
10.1. DSO OPCODE Registration
The IANA has assigned the value 6 for DNS Stateful Operations (DSO) in the "DNS OpCodes" registry.10.2. DSO RCODE Registration
IANA has assigned the value 11 for the DSOTYPENI error code in the "DNS RCODEs" registry. The DSOTYPENI error code ("DSO-TYPE Not Implemented") indicates that the receiver does implement DNS Stateful Operations, but does not implement the specific DSO-TYPE of the Primary TLV in the DSO request message.10.3. DSO Type Code Registry
The IANA has created the 16-bit "DSO Type Codes" registry, with initial (hexadecimal) values as shown below: +-----------+-----------------------+-------+-----------+-----------+ | Type | Name | Early | Status | Reference | | | | Data | | | +-----------+-----------------------+-------+-----------+-----------+ | 0000 | Reserved | NO | Standards | RFC 8490 | | | | | Track | | | | | | | | | 0001 | KeepAlive | OK | Standards | RFC 8490 | | | | | Track | | | | | | | | | 0002 | RetryDelay | NO | Standards | RFC 8490 | | | | | Track | | | | | | | | | 0003 | EncryptionPadding | NA | Standards | RFC 8490 | | | | | Track | | | | | | | | | 0004-003F | Unassigned, reserved | NO | | | | | for DSO session- | | | | | | management TLVs | | | | | | | | | | | 0040-F7FF | Unassigned | NO | | | | | | | | | | F800-FBFF | Experimental/local | NO | | | | | use | | | | | | | | | | | FC00-FFFF | Reserved for future | NO | | | | | expansion | | | | +-----------+-----------------------+-------+-----------+-----------+
The meanings of the fields are as follows:
Type: The 16-bit DSO type code.
Name: The human-readable name of the TLV.
Early Data: If OK, this TLV may be sent as early data in a TLS zero
round-trip (Section 2.3 of the TLS 1.3 specification [RFC8446])
initial handshake. If NA, the TLV may appear as an Additional TLV
in a DSO message that is sent as early data.
Status: RFC status (e.g., "Standards Track") or "External" if not
documented in an RFC.
Reference: A stable reference to the document in which this TLV is
defined.
Note: DSO Type Code zero is reserved and is not currently intended
for allocation.
Registrations of new DSO Type Codes in the "Reserved for DSO session-
management" range 0004-003F and the "Reserved for future expansion"
range FC00-FFFF require publication of an IETF Standards Action
document [RFC8126].
Requests to register additional new DSO Type Codes in the
"Unassigned" range 0040-F7FF are to be recorded by IANA after Expert
Review [RFC8126]. The expert review should validate that the
requested type code is specified in a way that conforms to this
specification, and that the intended use for the code would not be
addressed with an experimental/local assignment.
DSO Type Codes in the "experimental/local" range F800-FBFF may be
used as Experimental Use or Private Use values [RFC8126] and may be
used freely for development purposes or for other purposes within a
single site. No attempt is made to prevent multiple sites from using
the same value in different (and incompatible) ways. There is no
need for IANA to review such assignments (since IANA does not record
them) and assignments are not generally useful for broad
interoperability. It is the responsibility of the sites making use
of "experimental/local" values to ensure that no conflicts occur
within the intended scope of use.
Any document defining a new TLV that lists a value of "OK" in the
Early Data column must include a threat analysis for the use of the
TLV in the case of TLS zero round-trip. See Section 11.1 for
details.
11. Security Considerations
If this mechanism is to be used with DNS-over-TLS, then these messages are subject to the same constraints as any other DNS-over- TLS messages and MUST NOT be sent in the clear before the TLS session is established. The data field of the "Encryption Padding" TLV could be used as a covert channel. When designing new DSO TLVs, the potential for data in the TLV to be used as a tracking identifier should be taken into consideration and should be avoided when not required. When used without TLS or similar cryptographic protection, a malicious entity may be able to inject a malicious unidirectional DSO Retry Delay message into the data stream, specifying an unreasonably large RETRY DELAY, causing a denial-of-service attack against the client. The establishment of DSO Sessions has an impact on the number of open TCP connections on a DNS server. Additional resources may be used on the server as a result. However, because the server can limit the number of DSO Sessions established and can also close existing DSO Sessions as needed, denial of service or resource exhaustion should not be a concern.11.1. TLS Zero Round-Trip Considerations
DSO permits zero round-trip operation using TCP Fast Open with TLS 1.3 [RFC8446] early data to reduce or eliminate round trips in session establishment. TCP Fast Open is only permitted in combination with TLS 1.3 early data. In the rest of this section, we refer to TLS 1.3 early data in a TLS zero round-trip initial handshake message, regardless of whether or not it is included in a TCP SYN packet with early data using the TCP Fast Open option, as "early data." A DSO message may or may not be permitted to be sent as early data. The definition for each TLV that can be used as a Primary TLV is required to state whether or not that TLV is permitted as early data. Only response-requiring messages are ever permitted as early data, and only clients are permitted to send a DSO message as early data unless there is an implicit DSO session (see Section 5.1).
For DSO messages that are permitted as early data, a client MAY include one or more such messages as early data without having to wait for a DSO response to the first DSO request message to confirm successful establishment of a DSO Session. However, unless there is an implicit DSO session, a client MUST NOT send DSO unidirectional messages until after a DSO Session has been mutually established. Similarly, unless there is an implicit DSO session, a server MUST NOT send DSO request messages until it has received a response-requiring DSO request message from a client and transmitted a successful NOERROR response for that request. Caution must be taken to ensure that DSO messages sent as early data are idempotent or are otherwise immune to any problems that could result from the inadvertent replay that can occur with zero round- trip operation. It would be possible to add a TLV that requires the server to do some significant work and send that to the server as initial data in a TCP SYN packet. A flood of such packets could be used as a DoS attack on the server. None of the TLVs defined here have this property. If a new TLV is specified that does have this property, that TLV must be specified as not permitted in zero round-trip messages. This prevents work from being done until a round-trip has occurred from the server to the client to verify that the source address of the packet is reachable. Documents that define new TLVs must state whether each new TLV may be sent as early data. Such documents must include a threat analysis in the security considerations section for each TLV defined in the document that may be sent as early data. This threat analysis should be done based on the advice given in Sections 2.3, 8, and Appendix E.5 of the TLS 1.3 specification [RFC8446].12. References
12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>. [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>. [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-editor.org/info/rfc7830>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.12.2. Informative References
[Fail] Andrews, M. and R. Bellis, "A Common Operational Problem in DNS Servers - Failure To Communicate", Work in Progress, draft-ietf-dnsop-no-response-issue-13, February 2019.
[NagleDA] Cheshire, S., "TCP Performance problems caused by interaction between Nagle's Algorithm and Delayed ACK", May 2005, <http://www.stuartcheshire.org/papers/nagledelayedack/>. [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", Work in Progress, draft-ietf-dnssd-push-18, March 2019. [Relay] Lemon, T. and S. Cheshire, "Multicast DNS Discovery Relay", Work in Progress, draft-ietf-dnssd-mdns-relay-02, March 2019. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>. [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>. [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>. [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-editor.org/info/rfc7828>. [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7858] 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, <https://www.rfc-editor.org/info/rfc7858>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, October 2018, <https://www.rfc-editor.org/info/rfc8467>. [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.Acknowledgements
Thanks to Stephane Bortzmeyer, Tim Chown, Ralph Droms, Paul Hoffman, Jan Komissar, Edward Lewis, Allison Mankin, Rui Paulo, David Schinazi, Manju Shankar Rao, Bernie Volz, and Bob Harold for their helpful contributions to this document.Authors' Addresses
Ray Bellis Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 United States of America Phone: +1 (650) 423-1200 Email: ray@isc.org Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America Phone: +1 (408) 996-1010 Email: cheshire@apple.com
John Dickinson Sinodun Internet Technologies Magadalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom Email: jad@sinodun.com Sara Dickinson Sinodun Internet Technologies Magadalen Centre Oxford Science Park Oxford OX4 4GA United Kingdom Email: sara@sinodun.com Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, VT 05302-0958 United States of America Email: mellon@fugue.com Tom Pusateri Unaffiliated Raleigh, NC 27608 United States of America Phone: +1 (919) 867-1330 Email: pusateri@bangj.com