1 Network Working Group R. Bellis
2 Request for Comments: 5625 Nominet UK
3 BCP: 152 August 2009
4 Category: Best Current Practice
5
6
7 DNS Proxy Implementation Guidelines
8
9 Abstract
10
11 This document provides guidelines for the implementation of DNS
12 proxies, as found in broadband gateways and other similar network
13 devices.
14
15 Status of This Memo
16
17 This document specifies an Internet Best Current Practices for the
18 Internet Community, and requests discussion and suggestions for
19 improvements. Distribution of this memo is unlimited.
20
21 Copyright Notice
22
23 Copyright (c) 2009 IETF Trust and the persons identified as the
24 document authors. All rights reserved.
25
26 This document is subject to BCP 78 and the IETF Trust's Legal
27 Provisions Relating to IETF Documents in effect on the date of
28 publication of this document (http://trustee.ietf.org/license-info).
29 Please review these documents carefully, as they describe your rights
30 and restrictions with respect to this document.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Bellis Best Current Practice [Page 1]
53 RFC 5625 DNS Proxy Implementation Guidelines August 2009
54
55
56 Table of Contents
57
58 1. Introduction ....................................................2
59 2. Terminology .....................................................3
60 3. The Transparency Principle ......................................3
61 4. Protocol Conformance ............................................4
62 4.1. Unexpected Flags and Data ..................................4
63 4.2. Label Compression ..........................................4
64 4.3. Unknown Resource Record Types ..............................4
65 4.4. Packet Size Limits .........................................4
66 4.4.1. TCP Transport .......................................5
67 4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
68 4.4.3. IP Fragmentation ....................................6
69 4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
70 5. DHCP's Interaction with DNS .....................................7
71 5.1. Domain Name Server (DHCP Option 6) .........................7
72 5.2. Domain Name (DHCP Option 15) ...............................8
73 5.3. DHCP Leases ................................................8
74 6. Security Considerations .........................................9
75 6.1. Forgery Resilience .........................................9
76 6.2. Interface Binding .........................................10
77 6.3. Packet Filtering ..........................................10
78 7. Acknowledgements ...............................................10
79 8. References .....................................................11
80 8.1. Normative References ......................................11
81 8.2. Informative References ....................................12
82
83 1. Introduction
84
85 Research has found ([SAC035], [DOTSE]) that many commonly used
86 broadband gateways (and similar devices) contain DNS proxies that are
87 incompatible in various ways with current DNS standards.
88
89 These proxies are usually simple DNS forwarders, but typically do not
90 have any caching capabilities. The proxy serves as a convenient
91 default DNS resolver for clients on the LAN, but relies on an
92 upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
93
94 Note that to ensure full DNS protocol interoperability it is
95 preferred that client stub resolvers should communicate directly with
96 full-feature, upstream recursive resolvers wherever possible.
97
98 That notwithstanding, this document describes the incompatibilities
99 that have been discovered and offers guidelines to implementors on
100 how to provide better interoperability in those cases where the
101 client must use the broadband gateway's DNS proxy.
102
103
104
105
106
107 Bellis Best Current Practice [Page 2]
108 RFC 5625 DNS Proxy Implementation Guidelines August 2009
109
110
111 2. Terminology
112
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
115 document are to be interpreted as described in [RFC2119].
116
117 3. The Transparency Principle
118
119 It is not considered practical for a simple DNS proxy to implement
120 all current and future DNS features.
121
122 There are several reasons why this is the case:
123
124 o Broadband gateways usually have limited hardware resources.
125
126 o Firmware upgrade cycles are long, and many users do not routinely
127 apply upgrades when they become available.
128
129 o No one knows what those future DNS features will be or how they
130 might be implemented.
131
132 o Doing so would substantially complicate the configuration user
133 interface (UI) of the device.
134
135 Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
136 below) are intended to be used as "hop-by-hop" mechanisms. If the
137 DNS proxy is considered to be such a "hop" in the resolution chain,
138 then for it to function correctly, it would need to be fully
139 compliant with all such mechanisms.
140
141 [SAC035] shows that the more actively a proxy participates in the DNS
142 protocol, the more likely it is that it will somehow interfere with
143 the flow of messages between the DNS client and the upstream
144 recursive resolvers.
145
146 The role of the proxy should therefore be no more and no less than to
147 receive DNS requests from clients on the LAN side, forward those
148 verbatim to one of the known upstream recursive resolvers on the WAN
149 side, and ensure that the whole response is returned verbatim to the
150 original client.
151
152 It is RECOMMENDED that proxies should be as transparent as possible,
153 such that any "hop-by-hop" mechanisms or newly introduced protocol
154 extensions operate as if the proxy were not there.
155
156 Except when required to enforce an active security or network policy
157 (such as maintaining a pre-authentication "walled garden"), end-users
158 SHOULD be able to send their DNS queries to specified upstream
159
160
161
162 Bellis Best Current Practice [Page 3]
163 RFC 5625 DNS Proxy Implementation Guidelines August 2009
164
165
166 resolvers, thereby bypassing the proxy altogether. In this case, the
167 gateway SHOULD NOT modify the DNS request or response packets in any
168 way.
169
170 4. Protocol Conformance
171
172 4.1. Unexpected Flags and Data
173
174 The Transparency Principle above, when combined with Postel's
175 Robustness Principle [RFC0793], suggests that DNS proxies should not
176 arbitrarily reject or otherwise drop requests or responses based on
177 perceived non-compliance with standards.
178
179 For example, some proxies have been observed to drop any packet
180 containing either the "Authentic Data" (AD) or "Checking Disabled"
181 (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
182 originally specified that these unused "Z" flag bits "MUST" be zero.
183 However, these flag bits were always intended to be reserved for
184 future use, so refusing to proxy any packet containing these flags
185 (now that uses for those flags have indeed been defined) is not
186 appropriate.
187
188 Therefore, proxies MUST ignore any unknown DNS flags and proxy those
189 packets as usual.
190
191 4.2. Label Compression
192
193 Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
194
195 Proxies MUST forward packets regardless of the presence or absence of
196 compressed labels therein.
197
198 4.3. Unknown Resource Record Types
199
200 [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
201 of unknown type transparently.
202
203 All requests and responses MUST be proxied regardless of the values
204 of the QTYPE and QCLASS fields.
205
206 Similarly, all responses MUST be proxied regardless of the values of
207 the TYPE and CLASS fields of any Resource Record therein.
208
209 4.4. Packet Size Limits
210
211 [RFC1035] specifies that the maximum size of the DNS payload in a UDP
212 packet is 512 octets. Where the required portions of a response
213 would not fit inside that limit, the DNS server MUST set the
214
215
216
217 Bellis Best Current Practice [Page 4]
218 RFC 5625 DNS Proxy Implementation Guidelines August 2009
219
220
221 "TrunCation" (TC) bit in the DNS response header to indicate that
222 truncation has occurred. There are however two standard mechanisms
223 (described in Sections 4.4.1 and 4.4.2) for transporting responses
224 larger than 512 octets.
225
226 Many proxies have been observed to truncate all responses at 512
227 octets, and others at a packet size related to the WAN MTU, in either
228 case doing so without correctly setting the TC bit.
229
230 Other proxies have been observed to remove the TC bit in server
231 responses that correctly had the TC bit set by the server.
232
233 If a DNS response is truncated but the TC bit is not set, then client
234 failures may result. In particular, a naive DNS client library might
235 suffer crashes due to reading beyond the end of the data actually
236 received.
237
238 Since UDP packets larger than 512 octets are now expected in normal
239 operation, proxies SHOULD NOT truncate UDP packets that exceed that
240 size. See Section 4.4.3 for recommendations for packet sizes
241 exceeding the WAN MTU.
242
243 If a proxy must unilaterally truncate a response, then the proxy MUST
244 set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
245 responses.
246
247 4.4.1. TCP Transport
248
249 Should a UDP query fail because of truncation, the standard fail-over
250 mechanism is to retry the query using TCP, as described in Section
251 6.1.3.2 of [RFC1123].
252
253 Whilst TCP transport is not strictly mandatory, it is supported by
254 the vast majority of stub resolvers and recursive servers. Lack of
255 support in the proxy prevents this fail-over mechanism from working.
256
257 DNS proxies MUST therefore be prepared to receive and forward queries
258 over TCP.
259
260 Note that it is unlikely that a client would send a request over TCP
261 unless it had already received a truncated UDP response. Some
262 "smart" proxies have been observed to first forward any request
263 received over TCP to an upstream resolver over UDP, only for the
264 response to be truncated, causing the proxy to retry over TCP. Such
265 behaviour increases network traffic and causes delay in DNS
266 resolution since the initial UDP request is doomed to fail.
267
268
269
270
271
272 Bellis Best Current Practice [Page 5]
273 RFC 5625 DNS Proxy Implementation Guidelines August 2009
274
275
276 Therefore, whenever a proxy receives a request over TCP, the proxy
277 SHOULD forward the query over TCP and SHOULD NOT attempt the same
278 query over UDP first.
279
280 4.4.2. Extension Mechanisms for DNS (EDNS0)
281
282 The "Extension Mechanism for DNS" [RFC2671] was introduced to allow
283 the transport of larger DNS packets over UDP and also to allow for
284 additional request and response flags.
285
286 A client may send an OPT Resource Record (OPT RR) in the Additional
287 Section of a request to indicate that it supports a specific receive
288 buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
289 by DNSSEC to indicate that DNSSEC-related RRs should be returned to
290 the client.
291
292 However, some proxies have been observed to either reject (with a
293 FORMERR response code) or black-hole any packet containing an OPT RR.
294 As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
295
296 4.4.3. IP Fragmentation
297
298 Support for UDP packet sizes exceeding the WAN MTU depends on the
299 gateway's algorithm for handling fragmented IP packets. Several
300 methods are possible:
301
302 1. Fragments are dropped.
303
304 2. Fragments are forwarded individually as they're received.
305
306 3. Complete packets are reassembled on the gateway and then re-
307 fragmented (if necessary) as they're forwarded to the client.
308
309 Method 1 above will cause compatibility problems with EDNS0 unless
310 the DNS client is configured to advertise an EDNS0 buffer size
311 limited to the WAN MTU less the size of the IP header. Note that RFC
312 2671 does recommend that the path MTU should be taken into account
313 when using EDNS0.
314
315 Also, whilst the EDNS0 specification allows for a buffer size of up
316 to 65535 octets, most common DNS server implementations do not
317 support a buffer size above 4096 octets.
318
319 Therefore (irrespective of which of the above methods is in use),
320 proxies SHOULD be capable of forwarding UDP packets up to a payload
321 size of at least 4096 octets.
322
323
324
325
326
327 Bellis Best Current Practice [Page 6]
328 RFC 5625 DNS Proxy Implementation Guidelines August 2009
329
330
331 NB: in theory, IP fragmentation may also occur if the LAN MTU is
332 smaller than the WAN MTU, although the author has not observed such a
333 configuration in use on any residential broadband service.
334
335 4.5. Secret Key Transaction Authentication for DNS (TSIG)
336
337 [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
338 requests and responses at the packet level.
339
340 Any modifications made to the DNS portions of a TSIG-signed query or
341 response packet (with the exception of the Query ID) will cause a
342 TSIG authentication failure.
343
344 DNS proxies MUST implement Section 4.7 of [RFC2845] and either
345 forward packets unchanged (as recommended above) or fully implement
346 TSIG.
347
348 As per Section 4.3, DNS proxies MUST be capable of proxying packets
349 containing TKEY [RFC2930] Resource Records.
350
351 NB: any DNS proxy (such as those commonly found in WiFi hotspot
352 "walled gardens") that transparently intercepts all DNS queries and
353 that returns unsigned responses to signed queries, will also cause
354 TSIG authentication failures.
355
356 5. DHCP's Interaction with DNS
357
358 Whilst this document is primarily about DNS proxies, most consumers
359 rely on DHCP [RFC2131] to obtain network configuration settings.
360 Such settings include the client machine's IP address, subnet mask,
361 and default gateway, but also include DNS-related settings.
362
363 It is therefore appropriate to examine how DHCP affects client DNS
364 configuration.
365
366 5.1. Domain Name Server (DHCP Option 6)
367
368 Most gateways default to supplying their own IP address in the DHCP
369 "Domain Name Server" option [RFC2132]. The net result is that
370 without explicit re-configuration many DNS clients will, by default,
371 send queries to the gateway's DNS proxy. This is understandable
372 behaviour given that the correct upstream settings are not usually
373 known at boot time.
374
375
376
377
378
379
380
381
382 Bellis Best Current Practice [Page 7]
383 RFC 5625 DNS Proxy Implementation Guidelines August 2009
384
385
386 Most gateways learn their own DNS settings via values supplied by an
387 ISP via DHCP or PPP over the WAN interface. However, whilst many
388 gateways do allow the device administrator to override those values,
389 some gateways only use those supplied values to affect the proxy's
390 own forwarding function, and do not offer these values via DHCP.
391
392 When using such a device, the only way to avoid using the DNS proxy
393 is to hard-code the required values in the client operating system.
394 This may be acceptable for a desktop system but it is inappropriate
395 for mobile devices that are regularly used on many different
396 networks.
397
398 As per Section 3, end-users SHOULD be able to send their DNS queries
399 directly to specified upstream resolvers, ideally without hard-coding
400 those settings in their stub resolver.
401
402 It is therefore RECOMMENDED that gateways SHOULD support device-
403 administrator configuration of values for the "Domain Name Server"
404 DHCP option.
405
406 5.2. Domain Name (DHCP Option 15)
407
408 A significant amount of traffic to the DNS Root Name Servers is for
409 invalid top-level domain names, and some of that traffic can be
410 attributed to particular equipment vendors whose firmware defaults
411 this DHCP option to specific values.
412
413 Since no standard exists for a "local" scoped domain name suffix, it
414 is RECOMMENDED that the default value for this option SHOULD be
415 empty, and that this option MUST NOT be sent to clients when no value
416 is configured.
417
418 5.3. DHCP Leases
419
420 It is noted that some DHCP servers in broadband gateways offer, by
421 default, their own IP address for the "Domain Name Server" option (as
422 described above) but then automatically start offering the upstream
423 servers' addresses once they've been learnt over the WAN interface.
424
425 In general, this behaviour is highly desirable, but the effect for
426 the end-user is that the settings used depend on whether the DHCP
427 lease was obtained before or after the WAN link was established.
428
429 If the DHCP lease is obtained whilst the WAN link is down, then the
430 DHCP client (and hence the DNS client) will not receive the correct
431 values until the DHCP lease is renewed.
432
433
434
435
436
437 Bellis Best Current Practice [Page 8]
438 RFC 5625 DNS Proxy Implementation Guidelines August 2009
439
440
441 Whilst no specific recommendations are given here, vendors may wish
442 to give consideration to the length of DHCP leases and to whether
443 some mechanism for forcing a DHCP lease renewal might be appropriate.
444
445 Another possibility is that the learnt upstream values might be
446 persisted in non-volatile memory such that on reboot the same values
447 can be automatically offered via DHCP. However, this does run the
448 risk that incorrect values are initially offered if the device is
449 moved or connected to another ISP.
450
451 Alternatively, the DHCP server might only issue very short (i.e., 60
452 second) leases while the WAN link is down, only reverting to more
453 typical lease lengths once the WAN link is up and the upstream DNS
454 servers are known. Indeed, with such a configuration it may be
455 possible to avoid the need to implement a DNS proxy function in the
456 broadband gateway at all.
457
458 6. Security Considerations
459
460 This document introduces no new protocols. However, there are some
461 security-related recommendations for vendors that are listed here.
462
463 6.1. Forgery Resilience
464
465 Whilst DNS proxies are not usually full-feature resolvers, they
466 nevertheless share some characteristics with them.
467
468 Notwithstanding the recommendations above about transparency, many
469 DNS proxies are observed to pick a new Query ID for outbound requests
470 to ensure that responses are directed to the correct client.
471
472 NB: changing the Query ID is acceptable and compatible with proxying
473 TSIG-signed packets since the TSIG signature calculation is based on
474 the original message ID, which is carried in the TSIG RR.
475
476 It has been standard guidance for many years that each DNS query
477 should use a randomly generated Query ID. However, many proxies have
478 been observed picking sequential Query IDs for successive requests.
479
480 It is strongly RECOMMENDED that DNS proxies follow the relevant
481 recommendations in [RFC5452], particularly those in Section 9.2
482 relating to randomisation of Query IDs and source ports. This also
483 applies to source port selection within any NAT function.
484
485 If a DNS proxy is running on a broadband gateway with NAT that is
486 compliant with [RFC4787], then it SHOULD also follow the
487 recommendations in Section 10 of [RFC5452] concerning how long DNS
488 state is kept.
489
490
491
492 Bellis Best Current Practice [Page 9]
493 RFC 5625 DNS Proxy Implementation Guidelines August 2009
494
495
496 6.2. Interface Binding
497
498 Some gateways have been observed to have their DNS proxy listening on
499 both internal (LAN) and external (WAN) interfaces. In this
500 configuration, it is possible for the proxy to be used to mount
501 reflector attacks as described in [RFC5358].
502
503 The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
504 the WAN interfaces of the device.
505
506 6.3. Packet Filtering
507
508 The Transparency and Robustness Principles are not entirely
509 compatible with the deep packet-inspection features of security
510 appliances such as firewalls, which are intended to protect systems
511 on the inside of a network from rogue traffic.
512
513 However, a clear distinction may be made between traffic that is
514 intrinsically malformed and that which merely contains unexpected
515 data.
516
517 Examples of malformed packets that MAY be dropped include:
518
519 o invalid compression pointers (i.e., those that point outside of
520 the current packet or that might cause a parsing loop)
521
522 o incorrect counts for the Question, Answer, Authority, and
523 Additional Sections (although care should be taken where
524 truncation is a possibility)
525
526 Dropped packets will cause the client to repeatedly retransmit the
527 original request, with the client only detecting the error after
528 several retransmit intervals.
529
530 In these circumstances, proxies SHOULD synthesise a suitable DNS
531 error response to the client (i.e., SERVFAIL) instead of dropping the
532 packet completely. This will allow the client to detect the error
533 immediately.
534
535 7. Acknowledgements
536
537 The author would particularly like to acknowledge the assistance of
538 Lisa Phifer of Core Competence. In addition, the author is grateful
539 for the feedback from the members of the DNSEXT Working Group.
540
541
542
543
544
545
546
547 Bellis Best Current Practice [Page 10]
548 RFC 5625 DNS Proxy Implementation Guidelines August 2009
549
550
551 8. References
552
553 8.1. Normative References
554
555 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
556 RFC 793, September 1981.
557
558 [RFC1035] Mockapetris, P., "Domain names - implementation and
559 specification", STD 13, RFC 1035, November 1987.
560
561 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
562 and Support", STD 3, RFC 1123, October 1989.
563
564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
565 Requirement Levels", BCP 14, RFC 2119, March 1997.
566
567 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
568 RFC 2131, March 1997.
569
570 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
571 Extensions", RFC 2132, March 1997.
572
573 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
574 RFC 2671, August 1999.
575
576 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
577 Wellington, "Secret Key Transaction Authentication for DNS
578 (TSIG)", RFC 2845, May 2000.
579
580 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
581 RR)", RFC 2930, September 2000.
582
583 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
584 (RR) Types", RFC 3597, September 2003.
585
586 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
587 Rose, "Protocol Modifications for the DNS Security
588 Extensions", RFC 4035, March 2005.
589
590 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
591 (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
592 RFC 4787, January 2007.
593
594 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
595 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
596 October 2008.
597
598
599
600
601
602 Bellis Best Current Practice [Page 11]
603 RFC 5625 DNS Proxy Implementation Guidelines August 2009
604
605
606 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
607 Resilient against Forged Answers", RFC 5452, January 2009.
608
609 8.2. Informative References
610
611 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
612 Routers", February 2008,
613 <http://www.iis.se/docs/Routertester_en.pdf>.
614
615 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
616 Broadband Routers and Firewalls", September 2008,
617 <http://www.icann.org/committees/security/sac035.pdf>.
618
619 Author's Address
620
621 Ray Bellis
622 Nominet UK
623 Edmund Halley Road
624 Oxford OX4 4DQ
625 United Kingdom
626
627 Phone: +44 1865 332211
628 EMail: ray.bellis@nominet.org.uk
629 URI: http://www.nominet.org.uk/
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657 Bellis Best Current Practice [Page 12]
658
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.