idnits 2.17.1 draft-grover-add-policy-detection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Grover 3 Internet-Draft P. Saint-Andre 4 Intended status: Standards Track Mozilla 5 Expires: January 9, 2020 July 8, 2019 7 DNS Resolver-Based Policy Detection Domain 8 draft-grover-add-policy-detection-00 10 Abstract 12 This document specifies the behavior that is expected from the Domain 13 Name System with regard to DNS queries for the special-use domain 14 name 'TBD.arpa' and designates this domain as a special-use domain 15 name. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 9, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Design Goals and Constraints . . . . . . . . . . . . . . . . 3 54 4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Domain Name Reservation Considerations . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 8.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Content-control software can be used to filter (i.e., block) web 67 requests that the user, the user's guardian, or the network operator 68 deems objectionable or outside the usage policy of the network. 69 Blocked resource categories can include advertisements, explicit 70 content, known malware, and government-unapproved material, along 71 with many others. 73 One way to implement content control that does not rely on software 74 or settings on the end-user's computing device is DNS-based content 75 filtering, which examines a client's initial DNS request for the 76 domain providing a resource and then either returns no result or 77 returns an alternate result so that the user is presented with an 78 explanation that filtering has taken place. 80 DNS-based policy such as content filtering is often built into a 81 network's configured DNS recursive resolver. In addition to blocking 82 a request, the resolver may also log the request for use by the 83 network administrators. 85 A network operator might wish to provide, or might be obligated to 86 provide, a filtering policy to users of its network. Because such a 87 policy is often enforced by the network operator's default resolver, 88 the use of a technology such as DNS over HTTPS (DoH) [RFC8484] or DNS 89 over TLS (DoT) [RFC7858] can result in bypassing local policies. If 90 the user agent can check for the presence of a policy, this could be 91 used as a signal that the network operator wishes its resolver to be 92 used as a condition of using the network, and that DoH or DoT should 93 be disabled. 95 At present, there is no standardized mechanism for the user or user 96 agent to identify the presence of a policy on a network's default 97 resolver without making a request that could trigger the policy and 98 logging thereof, which could have undesirable side-effects. 100 Therefore, this document defines such a mechanism by defining a so- 101 called "canary domain" that is an instance of Special-Use Domain 102 Names [RFC6761]. DNS requests for this domain would return different 103 results when a DNS-based policy is in place, allowing for the 104 detection of the policy in a consistent way by user agents. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Design Goals and Constraints 116 This canary domain has been defined with the following design goals 117 and constraints in mind: 119 o Minimize the risk of exposing personal information 121 o Ensure that the canary request cannot be mistaken for a user- 122 initiated DNS request 124 o Ensure that the technique is not specific to any given user agent, 125 policy, or resolver service 127 o Ensure that the technique is easy to implement for user agents and 128 resolvers 130 4. Behavior 132 Resolvers implementing a policy modify the result for the reserved 133 domain 'TBD.arpa', which can be observed by clients to determine if a 134 policy is present. 136 If a policy exists, the resolver MUST return NXDOMAIN [RFC1035]. If 137 policy is not present, DNS lookup will be successful (i.e., not 138 NXDOMAIN). (This could perhaps resolve to an actual host with a web 139 page managed by IANA, similar to example.com [RFC6761].) 141 5. Domain Name Reservation Considerations 143 This section specifies considerations for systems involved in domain 144 name resolution when resolving queries for the reserved domain 145 'TBD.arpa', in accordance with [RFC6761]. 147 1. Users: Users may invoke command-line DNS lookup tools to resolve 148 the domain, for the purposes of determining if a DNS-based policy 149 is present. 151 2. Application Software: Application software doing automated 152 lookups are the primary targets of this domain name reservation. 153 Applications can attempt to resolve this name in order to 154 determine if a DNS-based policy is present. 156 3. Name Resolution APIs and Libraries: Caching servers MUST NOT 157 treat this name as special, unless they implement a policy, in 158 which case they MUST return NXDOMAIN. 160 4. Caching DNS Servers: Caching servers MUST NOT treat this name as 161 special, unless they implement a policy, in which case they MUST 162 return NXDOMAIN. 164 5. Authoritative DNS Servers: Authoritative servers other than those 165 supporting the '.arpa' TLD MUST respond to queries for this name 166 with NXDOMAIN. 168 6. DNS Server Operators: Operators SHOULD ensure that any caching 169 DNS server with a policy on their network properly responds to 170 this name with NXDOMAIN. 172 7. DNS Registries/Registrars: The defined name is a subdomain of the 173 '.arpa' top-level domain, which is operated by IANA under the 174 authority of the Internet Architecture Board according to the 175 rules established in [RFC3172]. There are no other registrars 176 for '.arpa'. 178 6. IANA Considerations 180 IANA is requested to record the domain name 'TBD.arpa' in the 181 "Special-Use Domain Names" registry. See Section 5 for the completed 182 registration template. 184 [[NOTE TO RFC EDITOR: please change `TBD` to the name assigned by 185 IANA. The name 'dns-content-policy-detection' is suggested.]] 187 7. Security Considerations 189 Although a DNS resolution request for the 'TBD.arpa' domain can 190 reveal whether the user or application wishes to detect the presence 191 of DNS-based policy, such a request is relatively neutral compared to 192 a request for a domain that might be subject to a policy. 194 8. References 196 8.1. Normative References 198 [RFC1035] Mockapetris, P., "Domain names - implementation and 199 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 200 November 1987, . 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, 204 DOI 10.17487/RFC2119, March 1997, 205 . 207 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 208 Requirements for the Address and Routing Parameter Area 209 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 210 September 2001, . 212 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 213 RFC 6761, DOI 10.17487/RFC6761, February 2013, 214 . 216 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 217 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 218 May 2017, . 220 8.2. Informative References 222 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 223 and P. Hoffman, "Specification for DNS over Transport 224 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 225 2016, . 227 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 228 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 229 . 231 Appendix A. Acknowledgements 233 Thanks to Martin Thomson for his feedback. 235 Authors' Addresses 237 Andy Grover 238 Mozilla 240 Email: agrover@mozilla.com 241 URI: https://mozilla.com/ 243 Peter Saint-Andre 244 Mozilla 246 Phone: +1 720 256 6756 247 Email: stpeter@mozilla.com 248 URI: https://mozilla.com/