idnits 2.17.1 draft-ietf-dnsext-dnsproxy-06.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 (July 1, 2009) is 5375 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 July 1, 2009 5 Expires: January 2, 2010 7 DNS Proxy Implementation Guidelines 8 draft-ietf-dnsext-dnsproxy-06 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 January 2, 2010. 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 . . . . . . . . . . . . . . . . . . . . 6 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) . . . . . . . . . . . . 8 70 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8 71 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 11 80 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Research has found ([SAC035], [DOTSE]) 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 usually simple DNS forwarders, but typically do not 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 Note that to ensure full DNS protocol interoperability it is 102 preferred that client stub resolvers should communicate directly with 103 full-feature upstream recursive resolvers wherever possible. 105 That notwithstanding, this document describes the incompatibilities 106 that have been discovered and offers guidelines to implementors on 107 how to provide better interoperability in those cases where the 108 client must use the broadband gateway's DNS proxy. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. The Transparency Principle 118 It is not considered practical for a simple DNS proxy to implement 119 all current and future DNS features. 121 There are several reasons why this is the case: 123 o broadband gateways usually have limited hardware resources 124 o firmware upgrade cycles are long, and many users do not routinely 125 apply upgrades when they become available 126 o no-one knows what those future DNS features will be, nor how they 127 might be implemented 128 o it would substantially complicate the configuration UI of the 129 device 131 Furthermore some modern DNS protocol extensions (see e.g. EDNS0, 132 below) are intended to be used as "hop-by-hop" mechanisms. If the 133 DNS proxy is considered to be such a "hop" in the resolution chain, 134 then for it to function correctly, it would need to be fully 135 compliant with all such mechanisms. 137 [SAC035] shows that the more actively a proxy participates in the DNS 138 protocol then the more likely it is that it will somehow interfere 139 with the flow of messages between the DNS client and the upstream 140 recursive resolvers. 142 The role of the proxy should therefore be no more and no less than to 143 receive DNS requests from clients on the LAN side, forward those 144 verbatim to one of the known upstream recursive resolvers on the WAN 145 side, and ensure that the whole response is returned verbatim to the 146 original client. 148 It is RECOMMENDED that proxies should be as transparent as possible, 149 such that any "hop-by-hop" mechanisms or newly introduced protocol 150 extensions operate as if the proxy were not there. 152 Except when required to enforce an active security or network policy 153 (such as maintaining a pre-authentication "walled garden"), end-users 154 SHOULD be able to send their DNS queries to specified upstream 155 resolvers, thereby bypassing the proxy altogether. In this case, the 156 gateway SHOULD NOT modify the DNS request or response packets in any 157 way. 159 4. Protocol Conformance 161 4.1. Unexpected Flags and Data 163 The Transparency Principle above, when combined with Postel's 164 Robustness Principle [RFC0793], suggests that DNS proxies should not 165 arbitrarily reject or otherwise drop requests or responses based on 166 perceived non-compliance with standards. 168 For example, some proxies have been observed to drop any packet 169 containing either the "Authentic Data" (AD) or "Checking Disabled" 170 (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] 171 originally specified that these unused "Z" flag bits "MUST" be zero. 172 However these flag bits were always intended to be reserved for 173 future use, so refusing to proxy any packet containing these flags 174 (now that uses for those flags have indeed been defined) is not 175 appropriate. 177 Therefore proxies MUST ignore any unknown DNS flags and proxy those 178 packets as usual. 180 4.2. Label Compression 182 Compression of labels as per Section 4.1.4 of [RFC1035] is optional. 184 Proxies MUST forward packets regardless of the presence or absence of 185 compressed labels therein. 187 4.3. Unknown Resource Record Types 189 [RFC3597] requires that resolvers MUST handle Resource Records (RRs) 190 of unknown type transparently. 192 All requests and responses MUST be proxied regardless of the values 193 of the QTYPE and QCLASS fields. 195 Similarly all responses MUST be proxied regardless of the values of 196 the TYPE and CLASS fields of any Resource Record therein. 198 4.4. Packet Size Limits 200 [RFC1035] specifies that the maximum size of the DNS payload in a UDP 201 packet is 512 octets. Where the required portions of a response 202 would not fit inside that limit the DNS server MUST set the 203 "TrunCation" (TC) bit in the DNS response header to indicate that 204 truncation has occurred. There are however two standard mechanisms 205 (described in Section 4.4.1 and Section 4.4.2) for transporting 206 responses larger than 512 octets. 208 Many proxies have been observed to truncate all responses at 512 209 octets, and others at a packet size related to the WAN MTU, in either 210 case doing so without correctly setting the TC bit. 212 Other proxies have been observed to remove the TC bit in server 213 responses which correctly had the TC bit set by the server. 215 If a DNS response is truncated but the TC bit is not set then client 216 failures may result. In particular a naive DNS client library might 217 suffer crashes due to reading beyond the end of the data actually 218 received. 220 Since UDP packets larger than 512 octets are now expected in normal 221 operation, proxies SHOULD NOT truncate UDP packets that exceed that 222 size. See Section 4.4.3 for recommendations for packet sizes 223 exceeding the WAN MTU. 225 If a proxy must unilaterally truncate a response then the proxy MUST 226 set the TC bit. Similarly, proxies MUST NOT remove the TC bit from 227 responses. 229 4.4.1. TCP Transport 231 Should a UDP query fail because of truncation, the standard fail-over 232 mechanism is to retry the query using TCP, as described in section 233 6.1.3.2 of [RFC1123]. 235 Whilst TCP transport is not strictly mandatory, it is supported by 236 the vast majority of stub resolvers and recursive servers. Lack of 237 support in the proxy prevents this fail-over mechanism from working. 239 DNS proxies MUST therefore be prepared to receive and forward queries 240 over TCP. 242 Note that it is unlikely that a client would send a request over TCP 243 unless it had already received a truncated UDP response. Some 244 "smart" proxies have been observed to first forward any request 245 received over TCP to an upstream resolver over UDP, only for the 246 response to be truncated, causing the proxy to retry over TCP. Such 247 behaviour increases network traffic and causes delay in DNS 248 resolution since the initial UDP request is doomed to fail. 250 Therefore whenever a proxy receives a request over TCP, the proxy 251 SHOULD forward the query over TCP and SHOULD NOT attempt the same 252 query over UDP first. 254 4.4.2. Extension Mechanisms for DNS (EDNS0) 256 The Extension Mechanism for DNS [RFC2671] was introduced to allow the 257 transport of larger DNS packets over UDP and also to allow for 258 additional request and response flags. 260 A client may send an OPT Resource Record (OPT RR) in the Additional 261 Section of a request to indicate that it supports a specific receive 262 buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used 263 by DNSSEC to indicate that DNSSEC-related RRs should be returned to 264 the client. 266 However some proxies have been observed to either reject (with a 267 FORMERR response code) or black-hole any packet containing an OPT RR. 268 As per Section 4.1 proxies MUST NOT refuse to proxy such packets. 270 4.4.3. IP Fragmentation 272 Support for UDP packet sizes exceeding the WAN MTU depends on the 273 gateway's algorithm for handling fragmented IP packets. Several 274 methods are possible: 276 1. fragments are dropped 277 2. fragments are forwarded individually as they're received 278 3. complete packets are reassembled on the gateway, and then re- 279 fragmented (if necessary) as they're forwarded to the client 281 Method 1 above will cause compatibility problems with EDNS0 unless 282 the DNS client is configured to advertise an EDNS0 buffer size 283 limited to the WAN MTU less the size of the IP header. Note that RFC 284 2671 does recommend that the path MTU should be taken into account 285 when using EDNS0. 287 Also, whilst the EDNS0 specification allows for a buffer size of up 288 to 65535 octets, most common DNS server implementations do not 289 support a buffer size above 4096 octets. 291 Therefore (irrespective of which of the methods above is in use) 292 proxies SHOULD be capable of forwarding UDP packets up to a payload 293 size of at least 4096 octets. 295 NB: in theory IP fragmentation may also occur if the LAN MTU is 296 smaller than the WAN MTU, although the author has not observed such a 297 configuration in use on any residential broadband service. 299 4.5. Secret Key Transaction Authentication for DNS (TSIG) 301 [RFC2845] defines TSIG, which is a mechanism for authenticating DNS 302 requests and responses at the packet level. 304 Any modifications made to the DNS portions of a TSIG-signed query or 305 response packet (with the exception of the Query ID) will cause a 306 TSIG authentication failure. 308 DNS proxies MUST implement Section 4.7 of [RFC2845] and either 309 forward packets unchanged (as recommended above) or fully implement 310 TSIG. 312 As per Section 4.3, DNS proxies MUST be capable of proxying packets 313 containing TKEY [RFC2930] Resource Records. 315 NB: any DNS proxy (such as those commonly found in WiFi hotspot 316 "walled gardens") which transparently intercepts all DNS queries, and 317 which returns unsigned responses to signed queries, will also cause 318 TSIG authentication failures. 320 5. DHCP's Interaction with DNS 322 Whilst this document is primarily about DNS proxies, most consumers 323 rely on DHCP [RFC2131] to obtain network configuration settings. 324 Such settings include the client machine's IP address, subnet mask 325 and default gateway, but also include DNS related settings. 327 It is therefore appropriate to examine how DHCP affects client DNS 328 configuration. 330 5.1. Domain Name Server (DHCP Option 6) 332 Most gateways default to supplying their own IP address in the DHCP 333 "Domain Name Server" option [RFC2132]. The net result is that 334 without explicit re-configuration many DNS clients will by default 335 send queries to the gateway's DNS proxy. This is understandable 336 behaviour given that the correct upstream settings are not usually 337 known at boot time. 339 Most gateways learn their own DNS settings via values supplied by an 340 ISP via DHCP or PPP over the WAN interface. However whilst many 341 gateways do allow the device administrator to override those values, 342 some gateways only use those supplied values to affect the proxy's 343 own forwarding function, and do not offer these values via DHCP. 345 When using such a device the only way to avoid using the DNS proxy is 346 to hard-code the required values in the client operating system. 347 This may be acceptable for a desktop system but it is inappropriate 348 for mobile devices which are regularly used on many different 349 networks. 351 As per Section 3, end-users SHOULD be able to send their DNS queries 352 directly to specified upstream resolvers, ideally without hard-coding 353 those settings in their stub resolver. 355 It is therefore RECOMMENDED that gateways SHOULD support device 356 administrator configuration of values for the "Domain Name Server" 357 DHCP option. 359 5.2. Domain Name (DHCP Option 15) 361 A significant amount of traffic to the DNS Root Name Servers is for 362 invalid top-level domain names, and some of that traffic can be 363 attributed to particular equipment vendors whose firmware defaults 364 this DHCP option to specific values. 366 Since no standard exists for a "local" scoped domain name suffix it 367 is RECOMMENDED that the default value for this option SHOULD be 368 empty, and that this option MUST NOT be sent to clients when no value 369 is configured. 371 5.3. DHCP Leases 373 It is noted that some DHCP servers in broadband gateways by default 374 offer their own IP address for the "Domain Name Server" option (as 375 described above) but then automatically start offering the upstream 376 servers' addresses once they've been learnt over the WAN interface. 378 In general this behaviour is highly desirable, but the effect for the 379 end-user is that the settings used depend on whether the DHCP lease 380 was obtained before or after the WAN link was established. 382 If the DHCP lease is obtained whilst the WAN link is down then the 383 DHCP client (and hence the DNS client) will not receive the correct 384 values until the DHCP lease is renewed. 386 Whilst no specific recommendations are given here, vendors may wish 387 to give consideration to the length of DHCP leases, and whether some 388 mechanism for forcing a DHCP lease renewal might be appropriate. 390 Another possibility is that the learnt upstream values might be 391 persisted in non-volatile memory such that on reboot the same values 392 can be automatically offered via DHCP. However this does run the 393 risk that incorrect values are initially offered if the device is 394 moved or connected to another ISP. 396 Alternatively, the DHCP server might only issue very short (i.e. 60 397 second) leases while the WAN link is down, only reverting to more 398 typical lease lengths once the WAN link is up and the upstream DNS 399 servers are known. Indeed with such a configuration it may be 400 possible to avoid the need to implement a DNS proxy function in the 401 broadband gateway at all. 403 6. Security Considerations 405 This document introduces no new protocols. However there are some 406 security related recommendations for vendors that are listed here. 408 6.1. Forgery Resilience 410 Whilst DNS proxies are not usually full-feature resolvers they 411 nevertheless share some characteristics with them. 413 Notwithstanding the recommendations above about transparency many DNS 414 proxies are observed to pick a new Query ID for outbound requests to 415 ensure that responses are directed to the correct client. 417 NB: Changing the Query ID is acceptable and compatible with proxying 418 TSIG-signed packets since the TSIG signature calculation is based on 419 the original message ID which is carried in the TSIG RR. 421 It has been standard guidance for many years that each DNS query 422 should use a randomly generated Query ID. However many proxies have 423 been observed picking sequential Query IDs for successive requests. 425 It is strongly RECOMMENDED that DNS proxies follow the relevant 426 recommendations in [RFC5452], particularly those in Section 9.2 427 relating to randomisation of Query IDs and source ports. This also 428 applies to source port selection within any NAT function. 430 If a DNS proxy is running on a broadband gateway with NAT that is 431 compliant with [RFC4787] then it SHOULD also follow the 432 recommendations in Section 10 of [RFC5452] concerning how long DNS 433 state is kept. 435 6.2. Interface Binding 437 Some gateways have been observed to have their DNS proxy listening on 438 both internal (LAN) and external (WAN) interfaces. In this 439 configuration it is possible for the proxy to be used to mount 440 reflector attacks as described in [RFC5358]. 442 The DNS proxy in a gateway SHOULD NOT by default be accessible from 443 the WAN interfaces of the device. 445 6.3. Packet Filtering 447 The Transparency and Robustness Principles are not entirely 448 compatible with the deep packet inspection features of security 449 appliances such as firewalls which are intended to protect systems on 450 the inside of a network from rogue traffic. 452 However a clear distinction may be made between traffic that is 453 intrinsically malformed and that which merely contains unexpected 454 data. 456 Examples of malformed packets which MAY be dropped include: 458 o invalid compression pointers (i.e. those that point outside of the 459 current packet, or which might cause a parsing loop). 460 o incorrect counts for the Question, Answer, Authority and 461 Additional Sections (although care should be taken where 462 truncation is a possibility). 464 Dropped packets will cause the client to repeatedly retransmit the 465 original request, with the client only detecting the error after 466 several retransmit intervals. 468 In these circumstances proxies SHOULD synthesise a suitable DNS error 469 response to the client (i.e. SERVFAIL) instead of dropping the 470 packet completely. This will allow the client to detect the error 471 immediately. 473 7. IANA Considerations 475 This document requests no IANA actions. 477 8. Change Log 479 NB: to be removed by the RFC Editor before publication. 481 draft-ietf-dnsproxy-06pre (from IESG review) 482 Section 4.1 - cleaned up tautological language and changed SHOULD 483 to MUST (Adrian Farrel) 484 Section 4.4.1 - made TCP support mandatory (from Lars Eggert) 485 Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko) 486 Section 6.3 - clarified rationale for handling errors (from Robert 487 Sparks) 489 draft-ietf-dnsproxy-05 490 Removed specific reference to 28 byte IP headers (from Mark 491 Andrews) 493 draft-ietf-dnsproxy-04 - post WGLC 494 Introduction expanded 495 Section 5.2 - changed SHOULD to MUST 496 Section 4.5 - changed SHOULD to MUST (Alex Bligh) 497 Editorial nits (from Andrew Sullivan, Alfred Hones) 498 Clarificaton on end-user vs device administrator (Alan Barrett, 499 Paul Selkirk) 501 draft-ietf-dnsproxy-03 502 Editorial nits and mention of LAN MTU (from Alex Bligh) 504 draft-ietf-dnsproxy-02 505 Changed "router" to "gateway" throughout (David Oran) 506 Updated forgery resilience reference 507 Elaboration on bypassability (from Nicholas W.) 508 Elaboration on NAT source port randomisation (from Nicholas W.) 509 Mention of using short DHCP leases while the WAN link is down 510 (from Ralph Droms) 511 Further clarification on permissibility of altering QID when using 512 TSIG 514 draft-ietf-dnsproxy-01 515 Strengthened recommendations about truncation (from Shane Kerr) 516 New TSIG text (with help from Olafur) 517 Additional forgery resilience text (from Olafur) 518 Compression support (from Olafur) 519 Correction of text re: QID changes and compatibility with TSIG 521 draft-ietf-dnsproxy-00 522 Changed recommended DPI error to SERVFAIL (from Jelte) 523 Changed example for invalid compression pointers (from Wouter). 524 Note about TSIG implications of changing Query ID (from Wouter). 525 Clarified TC-bit text (from Wouter) 526 Extra text about proxy bypass (Nicholas W.) 528 draft-bellis-dnsproxy-00 529 Initial draft 531 9. Acknowledgements 533 The author would particularly like to acknowledge the assistance of 534 Lisa Phifer of Core Competence. In addition the author is grateful 535 for the feedback from the members of the DNSEXT Working Group. 537 10. References 539 10.1. Normative References 541 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 542 RFC 793, September 1981. 544 [RFC1035] Mockapetris, P., "Domain names - implementation and 545 specification", STD 13, RFC 1035, November 1987. 547 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 548 and Support", STD 3, RFC 1123, October 1989. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 554 RFC 2131, March 1997. 556 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 557 Extensions", RFC 2132, March 1997. 559 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 560 RFC 2671, August 1999. 562 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 563 Wellington, "Secret Key Transaction Authentication for DNS 564 (TSIG)", RFC 2845, May 2000. 566 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 567 RR)", RFC 2930, September 2000. 569 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 570 (RR) Types", RFC 3597, September 2003. 572 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 573 Rose, "Protocol Modifications for the DNS Security 574 Extensions", RFC 4035, March 2005. 576 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 577 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 578 RFC 4787, January 2007. 580 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 581 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 582 October 2008. 584 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 585 Resilient against Forged Answers", RFC 5452, January 2009. 587 10.2. Informative References 589 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 590 Routers", February 2008, 591 . 593 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 594 Broadband Routers and Firewalls", September 2008, 595 . 597 Author's Address 599 Ray Bellis 600 Nominet UK 601 Edmund Halley Road 602 Oxford OX4 4DQ 603 United Kingdom 605 Phone: +44 1865 332211 606 Email: ray.bellis@nominet.org.uk 607 URI: http://www.nominet.org.uk/