One document matched: draft-livingood-dns-malwareprotect-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- References are listed here so that they can be called via Entity attributes later -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1536.xml">
<!ENTITY RFC1591 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1591.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml">
<!ENTITY RFC2181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC2308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY RFC2535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2535.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- PROCESSING INSTRUCTIONS - GENERAL -->
<!-- EACH ONE STARTS WITH '?' BELOW -->
<!-- give errors on I-D nits and perform DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc strict='yes' ?>
<?rfc toc='yes'?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth='4'?>
<!-- END GENERAL PROCESSING -->
<!-- PROCESSING INSTRUCTIONS - CONTROL OF REFERENCES -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs='yes'?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space -->
<?rfc sortrefs='yes' ?>
<!-- do not start each main section on a new page -->
<?rfc compact='yes' ?>
<!-- keep one blank line between list items -->
<?rfc subcompact='no' ?>
<!-- END REFERENCE PROCESSING -->
<rfc ipr='pre5378Trust200902' docName='draft-livingood-dns-malwareprotect-00' category='info'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- FRONT SECTION -->
<front>
<title abbrev='DNS Redirect for Protection from Malware'>
DNS Redirect for Protection from Malware
</title>
<!-- add role='editor' attribute to author tag below for the editors if appropriate -->
<author initials='T.' surname='Creighton' fullname='Tom Creighton'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>tom_creighton@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='C.' surname='Griffiths' fullname='Chris Griffiths'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>chris_griffiths@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='J.' surname='Livingood' fullname='Jason Livingood' role='editor'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<author initials='R.' surname='Weber' fullname='Ralf Weber'>
<organization abbrev='Unaffiliated'>
Unaffiliated
</organization>
<address>
<postal>
<street>Bleichgarten 1</street>
<region>Hohenahr-Hohensolms</region>
<code>35644 </code>
<country>Germany</country>
</postal>
<email>rw@hohensolms.de</email>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day='4' month='September' year='2010'/>
<!-- META-DATA DECLARATIONS -->
<area></area>
<!-- WG name at the upperleft corner of the doc; 'Internet Engineering Task Force' is fine for individual submissions. -->
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>The objective of this document is to describe the design of so-called DNS-based malware protection services deployed today by Internet Service Providers (ISPs), DNS Application Service Providers (ASPs), and other organizations providing so-called DNS-based malware protection services via their recursive DNS services, as well as to describe the recommended practices regarding such systems. This document specifically and narrowly addresses those cases where DNS Redirect is being utilized to provide a service for end users which blocks domains hosting malicious software.</t>
</abstract>
<!-- END META-DATA DECLARATIONS -->
</front>
<!-- END FRONT SECTION -->
<!-- MIDDLE SECTION -->
<middle>
<section anchor='ReqLang' title='Requirements Language' toc='include'>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section anchor='intro' title='Introduction' toc='include'>
<t>Internet users typically are provided with several IP addresses for recursive DNS servers, as described in Section 2.3 of <xref target="RFC1591"/>, by their respective ISPs, typically in an automated fashion via DHCP <xref target="RFC2131"/>. Some other users and organizations choose to use a different set of IP address for their DNS servers, which are hosted and managed by another organization, such as a DNS ASP. It is also the case that a number of users and organizations choose to operate their own DNS servers, though those use cases are outside of the scope of this document.</t>
<t>ISPs and DNS ASPs have discovered over time that their users would like " enhanced " DNS services which can protect those users from reaching domains or fully qualified domain names (FQDNs, Section 5.1 of <xref target="RFC1035"/>) that would cause a user to inadvertently access malicious software, otherwise known simply as malware.</t>
<t>This document describes the design and function of a DNS-based malware protection service which only provides protection from domains hosting malware, as well as recommended practices and practices to avoid.</t>
</section>
<section title='Document Scope' toc='include'>
<t>This document focuses on the systems and practices of ISPs and DNS ASPs. All other use cases, such as when an Internet user or organization chooses to operate their own DNS servers is outside of the scope of this document.</t>
<t>There are several ways that such entities can provide users with these enhanced DNS services. In addition to methods which rely primarily upon a recursive DNS server, alternate methods include (a) interception and replacement of a malware-hosting domain or FQDN by web browser client software, (b) interception and replacement of a malware-hosting domain or FQDN by a tool bar, plug-in, personal firewall security software or other web browser client add-on. These alternate methods, which rely upon various types of client software, are also outside of the scope of this document.</t>
<t>It is important to note that while these alternate methods are considered out of scope for this document, this should not be interpreted as a negative judgment of their suitability or applicability to the relevant problem space. Instead, these should simply be considered as alternate methods since, as with most any technical problem, there are a variety of valid methods for solving a problem.</t>
<t>While the <xref target='options'/> section indicates that users must be able to opt into or out of DNS-based malware protection services, the reasons for why an ISP or DNS ASP may choose one or the other as the default are out of scope.</t>
<t>Lastly, in the <xref target='malware'/> section of this document, the method by which FQDNs, domains, and/or sites are added or removed from malware lists is outside the scope of this document. [EDITORIAL NOTE: THIS MAY CHANGE IN A FUTURE VERSION OF THE DOCUMENT]</t>
</section>
<section title='Terminology' toc='include'>
<t>While these terms are generally well known, it is important to define them in the context of this document.</t>
<section title='Internet Service Provider (ISP)' toc='exclude'>
<t>An Internet Service Provider, which provides Internet services, including basic network connectivity. It is not germane to this document what the method of connection is, such as wired or wireless, what the speed of such a connection is, or what other services are included or available to users. It is, however, assumed that the ISP is providing recursive DNS services to their users and is in some manner providing users with the IP addresses of these DNS servers, whether via DHCP, static assignment by users, or some other method.</t>
</section>
<section title='DNS Application Service Provider (ASP)' toc='exclude'>
<t>A DNS Application Service Provider, which provides managed and/or hosted recursive DNS services (and possibly other DNS services) to their users. In the case of managed services, the DNS ASP may remotely manage the recursive DNS servers in a user's network. For a hosted recursive DNS service, these servers are typically located outside of the user's network and these hosted resources are shared across multiple users. In most instances, these are hosted services and users are manually configuring either their DHCP server or their individual computing devices with the IP addresses of the recursive DNS servers operated by their ASP.</t>
</section>
<section title='Internet User' toc='exclude'>
<t>An Internet user, which is generally a person using a computing device to connect to and make use of the Internet. Such users are typically connected at the edge of the network, though the method by which they connect to the Internet is not particularly relevant to this document.</t>
</section>
<section title='DNS Recursive Resolver' toc='exclude'>
<t>A DNS recursive resolver processes fully qualified domain name queries (FQDN, Section 5.1 of <xref target="RFC1035"/>) into IP addresses by finding the resource records in the authoritative DNS servers for the domain associated with the FQDN. The resource records are then cached on the recursive server for future requests until an expiration timer expires called time to live (TTL), as described in Section 5.2 of <xref target="RFC2181"/>. These servers are in most cases provided by ISPs for name resolution.</t>
</section>
<section title='Web Browser' toc='exclude'>
<t>Client software operated by the user locally on their computing device, such as Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome, etc.</t>
</section>
<section title='Malicious Domain Web Error Landing Server' toc='exclude'>
<t>The web server that a user's web browser is directed to when the DNS Recursive Server matches a DNS query to a malicious domain or FQDN. The contents of the web page that the web server sends the user varies widely across different ISPs and DNS ASPs. In most cases it simply explains that the attempted URL contains malware and that access has been prevented, though there are many other possibilities.</t>
</section>
<section title='User Options Web Server' toc='exclude'>
<t>The web server that a user is directed to via a link on a page served by the Web Error Landing Server, the Malicious Domain Web Error Landing Server, from another system such as an account management system, or via direct access, which enables a user to control whether or not they are opted into or opted out of DNS-based malware protection services. This is described in additional detail in the <xref target='options'/> section.</t>
</section>
<section title='NXDOMAIN Response' toc='exclude'>
<t>In this document, an NXDOMAIN (nonexistent domain) response can be used interchangeably with an RCODE 3 response. The RCODE 3 response was first documented in see Section 4.1.1 of <xref target="RFC1035"/>). Subsequent RFCs introduced the term NXDOMAIN response, which is synonymous with RCODE 3 and tends to be used more frequently, as noted in Section 2.2 of <xref target="RFC2136"/>, Section 1 of <xref target="RFC2308"/>, and Section 5.4 of <xref target="RFC2535"/>.</t>
</section>
</section>
<section title='Malicious Site Protection' toc='include' anchor='malware'>
<t>Malware websites have proliferated recently, making malware and bot networks a major problem for users. In many cases, the initial contact with a virus or malware occurs when an unsuspecting user visits a particular website. This has even been observed to occur when a user visits an otherwise legitimate website, which contains external references that happen to contain malware, for example (such as advertisements served by a third party). Many organizations maintain lists of domains and FQDNs which host malware.</t>
<section title='Malicious Site Protection Problem Statement' toc='exclude'>
<t>A user, malware agent, or bot requests a URL www.example.net or domain example.net. This site is associated with distributing malware or some other malicious activity that would not be desired by the user. The correct IP address is returned by the DNS and the user accesses the malware site or domain and their computer is infected with a bot.</t>
</section>
<section title='Malicious Site Protection Solution Description' toc='exclude'>
<t>By using Malicious Site Protection, a user may have their DNS response redirected from the IP address for the malicious URL www.example.net or domain example.net to a safe website that explains why the user was redirected. Importantly, the application attempting to access a malicious resource may or may not be a web browser and, further, may be operating without the user's knowledge and/or permission. This page on the aforementioned safe website that the user is directed to may also provide the user with a link to a method of opting out in the future. See <xref target='Malicious Domain Response'/> and <xref target='Malicious Site Redirect and HTTP Flow'/> for examples below. There may also be limited cases where it could be harmful to the objective of Malicious Site Protection to redirect the user to a safe website, in which case the user may not be directed to any resource, and a NXDOMAIN response be provided.</t>
</section>
<section title='Malicious Site Protection Solution Considerations' toc='exclude'>
<t>It is important to note that this technology can directly impact non-web clients such as instant messaging, VPNs, FTP, email filters-related DNS queries. Thus, special exclusions may need to be made in order to prevent unintentional side effects. Design considerations for the Web Error Search and Malicious Site Protection services should include properly and promptly terminating non-HTTP connection requests. A range of resource records may be redirected, such as A, AAAA, MX, SRV, and NAPTR records, in order to fulfill the objective of preventing access to certain network elements containing malicious content or which and in some way used to transmit, relay, or otherwise transfer malicious content. All other resource record types must be answered as if there was no redirection.</t>
<t>Malicious domain protection is also only effective if a user is actually using the DNS IP addresses that have this functionality. Thus, should a user's computer become compromised with some type of bot or virus that changes their DNS IP addresses (typically without their knowledge), the malicious domain protection would have no effect since the user is now pointed to DNS servers which are presumably in the control of a third party with malicious intentions.</t>
</section>
</section>
<section title='Opt-In or Opt-Out Mechanisms' toc='include' anchor='options'>
<t>ISPs and DNS ASPs MUST provide their users with a method to opt into (opt-in) or out (opt-out) of some or all DNS-based malware protection services. Opt-out and opt-in methods should be reliable and should take into consideration the <xref target='Practices to Avoid'/> section below. Whether such services are offered on an opt-in or opt-out basis depends on a range of factors which are outside of the scope of this document. The two different methods, opt-out and opt-in, are described below.</t>
<section title='Opt-Out' toc='exclude'>
<t>Opt-Out is used when the users are by default offered all or some DNS-based malware protection services. As a result, the user must take an action to disable some or all such services. This is typically performed via a User Options Web Server. Users that have chosen to opt-out should receive DNS responses which are indistinguishable from those responses provided by a DNS server with no DNS Redirect functionality. In addition, opt-out should be persistent in nature, which means that opt-out should be tied to a fixed credential or attribute of some type, such as an account identifier, billing identifier, or equipment identifier, which is not typically subject to change on a regular basis.</t>
</section>
<section title='Opt-In' toc='exclude'>
<t>Opt-In is used when the users are by default not offered any DNS-based malware protection services. As a result, the user must take an action to enable some or all such services. This is typically performed via a User Options Web Server.</t>
</section>
<section title='Automated Mechanisms and Reasonable Processing Times' toc='exclude'>
<t>Once a user has selected to opt-in or opt-out of DNS-based malware protection services, such changes should occur automatically, when this is technically possible, without requiring the user to manually change any settings on their computing device. Such changes should also occur within a reasonable period of time. In some cases, however, a user may be offered the ability to speed the period of time for these changes to take effect, such as by restarting the computing device or a piece of network equipment which connects them to their ISP's network, for example.</t>
<t>While an automated mechanism may be the easiest for users, since it requires no manual reconfiguration of their network settings, the authors also recognize that there may be extenuating circumstances where this is not achievable. In such cases, which may for example be due to the particular attributes of one or another ISP's network design, a fully automated mechanism may not be possible. Another example is where a user is switching from their ISP's DNS server IP addresses to those of a DNS ASP. As a result, a user in all of these cases, as well as other possible cases, must manually reconfigure their network with different DNS IP addresses.</t>
</section>
<section title='Type of Opt-Out Method' toc='exclude'>
<t>There are several workable methods that can be employed to effect the actual opt-out for a given user. These include setting a local user application attribute, such as via a cookie in a web browser, as well as setting a network attribute, via a DHCP change or manually configuring the DNS IP addresses (in the operating system, modem, home gateway device, or router) in order to change the DNS IP addresses for a particular user.</t>
<t>While all of these methods are workable and can be made reliable, the best current method is via a network-based change of some sort. In this way, all Internet-connected computing devices within a given household are included in the opt-out (these devices are generally connected in some manner to the LAN side of some type of customer premise device, such as a cable modem or DSL modem). This is in contrast to a method which uses a local user application attribute, such as a cookie in a web browser, where deletion of cookies, upgrade to a new operating system, upgrade to a new web browser, use of a different web browser, or countless other factors on that device could cause the user to be opted back into a DNS-based malware protection service. Thus, a network-based approach which sets opt-out-related attributes at the device, or household level, is the most inclusive and persistent method for providing a reliable opt-out method, and is the recommended practice.</t>
</section>
</section>
<section title='Practices to Avoid' toc='include' anchor='Practices to Avoid'>
<t>This document primarily focuses on the recommended practices for an ISP or ASP to provide users with DNS-based malware protection services. However, it is important to note that some entities may not operate in accordance with such practices. As such, some of these are catalogued below in order to contrast them with recommended practices and provide information which may be of interest and use to the community.</t>
<section title='Use of DNS Redirect with DNSSEC' toc='exclude'>
<t>When DNSSEC has been implemented in a service provider's resolvers, DNS redirect MUST NOT be used, as it is technically incompatible with DNSSEC and breaks the chain of trust critical to proper DNSSEC validation functionality.</t>
</section>
<section title='Improper Redirect of Valid Responses' toc='exclude'>
<t>It has been observed that some service providers improperly utilize DNS-based malware protection services when there is a valid DNS resource record returned in response to a DNS recursive query. The effect is to redirect users to a server not maintained by the intended destination, such as a web site that looks like the intended web site but is not actually the intended site and is instead controlled by the service provider. For example a DNS query for www.example.com results in a valid A record response, but this valid response is instead replaced with an A record controlled by the service provider. In this case the intended server identified with the valid A record contained valid, lawful, non-malicious content, and there would otherwise appear to be no valid justification for a redirect to occur. See <xref target='Improper Redirect of Valid Response Redirect and HTTP Flow'/> for an example below.</t>
<t>If there is a valid and reasonable justification for such a redirect to occur, examples of which are not currently known by the authors of this document, then the resulting connection to the server that the user has been redirected to should clearly and prominently disclose that this is not the intended site. For example, in the case of an attempt by a user to connect to a web site, the site may contain a banner or frame which indicates that this is not the intended site or that the site is in some manner controlled by the service provider. In addition, such a notice should also offer a clear method to opt-out of this redirect function.</t>
<t>Thus, to summarize, redirection of valid responses SHOULD NOT be performed.</t>
</section>
<section title='Redirect of SERVFAIL Responses' toc='exclude'>
<t>Redirection of SERVFAIL responses SHOULD NOT occur. SERVFAIL responses may occur intermittently in an operational network for a variety of highly transient reasons. As a result, a DNS Redirect should not be performed when a SERVFAIL response is received, as normal retry a short time later is likely to result in a valid response.</t>
</section>
<section title='Routinely Broken, Purposefully Broken, and Otherwise Unreliable Opt-Out Mechanisms' toc='exclude'>
<t>There are several well known and dependable methods of opt-out mechanisms that ISPs and DNS ASPs can deploy for users to opt-out of their DNS-based malware protection services. These methods can rather easily be employed and are highly recommended, as noted in <xref target='options'/>. However, some ISPs and DNS ASPs may instead choose to employ a less dependable mechanism, which routinely fails to work as expected by users or is known not to function properly.</t>
<t>For example, one routinely unreliable method for opt-out is the cookie-based method. When a user opts out of a DNS-based malware protection service, a cookie is installed in their web browser. The problem with this method occurs when a user clears their cookies or the cookies are deleted for some reason. In some cases, users may configure their web browsers to clear all cookies every time the close their web browser. Thus, one possible effect upon the user in this case is that they are once again opted into the redirect service. Furthermore, a cookie-based method has the effect of only opting out browser-based protocols (generally HTTP and HTTPS), which means that the user may have non-web applications affected by DNS Redirect, even though they believe they have opted-out. As a result, there is no assured permanency with this opt-out method, nor does it work consistently across all applications and protocols, which can be aggravating to users who do not wish to utilize DNS-based malware protection services.</t>
<t>Another example of an unreliable method for opt-out is one where opt-out is tied to the IP address of the user, where that address may be subject to change on a regular basis, such as via an ISP-based DHCP lease. In such a case, if opt-out was tied to what can be considered a largely dynamic IP address, then the user would be opted-in every time they received a new IP address, forcing them to repeatedly opt-out.</t>
<t>Thus, to summarize, the opt-out mechanism provided to users SHOULD be reliable and SHOULD NOT be routinely broken, purposefully broken, or otherwise unreliable.</t>
</section>
<section title='Markedly Slower DNS Query Performance' toc='exclude'>
<t>An ISP or DNS ASP should also understand that DNS query latency, the time between when a user's stub resolver issues and DNS query and receives a DNS response, should be kept as low as is reasonably possible. High DNS query latency is often perceived by users, and can have an adverse effect on a variety of applications where low DNS query latency may be especially important. Any additional processing which must be performed in order to provide DNS-based malware protection services should be monitored closely, in order that DNS Redirect functionality does not markedly slow DNS query performance.</t>
<t>Thus, to summarize, when DNS redirect is performed, DNS query performance SHOULD NOT suffer as a result, since this could provide an incrementally inferior user experience as compared to when DNS redirect is not performed.</t>
</section>
<section title='Override of a User's DNS Selection' toc='exclude'>
<t>Some users may decide to use the DNS server IP addresses of a DNS ASP or other non-ISP-provided DNS servers. Such selections should be preserved as the free choice of a user, particularly when DNS-based malware protection services are offered. Thus, an ISP SHOULD NOT redirect port 53 DNS traffic from servers intended by the user via their selection of non-ISP DNS servers to the DNS servers of the ISP, except in reasonable and justifiable cases where a user has been placed into a so-called "walled garden" for reasons of abuse, security compromise, account non-payment, new service activation, etc.</t>
</section>
</section>
<section title='Functional Design' toc='include'>
<t>The functional design described in this section is intended to be generally representative of the many different ways that DNS-based malware protection services are deployed today. As such, they are necessarily high level and different implementations may vary somewhat, due to any number of factors.</t>
<section title='DNS Recursive Resolver'>
<t>The DNS Recursive Resolver is used by the host computer to translate fully qualified domain names into IP addresses, according to Section 3.6.1 of <xref target="RFC1034"/>. When a FQDN does not exist in authoritative DNS a NXDOMAIN response, as described in Section 4.1.1 of <xref target="RFC1035"/> is normally returned (see <xref target='DNS Redirect Response'/>). In the case of DNS Redirect, the NXDOMAIN response is changed to reply with a resource record (RR) response which instructs the host computer to send the original request to a new IP address (see <xref target='DNS Redirect Response'/>).</t>
<figure anchor='DNS Redirect Response' title='DNS Redirect Response'>
<artwork><![CDATA[
Request Request
www.example.invalid www.example.invalid
+--------+ +--------+
++--++ ------------> | | ------------> | |
|| || | | | |
+-++--++-+ | | | |
+--------+ <------------ | | <------------ | |
Host NXDOMAIN +--------+ NXDOMAIN +--------+
Computer Response Recursive Response Authoritative
Server Server
]]></artwork></figure>
</section>
<section title='Web Error Landing Server'>
<t>When a user requests an invalid URL or Domain, their web client is redirected to a Web Error Landing Server which presents several possible helpful website views (see <xref target='Web Error Landing Server'/>). The first is "Did you mean..." response which presents the user with possible correct results based on their original invalid request. The search server can also present search engine results to the user.</t>
<figure anchor='Web Error Landing Server' title='Web Error Landing Server'>
<artwork><![CDATA[
Request Request
www.example.invalid www.example.invalid
+--------+ +--------+
++--++ ---------------> | | --------------->| |
|| || | | | |
+-++--++-+ | | | |
+--------+ <-------------- | | <------------- | |
Host Redirect +--------+ NXDOMAIN +--------+
Computer IP Address Recursive Response Authoritative
Server Server
|
| ___________________________________
| +--------+ | Web Response: |
| | | | "Did you mean...www.example.com"|
+------> | | ------> |__________________________________|
| | | Search result: #1 |
| | | Search result: #2 |
+--------+ |__________________________________|
Web Server
Landing Page
]]></artwork></figure>
</section>
<section title='Web Browser Client'>
<t>The Web Browser Client is redirected to a Web Server Landing Page instead of presenting an error page when there is no valid DNS record present.</t>
<t>Examples of common Web Browser Clients include:
<list style='symbols'>
<t>Microsoft Internet Explorer</t>
<t>Mozilla Firefox</t>
<t>Apple Safari</t>
<t>Google Chrome</t>
<t>Opera</t>
</list>
</t>
</section>
<section title='Domain White List'>
<t>There may be certain domains which should be not be redirected under any circumstances for legal, business, or other reasons. The Domain White List can contain both domains, such as *.example.com, as well as specific FQDNs, such as www.example.com. For instance, the owner of example.com may request that the ISP or DNS ASP not perform DNS Redirect for the example.com domain, so that there is no DNS Redirect resulting from queries to nonexistent names, such as invalid.example.com.</t>
</section>
<section title='Malicious Domain List'>
<t>Using a Malicious Domain List, a DNS server can redirect DNS requests that were intended for malicious websites or domains to a web server landing page (see <xref target='Malicious Domain Response'/>). The Malicious Domain List can contain both domains, such as *.example.net, as well as specific FQDNs, such as www.example.net.</t>
<figure anchor='Malicious Domain Response' title='Malicious Domain Response'>
<artwork><![CDATA[
Request Request
www.example.net www.example.net
+--------+ +--------+
++--++ ---------------> | | --------------->| |
|| || | | | |
+-++--++-+ | | | |
+--------+ <-------------- | | <------------- | |
Host Redirect +--------+ Response +--------+
Computer IP Address Recursive IP Address Authoritative
Server Server
|
| ___________________________________
| +--------+ | Web Response: |
| | | | "Malware software alert!" |
+-------> | | ------> |__________________________________|
| | | The site you attempted to access |
| | | is known to host malware that |
+--------+ | could damage your computer. |
Web Server |__________________________________|
Landing Page
]]></artwork></figure>
</section>
<section title='Legally-Mandated DNS Redirect Domain List'>
<t>Using a Malicious Domain List, a DNS server can redirect DNS requests that were intended for malicious websites or domains to a web server landing page (see <xref target='Malicious Domain Response'/>). The Legally-Mandated DNS Redirect Domain List can contain both domains, such as *.illegalcontent.example, as well as specific FQDNs, such as www.illegalcontent.example.net.</t>
<figure anchor='Legally-Mandated DNS Redirect Domain Response' title='Legally-Mandated DNS Redirect Domain Response'>
<artwork><![CDATA[
Request Request
www.illegalcontent.example.net www.illegalcontent.example.net
+--------+ +--------+
++--++ ---------------> | | --------------->| |
|| || | | | |
+-++--++-+ | | | |
+--------+ <-------------- | | <------------- | |
Host Redirect +--------+ Response +--------+
Computer IP Address Recursive IP Address Authoritative
Server Server
|
| ___________________________________
| +--------+ | Web Response: |
| | | | "Illegal content alert!" |
+-------> | | ------> |__________________________________|
| | | The site you attempted to access |
| | | has been designated as hosting |
+--------+ | illegal content under XYZ law of |
Web Server | 2009, which your ISP is legally |
Landing Page | compelled to block or be fined. |
|__________________________________|
]]></artwork></figure>
</section>
<section title='Content-Based DNS Redirect Domain List'>
<t>Using a Content Protection List, a DNS server can redirect DNS requests that were intended for websites or domains containing content deemed inappropriate by a user, to a web server landing page (see <xref target='Content-Based Redirect Domain Response'/>). The Legally-Mandated DNS Redirect Domain List can contain both domains, such as *.inappropriate.example, as well as specific FQDNs, such as www.inappropriate.example.com.</t>
<figure anchor='Content-Based Redirect Domain Response' title='Content-Based Redirect Domain Response'>
<artwork><![CDATA[
Request Request
www.inappropriate.example.com www.inappropriate.example.com
+--------+ +--------+
++--++ ---------------> | | --------------->| |
|| || | | | |
+-++--++-+ | | | |
+--------+ <-------------- | | <------------- | |
Host Redirect +--------+ Response +--------+
Computer IP Address Recursive IP Address Authoritative
Server Server
|
| ___________________________________
| +--------+ | Web Response: |
| | | | "Inappropriate content alert!" |
+------> | | ------> |__________________________________|
| | | The site you attempted to access |
| | | has been blocked by you or |
+--------+ | your network administrator. |
Web Server |__________________________________|
Landing Page
]]></artwork></figure>
</section>
</section>
<section title='Example DNS and HTTP Flows' toc='include'>
<section title='Successful DNS Lookup and HTTP Flow' toc='exclude'>
<t>This example represents a successful lookup of a valid DNS RR, and the resulting HTTP transaction.</t>
<figure anchor='Successful DNS Lookup and HTTP Flow' title='Successful DNS Lookup and HTTP Flow'>
<artwork><![CDATA[
Web DNS R DNS A DNS Web Server
Browser Client Server Server 10.1.10.10
| Request | A | | |
|www.example. |Record Query | A | |
| com |www.example. |Record Query | |
|------------>| com |www.example. | |
| |------------>| com | |
| | |------------>| |
| | | A Record | |
| | A Record | 10.1.10.10 | |
| DNS Response| 10.1.10.10 |<------------| |
| 10.1.10.10 |<------------| | |
|<------------| | | |
| HTTP GET | | | |
| 10.1.10.10 | | | |
|------------------------------------------------------>|
| | | | |
| | | | |
| | | | |
]]></artwork></figure>
</section>
<section title='Unsuccessful DNS Lookup and HTTP Flow' toc='exclude'>
<t>This example represents a lookup of a nonexistent DNS RR, and the resulting HTTP transaction.</t>
<figure anchor='Unsuccessful DNS Lookup and HTTP Flow' title='Unsuccessful DNS Lookup and HTTP Flow'>
<artwork><![CDATA[
Web DNS R DNS A DNS
Browser Client Server Server
| Request | A | |
|www.example. |Record Query | A |
| invalid |www.example. |Record Query |
|------------>| invalid |www.example. |
| |------------>| invalid |
| | |------------>|
| | | NXDOMAIN |
| | NXDOMAIN |<------------|
| NXDOMAIN |<------------| |
|<------------| | |
| | | |
]]></artwork></figure>
</section>
<section title='DNS Redirect and HTTP Flow' toc='exclude'>
<t>This example represents a lookup of a non-existing DNS RR, and the HTTP transition that results from a typical DNS-based malware protection service.</t>
<figure anchor='DNS Redirect and HTTP Flow' title='DNS Redirect and HTTP Flow'>
<artwork><![CDATA[
Redirect
Host R DNS A DNS Web Server Web Server
Computer Server Server 10.2.20.20 10.1.10.10
| A | | | |
|Record Query | A | | |
|www.example. |Record Query | | |
| invalid |www.example. | | |
|------------>| invalid | | |
| |------------>| | |
| A Record | NXDOMAIN | | |
| 10.2.20.20 |<------------| | |
|<------------| | | |
| HTTP GET | | | |
| 10.2.20.20 | | | |
|---------------------------------------->| |
| | | HTTP 200 OK | |
|<----------------------------------------| |
| A | | | |
|Record Query | A | | |
|www.example. |Record Query | | |
| com |www.example. | | |
|------------>| com | | |
| |------------>| | |
| | A Record | | |
| A Record | 10.1.10.10 | | |
| 10.1.10.10 |<------------| | |
|<------------| | | |
| HTTP GET | | | |
| 10.1.10.10 | | | |
|------------------------------------------------------>|
| | | | HTTP 200 OK |
|<------------------------------------------------------|
| | | | |
]]></artwork></figure>
</section>
<section title='Malicious Site Redirect and HTTP Flow' toc='exclude'>
<t>This example represents a lookup of a valid RR which hosts malware, and the HTTP transaction that results from a typical Malicious Site Protection service.</t>
<figure anchor='Malicious Site Redirect and HTTP Flow' title='Malicious Site Redirect and HTTP Flow'>
<artwork><![CDATA[
R DNS Mal Redirect
Host R DNS Server Web Server
Computer Server Mal List 10.2.20.20
| A | | |
|Record Query | Mal List | |
|www.example. | Query | |
| net |www.example. | |
|------------>| net | |
| |------------>| |
| | Postivie | |
| A Record | Match | |
| 10.2.20.20 |<------------| |
|<------------| | |
| HTTP GET | | |
| 10.2.20.20 | | |
|---------------------------------------->|
| | | HTTP 200 OK |
|<----------------------------------------|
| | | |
]]></artwork></figure>
</section>
<section title='Legally-Mandated Redirect and HTTP Flow' toc='exclude'>
<t>This example represents a lookup of a valid RR which hosts illegal content, and the HTTP transaction that results from a typical Legally-Mandated DNS Redirect function.</t>
<figure anchor='Legally-Mandated Redirect and HTTP Flow' title='Legally-Mandated Redirect and HTTP Flow'>
<artwork><![CDATA[
R DNS Illegal Content
Server Redirect
Host R DNS Illegal Web Server
Computer Server Content List 10.2.20.20
| A | | |
|Record Query | Illegal | |
| www. | Content List | |
|illegalcontent.| | |
|example.net | Query | |
| | www. | |
| |illegalcontent.| |
| |example.net | |
|-------------->| | |
| |-------------->| |
| | Postivie | |
| A Record | Match | |
| 10.2.20.20 |<--------------| |
|<--------------| | |
| HTTP GET | | |
| 10.2.20.20 | | |
|---------------------------------------------->|
| | | HTTP 200 OK |
|<----------------------------------------------|
| | | |
]]></artwork></figure>
</section>
<section title='Content-Based Redirect and HTTP Flow' toc='exclude'>
<t>This example represents a lookup of a valid RR which hosts content which has been deemed inappropriate by a user, and the HTTP transaction that results from a typical Content-Based Redirect function.</t>
<figure anchor='Content-Based Redirect and HTTP Flow' title='Content-Based Redirect and HTTP Flow'>
<artwork><![CDATA[
R DNS Inappropriate
Server Content Redirect
Host R DNS Inappropriate Web Server
Computer Server Content List 10.2.20.20
| A | | |
|Record Query | Illegal | |
| www. | Content List | |
|inappropriate. | | |
|example.com | Query | |
| | www. | |
| |inappropriate. | |
| |example.com | |
|-------------->| | |
| |-------------->| |
| | Postivie | |
| A Record | Match | |
| 10.2.20.20 |<--------------| |
|<--------------| | |
| HTTP GET | | |
| 10.2.20.20 | | |
|---------------------------------------------->|
| | | HTTP 200 OK |
|<----------------------------------------------|
| | | |
]]></artwork></figure>
</section>
<section title='Improper Redirect of Valid Response Redirect and HTTP Flow' anchor='Improper Redirect Section' toc='exclude'>
<t>This example represents an improper redirect occurring when a valid DNS RR should have been returned in response to a DNS recursive query for an example website, the resulting HTTP transaction, and that no DNS query or HTTP traffic was sent to the valid authoritative DNS server and valid web server. <xref target='DNSSEC Considerations Section'/> below shows one of the reasons why this practice is problematic. Another reason is that a user intends to visit a valid resource with lawful and legitimate content, such as a web site, and is instead sent to a different destination (which may even closely resemble the intended site, in the pattern used by phishing sites).</t>
<figure anchor='Improper Redirect of Valid Response Redirect and HTTP Flow' title='Improper Redirect of Valid Response Redirect and HTTP Flow'>
<artwork><![CDATA[
R DNS Improper Valid
Server Redirect Valid Web
Host R DNS Improper Web Server A DNS Server
Computer Server Reirect List 10.2.20.20 Server 10.1.10.10
| A | Improper | | | |
|Record Query |Redirect List| | | |
|www.example. | Query | | | |
| com |www.example. | | | |
|------------>| com | | | |
| |------------>| | | |
| | Postivie | | | |
| A Record | Match | | | |
| 10.2.20.20 |<------------| | | |
|<------------| | | | |
| HTTP GET | | | | |
| 10.2.20.20 | | | | |
|-------------------------------------->| | |
| | |HTTP 200 OK| | |
|<--------------------------------------| | |
| | | | | |
]]></artwork></figure>
</section>
</section>
<section title='DNSSEC Considerations' anchor='DNSSEC Considerations Section' toc='include'>
<t>DNS security extensions defined in <xref target='RFC4033'/>, <xref target='RFC4034'/>, and <xref target='RFC4035'/> use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Name Server that can be used by Security-Aware Resolvers to verify the answers. As the DNS redirections described herein take place on the recursive server there is no need to look into the communication between the recursive resolvers and name servers. Depending on the security awareness of recursive server used to perform DNS-based malware protection services, as well as the security awareness of the stub resolvers the following impact is observed on DNS Redirect when giving out answers to fully secured zones or parent zones:</t>
<t><list style='symbols'>
<t>Security-Oblivious Resolver with Validating and Non-Validating Stub Resolvers: Since the resolver is not security-aware, it will not pass any DNSSEC-related packets and, thus, even the validating stub resolver cannot validate the records and will present the DNS Redirect answers to the application.</t>
<t>Security-Aware Resolver with Non-Validating Stub Resolver: As the security-aware resolver does not have the key generated the resource record signatures (RRSIG) for it's response it should give the redirected answer out as indeterminate or insecure. As the stub resolver is not doing any validation it will use the DNS Redirect response and pass them on to the application.</t>
<t>Security-Aware Resolver with Validating Stub Resolver: As the security-aware resolver does not have the key generated the resource record signatures (RRSIG) for it's response it should give the redirected answer out as indeterminate or insecure. However, as the validating stub has a DNSKEY record for the zone or a DS record for the parent zone it cannot validate the answer and will report it as bogus to the application leading to non-resolution for that domain.</t>
</list></t>
<t>So the only case where DNS security extensions cause problems for DNS Redirect is with a validating stub resolver. This case doesn't have widespread deployment now and could be mitigated by using trust anchor, configured by the applicable ISP or DNS ASP, that could be used to sign the redirected answers. As noted above in <xref target='Improper Redirect Section'/>, such improper redirection of valid responses may also cause DNSSEC trust verification problems.</t>
</section>
<section title='Security Considerations' toc='include'>
<t>Security best practices should be followed regarding access to the opt-in and opt-out functions, in order that someone other than the user is able to change the user's DNS Redirect settings. For example, the User Options Web Server must not permit someone to modify a page URI to access and change another user's options. Thus, if the URI is "http://www.example.net/redirect-options.php?account=1234", someone must not be able to modify the account to be "=1235" and then be able to change the options for a different user with some other additional validation being performed. While web site security practices are outside the scope of this document, the authors believe it is important to identify such problematic use cases to any ISPs and DNS ASPs offering and/or implementing DNS Redirect functionality.</t>
</section>
<section title='IANA Considerations' toc='include'>
<t>There are no IANA considerations in this document.</t>
</section>
<section title='Contributors' toc='include'>
<t>The following people made significant textual contributions to this document and played an important role in the development and evolution of this document:</t>
<t>Don Bowman, Sandvine (don@sandvine.com)</t>
<t>Rick Hiester, Verizon (richard.hiester@verizon.com)</t>
<t>Chris Roosenraad, Time Warner Cable (chris.roosenraad@twcable.com)</t>
<t>David Ulevitch, OpenDNS (david@opendns.com)</t>
</section>
<section title='Acknowledgements' toc='include'>
<t>The authors and contributors also wish to acknowledge the assistance of the following individuals in helping us to develop and/or review this document: </t>
<t>John Barnitz, Comcast Cable Communications (john_barnitz@cable.comcast.com)</t>
<t>Mike Burns, Cablevision (mburns@cablevision.com)</t>
<t>Phil Marcella, Comcast Interactive Media (phillip_marcella@cable.comcast.com)</t>
<t>Luis Uribarri, Comcast Cable Communications (luis_uribarri@cable.comcast.com)</t>
<t>Sandy Wilbourn, Nominum (sandy.wilbourn@nominum.com)</t>
<t>Matt Williams, Cox Cable (matt.williams@cox.com)</t>
<t>The authors and contributors also wish to thank ICANN's Security and Stability Advisory Committee (SSAC) for their review and debate of this document, as well as for raising important questions concerning DNSSEC compatibility.</t>
</section>
<!-- appendix -->
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title='Normative References'>
&RFC2119;
&RFC1034;
&RFC1035;
&RFC1536;
&RFC1591;
&RFC2131;
&RFC2136;
&RFC2181;
&RFC2308;
&RFC2535;
&RFC4033;
&RFC4034;
&RFC4035;
</references>
<section title='Document Change Log'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>-00: First version published</t>
</section>
<section title='Open Issues'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>
<list style='numbers'>
<t>CRITICAL: THIS DOCUMENT HAS BEEN SPLIT OFF FROM A GENERAL DNS REDIRECT DOCUMENT. THIS FIRST VERSION IS A SIMPLE REPURPOSING OF THE CONTENT FROM THE OLD DOCUMENT. EXISTING AUTHORS NOW NEED TO PERFORM A FULL DOCUMENT REVIEW TO ENSURE THAT THE NEW CONTENT HAS CARRIED OVER CORRECTLY AND THAT IT MAKES SENSE AND THAT THEY STILL SUPPORT THE DOCUMENT AND CAN CONTRIBUTE TO IT.</t>
<t>REMOVE ALL LEGACY CONTENT REFERRING TO OTHER FORMS OF REDIRECTION THAT CARRIED OVER FROM THE OLD DOCUMENT</t>
<t>RW: Consider whether it is a good idea to add to section 4.9 (NXDOMAIN RESPONSE) a reference to Authenticated Denial of Existence described in RFC4035 section 5.4 as these should be also redirected.</t>
<t>MB: Consider addressing how opt-out works when a user roams across a shared WiFi AP.</t>
<t>RH: Update reference to RFC2535, which is obsoleted by RFCs 4033, 4034, 4035.</t>
<t>JL: Consider capitalizing RFC 2119 language used.</t>
<t>JL: What sort of DNSSEC section is needed?</t>
</list>
</t>
</section>
</back>
<!-- END BACK SECTION -->
</rfc>
<!-- FOR REFERENCE -->
<!-- less than is < -->
<!-- ampersand is & -->
<!-- apostrophe is &apos -->
<!-- quotation is " -->
| PAFTECH AB 2003-2026 | 2026-04-24 13:57:02 |