Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8490

DNS Stateful Operations

Pages: 64
Proposed Standard
Updates:  10357766
Part 4 of 4 – Pages 47 to 64
First   Prev   None

Top   ToC   RFC8490 - Page 47   prevText

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 | +--------+------------------------------+------------------------+
Top   ToC   RFC8490 - Page 48

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.
Top   ToC   RFC8490 - Page 49
   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.
Top   ToC   RFC8490 - Page 50

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".
Top   ToC   RFC8490 - Page 51

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.
Top   ToC   RFC8490 - Page 52

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.
Top   ToC   RFC8490 - Page 53

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.
Top   ToC   RFC8490 - Page 54

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.
Top   ToC   RFC8490 - Page 55
   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
Top   ToC   RFC8490 - Page 56
   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.
Top   ToC   RFC8490 - Page 57

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 | | | | +-----------+-----------------------+-------+-----------+-----------+
Top   ToC   RFC8490 - Page 58
   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.
Top   ToC   RFC8490 - Page 59

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).
Top   ToC   RFC8490 - Page 60
   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>.
Top   ToC   RFC8490 - Page 61
   [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.
Top   ToC   RFC8490 - Page 62
   [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>.
Top   ToC   RFC8490 - Page 63
   [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
Top   ToC   RFC8490 - Page 64
   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