idnits 2.17.1 draft-ietf-dnsop-bad-dns-res-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6644 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations M. Larson 3 Internet-Draft P. Barber 4 Expires: August 5, 2006 VeriSign 5 February 2006 7 Observed DNS Resolution Misbehavior 8 draft-ietf-dnsop-bad-dns-res-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 5, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This memo describes DNS iterative resolver behavior that results in a 42 significant query volume sent to the root and top-level domain (TLD) 43 name servers. We offer implementation advice to iterative resolver 44 developers to alleviate these unnecessary queries. The 45 recommendations made in this document are a direct byproduct of 46 observation and analysis of abnormal query traffic patterns seen at 47 two of the thirteen root name servers and all thirteen com/net TLD 48 name servers. 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [1]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. A note about terminology in this memo . . . . . . . . . . 3 58 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5 59 2.1. Aggressive requerying for delegation information . . . . . 5 60 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7 62 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7 63 2.3. Inability to follow multiple levels of indirection . . . . 8 64 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9 65 2.4. Aggressive retransmission when fetching glue . . . . . . . 9 66 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10 67 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10 68 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11 69 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11 70 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12 71 2.7. Name server records with zero TTL . . . . . . . . . . . . 12 72 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13 73 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13 74 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 75 2.9. Queries for domain names resembling IPv4 addresses . . . . 14 76 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 77 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 78 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 79 2.11. Suboptimal name server selection algorithm . . . . . . . . 15 80 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 81 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 82 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 83 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 84 6. Internationalization considerations . . . . . . . . . . . . . 20 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 89 Intellectual Property and Copyright Statements . . . . . . . . . . 23 91 1. Introduction 93 Observation of query traffic received by two root name servers and 94 the thirteen com/net TLD name servers has revealed that a large 95 proportion of the total traffic often consists of "requeries". A 96 requery is the same question () asked 97 repeatedly at an unexpectedly high rate. We have observed requeries 98 from both a single IP address and multiple IP addresses (i.e., the 99 same query received simultaneously from multiple IP addresses). 101 By analyzing requery events we have found that the cause of the 102 duplicate traffic is almost always a deficient iterative resolver, 103 stub resolver or application implementation combined with an 104 operational anomaly. The implementation deficiencies we have 105 identified to date include well-intentioned recovery attempts gone 106 awry, insufficient caching of failures, early abort when multiple 107 levels of indirection must be followed, and aggressive retry by stub 108 resolvers or applications. Anomalies that we have seen trigger 109 requery events include lame delegations, unusual glue records, and 110 anything that makes all authoritative name servers for a zone 111 unreachable (DoS attacks, crashes, maintenance, routing failures, 112 congestion, etc.). 114 In the following sections, we provide a detailed explanation of the 115 observed behavior and recommend changes that will reduce the requery 116 rate. None of the changes recommended affects the core DNS protocol 117 specification; instead, this document consists of guidelines to 118 implementors of iterative resolvers. 120 1.1. A note about terminology in this memo 122 To recast an old saying about standards, the nice thing about DNS 123 terms is that there are so many of them to choose from. Writing or 124 talking about DNS can be difficult and cause confusion resulting from 125 a lack of agreed-upon terms for its various components. Further 126 complicating matters are implementations that combine multiple roles 127 into one piece of software, which makes naming the result 128 problematic. An example is the entity that accepts recursive 129 queries, issues iterative queries as necessary to resolve the initial 130 recursive query, caches responses it receives, and which is also able 131 to answer questions about certain zones authoritatively. This entity 132 is an iterative resolver combined with an authoritative name server 133 and is often called a "recursive name server" or a "caching name 134 server". 136 This memo is concerned principally with the behavior of iterative 137 resolvers, which are typically found as part of a recursive name 138 server. This memo uses the more precise term "iterative resolver", 139 because the focus is usually on that component. In instances where 140 the name server role of this entity requires mentioning, this memo 141 uses the term "recursive name server". As an example of the 142 difference, the name server component of a recursive name server 143 receives DNS queries and the iterative resolver component sends 144 queries. 146 The advent of IPv6 requires mentioning AAAA records as well as A 147 records when discussing glue. To avoid continuous repetition and 148 qualification, this memo uses the general term "address record" to 149 encompass both A and AAAA records when a particular situation is 150 relevant to both types. 152 2. Observed iterative resolver misbehavior 154 2.1. Aggressive requerying for delegation information 156 There can be times when every name server in a zone's NS RRset is 157 unreachable (e.g., during a network outage), unavailable (e.g., the 158 name server process is not running on the server host) or 159 misconfigured (e.g., the name server is not authoritative for the 160 given zone, also known as "lame"). Consider an iterative resolver 161 that attempts to resolve a query for a domain name in such a zone and 162 discovers that none of the zone's name servers can provide an answer. 163 We have observed a recursive name server implementation whose 164 iterative resolver then verifies the zone's NS RRset in its cache by 165 querying for the zone's delegation information: it sends a query for 166 the zone's NS RRset to one of the parent zone's name servers. (Note 167 that queries with QTYPE=NS are not required by the standard 168 resolution algorithm described in section 4.3.2 of RFC 1034 [2]. 169 These NS queries represent this implementation's addition to that 170 algorithm.) 172 For example, suppose that "example.com" has the following NS RRset: 174 example.com. IN NS ns1.example.com. 175 example.com. IN NS ns2.example.com. 177 Upon receipt of a query for "www.example.com" and assuming that 178 neither "ns1.example.com" nor "ns2.example.com" can provide an 179 answer, this iterative resolver implementation immediately queries a 180 "com" zone name server for the "example.com" NS RRset to verify it 181 has the proper delegation information. This implementation performs 182 this query to a zone's parent zone for each recursive query it 183 receives that fails because of a completely unresponsive set of name 184 servers for the target zone. Consider the effect when a popular zone 185 experiences a catastrophic failure of all its name servers: now every 186 recursive query for domain names in that zone sent to this recursive 187 name server implementation results in a query to the failed zone's 188 parent name servers. On one occasion when several dozen popular 189 zones became unreachable, the query load on the com/net name servers 190 increased by 50%. 192 We believe this verification query is not reasonable. Consider the 193 circumstances: When an iterative resolver is resolving a query for a 194 domain name in a zone it has not previously searched, it uses the 195 list of name servers in the referral from the target zone's parent. 196 If on its first attempt to search the target zone, none of the name 197 servers in the referral is reachable, a verification query to the 198 parent would be pointless: this query to the parent would come so 199 quickly on the heels of the referral that it would be almost certain 200 to contain the same list of name servers. The chance of discovering 201 any new information is slim. 203 The other possibility is that the iterative resolver successfully 204 contacts one of the target zone's name servers and then caches the NS 205 RRset from the authority section of a response, the proper behavior 206 according to section 5.4.1 of RFC 2181 [3], because the NS RRset from 207 the target zone is more trustworthy than delegation information from 208 the parent zone. If, while processing a subsequent recursive query, 209 the iterative resolver discovers that none of the name servers 210 specified in the cached NS RRset is available or authoritative, 211 querying the parent would be wrong. An NS RRset from the parent zone 212 would now be less trustworthy than data already in the cache. 214 For this query of the parent zone to be useful, the target zone's 215 entire set of name servers would have to change AND the former set of 216 name servers would have to be deconfigured or decommissioned AND the 217 delegation information in the parent zone would have to be updated 218 with the new set of name servers, all within the TTL of the target 219 zone's NS RRset. We believe this scenario is uncommon: 220 administrative best practices dictate that changes to a zone's set of 221 name servers happen gradually when at all possible, with servers 222 removed from the NS RRset left authoritative for the zone as long as 223 possible. The scenarios that we can envision that would benefit from 224 the parent requery behavior do not outweigh its damaging effects. 226 This section should not be understood to claim that all queries to a 227 zone's parent are bad. In some cases, such queries are not only 228 reasonable but required. Consider the situation when required 229 information, such as the address of a name server (i.e., the address 230 record corresponding to the RDATA of an NS record), has timed out of 231 an iterative resolver's cache before the corresponding NS record. If 232 the name of the name server is below the apex of the zone, then the 233 name server's address record is only available as glue in the parent 234 zone. For example, consider this NS record: 236 example.com. IN NS ns.example.com. 238 If a cache has this NS record but not the address record for 239 "ns.example.com", it is unable to contact the "example.com" zone 240 directly and must query the "com" zone to obtain the address record. 241 Note, however, that such a query would not have QTYPE=NS according to 242 the standard resolution algorithm. 244 2.1.1. Recommendation 246 An iterative resolver MUST NOT send a query for the NS RRset of a 247 non-responsive zone to any of the name servers for that zone's parent 248 zone. For the purposes of this injunction, a non-responsive zone is 249 defined as a zone for which every name server listed in the zone's NS 250 RRset: 252 1. is not authoritative for the zone (i.e., lame), or, 254 2. returns a server failure response (RCODE=2), or, 256 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. 258 2.2. Repeated queries to lame servers 260 Section 2.1 describes a catastrophic failure: when every name server 261 for a zone is unable to provide an answer for one reason or another. 262 A more common occurrence is when a subset of a zone's name servers 263 are unavailable or misconfigured. Different failure modes have 264 different expected durations. Some symptoms indicate problems that 265 are potentially transient; for example, various types of ICMP 266 unreachable messages because a name server process is not running or 267 a host or network is unreachable, or a complete lack of a response to 268 a query. Such responses could be the result of a host rebooting or 269 temporary outages; these events don't necessarily require any human 270 intervention and can be reasonably expected to be temporary. 272 Other symptoms clearly indicate a condition requiring human 273 intervention, such as lame server: if a name server is misconfigured 274 and not authoritative for a zone delegated to it, it is reasonable to 275 assume that this condition has potential to last longer than 276 unreachability or unresponsiveness. Consequently, repeated queries 277 to known lame servers are not useful. In this case of a condition 278 with potential to persist for a long time, a better practice would be 279 to maintain a list of known lame servers and avoid querying them 280 repeatedly in a short interval. 282 It should also be noted, however, that some authoritative name server 283 implementations appear to be lame only for queries of certain types 284 as described in RFC 4074 [5]. In this case, it makes sense to retry 285 the "lame" servers for other types of queries, particularly when all 286 known authoritative name servers appear to be "lame". 288 2.2.1. Recommendation 290 Iterative resolvers SHOULD cache name servers that they discover are 291 not authoritative for zones delegated to them (i.e. lame servers). 292 If this caching is performed, lame servers MUST be cached against the 293 specific query tuple . Zone 294 name can be derived from the owner name of the NS record that was 295 referenced to query the name server that was discovered to be lame. 297 Implementations that perform lame server caching MUST refrain from 298 sending queries to known lame servers for a configurable time 299 interval after the server is discovered to be lame. A minimum 300 interval of thirty minutes is RECOMMENDED. 302 An exception to this recommendation occurs if all name servers for a 303 zone are marked lame. In that case, the iterative resolver SHOULD 304 temporarily ignore the servers' lameness status and query one or more 305 servers. This behavior is a workaround for the type-specific 306 lameness issue described in the previous section. 308 Implementors should take care not to make lame server avoidance logic 309 overly broad: note that a name server could be lame for a parent zone 310 but not a child zone, e.g., lame for "example.com" but properly 311 authoritative for "sub.example.com". Therefore a name server should 312 not be automatically considered lame for subzones. In the case 313 above, even if a name server is known to be lame for "example.com", 314 it should be queried for QNAMEs at or below "sub.example.com" if an 315 NS record indicates it should be authoritative for that zone. 317 2.3. Inability to follow multiple levels of indirection 319 Some iterative resolver implementations are unable to follow 320 sufficient levels of indirection. For example, consider the 321 following delegations: 323 foo.example. IN NS ns1.example.com. 324 foo.example. IN NS ns2.example.com. 326 example.com. IN NS ns1.test.example.net. 327 example.com. IN NS ns2.test.example.net. 329 test.example.net. IN NS ns1.test.example.net. 330 test.example.net. IN NS ns2.test.example.net. 332 An iterative resolver resolving the name "www.foo.example" must 333 follow two levels of indirection, first obtaining address records for 334 "ns1.test.example.net" or "ns2.test.example.net" in order to obtain 335 address records for "ns1.example.com" or "ns2.example.com" in order 336 to query those name servers for the address records of 337 "www.foo.example". While this situation may appear contrived, we 338 have seen multiple similar occurrences and expect more as new generic 339 top-level domains (gTLDs) become active. We anticipate many zones in 340 new gTLDs will use name servers in existing gTLDs, increasing the 341 number of delegations using out-of-zone name servers. 343 2.3.1. Recommendation 345 Clearly constructing a delegation that relies on multiple levels of 346 indirection is not a good administrative practice. However, the 347 practice is widespread enough to require that iterative resolvers be 348 able to cope with it. Iterative resolvers SHOULD be able to handle 349 arbitrary levels of indirection resulting from out-of-zone name 350 servers. Iterative resolvers SHOULD implement a level-of-effort 351 counter to avoid loops or otherwise performing too much work in 352 resolving pathological cases. 354 A best practice that avoids this entire issue of indirection is to 355 name one or more of a zone's name servers in the zone itself. For 356 example, if the zone is named "example.com", consider naming some of 357 the name servers "ns{1,2,...}.example.com" (or similar). 359 2.4. Aggressive retransmission when fetching glue 361 When an authoritative name server responds with a referral, it 362 includes NS records in the authority section of the response. 363 According to the algorithm in section 4.3.2 of RFC 1034 [2], the name 364 server should also "put whatever addresses are available into the 365 additional section, using glue RRs if the addresses are not available 366 from authoritative data or the cache." Some name server 367 implementations take this address inclusion a step further with a 368 feature called "glue fetching". A name server that implements glue 369 fetching attempts to include address records for every NS record in 370 the authority section. If necessary, the name server issues multiple 371 queries of its own to obtain any missing address records. 373 Problems with glue fetching can arise in the context of 374 "authoritative-only" name servers, which only serve authoritative 375 data and ignore requests for recursion. Such an entity will not 376 normally generate any queries of its own. Instead it answers non- 377 recursive queries from iterative resolvers looking for information in 378 zones it serves. With glue fetching enabled, however, an 379 authoritative server invokes an iterative resolver to look up an 380 unknown address record to complete the additional section of a 381 response. 383 We have observed situations where the iterative resolver of a glue- 384 fetching name server can send queries that reach other name servers, 385 but is apparently prevented from receiving the responses. For 386 example, perhaps the name server is authoritative-only and therefore 387 its administrators expect it to receive only queries and not 388 responses. Perhaps unaware of glue fetching and presuming that the 389 name server's iterative resolver will generate no queries, its 390 administrators place the name server behind a network device that 391 prevents it from receiving responses. If this is the case, all glue- 392 fetching queries will go unanswered. 394 We have observed name server implementations whose iterative 395 resolvers retry excessively when glue-fetching queries are 396 unanswered. A single com/net name server has received hundreds of 397 queries per second from a single such source. Judging from the 398 specific queries received and based on additional analysis, we 399 believe these queries result from overly aggressive glue fetching. 401 2.4.1. Recommendation 403 Implementers whose name servers support glue fetching SHOULD take 404 care to avoid sending queries at excessive rates. Implementations 405 SHOULD support throttling logic to detect when queries are sent but 406 no responses are received. 408 2.5. Aggressive retransmission behind firewalls 410 A common occurrence and one of the largest sources of repeated 411 queries at the com/net and root name servers appears to result from 412 resolvers behind misconfigured firewalls. In this situation, an 413 iterative resolver is apparently allowed to send queries through a 414 firewall to other name servers, but not receive the responses. The 415 result is more queries than necessary because of retransmission, all 416 of which are useless because the responses are never received. Just 417 as with the glue-fetching scenario described in Section 2.4, the 418 queries are sometimes sent at excessive rates. To make matters 419 worse, sometimes the responses, sent in reply to legitimate queries, 420 trigger an alarm on the originator's intrusion detection system. We 421 are frequently contacted by administrators responding to such alarms 422 who believe our name servers are attacking their systems. 424 Not only do some resolvers in this situation retransmit queries at an 425 excessive rate, but they continue to do so for days or even weeks. 426 This scenario could result from an organization with multiple 427 recursive name servers, only a subset of whose iterative resolvers' 428 traffic is improperly filtered in this manner. Stub resolvers in the 429 organization could be configured to query multiple recursive name 430 servers. Consider the case where a stub resolver queries a filtered 431 recursive name server first. The iterative resolver of this 432 recursive name server sends one or more queries whose replies are 433 filtered, so it can't respond to the stub resolver, which times out. 434 Then the stub resolver retransmits to a recursive name server that is 435 able to provide an answer. Since resolution ultimately succeeds the 436 underlying problem might not be recognized or corrected. A popular 437 stub resolver implementation has a very aggressive retransmission 438 schedule, including simultaneous queries to multiple recursive name 439 servers, which could explain how such a situation could persist 440 without being detected. 442 2.5.1. Recommendation 444 The most obvious recommendation is that administrators SHOULD take 445 care not to place iterative resolvers behind a firewall that allows 446 queries to pass through but not the resulting replies. 448 Iterative resolvers SHOULD take care to avoid sending queries at 449 excessive rates. Implementations SHOULD support throttling logic to 450 detect when queries are sent but no responses are received. 452 2.6. Misconfigured NS records 454 Sometimes a zone administrator forgets to add the trailing dot on the 455 domain names in the RDATA of a zone's NS records. Consider this 456 fragment of the zone file for "example.com": 458 $ORIGIN example.com. 459 example.com. 3600 IN NS ns1.example.com ; Note missing 460 example.com. 3600 IN NS ns2.example.com ; trailing dots 462 The zone's authoritative servers will parse the NS RDATA as 463 "ns1.example.com.example.com" and "ns2.example.com.example.com" and 464 return NS records with this incorrect RDATA in responses, including 465 typically the authority section of every response containing records 466 from the "example.com" zone. 468 Now consider a typical sequence of queries. An iterative resolver 469 attempting to resolve address records for "www.example.com" with no 470 cached information for this zone will query a "com" authoritative 471 server. The "com" server responds with a referral to the 472 "example.com" zone, consisting of NS records with valid RDATA and 473 associated glue records. (This example assumes that the 474 "example.com" zone delegation information is correct in the "com" 475 zone.) The iterative resolver caches the NS RRset from the "com" 476 server and follows the referral by querying one of the "example.com" 477 authoritative servers. This server responds with the 478 "www.example.com" address record in the answer section and, 479 typically, the "example.com" NS records in the authority section and, 480 if space in the message remains, glue address records in the 481 additional section. According to Section 5.4 of RFC 2181 [3], NS 482 records in the authority section of an authoritative answer are more 483 trustworthy than NS records from the authority section of a non- 484 authoritative answer. Thus the "example.com" NS RRset just received 485 from the "example.com" authoritative server overrides the 486 "example.com" NS RRset received moments ago from the "com" 487 authoritative server. 489 But the "example.com" zone contains the erroneous NS RRset as shown 490 in the example above. Subsequent queries for names in "example.com" 491 will cause the iterative resolver to attempt to use the incorrect NS 492 records and so it will try to resolve the nonexistent names 493 "ns1.example.com.example.com" and "ns2.example.com.example.com". In 494 this example, since all of the zone's name servers are named in the 495 zone itself (i.e., "ns1.example.com.example.com" and 496 "ns2.example.com.example.com" both end in "example.com") and all are 497 bogus, the iterative resolver cannot reach any "example.com" name 498 servers. Therefore attempts to resolve these names result in address 499 record queries to the "com" authoritative servers. Queries for such 500 obviously bogus glue address records occur frequently at the com/net 501 name servers. 503 2.6.1. Recommendation 505 An authoritative server can detect this situation. A trailing dot 506 missing from an NS record's RDATA always results by definition in a 507 name server name that exists somewhere under the apex of the zone the 508 NS record appears in. Note that further levels of delegation are 509 possible, so a missing trailing dot could inadvertently create a name 510 server name that actually exists in a subzone. 512 An authoritative name server SHOULD issue a warning when one of a 513 zone's NS records references a name server below the zone's apex when 514 a corresponding address record does not exist in the zone AND there 515 are no delegated subzones where the address record could exist. 517 2.7. Name server records with zero TTL 519 Sometimes a popular com/net subdomain's zone is configured with a TTL 520 of zero on the zone's NS records, which prohibits these records from 521 being cached and will result in a higher query volume to the zone's 522 authoritative servers. The zone's administrator should understand 523 the consequences of such a configuration and provision resources 524 accordingly. A zero TTL on the zone's NS RRset, however, carries 525 additional consequences beyond the zone itself: if an iterative 526 resolver cannot cache a zone's NS records because of a zero TTL, it 527 will be forced to query that zone's parent's name servers each time 528 it resolves a name in the zone. The com/net authoritative servers do 529 see an increased query load when a popular com/net subdomain's zone 530 is configured with a TTL of zero on the zone's NS records. 532 A zero TTL on an RRset expected to change frequently is extreme but 533 permissible. A zone's NS RRset is a special case, however, because 534 changes to it must be coordinated with the zone's parent. In most 535 zone parent/child relationships we are aware of, there is typically 536 some delay involved in effecting changes. Further, changes to the 537 set of a zone's authoritative name servers (and therefore to the 538 zone's NS RRset) are typically relatively rare: providing reliable 539 authoritative service requires a reasonably stable set of servers. 540 Therefore an extremely low or zero TTL on a zone's NS RRset rarely 541 makes sense, except in anticipation of an upcoming change. In this 542 case, when the zone's administrator has planned a change and does not 543 want iterative resolvers throughout the Internet to cache the NS 544 RRset for a long period of time, a low TTL is reasonable. 546 2.7.1. Recommendation 548 Because of the additional load placed on a zone's parent's 549 authoritative servers resulting from a zero TTL on a zone's NS RRset, 550 under such circumstances authoritative name servers SHOULD issue a 551 warning when loading a zone. 553 2.8. Unnecessary dynamic update messages 555 The UPDATE message specified in RFC 2136 [6] allows an authorized 556 agent to update a zone's data on an authoritative name server using a 557 DNS message sent over the network. Consider the case of an agent 558 desiring to add a particular resource record. Because of zone cuts, 559 the agent does not necessarily know the proper zone to which the 560 record should be added. The dynamic update process requires that the 561 agent determine the appropriate zone so the UPDATE message can be 562 sent to one of the zone's authoritative servers (typically the 563 primary master as specified in the zone's SOA MNAME field). 565 The appropriate zone to update is the closest enclosing zone, which 566 cannot be determined only by inspecting the domain name of the record 567 to be updated, since zone cuts can occur anywhere. One way to 568 determine the closest enclosing zone entails walking up the name 569 space tree by sending repeated UPDATE messages until success. For 570 example, consider an agent attempting to add an address record with 571 the name "foo.bar.example.com". The agent could first attempt to 572 update the "foo.bar.example.com" zone. If the attempt failed, the 573 update could be directed to the "bar.example.com" zone, then the 574 "example.com" zone, then the "com" zone, and finally the root zone. 576 A popular dynamic agent follows this algorithm. The result is many 577 UPDATE messages received by the root name servers, the com/net 578 authoritative servers, and presumably other TLD authoritative 579 servers. A valid question is why the algorithm proceeds to send 580 updates all the way to TLD and root name servers. This behavior is 581 not entirely unreasonable: in enterprise DNS architectures with an 582 "internal root" design, there could conceivably be private, non- 583 public TLD or root zones that would be the appropriate targets for a 584 dynamic update. 586 A significant deficiency with this algorithm is that knowledge of a 587 given UPDATE message's failure is not helpful in directing future 588 UPDATE messages to the appropriate servers. A better algorithm would 589 be to find the closest enclosing zone by walking up the name space 590 with queries for SOA or NS rather than "probing" with UPDATE 591 messages. Once the appropriate zone is found, an UPDATE message can 592 be sent. In addition, the results of these queries can be cached to 593 aid in determining closest enclosing zones for future updates. Once 594 the closest enclosing zone is determined with this method, the update 595 will either succeed or fail and there is no need to send further 596 updates to higher-level zones. The important point is that walking 597 up the tree with queries yields cacheable information, whereas 598 walking up the tree by sending UPDATE messages does not. 600 2.8.1. Recommendation 602 Dynamic update agents SHOULD send SOA or NS queries to progressively 603 higher-level names to find the closest enclosing zone for a given 604 name to update. Only after the appropriate zone is found should the 605 client send an UPDATE message to one of the zone's authoritative 606 servers. Update clients SHOULD NOT "probe" using UPDATE messages by 607 walking up the tree to progressively higher-level zones. 609 2.9. Queries for domain names resembling IPv4 addresses 611 The root name servers receive a significant number of A record 612 queries where the QNAME looks like an IPv4 address. The source of 613 these queries is unknown. It could be attributed to situations where 614 a user believes an application will accept either a domain name or an 615 IP address in a given configuration option. The user enters an IP 616 address, but the application assumes any input is a domain name and 617 attempts to resolve it, resulting in an A record lookup. There could 618 also be applications that produce such queries in a misguided attempt 619 to reverse map IP addresses. 621 These queries result in Name Error (RCODE=3) responses. An iterative 622 resolver can negatively cache such responses, but each response 623 requires a separate cache entry, i.e., a negative cache entry for the 624 domain name "192.0.2.1" does not prevent a subsequent query for the 625 domain name "192.0.2.2". 627 2.9.1. Recommendation 629 It would be desirable for the root name servers not to have to answer 630 these queries: they unnecessarily consume CPU resources and network 631 bandwidth. A possible solution is to delegate these numeric TLDs 632 from the root zone to a separate set of servers to absorb the 633 traffic. The "black hole servers" used by the AS 112 Project 634 (http://www.as112.net), which are currently delegated the in- 635 addr.arpa zones corresponding to RFC 1918 [7] private use address 636 space, would be a possible choice to receive these delegations. Of 637 course, the proper and usual root zone change procedures would have 638 to be followed to make such a change to the root zone. 640 2.10. Misdirected recursive queries 642 The root name servers receive a significant number of recursive 643 queries (i.e., queries with the RD bit set in the header). Since 644 none of the root servers offers recursion, the servers' response in 645 such a situation ignores the request for recursion and the response 646 probably does not contain the data the querier anticipated. Some of 647 these queries result from users configuring stub resolvers to query a 648 root server. (This situation is not hypothetical: we have received 649 complaints from users when this configuration does not work as 650 hoped.) Of course, users should not direct stub resolvers to use 651 name servers that do not offer recursion, but we are not aware of any 652 stub resolver implementation that offers any feedback to the user 653 when so configured, aside from simply "not working". 655 2.10.1. Recommendation 657 When the IP address of a name server that supposedly offers recursion 658 is configured in a stub resolver using an interactive user interface, 659 the resolver could send a test query to verify that the server indeed 660 supports recursion (i.e., verify that the response has the RA bit set 661 in the header). The user could be immediately notified if the server 662 is non-recursive. 664 The stub resolver could also report an error, either through a user 665 interface or in a log file, if the queried server does not support 666 recursion. Error reporting SHOULD be throttled to avoid a 667 notification or log message for every response from a non-recursive 668 server. 670 2.11. Suboptimal name server selection algorithm 672 An entire document could be devoted to the topic of problems with 673 different implementations of the recursive resolution algorithm. The 674 entire process of recursion is woefully under specified, requiring 675 each implementor to design an algorithm. Sometimes implementors make 676 poor design choices that could be avoided if a suggested algorithm 677 and best practices were documented, but that is a topic for another 678 document. 680 Some deficiencies cause significant operational impact and are 681 therefore worth mentioning here. One of these is name server 682 selection by an iterative resolver. When an iterative resolver wants 683 to contact one of a zone's authoritative name servers, how does it 684 choose from the NS records listed in the zone's NS RRset? If the 685 selection mechanism is suboptimal, queries are not spread evenly 686 among a zone's authoritative servers. The details of the selection 687 mechanism are up to the implementor, but we offer some suggestions. 689 2.11.1. Recommendation 691 This list is not conclusive, but reflects the changes that would 692 produce the most impact in terms of reducing disproportionate query 693 load among a zone's authoritative servers. I.e., these changes would 694 help spread the query load evenly. 696 o Do not make assumptions based on NS RRset order: all NS RRs SHOULD 697 be treated equally. (In the case of the "com" zone, for example, 698 most of the root servers return the NS record for "a.gtld- 699 servers.net" first in the authority section of referrals. 700 Apparently as a result, this server receives disproportionately 701 more traffic than the other 12 authoritative servers for "com".) 703 o Use all NS records in an RRset. (For example, we are aware of 704 implementations that hard-coded information for a subset of the 705 root servers.) 707 o Maintain state and favor the best-performing of a zone's 708 authoritative servers. A good definition of performance is 709 response time. Non-responsive servers can be penalized with an 710 extremely high response time. 712 o Do not lock onto the best-performing of a zone's name servers. An 713 iterative resolver SHOULD periodically check the performance of 714 all of a zone's name servers to adjust its determination of the 715 best-performing one. 717 3. Acknowledgments 719 The authors would like to thank the following people for their 720 comments that improved this document: Andras Salamon, Dave Meyer, 721 Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, 722 Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We 723 apologize if we have omitted anyone; any oversight was unintentional. 725 4. IANA considerations 727 There are no new IANA considerations introduced by this memo. 729 5. Security considerations 731 The iterative resolver misbehavior discussed in this document exposes 732 the root and TLD name servers to increased risk of both intentional 733 and unintentional denial of service attacks. 735 We believe that implementation of the recommendations offered in this 736 document will reduce the amount of unnecessary traffic seen at root 737 and TLD name servers, thus reducing the opportunity for an attacker 738 to use such queries to his or her advantage. 740 6. Internationalization considerations 742 There are no new internationalization considerations introduced by 743 this memo. 745 7. References 747 7.1. Normative References 749 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 750 Levels", BCP 14, RFC 2119, March 1997. 752 [2] Mockapetris, P., "Domain names - concepts and facilities", 753 STD 13, RFC 1034, November 1987. 755 7.2. Informative References 757 [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 758 RFC 2181, July 1997. 760 [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 761 RFC 2308, March 1998. 763 [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS 764 Queries for IPv6 Addresses", RFC 4074, May 2005. 766 [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 767 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 768 April 1997. 770 [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 771 Lear, "Address Allocation for Private Internets", BCP 5, 772 RFC 1918, February 1996. 774 Authors' Addresses 776 Matt Larson 777 VeriSign, Inc. 778 21345 Ridgetop Circle 779 Dulles, VA 20166-6503 780 USA 782 Email: mlarson@verisign.com 784 Piet Barber 785 VeriSign, Inc. 786 21345 Ridgetop Circle 787 Dulles, VA 20166-6503 788 USA 790 Email: pbarber@verisign.com 792 Intellectual Property Statement 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Disclaimer of Validity 818 This document and the information contained herein are provided on an 819 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 820 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 821 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 822 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 823 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 824 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Copyright Statement 828 Copyright (C) The Internet Society (2006). This document is subject 829 to the rights, licenses and restrictions contained in BCP 78, and 830 except as set forth therein, the authors retain all their rights. 832 Acknowledgment 834 Funding for the RFC Editor function is currently provided by the 835 Internet Society.