idnits 2.17.1 draft-sullivan-dnsop-refer-down-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2017) is 2334 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP A. Sullivan 3 Internet-Draft Oracle 4 Intended status: Best Current Practice J. Abley 5 Expires: June 1, 2018 Snake Hill Labs 6 November 28, 2017 8 Please See Below: Use Only Downward Referrals in the DNS 9 draft-sullivan-dnsop-refer-down-00 11 Abstract 13 A server in the Domain Name System can use a mechanism called 14 "referral" to indicate that the server is not authoritative for a 15 given zone, and to redirect the query to another, more appropriate 16 server. The mechanism was originally specified such that a referral 17 might be to any location in the DNS. Operational experience 18 indicates dubious value to referrals other than those to zones below 19 the zones for which a server is authoritative. This memo therefore 20 recommends such referrals and discourages other kinds of referrals. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 1, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Downward Referrals . . . . . . . . . . . . . . . . . . . 3 60 2.2. Upward Referrals . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Negative Consequences of Upward Referrals . . . . . . . . 5 62 2.4. Alternatives to Upward Referrals . . . . . . . . . . . . 6 63 2.4.1. NODATA . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.4.2. SERVFAIL . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4.3. NXDOMAIN . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.5. Recommendations . . . . . . . . . . . . . . . . . . . . . 7 68 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 5.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 8 74 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The Domain Name System (DNS) divides parts of the domain name space 80 "into units called 'zones'" ([RFC1034], Section 2.4). The answers 81 for data in these zones are (ultimately) provided by authoritative 82 servers. In the Internet context, for any given query, there is a 83 set of authoritative servers that can provide an authoritative answer 84 in response to that query. 86 Sometimes, however, a server receives a query for which it is not 87 authoritative. If such a server does not offer recursion, the server 88 might return a response that refers to another set of servers on the 89 Internet. This response is called a "referral". 91 There are two categories of referral response. One of them indicates 92 a delegation in the DNS, and is a basic part of how the DNS 93 functions. Without such delegation responses, the distributed nature 94 of the DNS is impossible. They may be thought of as "downward" 95 referrals because they refer to a zone somewhere beneath the zone for 96 which the server is authoritative. Other referrals are for zones 97 where the server is neither authoritative for the zone of the QNAME, 98 nor for any zone that might be an ancestor of the zone containing the 99 QNAME. These referrals might be thought of as "off-tree" referrals, 100 because the server is not authoritative for any part of the tree 101 containing the QNAME. 103 Historically, authoritative servers that received an off-tree query 104 would reply with an "upward referral", usually to the root zone; 105 these were sometimes called a "root referral". Such referrals have 106 turned out to be undesirable in practice. This memo recommends that 107 servers not provide upward referrals, and instead should respond to 108 such queries in some other way. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 Unfamiliar DNS-related terms are likely to be found in RFC 7719 119 [RFC7719], and the reader is assumed to be familiar with that 120 vocabulary. 122 2. Referrals 124 Referrals are defined as part of the algorithm for a name server 125 ([RFC1034], section 4.3.2, henceforth "the algorithm"). Referrals 126 only happen when the RD bit is clear in the query or the server does 127 not offer recursion (or both). There are different possible 128 interpretations of the algorithm; one's interpretation will affect 129 which kinds of referral one thinks acceptable. 131 A referral contains an empty answer section. It contains the NS 132 RRset for the referred-to zone in the authority section. It may 133 contain RRs that provide addresses in the additional section. The AA 134 bit is clear. 136 2.1. Downward Referrals 138 The first kind of referral is downward, and is uncontroversial. Step 139 2 of the matching algorithm evaluates whether the name server is 140 authoritative for some zone that is an ancestor for the QNAME. (If 141 the QNAME exactly matches, then that zone is the "ancestor". This is 142 a slightly awkward usage of "ancestor", but makes sense due to the 143 distinction between a zone and the matching owner name inside the 144 zone.) If there is such a zone, then the algorithm moves to step 3; 145 otherwise, it moves to step 4. 147 In step 3, the server matches label by label in the zone until 148 matching terminates. Step 3(b) of the matching algorithm says, "If a 149 match would take us out of the authoritative data, we have a 150 referral. This happens when we encounter a node with NS RRs marking 151 cuts along the bottom of a zone." Such a referral is called 152 "downward" because the referral is of necessity to a part of the 153 namespace beneath the zone for which the server is generating a 154 response. In other words, if the server is authoritative for the 155 zone example.com, the referral needs to be to the NS records of some 156 subordinate zone in the domain name space. 158 Downward referrals are necessary for the DNS to function. They are 159 the mechanism by which delegation happens. 161 2.2. Upward Referrals 163 The second kind of referral is often called an "upward" referral, 164 because it is often a referral to the name servers for the root zone 165 (perforce above everything else in the domain name space), though in 166 principle the referral could be elsewhere in the domain name space. 167 Step 4 of the algorithm says, "If there was no delegation from 168 authoritative data, look for the best one from the cache, and put it 169 in the authority section." Returning this kind of referral under 170 normal operational conditions is somewhat more controversial than a 171 downward referral, because it is not clear that it is necessary for 172 the operation of the DNS. 174 There are only two cases where upward referrals are possible: 176 1. The server offers recursive service, and it cannot provide an 177 authoritative answer or a downward referral, but the query was 178 received with the RD bit clear. 180 2. The server does not offer recursive service, and it cannot 181 provide either an answer or a downward referral in response to 182 the query. 184 The first of these is plainly required by step 4 of the algorithm, 185 and should therefore be uncontroversial. In normal operation, 186 however, this case appears to be unusual. A resolver that was using 187 such a server for full-service DNS resolution would normally query 188 with the RD bit set. A resolver that did not expect recursion would 189 likely only send a QNAME for which the server could provide an 190 authoritative answer or a downward referral; it is unclear why the 191 query would be sent to the server at all otherwise. Such queries are 192 known to occur sometimes, for example when troubleshooting, but they 193 do not appear to be normal according to the protocol. 195 The second case is controversial because the server, which only 196 provides authoritative answers, must somehow have some data in a 197 cache in order to return anything in the authority section. The 198 controversy arises because of the question of whether the server 199 ought to have such data. This amounts to a question of whether a 200 server that only provides authoritative answers should ever have a 201 cache. 203 On the one hand, it would seem that such a server should not have a 204 cache, because it does not have a resolver side that populates such a 205 cache. Moreover, the SBELT structure (see [RFC1034], section 5.3.2) 206 is defined only for resolvers and not for servers. So a server that 207 only provides authoritative answers has no reason even to have 208 configured in the SBELT structure a list of servers from which to 209 start (in resolvers, this is often the "root hints" file). On the 210 other hand, there is no requirement that a given name server should 211 not provide both authoritative service and recursive service. 212 Moreover, even a server that provides no recursive service to others 213 may need to perform resolution for its own purposes, and therefore 214 might have need of the SBELT structure. So, depending on one's 215 reading of the algorithm, either upward referrals should not be 216 returned from such a server and are a sign of misconfiguration, or 217 else they will be a normal part of operation. 219 Upward referrals, and particularly root referrals, were once regarded 220 as a useful mechanism to indicate lame delegation [RFC1912]. That 221 use turned out to create some difficulties (see Section 2.3, below). 223 2.3. Negative Consequences of Upward Referrals 225 Upward referrals have some negative consequences. The most obvious 226 of them is that they are not in-domain records, and therefore they 227 should not be accepted in any case according to RFC 5452 [RFC5452], 228 section 6. This means that an upward referral response is just extra 229 traffic, because the querying resolver will need to find those 230 records from an authoritative source anyway. Moreover, upward 231 referral response messages can be considerably larger than the query 232 message that causes them, making them a useful amplifier when used in 233 reflector attacks [RFC5358]. 235 Upward referrals can be part of a referral loop, and the algorithm 236 does not specify how or when to terminate such a loop. The use of 237 upward referrals to indicate lame delegations exhibits this weakness. 239 2.4. Alternatives to Upward Referrals 241 It is possible for a server to send some other response than an 242 upward referral, when an upward referral might have been generated 243 under the algorithm. There are several alternatives, each of which 244 has advantages and disadvantages. 246 2.4.1. NODATA 248 A name server that had no information at all in a cache (including 249 the SBELT structure) would complete step 4 of the algorithm having 250 added nothing to the authority section in the response. It would 251 exit step 6 of the algorithm having created an empty response (except 252 for the query that was copied from the original query message). This 253 is a type 3 NODATA response [RFC2308]. A disadvantage of returning 254 such a message is that it is unlikely to cause the query source to 255 stop querying the nameserver for that name, because type 3 NODATA 256 responses are not cached (see [RFC2308], section 5). 258 2.4.2. SERVFAIL 260 RCODE 2, Server Failure, indicates that a server cannot process the 261 query due to a problem with the name server. Some operators adopt 262 the position that the name server would normally provide an upward 263 referral, except that it has been configured not to. Therefore, the 264 server can return RCODE 2. Others argue, however, that there is 265 nothing wrong with the server; and that, moreover, the use of RCODE 2 266 in DNSSEC (see [RFC4035]) means that this RCODE is already overloaded 267 enough. Some interpretations of RCODE 2 by resolvers invites 268 subsequent retries to the same server, which may not always be 269 desirable. 271 2.4.3. NXDOMAIN 273 RCODE 3, Name Error or NXDOMAIN, indicates that the domain name does 274 not exist. Some operators use RCODE 3 instead of producing upward 275 referrals. But since RCODE 3 is supposed to be "[m]eaningful only 276 for responses from an authoritative name server" ([RFC1035] section 277 4.1.1) and since by definition the upward referral can only happen in 278 a case where the name server is not authoritative, this use appears 279 to be inconsistent with the protocol. 281 2.4.4. REFUSED 283 RCODE 5, Refused, indicates that the server "refuses to perform the 284 specified operatio for policy reasons." ([RFC1035], section 4.1.1) 285 Some operators adopt a policy of refusing to perform upward 286 referrals, and so return RCODE 5 to queries that would otherwise 287 cause such referrals. There are some resolvers, however, that 288 interpret RCODE 5 to mean that the resolver itself, rather than the 289 query sent, is what causes the Refused response. Those resolvers 290 will not attempt to query the server again (or not for some period of 291 time), running the risk of outages in domains for which the server is 292 authoritative and would provide a response. 294 2.5. Recommendations 296 A name server that only provides authoritative service SHOULD NOT 297 return upward referrals under any circumstances. Such a name server 298 SHOULD provide either RCODE 2 or RCODE 5 in response. A name server 299 MUST NOT return RCODE 3 except for names for which it can provide 300 authoritative answer that the name does not exist. 302 A name server that provides recursive service MAY provide upward 303 referrals when replying to a query with the RD bit clear, or it MAY 304 refuse to provide upward referrals just as though it provided only 305 authoritative service. Operators should note that upward referrals 306 might provide a modest troubleshooting advantage for recursive 307 servers, but this should be weighed against the advantages of 308 removing upward referrals as one of the available tools of attackers 309 on Internet infrastructure. 311 3. Acknowledgements 313 This memo has benefitted from the comments of Stephane Bortzmeyer, 314 Robert Edmonds, Tony Finch, Evan Hunt, John Kristoff, Dave Lawrence, 315 Edward Lewis, Matthew Pounsett, and Paul Vixie. 317 4. IANA Considerations 319 This memo makes no requests of IANA. 321 [[CREF1: Note in draft: this section can be removed by the RFC Editor 322 if the document is ever published as an RFC.]] 324 5. References 326 5.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 335 May 2017, . 337 5.2. Informative References 339 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 340 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 341 . 343 [RFC1035] Mockapetris, P., "Domain names - implementation and 344 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 345 November 1987, . 347 [RFC1912] Barr, D., "Common DNS Operational and Configuration 348 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, 349 . 351 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 352 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 353 . 355 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 356 Rose, "Protocol Modifications for the DNS Security 357 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 358 . 360 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 361 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 362 DOI 10.17487/RFC5358, October 2008, 363 . 365 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 366 Resilient against Forged Answers", RFC 5452, 367 DOI 10.17487/RFC5452, January 2009, 368 . 370 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 371 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 372 2015, . 374 Appendix A. Discussion Venue 376 This Internet-Draft is discussed on the DNS Operations Working Group 377 list: dnsop@ietf.org. 379 Appendix B. Change History 381 Note to RFC Editor: this section should be removed prior to 382 publication as an RFC. 384 00: 386 * Initial version 388 Authors' Addresses 390 Andrew Sullivan 391 Oracle 393 Email: andrew.s.sullivan@oracle.com 395 Joe Abley 396 Snake Hill Labs 397 300-184 York Street 398 London, ON N6A 1B5 399 Canada 401 Email: jabley@shl.io