idnits 2.17.1 draft-livingood-dns-redirect-00.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.ii 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 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 23 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 == Line 779 has weird spacing: '...ple.net www...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (July 6, 2009) is 5380 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) == Unused Reference: 'RFC1536' is defined on line 1173, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1536 ** Downref: Normative reference to an Informational RFC: RFC 1591 ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 7 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: BCP J. Livingood, Ed. 5 Expires: January 7, 2010 Comcast 6 R. Weber 7 Unaffiliated 8 July 6, 2009 10 Recommended Configuration and Use of DNS Redirect by Service Providers 11 draft-livingood-dns-redirect-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on January 7, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 The objective of this document is to describe the design of so-called 60 DNS Redirect services deployed today by Internet Service Providers 61 (ISPs), DNS Application Service Providers (ASPs), and other 62 organizations providing so-called DNS Redirect services via their 63 recursive DNS services, as well as to describe the recommended best 64 current practices regarding such systems. 66 Table of Contents 68 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Major Types of DNS Redirect Services . . . . . . . . . . . . . 7 73 5.1. Web Error Redirect . . . . . . . . . . . . . . . . . . . . 7 74 5.2. Malicious Site Protection . . . . . . . . . . . . . . . . 8 75 5.3. Legally-Mandated DNS Redirect . . . . . . . . . . . . . . 9 76 5.4. Content-Based Redirect . . . . . . . . . . . . . . . . . . 10 77 6. Opt-In or Opt-Out Mechanisms . . . . . . . . . . . . . . . . . 11 78 7. Practices to Avoid . . . . . . . . . . . . . . . . . . . . . . 13 79 8. Functional Design . . . . . . . . . . . . . . . . . . . . . . 15 80 8.1. DNS Recursive Resolver . . . . . . . . . . . . . . . . . . 15 81 8.2. Web Error Landing Server . . . . . . . . . . . . . . . . . 16 82 8.3. Web Browser Client . . . . . . . . . . . . . . . . . . . . 17 83 8.4. Domain White List . . . . . . . . . . . . . . . . . . . . 17 84 8.5. Malicious Domain List . . . . . . . . . . . . . . . . . . 17 85 8.6. Legally-Mandated DNS Redirect Domain List . . . . . . . . 18 86 8.7. Content-Based DNS Redirect Domain List . . . . . . . . . . 19 87 9. Example DNS and HTTP Flows . . . . . . . . . . . . . . . . . . 20 88 10. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 26 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 90 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 91 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 93 15. Normative References . . . . . . . . . . . . . . . . . . . . . 28 94 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 29 95 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 98 1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Introduction 106 Internet users typically are provided with several IP addresses for 107 recursive DNS servers, as described in Section 2.3 of [RFC1591], by 108 their respective ISPs, typically in an automated fashion via DHCP 109 [RFC2131]. Some other users and organizations choose to use a 110 different set of IP address for their DNS servers, which are hosted 111 and managed by another organization, such as a DNS ASP. It is also 112 the case that a number of users and organizations choose to operate 113 their own DNS servers, though those use cases are outside of the 114 scope of this document. 116 ISPs and DNS ASPs have discovered over time that their users would 117 benefit via " enhanced " DNS services, which often rely upon 118 DNS Redirect functionality. These enhanced services, which are 119 offered on an opt-in or opt-out basis (with the exception of where 120 legal mandates preclude this), can perform a number of value added 121 services for users, such as attempting to interpret web address 122 errors and protecting users from reaching domains or fully qualified 123 domain names (FQDNs, Section 5.1 of [RFC1035]) that would cause a 124 user to inadvertently access malware. 126 There are a number of ways such services should and should not work. 127 As a result, a document describing the best current practices in this 128 area is beneficial to the community, and this is the motivation for 129 this document. 131 3. Document Scope 133 This document focuses on the practices of ISPs and DNS ASPs. All 134 other use cases, such as when an Internet user or organization 135 chooses to operate their own DNS servers is outside of the scope of 136 this document. 138 In addition, there are several ways that such entities can provide 139 users with these enhanced services, such as web error redirect 140 services and malicious domain protection services. In addition to 141 methods which rely primarily upon a recursive DNS server, alternate 142 methods include (a) interception and replacement of the error by a 143 web browser client software, (b) interception and replacement of the 144 error by a tool bar, plug-in, personal firewall security software or 145 other web browser client add-on. These alternate methods, which rely 146 upon various types of client software, are also outside of the scope 147 of this document. 149 It is important to note that while these alternate methods are 150 considered out of scope for this document, this should not be 151 interpreted as a negative judgment of their suitability or 152 applicability to the relevant problem space. Instead, these should 153 simply be considered as alternate methods since, as with most any 154 technical problem, there are a variety of valid methods for solving a 155 problem. 157 While the Section 5.2 section indicates that users must be able to 158 opt into or out of DNS Redirect services, the reasons for why an ISP 159 or DNS ASP may choose one or the other as the default are out of 160 scope. 162 Lastly, in the Section 5.2 section of this document, the method by 163 which FQDNs, domains, and/or sites are added or removed from malware 164 lists is outside the scope of this document. 166 4. Terminology 168 While these terms are generally well known, it is important to define 169 them in the context of this document. 171 4.1. Internet Service Provider (ISP) 173 An Internet Service Provider, which provides Internet services, 174 including basic network connectivity. It is not germane to this 175 document what the method of connection is, such as wired or wireless, 176 what the speed of such a connection is, and what other services are 177 included or available to users. It is, however, assumed that the ISP 178 is providing recursive DNS services to their users and is in some 179 manner providing users with the IP addresses of these DNS servers, 180 whether via DHCP, static assignment by users, or some other method. 182 4.2. DNS Application Service Provider (ASP) 184 A DNS Application Service Provider, which provides managed and/or 185 hosted recursive DNS services (and possibly other DNS services) to 186 their users. In the case of managed services, the DNS ASP may 187 remotely manage the recursive DNS servers in a user's network. For a 188 hosted recursive DNS service, these servers are typically located 189 outside of the user's network and these hosted resources are shared 190 across multiple users. In most instances, these are hosted services 191 and users are manually configuring either their DHCP server or their 192 individual computing devices with the IP addresses of the recursive 193 DNS servers operated by their ASP. 195 4.3. Internet User 197 An Internet user, which is generally a person using a computing 198 device to connect to and make use of the Internet. Such users are 199 typically connected at the edge of the network, though the method by 200 which they connect to the Internet is not particularly relevant to 201 this document. 203 4.4. DNS Recursive Resolver 205 A DNS recursive resolver processes fully qualified domain name 206 queries (FQDN, Section 5.1 of [RFC1035]) into IP addresses by finding 207 the resource records in the authoritative DNS servers for the domain 208 associated with the FQDN. The resource records are then cached on 209 the recursive server for future requests until an expiration timer 210 expires called time to live (TTL), as described in Section 5.2 of 211 [RFC2181]. These servers are in most cases provide by ISPs for name 212 resolution. 214 4.5. Web Browser 216 Client software operated by the user locally on their computing 217 device, such as Microsoft Internet Explorer, Mozilla Firefox, Apple 218 Safari, Google Chrome, etc. 220 4.6. Web Error Landing Server 222 The host that a user is directed to when the DNS Recursive Server 223 receives a NXDOMAIN response. The contents of the web page that the 224 web server sends the user varies widely across different ISPs and DNS 225 ASPs. In some cases it is simply a more descriptive error that the 226 user would otherwise receive, while in other cases it may include 227 links to sites similar to the URL attempted and/or a search page, 228 among many other possibilities. 230 4.7. Malicious Domain Web Error Landing Server 232 The web server that a user's web browser is directed to when the DNS 233 Recursive Server matches a DNS query to a malicious domain or FQDN. 234 The contents of the web page that the web server sends the user 235 varies widely across different ISPs and DNS ASPs. In most cases it 236 simply explains that the attempted URL contains malware and that 237 access has been prevented, though there are many other possibilities. 239 4.8. User Options Web Server 241 The web server that a user is directed to via a link on a page served 242 by the Web Error Landing Server, the Malicious Domain Web Error 243 Landing Server, from another system such as an account management 244 system, or via direct access, which enables a user to control whether 245 or not they are opted into or opted out of DNS Redirect services. 246 This is described in additional detail in the Section 6 section. 248 4.9. NXDOMAIN Response 250 In this document, an NXDOMAIN (nonexistent domain) response can be 251 used interchangeably with an RCODE 3 response. The RCODE 3 response 252 was first documented in see Section 4.1.1 of [RFC1035]). Subsequent 253 RFCs introduced the term NXDOMAIN response, which is synonymous with 254 RCODE 3 and tends to be used more frequently, as noted in Section 2.2 255 of [RFC2136], Section 1 of [RFC2308], and Section 5.4 of [RFC2535]. 257 5. Major Types of DNS Redirect Services 259 DNS Redirect services can be classified into several major 260 categories, as follows below. 262 5.1. Web Error Redirect 264 A web error redirect service enables an ISP or ASP to provide a user, 265 who is generally utilizing a web browser, with an improved user 266 experience when an attempt to reach a nonexistent domain is made. 268 5.1.1. Web Error Redirect Problem Statement 270 A user enters an incorrect URL into their web browser, such as 271 http://www.example.invalid, where .invalid is a nonexistent Top Level 272 Domain (TLD, see Section 2 of [RFC1591]). In such a case, a user 273 would typically receive an error. 275 5.1.2. Web Error Redirect Solution Description 277 When a recursive DNS server detects such a nonexistent domain error 278 (NXDOMAIN, see Section 4.1.1 of [RFC1035]), the ISP or ASP can 279 instead provide a IP address for a Web Error Landing Server that can 280 present the user with a list of suggested destinations rather than 281 simply an error page. This page must also provide the user with a 282 link to a method of opting out in the future. See Figure 1, 283 Figure 2, and Figure 8 for examples below. 285 5.1.3. Web Error Redirect Solution Considerations 287 It is important to note that this technology can directly impact non- 288 web clients such as instant messaging, VPNs, FTP, email filters- 289 related DNS queries. Thus, special exclusions may need to be made in 290 order to prevent unintentional side effects. Design considerations 291 for the Web Error Search and Malicious Site Protection services 292 should include properly and promptly terminating non-HTTP connection 293 requests. Only A and AAAA resource records should be redirected, all 294 other resource record types must be answered as if there was no 295 redirection. 297 5.2. Malicious Site Protection 299 Malware websites have proliferated recently, making malware and bot 300 networks a major problem for users. In many cases, the initial 301 contact with a virus or malware occurs when an unsuspecting user 302 visits a particular website. This has even been observed to occur 303 when a user visits an otherwise legitimate website, which contains 304 external references that happen to contain malware, for example (such 305 as advertisements served by a third party). Many organizations 306 maintain lists of domains and FQDNs which host malware. 308 5.2.1. Malicious Site Protection Problem Statement 310 A user, malware agent, or bot requests a URL www.example.net or 311 domain example.net. This site is associated with distributing 312 malware or some other malicious activity that would not be desired by 313 the user. The correct IP address is returned by the DNS and the user 314 accesses the malware site or domain and their computer is infected 315 with a bot. 317 5.2.2. Malicious Site Protection Solution Description 319 By using Malicious Site Protection, a user may have their DNS 320 response redirected from the IP address for the malicious URL 321 www.example.net or domain example.net to a safe website that explains 322 why the user was redirected. Importantly, the application attempting 323 to access a malicious resource may or may not be a web browser and, 324 further, may be operating without the user's knowledge and/or 325 permission. This page on the aforementioned safe website that the 326 user is directed to may also provide the user with a link to a method 327 of opting out in the future. See Figure 3 and Figure 9 for examples 328 below. There may also be limited cases where it could be harmful to 329 the objective of Malicious Site Protection to redirect the user to a 330 safe website, in which case the user may not be directed to any 331 resource, and a NXDOMAIN response be provided. 333 5.2.3. Malicious Site Protection Solution Considerations 335 It is important to note that this technology can directly impact non- 336 web clients such as instant messaging, VPNs, FTP, email filters- 337 related DNS queries. Thus, special exclusions may need to be made in 338 order to prevent unintentional side effects. Design considerations 339 for the Web Error Search and Malicious Site Protection services 340 should include properly and promptly terminating non-HTTP connection 341 requests. A range of resource records may be redirected, such as A, 342 AAAA, MX, SRV, and NAPTR records, in order to fulfill the objective 343 of preventing access to certain network elements containing malicious 344 content or which and in some way used to transmit, relay, or 345 otherwise transfer malicious content. All other resource record 346 types must be answered as if there was no redirection. 348 Malicious domain protection is also only effective if a user is 349 actually using the DNS IP addresses that have this functionality. 350 Thus, should a user's computer become compromised with some type of 351 bot or virus that changes their DNS IP addresses (typically without 352 their knowledge), the malicious domain protection would have no 353 effect since the user is now pointed to DNS servers which are 354 presumably in the control of a third party with malicious intentions. 356 5.3. Legally-Mandated DNS Redirect 358 A regulatory organization or other entities with law enforcement 359 authority over ISP businesses may in some cases mandate or otherwise 360 compel ISPs and/or DNS ASPs to perform DNS Redirection for specific 361 sites. For example, local laws may compel an ISP and/or DNS ASP to 362 attempt to protect/prevent users from viewing illegal content via a 363 mandate to redirect or block specific sites and/or domains. However, 364 it is out of the scope of this document to address the suitability of 365 DNS Redirect for this problem, how this may or may not affect user 366 rights/freedoms in various jurisdictions, problematic judgment areas 367 which may exist relating to management of applicable site lists, 368 unintended side effects of legally-mandated lists, etc. 370 5.3.1. Legally-Mandated DNS Redirect Problem Statement 372 Governments, whether via regulatory or law enforcement bodies, as 373 well as courts, sometimes require ISPs and/or DNS ASPs to block 374 access to certain sites or domains. In some cases, these entities 375 will provide a site (FQDN) and/or domain list to the ISP and/or DNS 376 ASP, and compel the ISP and/or DNS ASP to prevent access to these 377 sites and/or domains via the DNS. 379 5.3.2. Legally-Mandated DNS Redirect Solution Description 381 By using legally-mandated domain redirection, a user may have their 382 DNS response redirected from the IP address for the URL 383 www.illegalcontent.example.net or domain illegalcontent.example to a 384 "safe" website that may explain why the user was redirected. See 385 Figure 4 and Figure 10 for examples below. 387 5.3.3. Legally-Mandated DNS Redirect Solution Considerations 389 It is important to note that these governmental and/or law 390 enforcement actions are frequently quite controversial in a given 391 jurisdiction, and also that there are many examples where lists have 392 inadvertently blocked legal content and therefore improperly blocked 393 the freedom of access to legitimate and legal content. A range of 394 resource records may be redirected, such as A, AAAA, SRV, and NAPTR 395 records, in order to fulfill particular legal mandates. All other 396 resource record types must be answered as if there was no 397 redirection. 399 Depending upon government, law enforcement, and/or court-related 400 mandates/laws/rules, an ISP and/or DNS ASP performing Legally- 401 Mandated DNS Redirect may not provide an opt-out capability, and in 402 some jurisdictions they must not provide an opt-out capability. ISPs 403 should disclose openly that they have been compelled to perform 404 legally-mandated DNS Redirect, provided that such disclosure has not 405 been prohibited for some reason by any relevant regulator, court, or 406 law enforcement organization. For example, a page which may be 407 served in response to redirection should be a location at which such 408 a disclosure is made, in addition to the relevant sections of network 409 policy documents, etc. 411 In some cases where the such Legally-Mandated DNS Redirect is 412 required, there may be hosts with a mix of legal and illegal/ 413 restricted content such that the redirect will not be to an error 414 page but will be instead to a proxy server, which will be capable of 415 performing a more fine-grained content analysis. The manner in which 416 such functionality might work is outside the scope of this document. 418 5.4. Content-Based Redirect 420 Content-Based Redirect is similar to content filtering, except that 421 it is more aptly "content avoidance." To explain this difference 422 more fully, no content is actually filtered by an ISP or DNS ASP 423 system before it is sent to the user. Instead, DNS responses can be 424 modified in order that a user is protected from content which they 425 deemed inappropriate. 427 5.4.1. Content-Based Redirect Problem Statement 429 A user wishes to avoid visiting web sites with certain types of 430 content. For example, the user may have children in their household 431 and wished to prevent access to adult-themed content. Other examples 432 of the type of content that the user may wish to prevent access to 433 may include categories such as illicit drugs, alcohol, hate speech, 434 and weapons, among many other potential categories. The user in this 435 case may not exclusively be a residential user, but may also be the 436 network administrator for a small business, school, church, or other 437 organization. Thus, there may be a wide range of motivations for the 438 desire to prevent access to certain types of content. 440 5.4.2. Content-Based Redirect Solution Description 442 By using Content-Based Redirect, a user may have their DNS response 443 redirected from the IP address for the inappropriate URL 444 www.inappropriate.example.com to a safe website that explains why the 445 user was redirected. This page may also provide the user with a link 446 to a method of reconfiguring the service, in case it has unexpected 447 results and a site that the user wishes to access has been blocked. 448 In addition, the user should be able to fully configure Content-Based 449 Redirect via the User Options Web Server, such as electing which 450 categories of content they may wish to prevent access to. See 451 Figure 5 and Figure 11 for examples below. 453 5.5. Content-Based Redirect Solution Considerations 455 A range of resource records may be redirected, such as A, AAAA, SRV, 456 and NAPTR records, in order to fulfill the user-directed objective of 457 preventing access to certain types of content. All other resource 458 record types must be answered as if there was no redirection. 460 6. Opt-In or Opt-Out Mechanisms 462 ISPs and DNS ASPs must provide their users with a method to opt into 463 (opt-in) or out (opt-out) of some or all DNS Redirect services. Opt- 464 out and opt-in methods should be reliable and should take into 465 consideration the Section 7 section below. Whether such services are 466 offered on an opt-in or opt-out basis depends on a range of factors 467 which are outside of the scope of this document. The two different 468 methods, opt-out and opt-in, are described below. 470 6.1. Opt-Out 472 Opt-Out is used when the users are by default offered all or some DNS 473 Redirect services. As a result, the user must take an action to 474 disable some or all such services. This is typically performed via a 475 User Options Web Server. Users that have chosen to opt-out should 476 receive DNS responses which are indistinguishable from those 477 responses provided by a DNS server with no DNS Redirect 478 functionality. In addition, opt-out should be persistent in nature, 479 which means that opt-out should be tied to a fixed credential or 480 attribute of some type, such as an account identifier, billing 481 identifier, or equipment identifier, which is not typically subject 482 to change on a regular basis. 484 6.2. Opt-In 486 Opt-In is used when the users are by default not offered any DNS 487 Redirect services. As a result, the user must take an action to 488 enable some or all such services. This is typically performed via a 489 User Options Web Server. 491 6.3. Automated Mechanisms and Reasonable Processing Times 493 Once a user has selected to opt-in or opt-out of DNS Redirect 494 services, such changes should occur automatically, when this is 495 technically possible, without requiring the user to manually change 496 any settings on their computing device. Such changes should also 497 occur within a reasonable period of time. In some cases, however, a 498 user may be offered the ability to speed the period of time for these 499 changes to take effect, such as by restarting the computing device or 500 a piece of network equipment which connects them to their ISP's 501 network, for example. 503 While an automated mechanism may be the easiest for users, since it 504 requires no manual reconfiguration of their network settings, the 505 authors also recognize that there may be extenuating circumstances 506 where this is not achievable. In such cases, which may for example 507 be due to the particular attributes of one or another ISP's network 508 design, a fully automated mechanism may not be possible. Another 509 example is where a user is switching from their ISP's DNS server IP 510 addresses to those of a DNS ASP. As a result, a user in all of these 511 cases, as well as other possible cases, must manually reconfigure 512 their network with different DNS IP addresses. 514 6.4. Type of Opt-Out Method 516 There are several workable methods that can be employed to effect the 517 actual opt-out for a given user. These include setting a local user 518 application attribute, such as via a cookie in a web browser, as well 519 as setting a network attribute, via a DHCP change or manually 520 configuring the DNS IP addresses (in the operating system, modem, 521 home gateway device, or router) in order to change the DNS IP 522 addresses for a particular user. 524 While all of these methods are workable and can be made reliable, the 525 best current method is via a network-based change of some sort. In 526 this way, all Internet-connected computing devices within a given 527 household are included in the opt-out (these devices are generally 528 connected in some manner to the LAN side of some type of customer 529 premise device, such as a cable modem or DSL modem). This is in 530 contrast to a method which uses a local user application attribute, 531 such as a cookie in a web browser, where deletion of cookies, upgrade 532 to a new operating system, upgrade to a new web browser, use of a 533 different web browser, or countless other factors on that device 534 could cause the user to be opted back into a DNS Redirect service. 535 Thus, a network-based approach which sets opt-out-related attributes 536 at the device, or household level, is the most inclusive and 537 persistent method for providing a reliable opt-out method, and is the 538 recommended practice. 540 7. Practices to Avoid 542 This document primarily focuses on the best current practices for an 543 ISP or ASP to provide users with DNS Redirect services. However, it 544 is important to note that some entities may not operate in accordance 545 with such practices. As such, some of these are cataloged below in 546 order to contrast them with best practices and provide information 547 which may be of interest and use to the community. 549 7.1. Improper Redirect of Valid Responses 551 It has been observed that some service providers improperly utilize 552 DNS Redirect services when there is a valid DNS resource record 553 returned in response to a DNS recursive query. The effect is to 554 redirect users to a server not maintained by the intended 555 destination, such as a web site that looks like the intended web site 556 but is not actually the intended site and is instead controlled by 557 the service provider. For example a DNS query for www.example.com 558 results in a valid A record response, but this valid response is 559 instead replaced with an A record controlled by the service provider. 560 In this case the intended server identified with the valid A record 561 contained valid, lawful, non-malicious content, and there would 562 otherwise appear to be no valid justification for a redirect to 563 occur. See Figure 12 for an example below. 565 If there is a valid and reasonable justification for such a redirect 566 to occur, examples of which are not currently known by the authors of 567 this document, then the resulting connection to the server that the 568 user has been redirected to should clearly and prominently disclose 569 that this is not the intended site. For example, in the case of an 570 attempt by a user to connect to a web site, the site may contain a 571 banner or frame which indicates that this is not the intended site or 572 that the site is in some manner controlled by the service provider. 573 In addition, such a notice should also offer a clear method to opt- 574 out of this redirect function. 576 7.2. Redirect of SERVFAIL Responses 578 Redirection of SERVFAIL responses should not occur. SERVFAIL 579 responses may occur intermittently in an operational network for a 580 variety of highly transient reasons. As a result, a DNS Redirect 581 should not be performed when a SERVFAIL response is received, as 582 normal retry a short time later is likely to result in a valid 583 response. 585 7.3. Routinely Broken, Purposefully Broken, and Otherwise Unreliable 586 Opt-Out Mechanisms 588 There are several well known and dependable methods of opt-out 589 mechanisms that ISPs and DNS ASPs can deploy for users to opt-out of 590 their DNS Redirect services. These methods can rather easily be 591 employed and are highly recommended, as noted in Section 6. However, 592 some ISPs and DNS ASPs may instead choose to employ a less dependable 593 mechanism, which routinely fails to work as expected by users or is 594 known not to function properly. 596 For example, one routinely unreliable method for opt-out is the 597 cookie-based method. When a user opts out of a DNS Redirect service, 598 a cookie is installed in their web browser. The problem with this 599 method occurs when a user clears their cookies or the cookies are 600 deleted for some reason. In some cases, users may configure their 601 web browsers to clear all cookies every time the close their web 602 browser. Thus, one possible effect upon the user in this case is 603 that they are once again opted into the redirect service. 604 Furthermore, a cookie-based method has the effect of only opting out 605 browser-based protocols (generally HTTP and HTTPS), which means that 606 the user may have non-web applications affected by DNS Redirect, even 607 though they believe they have opted-out. As a result, there is no 608 assured permanency with this opt-out method, nor does it work 609 consistently across all applications and protocols, which can be 610 aggravating to users who do not wish to utilize DNS Redirect 611 services. 613 Another example of an unreliable method for opt-out is one where opt- 614 out is tied to the IP address of the user, where that address may be 615 subject to change on a regular basis, such as via an ISP-based DHCP 616 lease. In such a case, if opt-out was tied to what can be considered 617 a largely dynamic IP address, then the user would be opted-in every 618 time they received a new IP address, forcing them to repeatedly opt- 619 out. 621 7.4. Markedly Slower DNS Query Performance 623 An ISP or DNS ASP should also understand that DNS query latency, the 624 time between when a user's stub resolver issues and DNS query and 625 receives a DNS response, should be kept as low as is reasonably 626 possible. High DNS query latency is often perceived by users, and 627 can have an adverse effect on a variety of applications where low DNS 628 query latency may be especially important. Any additional processing 629 which must be performed in order to provide DNS Redirect services 630 should be monitored closely, in order that DNS Redirect functionality 631 does not markedly slow DNS query performance. 633 7.5. Override of a User's DNS Selection 635 Some users may decide to use the DNS server IP addresses of a DNS ASP 636 or other non-ISP-provided DNS servers. Such selections should be 637 preserved as the free choice of a user, particularly when DNS 638 Redirect services are offered. Thus, an ISP should not redirect port 639 53 DNS traffic from servers intended by the user via their selection 640 of non-ISP DNS servers to the DNS servers of the ISP, except in 641 reasonable and justifiable cases where a user has been placed into a 642 so-called "walled garden" for reasons of abuse, security compromise, 643 account non-payment, new service activation, etc. 645 8. Functional Design 647 The functional design described in this section is intended to be 648 generally representative of the many different ways that DNS Redirect 649 services are deployed today. As such, they are necessarily high 650 level and different implementations may vary somewhat, due to any 651 number of factors. 653 8.1. DNS Recursive Resolver 655 The DNS Recursive Resolver is used by the host computer to translate 656 fully qualified domain names into IP addresses, according to Section 657 3.6.1 of [RFC1034]. When a FQDN does not exist in authoritative DNS 658 a NXDOMAIN response, as described in Section 4.1.1 of [RFC1035] is 659 normally returned (see Figure 1). In the case of DNS Redirect, the 660 NXDOMAIN response is changed to reply with a resource record (RR) 661 response which instructs the host computer to send the original 662 request to a new IP address (see Figure 1). 664 Request Request 665 www.example.invalid www.example.invalid 666 +--------+ +--------+ 667 ++--++ ------------> | | ------------> | | 668 || || | | | | 669 +-++--++-+ | | | | 670 +--------+ <------------ | | <------------ | | 671 Host NXDOMAIN +--------+ NXDOMAIN +--------+ 672 Computer Response Recursive Response Authoritative 673 Server Server 675 Figure 1: DNS Redirect Response 677 8.2. Web Error Landing Server 679 When a user requests an invalid URL or Domain, their web client is 680 redirected to a Web Error Landing Server which presents several 681 possible helpful website views (see Figure 2). The first is "Did you 682 mean..." response which presents the user with possible correct 683 results based on their original invalid request. The search server 684 can also present search engine results to the user. 686 Request Request 687 www.example.invalid www.example.invalid 688 +--------+ +--------+ 689 ++--++ ---------------> | | --------------->| | 690 || || | | | | 691 +-++--++-+ | | | | 692 +--------+ <-------------- | | <------------- | | 693 Host Redirect +--------+ NXDOMAIN +--------+ 694 Computer IP Address Recursive Response Authoritative 695 Server Server 696 | 697 | ___________________________________ 698 | +--------+ | Web Response: | 699 | | | | "Did you mean...www.example.com"| 700 +------> | | ------> |__________________________________| 701 | | | Search result: #1 | 702 | | | Search result: #2 | 703 +--------+ |__________________________________| 704 Web Server 705 Landing Page 707 Figure 2: Web Error Landing Server 709 8.3. Web Browser Client 711 The Web Browser Client is redirected to a Web Server Landing Page 712 instead of presenting an error page when there is no valid DNS record 713 present. 715 Examples of common Web Browser Clients include: 717 o Microsoft Internet Explorer 719 o Mozilla Firefox 721 o Apple Safari 723 o Google Chrome 725 o Opera 727 8.4. Domain White List 729 There may be certain domains which should be not be redirected under 730 any circumstances for legal, business, or other reasons. The Domain 731 White List can contain both domains, such as *.example.com, as well 732 as specific FQDNs, such as www.example.com. For instance, the owner 733 of example.com may request that the ISP or DNS ASP not perform DNS 734 Redirect for the example.com domain, so that there is no DNS Redirect 735 resulting from queries to nonexistent names, such as 736 invalid.example.com. 738 8.5. Malicious Domain List 740 Using a Malicious Domain List, a DNS server can redirect DNS requests 741 that were intended for malicious websites or domains to a web server 742 landing page (see Figure 3). The Malicious Domain List can contain 743 both domains, such as *.example.net, as well as specific FQDNs, such 744 as www.example.net. 746 Request Request 747 www.example.net www.example.net 748 +--------+ +--------+ 749 ++--++ ---------------> | | --------------->| | 750 || || | | | | 751 +-++--++-+ | | | | 752 +--------+ <-------------- | | <------------- | | 753 Host Redirect +--------+ Response +--------+ 754 Computer IP Address Recursive IP Address Authoritative 755 Server Server 756 | 757 | ___________________________________ 758 | +--------+ | Web Response: | 759 | | | | "Malware software alert!" | 760 +-------> | | ------> |__________________________________| 761 | | | The site you attempted to access | 762 | | | is known to host malware that | 763 +--------+ | could damage your computer. | 764 Web Server |__________________________________| 765 Landing Page 767 Figure 3: Malicious Domain Response 769 8.6. Legally-Mandated DNS Redirect Domain List 771 Using a Malicious Domain List, a DNS server can redirect DNS requests 772 that were intended for malicious websites or domains to a web server 773 landing page (see Figure 3). The Legally-Mandated DNS Redirect 774 Domain List can contain both domains, such as 775 *.illegalcontent.example, as well as specific FQDNs, such as 776 www.illegalcontent.example.net. 778 Request Request 779 www.illegalcontent.example.net www.illegalcontent.example.net 780 +--------+ +--------+ 781 ++--++ ---------------> | | --------------->| | 782 || || | | | | 783 +-++--++-+ | | | | 784 +--------+ <-------------- | | <------------- | | 785 Host Redirect +--------+ Response +--------+ 786 Computer IP Address Recursive IP Address Authoritative 787 Server Server 788 | 789 | ___________________________________ 790 | +--------+ | Web Response: | 791 | | | | "Illegal content alert!" | 792 +-------> | | ------> |__________________________________| 793 | | | The site you attempted to access | 794 | | | has been designated as hosting | 795 +--------+ | illegal content under XYZ law of | 796 Web Server | 2009, which your ISP is legally | 797 Landing Page | compelled to block or be fined. | 798 |__________________________________| 800 Figure 4: Legally-Mandated DNS Redirect Domain Response 802 8.7. Content-Based DNS Redirect Domain List 804 Using a Content Protection List, a DNS server can redirect DNS 805 requests that were intended for websites or domains containing 806 content deemed inappropriate by a user, to a web server landing page 807 (see Figure 5). The Legally-Mandated DNS Redirect Domain List can 808 contain both domains, such as *.inappropriate.example, as well as 809 specific FQDNs, such as www.inappropriate.example.com. 811 Request Request 812 www.inappropriate.example.com www.inappropriate.example.com 813 +--------+ +--------+ 814 ++--++ ---------------> | | --------------->| | 815 || || | | | | 816 +-++--++-+ | | | | 817 +--------+ <-------------- | | <------------- | | 818 Host Redirect +--------+ Response +--------+ 819 Computer IP Address Recursive IP Address Authoritative 820 Server Server 821 | 822 | ___________________________________ 823 | +--------+ | Web Response: | 824 | | | | "Inappropriate content alert!" | 825 +------> | | ------> |__________________________________| 826 | | | The site you attempted to access | 827 | | | has been blocked by you or | 828 +--------+ | your network administrator. | 829 Web Server |__________________________________| 830 Landing Page 832 Figure 5: Content-Based Redirect Domain Response 834 9. Example DNS and HTTP Flows 836 9.1. Successful DNS Lookup and HTTP Flow 838 This example represents a successful lookup of a valid DNS RR, and 839 the resulting HTTP transaction. 841 Web DNS R DNS A DNS Web Server 842 Browser Client Server Server 10.1.10.10 844 | Request | A | | | 845 |www.example. |Record Query | A | | 846 | com |www.example. |Record Query | | 847 |------------>| com |www.example. | | 848 | |------------>| com | | 849 | | |------------>| | 850 | | | A Record | | 851 | | A Record | 10.1.10.10 | | 852 | DNS Response| 10.1.10.10 |<------------| | 853 | 10.1.10.10 |<------------| | | 854 |<------------| | | | 855 | HTTP GET | | | | 856 | 10.1.10.10 | | | | 857 |------------------------------------------------------>| 858 | | | | | 859 | | | | | 860 | | | | | 862 Figure 6: Successful DNS Lookup and HTTP Flow 864 9.2. Unsuccessful DNS Lookup and HTTP Flow 866 This example represents a lookup of a nonexistent DNS RR, and the 867 resulting HTTP transaction. 869 Web DNS R DNS A DNS 870 Browser Client Server Server 872 | Request | A | | 873 |www.example. |Record Query | A | 874 | invalid |www.example. |Record Query | 875 |------------>| invalid |www.example. | 876 | |------------>| invalid | 877 | | |------------>| 878 | | | NXDOMAIN | 879 | | NXDOMAIN |<------------| 880 | NXDOMAIN |<------------| | 881 |<------------| | | 882 | | | | 884 Figure 7: Unsuccessful DNS Lookup and HTTP Flow 886 9.3. DNS Redirect and HTTP Flow 888 This example represents a lookup of a non-existing DNS RR, and the 889 HTTP transition that results from a typical DNS Redirect service. 891 Redirect 892 Host R DNS A DNS Web Server Web Server 893 Computer Server Server 10.2.20.20 10.1.10.10 895 | A | | | | 896 |Record Query | A | | | 897 |www.example. |Record Query | | | 898 | invalid |www.example. | | | 899 |------------>| invalid | | | 900 | |------------>| | | 901 | A Record | NXDOMAIN | | | 902 | 10.2.20.20 |<------------| | | 903 |<------------| | | | 904 | HTTP GET | | | | 905 | 10.2.20.20 | | | | 906 |---------------------------------------->| | 907 | | | HTTP 200 OK | | 908 |<----------------------------------------| | 909 | A | | | | 910 |Record Query | A | | | 911 |www.example. |Record Query | | | 912 | com |www.example. | | | 913 |------------>| com | | | 914 | |------------>| | | 915 | | A Record | | | 916 | A Record | 10.1.10.10 | | | 917 | 10.1.10.10 |<------------| | | 918 |<------------| | | | 919 | HTTP GET | | | | 920 | 10.1.10.10 | | | | 921 |------------------------------------------------------>| 922 | | | | HTTP 200 OK | 923 |<------------------------------------------------------| 924 | | | | | 926 Figure 8: DNS Redirect and HTTP Flow 928 9.4. Malicious Site Redirect and HTTP Flow 930 This example represents a lookup of a valid RR which hosts malware, 931 and the HTTP transaction that results from a typical Malicious Site 932 Protection service. 934 R DNS Mal Redirect 935 Host R DNS Server Web Server 936 Computer Server Mal List 10.2.20.20 938 | A | | | 939 |Record Query | Mal List | | 940 |www.example. | Query | | 941 | net |www.example. | | 942 |------------>| net | | 943 | |------------>| | 944 | | Postivie | | 945 | A Record | Match | | 946 | 10.2.20.20 |<------------| | 947 |<------------| | | 948 | HTTP GET | | | 949 | 10.2.20.20 | | | 950 |---------------------------------------->| 951 | | | HTTP 200 OK | 952 |<----------------------------------------| 953 | | | | 955 Figure 9: Malicious Site Redirect and HTTP Flow 957 9.5. Legally-Mandated Redirect and HTTP Flow 959 This example represents a lookup of a valid RR which hosts illegal 960 content, and the HTTP transaction that results from a typical 961 Legally-Mandated DNS Redirect function. 963 R DNS Illegal Content 964 Server Redirect 965 Host R DNS Illegal Web Server 966 Computer Server Content List 10.2.20.20 968 | A | | | 969 |Record Query | Illegal | | 970 | www. | Content List | | 971 |illegalcontent.| | | 972 |example.net | Query | | 973 | | www. | | 974 | |illegalcontent.| | 975 | |example.net | | 976 |-------------->| | | 977 | |-------------->| | 978 | | Postivie | | 979 | A Record | Match | | 980 | 10.2.20.20 |<--------------| | 981 |<--------------| | | 982 | HTTP GET | | | 983 | 10.2.20.20 | | | 984 |---------------------------------------------->| 985 | | | HTTP 200 OK | 986 |<----------------------------------------------| 987 | | | | 989 Figure 10: Legally-Mandated Redirect and HTTP Flow 991 9.6. Content-Based Redirect and HTTP Flow 993 This example represents a lookup of a valid RR which hosts content 994 which has been deemed inappropriate by a user, and the HTTP 995 transaction that results from a typical Content-Based Redirect 996 function. 998 R DNS Inappropriate 999 Server Content Redirect 1000 Host R DNS Inappropriate Web Server 1001 Computer Server Content List 10.2.20.20 1003 | A | | | 1004 |Record Query | Illegal | | 1005 | www. | Content List | | 1006 |inappropriate. | | | 1007 |example.com | Query | | 1008 | | www. | | 1009 | |inappropriate. | | 1010 | |example.com | | 1011 |-------------->| | | 1012 | |-------------->| | 1013 | | Postivie | | 1014 | A Record | Match | | 1015 | 10.2.20.20 |<--------------| | 1016 |<--------------| | | 1017 | HTTP GET | | | 1018 | 10.2.20.20 | | | 1019 |---------------------------------------------->| 1020 | | | HTTP 200 OK | 1021 |<----------------------------------------------| 1022 | | | | 1024 Figure 11: Content-Based Redirect and HTTP Flow 1026 9.7. Improper Redirect of Valid Response Redirect and HTTP Flow 1028 This example represents an improper redirect occurring when a valid 1029 DNS RR should have been returned in response to a DNS recursive query 1030 for an example website, the resulting HTTP transaction, and that no 1031 DNS query or HTTP traffic was sent to the valid authoritative DNS 1032 server and valid web server. Section 10 below shows one of the 1033 reasons why this practice is problematic. Another reason is that a 1034 user intends to visit a valid resource with lawful and legitimate 1035 content, such as a web site, and is instead sent to a different 1036 destination (which may even closely resemble the intended site, in 1037 the pattern used by phishing sites). 1039 R DNS Improper Valid 1040 Server Redirect Valid Web 1041 Host R DNS Improper Web Server A DNS Server 1042 Computer Server Reirect List 10.2.20.20 Server 10.1.10.10 1044 | A | Improper | | | | 1045 |Record Query |Redirect List| | | | 1046 |www.example. | Query | | | | 1047 | com |www.example. | | | | 1048 |------------>| com | | | | 1049 | |------------>| | | | 1050 | | Postivie | | | | 1051 | A Record | Match | | | | 1052 | 10.2.20.20 |<------------| | | | 1053 |<------------| | | | | 1054 | HTTP GET | | | | | 1055 | 10.2.20.20 | | | | | 1056 |-------------------------------------->| | | 1057 | | |HTTP 200 OK| | | 1058 |<--------------------------------------| | | 1059 | | | | | | 1061 Figure 12: Improper Redirect of Valid Response Redirect and HTTP Flow 1063 10. DNSSEC Considerations 1065 DNS security extensions defined in [RFC4033], [RFC4034], and 1066 [RFC4035] use cryptographic digital signatures to provide origin 1067 authentication and integrity assurance for DNS data. This is done by 1068 creating signatures for DNS data on a Security-Aware Name Server that 1069 can be used by Security-Aware Resolvers to verify the answers. As 1070 the DNS redirections described herein take place on the recursive 1071 server there is no need to look into the communication between the 1072 recursive resolvers and name servers. Depending on the security 1073 awareness of recursive server used to perform DNS Redirect services, 1074 as well as the security awareness of the stub resolvers the following 1075 impact is observed on DNS Redirect when giving out answers to fully 1076 secured zones or parent zones: 1078 o Security-Oblivious Resolver with Validating and Non-Validating 1079 Stub Resolvers: Since the resolver is not security-aware, it will 1080 not pass any DNSSEC-related packets and, thus, even the validating 1081 stub resolver cannot validate the records and will present the DNS 1082 Redirect answers to the application. 1084 o Security-Aware Resolver with Non-Validating Stub Resolver: As the 1085 security-aware resolver does not have the key generated the 1086 resource record signatures (RRSIG) for it's response it should 1087 give the redirected answer out as indeterminate or insecure. As 1088 the stub resolver is not doing any validation it will use the DNS 1089 Redirect response and pass them on to the application. 1091 o Security-Aware Resolver with Validating Stub Resolver: As the 1092 security-aware resolver does not have the key generated the 1093 resource record signatures (RRSIG) for it's response it should 1094 give the redirected answer out as indeterminate or insecure. 1095 However, as the validating stub has a DNSKEY record for the zone 1096 or a DS record for the parent zone it cannot validate the answer 1097 and will report it as bogus to the application leading to non- 1098 resolution for that domain. 1100 So the only case where DNS security extensions cause problems for DNS 1101 Redirect is with a validating stub resolver. This case doesn't have 1102 widespread deployment now and could be mitigated by using trust 1103 anchor, configured by the applicable ISP or DNS ASP, that could be 1104 used to sign the redirected answers. As noted above in Section 9.7, 1105 such improper redirection of valid responses may also cause DNSSEC 1106 trust verification problems. 1108 11. Security Considerations 1110 Security best practices should be followed regarding access to the 1111 opt-in and opt-out functions, in order that someone other than the 1112 user is able to change the user's DNS Redirect settings. For 1113 example, the User Options Web Server must not permit someone to 1114 modify a page URI to access and change another user's options. Thus, 1115 if the URI is 1116 "http://www.example.net/redirect-options.php?account=1234", someone 1117 must not be able to modify the account to be "=1235" and then be able 1118 to change the options for a different user with some other additional 1119 validation being performed. While web site security practices are 1120 outside the scope of this document, the authors believe it is 1121 important to identify such problematic use cases to any ISPs and DNS 1122 ASPs offering and/or implementing DNS Redirect functionality. 1124 12. IANA Considerations 1126 There are no IANA considerations in this document. 1128 13. Contributors 1130 The following people made significant textual contributions to this 1131 document and played an important role in the development and 1132 evolution of this document: 1134 Don Bowman, Sandvine (don@sandvine.com) 1136 Rick Hiester, Verizon (richard.hiester@verizon.com) 1138 Chris Roosenraad, Time Warner Cable (chris.roosenraad@twcable.com) 1140 David Ulevitch, OpenDNS (david@opendns.com) 1142 14. Acknowledgements 1144 The authors and contributors also wish to acknowledge the assistance 1145 of the following individuals in helping us to develop and/or review 1146 this document: 1148 John Barnitz, Comcast Cable Communications 1149 (john_barnitz@cable.comcast.com) 1151 Mike Burns, Cablevision (mburns@cablevision.com) 1153 Phil Marcella, Comcast Interactive Media 1154 (phillip_marcella@cable.comcast.com) 1156 Luis Uribarri, Comcast Cable Communications 1157 (luis_uribarri@cable.comcast.com) 1159 Sandy Wilbourn, Nominum (sandy.wilbourn@nominum.com) 1161 Matt Williams, Cox Cable (matt.williams@cox.com) 1163 And another contributor... 1165 15. Normative References 1167 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1168 STD 13, RFC 1034, November 1987. 1170 [RFC1035] Mockapetris, P., "Domain names - implementation and 1171 specification", STD 13, RFC 1035, November 1987. 1173 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 1175 Miller, "Common DNS Implementation Errors and Suggested 1176 Fixes", RFC 1536, October 1993. 1178 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1179 RFC 1591, March 1994. 1181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1182 Requirement Levels", BCP 14, RFC 2119, March 1997. 1184 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1185 RFC 2131, March 1997. 1187 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1188 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1189 RFC 2136, April 1997. 1191 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1192 Specification", RFC 2181, July 1997. 1194 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1195 NCACHE)", RFC 2308, March 1998. 1197 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1198 RFC 2535, March 1999. 1200 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1201 Rose, "DNS Security Introduction and Requirements", 1202 RFC 4033, March 2005. 1204 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1205 Rose, "Resource Records for the DNS Security Extensions", 1206 RFC 4034, March 2005. 1208 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1209 Rose, "Protocol Modifications for the DNS Security 1210 Extensions", RFC 4035, March 2005. 1212 Appendix A. Document Change Log 1214 [RFC Editor: This section is to be removed before publication] 1216 -00 version: 1218 o first version published 1220 Appendix B. Open Issues 1222 [RFC Editor: This section is to be removed before publication] 1224 1. RW: Consider whether it is a good idea to add to section 4.9 1225 (NXDOMAIN RESPONSE) a reference to Authenticated Denial of 1226 Existence described in RFC4035 section 5.4 as these should be 1227 also redirected. 1229 2. MB: Consider addressing how opt-out works when a user roams 1230 across a shared WiFi AP. 1232 3. RH: Update reference to RFC2535, which is obsoleted by RFCs 4033, 1233 4034, 4035. 1235 4. JL: Consider capitalizing RFC 2119 language used. 1237 5. JL: Need additional review and development of the DNSSEC section. 1238 Could probably benefit by having a DNSSEC expert perform a review 1239 of that section and offer suggestions. 1241 Authors' Addresses 1243 Tom Creighton 1244 Comcast Cable Communications 1245 One Comcast Center 1246 1701 John F. Kennedy Boulevard 1247 Philadelphia, PA 19103 1248 US 1250 Email: tom_creighton@cable.comcast.com 1251 URI: http://www.comcast.com 1253 Chris Griffiths 1254 Comcast Cable Communications 1255 One Comcast Center 1256 1701 John F. Kennedy Boulevard 1257 Philadelphia, PA 19103 1258 US 1260 Email: chris_griffiths@cable.comcast.com 1261 URI: http://www.comcast.com 1262 Jason Livingood (editor) 1263 Comcast Cable Communications 1264 One Comcast Center 1265 1701 John F. Kennedy Boulevard 1266 Philadelphia, PA 19103 1267 US 1269 Email: jason_livingood@cable.comcast.com 1270 URI: http://www.comcast.com 1272 Ralf Weber 1273 Unaffiliated 1274 Bleichgarten 1 1275 Hohenahr-Hohensolms 35644 1276 Germany 1278 Email: rw@hohensolms.de