idnits 2.17.1 draft-ietf-dnsext-dnsproxy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 540. 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 Copyright Line does not match the current year -- The document date (November 26, 2008) is 5629 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) == Outdated reference: A later version (-10) exists of draft-ietf-dnsext-forgery-resilience-09 ** 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 (~~), 3 warnings (==), 6 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 November 26, 2008 5 Expires: May 30, 2009 7 DNS Proxy Implementation Guidelines 8 draft-ietf-dnsext-dnsproxy-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 30, 2009. 35 Abstract 37 This document provides guidelines for the implementation of DNS 38 proxies, as found in broadband routers and other similar network 39 devices. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 49 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 50 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 51 4.2. Unknown Resource Record Types . . . . . . . . . . . . . . 4 52 4.3. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 4 53 4.3.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5 54 4.3.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 5 55 4.3.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 56 4.4. Secret Key Transaction Authentication for DNS (TSIG) . . . 6 58 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7 59 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 7 60 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 7 61 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 8 65 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 9 66 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 Intellectual Property and Copyright Statements . . . . . . . . . . 12 81 1. Introduction 83 Recent research ([SAC035], [DOTSE]) has shown that many commonly-used 84 broadband routers (and similar devices) contain DNS proxies which are 85 incompatible in various ways with current DNS standards. 87 These proxies are usual simple DNS forwarders, but do not usually 88 have any caching capabilities. The proxy serves as a convenient 89 default DNS resolver for clients on the LAN, but relies on an 90 upstream resolver (e.g. at an ISP) to perform recursive DNS lookups. 92 This documents describes the incompatibilities that have been 93 discovered and offers guidelines to implementors on how to provide 94 maximum interoperability. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. The Transparency Principle 104 It is not considered practical for a simple DNS proxy to directly 105 implement all current and future DNS features. 107 There are several reasons why this is the case: 109 o broadband routers usually have limited hardware resources 110 o firmware upgrade cycles are long, and many users do not routinely 111 apply upgrades when they become available 112 o no-one knows what those future DNS features will be, nor how they 113 might be implemented 114 o it would substantially complicate the configuration UI of the 115 device 117 Furthermore some modern DNS protocol extensions (see e.g. EDNS0, 118 below) are intended to be used as "hop-by-hop" mechanisms. If the 119 DNS proxy is considered to be such a "hop" in the resolution chain 120 then for it to function correctly it would need to be fully compliant 121 with all such mechanisms. 123 Research has shown that the more actively a proxy participates in the 124 DNS protocol then the more likely it is that it will somehow 125 interfere with the flow of messages between the DNS client and the 126 upstream recursive resolvers. 128 The task of the proxy SHOULD therefore be no more and no less than to 129 receive DNS requests from clients on the LAN side, forward those 130 verbatim to one of the known upstream recursive resolvers on the WAN 131 side, and ensure that the whole response is returned verbatim to the 132 original client. 134 It is RECOMMENDED that proxies should be as transparent as possible, 135 such that any "hop-by-hop" mechanisms or newly introduced protocol 136 extensions operate as if the proxy were not there. 138 4. Protocol Conformance 140 4.1. Unexpected Flags and Data 142 The Transparency Principle above, when combined with Postel's 143 Robustness Principle [RFC0793], suggests that DNS proxies should not 144 arbitrarily reject or otherwise drop requests or responses based on 145 perceived non-compliance with standards. 147 For example, some proxies have been observed to drop any packet 148 containing either the "Authentic Data" (AD) or "Checking Disabled" 149 (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] 150 originally specified that these unused "Z" flag bits "MUST" be zero. 151 However these flag bits were always intended to be reserved for 152 future use, so refusing to proxy any packet containing these flags 153 (now that uses for those flags have indeed been defined) is not 154 appropriate. 156 Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown 157 DNS flags and proxy those packets as usual. 159 4.2. Unknown Resource Record Types 161 [RFC3597] requires that resolvers MUST handle Resource Records (RRs) 162 of unknown type transparently. 164 All requests and responses MUST be proxied regardless of the values 165 of the QTYPE and QCLASS fields. 167 Similarly all responses MUST be proxied regardless of the values of 168 the TYPE and CLASS fields of any Resource Record therein. 170 4.3. Packet Size Limits 172 [RFC1035] specifies that the maximum size of the DNS payload in a UDP 173 packet is 512 octets. Where the required portions of a response 174 would not fit inside that limit the DNS server MUST set the 175 "TrunCation" (TC) bit in the DNS response header to indicate that 176 truncation has occurred. There are however two standard mechanisms 177 (described below) for transporting responses larger than 512 octets. 179 Many proxies have been observed to truncate all responses at 512 180 octets, and others at a packet size related to the WAN MTU, in either 181 case doing so without correctly setting the TC bit. 183 Other proxies have been observed to incorrectly remove the TC bit in 184 server responses which correctly had the TC bit set by the server. 186 If a DNS response is truncated but the TC bit is not set then client 187 failures may result, in particular a naive DNS client library might 188 suffer crashes due to reading beyond the end of the data actually 189 received. 191 Therefore if a proxy must unilaterally truncate a response then the 192 proxy MUST set the TC bit. Similarly, proxies MUST NOT remove the TC 193 bit from responses. 195 4.3.1. TCP Transport 197 Should a UDP query fail because of truncation the standard fail-over 198 mechanism is to retry the query using TCP, as described in section 199 6.1.3.2 of [RFC1123] . 201 DNS proxies SHOULD therefore be prepared to receive and forward 202 queries over TCP. 204 Note that it is unlikely that a client would send a request over TCP 205 unless it had already received a truncated UDP response. Some 206 "smart" proxies have been observed to first forward a request 207 received over TCP to an upstream resolver over UDP, only for the 208 response to be truncated, causing the proxy to retry over TCP. Such 209 behaviour increases network traffic and causes delay in DNS 210 resolution since the initial UDP request is doomed to fail. 212 Therefore whenever a proxy receives a request over TCP, the proxy 213 SHOULD forward the query over TCP and SHOULD NOT attempt the same 214 query over UDP first. 216 4.3.2. Extension Mechanisms for DNS (EDNS0) 218 The Extension Mechanism for DNS [RFC2671] was introduced to allow the 219 transport of larger DNS packets over UDP and also to allow for 220 additional request and response flags. 222 A client may send an OPT Resource Record (OPT RR) in the Additional 223 Section of a request to indicate that it supports a specific receive 224 buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used 225 by DNSSEC to indicate that DNSSEC-related RRs should be returned to 226 the client. 228 However some proxies have been observed to either reject (with a 229 FORMERR response code) or black-hole any packet containing an OPT RR. 230 As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. 232 4.3.3. IP Fragmentation 234 Support for UDP packet sizes exceeding the WAN MTU depends on the 235 router's algorithm for handling fragmented IP packets. Several 236 options are possible: 238 1. fragments are dropped 239 2. fragments are forwarded individually as they're received 240 3. complete packets are reassembled on the router, and then re- 241 fragmented (if necessary) as they're forwarded to the client 243 Option 1 above will cause compatibility problems with EDNS0 unless 244 the DNS client is configured to advertise an EDNS0 buffer size 245 limited to 28 octets less than the MTU. Note that RFC 2671 does 246 recommend that the path MTU should be taken into account when using 247 EDNS0. 249 Also, whilst the EDNS0 specification allows for a buffer size of up 250 to 65535 octets, most common DNS server implementations do not 251 support a buffer size above 4096 octets. 253 Therefore it is RECOMMENDED (whichever of options 2 or 3 above is in 254 use) that routers SHOULD be capable of forwarding UDP packets up to a 255 payload size of at least 4096 octets. 257 4.4. Secret Key Transaction Authentication for DNS (TSIG) 259 [RFC2845] defines TSIG, which is a hop-by-hop mechanism for 260 authenticating DNS requests and responses at the packet level. 262 Whilst it's not impossible for a simple DNS proxy to implement TSIG 263 directly it is not advised since parsing and validating received 264 packets is a computationally intensive task, best left to full- 265 featured DNS clients. 267 DNS proxies SHOULD be transparent to TSIG signed packets. 269 Similarly, as per Section 4.2, DNS proxies SHOULD be capable to 270 proxying packets containing TKEY [RFC2930] Resource Records 272 5. DHCP's Interaction with DNS 274 Whilst this document is primarily about DNS proxies, most consumers 275 rely on DHCP [RFC2131] to obtain network configuration settings. 276 Such settings include the client machine's IP address, subnet mask 277 and default gateway, but also include DNS related settings. 279 It is therefore appropriate to examine how DHCP affects client DNS 280 configuration. 282 5.1. Domain Name Server (DHCP Option 6) 284 Most routers default to supplying their own IP address in the DHCP 285 "Domain Name Server" option [RFC2132]. The net result is that 286 without explicit re-configuration many DNS clients will by default 287 send queries to the router's DNS proxy. This is understandable 288 behaviour given that the correct upstream settings are not usually 289 known at boot time. 291 Most routers learn their own DNS settings via values supplied by an 292 ISP via DHCP or PPP over the WAN interface. However whilst many 293 routers do allow the end-user to override those values, some routers 294 only use those end-user supplied values to affect the proxy's own 295 forwarding function, and do not offer these values via DHCP. 297 When using such a device the only way to avoid using the DNS proxy is 298 to hard-code the required values in the client operating system. 299 This may be acceptable for a desktop system but it is inappropriate 300 for mobile devices which are regularly used on many different 301 networks. 303 End users SHOULD be able to send their DNS queries directly to 304 specified upstream resolvers, ideally without hard-coding those 305 settings in their stub resolver. 307 It is therefore RECOMMENDED that routers SHOULD support end-user 308 configuration of values for the "Domain Name Server" DHCP option. 310 5.2. Domain Name (DHCP Option 15) 312 A significant amount of traffic to the DNS Root Name Servers is for 313 invalid top-level domain names, and some of that traffic can be 314 attributed to particular equipment vendors whose firmware defaults 315 this DHCP option to specific values. 317 Since no standard exists for a "local" scoped domain name suffix it 318 is RECOMMENDED that the default value for this option SHOULD be 319 empty, and that this option SHOULD NOT be sent to clients when no 320 value is configured. 322 5.3. DHCP Leases 324 It is noted that some DHCP servers in broadband gateways by default 325 offer their own IP address for the "Domain Name Server" option (as 326 describe above) but then automatically start offering the upstream 327 settings once they've been learnt over the WAN interface. 329 In general this behaviour is desirable, but the effect for the end- 330 user is that the settings used depend on whether the DHCP lease was 331 obtained before or after the WAN link was established. 333 If the DHCP lease is obtained whilst the WAN link is down then the 334 DHCP client (and hence the DNS client) will not receive the correct 335 values until the DHCP lease is renewed. 337 Whilst no specific recommendations are given here, vendors may wish 338 to give consideration to the length of DHCP leases, and whether some 339 mechanism for forcing a DHCP lease renewal (i.e. by toggling the LAN 340 port link state whenever the WAN link state changes from DOWN to UP) 341 might be appropriate. 343 Another possibility is that the learnt upstream values might be 344 persisted in non-volatile memory such that on reboot the same values 345 can be automatically offered via DHCP. However this does run the 346 risk that incorrect values are initially offered if the device is 347 moved or connected to another ISP. 349 6. Security Considerations 351 This document introduces no new protocols. However there are some 352 security related recommendations for vendors that are listed here. 354 6.1. Forgery Resilience 356 Whilst DNS proxies are not usually full-feature resolvers they 357 nevertheless share some characteristics with them. 359 Notwithstanding the recommendations above about transparency many DNS 360 proxies are observed to pick a new Query ID for outbound requests to 361 ensure that responses are directed to the correct client. 363 It has been standard guidance for many years that each DNS query 364 should use a randomly generated Query ID. However many proxies have 365 been observed picking sequential Query IDs for successive requests. 367 DNS proxies SHOULD follow the relevant recommendations in 368 [I-D.ietf-dnsext-forgery-resilience], particularly those in Section 369 9.2 relating to randomisation of Query IDs and source ports. 371 NB: Changing the Query ID is incompatible with transparent proxying 372 of any TSIG records since the TSIG signature includes the Query ID. 373 It SHOULD be avoided wherever possible. 375 6.2. Interface Binding 377 Some routers have been observed to have their DNS proxy listening on 378 both internal (LAN) and external (WAN) interfaces. In this 379 configuration it is possible for the proxy to be used to mount 380 reflector attacks as described in [RFC5358] 382 The DNS proxy in a router SHOULD NOT by default be accessible from 383 the WAN interfaces of the device. 385 6.3. Packet Filtering 387 The Transparency and Robustness Principles are not entirely 388 compatible with the Deep Packet Inspection features of security 389 appliances such as firewalls which are intended to protect systems on 390 the inside of a network from rogue traffic. 392 However a clear distinction may be made between traffic that is 393 intrinsically malformed and that which merely contains unexpected 394 data. 396 Examples of malformed packets which MAY be dropped include: 398 o invalid compression pointers (i.e. those that run forward of the 399 current packet offset, or which might cause a parsing loop). 400 o incorrect counts for the Question, Answer, Authority and 401 Additional Sections (although care should be taken where 402 truncation is a possibility). 404 Since dropped packets will cause the client to repeatedly retransmit 405 the original request, it is RECOMMENDED that proxies SHOULD instead 406 return a suitable DNS error response to the client (i.e. SERVFAIL) 407 instead of dropping the packet completely. 409 7. IANA Considerations 411 This document requests no IANA actions. 413 8. Change Log 415 draft-ietf-dnsproxy-00 416 Changed recommended DPI error to SERVFAIL (from Jelte) 417 Changed example for invalid compression pointers (from Wouter). 418 Note about TSIG implications of changing Query ID (from Wouter). 419 Clarified TC-bit text (from Wouter) 420 Extra text about proxy bypass (Nicholas W.) 422 draft-bellis-dnsproxy-00 423 Initial draft 425 9. Acknowledgements 427 The author would particularly like to acknowledge the assistance of 428 Lisa Phifer of Core Competence. In addition the author is grateful 429 for the feedback from the members of the DNSEXT Working Group. 431 10. References 433 10.1. Normative References 435 [I-D.ietf-dnsext-forgery-resilience] 436 Hubert, B. and R. Mook, "Measures for making DNS more 437 resilient against forged answers", 438 draft-ietf-dnsext-forgery-resilience-09 (work in 439 progress), November 2008. 441 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 442 RFC 793, September 1981. 444 [RFC1035] Mockapetris, P., "Domain names - implementation and 445 specification", STD 13, RFC 1035, November 1987. 447 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 448 and Support", STD 3, RFC 1123, October 1989. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 454 RFC 2131, March 1997. 456 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 457 Extensions", RFC 2132, March 1997. 459 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 460 RFC 2671, August 1999. 462 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 463 Wellington, "Secret Key Transaction Authentication for DNS 464 (TSIG)", RFC 2845, May 2000. 466 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 467 RR)", RFC 2930, September 2000. 469 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 470 (RR) Types", RFC 3597, September 2003. 472 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 473 Rose, "Protocol Modifications for the DNS Security 474 Extensions", RFC 4035, March 2005. 476 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 477 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 478 October 2008. 480 10.2. Informative References 482 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 483 Routers", February 2008, 484 . 486 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 487 Broadband Routers and Firewalls", September 2008, 488 . 490 Author's Address 492 Ray Bellis 493 Nominet UK 494 Edmund Halley Road 495 Oxford OX4 4DQ 496 United Kingdom 498 Phone: +44 1865 332211 499 Email: ray.bellis@nominet.org.uk 500 URI: http://www.nominet.org.uk/ 502 Full Copyright Statement 504 Copyright (C) The IETF Trust (2008). 506 This document is subject to the rights, licenses and restrictions 507 contained in BCP 78, and except as set forth therein, the authors 508 retain all their rights. 510 This document and the information contained herein are provided on an 511 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 512 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 513 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 514 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 515 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 516 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 518 Intellectual Property 520 The IETF takes no position regarding the validity or scope of any 521 Intellectual Property Rights or other rights that might be claimed to 522 pertain to the implementation or use of the technology described in 523 this document or the extent to which any license under such rights 524 might or might not be available; nor does it represent that it has 525 made any independent effort to identify any such rights. Information 526 on the procedures with respect to rights in RFC documents can be 527 found in BCP 78 and BCP 79. 529 Copies of IPR disclosures made to the IETF Secretariat and any 530 assurances of licenses to be made available, or the result of an 531 attempt made to obtain a general license or permission for the use of 532 such proprietary rights by implementers or users of this 533 specification can be obtained from the IETF on-line IPR repository at 534 http://www.ietf.org/ipr. 536 The IETF invites any interested party to bring to its attention any 537 copyrights, patents or patent applications, or other proprietary 538 rights that may cover technology that may be required to implement 539 this standard. Please address the information to the IETF at 540 ietf-ipr@ietf.org.