doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc8094.txt b/doc/rfc/rfc8094.txt
new file mode 100644
index 0000000..881feb6
--- /dev/null
+++ b/doc/rfc/rfc8094.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          T. Reddy
+Request for Comments: 8094                                         Cisco
+Category: Experimental                                           D. Wing
+ISSN: 2070-1721
+                                                                P. Patil
+                                                                   Cisco
+                                                           February 2017
+
+
+           DNS over Datagram Transport Layer Security (DTLS)
+
+Abstract
+
+   DNS queries and responses are visible to network elements on the path
+   between the DNS client and its server.  These queries and responses
+   can contain privacy-sensitive information, which is valuable to
+   protect.
+
+   This document proposes the use of Datagram Transport Layer Security
+   (DTLS) for DNS, to protect against passive listeners and certain
+   active attacks.  As latency is critical for DNS, this proposal also
+   discusses mechanisms to reduce DTLS round trips and reduce the DTLS
+   handshake size.  The proposed mechanism runs over port 853.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8094.
+
+
+
+
+
+
+
+
+
+
+Reddy, et al.                 Experimental                      [Page 1]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship to TCP Queries and to DNSSEC ..................3
+      1.2. Document Status ............................................4
+   2. Terminology .....................................................4
+   3. Establishing and Managing DNS over DTLS Sessions ................5
+      3.1. Session Initiation .........................................5
+      3.2. DTLS Handshake and Authentication ..........................5
+      3.3. Established Sessions .......................................6
+   4. Performance Considerations ......................................7
+   5. Path MTU (PMTU) Issues ..........................................7
+   6. Anycast .........................................................8
+   7. Usage ...........................................................9
+   8. IANA Considerations .............................................9
+   9. Security Considerations .........................................9
+   10. References ....................................................10
+      10.1. Normative References .....................................10
+      10.2. Informative References ...................................11
+   Acknowledgements ..................................................13
+   Authors' Addresses ................................................13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al.                 Experimental                      [Page 2]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+1.  Introduction
+
+   The Domain Name System is specified in [RFC1034] and [RFC1035].  DNS
+   queries and responses are normally exchanged unencrypted; thus, they
+   are vulnerable to eavesdropping.  Such eavesdropping can result in an
+   undesired entity learning domain that a host wishes to access, thus
+   resulting in privacy leakage.  The DNS privacy problem is further
+   discussed in [RFC7626].
+
+   This document defines DNS over DTLS, which provides confidential DNS
+   communication between stub resolvers and recursive resolvers, stub
+   resolvers and forwarders, and forwarders and recursive resolvers.
+   DNS over DTLS puts an additional computational load on servers.  The
+   largest gain for privacy is to protect the communication between the
+   DNS client (the end user's machine) and its caching resolver.  DNS
+   over DTLS might work equally between recursive clients and
+   authoritative servers, but this application of the protocol is out of
+   scope for the DNS PRIVate Exchange (DPRIVE) working group per its
+   current charter.  This document does not change the format of DNS
+   messages.
+
+   The motivations for proposing DNS over DTLS are that:
+
+   o  TCP suffers from network head-of-line blocking, where the loss of
+      a packet causes all other TCP segments not to be delivered to the
+      application until the lost packet is retransmitted.  DNS over
+      DTLS, because it uses UDP, does not suffer from network head-of-
+      line blocking.
+
+   o  DTLS session resumption consumes one round trip, whereas TLS
+      session resumption can start only after the TCP handshake is
+      complete.  However, with TCP Fast Open [RFC7413], the
+      implementation can achieve the same RTT efficiency as DTLS.
+
+   Note: DNS over DTLS is an experimental update to DNS, and the
+   experiment will be concluded when the specification is evaluated
+   through implementations and interoperability testing.
+
+1.1.  Relationship to TCP Queries and to DNSSEC
+
+   DNS queries can be sent over UDP or TCP.  The scope of this document,
+   however, is only UDP.  DNS over TCP can be protected with TLS, as
+   described in [RFC7858].  DNS over DTLS alone cannot provide privacy
+   for DNS messages in all circumstances, specifically when the DTLS
+   record size is larger than the path MTU.  In such situations, the DNS
+   server will respond with a truncated response (see Section 5).
+
+
+
+
+
+Reddy, et al.                 Experimental                      [Page 3]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+   Therefore, DNS clients and servers that implement DNS over DTLS MUST
+   also implement DNS over TLS in order to provide privacy for clients
+   that desire Strict Privacy as described in [DTLS].
+
+   DNS Security Extensions (DNSSEC) [RFC4033] provide object integrity
+   of DNS resource records, allowing end users (or their resolver) to
+   verify the legitimacy of responses.  However, DNSSEC does not provide
+   privacy for DNS requests or responses.  DNS over DTLS works in
+   conjunction with DNSSEC, but DNS over DTLS does not replace the need
+   or value of DNSSEC.
+
+1.2.  Document Status
+
+   This document is an Experimental RFC.  One key aspect to judge
+   whether the approach is usable on a large scale is by observing the
+   uptake, usability, and operational behavior of the protocol in large-
+   scale, real-life deployments.
+
+   This DTLS solution was considered by the DPRIVE working group as an
+   option to use in case the TLS-based approach specified in [RFC7858]
+   turns out to have some issues when deployed.  At the time of writing,
+   it is expected that [RFC7858] is what will be deployed, and so this
+   specification is mainly intended as a backup.
+
+   The following guidelines should be considered when performance
+   benchmarking DNS over DTLS:
+
+   1.  DNS over DTLS can recover from packet loss and reordering, and
+       does not suffer from network head-of-line blocking.  DNS over
+       DTLS performance, in comparison with DNS over TLS, may be better
+       in lossy networks.
+
+   2.  The number of round trips to send the first DNS query over DNS
+       over DTLS is less than the number of round trips to send the
+       first DNS query over TLS.  Even if TCP Fast Open is used, it only
+       works for subsequent TCP connections between the DNS client and
+       server (Section 3 in [RFC7413]).
+
+   3.  If the DTLS 1.3 protocol [DTLS13] is used for DNS over DTLS, it
+       provides critical latency improvements for connection
+       establishment over DTLS 1.2.
+
+2.  Terminology
+
+   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
+   [RFC2119] .
+
+
+
+Reddy, et al.                 Experimental                      [Page 4]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+3.  Establishing and Managing DNS over DTLS Sessions
+
+3.1.  Session Initiation
+
+   By default, DNS over DTLS MUST run over standard UDP port 853 as
+   defined in Section 8, unless the DNS server has mutual agreement with
+   its clients to use a port other than 853 for DNS over DTLS.  In order
+   to use a port other than 853, both clients and servers would need a
+   configuration option in their software.
+
+   The DNS client should determine if the DNS server supports DNS over
+   DTLS by sending a DTLS ClientHello message to port 853 on the server,
+   unless it has mutual agreement with its server to use a port other
+   than port 853 for DNS over DTLS.  Such another port MUST NOT be port
+   53 but MAY be from the "first-come, first-served" port range (User
+   Ports [RFC6335], range 1024-49151).  This recommendation against the
+   use of port 53 for DNS over DTLS is to avoid complications in
+   selecting use or non-use of DTLS and to reduce risk of downgrade
+   attacks.
+
+   A DNS server that does not support DNS over DTLS will not respond to
+   ClientHello messages sent by the client.  If no response is received
+   from that server, and the client has no better round-trip estimate,
+   the client SHOULD retransmit the DTLS ClientHello according to
+   Section 4.2.4.1 of [RFC6347].  After 15 seconds, it SHOULD cease
+   attempts to retransmit its ClientHello.  The client MAY repeat that
+   procedure to discover if DNS over DTLS service becomes available from
+   the DNS server, but such probing SHOULD NOT be done more frequently
+   than every 24 hours and MUST NOT be done more frequently than every
+   15 minutes.  This mechanism requires no additional signaling between
+   the client and server.
+
+   DNS clients and servers MUST NOT use port 853 to transport cleartext
+   DNS messages.  DNS clients MUST NOT send and DNS servers MUST NOT
+   respond to cleartext DNS messages on any port used for DNS over DTLS
+   (including, for example, after a failed DTLS handshake).  There are
+   significant security issues in mixing protected and unprotected data;
+   therefore, UDP connections on a port designated by a given server for
+   DNS over DTLS are reserved purely for encrypted communications.
+
+3.2.  DTLS Handshake and Authentication
+
+   The DNS client initiates the DTLS handshake as described in
+   [RFC6347], following the best practices specified in [RFC7525].
+   After DTLS negotiation completes, if the DTLS handshake succeeds
+   according to [RFC6347], the connection will be encrypted and would
+   then be protected from eavesdropping.
+
+
+
+
+Reddy, et al.                 Experimental                      [Page 5]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+   DNS privacy requires encrypting the query (and response) from passive
+   attacks.  Such encryption typically provides integrity protection as
+   a side effect, which means on-path attackers cannot simply inject
+   bogus DNS responses.  However, to provide stronger protection from
+   active attackers pretending to be the server, the server itself needs
+   to be authenticated.  To authenticate the server providing DNS
+   privacy, DNS client MUST use the authentication mechanisms discussed
+   in [DTLS].  This document does not propose new ideas for
+   authentication.
+
+3.3.  Established Sessions
+
+   In DTLS, all data is protected using the same record encoding and
+   mechanisms.  When the mechanism described in this document is in
+   effect, DNS messages are encrypted using the standard DTLS record
+   encoding.  When a DTLS user wishes to send a DNS message, the data is
+   delivered to the DTLS implementation as an ordinary application data
+   write (e.g., SSL_write()).  A single DTLS session can be used to send
+   multiple DNS requests and receive multiple DNS responses.
+
+   To mitigate the risk of unintentional server overload, DNS over DTLS
+   clients MUST take care to minimize the number of concurrent DTLS
+   sessions made to any individual server.  For any given client/server
+   interaction, it is RECOMMENDED that there be no more than one DTLS
+   session.  Similarly, servers MAY impose limits on the number of
+   concurrent DTLS sessions being handled for any particular client IP
+   address or subnet.  These limits SHOULD be much looser than the
+   client guidelines above because the server does not know, for
+   example, if a client IP address belongs to a single client, is
+   representing multiple resolvers on a single machine, or is
+   representing multiple clients behind a device performing Network
+   Address Translation (NAT).
+
+   In between normal DNS traffic, while the communication to the DNS
+   server is quiescent, the DNS client MAY want to probe the server
+   using DTLS heartbeat [RFC6520] to ensure it has maintained
+   cryptographic state.  Such probes can also keep alive firewall or NAT
+   bindings.  This probing reduces the frequency of needing a new
+   handshake when a DNS query needs to be resolved, improving the user
+   experience at the cost of bandwidth and processing time.
+
+   A DTLS session is terminated by the receipt of an authenticated
+   message that closes the connection (e.g., a DTLS fatal alert).  If
+   the server has lost state, a DTLS handshake needs to be initiated
+   with the server.  For the server, to mitigate the risk of
+   unintentional server overload, it is RECOMMENDED that the default DNS
+   over DTLS server application-level idle time be set to several
+   seconds and not set to less than a second, but no particular value is
+
+
+
+Reddy, et al.                 Experimental                      [Page 6]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+   specified.  When no DNS queries have been received from the client
+   after idle timeout, the server MUST send a DTLS fatal alert and then
+   destroy its DTLS state.  The DTLS fatal alert packet indicates the
+   server has destroyed its state, signaling to the client that if it
+   wants to send a new DTLS message, it will need to re-establish
+   cryptographic context with the server (via full DTLS handshake or
+   DTLS session resumption).  In practice, the idle period can vary
+   dynamically, and servers MAY allow idle connections to remain open
+   for longer periods as resources permit.
+
+4.  Performance Considerations
+
+   The DTLS protocol profile for DNS over DTLS is discussed in
+   Section 11 of [DTLS].  To reduce the number of octets of the DTLS
+   handshake, especially the size of the certificate in the ServerHello
+   (which can be several kilobytes), DNS clients and servers can use raw
+   public keys [RFC7250] or Cached Information Extension [RFC7924].
+   Cached Information Extension avoids transmitting the server's
+   certificate and certificate chain if the client has cached that
+   information from a previous TLS handshake.  TLS False Start [RFC7918]
+   can reduce round trips by allowing the TLS second flight of messages
+   (ChangeCipherSpec) to also contain the (encrypted) DNS query.
+
+   It is highly advantageous to avoid server-side DTLS state and reduce
+   the number of new DTLS sessions on the server that can be done with
+   TLS Session Resumption without server state [RFC5077].  This also
+   eliminates a round trip for subsequent DNS over DTLS queries, because
+   with [RFC5077] the DTLS session does not need to be re-established.
+
+   Since responses within a DTLS session can arrive out of order,
+   clients MUST match responses to outstanding queries on the same DTLS
+   connection using the DNS Message ID.  If the response contains a
+   question section, the client MUST match the QNAME, QCLASS, and QTYPE
+   fields.  Failure by clients to properly match responses to
+   outstanding queries can have serious consequences for
+   interoperability (Section 7 of [RFC7766]).
+
+5.  Path MTU (PMTU) Issues
+
+   Compared to normal DNS, DTLS adds at least 13 octets of header, plus
+   cipher and authentication overhead to every query and every response.
+   This reduces the size of the DNS payload that can be carried.  The
+   DNS client and server MUST support the Extension Mechanisms for DNS
+   (EDNS0) option defined in [RFC6891] so that the DNS client can
+   indicate to the DNS server the maximum DNS response size it can
+   reassemble and deliver in the DNS client's network stack.  If the DNS
+   client does set the EDNS0 option defined in [RFC6891], then the
+   maximum DNS response size of 512 bytes plus DTLS overhead will be
+
+
+
+Reddy, et al.                 Experimental                      [Page 7]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+   well within the Path MTU.  If the Path MTU is not known, an IP MTU of
+   1280 bytes SHOULD be assumed.  The client sets its EDNS0 value as if
+   DTLS is not being used.  The DNS server MUST ensure that the DNS
+   response size does not exceed the Path MTU, i.e., each DTLS record
+   MUST fit within a single datagram, as required by [RFC6347].  The DNS
+   server must consider the amount of record expansion expected by the
+   DTLS processing when calculating the size of DNS response that fits
+   within the path MTU.  The Path MTU MUST be greater than or equal to
+   the DNS response size + DTLS overhead of 13 octets + padding size
+   ([RFC7830]) + authentication overhead of the negotiated DTLS cipher
+   suite + block padding (Section 4.1.1.1 of [RFC6347]).  If the DNS
+   server's response were to exceed that calculated value, the server
+   MUST send a response that does fit within that value and sets the TC
+   (truncated) bit.  Upon receiving a response with the TC bit set and
+   wanting to receive the entire response, the client behavior is
+   governed by the current Usage Profile [DTLS].  For Strict Privacy,
+   the client MUST only send a new DNS request for the same resource
+   record over an encrypted transport (e.g., DNS over TLS [RFC7858]).
+   Clients using Opportunistic Privacy SHOULD try for the best case (an
+   encrypted and authenticated transport) but MAY fall back to
+   intermediate cases and eventually the worst case scenario (clear
+   text) in order to obtain a response.
+
+6.  Anycast
+
+   DNS servers are often configured with anycast addresses.  While the
+   network is stable, packets transmitted from a particular source to an
+   anycast address will reach the same server that has the cryptographic
+   context from the DNS over DTLS handshake.  But, when the network
+   configuration or routing changes, a DNS over DTLS packet can be
+   received by a server that does not have the necessary cryptographic
+   context.  Clients using DNS over DTLS need to always be prepared to
+   re-initiate the DTLS handshake, and in the worst case this could even
+   happen immediately after re-initiating a new handshake.  To encourage
+   the client to initiate a new DTLS handshake, DNS servers SHOULD
+   generate a DTLS fatal alert message in response to receiving a DTLS
+   packet for which the server does not have any cryptographic context.
+   Upon receipt of an unauthenticated DTLS fatal alert, the DTLS client
+   validates the fatal alert is within the replay window
+   (Section 4.1.2.6 of [RFC6347]).  It is difficult for the DTLS client
+   to validate that the DTLS fatal alert was generated by the DTLS
+   server in response to a request or was generated by an on- or off-
+   path attacker.  Thus, upon receipt of an in-window DTLS fatal alert,
+   the client SHOULD continue retransmitting the DTLS packet (in the
+   event the fatal alert was spoofed), and at the same time it SHOULD
+   initiate DTLS session resumption.  When the DTLS client receives an
+   authenticated DNS response from one of those DTLS sessions, the other
+   DTLS session should be terminated.
+
+
+
+Reddy, et al.                 Experimental                      [Page 8]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+7.  Usage
+
+   Two Usage Profiles, Strict and Opportunistic, are explained in
+   [DTLS].  The order of preference for DNS usage is as follows:
+
+   1.  Encrypted DNS messages with an authenticated server
+
+   2.  Encrypted DNS messages with an unauthenticated server
+
+   3.  Plaintext DNS messages
+
+8.  IANA Considerations
+
+   This specification uses port 853 already allocated in the IANA port
+   number registry as defined in Section 6 of [RFC7858].
+
+9.  Security Considerations
+
+   The interaction between a DNS client and a DNS server requires
+   Datagram Transport Layer Security (DTLS) with a ciphersuite offering
+   confidentiality protection.  The guidance given in [RFC7525] MUST be
+   followed to avoid attacks on DTLS.  The DNS client SHOULD use the TLS
+   Certificate Status Request extension (Section 8 of [RFC6066]),
+   commonly called "OCSP stapling" to check the revocation status of the
+   public key certificate of the DNS server.  OCSP stapling, unlike OCSP
+   [RFC6960], does not suffer from scale and privacy issues.  DNS
+   clients keeping track of servers known to support DTLS enables
+   clients to detect downgrade attacks.  To interfere with DNS over
+   DTLS, an on- or off-path attacker might send an ICMP message towards
+   the DTLS client or DTLS server.  As these ICMP messages cannot be
+   authenticated, all ICMP errors should be treated as soft errors
+   [RFC1122].  If the DNS query was sent over DTLS, then the
+   corresponding DNS response MUST only be accepted if it is received
+   over the same DTLS connection.  This behavior mitigates all possible
+   attacks described in Measures for Making DNS More Resilient against
+   Forged Answers [RFC5452].  The security considerations in [RFC6347]
+   and [DTLS] are to be taken into account.
+
+   A malicious client might attempt to perform a high number of DTLS
+   handshakes with a server.  As the clients are not uniquely identified
+   by the protocol and can be obfuscated with IPv4 address sharing and
+   with IPv6 temporary addresses, a server needs to mitigate the impact
+   of such an attack.  Such mitigation might involve rate limiting
+   handshakes from a certain subnet or more advanced DoS/DDoS techniques
+   beyond the scope of this document.
+
+
+
+
+
+
+Reddy, et al.                 Experimental                      [Page 9]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <http://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <http://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+              "Transport Layer Security (TLS) Session Resumption without
+              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
+              January 2008, <http://www.rfc-editor.org/info/rfc5077>.
+
+   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
+              Resilient against Forged Answers", RFC 5452,
+              DOI 10.17487/RFC5452, January 2009,
+              <http://www.rfc-editor.org/info/rfc5452>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <http://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
+              Layer Security (TLS) and Datagram Transport Layer Security
+              (DTLS) Heartbeat Extension", RFC 6520,
+              DOI 10.17487/RFC6520, February 2012,
+              <http://www.rfc-editor.org/info/rfc6520>.
+
+   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+              for DNS (EDNS(0))", STD 75, RFC 6891,
+              DOI 10.17487/RFC6891, April 2013,
+              <http://www.rfc-editor.org/info/rfc6891>.
+
+
+
+
+
+Reddy, et al.                 Experimental                     [Page 10]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+              2015, <http://www.rfc-editor.org/info/rfc7525>.
+
+   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
+              DOI 10.17487/RFC7830, May 2016,
+              <http://www.rfc-editor.org/info/rfc7830>.
+
+10.2.  Informative References
+
+   [DTLS]     Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
+              and (D)TLS Profile for DNS-over-(D)TLS", Work in
+              Progress, draft-ietf-dprive-dtls-and-tls-profiles-08,
+              January 2017.
+
+   [DTLS13]   Rescorla, E. and H. Tschofenig, "The Datagram Transport
+              Layer Security (DTLS) Protocol Version 1.3", Work in
+              Progress, draft-rescorla-tls-dtls13-00, October 2016.
+
+   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122,
+              DOI 10.17487/RFC1122, October 1989,
+              <http://www.rfc-editor.org/info/rfc1122>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <http://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
+              Cheshire, "Internet Assigned Numbers Authority (IANA)
+              Procedures for the Management of the Service Name and
+              Transport Protocol Port Number Registry", BCP 165,
+              RFC 6335, DOI 10.17487/RFC6335, August 2011,
+              <http://www.rfc-editor.org/info/rfc6335>.
+
+   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
+              Galperin, S., and C. Adams, "X.509 Internet Public Key
+              Infrastructure Online Certificate Status Protocol - OCSP",
+              RFC 6960, DOI 10.17487/RFC6960, June 2013,
+              <http://www.rfc-editor.org/info/rfc6960>.
+
+
+
+
+
+
+
+
+Reddy, et al.                 Experimental                     [Page 11]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
+              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
+              Transport Layer Security (TLS) and Datagram Transport
+              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
+              June 2014, <http://www.rfc-editor.org/info/rfc7250>.
+
+   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
+              <http://www.rfc-editor.org/info/rfc7413>.
+
+   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
+              DOI 10.17487/RFC7626, August 2015,
+              <http://www.rfc-editor.org/info/rfc7626>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7766>.
+
+   [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, <http://www.rfc-editor.org/info/rfc7858>.
+
+   [RFC7918]  Langley, A., Modadugu, N., and B. Moeller, "Transport
+              Layer Security (TLS) False Start", RFC 7918,
+              DOI 10.17487/RFC7918, August 2016,
+              <http://www.rfc-editor.org/info/rfc7918>.
+
+   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
+              (TLS) Cached Information Extension", RFC 7924,
+              DOI 10.17487/RFC7924, July 2016,
+              <http://www.rfc-editor.org/info/rfc7924>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al.                 Experimental                     [Page 12]
+
+RFC 8094                      DNS over DTLS                February 2017
+
+
+Acknowledgements
+
+   Thanks to Phil Hedrick for his review comments on TCP and to Josh
+   Littlefield for pointing out DNS over DTLS load on busy servers (most
+   notably root servers).  The authors would like to thank Simon
+   Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara
+   Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander
+   Mayrhofer, Allison Mankin, Jouni Korhonen, Stephen Farrell, Mirja
+   Kuehlewind, Benoit Claise, and Geoff Huston for discussions and
+   comments on the design of DNS over DTLS.  The authors would like to
+   give special thanks to Sara Dickinson for her help.
+
+Authors' Addresses
+
+   Tirumaleswar Reddy
+   Cisco Systems, Inc.
+   Cessna Business Park, Varthur Hobli
+   Sarjapur Marathalli Outer Ring Road
+   Bangalore, Karnataka  560103
+   India
+
+   Email: tireddy@cisco.com
+
+
+   Dan Wing
+
+   Email: dwing-ietf@fuggles.com
+
+
+   Prashanth Patil
+   Cisco Systems, Inc.
+
+   Email: praspati@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al.                 Experimental                     [Page 13]
+