idnits 2.17.1 draft-ietf-dnsext-dnsproxy-02.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 2, 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 2, 2009 5 Expires: September 3, 2009 7 DNS Proxy Implementation Guidelines 8 draft-ietf-dnsext-dnsproxy-02 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 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 documents 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 directly 114 implement 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 compliant 130 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. In this case, the proxy SHOULD NOT modify the packets in 151 any way except for modifying IP and TCP/UDP headers as required by 152 NAT. 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 incorrectly remove the TC bit in 207 server 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 a 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 it is RECOMMENDED (whichever of options 2 or 3 above is in 282 use) that gateways SHOULD be capable of forwarding UDP packets up to 283 a payload size of at least 4096 octets. 285 4.5. Secret Key Transaction Authentication for DNS (TSIG) 287 [RFC2845] defines TSIG, which is a mechanism for authenticating DNS 288 requests and responses at the packet level. 290 Any modifications made to the DNS portions of a TSIG-signed query or 291 response packet (with the exception of the Query ID) will cause a 292 TSIG authentication failure. 294 DNS proxies MUST implement Section 4.7 of [RFC2845] and either 295 forward packets unchanged (as recommended above) or fully implement 296 TSIG. 298 As per Section 4.3, DNS proxies SHOULD be capable of proxying packets 299 containing TKEY [RFC2930] Resource Records. 301 NB: any DNS proxy (such as those commonly found in WiFi hotspot 302 "walled gardens") which transparently intercepts all DNS queries, and 303 which returns unsigned responses to signed queries, will also cause 304 TSIG authentication failures. 306 5. DHCP's Interaction with DNS 308 Whilst this document is primarily about DNS proxies, most consumers 309 rely on DHCP [RFC2131] to obtain network configuration settings. 310 Such settings include the client machine's IP address, subnet mask 311 and default gateway, but also include DNS related settings. 313 It is therefore appropriate to examine how DHCP affects client DNS 314 configuration. 316 5.1. Domain Name Server (DHCP Option 6) 318 Most gateways default to supplying their own IP address in the DHCP 319 "Domain Name Server" option [RFC2132]. The net result is that 320 without explicit re-configuration many DNS clients will by default 321 send queries to the gateway's DNS proxy. This is understandable 322 behaviour given that the correct upstream settings are not usually 323 known at boot time. 325 Most gateways learn their own DNS settings via values supplied by an 326 ISP via DHCP or PPP over the WAN interface. However whilst many 327 gateways do allow the end-user to override those values, some 328 gateways only use those end-user supplied values to affect the 329 proxy's own forwarding function, and do not offer these values via 330 DHCP. 332 When using such a device the only way to avoid using the DNS proxy is 333 to hard-code the required values in the client operating system. 334 This may be acceptable for a desktop system but it is inappropriate 335 for mobile devices which are regularly used on many different 336 networks. 338 As per Section 3, end-users SHOULD be able to send their DNS queries 339 directly to specified upstream resolvers, ideally without hard-coding 340 those settings in their stub resolver. 342 It is therefore RECOMMENDED that gateways SHOULD support end-user 343 configuration of values for the "Domain Name Server" DHCP option. 345 5.2. Domain Name (DHCP Option 15) 347 A significant amount of traffic to the DNS Root Name Servers is for 348 invalid top-level domain names, and some of that traffic can be 349 attributed to particular equipment vendors whose firmware defaults 350 this DHCP option to specific values. 352 Since no standard exists for a "local" scoped domain name suffix it 353 is RECOMMENDED that the default value for this option SHOULD be 354 empty, and that this option SHOULD NOT be sent to clients when no 355 value is configured. 357 5.3. DHCP Leases 359 It is noted that some DHCP servers in broadband gateways by default 360 offer their own IP address for the "Domain Name Server" option (as 361 describe above) but then automatically start offering the upstream 362 settings once they've been learnt over the WAN interface. 364 In general this behaviour is highly desirable, but the effect for the 365 end-user is that the settings used depend on whether the DHCP lease 366 was obtained before or after the WAN link was established. 368 If the DHCP lease is obtained whilst the WAN link is down then the 369 DHCP client (and hence the DNS client) will not receive the correct 370 values until the DHCP lease is renewed. 372 Whilst no specific recommendations are given here, vendors may wish 373 to give consideration to the length of DHCP leases, and whether some 374 mechanism for forcing a DHCP lease renewal might be appropriate. 376 Another possibility is that the learnt upstream values might be 377 persisted in non-volatile memory such that on reboot the same values 378 can be automatically offered via DHCP. However this does run the 379 risk that incorrect values are initially offered if the device is 380 moved or connected to another ISP. 382 Alternatively, the DHCP server might only issue very short (i.e. 60 383 second) leases while the WAN link is down, only reverting to more 384 typical lease lengths once the WAN link is up and the upstream DNS 385 servers are known. Indeed with such a configuration it may be 386 possible to avoid the need to implement a DNS proxy function in the 387 broadband gateway at all. 389 6. Security Considerations 391 This document introduces no new protocols. However there are some 392 security related recommendations for vendors that are listed here. 394 6.1. Forgery Resilience 396 Whilst DNS proxies are not usually full-feature resolvers they 397 nevertheless share some characteristics with them. 399 Notwithstanding the recommendations above about transparency many DNS 400 proxies are observed to pick a new Query ID for outbound requests to 401 ensure that responses are directed to the correct client. 403 NB: Changing the Query ID is acceptable and compatible with proxying 404 TSIG-signed packets since the TSIG signature calculation is based on 405 the original message ID which is carried in the TSIG RR. 407 It has been standard guidance for many years that each DNS query 408 should use a randomly generated Query ID. However many proxies have 409 been observed picking sequential Query IDs for successive requests. 411 It is strongly RECOMMENDED that DNS proxies follow the relevant 412 recommendations in [RFC5452], particularly those in Section 9.2 413 relating to randomisation of Query IDs and source ports. This also 414 applies to source port selection within any NAT function. 416 If a DNS proxy is running on a broadband gateway with NAT that is 417 compliant with [RFC4787] then it SHOULD also follow the 418 recommendations for how long DNS state is kept from Section 10 of 419 [RFC5452] 421 6.2. Interface Binding 423 Some gateways have been observed to have their DNS proxy listening on 424 both internal (LAN) and external (WAN) interfaces. In this 425 configuration it is possible for the proxy to be used to mount 426 reflector attacks as described in [RFC5358] 428 The DNS proxy in a gateway SHOULD NOT by default be accessible from 429 the WAN interfaces of the device. 431 6.3. Packet Filtering 433 The Transparency and Robustness Principles are not entirely 434 compatible with the Deep Packet Inspection features of security 435 appliances such as firewalls which are intended to protect systems on 436 the inside of a network from rogue traffic. 438 However a clear distinction may be made between traffic that is 439 intrinsically malformed and that which merely contains unexpected 440 data. 442 Examples of malformed packets which MAY be dropped include: 444 o invalid compression pointers (i.e. those that point outside of the 445 current packet, or which might cause a parsing loop). 446 o incorrect counts for the Question, Answer, Authority and 447 Additional Sections (although care should be taken where 448 truncation is a possibility). 450 Since dropped packets will cause the client to repeatedly retransmit 451 the original request, it is RECOMMENDED that proxies SHOULD instead 452 return a suitable DNS error response to the client (i.e. SERVFAIL) 453 instead of dropping the packet completely. 455 7. IANA Considerations 457 This document requests no IANA actions. 459 8. Change Log 461 draft-ietf-dnsproxy-02 462 Changed "router" to "gateway" throughout (David Oran) 463 Updated forgery resilience reference 464 Elaboration on bypassability (from Nicholas W.) 465 Elaboration on NAT source port randomisation (from Nicholas W.) 466 Mention of using short DHCP leases while the WAN link is down 467 (from Ralph Droms) 468 Further clarification on permissibility of altering QID when using 469 TSIG 471 draft-ietf-dnsproxy-01 472 Strengthened recommendations about truncation (from Shane Kerr) 473 New TSIG text (with help from Olafur) 474 Additional forgery resilience text (from Olafur) 475 Compression support (from Olafur) 476 Correction of text re: QID changes and compatibility with TSIG 478 draft-ietf-dnsproxy-00 479 Changed recommended DPI error to SERVFAIL (from Jelte) 480 Changed example for invalid compression pointers (from Wouter). 481 Note about TSIG implications of changing Query ID (from Wouter). 482 Clarified TC-bit text (from Wouter) 483 Extra text about proxy bypass (Nicholas W.) 485 draft-bellis-dnsproxy-00 486 Initial draft 488 9. Acknowledgements 490 The author would particularly like to acknowledge the assistance of 491 Lisa Phifer of Core Competence. In addition the author is grateful 492 for the feedback from the members of the DNSEXT Working Group. 494 10. References 496 10.1. Normative References 498 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 499 RFC 793, September 1981. 501 [RFC1035] Mockapetris, P., "Domain names - implementation and 502 specification", STD 13, RFC 1035, November 1987. 504 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 505 and Support", STD 3, RFC 1123, October 1989. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 511 RFC 2131, March 1997. 513 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 514 Extensions", RFC 2132, March 1997. 516 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 517 RFC 2671, August 1999. 519 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 520 Wellington, "Secret Key Transaction Authentication for DNS 521 (TSIG)", RFC 2845, May 2000. 523 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 524 RR)", RFC 2930, September 2000. 526 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 527 (RR) Types", RFC 3597, September 2003. 529 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 530 Rose, "Protocol Modifications for the DNS Security 531 Extensions", RFC 4035, March 2005. 533 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 534 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 535 RFC 4787, January 2007. 537 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 538 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 539 October 2008. 541 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 542 Resilient against Forged Answers", RFC 5452, January 2009. 544 10.2. Informative References 546 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 547 Routers", February 2008, 548 . 550 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 551 Broadband Routers and Firewalls", September 2008, 552 . 554 Author's Address 556 Ray Bellis 557 Nominet UK 558 Edmund Halley Road 559 Oxford OX4 4DQ 560 United Kingdom 562 Phone: +44 1865 332211 563 Email: ray.bellis@nominet.org.uk 564 URI: http://www.nominet.org.uk/