idnits 2.17.1 draft-livingood-dns-redirect-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 14 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2010) is 4934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1536' is defined on line 913, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Creighton 3 Internet-Draft C. Griffiths 4 Intended status: Informational J. Livingood 5 Expires: April 25, 2011 Comcast 6 R. Weber 7 Unaffiliated 8 October 22, 2010 10 DNS Redirect Use by Service Providers 11 draft-livingood-dns-redirect-03 13 Abstract 15 The objective of this document is to describe the design of so-called 16 DNS Redirect services deployed today by Internet Service Providers 17 (ISPs), DNS Application Service Providers (ASPs), and other 18 organizations providing so-called DNS Redirect services via their 19 recursive DNS servers, as well as to describe the recommended 20 practices regarding relating to DNS redirect. This document 21 specifically and narrowly addresses those cases where DNS Redirect is 22 being utilized to provide a web error redirect service to end users, 23 and describes the critical implications for DNS Redirect when DNSSEC 24 is deployed. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 73 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. DNSSEC Considerations and Implications . . . . . . . . . . . . 5 76 5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 6. Web Error Redirect . . . . . . . . . . . . . . . . . . . . . . 7 78 7. Opt-In or Opt-Out Mechanisms . . . . . . . . . . . . . . . . . 8 79 7.1. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7.2. Opt-In . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 7.3. Automated Mechanisms and Reasonable Processing Times . . . 9 82 7.4. Type of Opt-Out Method . . . . . . . . . . . . . . . . . . 9 83 8. Practices to Avoid . . . . . . . . . . . . . . . . . . . . . . 10 84 8.1. Use of DNS Redirect with DNSSEC . . . . . . . . . . . . . 10 85 8.2. Improper Redirect of Valid Responses . . . . . . . . . . . 10 86 8.3. Redirect of SERVFAIL Responses . . . . . . . . . . . . . . 11 87 8.4. Routinely Broken, Purposefully Broken, and Otherwise 88 Unreliable Opt-Out Mechanisms . . . . . . . . . . . . . . 11 89 8.5. Markedly Slower DNS Query Performance . . . . . . . . . . 12 90 8.6. Override of a User's DNS Selection . . . . . . . . . . . . 12 91 9. Functional Design . . . . . . . . . . . . . . . . . . . . . . 12 92 10. Example DNS and HTTP Flows . . . . . . . . . . . . . . . . . . 15 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 12. Controvery Surrounding DNS Redirect . . . . . . . . . . . . . 19 95 13. Future Prospects for DNS Redirect . . . . . . . . . . . . . . 19 96 14. Why This Document Merits Publishing . . . . . . . . . . . . . 20 97 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 100 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 18.1. Normative References . . . . . . . . . . . . . . . . . . . 22 102 18.2. Informative References . . . . . . . . . . . . . . . . . . 22 103 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 23 104 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 23 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 107 1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Introduction 115 Internet users typically are provided with several IP addresses for 116 recursive DNS servers, as described in Section 2.3 of [RFC1591], by 117 their respective ISPs, typically in an automated fashion via DHCP 118 [RFC2131]. Some other users and organizations choose to use a 119 different set of IP address for their DNS servers, which are hosted 120 and managed by another organization, such as a DNS ASP. It is also 121 the case that a number of users and organizations choose to operate 122 their own DNS servers, though those use cases are outside of the 123 scope of this document. 125 ISPs and DNS ASPs have over time created " enhanced " DNS 126 services for their users, which often rely upon DNS Redirect 127 functionality. These enhanced services, which are offered on an 128 opt-in or opt-out basis, can perform a number of enhanced services 129 for users, such as attempting to interpret web address errors when an 130 invalid fully qualified domain name (FQDN, Section 5.1 of [RFC1035]) 131 has been typed by a user. 133 This document describes the design and function of a DNS Redirect 134 service, as well as recommended practices and practices to avoid. It 135 also describes the critical implications for DNS Redirect when DNSSEC 136 is adopted, in Section 4. 138 3. Document Scope 140 This document focuses on the systems and practices of ISPs and DNS 141 ASPs. All other use cases, such as when an Internet user or 142 organization chooses to operate their own DNS servers is outside of 143 the scope of this document. 145 There are several ways that such entities can provide users with 146 these enhanced DNS services. In addition to methods which rely 147 primarily upon a recursive DNS server, alternate methods include (a) 148 interception and replacement of the error by a web browser client 149 software, (b) interception and replacement of the error by a tool 150 bar, plug-in, personal firewall security software or other web 151 browser client add-on. These alternate methods, which rely upon 152 various types of client software, are also outside of the scope of 153 this document. 155 It is important to note that while these alternate methods are 156 considered out of scope for this document, this should not be 157 interpreted as a negative judgment of their suitability or 158 applicability to the relevant problem space. Instead, these should 159 simply be considered as alternate methods since, as with most any 160 technical problem, there are a variety of valid methods for solving a 161 problem. 163 Lastly, while Section 7 indicates that users must be able to opt into 164 or out of DNS Redirect services, the reasons for why an ISP or DNS 165 ASP may choose one or the other as the default are out of scope. 167 4. DNSSEC Considerations and Implications 169 DNS security extensions defined in [RFC4033], [RFC4034], and 170 [RFC4035] use cryptographic digital signatures to provide origin 171 authentication and integrity assurance for DNS data. This is done by 172 creating signatures for DNS data on a DNS Security-Aware 173 Authoritative Name Server that can be used by DNS Security-Aware 174 Resolvers to verify the answers. 176 DNSSEC is now in the process of being deployed on authoritative 177 servers, now that the DNS root has been signed and several key Top 178 Level Domains (TLDs) have been signed. DNSSEC is also starting to be 179 adopted by service providers, which are now in the process of adding 180 DNSSEC validation in DNS recursive resolvers. 182 It is critically important that service providers understand that 183 adoption of DNSSEC is technically incompatible with DNS redirect. As 184 such, in order to properly implement DNSSEC and maintain a valid 185 chain of trust, DNS redirect MUST NOT be used any longer. Thus, once 186 DNSSEC is in widespread use, this document should be considered 187 historical. That being said, sections of this document concerning 188 opt-in and opt-out practices may be useful for future reference in 189 other, unrelated documents. 191 5. Terminology 193 While these terms are generally well known, it is important to define 194 them in the context of this document. 196 5.1. Internet Service Provider (ISP) 198 An Internet Service Provider, which provides Internet services, 199 including basic network connectivity. It is not germane to this 200 document what the method of connection is, such as wired or wireless, 201 what the speed of such a connection is, or what other services are 202 included or available to users. It is, however, assumed that the ISP 203 is providing recursive DNS services to their users and is in some 204 manner providing users with the IP addresses of these DNS servers, 205 whether via DHCP, static assignment by users, or some other method. 207 5.2. DNS Application Service Provider (ASP) 209 A DNS Application Service Provider, which provides managed and/or 210 hosted recursive DNS services (and possibly other DNS services) to 211 their users. In the case of managed services, the DNS ASP may 212 remotely manage the recursive DNS servers in a user's network. For a 213 hosted recursive DNS service, these servers are typically located 214 outside of the user's network and these hosted resources are shared 215 across multiple users. In most instances, these are hosted services 216 and users are manually configuring either their DHCP server or their 217 individual computing devices with the IP addresses of the recursive 218 DNS servers operated by their ASP. 220 5.3. Internet User 222 An Internet user, which is generally a person using a computing 223 device to connect to and make use of the Internet. Such users are 224 typically connected at the edge of the network, though the method by 225 which they connect to the Internet is not particularly relevant to 226 this document. 228 5.4. DNS Recursive Resolver 230 A DNS recursive resolver processes fully qualified domain name 231 queries (FQDN, Section 5.1 of [RFC1035]) into IP addresses by finding 232 the resource records in the authoritative DNS servers for the domain 233 associated with the FQDN. The resource records are then cached on 234 the recursive server for future requests until an expiration timer 235 expires called time to live (TTL), as described in Section 5.2 of 236 [RFC2181]. These servers are in most cases provided by ISPs for name 237 resolution. 239 5.5. Web Browser 241 Client software operated by the user locally on their computing 242 device, such as Microsoft Internet Explorer, Mozilla Firefox, Apple 243 Safari, Google Chrome, etc. 245 5.6. Web Error Landing Server 247 The host that a user is directed to when the DNS Recursive Server 248 receives a NXDOMAIN response. The contents of the web page that the 249 web server sends the user varies widely across different ISPs and DNS 250 ASPs. In some cases it is simply a more descriptive error that the 251 user would otherwise receive, while in other cases it may include 252 links to sites similar to the URL attempted and/or a search page, 253 among many other possibilities. 255 5.7. User Options Web Server 257 The web server that a user is directed to via a link on a page served 258 by the Web Error Landing Server, the Malicious Domain Web Error 259 Landing Server, from another system such as an account management 260 system, or via direct access, which enables a user to control whether 261 or not they are opted into or opted out of DNS Redirect services. 262 This is described in additional detail in the Section 7 section. 264 5.8. NXDOMAIN Response 266 In this document, an NXDOMAIN (nonexistent domain) response can be 267 used interchangeably with an RCODE 3 response. The RCODE 3 response 268 was first documented in see Section 4.1.1 of [RFC1035]). Subsequent 269 RFCs introduced the term NXDOMAIN response, which is synonymous with 270 RCODE 3 and tends to be used more frequently, as noted in Section 2.2 271 of [RFC2136], and Section 1 of [RFC2308]. 273 6. Web Error Redirect 275 A web error redirect service enables an ISP or ASP to provide a user, 276 who is generally utilizing a web browser, with an improved user 277 experience when an attempt to reach a nonexistent domain is made. 279 6.1. Web Error Redirect Problem Statement 281 A user enters an incorrect URL into their web browser, such as 282 http://www.example.invalid, where .invalid is a nonexistent Top Level 283 Domain (TLD, see Section 2 of [RFC1591]). In such a case, a user 284 would typically receive an error. 286 6.2. Web Error Redirect Solution Description 288 When a recursive DNS server detects such a nonexistent domain error 289 (NXDOMAIN, see Section 4.1.1 of [RFC1035]), the ISP or ASP can 290 instead provide a IP address for a Web Error Landing Server that can 291 present the user with a list of suggested destinations rather than 292 simply an error page. This page must also provide the user with a 293 link to a method of opting out in the future. See Figure 1, 294 Figure 2, and Figure 5 for examples below. 296 6.3. Web Error Redirect Solution Considerations 298 It is important to note that this technology can directly impact non- 299 web clients such as instant messaging, VPNs, FTP, email filters- 300 related DNS queries. Thus, special exclusions may need to be made in 301 order to prevent unintentional side effects. Design considerations 302 for the Web Error Search and Malicious Site Protection services 303 should include properly and promptly terminating non-HTTP connection 304 requests. Only A and AAAA resource records should be redirected, all 305 other resource record types must be answered as if there was no 306 redirection. 308 7. Opt-In or Opt-Out Mechanisms 310 ISPs and DNS ASPs MUST provide their users with a method to opt into 311 (opt-in) or out (opt-out) of some or all DNS Redirect services. Opt- 312 out and opt-in methods should be reliable and should take into 313 consideration the Section 8 section below. Whether such services are 314 offered on an opt-in or opt-out basis depends on a range of factors 315 which are outside of the scope of this document. The two different 316 methods, opt-out and opt-in, are described below. 318 7.1. Opt-Out 320 Opt-Out is used when the users are by default offered all or some DNS 321 Redirect services. As a result, the user must take an action to 322 disable some or all such services. This is typically performed via a 323 User Options Web Server. Users that have chosen to opt-out should 324 receive DNS responses which are indistinguishable from those 325 responses provided by a DNS server with no DNS Redirect 326 functionality. In addition, opt-out should be persistent in nature, 327 which means that opt-out should be tied to a fixed credential or 328 attribute of some type, such as an account identifier, billing 329 identifier, or equipment identifier, which is not typically subject 330 to change on a regular basis. 332 7.2. Opt-In 334 Opt-In is used when the users are by default not offered any DNS 335 Redirect services. As a result, the user must take an action to 336 enable some or all such services. This is typically performed via a 337 User Options Web Server. 339 7.3. Automated Mechanisms and Reasonable Processing Times 341 Once a user has selected to opt-in or opt-out of DNS Redirect 342 services, such changes should occur automatically, when this is 343 technically possible, without requiring the user to manually change 344 any settings on their computing device. Such changes should also 345 occur within a reasonable period of time. In some cases, however, a 346 user may be offered the ability to speed the period of time for these 347 changes to take effect, such as by restarting the computing device or 348 a piece of network equipment which connects them to their ISP's 349 network, for example. 351 While an automated mechanism may be the easiest for users, since it 352 requires no manual reconfiguration of their network settings, the 353 authors also recognize that there may be extenuating circumstances 354 where this is not achievable. In such cases, which may for example 355 be due to the particular attributes of one or another ISP's network 356 design, a fully automated mechanism may not be possible. Another 357 example is where a user is switching from their ISP's DNS server IP 358 addresses to those of a DNS ASP. As a result, a user in all of these 359 cases, as well as other possible cases, must manually reconfigure 360 their network with different DNS IP addresses. 362 7.4. Type of Opt-Out Method 364 There are several workable methods that can be employed to effect the 365 actual opt-out for a given user. These include setting a local user 366 application attribute, such as via a cookie in a web browser, as well 367 as setting a network attribute, via a DHCP change or manually 368 configuring the DNS IP addresses (in the operating system, modem, 369 home gateway device, or router) in order to change the DNS IP 370 addresses for a particular user. 372 While all of these methods are workable and can be made reliable, the 373 best current method is via a network-based change of some sort. In 374 this way, all Internet-connected computing devices within a given 375 household are included in the opt-out (these devices are generally 376 connected in some manner to the LAN side of some type of customer 377 premise device, such as a cable modem or DSL modem). This is in 378 contrast to a method which uses a local user application attribute, 379 such as a cookie in a web browser, where deletion of cookies, upgrade 380 to a new operating system, upgrade to a new web browser, use of a 381 different web browser, or countless other factors on that device 382 could cause the user to be opted back into a DNS Redirect service. 383 Thus, a network-based approach which sets opt-out-related attributes 384 at the device, or household level, is the most inclusive and 385 persistent method for providing a reliable opt-out method, and is the 386 recommended practice. 388 8. Practices to Avoid 390 This document primarily focuses on the recommended practices for an 391 ISP or ASP to provide users with DNS Redirect services. However, it 392 is important to note that some entities may not operate in accordance 393 with such practices. As such, some of these are catalogued below in 394 order to contrast them with recommended practices and provide 395 information which may be of interest and use to the community. 397 8.1. Use of DNS Redirect with DNSSEC 399 When DNSSEC has been implemented in a service provider's resolvers, 400 DNS redirect MUST NOT be used, as it is technically incompatible with 401 DNSSEC and breaks the chain of trust critical to proper DNSSEC 402 validation functionality. 404 8.2. Improper Redirect of Valid Responses 406 It has been observed that some service providers improperly utilize 407 DNS Redirect services when there is a valid DNS resource record 408 returned in response to a DNS recursive query. The effect is to 409 redirect users to a server not maintained by the intended 410 destination, such as a web site that looks like the intended web site 411 but is not actually the intended site and is instead controlled by 412 the service provider. For example a DNS query for www.example.com 413 results in a valid A record response, but this valid response is 414 instead replaced with an A record controlled by the service provider. 415 In this case the intended server identified with the valid A record 416 contained valid, lawful, non-malicious content, and there would 417 otherwise appear to be no valid justification for a redirect to 418 occur. See Figure 6 for an example below. 420 If there is a valid and reasonable justification for such a redirect 421 to occur, examples of which are not currently known by the authors of 422 this document, then the resulting connection to the server that the 423 user has been redirected to should clearly and prominently disclose 424 that this is not the intended site. For example, in the case of an 425 attempt by a user to connect to a web site, the site may contain a 426 banner or frame which indicates that this is not the intended site or 427 that the site is in some manner controlled by the service provider. 428 In addition, such a notice should also offer a clear method to opt- 429 out of this redirect function. 431 Thus, to summarize, redirection of valid responses SHOULD NOT be 432 performed. 434 8.3. Redirect of SERVFAIL Responses 436 Redirection of SERVFAIL responses SHOULD NOT occur. SERVFAIL 437 responses may occur intermittently in an operational network for a 438 variety of highly transient reasons. As a result, a DNS Redirect 439 should not be performed when a SERVFAIL response is received, as 440 normal retry a short time later is likely to result in a valid 441 response. 443 8.4. Routinely Broken, Purposefully Broken, and Otherwise Unreliable 444 Opt-Out Mechanisms 446 There are several well known and dependable methods of opt-out 447 mechanisms that ISPs and DNS ASPs can deploy for users to opt-out of 448 their DNS Redirect services. These methods can rather easily be 449 employed and are highly recommended, as noted in Section 7. However, 450 some ISPs and DNS ASPs may instead choose to employ a less dependable 451 mechanism, which routinely fails to work as expected by users or is 452 known not to function properly. 454 For example, one routinely unreliable method for opt-out is the 455 cookie-based method. When a user opts out of a DNS Redirect service, 456 a cookie is installed in their web browser. The problem with this 457 method occurs when a user clears their cookies or the cookies are 458 deleted for some reason. In some cases, users may configure their 459 web browsers to clear all cookies every time the close their web 460 browser. Thus, one possible effect upon the user in this case is 461 that they are once again opted into the redirect service. 462 Furthermore, a cookie-based method has the effect of only opting out 463 browser-based protocols (generally HTTP and HTTPS), which means that 464 the user may have non-web applications affected by DNS Redirect, even 465 though they believe they have opted-out. As a result, there is no 466 assured permanency with this opt-out method, nor does it work 467 consistently across all applications and protocols, which can be 468 aggravating to users who do not wish to utilize DNS Redirect 469 services. 471 Another example of an unreliable method for opt-out is one where opt- 472 out is tied to the IP address of the user, where that address may be 473 subject to change on a regular basis, such as via an ISP-based DHCP 474 lease. In such a case, if opt-out was tied to what can be considered 475 a largely dynamic IP address, then the user would be opted-in every 476 time they received a new IP address, forcing them to repeatedly opt- 477 out. 479 Thus, to summarize, the opt-out mechanism provided to users SHOULD be 480 reliable and SHOULD NOT be routinely broken, purposefully broken, or 481 otherwise unreliable. 483 8.5. Markedly Slower DNS Query Performance 485 An ISP or DNS ASP should also understand that DNS query latency, the 486 time between when a user's stub resolver issues a DNS query and 487 receives a DNS response, should be kept as low as is reasonably 488 possible. High DNS query latency is often perceived by users, and 489 can have an adverse effect on a variety of applications where low DNS 490 query latency may be especially important. Any additional processing 491 which must be performed in order to provide DNS Redirect services 492 should be monitored closely, in order that DNS Redirect functionality 493 does not markedly slow DNS query performance. 495 Thus, to summarize, when DNS redirect is performed, DNS query 496 performance SHOULD NOT suffer as a result, since this could provide 497 an incrementally inferior user experience as compared to when DNS 498 redirect is not performed. 500 8.6. Override of a User's DNS Selection 502 Some users may decide to use the DNS server IP addresses of a DNS ASP 503 or other non-ISP-provided DNS servers. Such selections should be 504 preserved as the free choice of a user, particularly when DNS 505 Redirect services are offered. Thus, an ISP SHOULD NOT redirect port 506 53 DNS traffic from servers intended by the user via their selection 507 of non-ISP DNS servers to the DNS servers of the ISP, except in 508 reasonable and justifiable cases where a user has been placed into a 509 so-called "walled garden" for reasons of abuse, security compromise, 510 account non-payment, new service activation, etc. 512 An exception to this is when, unbeknownst to the user, malicious 513 software (malware) has changed the IP address of their DNS server to 514 a known malicious DNS server. In such cases, it may be in the best 515 interests of the user to take steps to ensure they do not use such a 516 malicious DNS server, particularly since they did not intend to do so 517 and may be infected with malware. While this is unrelated to DNS 518 Redirect per se, it merits mentioning based on feedback received from 519 the security community. 521 9. Functional Design 523 The functional design described in this section is intended to be 524 generally representative of the many different ways that DNS Redirect 525 services are deployed today. As such, they are necessarily high 526 level and different implementations may vary somewhat, due to any 527 number of factors. 529 9.1. DNS Recursive Resolver 531 The DNS Recursive Resolver is used by the host computer to translate 532 fully qualified domain names into IP addresses, according to Section 533 3.6.1 of [RFC1034]. When a FQDN does not exist in authoritative DNS 534 a NXDOMAIN response, as described in Section 4.1.1 of [RFC1035] is 535 normally returned (see Figure 1). In the case of DNS Redirect, the 536 NXDOMAIN response is changed to reply with a resource record (RR) 537 response which instructs the host computer to send the original 538 request to a new IP address (see Figure 1). 540 Request Request 541 www.example.invalid www.example.invalid 542 +--------+ +--------+ 543 ++--++ ------------> | | ------------> | | 544 || || | | | | 545 +-++--++-+ | | | | 546 +--------+ <------------ | | <------------ | | 547 Host NXDOMAIN +--------+ NXDOMAIN +--------+ 548 Computer Response Recursive Response Authoritative 549 Server Server 551 Figure 1: DNS Redirect Response 553 9.2. Web Error Landing Server 555 When a user requests an invalid URL or Domain, their web client is 556 redirected to a Web Error Landing Server which presents several 557 possible helpful website views (see Figure 2). The first is "Did you 558 mean..." response which presents the user with possible correct 559 results based on their original invalid request. The search server 560 can also present search engine results to the user. 562 Request Request 563 www.example.invalid www.example.invalid 564 +--------+ +--------+ 565 ++--++ ---------------> | | --------------->| | 566 || || | | | | 567 +-++--++-+ | | | | 568 +--------+ <-------------- | | <------------- | | 569 Host Redirect +--------+ NXDOMAIN +--------+ 570 Computer IP Address Recursive Response Authoritative 571 Server Server 572 | 573 | ___________________________________ 574 | +--------+ | Web Response: | 575 | | | | "Did you mean...www.example.com"| 576 +------> | | ------> |__________________________________| 577 | | | Search result: #1 | 578 | | | Search result: #2 | 579 +--------+ |__________________________________| 580 Web Server 581 Landing Page 583 Figure 2: Web Error Landing Server 585 9.3. Web Browser Client 587 The Web Browser Client is redirected to a Web Server Landing Page 588 instead of presenting an error page when there is no valid DNS record 589 present. 591 Examples of common Web Browser Clients include: 593 o Microsoft Internet Explorer 595 o Mozilla Firefox 597 o Apple Safari 599 o Google Chrome 601 o Opera 603 9.4. Domain White List 605 There may be certain domains which should be not be redirected under 606 any circumstances for technical, legal, business, or other reasons. 607 The Domain White List can contain both domains, such as 608 *.example.com, as well as specific FQDNs, such as www.example.com. 610 For instance, the owner of example.com may request that the ISP or 611 DNS ASP not perform DNS Redirect for the example.com domain, so that 612 there is no DNS Redirect resulting from queries to nonexistent names, 613 such as invalid.example.com. 615 10. Example DNS and HTTP Flows 617 This section shows several illustrated examples of DNS and HTTP 618 flows, in order to better explain certain DNS and HTTP use cases. 620 10.1. Successful DNS Lookup and HTTP Flow 622 This example represents a successful lookup of a valid DNS RR, and 623 the resulting HTTP transaction. 625 Web DNS R DNS A DNS Web Server 626 Browser Client Server Server 10.1.10.10 628 | Request | A | | | 629 |www.example. |Record Query | A | | 630 | com |www.example. |Record Query | | 631 |------------>| com |www.example. | | 632 | |------------>| com | | 633 | | |------------>| | 634 | | | A Record | | 635 | | A Record | 10.1.10.10 | | 636 | DNS Response| 10.1.10.10 |<------------| | 637 | 10.1.10.10 |<------------| | | 638 |<------------| | | | 639 | HTTP GET | | | | 640 | 10.1.10.10 | | | | 641 |------------------------------------------------------>| 642 | | | | | 643 | | | | | 644 | | | | | 646 Figure 3: Successful DNS Lookup and HTTP Flow 648 10.2. Unsuccessful DNS Lookup and HTTP Flow 650 This example represents a lookup of a nonexistent DNS RR, and the 651 resulting HTTP transaction. 653 Web DNS R DNS A DNS 654 Browser Client Server Server 656 | Request | A | | 657 |www.example. |Record Query | A | 658 | invalid |www.example. |Record Query | 659 |------------>| invalid |www.example. | 660 | |------------>| invalid | 661 | | |------------>| 662 | | | NXDOMAIN | 663 | | NXDOMAIN |<------------| 664 | NXDOMAIN |<------------| | 665 |<------------| | | 666 | | | | 668 Figure 4: Unsuccessful DNS Lookup and HTTP Flow 670 10.3. DNS Redirect and HTTP Flow 672 This example represents a lookup of a non-existing DNS RR, and the 673 HTTP transition that results from a typical DNS Redirect service. 675 Redirect 676 Host R DNS A DNS Web Server Web Server 677 Computer Server Server 10.2.20.20 10.1.10.10 679 | A | | | | 680 |Record Query | A | | | 681 |www.example. |Record Query | | | 682 | invalid |www.example. | | | 683 |------------>| invalid | | | 684 | |------------>| | | 685 | A Record | NXDOMAIN | | | 686 | 10.2.20.20 |<------------| | | 687 |<------------| | | | 688 | HTTP GET | | | | 689 | 10.2.20.20 | | | | 690 |---------------------------------------->| | 691 | | | HTTP 200 OK | | 692 |<----------------------------------------| | 693 | A | | | | 694 |Record Query | A | | | 695 |www.example. |Record Query | | | 696 | com |www.example. | | | 697 |------------>| com | | | 698 | |------------>| | | 699 | | A Record | | | 700 | A Record | 10.1.10.10 | | | 701 | 10.1.10.10 |<------------| | | 702 |<------------| | | | 703 | HTTP GET | | | | 704 | 10.1.10.10 | | | | 705 |------------------------------------------------------>| 706 | | | | HTTP 200 OK | 707 |<------------------------------------------------------| 708 | | | | | 710 Figure 5: DNS Redirect and HTTP Flow 712 10.4. Improper Redirect of Valid Response Redirect and HTTP Flow 714 This example represents an improper redirect occurring when a valid 715 DNS RR should have been returned in response to a DNS recursive query 716 for an example website, the resulting HTTP transaction, and that no 717 DNS query or HTTP traffic was sent to the valid authoritative DNS 718 server and valid web server. Section 4 shows one of the reasons why 719 this practice is problematic. Another reason is that a user intends 720 to visit a valid resource with lawful and legitimate content, such as 721 a web site, and is instead sent to a different destination (which may 722 even closely resemble the intended site, in the pattern used by 723 phishing sites). 725 R DNS Improper Valid 726 Server Redirect Valid Web 727 Host R DNS Improper Web Server A DNS Server 728 Computer Server Reirect List 10.2.20.20 Server 10.1.10.10 730 | A | Improper | | | | 731 |Record Query |Redirect List| | | | 732 |www.example. | Query | | | | 733 | com |www.example. | | | | 734 |------------>| com | | | | 735 | |------------>| | | | 736 | | Postivie | | | | 737 | A Record | Match | | | | 738 | 10.2.20.20 |<------------| | | | 739 |<------------| | | | | 740 | HTTP GET | | | | | 741 | 10.2.20.20 | | | | | 742 |-------------------------------------->| | | 743 | | |HTTP 200 OK| | | 744 |<--------------------------------------| | | 745 | | | | | | 747 Figure 6: Improper Redirect of Valid Response Redirect and HTTP Flow 749 11. Security Considerations 751 The critical considerations relating to DNS Security Extensions are 752 detailed in Section 4. 754 Security best practices should be followed regarding access to the 755 opt-in and opt-out functions, in order that someone other than the 756 user is able to change the user's DNS Redirect settings. For 757 example, the User Options Web Server must not permit someone to 758 modify a page URI to access and change another user's options. Thus, 759 if the URI is 760 "http://www.example.net/redirect-options.php?account=1234", someone 761 must not be able to modify the account to be "=1235" and then be able 762 to change the options for a different user with some other additional 763 validation being performed. While web site security practices are 764 outside the scope of this document, the authors believe it is 765 important to identify such problematic use cases to any ISPs and DNS 766 ASPs offering and/or implementing DNS Redirect functionality. 768 12. Controvery Surrounding DNS Redirect 770 It is clear based on the community feedback that this document has 771 elicited, and from debates which have occurred over the years prior 772 to this document, that DNS Redirect is a controversial topic. Views 773 on whether DNS Redirect should be performed or not vary widely. Some 774 feel strongly that it is a valid practice from which end users derive 775 benefits. Some others feel that DNS Redirect should not be performed 776 and that it puts at risk trust in and stability of the DNS. Others 777 in the community are neutral on the topic and have expressed the view 778 that as long as DNS Redirect does not slow the deployment of DNSSEC, 779 that it is transparently disclosed to end users, and that those end 780 users have easy opt-out methods, that it is an acceptable, or at 781 least tolerated, practice. This moderate view is probably the 782 majority view, though critics of DNS Redirect have expressed their 783 views firmly and many of those holding such strongly critical views 784 have played and continue to play a key role in DNS protocols and 785 other critical areas of the IETF and the Internet community. Some 786 strong critics also describe resolvers that perform DNS Redirect as 787 "lying resolvers", explaining that the accurate and therefore honest 788 response is an NXDOMAIN response and that anything else is not 789 intended and is considered a lie. 791 Thus, it is important for readers to understand that DNS Redirect 792 remains a practice which is subject to some controversy and that 793 there is not strong consensus in support of it. At best, there is 794 what could be described as grudging acceptance of the practice if it 795 has been implemented along the lines recommended in this document. 796 In addition, many critics take solace in the view that as DNSSEC is 797 increasingly deployed that DNS Redirect is likely to decline 798 correspondingly over time. 800 Finally, any provider implementing DNS Redirect is well advised to 801 follow the recommendations outlined herein. This is because many 802 critics of DNS Redirect have explained that their strong views 803 developed or deepened when they observed that some implementers have 804 deployed systems which fail to provide an easy and/or reliable opt- 805 out method, redirect valid responses, or follow practices noted as 806 ones to avoid in Section 8. 808 13. Future Prospects for DNS Redirect 810 As noted in Section 4, there exists today a technical incompatibility 811 between DNSSEC and DNS Redirect. While it is possible that some 812 provider implementing DNS Redirect today will uncover a method to 813 implement DNSSEC and DNS Redirect, currently these two functions do 814 not go well together. As such, providers will soon or are now facing 815 a decision between embracing and deploying DNSSEC or continuing to 816 perform DNS Redirect. It is likely that many of these providers will 817 choose to deploy DNSSEC, as some already are doing [Comcast DNSSEC 818 Rollout Announced]. It is also possible that some others will deploy 819 DNSSEC-validating DNS recursive resolvers alongside those resolvers 820 performing DNS Redirect, giving their customers the choice between 821 the two. In this case, it is likely that over time customers will 822 express a preference for greater levels of Internet security, 823 including DNSSEC and other forms of security, and that their 824 respective service providers will evolve their offerings to satisfy 825 these customer needs. 827 14. Why This Document Merits Publishing 829 Documentation of DNS Redirect is beneficial for the Internet 830 community in and of itself. Prior to this document, the IETF lacked 831 a stable reference document that described how DNS Redirect was 832 designed and implemented, even though the practice has become 833 relatively widespread. As a result, one benefit of publishing this 834 is to document the design and implementation of DNS Redirect on the 835 Internet. 837 An additional benefit of the document is to guide those providers 838 which decide to implement DNS Redirect on what practices should be 839 avoided and what steps should be taken to ensure that end users are 840 able to easily and reliably opt out of such a system. While it does 841 not seem appropriate, based on the community response noted in 842 Section 12, to identify this as a Best Current Practices (BCP) 843 document, this can guide implementers on what to avoid and on "least 844 worst" practices as some in the community have described them. 846 Furthermore, this documents other key aspects of DNS Redirect that 847 are valuable. For example, this document encourages transparency and 848 disclosure of DNS Redirect practices on the Internet, and notes 849 community concerns and controversy regarding the practice, all of 850 which may be valuable to refer back to in future documents or to 851 refer to during future debates in the Internet community. There will 852 also be future systems which call for well functioning opt-out 853 systems. For such systems, the sections referring to automated opt- 854 out mechanisms and reasonable processing times of opt-out requests, 855 in Section 7.3, and the reliability of opt-out systems, in 856 Section 8.4, may be valuable. Finally, Section 8.6 describes that a 857 user's selection of an alternative DNS server IP address should not 858 be overridden, which seems an important principle to highlight. 860 15. IANA Considerations 862 There are no IANA considerations in this document. 864 16. Contributors 866 The following people made significant textual contributions to this 867 document and played an important role in the development and 868 evolution of this document: 870 Don Bowman, Sandvine (don@sandvine.com) 872 Rick Hiester, Verizon (richard.hiester@verizon.com) 874 Chris Roosenraad, Time Warner Cable (chris.roosenraad@twcable.com) 876 David Ulevitch, OpenDNS (david@opendns.com) 878 17. Acknowledgements 880 The authors and contributors also wish to acknowledge the assistance 881 of the following individuals in helping us to develop and/or review 882 this document: 884 John Barnitz, Comcast Cable Communications 885 (john_barnitz@cable.comcast.com) 887 Mike Burns, Cablevision (mburns@cablevision.com) 889 Phil Marcella, Comcast Interactive Media 890 (phillip_marcella@cable.comcast.com) 892 Luis Uribarri, Comcast Cable Communications 893 (luis_uribarri@cable.comcast.com) 895 Sandy Wilbourn, Nominum (sandy.wilbourn@nominum.com) 897 Matt Williams, Cox Cable (matt.williams@cox.com) 899 The authors and contributors also wish to thank ICANN's Security and 900 Stability Advisory Committee (SSAC) for their review and debate of 901 this document, as well as for raising important questions concerning 902 DNSSEC compatibility. 904 18. References 905 18.1. Normative References 907 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 908 STD 13, RFC 1034, November 1987. 910 [RFC1035] Mockapetris, P., "Domain names - implementation and 911 specification", STD 13, RFC 1035, November 1987. 913 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 914 Miller, "Common DNS Implementation Errors and Suggested 915 Fixes", RFC 1536, October 1993. 917 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 918 RFC 1591, March 1994. 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, March 1997. 923 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 924 RFC 2131, March 1997. 926 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 927 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 928 RFC 2136, April 1997. 930 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 931 Specification", RFC 2181, July 1997. 933 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 934 NCACHE)", RFC 2308, March 1998. 936 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 937 Rose, "DNS Security Introduction and Requirements", 938 RFC 4033, March 2005. 940 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 941 Rose, "Resource Records for the DNS Security Extensions", 942 RFC 4034, March 2005. 944 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 945 Rose, "Protocol Modifications for the DNS Security 946 Extensions", RFC 4035, March 2005. 948 18.2. Informative References 950 [Comcast DNSSEC Rollout Announced] 951 Livingood, J., "DNS Security Rollout Begins", Comcast 952 Blog , October 2010, . 955 Appendix A. Document Change Log 957 [RFC Editor: This section is to be removed before publication] 959 -03: Changed some text to make it more neutral, and introduced new 960 sections: Controvery Surrounding DNS Redirect, Future Prospects for 961 DNS Redirect, and Why This Document Merits Publishing. Also closed 962 out an open issue to remove references to RFC 2535, which is 963 obsolete. Lastly, updated the section 8.6 on override of user DNS 964 choices to note a malware case raised during a document review. 966 -02: Fixed some small grammatical nits. 968 -01: Removed sections regarding malicious domain protection, legally- 969 mandated redirect, and content-based redirect based on DNSOP WG 970 feedback to split those out into separate documents which will be 971 published in the future. Also significantly modified the DNSSEC 972 section and moved it to the top of the document. Also, capitalized 973 applicable 2119 language. 975 -00: First version published. 977 Appendix B. Open Issues 979 [RFC Editor: This section is to be removed before publication] 981 1. RW: Consider whether it is a good idea to add to section 4.9 982 (NXDOMAIN RESPONSE) a reference to Authenticated Denial of 983 Existence described in RFC4035 section 5.4 as these should be 984 also redirected. 986 2. MB: Consider addressing how opt-out works when a user roams 987 across a shared WiFi AP. 989 3. Ensure that references are in the appropriate section (normative 990 vs. informative). 992 Authors' Addresses 994 Tom Creighton 995 Comcast Cable Communications 996 One Comcast Center 997 1701 John F. Kennedy Boulevard 998 Philadelphia, PA 19103 999 US 1001 Email: tom_creighton@cable.comcast.com 1002 URI: http://www.comcast.com 1004 Chris Griffiths 1005 Comcast Cable Communications 1006 One Comcast Center 1007 1701 John F. Kennedy Boulevard 1008 Philadelphia, PA 19103 1009 US 1011 Email: chris_griffiths@cable.comcast.com 1012 URI: http://www.comcast.com 1014 Jason Livingood 1015 Comcast Cable Communications 1016 One Comcast Center 1017 1701 John F. Kennedy Boulevard 1018 Philadelphia, PA 19103 1019 US 1021 Email: jason_livingood@cable.comcast.com 1022 URI: http://www.comcast.com 1024 Ralf Weber 1025 Unaffiliated 1026 Bleichgarten 1 1027 Hohenahr-Hohensolms 35644 1028 Germany 1030 Email: rw@hohensolms.de