idnits 2.17.1 draft-ietf-dnsext-dnsproxy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT R. Bellis 3 Internet-Draft Nominet UK 4 Intended status: BCP March 3, 2009 5 Expires: September 4, 2009 7 DNS Proxy Implementation Guidelines 8 draft-ietf-dnsext-dnsproxy-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 4, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document provides guidelines for the implementation of DNS 47 proxies, as found in broadband gateways and other similar network 48 devices. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 58 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 60 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5 62 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5 63 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5 64 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6 65 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 66 4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7 68 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7 69 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 7 70 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8 71 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9 75 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10 76 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Recent research ([SAC035], [DOTSE]) has found that many commonly-used 93 broadband gateways (and similar devices) contain DNS proxies which 94 are incompatible in various ways with current DNS standards. 96 These proxies are usual simple DNS forwarders, but do not usually 97 have any caching capabilities. The proxy serves as a convenient 98 default DNS resolver for clients on the LAN, but relies on an 99 upstream resolver (e.g. at an ISP) to perform recursive DNS lookups. 101 This document describes the incompatibilities that have been 102 discovered and offers guidelines to implementors on how to provide 103 maximum interoperability. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. The Transparency Principle 113 It is not considered practical for a simple DNS proxy to implement 114 all current and future DNS features. 116 There are several reasons why this is the case: 118 o broadband gateways usually have limited hardware resources 119 o firmware upgrade cycles are long, and many users do not routinely 120 apply upgrades when they become available 121 o no-one knows what those future DNS features will be, nor how they 122 might be implemented 123 o it would substantially complicate the configuration UI of the 124 device 126 Furthermore some modern DNS protocol extensions (see e.g. EDNS0, 127 below) are intended to be used as "hop-by-hop" mechanisms. If the 128 DNS proxy is considered to be such a "hop" in the resolution chain, 129 then for it to function correctly, it would need to be fully 130 compliant with all such mechanisms. 132 Research [SAC035] has shown that the more actively a proxy 133 participates in the DNS protocol then the more likely it is that it 134 will somehow interfere with the flow of messages between the DNS 135 client and the upstream recursive resolvers. 137 The role of the proxy should therefore be no more and no less than to 138 receive DNS requests from clients on the LAN side, forward those 139 verbatim to one of the known upstream recursive resolvers on the WAN 140 side, and ensure that the whole response is returned verbatim to the 141 original client. 143 It is RECOMMENDED that proxies should be as transparent as possible, 144 such that any "hop-by-hop" mechanisms or newly introduced protocol 145 extensions operate as if the proxy were not there. 147 Except when required to enforce an active security or network policy 148 (such as maintaining a pre-authentication "walled garden"), end-users 149 SHOULD be able to send their DNS queries to specified upstream 150 resolvers, thereby bypassing the proxy altogether. In this case, the 151 gateway SHOULD NOT modify the DNS request or response packets in any 152 way. 154 4. Protocol Conformance 156 4.1. Unexpected Flags and Data 158 The Transparency Principle above, when combined with Postel's 159 Robustness Principle [RFC0793], suggests that DNS proxies should not 160 arbitrarily reject or otherwise drop requests or responses based on 161 perceived non-compliance with standards. 163 For example, some proxies have been observed to drop any packet 164 containing either the "Authentic Data" (AD) or "Checking Disabled" 165 (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] 166 originally specified that these unused "Z" flag bits "MUST" be zero. 167 However these flag bits were always intended to be reserved for 168 future use, so refusing to proxy any packet containing these flags 169 (now that uses for those flags have indeed been defined) is not 170 appropriate. 172 Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown 173 DNS flags and proxy those packets as usual. 175 4.2. Label Compression 177 Compression of labels as per Section 4.1.4 of [RFC1035] is optional. 179 Proxies MUST forward packets regardless of the presence or absence of 180 compressed labels therein. 182 4.3. Unknown Resource Record Types 184 [RFC3597] requires that resolvers MUST handle Resource Records (RRs) 185 of unknown type transparently. 187 All requests and responses MUST be proxied regardless of the values 188 of the QTYPE and QCLASS fields. 190 Similarly all responses MUST be proxied regardless of the values of 191 the TYPE and CLASS fields of any Resource Record therein. 193 4.4. Packet Size Limits 195 [RFC1035] specifies that the maximum size of the DNS payload in a UDP 196 packet is 512 octets. Where the required portions of a response 197 would not fit inside that limit the DNS server MUST set the 198 "TrunCation" (TC) bit in the DNS response header to indicate that 199 truncation has occurred. There are however two standard mechanisms 200 (described below) for transporting responses larger than 512 octets. 202 Many proxies have been observed to truncate all responses at 512 203 octets, and others at a packet size related to the WAN MTU, in either 204 case doing so without correctly setting the TC bit. 206 Other proxies have been observed to remove the TC bit in server 207 responses which correctly had the TC bit set by the server. 209 If a DNS response is truncated but the TC bit is not set then client 210 failures may result, in particular a naive DNS client library might 211 suffer crashes due to reading beyond the end of the data actually 212 received. 214 Since UDP packets larger than 512 octets are now expected in normal 215 operation, proxies SHOULD NOT truncate UDP packets that exceed that 216 size. See Section 4.4.3 for recommendations for packet sizes 217 exceeding the WAN MTU. 219 If a proxy must unilaterally truncate a response then the proxy MUST 220 set the TC bit. Similarly, proxies MUST NOT remove the TC bit from 221 responses. 223 4.4.1. TCP Transport 225 Should a UDP query fail because of truncation, the standard fail-over 226 mechanism is to retry the query using TCP, as described in section 227 6.1.3.2 of [RFC1123]. 229 DNS proxies SHOULD therefore be prepared to receive and forward 230 queries over TCP. 232 Note that it is unlikely that a client would send a request over TCP 233 unless it had already received a truncated UDP response. Some 234 "smart" proxies have been observed to first forward any request 235 received over TCP to an upstream resolver over UDP, only for the 236 response to be truncated, causing the proxy to retry over TCP. Such 237 behaviour increases network traffic and causes delay in DNS 238 resolution since the initial UDP request is doomed to fail. 240 Therefore whenever a proxy receives a request over TCP, the proxy 241 SHOULD forward the query over TCP and SHOULD NOT attempt the same 242 query over UDP first. 244 4.4.2. Extension Mechanisms for DNS (EDNS0) 246 The Extension Mechanism for DNS [RFC2671] was introduced to allow the 247 transport of larger DNS packets over UDP and also to allow for 248 additional request and response flags. 250 A client may send an OPT Resource Record (OPT RR) in the Additional 251 Section of a request to indicate that it supports a specific receive 252 buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used 253 by DNSSEC to indicate that DNSSEC-related RRs should be returned to 254 the client. 256 However some proxies have been observed to either reject (with a 257 FORMERR response code) or black-hole any packet containing an OPT RR. 258 As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. 260 4.4.3. IP Fragmentation 262 Support for UDP packet sizes exceeding the WAN MTU depends on the 263 gateway's algorithm for handling fragmented IP packets. Several 264 options are possible: 266 1. fragments are dropped 267 2. fragments are forwarded individually as they're received 268 3. complete packets are reassembled on the gateway, and then re- 269 fragmented (if necessary) as they're forwarded to the client 271 Option 1 above will cause compatibility problems with EDNS0 unless 272 the DNS client is configured to advertise an EDNS0 buffer size 273 limited to 28 octets less than the MTU. Note that RFC 2671 does 274 recommend that the path MTU should be taken into account when using 275 EDNS0. 277 Also, whilst the EDNS0 specification allows for a buffer size of up 278 to 65535 octets, most common DNS server implementations do not 279 support a buffer size above 4096 octets. 281 Therefore proxies SHOULD (whichever of options 2 or 3 above is in 282 use) be capable of forwarding UDP packets up to a payload size of at 283 least 4096 octets. 285 NB: in theory IP fragmentation may also occur if the LAN MTU is 286 smaller than the WAN MTU, although the author has not observed such a 287 configuration in use on any residential broadband service. 289 4.5. Secret Key Transaction Authentication for DNS (TSIG) 291 [RFC2845] defines TSIG, which is a mechanism for authenticating DNS 292 requests and responses at the packet level. 294 Any modifications made to the DNS portions of a TSIG-signed query or 295 response packet (with the exception of the Query ID) will cause a 296 TSIG authentication failure. 298 DNS proxies MUST implement Section 4.7 of [RFC2845] and either 299 forward packets unchanged (as recommended above) or fully implement 300 TSIG. 302 As per Section 4.3, DNS proxies SHOULD be capable of proxying packets 303 containing TKEY [RFC2930] Resource Records. 305 NB: any DNS proxy (such as those commonly found in WiFi hotspot 306 "walled gardens") which transparently intercepts all DNS queries, and 307 which returns unsigned responses to signed queries, will also cause 308 TSIG authentication failures. 310 5. DHCP's Interaction with DNS 312 Whilst this document is primarily about DNS proxies, most consumers 313 rely on DHCP [RFC2131] to obtain network configuration settings. 314 Such settings include the client machine's IP address, subnet mask 315 and default gateway, but also include DNS related settings. 317 It is therefore appropriate to examine how DHCP affects client DNS 318 configuration. 320 5.1. Domain Name Server (DHCP Option 6) 322 Most gateways default to supplying their own IP address in the DHCP 323 "Domain Name Server" option [RFC2132]. The net result is that 324 without explicit re-configuration many DNS clients will by default 325 send queries to the gateway's DNS proxy. This is understandable 326 behaviour given that the correct upstream settings are not usually 327 known at boot time. 329 Most gateways learn their own DNS settings via values supplied by an 330 ISP via DHCP or PPP over the WAN interface. However whilst many 331 gateways do allow the end-user to override those values, some 332 gateways only use those end-user supplied values to affect the 333 proxy's own forwarding function, and do not offer these values via 334 DHCP. 336 When using such a device the only way to avoid using the DNS proxy is 337 to hard-code the required values in the client operating system. 338 This may be acceptable for a desktop system but it is inappropriate 339 for mobile devices which are regularly used on many different 340 networks. 342 As per Section 3, end-users SHOULD be able to send their DNS queries 343 directly to specified upstream resolvers, ideally without hard-coding 344 those settings in their stub resolver. 346 It is therefore RECOMMENDED that gateways SHOULD support end-user 347 configuration of values for the "Domain Name Server" DHCP option. 349 5.2. Domain Name (DHCP Option 15) 351 A significant amount of traffic to the DNS Root Name Servers is for 352 invalid top-level domain names, and some of that traffic can be 353 attributed to particular equipment vendors whose firmware defaults 354 this DHCP option to specific values. 356 Since no standard exists for a "local" scoped domain name suffix it 357 is RECOMMENDED that the default value for this option SHOULD be 358 empty, and that this option SHOULD NOT be sent to clients when no 359 value is configured. 361 5.3. DHCP Leases 363 It is noted that some DHCP servers in broadband gateways by default 364 offer their own IP address for the "Domain Name Server" option (as 365 describe above) but then automatically start offering the upstream 366 settings once they've been learnt over the WAN interface. 368 In general this behaviour is highly desirable, but the effect for the 369 end-user is that the settings used depend on whether the DHCP lease 370 was obtained before or after the WAN link was established. 372 If the DHCP lease is obtained whilst the WAN link is down then the 373 DHCP client (and hence the DNS client) will not receive the correct 374 values until the DHCP lease is renewed. 376 Whilst no specific recommendations are given here, vendors may wish 377 to give consideration to the length of DHCP leases, and whether some 378 mechanism for forcing a DHCP lease renewal might be appropriate. 380 Another possibility is that the learnt upstream values might be 381 persisted in non-volatile memory such that on reboot the same values 382 can be automatically offered via DHCP. However this does run the 383 risk that incorrect values are initially offered if the device is 384 moved or connected to another ISP. 386 Alternatively, the DHCP server might only issue very short (i.e. 60 387 second) leases while the WAN link is down, only reverting to more 388 typical lease lengths once the WAN link is up and the upstream DNS 389 servers are known. Indeed with such a configuration it may be 390 possible to avoid the need to implement a DNS proxy function in the 391 broadband gateway at all. 393 6. Security Considerations 395 This document introduces no new protocols. However there are some 396 security related recommendations for vendors that are listed here. 398 6.1. Forgery Resilience 400 Whilst DNS proxies are not usually full-feature resolvers they 401 nevertheless share some characteristics with them. 403 Notwithstanding the recommendations above about transparency many DNS 404 proxies are observed to pick a new Query ID for outbound requests to 405 ensure that responses are directed to the correct client. 407 NB: Changing the Query ID is acceptable and compatible with proxying 408 TSIG-signed packets since the TSIG signature calculation is based on 409 the original message ID which is carried in the TSIG RR. 411 It has been standard guidance for many years that each DNS query 412 should use a randomly generated Query ID. However many proxies have 413 been observed picking sequential Query IDs for successive requests. 415 It is strongly RECOMMENDED that DNS proxies follow the relevant 416 recommendations in [RFC5452], particularly those in Section 9.2 417 relating to randomisation of Query IDs and source ports. This also 418 applies to source port selection within any NAT function. 420 If a DNS proxy is running on a broadband gateway with NAT that is 421 compliant with [RFC4787] then it SHOULD also follow the 422 recommendations in Section 10 of [RFC5452] concerning how long DNS 423 state is kept. 425 6.2. Interface Binding 427 Some gateways have been observed to have their DNS proxy listening on 428 both internal (LAN) and external (WAN) interfaces. In this 429 configuration it is possible for the proxy to be used to mount 430 reflector attacks as described in [RFC5358] 432 The DNS proxy in a gateway SHOULD NOT by default be accessible from 433 the WAN interfaces of the device. 435 6.3. Packet Filtering 437 The Transparency and Robustness Principles are not entirely 438 compatible with the Deep Packet Inspection features of security 439 appliances such as firewalls which are intended to protect systems on 440 the inside of a network from rogue traffic. 442 However a clear distinction may be made between traffic that is 443 intrinsically malformed and that which merely contains unexpected 444 data. 446 Examples of malformed packets which MAY be dropped include: 448 o invalid compression pointers (i.e. those that point outside of the 449 current packet, or which might cause a parsing loop). 450 o incorrect counts for the Question, Answer, Authority and 451 Additional Sections (although care should be taken where 452 truncation is a possibility). 454 Since dropped packets will cause the client to repeatedly retransmit 455 the original request, it is RECOMMENDED that proxies SHOULD instead 456 return a suitable DNS error response to the client (i.e. SERVFAIL) 457 instead of dropping the packet completely. 459 7. IANA Considerations 461 This document requests no IANA actions. 463 8. Change Log 465 draft-ietf-dnsproxy-03 466 Editorial nits and mention of LAN MTU (from Alex Bligh) 468 draft-ietf-dnsproxy-02 469 Changed "router" to "gateway" throughout (David Oran) 470 Updated forgery resilience reference 471 Elaboration on bypassability (from Nicholas W.) 472 Elaboration on NAT source port randomisation (from Nicholas W.) 473 Mention of using short DHCP leases while the WAN link is down 474 (from Ralph Droms) 475 Further clarification on permissibility of altering QID when using 476 TSIG 478 draft-ietf-dnsproxy-01 479 Strengthened recommendations about truncation (from Shane Kerr) 480 New TSIG text (with help from Olafur) 481 Additional forgery resilience text (from Olafur) 482 Compression support (from Olafur) 483 Correction of text re: QID changes and compatibility with TSIG 485 draft-ietf-dnsproxy-00 486 Changed recommended DPI error to SERVFAIL (from Jelte) 487 Changed example for invalid compression pointers (from Wouter). 488 Note about TSIG implications of changing Query ID (from Wouter). 489 Clarified TC-bit text (from Wouter) 490 Extra text about proxy bypass (Nicholas W.) 492 draft-bellis-dnsproxy-00 493 Initial draft 495 9. Acknowledgements 497 The author would particularly like to acknowledge the assistance of 498 Lisa Phifer of Core Competence. In addition the author is grateful 499 for the feedback from the members of the DNSEXT Working Group. 501 10. References 503 10.1. Normative References 505 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 506 RFC 793, September 1981. 508 [RFC1035] Mockapetris, P., "Domain names - implementation and 509 specification", STD 13, RFC 1035, November 1987. 511 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 512 and Support", STD 3, RFC 1123, October 1989. 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 518 RFC 2131, March 1997. 520 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 521 Extensions", RFC 2132, March 1997. 523 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 524 RFC 2671, August 1999. 526 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 527 Wellington, "Secret Key Transaction Authentication for DNS 528 (TSIG)", RFC 2845, May 2000. 530 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 531 RR)", RFC 2930, September 2000. 533 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 534 (RR) Types", RFC 3597, September 2003. 536 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 537 Rose, "Protocol Modifications for the DNS Security 538 Extensions", RFC 4035, March 2005. 540 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 541 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 542 RFC 4787, January 2007. 544 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 545 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 546 October 2008. 548 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 549 Resilient against Forged Answers", RFC 5452, January 2009. 551 10.2. Informative References 553 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 554 Routers", February 2008, 555 . 557 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 558 Broadband Routers and Firewalls", September 2008, 559 . 561 Author's Address 563 Ray Bellis 564 Nominet UK 565 Edmund Halley Road 566 Oxford OX4 4DQ 567 United Kingdom 569 Phone: +44 1865 332211 570 Email: ray.bellis@nominet.org.uk 571 URI: http://www.nominet.org.uk/