idnits 2.17.1 draft-bellis-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 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 525. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5661 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-07 ** 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 (==), 7 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 October 27, 2008 5 Expires: April 30, 2009 7 DNS Proxy Implementation Guidelines 8 draft-bellis-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 April 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 setting the TC bit. 183 Other proxies have been observed to remove the TC bit in server 184 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 65536 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 It is therefore RECOMMENDED that routers SHOULD support end-user 304 configuration of values for the "Domain Name Server" DHCP option. 306 5.2. Domain Name (DHCP Option 15) 308 A significant amount of traffic to the DNS Root Name Servers is for 309 invalid top-level domain names, and some of that traffic can be 310 attributed to particular equipment vendors whose firmware defaults 311 this DHCP option to specific values. 313 Since no standard exists for a "local" scoped domain name suffix it 314 is RECOMMENDED that the default value for this option SHOULD be 315 empty, and that this option SHOULD NOT be sent to clients when no 316 value is configured. 318 5.3. DHCP Leases 320 It is noted that some DHCP servers in broadband gateways by default 321 offer their own IP address for the "Domain Name Server" option (as 322 describe above) but then automatically start offering the upstream 323 settings once they've been learnt over the WAN interface. 325 In general this behaviour is desirable, but the effect for the end- 326 user is that the settings used depend on whether the DHCP lease was 327 obtained before or after the WAN link was established. 329 If the DHCP lease is obtained whilst the WAN link is down then the 330 DHCP client (and hence the DNS client) will not receive the correct 331 values until the DHCP lease is renewed. 333 Whilst no specific recommendations are given here, vendors may wish 334 to give consideration to the length of DHCP leases, and whether some 335 mechanism for forcing a DHCP lease renewal (i.e. by toggling the LAN 336 port link state whenever the WAN link state changes from DOWN to UP) 337 might be appropriate. 339 Another possibility is that the learnt upstream values might be 340 persisted in non-volatile memory such that on reboot the same values 341 can be automatically offered via DHCP. However this does run the 342 risk that incorrect values are initially offered if the device is 343 moved or connected to another ISP. 345 6. Security Considerations 347 This document introduces no new protocols. However there are some 348 security related recommendations for vendors that are listed here. 350 6.1. Forgery Resilience 352 Whilst DNS proxies are not usually full-feature resolvers they 353 nevertheless share some characteristics with them. 355 Notwithstanding the recommendations above about transparency it is 356 often necessary for a DNS proxy to pick a new Query ID for outbound 357 requests to ensure that responses are directed to the correct client. 359 It has been standard guidance for many years that each DNS query 360 should use a randomly generated Query ID. However many proxies have 361 been observed picking sequential Query IDs for successive requests. 363 DNS proxies SHOULD follow the relevant recommendations in 364 [I-D.ietf-dnsext-forgery-resilience], particularly those in Section 365 9.2 relating to randomisation of Query IDs and source ports. 367 6.2. Interface Binding 369 Some routers have been observed to have their DNS proxy listening on 370 both internal (LAN) and external (WAN) interfaces. In this 371 configuration it is possible for the proxy to be used to mount 372 reflector attacks as described in [RFC5358] 374 The DNS proxy in a router SHOULD NOT by default be accessible from 375 the WAN interfaces of the device. 377 6.3. Packet Filtering 379 The Transparency and Robustness Principles are not entirely 380 compatible with the Deep Packet Inspection features of security 381 appliances such as firewalls which are intended to protect systems on 382 the inside of a network from rogue traffic. 384 However a clear distinction may be made between traffic that is 385 intrinsically malformed and that which merely contains unexpected 386 data. 388 Examples of malformed packets which MAY be dropped include: 390 o invalid compression pointers (i.e. those that run forward of the 391 current packet offset, or which don't point at the start of 392 another label). 393 o incorrect counts for the Question, Answer, Authority and 394 Additional Sections (although care should be taken where 395 truncation is a possibility). 397 Since dropped packets will cause the client to repeatedly retransmit 398 the original request, it is RECOMMENDED that proxies SHOULD instead 399 return a suitable DNS error response to the client (i.e. FORMERR) 400 instead of dropping the packet completely. 402 7. IANA Considerations 404 This document requests no IANA actions. 406 8. Change Log 408 draft-bellis-dnsproxy-00 409 Initial draft 411 9. Acknowledgements 413 The author would particularly like to acknowledge the assistance of 414 Lisa Phifer of Core Competence. 416 10. References 418 10.1. Normative References 420 [I-D.ietf-dnsext-forgery-resilience] 421 Hubert, B. and R. Mook, "Measures for making DNS more 422 resilient against forged answers", 423 draft-ietf-dnsext-forgery-resilience-07 (work in 424 progress), August 2008. 426 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 427 RFC 793, September 1981. 429 [RFC1035] Mockapetris, P., "Domain names - implementation and 430 specification", STD 13, RFC 1035, November 1987. 432 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 433 and Support", STD 3, RFC 1123, October 1989. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 439 RFC 2131, March 1997. 441 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 442 Extensions", RFC 2132, March 1997. 444 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 445 RFC 2671, August 1999. 447 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 448 Wellington, "Secret Key Transaction Authentication for DNS 449 (TSIG)", RFC 2845, May 2000. 451 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 452 RR)", RFC 2930, September 2000. 454 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 455 (RR) Types", RFC 3597, September 2003. 457 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 458 Rose, "Protocol Modifications for the DNS Security 459 Extensions", RFC 4035, March 2005. 461 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 462 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 463 October 2008. 465 10.2. Informative References 467 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 468 Routers", February 2008, 469 . 471 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 472 Broadband Routers and Firewalls", September 2008, 473 . 475 Author's Address 477 Ray Bellis 478 Nominet UK 479 Edmund Halley Road 480 Oxford OX4 4DQ 481 United Kingdom 483 Phone: +44 1865 332211 484 Email: ray.bellis@nominet.org.uk 485 URI: http://www.nominet.org.uk/ 487 Full Copyright Statement 489 Copyright (C) The IETF Trust (2008). 491 This document is subject to the rights, licenses and restrictions 492 contained in BCP 78, and except as set forth therein, the authors 493 retain all their rights. 495 This document and the information contained herein are provided on an 496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 498 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 499 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Intellectual Property 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; nor does it represent that it has 510 made any independent effort to identify any such rights. Information 511 on the procedures with respect to rights in RFC documents can be 512 found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use of 517 such proprietary rights by implementers or users of this 518 specification can be obtained from the IETF on-line IPR repository at 519 http://www.ietf.org/ipr. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights that may cover technology that may be required to implement 524 this standard. Please address the information to the IETF at 525 ietf-ipr@ietf.org.