1 Internet Engineering Task Force (IETF) Z. Hu
2 Request for Comments: 7858 L. Zhu
3 Category: Standards Track J. Heidemann
4 ISSN: 2070-1721 USC/ISI
5 A. Mankin
6 Independent
7 D. Wessels
8 Verisign Labs
9 P. Hoffman
10 ICANN
11 May 2016
12
13
14 Specification for DNS over Transport Layer Security (TLS)
15
16 Abstract
17
18 This document describes the use of Transport Layer Security (TLS) to
19 provide privacy for DNS. Encryption provided by TLS eliminates
20 opportunities for eavesdropping and on-path tampering with DNS
21 queries in the network, such as discussed in RFC 7626. In addition,
22 this document specifies two usage profiles for DNS over TLS and
23 provides advice on performance considerations to minimize overhead
24 from using TCP and TLS with DNS.
25
26 This document focuses on securing stub-to-recursive traffic, as per
27 the charter of the DPRIVE Working Group. It does not prevent future
28 applications of the protocol to recursive-to-authoritative traffic.
29
30 Status of This Memo
31
32 This is an Internet Standards Track document.
33
34 This document is a product of the Internet Engineering Task Force
35 (IETF). It represents the consensus of the IETF community. It has
36 received public review and has been approved for publication by the
37 Internet Engineering Steering Group (IESG). Further information on
38 Internet Standards is available in Section 2 of RFC 5741.
39
40 Information about the current status of this document, any errata,
41 and how to provide feedback on it may be obtained at
42 http://www.rfc-editor.org/info/rfc7858.
43
44
45
46
47
48
49
50
51
52 Hu, et al. Standards Track [Page 1]
53 RFC 7858 DNS over TLS May 2016
54
55
56 Copyright Notice
57
58 Copyright (c) 2016 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
75 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
76 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
77 3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5
78 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
79 3.4. Connection Reuse, Close, and Reestablishment . . . . . . 6
80 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
81 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
82 4.2. Out-of-Band Key-Pinned Privacy Profile . . . . . . . . . 7
83 5. Performance Considerations . . . . . . . . . . . . . . . . . 9
84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
85 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10
86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
88 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
89 9.2. Informative References . . . . . . . . . . . . . . . . . 13
90 Appendix A. Out-of-Band Key-Pinned Privacy Profile Example . . . 16
91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
92 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Hu, et al. Standards Track [Page 2]
108 RFC 7858 DNS over TLS May 2016
109
110
111 1. Introduction
112
113 Today, nearly all DNS queries [RFC1034] [RFC1035] are sent
114 unencrypted, which makes them vulnerable to eavesdropping by an
115 attacker that has access to the network channel, reducing the privacy
116 of the querier. Recent news reports have elevated these concerns,
117 and recent IETF work has specified privacy considerations for DNS
118 [RFC7626].
119
120 Prior work has addressed some aspects of DNS security, but until
121 recently, there has been little work on privacy between a DNS client
122 and server. DNS Security Extensions (DNSSEC) [RFC4033] provide
123 _response integrity_ by defining mechanisms to cryptographically sign
124 zones, allowing end users (or their first-hop resolver) to verify
125 replies are correct. By intention, DNSSEC does not protect request
126 and response privacy. Traditionally, either privacy was not
127 considered a requirement for DNS traffic or it was assumed that
128 network traffic was sufficiently private; however, these perceptions
129 are evolving due to recent events [RFC7258].
130
131 Other work that has offered the potential to encrypt between DNS
132 clients and servers includes DNSCurve [DNSCurve], DNSCrypt
133 [DNSCRYPT-WEBSITE], Confidential DNS [CONFIDENTIAL-DNS], and IPSECA
134 [IPSECA]. In addition to the present specification, the DPRIVE
135 Working Group has also adopted a proposal for DNS over Datagram
136 Transport Layer Security (DTLS) [DNSoD].
137
138 This document describes using DNS over TLS on a well-known port and
139 also offers advice on performance considerations to minimize
140 overheads from using TCP and TLS with DNS.
141
142 Initiation of DNS over TLS is very straightforward. By establishing
143 a connection over a well-known port, clients and servers expect and
144 agree to negotiate a TLS session to secure the channel. Deployment
145 will be gradual. Not all servers will support DNS over TLS and the
146 well-known port might be blocked by some firewalls. Clients will be
147 expected to keep track of servers that support TLS and those that
148 don't. Clients and servers will adhere to the TLS implementation
149 recommendations and security considerations of [BCP195].
150
151 The protocol described here works for queries and responses between
152 stub clients and recursive servers. It might work equally between
153 recursive clients and authoritative servers, but this application of
154 the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE)
155 Working Group per its current charter.
156
157
158
159
160
161
162 Hu, et al. Standards Track [Page 3]
163 RFC 7858 DNS over TLS May 2016
164
165
166 This document describes two profiles in Section 4 that provide
167 different levels of assurance of privacy: an opportunistic privacy
168 profile and an out-of-band key-pinned privacy profile. It is
169 expected that a future document based on [TLS-DTLS-PROFILES] will
170 further describe additional privacy profiles for DNS over both TLS
171 and DTLS.
172
173 An earlier draft version of this document described a technique for
174 upgrading a DNS-over-TCP connection to a DNS-over-TLS session with,
175 essentially, "STARTTLS for DNS". To simplify the protocol, this
176 document now only uses a well-known port to specify TLS use, omitting
177 the upgrade approach. The upgrade approach no longer appears in this
178 document, which now focuses exclusively on the use of a well-known
179 port for DNS over TLS.
180
181 2. Key Words
182
183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
185 document are to be interpreted as described in RFC 2119 [RFC2119].
186
187 3. Establishing and Managing DNS-over-TLS Sessions
188
189 3.1. Session Initiation
190
191 By default, a DNS server that supports DNS over TLS MUST listen for
192 and accept TCP connections on port 853, unless it has mutual
193 agreement with its clients to use a port other than 853 for DNS over
194 TLS. In order to use a port other than 853, both clients and servers
195 would need a configuration option in their software.
196
197 By default, a DNS client desiring privacy from DNS over TLS from a
198 particular server MUST establish a TCP connection to port 853 on the
199 server, unless it has mutual agreement with its server to use a port
200 other than port 853 for DNS over TLS. Such another port MUST NOT be
201 port 53 but MAY be from the "first-come, first-served" port range.
202 This recommendation against use of port 53 for DNS over TLS is to
203 avoid complication in selecting use or non-use of TLS and to reduce
204 risk of downgrade attacks. The first data exchange on this TCP
205 connection MUST be the client and server initiating a TLS handshake
206 using the procedure described in [RFC5246].
207
208 DNS clients and servers MUST NOT use port 853 to transport cleartext
209 DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT
210 respond to cleartext DNS messages on any port used for DNS over TLS
211 (including, for example, after a failed TLS handshake). There are
212 significant security issues in mixing protected and unprotected data,
213
214
215
216
217 Hu, et al. Standards Track [Page 4]
218 RFC 7858 DNS over TLS May 2016
219
220
221 and for this reason, TCP connections on a port designated by a given
222 server for DNS over TLS are reserved purely for encrypted
223 communications.
224
225 DNS clients SHOULD remember server IP addresses that don't support
226 DNS over TLS, including timeouts, connection refusals, and TLS
227 handshake failures, and not request DNS over TLS from them for a
228 reasonable period (such as one hour per server). DNS clients
229 following an out-of-band key-pinned privacy profile (Section 4.2) MAY
230 be more aggressive about retrying DNS-over-TLS connection failures.
231
232 3.2. TLS Handshake and Authentication
233
234 Once the DNS client succeeds in connecting via TCP on the well-known
235 port for DNS over TLS, it proceeds with the TLS handshake [RFC5246],
236 following the best practices specified in [BCP195].
237
238 The client will then authenticate the server, if required. This
239 document does not propose new ideas for authentication. Depending on
240 the privacy profile in use (Section 4), the DNS client may choose not
241 to require authentication of the server, or it may make use of a
242 trusted Subject Public Key Info (SPKI) Fingerprint pin set.
243
244 After TLS negotiation completes, the connection will be encrypted and
245 is now protected from eavesdropping.
246
247 3.3. Transmitting and Receiving Messages
248
249 All messages (requests and responses) in the established TLS session
250 MUST use the two-octet length field described in Section 4.2.2 of
251 [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD
252 pass the two-octet length field, and the message described by that
253 length field, to the TCP layer at the same time (e.g., in a single
254 "write" system call) to make it more likely that all the data will be
255 transmitted in a single TCP segment ([RFC7766], Section 8).
256
257 In order to minimize latency, clients SHOULD pipeline multiple
258 queries over a TLS session. When a DNS client sends multiple queries
259 to a server, it should not wait for an outstanding reply before
260 sending the next query ([RFC7766], Section 6.2.1.1).
261
262 Since pipelined responses can arrive out of order, clients MUST match
263 responses to outstanding queries on the same TLS connection using the
264 Message ID. If the response contains a Question Section, the client
265 MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients
266 to properly match responses to outstanding queries can have serious
267 consequences for interoperability ([RFC7766], Section 7).
268
269
270
271
272 Hu, et al. Standards Track [Page 5]
273 RFC 7858 DNS over TLS May 2016
274
275
276 3.4. Connection Reuse, Close, and Reestablishment
277
278 For DNS clients that use library functions such as "getaddrinfo()"
279 and "gethostbyname()", current implementations are known to open and
280 close TCP connections for each DNS query. To avoid excess TCP
281 connections, each with a single query, clients SHOULD reuse a single
282 TCP connection to the recursive resolver. Alternatively, they may
283 prefer to use UDP to a DNS-over-TLS-enabled caching resolver on the
284 same machine that then uses a system-wide TCP connection to the
285 recursive resolver.
286
287 In order to amortize TCP and TLS connection setup costs, clients and
288 servers SHOULD NOT immediately close a connection after each
289 response. Instead, clients and servers SHOULD reuse existing
290 connections for subsequent queries as long as they have sufficient
291 resources. In some cases, this means that clients and servers may
292 need to keep idle connections open for some amount of time.
293
294 Proper management of established and idle connections is important to
295 the healthy operation of a DNS server. An implementor of DNS over
296 TLS SHOULD follow best practices for DNS over TCP, as described in
297 [RFC7766]. Failure to do so may lead to resource exhaustion and
298 denial of service.
299
300 Whereas client and server implementations from the era of [RFC1035]
301 are known to have poor TCP connection management, this document
302 stipulates that successful negotiation of TLS indicates the
303 willingness of both parties to keep idle DNS connections open,
304 independent of timeouts or other recommendations for DNS over TCP
305 without TLS. In other words, software implementing this protocol is
306 assumed to support idle, persistent connections and be prepared to
307 manage multiple, potentially long-lived TCP connections.
308
309 This document does not make specific recommendations for timeout
310 values on idle connections. Clients and servers should reuse and/or
311 close connections depending on the level of available resources.
312 Timeouts may be longer during periods of low activity and shorter
313 during periods of high activity. Current work in this area may also
314 assist DNS-over-TLS clients and servers in selecting useful timeout
315 values [RFC7828] [TDNS].
316
317 Clients and servers that keep idle connections open MUST be robust to
318 termination of idle connection by either party. As with current DNS
319 over TCP, DNS servers MAY close the connection at any time (perhaps
320 due to resource constraints). As with current DNS over TCP, clients
321 MUST handle abrupt closes and be prepared to reestablish connections
322 and/or retry queries.
323
324
325
326
327 Hu, et al. Standards Track [Page 6]
328 RFC 7858 DNS over TLS May 2016
329
330
331 When reestablishing a DNS-over-TCP connection that was terminated, as
332 discussed in [RFC7766], TCP Fast Open [RFC7413] is of benefit.
333 Underlining the requirement for sending only encrypted DNS data on a
334 DNS-over-TLS port (Section 3.2), when using TCP Fast Open, the client
335 and server MUST immediately initiate or resume a TLS handshake
336 (cleartext DNS MUST NOT be exchanged). DNS servers SHOULD enable
337 fast TLS session resumption [RFC5077], and this SHOULD be used when
338 reestablishing connections.
339
340 When closing a connection, DNS servers SHOULD use the TLS close-
341 notify request to shift TCP TIME-WAIT state to the clients.
342 Additional requirements and guidance for optimizing DNS over TCP are
343 provided by [RFC7766].
344
345 4. Usage Profiles
346
347 This protocol provides flexibility to accommodate several different
348 use cases. This document defines two usage profiles: (1)
349 opportunistic privacy and (2) out-of-band key-pinned authentication
350 that can be used to obtain stronger privacy guarantees if the client
351 has a trusted relationship with a DNS server supporting TLS.
352 Additional methods of authentication will be defined in a forthcoming
353 document [TLS-DTLS-PROFILES].
354
355 4.1. Opportunistic Privacy Profile
356
357 For opportunistic privacy, analogous to SMTP opportunistic security
358 [RFC7435], one does not require privacy, but one desires privacy when
359 possible.
360
361 With opportunistic privacy, a client might learn of a TLS-enabled
362 recursive DNS resolver from an untrusted source. One possible
363 example flow would be if the client used the DHCP DNS server option
364 [RFC3646] to discover the IP address of a TLS-enabled recursive and
365 then attempted DNS over TLS on port 853. With such a discovered DNS
366 server, the client might or might not validate the resolver. These
367 choices maximize availability and performance, but they leave the
368 client vulnerable to on-path attacks that remove privacy.
369
370 Opportunistic privacy can be used by any current client, but it only
371 provides privacy when there are no on-path active attackers.
372
373 4.2. Out-of-Band Key-Pinned Privacy Profile
374
375 The out-of-band key-pinned privacy profile can be used in
376 environments where an established trust relationship already exists
377 between DNS clients and servers (e.g., stub-to-recursive in
378 enterprise networks, actively maintained contractual service
379
380
381
382 Hu, et al. Standards Track [Page 7]
383 RFC 7858 DNS over TLS May 2016
384
385
386 relationships, or a client using a public DNS resolver). The result
387 of this profile is that the client has strong guarantees about the
388 privacy of its DNS data by connecting only to servers it can
389 authenticate. Operators of a DNS-over-TLS service in this profile
390 are expected to provide pins that are specific to the service being
391 pinned (i.e., public keys belonging directly to the end entity or to
392 a service-specific private certificate authority (CA)) and not to a
393 public key(s) of a generic public CA.
394
395 In this profile, clients authenticate servers by matching a set of
396 SPKI Fingerprints in an analogous manner to that described in
397 [RFC7469]. With this out-of-band key-pinned privacy profile, client
398 administrators SHOULD deploy a backup pin along with the primary pin,
399 for the reasons explained in [RFC7469]. A backup pin is especially
400 helpful in the event of a key rollover, so that a server operator
401 does not have to coordinate key transitions with all its clients
402 simultaneously. After a change of keys on the server, an updated pin
403 set SHOULD be distributed to all clients in some secure way in
404 preparation for future key rollover. The mechanism for an
405 out-of-band pin set update is out of scope for this document.
406
407 Such a client will only use DNS servers for which an SPKI Fingerprint
408 pin set has been provided. The possession of a trusted pre-deployed
409 pin set allows the client to detect and prevent person-in-the-middle
410 and downgrade attacks.
411
412 However, a configured DNS server may be temporarily unavailable when
413 configuring a network. For example, for clients on networks that
414 require authentication through web-based login, such authentication
415 may rely on DNS interception and spoofing. Techniques such as those
416 used by DNSSEC-trigger [DNSSEC-TRIGGER] MAY be used during network
417 configuration, with the intent to transition to the designated DNS
418 provider after authentication. The user MUST be alerted whenever
419 possible that the DNS is not private during such bootstrap.
420
421 Upon successful TLS connection and handshake, the client computes the
422 SPKI Fingerprints for the public keys found in the validated server's
423 certificate chain (or in the raw public key, if the server provides
424 that instead). If a computed fingerprint exactly matches one of the
425 configured pins, the client continues with the connection as normal.
426 Otherwise, the client MUST treat the SPKI validation failure as a
427 non-recoverable error. Appendix A provides a detailed example of how
428 this authentication could be performed in practice.
429
430 Implementations of this privacy profile MUST support the calculation
431 of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded
432 ASN.1 representation of the SPKI of an X.509 certificate.
433
434
435
436
437 Hu, et al. Standards Track [Page 8]
438 RFC 7858 DNS over TLS May 2016
439
440
441 Implementations MUST support the representation of a SHA-256
442 fingerprint as a base64-encoded character string [RFC4648].
443 Additional fingerprint types MAY also be supported.
444
445 5. Performance Considerations
446
447 DNS over TLS incurs additional latency at session startup. It also
448 requires additional state (memory) and increased processing (CPU).
449
450 Latency: Compared to UDP, DNS over TCP requires an additional round-
451 trip time (RTT) of latency to establish a TCP connection. TCP
452 Fast Open [RFC7413] can eliminate that RTT when information exists
453 from prior connections. The TLS handshake adds another two RTTs
454 of latency. Clients and servers should support connection
455 keepalive (reuse) and out-of-order processing to amortize
456 connection setup costs. Fast TLS connection resumption [RFC5077]
457 further reduces the setup delay and avoids the DNS server keeping
458 per-client session state.
459
460 TLS False Start [TLS-FALSESTART] can also lead to a latency
461 reduction in certain situations. Implementations supporting TLS
462 False Start need to be aware that it imposes additional
463 constraints on how one uses TLS, over and above those stated in
464 [BCP195]. It is unsafe to use False Start if your implementation
465 and deployment does not adhere to these specific requirements.
466 See [TLS-FALSESTART] for the details of these additional
467 constraints.
468
469 State: The use of connection-oriented TCP requires keeping
470 additional state at the server in both the kernel and application.
471 The state requirements are of particular concern on servers with
472 many clients, although memory-optimized TLS can add only modest
473 state over TCP. Smaller timeout values will reduce the number of
474 concurrent connections, and servers can preemptively close
475 connections when resource limits are exceeded.
476
477 Processing: The use of TLS encryption algorithms results in slightly
478 higher CPU usage. Servers can choose to refuse new DNS-over-TLS
479 clients if processing limits are exceeded.
480
481 Number of connections: To minimize state on DNS servers and
482 connection startup time, clients SHOULD minimize the creation of
483 new TCP connections. Use of a local DNS request aggregator (a
484 particular type of forwarder) allows a single active DNS-over-TLS
485 connection from any given client computer to its server.
486 Additional guidance can be found in [RFC7766].
487
488
489
490
491
492 Hu, et al. Standards Track [Page 9]
493 RFC 7858 DNS over TLS May 2016
494
495
496 A full performance evaluation is outside the scope of this
497 specification. A more detailed analysis of the performance
498 implications of DNS over TLS (and DNS over TCP) is discussed in
499 [TDNS] and [RFC7766].
500
501 6. IANA Considerations
502
503 IANA has added the following value to the "Service Name and Transport
504 Protocol Port Number Registry" in the System Range. The registry for
505 that range requires IETF Review or IESG Approval [RFC6335], and such
506 a review was requested using the early allocation process [RFC7120]
507 for the well-known TCP port in this document.
508
509 IANA has reserved the same port number over UDP for the proposed DNS-
510 over-DTLS protocol [DNSoD].
511
512 Service Name domain-s
513 Port Number 853
514 Transport Protocol(s) TCP/UDP
515 Assignee IESG
516 Contact IETF Chair
517 Description DNS query-response protocol run over TLS/DTLS
518 Reference This document
519
520 7. Design Evolution
521
522 Earlier draft versions of this document proposed an upgrade-based
523 approach to establish a TLS session. The client would signal its
524 interest in TLS by setting a "TLS OK" bit in the Extensions
525 Mechanisms for DNS (EDNS(0)) flags field. A server would signal its
526 acceptance by responding with the TLS OK bit set.
527
528 Since we assume the client doesn't want to reveal (leak) any
529 information prior to securing the channel, we proposed the use of a
530 "dummy query" that clients could send for this purpose. The proposed
531 query name was STARTTLS, query type TXT, and query class CH.
532
533 The TLS OK signaling approach has both advantages and disadvantages.
534 One important advantage is that clients and servers could negotiate
535 TLS. If the server is too busy, or doesn't want to provide TLS
536 service to a particular client, it can respond negatively to the TLS
537 probe. An ancillary benefit is that servers could collect
538 information on adoption of DNS over TLS (via the TLS OK bit in
539 queries) before implementation and deployment. Another anticipated
540 advantage is the expectation that DNS over TLS would work over port
541 53. That is, no need to "waste" another port and deploy new firewall
542 rules on middleboxes.
543
544
545
546
547 Hu, et al. Standards Track [Page 10]
548 RFC 7858 DNS over TLS May 2016
549
550
551 However, at the same time, there was uncertainty whether or not
552 middleboxes would pass the TLS OK bit, given that the EDNS0 flags
553 field has been unchanged for many years. Another disadvantage is
554 that the TLS OK bit may make downgrade attacks easy and
555 indistinguishable from broken middleboxes. From a performance
556 standpoint, the upgrade-based approach had the disadvantage of
557 requiring 1xRTT additional latency for the dummy query.
558
559 Following this proposal, DNS over DTLS was proposed separately. DNS
560 over DTLS claimed it could work over port 53, but only because a non-
561 DTLS server interprets a DNS-over-DTLS query as a response. That is,
562 the non-DTLS server observes the QR flag set to 1. While this
563 technically works, it seems unfortunate and perhaps even undesirable.
564
565 DNS over both TLS and DTLS can benefit from a single well-known port
566 and avoid extra latency and misinterpreted queries as responses.
567
568 8. Security Considerations
569
570 Use of DNS over TLS is designed to address the privacy risks that
571 arise out of the ability to eavesdrop on DNS messages. It does not
572 address other security issues in DNS, and there are a number of
573 residual risks that may affect its success at protecting privacy:
574
575 1. There are known attacks on TLS, such as person-in-the-middle and
576 protocol downgrade. These are general attacks on TLS and not
577 specific to DNS over TLS; please refer to the TLS RFCs for
578 discussion of these security issues. Clients and servers MUST
579 adhere to the TLS implementation recommendations and security
580 considerations of [BCP195]. DNS clients keeping track of servers
581 known to support TLS enables clients to detect downgrade attacks.
582 For servers with no connection history and no apparent support
583 for TLS, depending on their privacy profile and privacy
584 requirements, clients may choose to (a) try another server when
585 available, (b) continue without TLS, or (c) refuse to forward the
586 query.
587
588 2. Middleboxes [RFC3234] are present in some networks and have been
589 known to interfere with normal DNS resolution. Use of a
590 designated port for DNS over TLS should avoid such interference.
591 In general, clients that attempt TLS and fail can either fall
592 back on unencrypted DNS or wait and retry later, depending on
593 their privacy profile and privacy requirements.
594
595 3. Any DNS protocol interactions performed in the clear can be
596 modified by a person-in-the-middle attacker. For example,
597 unencrypted queries and responses might take place over port 53
598 between a client and server. For this reason, clients MAY
599
600
601
602 Hu, et al. Standards Track [Page 11]
603 RFC 7858 DNS over TLS May 2016
604
605
606 discard cached information about server capabilities advertised
607 in cleartext.
608
609 4. This document does not, itself, specify ideas to resist known
610 traffic analysis or side-channel leaks. Even with encrypted
611 messages, a well-positioned party may be able to glean certain
612 details from an analysis of message timings and sizes. Clients
613 and servers may consider the use of a padding method to address
614 privacy leakage due to message sizes [RFC7830]. Since traffic
615 analysis can be based on many kinds of patterns and many kinds of
616 classifiers, simple padding schemes alone might not be sufficient
617 to mitigate such an attack. Padding will, however, form a part
618 of more complex mitigations for traffic-analysis attacks that are
619 likely to be developed over time. Implementors who can offer
620 flexibility in terms of how padding can be used may be in a
621 better position to enable such mitigations to be deployed in the
622 future.
623
624 As noted earlier, DNSSEC and DNS over TLS are independent and fully
625 compatible protocols, each solving different problems. The use of
626 one does not diminish the need nor the usefulness of the other.
627
628 9. References
629
630 9.1. Normative References
631
632 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
633 "Recommendations for Secure Use of Transport Layer
634 Security (TLS) and Datagram Transport Layer Security
635 (DTLS)", BCP 195, RFC 7525, May 2015,
636 <https://www.rfc-editor.org/info/bcp195>.
637
638 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
639 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
640 <http://www.rfc-editor.org/info/rfc1034>.
641
642 [RFC1035] Mockapetris, P., "Domain names - implementation and
643 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
644 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
645
646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
647 Requirement Levels", BCP 14, RFC 2119,
648 DOI 10.17487/RFC2119, March 1997,
649 <http://www.rfc-editor.org/info/rfc2119>.
650
651 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
652 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
653 <http://www.rfc-editor.org/info/rfc4648>.
654
655
656
657 Hu, et al. Standards Track [Page 12]
658 RFC 7858 DNS over TLS May 2016
659
660
661 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
662 "Transport Layer Security (TLS) Session Resumption without
663 Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
664 January 2008, <http://www.rfc-editor.org/info/rfc5077>.
665
666 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
667 (TLS) Protocol Version 1.2", RFC 5246,
668 DOI 10.17487/RFC5246, August 2008,
669 <http://www.rfc-editor.org/info/rfc5246>.
670
671 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
672 (SHA and SHA-based HMAC and HKDF)", RFC 6234,
673 DOI 10.17487/RFC6234, May 2011,
674 <http://www.rfc-editor.org/info/rfc6234>.
675
676 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
677 Cheshire, "Internet Assigned Numbers Authority (IANA)
678 Procedures for the Management of the Service Name and
679 Transport Protocol Port Number Registry", BCP 165,
680 RFC 6335, DOI 10.17487/RFC6335, August 2011,
681 <http://www.rfc-editor.org/info/rfc6335>.
682
683 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
684 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
685 2014, <http://www.rfc-editor.org/info/rfc7120>.
686
687 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
688 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
689 2015, <http://www.rfc-editor.org/info/rfc7469>.
690
691 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
692 D. Wessels, "DNS Transport over TCP - Implementation
693 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
694 <http://www.rfc-editor.org/info/rfc7766>.
695
696 9.2. Informative References
697
698 [CONFIDENTIAL-DNS]
699 Wijngaards, W. and G. Wiley, "Confidential DNS", Work in
700 Progress, draft-wijngaards-dnsop-confidentialdns-03, March
701 2015.
702
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions) with the exception of forwarding. Forwarding DNS queries over encrypted transports is not supported in BIND yet.
This document defines DoT. RFC8310 defines profiles for how it might be used in operation. RFC 8310 does not specify technical changes to DoT, but gives extensive advice on how it should be deployed in many scenarios.
703 [DNSCRYPT-WEBSITE]
704 Denis, F., "DNSCrypt", December 2015,
705 <https://www.dnscrypt.org/>.
706
707
708
709
710
711
712 Hu, et al. Standards Track [Page 13]
713 RFC 7858 DNS over TLS May 2016
714
715
716 [DNSCurve] Dempsky, M., "DNSCurve: Link-Level Security for the Domain
717 Name System", Work in Progress, draft-dempsky-dnscurve-01,
718 February 2010.
719
720 [DNSoD] Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
721 (DNSoD)", Work in Progress, draft-ietf-dprive-dnsodtls-06,
722 April 2016.
723
724 [DNSSEC-TRIGGER]
725 NLnet Labs, "Dnssec-Trigger", May 2014,
726 <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
727
728 [IPSECA] Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A.
729 Mohaisen, "Opportunistic Encryption with DANE Semantics
730 and IPsec: IPSECA", Work in Progress,
731 draft-osterweil-dane-ipsec-03, July 2015.
732
733 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
734 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
735 <http://www.rfc-editor.org/info/rfc3234>.
736
737 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
738 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
739 DOI 10.17487/RFC3646, December 2003,
740 <http://www.rfc-editor.org/info/rfc3646>.
741
742 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
743 Rose, "DNS Security Introduction and Requirements",
744 RFC 4033, DOI 10.17487/RFC4033, March 2005,
745 <http://www.rfc-editor.org/info/rfc4033>.
746
747 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
748 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
749 2014, <http://www.rfc-editor.org/info/rfc7258>.
750
751 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
752 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
753 <http://www.rfc-editor.org/info/rfc7413>.
754
755 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
756 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
757 December 2014, <http://www.rfc-editor.org/info/rfc7435>.
758
759 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
760 DOI 10.17487/RFC7626, August 2015,
761 <http://www.rfc-editor.org/info/rfc7626>.
762
763
764
765
766
767 Hu, et al. Standards Track [Page 14]
768 RFC 7858 DNS over TLS May 2016
769
770
771 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
772 edns-tcp-keepalive EDNS0 Option", RFC 7828,
773 DOI 10.17487/RFC7828, April 2016,
774 <http://www.rfc-editor.org/info/rfc7828>.
775
776 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
777 DOI 10.17487/RFC7830, May 2016,
778 <http://www.rfc-editor.org/info/rfc7830>.
779
780 [TDNS] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
781 and N. Somaiya, "Connection-Oriented DNS to Improve
782 Privacy and Security", 2015 IEEE Symposium on Security and
783 Privacy (SP), DOI 10.1109/SP.2015.18,
784 <http://dx.doi.org/10.1109/SP.2015.18>.
785
786 [TLS-DTLS-PROFILES]
787 Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
788 and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
789 Work in Progress, draft-ietf-dprive-dtls-and-tls-
790 profiles-01, March 2016.
791
792 [TLS-FALSESTART]
793 Langley, A., Modadugu, N., and B. Moeller, "Transport
794 Layer Security (TLS) False Start", Work in Progress,
795 draft-ietf-tls-falsestart-02, May 2016.
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Hu, et al. Standards Track [Page 15]
823 RFC 7858 DNS over TLS May 2016
824
825
826 Appendix A. Out-of-Band Key-Pinned Privacy Profile Example
827
828 This section presents an example of how the out-of-band key-pinned
829 privacy profile could work in practice based on a minimal pin set
830 (two pins).
831
832 A DNS client system is configured with an out-of-band key-pinned
833 privacy profile from a network service, using a pin set containing
834 two pins. Represented in HTTP Public Key Pinning (HPKP) [RFC7469]
835 style, the pins are:
836
837 o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
838
839 o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
840
841 The client also configures the IP addresses of its expected DNS
842 server: perhaps 192.0.2.3 and 2001:db8::2:4.
843
844 The client connects to one of these addresses on TCP port 853 and
845 begins the TLS handshake: negotiation of TLS 1.2 with a Diffie-
846 Hellman key exchange. The server sends a certificate message with a
847 list of three certificates (A, B, and C) and signs the
848 ServerKeyExchange message correctly with the public key found in
849 certificate A.
850
851 The client now takes the SHA-256 digest of the SPKI in cert A and
852 compares it against both pins in the pin set. If either pin matches,
853 the verification is successful; the client continues with the TLS
854 connection and can make its first DNS query.
855
856 If neither pin matches the SPKI of cert A, the client verifies that
857 cert A is actually issued by cert B. If it is, it takes the SHA-256
858 digest of the SPKI in cert B and compares it against both pins in the
859 pin set. If either pin matches, the verification is successful.
860 Otherwise, it verifies that B was issued by C and then compares the
861 pins against the digest of C's SPKI.
862
863 If none of the SPKIs in the cryptographically valid chain of certs
864 match any pin in the pin set, the client closes the connection with
865 an error and marks the IP address as failed.
866
867
868
869
870
871
872
873
874
875
876
877 Hu, et al. Standards Track [Page 16]
878 RFC 7858 DNS over TLS May 2016
879
880
881 Acknowledgments
882
883 The authors would like to thank Stephane Bortzmeyer, John Dickinson,
884 Brian Haberman, Christian Huitema, Shumon Huque, Simon Joseffson,
885 Kim-Minh Kaplan, Simon Kelley, Warren Kumari, John Levine, Ilari
886 Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei
887 Tatuya, Tim Wicinski, and Glen Wiley for reviewing this
888 specification. They also thank Nikita Somaiya for early work on this
889 idea.
890
891 Work by Zi Hu, Liang Zhu, and John Heidemann on this document is
892 partially sponsored by the U.S. Dept. of Homeland Security (DHS)
893 Science and Technology Directorate, Homeland Security Advanced
894 Research Projects Agency (HSARPA), Cyber Security Division, BAA
895 11-01-RIKA and Air Force Research Laboratory, Information Directorate
896 under agreement number FA8750-12-2-0344, and contract number
897 D08PC75599.
898
899 Contributors
900
901 The below individuals contributed significantly to the document:
902
903 Sara Dickinson
904 Sinodun Internet Technologies
905 Magdalen Centre
906 Oxford Science Park
907 Oxford OX4 4GA
908 United Kingdom
909
910 Email: sara@sinodun.com
911 URI: http://sinodun.com
912
913
914 Daniel Kahn Gillmor
915 ACLU
916 125 Broad Street, 18th Floor
917 New York, NY 10004
918 United States
919
920
921
922
923
924
925
926
927
928
929
930
931
932 Hu, et al. Standards Track [Page 17]
933 RFC 7858 DNS over TLS May 2016
934
935
936 Authors' Addresses
937
938 Zi Hu
939 USC/Information Sciences Institute
940 4676 Admiralty Way, Suite 1133
941 Marina del Rey, CA 90292
942 United States
943
944 Phone: +1-213-587-1057
945 Email: zihu@outlook.com
946
947
948 Liang Zhu
949 USC/Information Sciences Institute
950 4676 Admiralty Way, Suite 1133
951 Marina del Rey, CA 90292
952 United States
953
954 Phone: +1-310-448-8323
955 Email: liangzhu@usc.edu
956
957
958 John Heidemann
959 USC/Information Sciences Institute
960 4676 Admiralty Way, Suite 1001
961 Marina del Rey, CA 90292
962 United States
963
964 Phone: +1-310-822-1511
965 Email: johnh@isi.edu
966
967
968 Allison Mankin
969 Independent
970
971 Phone: +1-301-728-7198
972 Email: Allison.mankin@gmail.com
973
974
975 Duane Wessels
976 Verisign Labs
977 12061 Bluemont Way
978 Reston, VA 20190
979 United States
980
981 Phone: +1-703-948-3200
982 Email: dwessels@verisign.com
983
984
985
986
987 Hu, et al. Standards Track [Page 18]
988 RFC 7858 DNS over TLS May 2016
989
990
991 Paul Hoffman
992 ICANN
993
994 Email: paul.hoffman@icann.org
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Hu, et al. Standards Track [Page 19]
1043
[DNSCRYPT-WEBSITE]
Denis, F., "DNSCrypt", December 2015,
<https://www.dnscrypt.org/>.
[DNSCRYPT-WEBSITE]
Denis, F., "DNSCrypt", December 2015,
<https://www.dnscrypt.orginfo/>.