idnits 2.17.1 draft-ietf-dnsext-dnsproxy-05.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 (April 23, 2009) is 5453 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 April 23, 2009 5 Expires: October 25, 2009 7 DNS Proxy Implementation Guidelines 8 draft-ietf-dnsext-dnsproxy-05 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 October 25, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document provides guidelines for the implementation of DNS 47 proxies, as found in broadband gateways and other similar network 48 devices. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 58 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 60 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4 61 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5 62 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5 63 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9 75 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10 76 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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 it is RECOMMENDED that proxies SHOULD ignore any unknown 178 DNS flags and proxy those 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 DNS proxies SHOULD therefore be prepared to receive and forward 236 queries over TCP. 238 Note that it is unlikely that a client would send a request over TCP 239 unless it had already received a truncated UDP response. Some 240 "smart" proxies have been observed to first forward any request 241 received over TCP to an upstream resolver over UDP, only for the 242 response to be truncated, causing the proxy to retry over TCP. Such 243 behaviour increases network traffic and causes delay in DNS 244 resolution since the initial UDP request is doomed to fail. 246 Therefore whenever a proxy receives a request over TCP, the proxy 247 SHOULD forward the query over TCP and SHOULD NOT attempt the same 248 query over UDP first. 250 4.4.2. Extension Mechanisms for DNS (EDNS0) 252 The Extension Mechanism for DNS [RFC2671] was introduced to allow the 253 transport of larger DNS packets over UDP and also to allow for 254 additional request and response flags. 256 A client may send an OPT Resource Record (OPT RR) in the Additional 257 Section of a request to indicate that it supports a specific receive 258 buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used 259 by DNSSEC to indicate that DNSSEC-related RRs should be returned to 260 the client. 262 However some proxies have been observed to either reject (with a 263 FORMERR response code) or black-hole any packet containing an OPT RR. 264 As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. 266 4.4.3. IP Fragmentation 268 Support for UDP packet sizes exceeding the WAN MTU depends on the 269 gateway's algorithm for handling fragmented IP packets. Several 270 methods are possible: 272 1. fragments are dropped 273 2. fragments are forwarded individually as they're received 274 3. complete packets are reassembled on the gateway, and then re- 275 fragmented (if necessary) as they're forwarded to the client 277 Method 1 above will cause compatibility problems with EDNS0 unless 278 the DNS client is configured to advertise an EDNS0 buffer size 279 limited to the WAN MTU less the size of the IP header. Note that RFC 280 2671 does recommend that the path MTU should be taken into account 281 when using EDNS0. 283 Also, whilst the EDNS0 specification allows for a buffer size of up 284 to 65535 octets, most common DNS server implementations do not 285 support a buffer size above 4096 octets. 287 Therefore (irrespective of which of the methods above is in use) 288 proxies SHOULD be capable of forwarding UDP packets up to a payload 289 size of at least 4096 octets. 291 NB: in theory IP fragmentation may also occur if the LAN MTU is 292 smaller than the WAN MTU, although the author has not observed such a 293 configuration in use on any residential broadband service. 295 4.5. Secret Key Transaction Authentication for DNS (TSIG) 297 [RFC2845] defines TSIG, which is a mechanism for authenticating DNS 298 requests and responses at the packet level. 300 Any modifications made to the DNS portions of a TSIG-signed query or 301 response packet (with the exception of the Query ID) will cause a 302 TSIG authentication failure. 304 DNS proxies MUST implement Section 4.7 of [RFC2845] and either 305 forward packets unchanged (as recommended above) or fully implement 306 TSIG. 308 As per Section 4.3, DNS proxies MUST be capable of proxying packets 309 containing TKEY [RFC2930] Resource Records. 311 NB: any DNS proxy (such as those commonly found in WiFi hotspot 312 "walled gardens") which transparently intercepts all DNS queries, and 313 which returns unsigned responses to signed queries, will also cause 314 TSIG authentication failures. 316 5. DHCP's Interaction with DNS 318 Whilst this document is primarily about DNS proxies, most consumers 319 rely on DHCP [RFC2131] to obtain network configuration settings. 320 Such settings include the client machine's IP address, subnet mask 321 and default gateway, but also include DNS related settings. 323 It is therefore appropriate to examine how DHCP affects client DNS 324 configuration. 326 5.1. Domain Name Server (DHCP Option 6) 328 Most gateways default to supplying their own IP address in the DHCP 329 "Domain Name Server" option [RFC2132]. The net result is that 330 without explicit re-configuration many DNS clients will by default 331 send queries to the gateway's DNS proxy. This is understandable 332 behaviour given that the correct upstream settings are not usually 333 known at boot time. 335 Most gateways learn their own DNS settings via values supplied by an 336 ISP via DHCP or PPP over the WAN interface. However whilst many 337 gateways do allow the device administrator to override those values, 338 some gateways only use those supplied values to affect the proxy's 339 own forwarding function, and do not offer these values via DHCP. 341 When using such a device the only way to avoid using the DNS proxy is 342 to hard-code the required values in the client operating system. 343 This may be acceptable for a desktop system but it is inappropriate 344 for mobile devices which are regularly used on many different 345 networks. 347 As per Section 3, end-users SHOULD be able to send their DNS queries 348 directly to specified upstream resolvers, ideally without hard-coding 349 those settings in their stub resolver. 351 It is therefore RECOMMENDED that gateways SHOULD support device 352 administrator configuration of values for the "Domain Name Server" 353 DHCP option. 355 5.2. Domain Name (DHCP Option 15) 357 A significant amount of traffic to the DNS Root Name Servers is for 358 invalid top-level domain names, and some of that traffic can be 359 attributed to particular equipment vendors whose firmware defaults 360 this DHCP option to specific values. 362 Since no standard exists for a "local" scoped domain name suffix it 363 is RECOMMENDED that the default value for this option SHOULD be 364 empty, and that this option MUST NOT be sent to clients when no value 365 is configured. 367 5.3. DHCP Leases 369 It is noted that some DHCP servers in broadband gateways by default 370 offer their own IP address for the "Domain Name Server" option (as 371 described above) but then automatically start offering the upstream 372 servers' addresses once they've been learnt over the WAN interface. 374 In general this behaviour is highly desirable, but the effect for the 375 end-user is that the settings used depend on whether the DHCP lease 376 was obtained before or after the WAN link was established. 378 If the DHCP lease is obtained whilst the WAN link is down then the 379 DHCP client (and hence the DNS client) will not receive the correct 380 values until the DHCP lease is renewed. 382 Whilst no specific recommendations are given here, vendors may wish 383 to give consideration to the length of DHCP leases, and whether some 384 mechanism for forcing a DHCP lease renewal might be appropriate. 386 Another possibility is that the learnt upstream values might be 387 persisted in non-volatile memory such that on reboot the same values 388 can be automatically offered via DHCP. However this does run the 389 risk that incorrect values are initially offered if the device is 390 moved or connected to another ISP. 392 Alternatively, the DHCP server might only issue very short (i.e. 60 393 second) leases while the WAN link is down, only reverting to more 394 typical lease lengths once the WAN link is up and the upstream DNS 395 servers are known. Indeed with such a configuration it may be 396 possible to avoid the need to implement a DNS proxy function in the 397 broadband gateway at all. 399 6. Security Considerations 401 This document introduces no new protocols. However there are some 402 security related recommendations for vendors that are listed here. 404 6.1. Forgery Resilience 406 Whilst DNS proxies are not usually full-feature resolvers they 407 nevertheless share some characteristics with them. 409 Notwithstanding the recommendations above about transparency many DNS 410 proxies are observed to pick a new Query ID for outbound requests to 411 ensure that responses are directed to the correct client. 413 NB: Changing the Query ID is acceptable and compatible with proxying 414 TSIG-signed packets since the TSIG signature calculation is based on 415 the original message ID which is carried in the TSIG RR. 417 It has been standard guidance for many years that each DNS query 418 should use a randomly generated Query ID. However many proxies have 419 been observed picking sequential Query IDs for successive requests. 421 It is strongly RECOMMENDED that DNS proxies follow the relevant 422 recommendations in [RFC5452], particularly those in Section 9.2 423 relating to randomisation of Query IDs and source ports. This also 424 applies to source port selection within any NAT function. 426 If a DNS proxy is running on a broadband gateway with NAT that is 427 compliant with [RFC4787] then it SHOULD also follow the 428 recommendations in Section 10 of [RFC5452] concerning how long DNS 429 state is kept. 431 6.2. Interface Binding 433 Some gateways have been observed to have their DNS proxy listening on 434 both internal (LAN) and external (WAN) interfaces. In this 435 configuration it is possible for the proxy to be used to mount 436 reflector attacks as described in [RFC5358]. 438 The DNS proxy in a gateway SHOULD NOT by default be accessible from 439 the WAN interfaces of the device. 441 6.3. Packet Filtering 443 The Transparency and Robustness Principles are not entirely 444 compatible with the deep packet inspection features of security 445 appliances such as firewalls which are intended to protect systems on 446 the inside of a network from rogue traffic. 448 However a clear distinction may be made between traffic that is 449 intrinsically malformed and that which merely contains unexpected 450 data. 452 Examples of malformed packets which MAY be dropped include: 454 o invalid compression pointers (i.e. those that point outside of the 455 current packet, or which might cause a parsing loop). 456 o incorrect counts for the Question, Answer, Authority and 457 Additional Sections (although care should be taken where 458 truncation is a possibility). 460 Since dropped packets will cause the client to repeatedly retransmit 461 the original request, it is RECOMMENDED that proxies SHOULD instead 462 return a suitable DNS error response to the client (i.e. SERVFAIL) 463 instead of dropping the packet completely. 465 7. IANA Considerations 467 This document requests no IANA actions. 469 8. Change Log 471 NB: to be removed by the RFC Editor before publication. 473 draft-ietf-dnsproxy-05 474 Removed specific reference to 28 byte IP headers (from Mark 475 Andrews) 477 draft-ietf-dnsproxy-04 - post WGLC 478 Introduction expanded 479 Section 5.2 - changed SHOULD to MUST 480 Section 4.5 - changed SHOULD to MUST (Alex Bligh) 481 Editorial nits (from Andrew Sullivan, Alfred Hones) 482 Clarificaton on end-user vs device administrator (Alan Barrett, 483 Paul Selkirk) 485 draft-ietf-dnsproxy-03 486 Editorial nits and mention of LAN MTU (from Alex Bligh) 488 draft-ietf-dnsproxy-02 489 Changed "router" to "gateway" throughout (David Oran) 490 Updated forgery resilience reference 491 Elaboration on bypassability (from Nicholas W.) 492 Elaboration on NAT source port randomisation (from Nicholas W.) 493 Mention of using short DHCP leases while the WAN link is down 494 (from Ralph Droms) 495 Further clarification on permissibility of altering QID when using 496 TSIG 498 draft-ietf-dnsproxy-01 499 Strengthened recommendations about truncation (from Shane Kerr) 500 New TSIG text (with help from Olafur) 501 Additional forgery resilience text (from Olafur) 502 Compression support (from Olafur) 503 Correction of text re: QID changes and compatibility with TSIG 505 draft-ietf-dnsproxy-00 506 Changed recommended DPI error to SERVFAIL (from Jelte) 507 Changed example for invalid compression pointers (from Wouter). 508 Note about TSIG implications of changing Query ID (from Wouter). 509 Clarified TC-bit text (from Wouter) 510 Extra text about proxy bypass (Nicholas W.) 512 draft-bellis-dnsproxy-00 513 Initial draft 515 9. Acknowledgements 517 The author would particularly like to acknowledge the assistance of 518 Lisa Phifer of Core Competence. In addition the author is grateful 519 for the feedback from the members of the DNSEXT Working Group. 521 10. References 523 10.1. Normative References 525 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 526 RFC 793, September 1981. 528 [RFC1035] Mockapetris, P., "Domain names - implementation and 529 specification", STD 13, RFC 1035, November 1987. 531 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 532 and Support", STD 3, RFC 1123, October 1989. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 538 RFC 2131, March 1997. 540 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 541 Extensions", RFC 2132, March 1997. 543 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 544 RFC 2671, August 1999. 546 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 547 Wellington, "Secret Key Transaction Authentication for DNS 548 (TSIG)", RFC 2845, May 2000. 550 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 551 RR)", RFC 2930, September 2000. 553 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 554 (RR) Types", RFC 3597, September 2003. 556 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 557 Rose, "Protocol Modifications for the DNS Security 558 Extensions", RFC 4035, March 2005. 560 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 561 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 562 RFC 4787, January 2007. 564 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 565 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 566 October 2008. 568 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 569 Resilient against Forged Answers", RFC 5452, January 2009. 571 10.2. Informative References 573 [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband 574 Routers", February 2008, 575 . 577 [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on 578 Broadband Routers and Firewalls", September 2008, 579 . 581 Author's Address 583 Ray Bellis 584 Nominet UK 585 Edmund Halley Road 586 Oxford OX4 4DQ 587 United Kingdom 589 Phone: +44 1865 332211 590 Email: ray.bellis@nominet.org.uk 591 URI: http://www.nominet.org.uk/