RFC 2308
Negative Caching of DNS Queries (DNS NCACHE)
📜 RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) 💅
Okay bestie, come sit with me, because this one is the DNS negative caching spec and it is SO good. 🎀✨ It's from M. Andrews of CSIRO, dated March 1998, and it's a Standards Track doc. 🦋 It updates RFC 1034 and RFC 1035 (so it's basically a glow-up for those two) and it doesn't obsolete anything. 💖 Let's get into it. 🌸
Status of this Memo 🫶
Okay so this part is just the official "here's what this doc is" section. It says this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. 💜 If you want the current standardization state, check the "Internet Official Protocol Standards" (STD 1) doc. The distribution is unlimited, so share it with everyone! 🌈
Copyright Notice 📝
Copyright is held by The Internet Society (1998), and all rights are reserved. 🔒
Abstract 🌷
Okay, so the TEA: [RFC1034] described how to cache negative responses, but it had a big ol' flaw 💀. It didn't let a name server hand those cached negative responses out to other resolvers, which massively hurt how useful the caching was. 😭 This doc fixes that, based on what people learned from using it in the real world, and it replaces [RFC1034 Section 4.3.4]. 🛠️
Negative caching was optional in the DNS spec. It's about caching the non-existence of an RRset [RFC2181] or a domain name. 🧚
Why is it iconic? Because it cuts response time for negative answers and reduces how many messages go between resolvers and name servers, so overall network traffic goes down. 🔥 A huge chunk of DNS traffic could be gone if every resolver did negative caching, so honestly, negative caching should no longer be treated as optional for a DNS resolver. 👑
1 - Terminology 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🎀
Let's define some vibes:
- "Negative caching" is storing knowledge that something does not exist. 🙈 You can store the knowledge that a record has a particular value, and you can also do the reverse and store that a record does not exist. Storing knowledge that something doesn't exist, or can't or doesn't give an answer, is what we call negative caching. 💅
- "QNAME" is the name in the query section of an answer. If it resolves to a CNAME (or a CNAME chain), then the QNAME is the data field of the last CNAME, meaning the one whose value doesn't resolve to yet another CNAME. 🦋 Implementers should know that if you include CNAME records in responses in order, so the first one has the label from the query section and each next one has the label from the data section of the one before it, then the whole sequence can be processed in one pass. That makes life SO much easier for the receiver. 🫶 Other relevant records (like SIG RRs [RFC2065]) can be mixed in among the CNAMEs. ✨
- "NXDOMAIN" is just another way of saying the "Name Error" RCODE from [RFC1035 Section 4.1.1]. Both terms mean the same thing in this doc, so they're used interchangeably. 🌸
- "NODATA" is a pseudo RCODE meaning the name is valid for the given class, but there are no records of the given type. 🧚 There's no actual RCODE for it, so you have to infer a NODATA response from the answer. 🙃
- "FORWARDER" is a nameserver used to resolve queries instead of directly using the authoritative nameserver chain. 🌈 A forwarder usually has better access to the internet, or it keeps a bigger cache that many resolvers can share. ⭐ How a server gets identified as a FORWARDER (or knows it's one) is outside the scope of this doc. However, if you're being used as a forwarder, the query will have the recursion desired flag set. 👑
Reading this doc assumes you already understand [RFC1034], [RFC1035] and [RFC2065]. 📖 Don't skip the homework, bestie. 💀
2 - Negative Responses 🎀
The most common negative responses say that a particular RRset doesn't exist in the DNS, and the first sections of this doc are all about that case. ✨ Other negative responses can mean a nameserver has failed, and those get covered in section 7 (Other Negative Responses). 🙈
A negative response is indicated by one of the following conditions:
2.1 - Name Error 🔥
Name errors (NXDOMAIN) are indicated by "Name Error" in the RCODE field. In this case, the domain referred to by the QNAME does not exist. 😭 Note: the answer section may have SIG and CNAME RRs, and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. 🦋
You can tell a referral apart from an NXDOMAIN response by checking for NXDOMAIN in the RCODE, no matter whether the authority section has NS or SOA records. 💖
NXDOMAIN responses come in four types, based on what's in the authority section. Here they are, along with a referral for comparison. Fields not mentioned don't matter for these examples. 🧚
NXDOMAIN RESPONSE: TYPE 1.
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
NXDOMAIN RESPONSE: TYPE 2.
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
NXDOMAIN RESPONSE: TYPE 3.
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
<empty>
Additional:
<empty>
NXDOMAIN RESPONSE: TYPE 4
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
REFERRAL RESPONSE.
Header:
RDCODE=NOERROR
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3Look at that structure! 😍 In all four NXDOMAIN examples, we know that "AN.EXAMPLE." exists and its value is a CNAME record. 🌟 The NXDOMAIN refers to "TRIPPLE.XX", which is then known NOT to exist. 💀 In the referral example, "AN.EXAMPLE" exists and has a CNAME RR as its value, but we know nothing either way about "TRIPPLE.XX". All we know is that "NS1.XX" or "NS2.XX" can be asked as the next step to find out. 🧚
If there are no CNAME records, the NXDOMAIN response refers to the name in the label of the RR in the question section. 🦋
2.1.1 Special Handling of Name Error 🛠️
This section covers the errors you can run into when implementing negative caching of NXDOMAIN responses. 🙈
There are a LOT of resolvers out there that don't correctly detect and handle every form of NXDOMAIN response. 😭 Some treat a TYPE 1 NXDOMAIN response as a referral. To fix this, it is recommended that servers which are authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN responses, meaning the authority section contains an SOA record and no NS records. 🫶 If a non-authoritative server sends a TYPE 1 NXDOMAIN response to one of these old resolvers, the result is an unnecessary query to an authoritative server. That's undesirable but not fatal, except when the server is being used as a FORWARDER. 💅 If the resolver is using the server as a FORWARDER, then the sending of TYPE 1 NXDOMAIN responses to it has to be disabled, and TYPE 2 NXDOMAIN is used instead. 🔥
Some resolvers incorrectly keep processing if the authoritative answer flag isn't set, loop until the query retry threshold is exceeded, and then return SERVFAIL. 💀 This is a problem when your nameserver is listed as a FORWARDER for those resolvers. If the nameserver is used as a FORWARDER by such a resolver, the authority flag has to be forced on for NXDOMAIN responses to those resolvers. 🌈 In practice, this causes no problems even if it's turned on always, and it has been the default behaviour in BIND from 4.9.3 onwards. ✨
2.2 - No Data 🌸
NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section. 🧚 The authority section will contain an SOA record, or there will be no NS records there. 🎀
NODATA responses have to be worked out algorithmically from the response's contents, because there's no RCODE value that says NODATA. 🙃 In some cases, to be certain that NODATA is the right answer, it can be necessary to send another query. 🔍
The authority section may contain NXT and SIG RRsets in addition to NS and SOA records. 🦋 CNAME and SIG records may exist in the answer section. 💖
You can tell a NODATA response apart from a referral by the presence of an SOA record in the authority section, or by the absence of NS records there. ⭐
NODATA responses come in three types, based on what's in the authority section. Here they are, along with a referral for comparison. Fields not mentioned don't matter for these examples. 🌈
NODATA RESPONSE: TYPE 1.
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
EXAMPLE. NS NS1.XX.
EXAMPLE. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
NO DATA RESPONSE: TYPE 2.
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
NO DATA RESPONSE: TYPE 3.
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
<empty>
Additional:
<empty>
REFERRAL RESPONSE.
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. NS NS1.XX.
EXAMPLE. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3Unlike the NXDOMAIN examples, these have no CNAME records. 🙈 But they could have them, just like the NXDOMAIN examples did. In that case, NODATA would be concluded for the value of the last CNAME (the QNAME). 💅✨
2.2.1 - Special Handling of No Data ✨
okay so there are SO many resolvers out there that don't correctly spot and handle every flavour of NODATA response 😭 some of them even treat a TYPE 1 NODATA response like it's a referral 💀. to help with that, the advice is that servers which are authoritative for the NODATA response should only send TYPE 2 NODATA responses. that means the authority section has an SOA record and no NS records 🎀. if a non-authoritative server sends a TYPE 1 NODATA response to one of those resolvers, it just causes an unnecessary query, so that's a no-go 🙅♀️. and if a server is listed as a FORWARDER for another resolver, it may also be necessary to turn off sending TYPE 1 NODATA responses for non-authoritative NODATA responses 🫶.
some name servers don't set the RCODE to NXDOMAIN when there are CNAMEs in the answer section 🙈. if you need a definitive NXDOMAIN / NODATA answer in that situation, the resolver must query again using the QNAME as the query label 💅.
3 - Negative Answers from Authoritative Servers 💅
name servers that are authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when they're reporting an NXDOMAIN or saying that no data of the requested type exists 🫶. this is required so the response can be cached ✨. the TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and it tells a resolver how long it can cache the negative answer ⏰. the TTL SIG record that goes with the SOA record should also be trimmed in line with the SOA's TTL 🦋.
if the containing zone is signed [RFC2065], the SOA and the appropriate NXT and SIG records MUST be added 🔐.
4 - SOA Minimum Field 🎀
the SOA minimum field has been overloaded over the years and has picked up three different meanings 🥴: the minimum TTL value of all RRs in a zone, the default TTL of RRs that didn't have a TTL value, and the TTL of negative responses 🌸.
the first one, the minimum TTL value of all RRs in a zone, was the original defined meaning, but in practice it has never actually been used, so it's hereby deprecated 🪦.
the second one, the default TTL of RRs which contain no explicit TTL in the master zone file, only matters at the primary server 🧚. after a zone transfer, every RR has an explicit TTL, and there's no way to tell whether a TTL was explicitly set or derived from the default once that's happened 🤷♀️. if a server doesn't require RRs to include the TTL value explicitly, it should provide a mechanism (not the value of the MINIMUM field of the SOA record) that gives it the missing TTL values. exactly how that works is implementation dependent 🛠️.
the Master File format [RFC 1035 Section 5] is extended to include this directive:
$TTL <TTL> [comment]all resource records that show up after the directive, and that don't explicitly include a TTL value, get their TTL set to the TTL given in the $TTL directive 💖. SIG records without an explicit TTL get their TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5] 🌈.
and the remaining meaning, being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field 👑.
5 - Caching Negative Answers 🦋
okay this part is my fave 😍. like normal answers, negative answers have a time to live (TTL) ⏳. but since there's no record in the answer section that the TTL can go on, the TTL has to be carried some other way. that way is including the SOA record from the zone in the authority section of the reply 📜. when the authoritative server creates this record, its TTL is taken from the minimum of the SOA.MINIMUM field and the SOA's TTL. the TTL counts down the same way as a normal cached answer, and when it hits zero (0), the cached negative answer MUST NOT be used again 💀.
a negative answer that came from a name error (NXDOMAIN) should be cached so it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that caused the cached negative response 🧠.
a negative answer that came from a no data error (NODATA) should be cached so it can be retrieved and returned in response to another query for the same <QNAME, QTYPE, QCLASS> that caused the cached negative response 🫧.
if an NXT record is in the authority section of a negative answer you receive, it MUST be stored so it can be located and returned along with the SOA record in the authority section, and the same goes for any SIG records in the authority section 🗂️. for NXDOMAIN answers there's no obvious "necessary" relationship between the NXT records and the QNAME 🤔. for NODATA responses, the NXT record MUST have the same owner name as the query name 🎯.
negative responses without SOA records SHOULD NOT be cached, because there's no way to stop the negative responses from looping forever between a pair of servers, even with a short TTL 🔁.
even though the DNS forms a tree of servers, various misconfigurations can still make a loop in the query graph. for example, two servers listing each other as forwarders, or different lame server configurations 🙃. without a TTL count-down, a cached negative response would have its TTL reset every time the next server received it 😱. that negative indication could then live forever, circulating between the servers involved 🌀.
just like with caching positive responses, it's sensible for a resolver to limit how long it will cache a negative response, since the protocol supports caching for up to 68 years 🕰️. that limit should not be greater than the one applied to positive answers, and it's preferably tunable 🎚️. values of one to three hours have been found to work well and would make a sensible default ✨. values exceeding one day have been found to be problematic 🚩.
6 - Negative answers from the cache 🌸
when a server, while answering a query, runs into a cached negative response, it MUST add the cached SOA record to the authority section of the response, with the TTL decremented by the amount of time it was stored in the cache ⏱️. that's what lets the NXDOMAIN / NODATA response time out correctly ✅.
if an NXT record was cached along with the SOA record, it MUST be added to the authority section 🗝️. if a SIG record was cached along with an NXT record, it SHOULD be added to the authority section 💜.
like with all answers coming from the cache, negative answers SHOULD have an implicit referral built into the answer 🧭. this lets the resolver find an authoritative source. an implicit referral is characterised by NS records in the authority section that point the resolver toward an authoritative source. NXDOMAIN types 1 and 4 responses contain implicit referrals, and so does the NODATA type 1 response 🫶.
7 - Other Negative Responses 🧚
caching of other negative responses isn't covered by any existing RFC 📭. there's no way to indicate a desired TTL in these responses 🙅♀️. you need to be careful to make sure there are no forwarding loops 🔄.
7.1 Server Failure (OPTIONAL) 😭
server failures come in two major classes 💔. the first is where a server can tell that it's been misconfigured for a zone. this might be where it's been listed as a server but isn't configured to be one for the zone, or where it's been configured to be a server for the zone but can't get the zone data for some reason 🛠️. that can happen because the zone file doesn't exist or has errors, or because another server that the zone should have been available from didn't respond, or wasn't able or willing to supply it 🫠.
the second class is where the server needs to get an answer from somewhere else but can't, because of network failures, other servers that don't reply, servers that return server failure errors, or something similar 📡.
either way, a resolver MAY cache a server failure response. if it does, it MUST NOT cache it for longer than five (5) minutes, and it MUST be cached against the specific query tuple <query name, type, class, server IP address> 🎀.
7.2 Dead / Unreachable Server (OPTIONAL) 💀
dead / unreachable servers are servers that fail to respond in any way to a query, or where the transport layer has indicated that the server doesn't exist or is unreachable 🪦. a server may be considered dead or unreachable if it hasn't responded to an outstanding query within 120 seconds ⏲️.
examples of transport layer indications are:
- ICMP error messages indicating host, net or port unreachable.
- TCP resets
- IP stack error messages providing similar indications to those above.
a server MAY cache a dead server indication 🧊. if it does, it MUST NOT be deemed dead for longer than five (5) minutes 🌷. the indication MUST be stored against the query tuple <query name, type, class, server IP address>, unless there was a transport layer indication that the server doesn't exist. in that case, it applies to all queries to that specific IP address 💌.
8 - Changes from RFC 1034 👑
negative caching in resolvers is no-longer optional. if a resolver caches anything, it must also cache negative answers 🫧.
non-authoritative negative answers MAY be cached 🌈.
the SOA record from the authority section MUST be cached 🍓. name error indications must be cached against the tuple <query name, QCLASS>. no data indications must be cached against the <query name, QTYPE, QCLASS> tuple 🗃️.
a cached SOA record must be added to the response. this was explicitly not allowed before, because the distinction between a normal cached SOA record and the SOA cached as a result of a negative response wasn't made. simply pulling a normal cached SOA and adding it to a cached negative response caused problems 🙈.
the $TTL TTL directive was added to the master file format 🎉.
9. History of Negative Caching ✨
okay so this section is a potted history 🍓 (the RFC literally says it's not part of the technical spec, so this is just the tea ☕). the big plot twist is that the same concepts got reinvented in both CHIVES and BIND, which is so iconic of networking honestly 🫶
9.1. CHIVES 🎀
bestie, the early CHIVES story was shared by Rob Austein <sra@epilogue.com>, and it's reproduced here the way he gave it to them [MPA] 💜
sometime around spring 1985, he mentioned to Paul Mockapetris that their experience with his JEEVES DNS resolver showed they needed some kind of negative caching scheme. Paul suggested just caching authoritative errors, using the SOA MINIMUM value for the zone that would have contained the target RRs. ngl this conversation was before RFC-973 was written, but it's unclear whether Paul came up with the idea on the spot or had already been planning to put it in RFC-973. either way, neither of them was totally sure SOA MINIMUM was the right metric 🤔 but it was available and under the control of the target zone's administrator, and both of those felt like really important features at the time 🦋
late in 1987, the initial beta-test version of CHIVES dropped 💖 CHIVES was the DNS resolver he wrote to replace Paul's JEEVES resolver. it had a search path mechanism that got used pretty heavily at several sites (his own included), so CHIVES also had a negative caching mechanism based on SOA MINIMUM values. the basic strategy was to cache authoritative error codes keyed by the exact query parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the SOA MINIMUM value. CHIVES didn't try to track down SOA RRs if they weren't in the authoritative response, so it never fully got rid of the gratuitous DNS error message traffic, but it helped a LOT 🙈
this was happening at the same time as the near-collapse of the ARPANET, caused by exponential growth and the "old" (pre-VJ) TCP retransmission algorithm. so negative caching gave way better DNS response times for their users, mailer daemons, etc. 🔥
as far as he knows, CHIVES was the first resolver to implement negative caching 👑 it was built during the twilight years of TOPS-20, so it didn't run on very many machines. the ones it did run on were too critical to shut down quickly, no matter how much it cost to keep them going, so the few users they had drove CHIVES pretty hard 💀 a few interesting bits of DNS tech came out of that, but the one that matters here is the MAXTTL configuration parameter 🌈
okay so the MAXTTL story: experience with JEEVES had already shown that RRs often showed up with ridiculously long TTLs. 99999999 was especially popular for many years, because of bugs in the code and docs of several early versions of BIND 😭 robust software that blindly believed those TTLs could create so many strange failures that people often had to reboot the resolver just to clear the garbage out of the cache. so CHIVES got a configuration parameter called "MAXTTL", which specified the maximum "reasonable" TTL in a received RR. RRs with TTLs greater than MAXTTL would either have their TTLs reduced to MAXTTL or be discarded entirely, depending on the setting of another configuration parameter 🧚
once they started getting field experience with CHIVES's negative caching code, it became clear that SOA MINIMUM was often large enough to cause the same kinds of problems for negative caching that huge TTLs caused for normal caching. (this was partly due to a bug in several early versions of BIND, where a secondary server would authoritatively deny all knowledge of its zones if it couldn't reach the primaries on reboot 🙃) so they started running the negative cache TTLs through the MAXTTL check too, and kept experimenting 🧪
the setup that seemed to work best was on WSMR-SIMTEL20.ARMY.MIL. it was the last of the major Internet TOPS-20 machines to be shut down, which made it the last major CHIVES user and the place with the longest experimental baseline 🏆 most of SIMTEL20's traffic in its last years was mail-related, and the mail queue timeout was set to one week. setting MAXTTL to about three days gave a "stuck" message several tries at complete DNS resolution without bogging the system down with a bunch of useless queries 💌 since (for reasons that now escape him) they only had the single MAXTTL parameter instead of separate ones for positive and negative caching, it's not clear how much that setting affected the negative caching code 🤷♀️
CHIVES also had a second, kind of controversial mechanism that took the place of negative caching in some cases 🦄 the CHIVES resolver daemon could be configured to load DNS master files, which let it act as what today would be called a "stealth secondary". when set up this way, the resolver had direct access to authoritative info for heavily used zones. the search path mechanisms reflected this: there were actually two separate search paths. one only searched local authoritative zone data, and the other could generate normal iterative queries. this cut down on the need for negative caching when usage was predictably heavy. for example, the resolver on XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and AI.MIT.EDU and put both suffixes into the "local" search path, since the hosts in those two zones accounted for most of the DNS traffic 🌸 not every site chose this feature, though. C.CS.CMU.EDU used the "remote" search path for everything, because there were too many sub-zones at CMU for zone shadowing to be practical. so they relied pretty heavily on negative caching, even for local traffic 🫠
overall, he still thinks the basic design for negative caching was pretty reasonable. the zone administrator specified how long to cache negative answers, and the resolver configuration picked the actual cache time from the range between zero and the period the zone administrator specified 💜 there are lots of details he'd do differently now (like using a new SOA field instead of overloading the MINIMUM field). but after more than a decade, he'd be more worried if they couldn't think of at least a few improvements 💅
9.2. BIND 💅
while it wasn't the first attempt to get negative caching into BIND, in July 1993, BIND 4.9.2 ALPHA happened 🎉 Anant Kumar of ISI supplied code that implemented validation and negative caching (NCACHE). this code had a 10 minute TTL for negative caching, and it only cached the indication that there was a negative response, either NXDOMAIN or NOERROR_NODATA. this is the origin of the NODATA pseudo response code mentioned above 🍓
then Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA record so it could be retrieved by a similar query. UUnet complained that they were getting old answers after loading a new zone, so the option got turned off in BIND 4.9.3-alpha5, April 1994 😬 really, this meant that named needed to purge the space the zone would occupy. functionality to do that was added in BIND 4.9.3 BETA11 patch2, December 1994 🧹
RETURNSOA got re-enabled by default in BIND 4.9.5-T1A, August 1996 🎀
10. Example 🧚
okay the example is based on a signed zone that's basically empty apart from the nameservers 🫶 we're going to query for WWW.XX.EXAMPLE, showing the initial response and then again 10 minutes later. two things to watch for 👀 Note 1: during those 10 minutes, the NS records for XX.EXAMPLE have expired. Note 2: the TTL of the SIG records isn't explicitly set in the zone file, so they're hence the TTL of the RRset they're the signature for ✨
Zone File:
$TTL 86400
$ORIGIN XX.EXAMPLE.
@ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
1997102000 ; serial
1800 ; refresh (30 mins)
900 ; retry (15 mins)
604800 ; expire (7 days)
1200 ) ; minimum (20 mins)
IN SIG SOA ...
1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
IN SIG NXT ... XX.EXAMPLE. ...
300 IN NS NS1.XX.EXAMPLE.
300 IN NS NS2.XX.EXAMPLE.
IN SIG NS ... XX.EXAMPLE. ...
IN KEY 0x4100 1 1 ...
IN SIG KEY ... XX.EXAMPLE. ...
IN SIG KEY ... EXAMPLE. ...
NS1 IN A 10.0.0.1
IN SIG A ... XX.EXAMPLE. ...
1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG
IN SIG NXT ...
NS2 IN A 10.0.0.2
IN SIG A ... XX.EXAMPLE. ...
1200 IN NXT XX.EXAMPLE. A NXT SIG
IN SIG NXT ... XX.EXAMPLE. ...Initial Response:
Header:
RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
Query:
WWW.XX.EXAMPLE. IN A
Answer:
<empty>
Authority:
XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ...
XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ...
NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ...
XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE.
XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE.
XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ...
Additional
XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ...
XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ...
NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1
NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2
NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...After 10 Minutes:
Header:
RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
Query:
WWW.XX.EXAMPLE. IN A
Answer:
<empty>
Authority:
XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ...
XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ...
NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG
NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ...
EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE.
EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE.
EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ...
Additional
XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ...
XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ...
NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1
NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2
NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
EXAMPLE. 65799 IN KEY 0x4100 1 1 ...
EXAMPLE. 65799 IN SIG KEY ... . ...11. Security Considerations ✨
Okay so the big headline first: this document isn't believed to add any significant new security threats beyond the ones you already get when you use data from the DNS 🔐. The risks were already there, bestie 💅.
But the NXDOMAIN situation is a whole plot 👀. With negative caching, it might be possible to spread a denial of service attack by propagating an NXDOMAIN message with a very high TTL. Without negative caching, that would be way harder to pull off 💀.
A similar effect could already happen by spreading a bad A record, so the server can't be reached. That's almost the same thing. For the end user it has the same effect on what they can do, but the vibes are different 🙈. With the bad A record, the user thinks "damn the network is broken again" and tries again tomorrow. With the NXDOMAIN, they think "Oh, they've turned off the server and it doesn't exist any more" and probably never bother trying that server again 😭.
A practical example is an SMTP server where this behaviour is encoded 📬. With an NXDOMAIN attack, the mail bounces immediately. With a bad A record attack, the mail gets queued and could potentially get through after the attack is suspended. Iykyk, it's a whole different experience.
For an attack like this to work, the NXDOMAIN has to be injected into a parent server (or a busy caching resolver) 🎯. One way this might happen is with a CNAME that makes the parent server query an attacker's server 🕵️. Resolvers that want to prevent this kind of attack can query the final QNAME again, ignoring any NS data in the responses they've received for that query 🛡️.
Implementing TTL sanity checking will make this attack less effective 🧠. A successful attack would need the bogus data to be re-injected at more frequent intervals, and that's a lot more work for the attacker.
DNS Security [RFC2065] provides a mechanism to verify whether a negative response is valid or not, using NXT and SIG records 🔑. This document supports that mechanism by encouraging the transmission of the relevant security records, even from a server that isn't security aware 🫶.
Acknowledgments 🫶
I'd like to thank Rob Austein for his history of the CHIVES nameserver 🌸. Big thanks to the DNSIND working group, especially Robert Elz, for his valuable technical and editorial contributions to this document 💜.
References 📚
- [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES," STD 13, RFC 1034, November 1987.
- [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," STD 13, RFC 1035, November 1987.
- [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions," RFC 2065, January 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
- [RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS Specification," RFC 2181, July 1997.
Author's Address 💌
Mark Andrews
CSIRO - Mathematical and Information Sciences
Locked Bag 17
North Ryde NSW 2113
AUSTRALIA
Phone: +61 2 9325 3148
EMail: Mark.Andrews@cmis.csiro.auFull Copyright Statement ⚖️
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
📦 where this page comes from
- ietf: rfc2308 1998-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms