idnits 2.17.1 draft-ietf-dnsind-ncache-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 183 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC1034], [RFC2181]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC1034, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1997) is 9656 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) == Missing Reference: 'RFC1035' is mentioned on line 88, but not defined == Missing Reference: 'RFC2065' is mentioned on line 754, but not defined ** Obsolete undefined reference: RFC 2065 (Obsoleted by RFC 2535) == Missing Reference: 'MPA' is mentioned on line 516, but not defined == Unused Reference: 'RCF2065' is defined on line 773, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mark Andrews (CSIRO) 3 November 1997 4 Updates: 1034, 1035 6 Negative Caching of DNS Queries (DNS NCACHE) 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as "work 19 in progress." 21 To learn the current status of any Internet-Draft, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 [RFC1034] provided a description of how to cache negative 30 responses. It however had a fundamental flaw in that it did not 31 allow a name server to hand out those cached responses to other 32 resolvers, thereby greatly reducing the effect of the caching. 33 This document addresses issues raise in the light of experience 34 and replaces [RFC1034 Section 4.3.4]. 36 Negative caching was an optional part of the DNS specification 37 and deals with the caching of the non-existence of an RRset 38 [RFC2181] or domain name. 40 Negative caching is useful as it reduces the response time for 41 negative answers. It also reduces the number of messages that 42 have to be sent between resolvers and name servers hence overall 43 network traffic. A large proportion of DNS traffic on the 44 Internet could be eliminated if all resolvers implemented 45 negative caching. With this in mind negative caching should no 46 longer be seen as an optional part of a DNS resolver. 48 1 - Terminology 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 [RFC2119]. 54 "Negative caching" - the storage of knowledge that something does not 55 exist. We can store the knowledge that a record has a particular value. 56 We can also do the reverse, that is, to store the knowledge that a 57 record does not exist. It is the storage of knowledge that something 58 does not exist, cannot or does not give an answer that we call negative 59 caching. 61 "QNAME" - the name in the query section of an answer, or where this 62 resolves to a CNAME, or CNAME chain, the data field of the last CNAME. 63 The last CNAME in this sense is that which contains a value which does 64 not resolve to another CNAME. Implementations should note that 65 including CNAME records in responses in order, so that the first has the 66 label from the query section, and then each in sequence has the label 67 from the data section of the previous (where more than one CNAME is 68 needed) allows the sequence to be processed in one pass, and 69 considerably eases the task of the receiver. Other relevant records 70 (such as SIG RRs) can be interspersed amongst the CNAMEs. 72 "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as 73 described in [RFC1035 Section 4.1.1] and the two terms are used 74 interchangeably in this document. 76 "NODATA" - a pseudo RCODE which indicates that the name is valid, for 77 the given class, but are no records of the given type. A NODATA 78 response has to be inferred from the answer. 80 "FORWARDER" - a nameserver used to resolve queries instead of directly 81 using the authoritative nameserver chain. The forwarder typically 82 either has better access to the internet, or maintains a bigger cache 83 which may be shared amongst many resolvers. How a server is identified 84 as a FORWARDER, or knows it is a FORWARDER is outside the scope of this 85 document. However if you are being used as a forwarder the query will 86 have the recursion desired flag set. 88 An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected when 89 reading this document. 91 2 - Negative Responses 93 The most common negative responses indicate that a particular RRset does 94 not exist in the DNS. The first sections of this document deal with 95 this case. Other negative responses can indicate failures of a 96 nameserver, those are dealt with in section 7 (Other Negative 97 Responses). 99 A negative response is indicated by one of the following conditions: 101 2.1 - Name Error 103 Name errors (NXDOMAIN) are indicated by the presence of "Name Error" in 104 the RCODE field. In this case the domain referred to by the QNAME does 105 not exist. Note: the answer section may have SIG and CNAME RRs and 106 authority section may have SOA, NXT and SIG RRsets. 108 It is possible to distinguish between a referral and a NXDOMAIN response 109 by the presense of NXDOMAIN in the RCODE regardless of the presence of 110 NS or SOA records in the authority section. 112 NXDOMAIN responses can be categorised into four types by the contents of 113 the authority section. These are shown below along with a referral for 114 comparison. Fields not mentioned are not important in terms of the 115 examples. 117 NXDOMAIN RESPONSE: TYPE 1. 119 Header: 120 RDCODE=NXDOMAIN 121 Query: 122 AN.EXAMPLE. A 123 Answer: 124 AN.EXAMPLE. CNAME TRIPPLE.XX. 125 Authority: 126 XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... 127 XX. NS NS1.XX. 128 XX. NS NS2.XX. 129 Additional: 130 NS1.XX. A 127.0.0.2 131 NS2.XX. A 127.0.0.3 133 NXDOMAIN RESPONSE: TYPE 2. 135 Header: 136 RDCODE=NXDOMAIN 137 Query: 138 AN.EXAMPLE. A 139 Answer: 140 AN.EXAMPLE. CNAME TRIPPLE.XX. 141 Authority: 142 XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... 143 Additional: 144 146 NXDOMAIN RESPONSE: TYPE 3. 148 Header: 149 RDCODE=NXDOMAIN 150 Query: 151 AN.EXAMPLE. A 152 Answer: 153 AN.EXAMPLE. CNAME TRIPPLE.XX. 154 Authority: 155 156 Additional: 157 159 NXDOMAIN RESPONSE: TYPE 4 161 Header: 162 RDCODE=NXDOMAIN 163 Query: 164 AN.EXAMPLE. A 165 Answer: 166 AN.EXAMPLE. CNAME TRIPPLE.XX. 167 Authority: 168 XX. NS NS1.XX. 169 XX. NS NS2.XX. 170 Additional: 171 NS1.XX. A 127.0.0.2 172 NS2.XX. A 127.0.0.3 174 REFERRAL RESPONSE. 176 Header: 177 RDCODE=NOERROR 178 Query: 179 AN.EXAMPLE. A 180 Answer: 181 AN.EXAMPLE. CNAME TRIPPLE.XX. 182 Authority: 183 XX. NS NS1.XX. 184 XX. NS NS2.XX. 185 Additional: 186 NS1.XX. A 127.0.0.2 187 NS2.XX. A 127.0.0.3 189 Note, in the four examples of NXDOMAIN responses, it is known that the 190 name "AN.EXAMPLE." exists, and has as its value a CNAME record. The 191 NXDOMAIN refers to "TRIPPLE.XX", which is then known not to exist. On 192 the other hand, in the referral example, it is shown that "AN.EXAMPLE" 193 exists, and has a CNAME RR as its value, but nothing is known one way or 194 the other about the existence of "TRIPPLE.XX", other than that "NS1.XX" 195 or "NS2.XX" can be consulted as the next step in obtaining information 196 about it. 198 Where no CNAME records appear, the NXDOMAIN response refers to the name 199 in the label of the RR in the question section. 201 2.1.1 Special Handling of Name Error 203 This section deals with errors encountered when implementing negative 204 caching of NXDOMAIN responses. 206 There are a large number of resolvers currently in existence that fail 207 to correctly detect and process all forms of NXDOMAIN response. Some 208 resolvers treat a TYPE 1 NXDOMAIN response as a referral. To alleviate 209 this problem it is recommended that servers that are authoritative for 210 the NXDOMAIN response only send TYPE 2 NXDOMAIN responses, that is the 211 authority section contains a SOA record and no NS records. If a non- 212 authoritative server sends a type 1 NXDOMAIN response to one of these 213 old resolvers, the result will be an unnecessary query to an 214 authoritative server. This is undesirable, but not fatal except when 215 the server is being used a FORWARDER. If however the resolver is using 216 the server as a FORWARDER to such a resolver it will be necessary to 217 disable the sending of TYPE 1 NXDOMAIN response to it, use TYPE 2 218 NXDOMAIN instead. 220 Some resolvers incorrectly continue processing if the authoritative 221 answer flag is not set. This is a problem when your nameserver is 222 listed as a FORWARDER for such resolvers. If the nameserver is used as 223 a FORWARDER by such resolver, the authority flag will have to be forced 224 on for NXDOMAIN responses to these resolvers. 226 2.2 - No Data 228 NODATA is indicated by an answer with the RCODE set to NOERROR and no 229 relevant answers in the answer section. The authority section will 230 contain an SOA record, or there will be no NS records there. 232 NODATA responses have to be algorithmically determined from the 233 response's contents as there is no RCODE value to indicate NODATA. In 234 some cases to determine with certainty that NODATA is the correct 235 response it can be necessary to send another query. 237 The authority section may contain NXT and SIG RRsets in addition to NS 238 and SOA records. CNAME and SIG records may exist in the answer section. 240 It is possible to distinguish between a NODATA and a referral response 241 by the presence of a SOA record in the authority section or the absence 242 of NS records in the authority section. 244 NODATA responses can be categorised into three types by the contents of 245 the authority section. These are shows below along with a referral for 246 comparison. Fields not mentioned are not important in terms of the 247 examples. 249 NODATA RESPONSE: TYPE 1. 251 Header: 252 RDCODE=NOERROR 253 Query: 254 ANOTHER.EXAMPLE. A 255 Answer: 256 257 Authority: 258 EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... 259 EXAMPLE. NS NS1.XX. 260 EXAMPLE. NS NS2.XX. 261 Additional: 262 NS1.XX. A 127.0.0.2 263 NS2.XX. A 127.0.0.3 265 NO DATA RESPONSE: TYPE 2. 267 Header: 268 RDCODE=NOERROR 269 Query: 270 ANOTHER.EXAMPLE. A 271 Answer: 272 273 Authority: 274 EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... 275 Additional: 276 278 NO DATA RESPONSE: TYPE 3. 280 Header: 281 RDCODE=NOERROR 282 Query: 283 ANOTHER.EXAMPLE. A 284 Answer: 285 286 Authority: 287 288 Additional: 289 291 REFERRAL RESPONSE. 293 Header: 294 RDCODE=NOERROR 295 Query: 296 ANOTHER.EXAMPLE. A 297 Answer: 298 299 Authority: 300 EXAMPLE. NS NS1.XX. 301 EXAMPLE. NS NS2.XX. 302 Additional: 303 NS1.XX. A 127.0.0.2 304 NS2.XX. A 127.0.0.3 306 These examples, unlike the NXDOMAIN examples above, have no CNAME 307 records, however they could, in just the same way that the NXDOMAIN 308 examples did, in which case it would be the value of the last CNAME (the 309 QNAME) for which NODATA would be concluded. 311 2.2.1 - Special Handling of No Data 313 There are a large number of resolvers currently in existence that fail 314 to correctly detect and process all forms of NODATA response. Some 315 resolvers treat a TYPE 1 NODATA response as a referral. To alleviate 316 this problem it is recommended that servers that are authoritative for 317 the NODATA response only send TYPE 2 NODATA responses, that is the 318 authority section contains a SOA record and no NS records. Sending a 319 TYPE 1 NODATA response from a non-authoritative server to one of these 320 resolvers will only result in an unnecessary query. If a server is 321 listed as a FORWARDER for another resolver it may also be necessary to 322 disable the sending of TYPE 1 NODATA response for non-authoritative 323 NODATA responses. 325 Some name servers fail to set the RCODE to NXDOMAIN in the presence of 326 CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA answer 327 is required in this case the resolver must query again using the QNAME 328 as the query label. 330 3 - Negative Answers from Authoritative Servers 332 Name servers authoritative for a zone MUST include the SOA record of the 333 zone in the authority section of the response when reporting an NXDOMAIN 334 or indicating that no data of the requested type exists. This is 335 required so that the response may be cached. The TTL of this record is 336 set from the minimum of the MINIMUM field of the SOA record and the TTL 337 of the SOA itself, and indicates how long a resolver may cache the 338 negative answer. The TTL SIG record associated with the SOA record 339 should also be trimmed in line with the SOA's TTL. 341 If the containing zone is signed [RFC2065] the SOA and appropriate NXT 342 and SIG records MUST be added. 344 4 - SOA Minimum Field 346 The SOA minimum field has been overloaded in the past to have three 347 different meanings, the minimum TTL value of all RRs in a zone, the 348 default TTL of RRs which did not contain a TTL value and the TTL of 349 negative responses. 351 Despite being the original defined meaning, the first of these, the 352 minimum TTL value of all RRs in a zone, has never in practice been used 353 and is hereby deprecated. 355 The second, the default TTL of RRs which contain no explicit TTL in the 356 master zone file, is relevant only at the primary server. After a zone 357 transfer all RRs have explicit TTLs and it is impossible to determine 358 whether the TTL for a record was explicitly set or derived from the 359 default after a zone transfer. Where a server does not require RRs to 360 include the TTL value explicitly, it should provide a mechanism, not 361 being the value of the MINIMUM field of the SOA record, from which the 362 missing TTL values are obtained. How this is done is implementation 363 dependent. 365 The Master File format [RFC 1035 Section 5] is extended to include the 366 following directive: 368 $TTL [comment] 370 All resource records appearing after the directive, and which do not 371 explicitly include a TTL value, have their TTL set to the TTL given in 372 the $TTL directive. SIG records without a explicit TTL get their TTL 373 from the "original TTL" of the SIG record [RFC 2065 Section 4.5]. 375 The remaining of the current meanings, of being the TTL to be used for 376 negative responses, is the new defined meaning of the SOA minimum field. 378 5 - Caching Negative Answers 380 Like normal answers negative answers have a time to live (TTL). As 381 there is no record in the answer section to which this TTL can be 382 applied, the TTL must be carried by another method. This is done by 383 including the SOA record from the zone in the authority section of the 384 reply. When the authoritative server creates this record its TTL is 385 taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This TTL 386 decrements in a similar manner to a normal cached answer and upon 387 reaching zero (0) indicates the cached negative answer MUST NOT be used 388 again. 390 A negative answer that resulted from a name error (NXDOMAIN) should be 391 cached such that it can be retrieved and returned in response to another 392 query for the same that resulted in the cached negative 393 response. 395 A negative answer that resulted from a no data error (NODATA) should be 396 cached such that it can be retrieved and returned in response to another 397 query for the same that resulted in the cached 398 negative response. 400 The NXT record, if it exists in the authority section of a negative 401 answer received, MUST be stored such that it can be be located and 402 returned with SOA record in the authority section, as should any SIG 403 records in the authority section. For NXDOMAIN answers there is no 404 "necessary" obvious relationship between the NXT records and the QNAME. 405 The NXT record MUST have the same owner name as the query name for 406 NODATA responses. 408 Negative responses without SOA records SHOULD NOT be cached as there is 409 no way to prevent the negative responses looping forever between a pair 410 of servers even with a short TTL. 412 As with caching positive responses it is sensible for a resolver to 413 limit for how long it will cache a negative response as the protocol 414 supports caching for up to 68 years. Such a limit should not be greater 415 than that applied to positive answers and preferably be tunable. Values 416 of one to three hours have been found to work well and would make 417 sensible a default. Values exceeding one day have been found to be 418 problematic. 420 6 - Negative answers from the cache 422 When a server, in answering a query, encounters a cached negative 423 response it MUST add the cached SOA record to the authority section of 424 the response with the TTL decremented by the amount of time it was 425 stored in the cache. This allows the NXDOMAIN / NODATA response to time 426 out correctly. 428 If a NXT record was cached along with SOA record it MUST be added to the 429 authority section. If a SIG record was cached along with a NXT record 430 it SHOULD be added to the authority section. 432 As with all answers coming from the cache, negative answers SHOULD have 433 an implicit referral built into the answer. This enables the resolver 434 to locate an authoritative source. An implicit referral is 435 characterised by NS records in the authority section referring the 436 resolver towards a authoritative source. NXDOMAIN types 1 and 4 437 responses contain implicit referrals as does NODATA type 1 response. 439 7 - Other Negative Responses 441 Caching of other negative responses is not covered by any existing RFC. 442 There is no way to indicate a desired TTL in these responses. Care 443 needs to be taken to ensure that there are not forwarding loops. 445 7.1 Server Failure (OPTIONAL) 447 Server failures fall into two major classes. The first is where a 448 server can determine that it has been misconfigured for a zone. This 449 may be where it has been listed as a server, but not configured to be a 450 server for the zone, or where it has been configured to be a server for 451 the zone, but cannot obtain the zone data for some reason. This can 452 occur either because the zone file does not exist or contains errors, or 453 because another server from which the zone should have been available 454 either did not respond or was unable or unwilling to supply the zone. 456 The second class is where the server needs to obtain an answer from 457 elsewhere, but is unable to do so, due to network failures, other 458 servers that don't reply, or return server failure errors, or similar. 460 In either case a resolver MAY cache a server failure response. If it 461 does so it MUST NOT cache it for longer than five (5) minutes, and it 462 MUST be cached against the specific query tuple . 465 7.2 Dead / Unreachable Server (OPTIONAL) 467 Dead / Unreachable servers are servers that fail to respond in any way 468 to a query or where the transport layer has provided an indication that 469 the server does not exist or is unreachable. A server may be deemed to 470 be dead or unreachable if it has not responded to an outstanding query 471 within 120 seconds. 473 Examples of transport layer indications are: 475 ICMP error messages indicating host, net or port unreachable. 476 TCP resets 477 IP stack error messages providing similar indications to those above. 479 A server MAY cache a dead server indication. If it does so it MUST NOT 480 be deemed dead for longer than five (5) minutes. The indication MUST be 481 stored against query tuple 482 unless there was a transport layer indication that the server does not 483 exist, in which case it applies to all queries to that specific IP 484 address. 486 8 - Changes from RFC 1034 488 Negative caching in resolvers is no-longer optional, if a resolver 489 caches anything it must also cache negative answers. 491 Non-authoritative negative answers MAY be cached. 493 The SOA record from the authority section MUST be cached. Name error 494 indications must be cached against the tuple . No 495 data indications must be cached against 496 tuple. 498 A cached SOA record must be added to the response. This was explicitly 499 not allowed because previously the distinction between a normal cached 500 SOA record, and the SOA cached as a result of a negative response was 501 not made, and simply extracting a normal cached SOA and adding that to a 502 cached negative response causes problems. 504 The $TTL TTL directive was added to the master file format. 506 9 History of Negative Caching 508 The following is a potted history of negative caching in the DNS and 509 forms no part of the technical specification of negative caching. 511 It is interesting to note that the same concepts were re-invented in 512 both the CHIVES and BIND servers. 514 The history of the early CHIVES work (Section 9.1) was supplied by Rob 515 Austein and is reproduced here in the form in which 516 he supplied it [MPA]. 518 Sometime around the spring of 1985, I mentioned to Paul Mockapetris that 519 our experience with his JEEVES DNS resolver had pointed out the need for 520 some kind of negative caching scheme. Paul suggested that we simply 521 cache authoritative errors, using the SOA MINIMUM value for the zone 522 that would have contained the target RRs. I'm pretty sure that this 523 conversation took place before RFC-973 was written, but it was never 524 clear to me whether this idea was something that Paul came up with on 525 the spot in response to my question or something he'd already been 526 planning to put into the document that became RFC-973. In any case, 527 neither of us was entirely sure that the SOA MINIMUM value was really 528 the right metric to use, but it was available and was under the control 529 of the administrator of the target zone, both of which seemed to us at 530 the time to be important feature. 532 Late in 1987, I released the initial beta-test version of CHIVES, the 533 DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES 534 included a search path mechanism that was used pretty heavily at several 535 sites (including my own), so CHIVES also included a negative caching 536 mechanism based on SOA MINIMUM values. The basic strategy was to cache 537 authoritative error codes keyed by the exact query parameters (QNAME, 538 QCLASS, and QTYPE), with a cache TTL equal to the SOA MINIMUM value. 539 CHIVES did not attempt to track down SOA RRs if they weren't supplied in 540 the authoritative response, so it never managed to completely eliminate 541 the gratuitous DNS error message traffic, but it did help considerably. 542 Keep in mind that this was happening at about the same time as the 543 near-collapse of the ARPANET due to congestion caused by exponential 544 growth and the the "old" (pre-VJ) TCP retransmission algorithm, so 545 negative caching resulted in drasticly better DNS response time for our 546 users, mailer daemons, etcetera. 548 As far as I know, CHIVES was the first resolver to implement negative 549 caching. CHIVES was developed during the twilight years of TOPS-20, so 550 it never ran on very many machines, but the few machines that it did run 551 on were the ones that were too critical to shut down quickly no matter 552 how much it cost to keep them running. So what few users we did have 553 tended to drive CHIVES pretty hard. Several interesting bits of DNS 554 technology resulted from that, but the one that's relevant here is the 555 MAXTTL configuration parameter. 557 Experience with JEEVES had already shown that RRs often showed up with 558 ridiculously long TTLs (99999999 was particularly popular for many 559 years, due to bugs in the code and documentation of several early 560 versions of BIND), and that robust software that blindly believed such 561 TTLs could create so many strange failures that it was often necessary 562 to reboot the resolver frequently just to clear this garbage out of the 563 cache. So CHIVES had a configuration parameter "MAXTTL", which 564 specified the maximum "reasonable" TTL in a received RR. RRs with TTLs 565 greater than MAXTTL would either have their TTLs reduced to MAXTTL or 566 would be discarded entirely, depending on the setting of another 567 configuration parameter. 569 When we started getting field experience with CHIVES's negative caching 570 code, it became clear that the SOA MINIMUM value was often large enough 571 to cause the same kinds of problems for negative caching as the huge 572 TTLs in RRs had for normal caching (again, this was in part due to a bug 573 in several early versions of BIND, where a secondary server would 574 authoritatively deny all knowledge of its zones if it couldn't contact 575 the primaries on reboot). So we started running the negative cache TTLs 576 through the MAXTTL check too, and continued to experiment. 578 The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL 579 (last of the major Internet TOPS-20 machines to be shut down, thus the 580 last major user of CHIVES, thus the place where we had the longest 581 experimental baseline) was to set MAXTTL to about three days. Most of 582 the traffic initiated by SIMTEL20 in its last years was mail-related, 583 and the mail queue timeout was set to one week, so this gave a "stuck" 584 message several tries at complete DNS resolution, without bogging down 585 the system with a lot of useless queries. Since (for reasons that now 586 escape me) we only had the single MAXTTL parameter rather than separate 587 ones for positive and negative caching, it's not clear how much effect 588 this setting of MAXTTL had on the negative caching code. 590 CHIVES also included a second, somewhat controversial mechanism which 591 took the place of negative caching in some cases. The CHIVES resolver 592 daemon could be configured to load DNS master files, giving it the 593 ability to act as what today would be called a "stealth secondary". 594 That is, when configured in this way, the resolver had direct access to 595 authoritative information for heavily-used zones. The search path 596 mechanisms in CHIVES reflected this: there were actually two separate 597 search paths, one of which only searched local authoritative zone data, 598 and one which could generate normal iterative queries. This cut down on 599 the need for negative caching in cases where usage was predictably heavy 600 (e.g., the resolver on XX.LCS.MIT.EDU always loaded the zone files for 601 both LCS.MIT.EDU and AI.MIT.EDU and put both of these suffixes into the 602 "local" search path, since between them the hosts in these two zones 603 accounted for the bulk of the DNS traffic). Not all sites running 604 CHIVES chose to use this feature; C.CS.CMU.EDU, for example, chose to 605 use the "remote" search path for everything because there were too many 606 different sub-zones at CMU for zone shadowing to be practical for them, 607 so they relied pretty heavily on negative caching even for local 608 traffic. 610 Overall, I still think the basic design we used for negative caching was 611 pretty reasonable: the zone administrator specified how long to cache 612 negative answers, and the resolver configuration chose the actual cache 613 time from the range between zero and the period specified by the zone 614 administrator. There are a lot of details I'd do differently now (like 615 using a new SOA field instead of overloading the MINIMUM field), but 616 after more than a decade, I'd be more worried if we couldn't think of at 617 least a few improvements. 619 9.2 BIND 621 While not the first attempt to get negative caching into BIND, in July 622 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that 623 implemented, validation and negative caching (NCACHE). This code had a 624 10 minute TTL for negative caching and only cached the indication that 625 there was a negative response, NXDOMAIN or NOERROR_NODATA. This is the 626 origin of the NODATA pseudo response code mentioned above. 628 Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA record 629 such that it could be retrieved by a similar query. UUnet complained 630 that they were getting old answers after loading a new zone, and the 631 option was turned off, BIND 4.9.3-alpha5, April 1994. In reality this 632 indicated that the named needed to purge the space the zone would 633 occupy. Functionality to do this was added in BIND 4.9.3 BETA11 patch2, 634 December 1994. 636 RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996. 638 10 Example 640 The following example is based on a signed zone that is empty apart from 641 the nameservers. We will query for WWW.XX.EXAMPLE showing initial 642 response and again 10 minutes later. 643 Note 1: during the intervening 10 minutes the NS records for XX.EXAMPLE 644 have expired. 645 Note 2: the TTL of the SIG records are not explicitly set in the zone 646 file and are hence the TTL of the RRset they are the signature for. 648 Zone File: 650 $TTL 86400 651 $ORIGIN XX.EXAMPLE. 652 @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. ( 653 1997102000 ; serial 654 1800 ; refresh (30 mins) 655 900 ; retry (15 mins) 656 604800 ; expire (7 days) 657 1200 ) ; minimum (20 mins) 658 IN SIG SOA ... 659 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY 660 IN SIG NXT ... XX.EXAMPLE. ... 661 300 IN NS NS1.XX.EXAMPLE. 662 300 IN NS NS2.XX.EXAMPLE. 663 IN SIG NS ... XX.EXAMPLE. ... 664 IN KEY 0x4100 1 1 ... 665 IN SIG KEY ... XX.EXAMPLE. ... 666 IN SIG KEY ... EXAMPLE. ... 667 NS1 IN A 10.0.0.1 668 IN SIG A ... XX.EXAMPLE. ... 669 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG 670 IN SIG NXT ... 671 NS2 IN A 10.0.0.2 672 IN SIG A ... XX.EXAMPLE. ... 673 1200 IN NXT XX.EXAMPLE. A NXT SIG 674 IN SIG NXT ... XX.EXAMPLE. ... 676 Initial Response: 678 Header: 679 RDCODE=NXDOMAIN, AA=1, QR=1, TC=0 680 Query: 681 WWW.XX.EXAMPLE. IN A 682 Answer: 683 684 Authority: 685 XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ... 686 XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ... 687 NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG 688 NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ... 689 XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE. 690 XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE. 691 XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ... 692 Additional 693 XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ... 694 XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ... 695 NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1 696 NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... 697 NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2 698 NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... 700 After 10 Minutes: 702 Header: 703 RDCODE=NXDOMAIN, AA=0, QR=1, TC=0 704 Query: 705 WWW.XX.EXAMPLE. IN A 706 Answer: 707 708 Authority: 709 XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ... 710 XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ... 711 NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG 712 NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... 713 EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. 714 EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. 715 EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... 716 Additional 717 XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ... 718 XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... 719 NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 720 NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 721 NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 722 NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... 723 EXAMPLE. 65799 IN KEY 0x4100 1 1 ... 724 EXAMPLE. 65799 IN SIG KEY ... . ... 726 11 Security Considerations 728 It is believed that this document does not introduce any significant 729 additional security threats other that those that already exist when 730 using data from the DNS. 732 With negative caching it might be possible to propagate a denial of 733 service attack by spreading a NXDOMAIN message with a very high TTL. 734 Without negative caching that would be much harder. A similar effect 735 could be achieved previously by spreading a bad A record, so that the 736 server could not be reached - which is almost the same. It has the same 737 effect as far as what the end user is able to do, but with a different 738 psychological effect. With the bad A, I feel "damn the network is 739 broken again" and try again tomorrow. With the "NXDOMAIN" I feel "Oh, 740 they've turned off the server and it doesn't exist any more" and 741 probably never bother trying this server again. 743 For such an attack to be successful, the NXDOMAIN indiction injected 744 into a parent server (or a busy caching resolver). One way this might 745 be done by the use of a CNAME which results in the parent server 746 querying an attackers server. Resolvers that wish to prevent such 747 attacks can query again the final QNAME ignoring any NS data in the 748 query responses it has received for this query. 750 Implementing TTL sanity checking will reduce the effectiveness of such 751 an attack, because a successful attack would require re-injection of the 752 bogus data at more frequent intervals. 754 DNS Security [RFC2065] provides a mechanism to verify whether a negative 755 response is valid or not, through the use of NXT and SIG records. This 756 document supports the use of that mechanism by promoting the 757 transmission of the relevant security records even in a non security 758 aware server. 760 I would like to thank Rob Austein for his history of the CHIVES 761 nameserver. The DNSIND working group, in particular Robert Elz for his 762 valuable technical and editorial contributions to this document. 764 References 766 [RFC1034] 767 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES," STD 768 13, RFC 1034, November 1987. 770 [RFC1035]Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 771 SPECIFICATION," STD 13, RFC 1035, November 1987. 773 [RCF2065] 774 Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security 775 Extensions," RFC 2065, January 1997 777 [RFC2119] 778 Bradner, S., "Key words for use in RFCs to Indicate Requirement 779 Levels," BCP 14, RFC 2119, March 1997 781 [RFC2181] 782 Elz, R., and Bush, R., "Clarifications to the DNS 783 Specification," RFC 2181, July 1997. 785 Author's Address 787 Mark Andrews 788 CSIRO - Mathematical and Information Sciences 789 Locked Bag 17 790 North Ryde NSW 2113 791 AUSTRALIA 792 +61 2 9325 3148 793