contrib/bind9/doc/rfc/rfc2308.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          M. Andrews
   8 Request for Comments: 2308                                          CSIRO
   9 Updates: 1034, 1035                                            March 1998
  10 Category: Standards Track
  11
  12
  13               Negative Caching of DNS Queries (DNS NCACHE)
  14
  15 Status of this Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  26
  27 Abstract
  28
  29    [RFC1034] provided a description of how to cache negative responses.
  30    It however had a fundamental flaw in that it did not allow a name
  31    server to hand out those cached responses to other resolvers, thereby
  32    greatly reducing the effect of the caching.  This document addresses
  33    issues raise in the light of experience and replaces [RFC1034 Section
  34    4.3.4].
  35
  36    Negative caching was an optional part of the DNS specification and
  37    deals with the caching of the non-existence of an RRset [RFC2181] or
  38    domain name.
  39
  40    Negative caching is useful as it reduces the response time for
  41    negative answers.  It also reduces the number of messages that have
  42    to be sent between resolvers and name servers hence overall network
  43    traffic.  A large proportion of DNS traffic on the Internet could be
  44    eliminated if all resolvers implemented negative caching.  With this
  45    in mind negative caching should no longer be seen as an optional part
  46    of a DNS resolver.
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Andrews                     Standards Track                     [Page 1]
  59 \f
  60 RFC 2308                       DNS NCACHE                     March 1998
  61
  62
  63 1 - Terminology
  64
  65    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  66    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  67    document are to be interpreted as described in [RFC2119].
  68
  69    "Negative caching" - the storage of knowledge that something does not
  70    exist.  We can store the knowledge that a record has a particular
  71    value.  We can also do the reverse, that is, to store the knowledge
  72    that a record does not exist.  It is the storage of knowledge that
  73    something does not exist, cannot or does not give an answer that we
  74    call negative caching.
  75
  76    "QNAME" - the name in the query section of an answer, or where this
  77    resolves to a CNAME, or CNAME chain, the data field of the last
  78    CNAME.  The last CNAME in this sense is that which contains a value
  79    which does not resolve to another CNAME.  Implementations should note
  80    that including CNAME records in responses in order, so that the first
  81    has the label from the query section, and then each in sequence has
  82    the label from the data section of the previous (where more than one
  83    CNAME is needed) allows the sequence to be processed in one pass, and
  84    considerably eases the task of the receiver.  Other relevant records
  85    (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
  86
  87    "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
  88    described in [RFC1035 Section 4.1.1] and the two terms are used
  89    interchangeably in this document.
  90
  91    "NODATA" - a pseudo RCODE which indicates that the name is valid, for
  92    the given class, but are no records of the given type.  A NODATA
  93    response has to be inferred from the answer.
  94
  95    "FORWARDER" - a nameserver used to resolve queries instead of
  96    directly using the authoritative nameserver chain.  The forwarder
  97    typically either has better access to the internet, or maintains a
  98    bigger cache which may be shared amongst many resolvers.  How a
  99    server is identified as a FORWARDER, or knows it is a FORWARDER is
 100    outside the scope of this document.  However if you are being used as
 101    a forwarder the query will have the recursion desired flag set.
 102
 103    An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
 104    when reading this document.
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Andrews                     Standards Track                     [Page 2]
 115 \f
 116 RFC 2308                       DNS NCACHE                     March 1998
 117
 118
 119 2 - Negative Responses
 120
 121    The most common negative responses indicate that a particular RRset
 122    does not exist in the DNS.  The first sections of this document deal
 123    with this case.  Other negative responses can indicate failures of a
 124    nameserver, those are dealt with in section 7 (Other Negative
 125    Responses).
 126
 127    A negative response is indicated by one of the following conditions:
 128
 129 2.1 - Name Error
 130
 131    Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
 132    in the RCODE field.  In this case the domain referred to by the QNAME
 133    does not exist.  Note: the answer section may have SIG and CNAME RRs
 134    and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
 135
 136    It is possible to distinguish between a referral and a NXDOMAIN
 137    response by the presense of NXDOMAIN in the RCODE regardless of the
 138    presence of NS or SOA records in the authority section.
 139
 140    NXDOMAIN responses can be categorised into four types by the contents
 141    of the authority section.  These are shown below along with a
 142    referral for comparison.  Fields not mentioned are not important in
 143    terms of the examples.
 144
 145            NXDOMAIN RESPONSE: TYPE 1.
 146
 147            Header:
 148                RDCODE=NXDOMAIN
 149            Query:
 150                AN.EXAMPLE. A
 151            Answer:
 152                AN.EXAMPLE. CNAME TRIPPLE.XX.
 153            Authority:
 154                XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
 155                XX. NS NS1.XX.
 156                XX. NS NS2.XX.
 157            Additional:
 158                NS1.XX. A 127.0.0.2
 159                NS2.XX. A 127.0.0.3
 160
 161            NXDOMAIN RESPONSE: TYPE 2.
 162
 163            Header:
 164                RDCODE=NXDOMAIN
 165            Query:
 166                AN.EXAMPLE. A
 167
 168
 169
 170 Andrews                     Standards Track                     [Page 3]
 171 \f
 172 RFC 2308                       DNS NCACHE                     March 1998
 173
 174
 175            Answer:
 176                AN.EXAMPLE. CNAME TRIPPLE.XX.
 177            Authority:
 178                XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
 179            Additional:
 180                <empty>
 181
 182            NXDOMAIN RESPONSE: TYPE 3.
 183
 184            Header:
 185                RDCODE=NXDOMAIN
 186            Query:
 187                AN.EXAMPLE. A
 188            Answer:
 189                AN.EXAMPLE. CNAME TRIPPLE.XX.
 190            Authority:
 191                <empty>
 192            Additional:
 193                <empty>
 194
 195            NXDOMAIN RESPONSE: TYPE 4
 196
 197            Header:
 198                RDCODE=NXDOMAIN
 199            Query:
 200                AN.EXAMPLE. A
 201            Answer:
 202                AN.EXAMPLE. CNAME TRIPPLE.XX.
 203            Authority:
 204                XX. NS NS1.XX.
 205                XX. NS NS2.XX.
 206            Additional:
 207                NS1.XX. A 127.0.0.2
 208                NS2.XX. A 127.0.0.3
 209
 210            REFERRAL RESPONSE.
 211
 212            Header:
 213                RDCODE=NOERROR
 214            Query:
 215                AN.EXAMPLE. A
 216            Answer:
 217                AN.EXAMPLE. CNAME TRIPPLE.XX.
 218            Authority:
 219                XX. NS NS1.XX.
 220                XX. NS NS2.XX.
 221            Additional:
 222                NS1.XX. A 127.0.0.2
 223
 224
 225
 226 Andrews                     Standards Track                     [Page 4]
 227 \f
 228 RFC 2308                       DNS NCACHE                     March 1998
 229
 230
 231                NS2.XX. A 127.0.0.3
 232
 233    Note, in the four examples of NXDOMAIN responses, it is known that
 234    the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
 235    The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
 236    exist.  On the other hand, in the referral example, it is shown that
 237    "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
 238    known one way or the other about the existence of "TRIPPLE.XX", other
 239    than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
 240    obtaining information about it.
 241
 242    Where no CNAME records appear, the NXDOMAIN response refers to the
 243    name in the label of the RR in the question section.
 244
 245 2.1.1 Special Handling of Name Error
 246
 247    This section deals with errors encountered when implementing negative
 248    caching of NXDOMAIN responses.
 249
 250    There are a large number of resolvers currently in existence that
 251    fail to correctly detect and process all forms of NXDOMAIN response.
 252    Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
 253    alleviate this problem it is recommended that servers that are
 254    authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
 255    responses, that is the authority section contains a SOA record and no
 256    NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
 257    response to one of these old resolvers, the result will be an
 258    unnecessary query to an authoritative server.  This is undesirable,
 259    but not fatal except when the server is being used a FORWARDER.  If
 260    however the resolver is using the server as a FORWARDER to such a
 261    resolver it will be necessary to disable the sending of TYPE 1
 262    NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
 263
 264    Some resolvers incorrectly continue processing if the authoritative
 265    answer flag is not set, looping until the query retry threshold is
 266    exceeded and then returning SERVFAIL.  This is a problem when your
 267    nameserver is listed as a FORWARDER for such resolvers.  If the
 268    nameserver is used as a FORWARDER by such resolver, the authority
 269    flag will have to be forced on for NXDOMAIN responses to these
 270    resolvers.  In practice this causes no problems even if turned on
 271    always, and has been the default behaviour in BIND from 4.9.3
 272    onwards.
 273
 274 2.2 - No Data
 275
 276    NODATA is indicated by an answer with the RCODE set to NOERROR and no
 277    relevant answers in the answer section.  The authority section will
 278    contain an SOA record, or there will be no NS records there.
 279
 280
 281
 282 Andrews                     Standards Track                     [Page 5]
 283 \f
 284 RFC 2308                       DNS NCACHE                     March 1998
 285
 286
 287    NODATA responses have to be algorithmically determined from the
 288    response's contents as there is no RCODE value to indicate NODATA.
 289    In some cases to determine with certainty that NODATA is the correct
 290    response it can be necessary to send another query.
 291
 292    The authority section may contain NXT and SIG RRsets in addition to
 293    NS and SOA records.  CNAME and SIG records may exist in the answer
 294    section.
 295
 296    It is possible to distinguish between a NODATA and a referral
 297    response by the presence of a SOA record in the authority section or
 298    the absence of NS records in the authority section.
 299
 300    NODATA responses can be categorised into three types by the contents
 301    of the authority section.  These are shown below along with a
 302    referral for comparison.  Fields not mentioned are not important in
 303    terms of the examples.
 304
 305            NODATA RESPONSE: TYPE 1.
 306
 307            Header:
 308                RDCODE=NOERROR
 309            Query:
 310                ANOTHER.EXAMPLE. A
 311            Answer:
 312                <empty>
 313            Authority:
 314                EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
 315                EXAMPLE. NS NS1.XX.
 316                EXAMPLE. NS NS2.XX.
 317            Additional:
 318                NS1.XX. A 127.0.0.2
 319                NS2.XX. A 127.0.0.3
 320
 321            NO DATA RESPONSE: TYPE 2.
 322
 323            Header:
 324                RDCODE=NOERROR
 325            Query:
 326                ANOTHER.EXAMPLE. A
 327            Answer:
 328                <empty>
 329            Authority:
 330                EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
 331            Additional:
 332                <empty>
 333
 334
 335
 336
 337
 338 Andrews                     Standards Track                     [Page 6]
 339 \f
 340 RFC 2308                       DNS NCACHE                     March 1998
 341
 342
 343            NO DATA RESPONSE: TYPE 3.
 344
 345            Header:
 346                RDCODE=NOERROR
 347            Query:
 348                ANOTHER.EXAMPLE. A
 349            Answer:
 350                <empty>
 351            Authority:
 352                <empty>
 353            Additional:
 354                <empty>
 355
 356            REFERRAL RESPONSE.
 357
 358            Header:
 359                RDCODE=NOERROR
 360            Query:
 361                ANOTHER.EXAMPLE. A
 362            Answer:
 363                <empty>
 364            Authority:
 365                EXAMPLE. NS NS1.XX.
 366                EXAMPLE. NS NS2.XX.
 367            Additional:
 368                NS1.XX. A 127.0.0.2
 369                NS2.XX. A 127.0.0.3
 370
 371
 372    These examples, unlike the NXDOMAIN examples above, have no CNAME
 373    records, however they could, in just the same way that the NXDOMAIN
 374    examples did, in which case it would be the value of the last CNAME
 375    (the QNAME) for which NODATA would be concluded.
 376
 377 2.2.1 - Special Handling of No Data
 378
 379    There are a large number of resolvers currently in existence that
 380    fail to correctly detect and process all forms of NODATA response.
 381    Some resolvers treat a TYPE 1 NODATA response as a referral.  To
 382    alleviate this problem it is recommended that servers that are
 383    authoritative for the NODATA response only send TYPE 2 NODATA
 384    responses, that is the authority section contains a SOA record and no
 385    NS records.  Sending a TYPE 1 NODATA response from a non-
 386    authoritative server to one of these resolvers will only result in an
 387    unnecessary query.  If a server is listed as a FORWARDER for another
 388    resolver it may also be necessary to disable the sending of TYPE 1
 389    NODATA response for non-authoritative NODATA responses.
 390
 391
 392
 393
 394 Andrews                     Standards Track                     [Page 7]
 395 \f
 396 RFC 2308                       DNS NCACHE                     March 1998
 397
 398
 399    Some name servers fail to set the RCODE to NXDOMAIN in the presence
 400    of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
 401    answer is required in this case the resolver must query again using
 402    the QNAME as the query label.
 403
 404 3 - Negative Answers from Authoritative Servers
 405
 406    Name servers authoritative for a zone MUST include the SOA record of
 407    the zone in the authority section of the response when reporting an
 408    NXDOMAIN or indicating that no data of the requested type exists.
 409    This is required so that the response may be cached.  The TTL of this
 410    record is set from the minimum of the MINIMUM field of the SOA record
 411    and the TTL of the SOA itself, and indicates how long a resolver may
 412    cache the negative answer.  The TTL SIG record associated with the
 413    SOA record should also be trimmed in line with the SOA's TTL.
 414
 415    If the containing zone is signed [RFC2065] the SOA and appropriate
 416    NXT and SIG records MUST be added.
 417
 418 4 - SOA Minimum Field
 419
 420    The SOA minimum field has been overloaded in the past to have three
 421    different meanings, the minimum TTL value of all RRs in a zone, the
 422    default TTL of RRs which did not contain a TTL value and the TTL of
 423    negative responses.
 424
 425    Despite being the original defined meaning, the first of these, the
 426    minimum TTL value of all RRs in a zone, has never in practice been
 427    used and is hereby deprecated.
 428
 429    The second, the default TTL of RRs which contain no explicit TTL in
 430    the master zone file, is relevant only at the primary server.  After
 431    a zone transfer all RRs have explicit TTLs and it is impossible to
 432    determine whether the TTL for a record was explicitly set or derived
 433    from the default after a zone transfer.  Where a server does not
 434    require RRs to include the TTL value explicitly, it should provide a
 435    mechanism, not being the value of the MINIMUM field of the SOA
 436    record, from which the missing TTL values are obtained.  How this is
 437    done is implementation dependent.
 438
 439    The Master File format [RFC 1035 Section 5] is extended to include
 440    the following directive:
 441
 442                            $TTL <TTL> [comment]
 443
 444
 445
 446
 447
 448
 449
 450 Andrews                     Standards Track                     [Page 8]
 451 \f
 452 RFC 2308                       DNS NCACHE                     March 1998
 453
 454
 455    All resource records appearing after the directive, and which do not
 456    explicitly include a TTL value, have their TTL set to the TTL given
 457    in the $TTL directive.  SIG records without a explicit TTL get their
 458    TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
 459
 460    The remaining of the current meanings, of being the TTL to be used
 461    for negative responses, is the new defined meaning of the SOA minimum
 462    field.
 463
 464 5 - Caching Negative Answers
 465
 466    Like normal answers negative answers have a time to live (TTL).  As
 467    there is no record in the answer section to which this TTL can be
 468    applied, the TTL must be carried by another method.  This is done by
 469    including the SOA record from the zone in the authority section of
 470    the reply.  When the authoritative server creates this record its TTL
 471    is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
 472    This TTL decrements in a similar manner to a normal cached answer and
 473    upon reaching zero (0) indicates the cached negative answer MUST NOT
 474    be used again.
 475
 476    A negative answer that resulted from a name error (NXDOMAIN) should
 477    be cached such that it can be retrieved and returned in response to
 478    another query for the same <QNAME, QCLASS> that resulted in the
 479    cached negative response.
 480
 481    A negative answer that resulted from a no data error (NODATA) should
 482    be cached such that it can be retrieved and returned in response to
 483    another query for the same <QNAME, QTYPE, QCLASS> that resulted in
 484    the cached negative response.
 485
 486    The NXT record, if it exists in the authority section of a negative
 487    answer received, MUST be stored such that it can be be located and
 488    returned with SOA record in the authority section, as should any SIG
 489    records in the authority section.  For NXDOMAIN answers there is no
 490    "necessary" obvious relationship between the NXT records and the
 491    QNAME.  The NXT record MUST have the same owner name as the query
 492    name for NODATA responses.
 493
 494    Negative responses without SOA records SHOULD NOT be cached as there
 495    is no way to prevent the negative responses looping forever between a
 496    pair of servers even with a short TTL.
 497
 498    Despite the DNS forming a tree of servers, with various mis-
 499    configurations it is possible to form a loop in the query graph, e.g.
 500    two servers listing each other as forwarders, various lame server
 501    configurations.  Without a TTL count down a cache negative response
 502
 503
 504
 505
 506 Andrews                     Standards Track                     [Page 9]
 507 \f
 508 RFC 2308                       DNS NCACHE                     March 1998
 509
 510
 511    when received by the next server would have its TTL reset.  This
 512    negative indication could then live forever circulating between the
 513    servers involved.
 514
 515    As with caching positive responses it is sensible for a resolver to
 516    limit for how long it will cache a negative response as the protocol
 517    supports caching for up to 68 years.  Such a limit should not be
 518    greater than that applied to positive answers and preferably be
 519    tunable.  Values of one to three hours have been found to work well
 520    and would make sensible a default.  Values exceeding one day have
 521    been found to be problematic.
 522
 523 6 - Negative answers from the cache
 524
 525    When a server, in answering a query, encounters a cached negative
 526    response it MUST add the cached SOA record to the authority section
 527    of the response with the TTL decremented by the amount of time it was
 528    stored in the cache.  This allows the NXDOMAIN / NODATA response to
 529    time out correctly.
 530
 531    If a NXT record was cached along with SOA record it MUST be added to
 532    the authority section.  If a SIG record was cached along with a NXT
 533    record it SHOULD be added to the authority section.
 534
 535    As with all answers coming from the cache, negative answers SHOULD
 536    have an implicit referral built into the answer.  This enables the
 537    resolver to locate an authoritative source.  An implicit referral is
 538    characterised by NS records in the authority section referring the
 539    resolver towards a authoritative source.  NXDOMAIN types 1 and 4
 540    responses contain implicit referrals as does NODATA type 1 response.
 541
 542 7 - Other Negative Responses
 543
 544    Caching of other negative responses is not covered by any existing
 545    RFC.  There is no way to indicate a desired TTL in these responses.
 546    Care needs to be taken to ensure that there are not forwarding loops.
 547
 548 7.1 Server Failure (OPTIONAL)
 549
 550    Server failures fall into two major classes.  The first is where a
 551    server can determine that it has been misconfigured for a zone.  This
 552    may be where it has been listed as a server, but not configured to be
 553    a server for the zone, or where it has been configured to be a server
 554    for the zone, but cannot obtain the zone data for some reason.  This
 555    can occur either because the zone file does not exist or contains
 556    errors, or because another server from which the zone should have
 557    been available either did not respond or was unable or unwilling to
 558    supply the zone.
 559
 560
 561
 562 Andrews                     Standards Track                    [Page 10]
 563 \f
 564 RFC 2308                       DNS NCACHE                     March 1998
 565
 566
 567    The second class is where the server needs to obtain an answer from
 568    elsewhere, but is unable to do so, due to network failures, other
 569    servers that don't reply, or return server failure errors, or
 570    similar.
 571
 572    In either case a resolver MAY cache a server failure response.  If it
 573    does so it MUST NOT cache it for longer than five (5) minutes, and it
 574    MUST be cached against the specific query tuple <query name, type,
 575    class, server IP address>.
 576
 577 7.2 Dead / Unreachable Server (OPTIONAL)
 578
 579    Dead / Unreachable servers are servers that fail to respond in any
 580    way to a query or where the transport layer has provided an
 581    indication that the server does not exist or is unreachable.  A
 582    server may be deemed to be dead or unreachable if it has not
 583    responded to an outstanding query within 120 seconds.
 584
 585    Examples of transport layer indications are:
 586
 587       ICMP error messages indicating host, net or port unreachable.
 588       TCP resets
 589       IP stack error messages providing similar indications to those above.
 590
 591    A server MAY cache a dead server indication.  If it does so it MUST
 592    NOT be deemed dead for longer than five (5) minutes.  The indication
 593    MUST be stored against query tuple <query name, type, class, server
 594    IP address> unless there was a transport layer indication that the
 595    server does not exist, in which case it applies to all queries to
 596    that specific IP address.
 597
 598 8 - Changes from RFC 1034
 599
 600    Negative caching in resolvers is no-longer optional, if a resolver
 601    caches anything it must also cache negative answers.
 602
 603    Non-authoritative negative answers MAY be cached.
 604
 605    The SOA record from the authority section MUST be cached.  Name error
 606    indications must be cached against the tuple <query name, QCLASS>.
 607    No data indications must be cached against <query name, QTYPE,
 608    QCLASS> tuple.
 609
 610    A cached SOA record must be added to the response.  This was
 611    explicitly not allowed because previously the distinction between a
 612    normal cached SOA record, and the SOA cached as a result of a
 613    negative response was not made, and simply extracting a normal cached
 614    SOA and adding that to a cached negative response causes problems.
 615
 616
 617
 618 Andrews                     Standards Track                    [Page 11]
 619 \f
 620 RFC 2308                       DNS NCACHE                     March 1998
 621
 622
 623    The $TTL TTL directive was added to the master file format.
 624
 625 9 - History of Negative Caching
 626
 627    This section presents a potted history of negative caching in the DNS
 628    and forms no part of the technical specification of negative caching.
 629
 630    It is interesting to note that the same concepts were re-invented in
 631    both the CHIVES and BIND servers.
 632
 633    The history of the early CHIVES work (Section 9.1) was supplied by
 634    Rob Austein <sra@epilogue.com> and is reproduced here in the form in
 635    which he supplied it [MPA].
 636
 637    Sometime around the spring of 1985, I mentioned to Paul Mockapetris
 638    that our experience with his JEEVES DNS resolver had pointed out the
 639    need for some kind of negative caching scheme.  Paul suggested that
 640    we simply cache authoritative errors, using the SOA MINIMUM value for
 641    the zone that would have contained the target RRs.  I'm pretty sure
 642    that this conversation took place before RFC-973 was written, but it
 643    was never clear to me whether this idea was something that Paul came
 644    up with on the spot in response to my question or something he'd
 645    already been planning to put into the document that became RFC-973.
 646    In any case, neither of us was entirely sure that the SOA MINIMUM
 647    value was really the right metric to use, but it was available and
 648    was under the control of the administrator of the target zone, both
 649    of which seemed to us at the time to be important feature.
 650
 651    Late in 1987, I released the initial beta-test version of CHIVES, the
 652    DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
 653    included a search path mechanism that was used pretty heavily at
 654    several sites (including my own), so CHIVES also included a negative
 655    caching mechanism based on SOA MINIMUM values.  The basic strategy
 656    was to cache authoritative error codes keyed by the exact query
 657    parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
 658    SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
 659    they weren't supplied in the authoritative response, so it never
 660    managed to completely eliminate the gratuitous DNS error message
 661    traffic, but it did help considerably.  Keep in mind that this was
 662    happening at about the same time as the near-collapse of the ARPANET
 663    due to congestion caused by exponential growth and the the "old"
 664    (pre-VJ) TCP retransmission algorithm, so negative caching resulted
 665    in drasticly better DNS response time for our users, mailer daemons,
 666    etcetera.
 667
 668
 669
 670
 671
 672
 673
 674 Andrews                     Standards Track                    [Page 12]
 675 \f
 676 RFC 2308                       DNS NCACHE                     March 1998
 677
 678
 679    As far as I know, CHIVES was the first resolver to implement negative
 680    caching.  CHIVES was developed during the twilight years of TOPS-20,
 681    so it never ran on very many machines, but the few machines that it
 682    did run on were the ones that were too critical to shut down quickly
 683    no matter how much it cost to keep them running.  So what few users
 684    we did have tended to drive CHIVES pretty hard.  Several interesting
 685    bits of DNS technology resulted from that, but the one that's
 686    relevant here is the MAXTTL configuration parameter.
 687
 688    Experience with JEEVES had already shown that RRs often showed up
 689    with ridiculously long TTLs (99999999 was particularly popular for
 690    many years, due to bugs in the code and documentation of several
 691    early versions of BIND), and that robust software that blindly
 692    believed such TTLs could create so many strange failures that it was
 693    often necessary to reboot the resolver frequently just to clear this
 694    garbage out of the cache.  So CHIVES had a configuration parameter
 695    "MAXTTL", which specified the maximum "reasonable" TTL in a received
 696    RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
 697    reduced to MAXTTL or would be discarded entirely, depending on the
 698    setting of another configuration parameter.
 699
 700    When we started getting field experience with CHIVES's negative
 701    caching code, it became clear that the SOA MINIMUM value was often
 702    large enough to cause the same kinds of problems for negative caching
 703    as the huge TTLs in RRs had for normal caching (again, this was in
 704    part due to a bug in several early versions of BIND, where a
 705    secondary server would authoritatively deny all knowledge of its
 706    zones if it couldn't contact the primaries on reboot).  So we started
 707    running the negative cache TTLs through the MAXTTL check too, and
 708    continued to experiment.
 709
 710    The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
 711    (last of the major Internet TOPS-20 machines to be shut down, thus
 712    the last major user of CHIVES, thus the place where we had the
 713    longest experimental baseline) was to set MAXTTL to about three days.
 714    Most of the traffic initiated by SIMTEL20 in its last years was
 715    mail-related, and the mail queue timeout was set to one week, so this
 716    gave a "stuck" message several tries at complete DNS resolution,
 717    without bogging down the system with a lot of useless queries.  Since
 718    (for reasons that now escape me) we only had the single MAXTTL
 719    parameter rather than separate ones for positive and negative
 720    caching, it's not clear how much effect this setting of MAXTTL had on
 721    the negative caching code.
 722
 723    CHIVES also included a second, somewhat controversial mechanism which
 724    took the place of negative caching in some cases.  The CHIVES
 725    resolver daemon could be configured to load DNS master files, giving
 726    it the ability to act as what today would be called a "stealth
 727
 728
 729
 730 Andrews                     Standards Track                    [Page 13]
 731 \f
 732 RFC 2308                       DNS NCACHE                     March 1998
 733
 734
 735    secondary".  That is, when configured in this way, the resolver had
 736    direct access to authoritative information for heavily-used zones.
 737    The search path mechanisms in CHIVES reflected this: there were
 738    actually two separate search paths, one of which only searched local
 739    authoritative zone data, and one which could generate normal
 740    iterative queries.  This cut down on the need for negative caching in
 741    cases where usage was predictably heavy (e.g., the resolver on
 742    XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
 743    AI.MIT.EDU and put both of these suffixes into the "local" search
 744    path, since between them the hosts in these two zones accounted for
 745    the bulk of the DNS traffic).  Not all sites running CHIVES chose to
 746    use this feature; C.CS.CMU.EDU, for example, chose to use the
 747    "remote" search path for everything because there were too many
 748    different sub-zones at CMU for zone shadowing to be practical for
 749    them, so they relied pretty heavily on negative caching even for
 750    local traffic.
 751
 752    Overall, I still think the basic design we used for negative caching
 753    was pretty reasonable: the zone administrator specified how long to
 754    cache negative answers, and the resolver configuration chose the
 755    actual cache time from the range between zero and the period
 756    specified by the zone administrator.  There are a lot of details I'd
 757    do differently now (like using a new SOA field instead of overloading
 758    the MINIMUM field), but after more than a decade, I'd be more worried
 759    if we couldn't think of at least a few improvements.
 760
 761 9.2 BIND
 762
 763    While not the first attempt to get negative caching into BIND, in
 764    July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
 765    implemented, validation and negative caching (NCACHE).  This code had
 766    a 10 minute TTL for negative caching and only cached the indication
 767    that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
 768    is the origin of the NODATA pseudo response code mentioned above.
 769
 770    Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
 771    record such that it could be retrieved by a similar query.  UUnet
 772    complained that they were getting old answers after loading a new
 773    zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
 774    In reality this indicated that the named needed to purge the space
 775    the zone would occupy.  Functionality to do this was added in BIND
 776    4.9.3 BETA11 patch2, December 1994.
 777
 778    RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
 779
 780
 781
 782
 783
 784
 785
 786 Andrews                     Standards Track                    [Page 14]
 787 \f
 788 RFC 2308                       DNS NCACHE                     March 1998
 789
 790
 791 10 Example
 792
 793    The following example is based on a signed zone that is empty apart
 794    from the nameservers.  We will query for WWW.XX.EXAMPLE showing
 795    initial response and again 10 minutes later.  Note 1: during the
 796    intervening 10 minutes the NS records for XX.EXAMPLE have expired.
 797    Note 2: the TTL of the SIG records are not explicitly set in the zone
 798    file and are hence the TTL of the RRset they are the signature for.
 799
 800         Zone File:
 801
 802         $TTL 86400
 803         $ORIGIN XX.EXAMPLE.
 804         @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
 805                                 1997102000      ; serial
 806                                 1800    ; refresh (30 mins)
 807                                 900     ; retry (15 mins)
 808                                 604800  ; expire (7 days)
 809                                 1200 ) ; minimum (20 mins)
 810                 IN      SIG     SOA ...
 811           1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
 812                 IN      SIG     NXT ... XX.EXAMPLE. ...
 813            300  IN      NS      NS1.XX.EXAMPLE.
 814            300  IN      NS      NS2.XX.EXAMPLE.
 815                 IN      SIG     NS ... XX.EXAMPLE. ...
 816                 IN      KEY     0x4100 1 1 ...
 817                 IN      SIG     KEY ... XX.EXAMPLE. ...
 818                 IN      SIG     KEY ... EXAMPLE. ...
 819         NS1     IN      A       10.0.0.1
 820                 IN      SIG     A ... XX.EXAMPLE. ...
 821           1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
 822                 IN      SIG     NXT ...
 823         NS2     IN      A       10.0.0.2
 824                 IN      SIG     A ... XX.EXAMPLE. ...
 825           1200  IN      NXT     XX.EXAMPLE. A NXT SIG
 826                 IN      SIG     NXT ... XX.EXAMPLE. ...
 827
 828         Initial Response:
 829
 830         Header:
 831             RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
 832         Query:
 833             WWW.XX.EXAMPLE. IN A
 834         Answer:
 835             <empty>
 836         Authority:
 837             XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
 838             XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
 839
 840
 841
 842 Andrews                     Standards Track                    [Page 15]
 843 \f
 844 RFC 2308                       DNS NCACHE                     March 1998
 845
 846
 847             NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
 848             NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
 849             XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
 850             XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
 851             XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
 852         Additional
 853             XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
 854             XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
 855             NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
 856             NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
 857             NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
 858             NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
 859
 860          After 10 Minutes:
 861
 862          Header:
 863              RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
 864          Query:
 865              WWW.XX.EXAMPLE. IN A
 866          Answer:
 867              <empty>
 868          Authority:
 869              XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
 870              XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
 871              NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
 872              NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
 873              EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
 874              EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
 875              EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
 876          Additional
 877              XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
 878              XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
 879              NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
 880              NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
 881              NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
 882              NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
 883              EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
 884              EXAMPLE.        65799 IN SIG KEY ... . ...
 885
 886
 887 11 Security Considerations
 888
 889    It is believed that this document does not introduce any significant
 890    additional security threats other that those that already exist when
 891    using data from the DNS.
 892
 893
 894
 895
 896
 897
 898 Andrews                     Standards Track                    [Page 16]
 899 \f
 900 RFC 2308                       DNS NCACHE                     March 1998
 901
 902
 903    With negative caching it might be possible to propagate a denial of
 904    service attack by spreading a NXDOMAIN message with a very high TTL.
 905    Without negative caching that would be much harder.  A similar effect
 906    could be achieved previously by spreading a bad A record, so that the
 907    server could not be reached - which is almost the same.  It has the
 908    same effect as far as what the end user is able to do, but with a
 909    different psychological effect.  With the bad A, I feel "damn the
 910    network is broken again" and try again tomorrow.  With the "NXDOMAIN"
 911    I feel "Oh, they've turned off the server and it doesn't exist any
 912    more" and probably never bother trying this server again.
 913
 914    A practical example of this is a SMTP server where this behaviour is
 915    encoded.  With a NXDOMAIN attack the mail message would bounce
 916    immediately, where as with a bad A attack the mail would be queued
 917    and could potentially get through after the attack was suspended.
 918
 919    For such an attack to be successful, the NXDOMAIN indiction must be
 920    injected into a parent server (or a busy caching resolver).  One way
 921    this might be done by the use of a CNAME which results in the parent
 922    server querying an attackers server.  Resolvers that wish to prevent
 923    such attacks can query again the final QNAME ignoring any NS data in
 924    the query responses it has received for this query.
 925
 926    Implementing TTL sanity checking will reduce the effectiveness of
 927    such an attack, because a successful attack would require re-
 928    injection of the bogus data at more frequent intervals.
 929
 930    DNS Security [RFC2065] provides a mechanism to verify whether a
 931    negative response is valid or not, through the use of NXT and SIG
 932    records.  This document supports the use of that mechanism by
 933    promoting the transmission of the relevant security records even in a
 934    non security aware server.
 935
 936 Acknowledgments
 937
 938    I would like to thank Rob Austein for his history of the CHIVES
 939    nameserver. The DNSIND working group, in particular Robert Elz for
 940    his valuable technical and editorial contributions to this document.
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954 Andrews                     Standards Track                    [Page 17]
 955 \f
 956 RFC 2308                       DNS NCACHE                     March 1998
 957
 958
 959 References
 960
 961    [RFC1034]
 962            Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
 963            STD 13, RFC 1034, November 1987.
 964
 965    [RFC1035]
 966            Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
 967            SPECIFICATION," STD 13, RFC 1035, November 1987.
 968
 969    [RFC2065]
 970            Eastlake, D., and C. Kaufman, "Domain Name System Security
 971            Extensions," RFC 2065, January 1997.
 972
 973    [RFC2119]
 974            Bradner, S., "Key words for use in RFCs to Indicate
 975            Requirement Levels," BCP 14, RFC 2119, March 1997.
 976
 977    [RFC2181]
 978            Elz, R., and R. Bush, "Clarifications to the DNS
 979            Specification," RFC 2181, July 1997.
 980
 981 Author's Address
 982
 983    Mark Andrews
 984    CSIRO - Mathematical and Information Sciences
 985    Locked Bag 17
 986    North Ryde NSW 2113
 987    AUSTRALIA
 988
 989    Phone: +61 2 9325 3148
 990    EMail: Mark.Andrews@cmis.csiro.au
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Andrews                     Standards Track                    [Page 18]
1011 \f
1012 RFC 2308                       DNS NCACHE                     March 1998
1013
1014
1015 Full Copyright Statement
1016
1017    Copyright (C) The Internet Society (1998).  All Rights Reserved.
1018
1019    This document and translations of it may be copied and furnished to
1020    others, and derivative works that comment on or otherwise explain it
1021    or assist in its implementation may be prepared, copied, published
1022    and distributed, in whole or in part, without restriction of any
1023    kind, provided that the above copyright notice and this paragraph are
1024    included on all such copies and derivative works.  However, this
1025    document itself may not be modified in any way, such as by removing
1026    the copyright notice or references to the Internet Society or other
1027    Internet organizations, except as needed for the purpose of
1028    developing Internet standards in which case the procedures for
1029    copyrights defined in the Internet Standards process must be
1030    followed, or as required to translate it into languages other than
1031    English.
1032
1033    The limited permissions granted above are perpetual and will not be
1034    revoked by the Internet Society or its successors or assigns.
1035
1036    This document and the information contained herein is provided on an
1037    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1038    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1039    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1040    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1041    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Andrews                     Standards Track                    [Page 19]
1067 \f