idnits 2.17.1 draft-ietf-dnsext-dnsproxy-01.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (January 6, 2009) is 5589 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 (==), 2 comments (--). 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 January 6, 2009 5 Expires: July 10, 2009 7 DNS Proxy Implementation Guidelines 8 draft-ietf-dnsext-dnsproxy-01 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 July 10, 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document provides guidelines for the implementation of DNS 48 proxies, as found in broadband routers and other similar network 49 devices. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 59 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 61 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4 62 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 4 63 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5 64 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5 65 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6 66 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 67 4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7 69 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7 70 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 7 71 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8 72 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9 76 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 9 77 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 Recent research ([SAC035], [DOTSE]) has found that many commonly-used 94 broadband routers (and similar devices) contain DNS proxies which are 95 incompatible in various ways with current DNS standards. 97 These proxies are usual simple DNS forwarders, but do not usually 98 have any caching capabilities. The proxy serves as a convenient 99 default DNS resolver for clients on the LAN, but relies on an 100 upstream resolver (e.g. at an ISP) to perform recursive DNS lookups. 102 This documents describes the incompatibilities that have been 103 discovered and offers guidelines to implementors on how to provide 104 maximum interoperability. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. The Transparency Principle 114 It is not considered practical for a simple DNS proxy to directly 115 implement all current and future DNS features. 117 There are several reasons why this is the case: 119 o broadband routers usually have limited hardware resources 120 o firmware upgrade cycles are long, and many users do not routinely 121 apply upgrades when they become available 122 o no-one knows what those future DNS features will be, nor how they 123 might be implemented 124 o it would substantially complicate the configuration UI of the 125 device 127 Furthermore some modern DNS protocol extensions (see e.g. EDNS0, 128 below) are intended to be used as "hop-by-hop" mechanisms. If the 129 DNS proxy is considered to be such a "hop" in the resolution chain 130 then for it to function correctly it would need to be fully compliant 131 with all such mechanisms. 133 Research [SAC035] has shown that the more actively a proxy 134 participates in the DNS protocol then the more likely it is that it 135 will somehow interfere with the flow of messages between the DNS 136 client and the upstream recursive resolvers. 138 The role of the proxy should therefore be no more and no less than to 139 receive DNS requests from clients on the LAN side, forward those 140 verbatim to one of the known upstream recursive resolvers on the WAN 141 side, and ensure that the whole response is returned verbatim to the 142 original client. 144 It is RECOMMENDED that proxies should be as transparent as possible, 145 such that any "hop-by-hop" mechanisms or newly introduced protocol 146 extensions operate as if the proxy were not there. 148 4. Protocol Conformance 150 4.1. Unexpected Flags and Data 152 The Transparency Principle above, when combined with Postel's 153 Robustness Principle [RFC0793], suggests that DNS proxies should not 154 arbitrarily reject or otherwise drop requests or responses based on 155 perceived non-compliance with standards. 157 For example, some proxies have been observed to drop any packet 158 containing either the "Authentic Data" (AD) or "Checking Disabled" 159 (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] 160 originally specified that these unused "Z" flag bits "MUST" be zero. 161 However these flag bits were always intended to be reserved for 162 future use, so refusing to proxy any packet containing these flags 163 (now that uses for those flags have indeed been defined) is not 164 appropriate. 166 Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown 167 DNS flags and proxy those packets as usual. 169 4.2. Label Compression 171 Compression of labels as per Section 4.1.4 of [RFC1035] is optional. 173 Proxies MUST forward packets regardless of the presence or absence of 174 compressed labels therein. 176 4.3. Unknown Resource Record Types 178 [RFC3597] requires that resolvers MUST handle Resource Records (RRs) 179 of unknown type transparently. 181 All requests and responses MUST be proxied regardless of the values 182 of the QTYPE and QCLASS fields. 184 Similarly all responses MUST be proxied regardless of the values of 185 the TYPE and CLASS fields of any Resource Record therein. 187 4.4. Packet Size Limits 189 [RFC1035] specifies that the maximum size of the DNS payload in a UDP 190 packet is 512 octets. Where the required portions of a response 191 would not fit inside that limit the DNS server MUST set the 192 "TrunCation" (TC) bit in the DNS response header to indicate that 193 truncation has occurred. There are however two standard mechanisms 194 (described below) for transporting responses larger than 512 octets. 196 Many proxies have been observed to truncate all responses at 512 197 octets, and others at a packet size related to the WAN MTU, in either 198 case doing so without correctly setting the TC bit. 200 Other proxies have been observed to incorrectly remove the TC bit in 201 server responses which correctly had the TC bit set by the server. 203 If a DNS response is truncated but the TC bit is not set then client 204 failures may result, in particular a naive DNS client library might 205 suffer crashes due to reading beyond the end of the data actually 206 received. 208 Since UDP packets larger than 512 octets are now expected in normal 209 operation, proxies SHOULD NOT truncate UDP packets that exceed that 210 size. See Section 4.4.3 for recommendations for packet sizes 211 exceeding the WAN MTU. 213 If a proxy must unilaterally truncate a response then the proxy MUST 214 set the TC bit. Similarly, proxies MUST NOT remove the TC bit from 215 responses. 217 4.4.1. TCP Transport 219 Should a UDP query fail because of truncation the standard fail-over 220 mechanism is to retry the query using TCP, as described in section 221 6.1.3.2 of [RFC1123] . 223 DNS proxies SHOULD therefore be prepared to receive and forward 224 queries over TCP. 226 Note that it is unlikely that a client would send a request over TCP 227 unless it had already received a truncated UDP response. Some 228 "smart" proxies have been observed to first forward a request 229 received over TCP to an upstream resolver over UDP, only for the 230 response to be truncated, causing the proxy to retry over TCP. Such 231 behaviour increases network traffic and causes delay in DNS 232 resolution since the initial UDP request is doomed to fail. 234 Therefore whenever a proxy receives a request over TCP, the proxy 235 SHOULD forward the query over TCP and SHOULD NOT attempt the same 236 query over UDP first. 238 4.4.2. Extension Mechanisms for DNS (EDNS0) 240 The Extension Mechanism for DNS [RFC2671] was introduced to allow the 241 transport of larger DNS packets over UDP and also to allow for 242 additional request and response flags. 244 A client may send an OPT Resource Record (OPT RR) in the Additional 245 Section of a request to indicate that it supports a specific receive 246 buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used 247 by DNSSEC to indicate that DNSSEC-related RRs should be returned to 248 the client. 250 However some proxies have been observed to either reject (with a 251 FORMERR response code) or black-hole any packet containing an OPT RR. 252 As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. 254 4.4.3. IP Fragmentation 256 Support for UDP packet sizes exceeding the WAN MTU depends on the 257 router's algorithm for handling fragmented IP packets. Several 258 options are possible: 260 1. fragments are dropped 261 2. fragments are forwarded individually as they're received 262 3. complete packets are reassembled on the router, and then re- 263 fragmented (if necessary) as they're forwarded to the client 265 Option 1 above will cause compatibility problems with EDNS0 unless 266 the DNS client is configured to advertise an EDNS0 buffer size 267 limited to 28 octets less than the MTU. Note that RFC 2671 does 268 recommend that the path MTU should be taken into account when using 269 EDNS0. 271 Also, whilst the EDNS0 specification allows for a buffer size of up 272 to 65535 octets, most common DNS server implementations do not 273 support a buffer size above 4096 octets. 275 Therefore it is RECOMMENDED (whichever of options 2 or 3 above is in 276 use) that routers SHOULD be capable of forwarding UDP packets up to a 277 payload size of at least 4096 octets. 279 4.5. Secret Key Transaction Authentication for DNS (TSIG) 281 [RFC2845] defines TSIG, which is a mechanism for authenticating DNS 282 requests and responses at the packet level. 284 Any modifications made to the DNS portions of a TSIG-signed query or 285 response packet will cause a TSIG authentication failure. 287 DNS proxies MUST implement Section 4.7 of [RFC2845] and either 288 forward packets unchanged (as recommended above) or fully implement 289 TSIG. 291 As per Section 4.3, DNS proxies SHOULD be capable of proxying packets 292 containing TKEY [RFC2930] Resource Records. 294 NB: any DNS proxy (such as those commonly found in WiFi hotspot 295 "walled gardens") which transparently intercepts all DNS queries, and 296 which returns unsigned responses to signed queries, will also cause 297 TSIG authentication failures. 299 5. DHCP's Interaction with DNS 301 Whilst this document is primarily about DNS proxies, most consumers 302 rely on DHCP [RFC2131] to obtain network configuration settings. 303 Such settings include the client machine's IP address, subnet mask 304 and default gateway, but also include DNS related settings. 306 It is therefore appropriate to examine how DHCP affects client DNS 307 configuration. 309 5.1. Domain Name Server (DHCP Option 6) 311 Most routers default to supplying their own IP address in the DHCP 312 "Domain Name Server" option [RFC2132]. The net result is that 313 without explicit re-configuration many DNS clients will by default 314 send queries to the router's DNS proxy. This is understandable 315 behaviour given that the correct upstream settings are not usually 316 known at boot time. 318 Most routers learn their own DNS settings via values supplied by an 319 ISP via DHCP or PPP over the WAN interface. However whilst many 320 routers do allow the end-user to override those values, some routers 321 only use those end-user supplied values to affect the proxy's own 322 forwarding function, and do not offer these values via DHCP. 324 When using such a device the only way to avoid using the DNS proxy is 325 to hard-code the required values in the client operating system. 327 This may be acceptable for a desktop system but it is inappropriate 328 for mobile devices which are regularly used on many different 329 networks. 331 End users SHOULD be able to send their DNS queries directly to 332 specified upstream resolvers, ideally without hard-coding those 333 settings in their stub resolver. 335 It is therefore RECOMMENDED that routers SHOULD support end-user 336 configuration of values for the "Domain Name Server" DHCP option. 338 5.2. Domain Name (DHCP Option 15) 340 A significant amount of traffic to the DNS Root Name Servers is for 341 invalid top-level domain names, and some of that traffic can be 342 attributed to particular equipment vendors whose firmware defaults 343 this DHCP option to specific values. 345 Since no standard exists for a "local" scoped domain name suffix it 346 is RECOMMENDED that the default value for this option SHOULD be 347 empty, and that this option SHOULD NOT be sent to clients when no 348 value is configured. 350 5.3. DHCP Leases 352 It is noted that some DHCP servers in broadband gateways by default 353 offer their own IP address for the "Domain Name Server" option (as 354 describe above) but then automatically start offering the upstream 355 settings once they've been learnt over the WAN interface. 357 In general this behaviour is desirable, but the effect for the end- 358 user is that the settings used depend on whether the DHCP lease was 359 obtained before or after the WAN link was established. 361 If the DHCP lease is obtained whilst the WAN link is down then the 362 DHCP client (and hence the DNS client) will not receive the correct 363 values until the DHCP lease is renewed. 365 Whilst no specific recommendations are given here, vendors may wish 366 to give consideration to the length of DHCP leases, and whether some 367 mechanism for forcing a DHCP lease renewal (i.e. by toggling the LAN 368 port link state whenever the WAN link state changes from DOWN to UP) 369 might be appropriate. 371 Another possibility is that the learnt upstream values might be 372 persisted in non-volatile memory such that on reboot the same values 373 can be automatically offered via DHCP. However this does run the 374 risk that incorrect values are initially offered if the device is 375 moved or connected to another ISP. 377 6. Security Considerations 379 This document introduces no new protocols. However there are some 380 security related recommendations for vendors that are listed here. 382 6.1. Forgery Resilience 384 Whilst DNS proxies are not usually full-feature resolvers they 385 nevertheless share some characteristics with them. 387 Notwithstanding the recommendations above about transparency many DNS 388 proxies are observed to pick a new Query ID for outbound requests to 389 ensure that responses are directed to the correct client. 391 NB: Changing the Query ID is acceptable and compatible with proxying 392 TSIG-signed packets since the TSIG signature calculation is based on 393 the original message ID which is carried in the TSIG RR. 395 It has been standard guidance for many years that each DNS query 396 should use a randomly generated Query ID. However many proxies have 397 been observed picking sequential Query IDs for successive requests. 399 It is strongly RECOMMENDED that DNS proxies follow the relevant 400 recommendations in [I-D.ietf-dnsext-forgery-resilience], particularly 401 those in Section 9.2 relating to randomisation of Query IDs and 402 source ports. 404 If a DNS proxy is running on a broadband gateway with NAT that is 405 compliant with [RFC4787] then it SHOULD also follow the 406 recommendations for how long DNS state is kept from Section 10 of 407 [I-D.ietf-dnsext-forgery-resilience] 409 6.2. Interface Binding 411 Some routers have been observed to have their DNS proxy listening on 412 both internal (LAN) and external (WAN) interfaces. In this 413 configuration it is possible for the proxy to be used to mount 414 reflector attacks as described in [RFC5358] 416 The DNS proxy in a router SHOULD NOT by default be accessible from 417 the WAN interfaces of the device. 419 6.3. Packet Filtering 421 The Transparency and Robustness Principles are not entirely 422 compatible with the Deep Packet Inspection features of security 423 appliances such as firewalls which are intended to protect systems on 424 the inside of a network from rogue traffic. 426 However a clear distinction may be made between traffic that is 427 intrinsically malformed and that which merely contains unexpected 428 data. 430 Examples of malformed packets which MAY be dropped include: 432 o invalid compression pointers (i.e. those that point outside of the 433 current packet, or which might cause a parsing loop). 434 o incorrect counts for the Question, Answer, Authority and 435 Additional Sections (although care should be taken where 436 truncation is a possibility). 438 Since dropped packets will cause the client to repeatedly retransmit 439 the original request, it is RECOMMENDED that proxies SHOULD instead 440 return a suitable DNS error response to the client (i.e. SERVFAIL) 441 instead of dropping the packet completely. 443 7. IANA Considerations 445 This document requests no IANA actions. 447 8. Change Log 449 draft-ietf-dnsproxy-01 450 Strengthened recommendations about truncation (from Shane Kerr) 451 New TSIG text (with help from Olafur) 452 Additional forgery resilience text (from Olafur) 453 Compression support (from Olafur) 454 Correction of text re: QID changes and compatibility with TSIG 456 draft-ietf-dnsproxy-00 457 Changed recommended DPI error to SERVFAIL (from Jelte) 458 Changed example for invalid compression pointers (from Wouter). 459 Note about TSIG implications of changing Query ID (from Wouter). 460 Clarified TC-bit text (from Wouter) 461 Extra text about proxy bypass (Nicholas W.) 463 draft-bellis-dnsproxy-00 464 Initial draft 466 9. Acknowledgements 468 The author would particularly like to acknowledge the assistance of 469 Lisa Phifer of Core Competence. In addition the author is grateful 470 for the feedback from the members of the DNSEXT Working Group. 472 10. References 474 10.1. Normative References 476 [I-D.ietf-dnsext-forgery-resilience] 477 Hubert, B. and R. Mook, "Measures for making DNS more 478 resilient against forged answers", 479 draft-ietf-dnsext-forgery-resilience-10 (work in 480 progress), December 2008. 482 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 483 RFC 793, September 1981. 485 [RFC1035] Mockapetris, P., "Domain names - implementation and 486 specification", STD 13, RFC 1035, November 1987. 488 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 489 and Support", STD 3, RFC 1123, October 1989. 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 495 RFC 2131, March 1997. 497 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 498 Extensions", RFC 2132, March 1997. 500 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 501 RFC 2671, August 1999. 503 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 504 Wellington, "Secret Key Transaction Authentication for DNS 505 (TSIG)", RFC 2845, May 2000. 507 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 508 RR)", RFC 2930, September 2000. 510 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 511 (RR) Types", RFC 3597, September 2003. 513 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 514 Rose, "Protocol Modifications for the DNS Security 515 Extensions", RFC 4035, March 2005. 517 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 518 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 519 RFC 4787, January 2007. 521 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 522 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 523 October 2008. 525 10.2. Informative References 527 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 528 Routers", February 2008, 529 . 531 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 532 Broadband Routers and Firewalls", September 2008, 533 . 535 Author's Address 537 Ray Bellis 538 Nominet UK 539 Edmund Halley Road 540 Oxford OX4 4DQ 541 United Kingdom 543 Phone: +44 1865 332211 544 Email: ray.bellis@nominet.org.uk 545 URI: http://www.nominet.org.uk/