Specification for DNS over Transport Layer Security (TLS)
RFC 7858

<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.

   [IPSECA]   Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A.
              Mohaisen, "Opportunistic Encryption with DANE Semantics
              and IPsec: IPSECA", Work in Progress,
              draft-osterweil-dane-ipsec-03, July 2015.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
              <http://www.rfc-editor.org/info/rfc3234>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003,
              <http://www.rfc-editor.org/info/rfc3646>.

   [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>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

   [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>.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <http://www.rfc-editor.org/info/rfc7435>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,
              <http://www.rfc-editor.org/info/rfc7626>.

Hu, et al.                   Standards Track                   [Page 14]
RFC 7858                      DNS over TLS                      May 2016

   [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
              edns-tcp-keepalive EDNS0 Option", RFC 7828,
              DOI 10.17487/RFC7828, April 2016,
              <http://www.rfc-editor.org/info/rfc7828>.

   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016,
              <http://www.rfc-editor.org/info/rfc7830>.

   [TDNS]     Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
              and N. Somaiya, "Connection-Oriented DNS to Improve
              Privacy and Security", 2015 IEEE Symposium on Security and
              Privacy (SP), DOI 10.1109/SP.2015.18,
              <http://dx.doi.org/10.1109/SP.2015.18>.

   [TLS-DTLS-PROFILES]
              Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
              and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
              Work in Progress, draft-ietf-dprive-dtls-and-tls-
              profiles-01, March 2016.

   [TLS-FALSESTART]
              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", Work in Progress,
              draft-ietf-tls-falsestart-02, May 2016.

Hu, et al.                   Standards Track                   [Page 15]
RFC 7858                      DNS over TLS                      May 2016

Appendix A.  Out-of-Band Key-Pinned Privacy Profile Example

   This section presents an example of how the out-of-band key-pinned
   privacy profile could work in practice based on a minimal pin set
   (two pins).

   A DNS client system is configured with an out-of-band key-pinned
   privacy profile from a network service, using a pin set containing
   two pins.  Represented in HTTP Public Key Pinning (HPKP) [RFC7469]
   style, the pins are:

   o  pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="

   o  pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="

   The client also configures the IP addresses of its expected DNS
   server: perhaps 192.0.2.3 and 2001:db8::2:4.

   The client connects to one of these addresses on TCP port 853 and
   begins the TLS handshake: negotiation of TLS 1.2 with a Diffie-
   Hellman key exchange.  The server sends a certificate message with a
   list of three certificates (A, B, and C) and signs the
   ServerKeyExchange message correctly with the public key found in
   certificate A.

   The client now takes the SHA-256 digest of the SPKI in cert A and
   compares it against both pins in the pin set.  If either pin matches,
   the verification is successful; the client continues with the TLS
   connection and can make its first DNS query.

   If neither pin matches the SPKI of cert A, the client verifies that
   cert A is actually issued by cert B.  If it is, it takes the SHA-256
   digest of the SPKI in cert B and compares it against both pins in the
   pin set.  If either pin matches, the verification is successful.
   Otherwise, it verifies that B was issued by C and then compares the
   pins against the digest of C's SPKI.

   If none of the SPKIs in the cryptographically valid chain of certs
   match any pin in the pin set, the client closes the connection with
   an error and marks the IP address as failed.

Hu, et al.                   Standards Track                   [Page 16]
RFC 7858                      DNS over TLS                      May 2016

Acknowledgments

   The authors would like to thank Stephane Bortzmeyer, John Dickinson,
   Brian Haberman, Christian Huitema, Shumon Huque, Simon Joseffson,
   Kim-Minh Kaplan, Simon Kelley, Warren Kumari, John Levine, Ilari
   Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei
   Tatuya, Tim Wicinski, and Glen Wiley for reviewing this
   specification.  They also thank Nikita Somaiya for early work on this
   idea.

   Work by Zi Hu, Liang Zhu, and John Heidemann on this document is
   partially sponsored by the U.S. Dept. of Homeland Security (DHS)
   Science and Technology Directorate, Homeland Security Advanced
   Research Projects Agency (HSARPA), Cyber Security Division, BAA
   11-01-RIKA and Air Force Research Laboratory, Information Directorate
   under agreement number FA8750-12-2-0344, and contract number
   D08PC75599.

Contributors

   The below individuals contributed significantly to the document:

   Sara Dickinson
   Sinodun Internet Technologies
   Magdalen Centre
   Oxford Science Park
   Oxford  OX4 4GA
   United Kingdom

   Email: sara@sinodun.com
   URI:   http://sinodun.com

   Daniel Kahn Gillmor
   ACLU
   125 Broad Street, 18th Floor
   New York, NY  10004
   United States

Hu, et al.                   Standards Track                   [Page 17]
RFC 7858                      DNS over TLS                      May 2016

Authors' Addresses

   Zi Hu
   USC/Information Sciences Institute
   4676 Admiralty Way, Suite 1133
   Marina del Rey, CA  90292
   United States

   Phone: +1-213-587-1057
   Email: zihu@outlook.com

   Liang Zhu
   USC/Information Sciences Institute
   4676 Admiralty Way, Suite 1133
   Marina del Rey, CA  90292
   United States

   Phone: +1-310-448-8323
   Email: liangzhu@usc.edu

   John Heidemann
   USC/Information Sciences Institute
   4676 Admiralty Way, Suite 1001
   Marina del Rey, CA  90292
   United States

   Phone: +1-310-822-1511
   Email: johnh@isi.edu

   Allison Mankin
   Independent

   Phone: +1-301-728-7198
   Email: Allison.mankin@gmail.com

   Duane Wessels
   Verisign Labs
   12061 Bluemont Way
   Reston, VA  20190
   United States

   Phone: +1-703-948-3200
   Email: dwessels@verisign.com

Hu, et al.                   Standards Track                   [Page 18]
RFC 7858                      DNS over TLS                      May 2016

   Paul Hoffman
   ICANN

   Email: paul.hoffman@icann.org

Hu, et al.                   Standards Track                   [Page 19]