Authenticated Denial of Existence in the DNSGooglemiek@google.comNLnet LabsScience Park 400Amsterdam1098 XHNLmatthijs@nlnetlabs.nlhttp://www.nlnetlabs.nl/
Internet
DNSSECDenial of ExistanceNSECNSEC3Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists, but does not have the specific RR type you were asking for. When returning a negative DNSSEC response, a name server usually includes up to two NSEC records. With NSEC3 this amount is three. This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial of existence responses DNSSEC can be somewhat of a complicated matter, and there are certain areas of the specification that are more difficult to comprehend than others. One such area is "authenticated denial of existence". Denial of existence is a mechanism that informs a resolver that a certain domain name does not exist. It is also used to signal that a domain name exists, but does not have the specific RR type you were asking for. The first is referred to as an NXDOMAIN (non-existent domain) ( Section 2.1) and the latter a NODATA ( Section 2.2) response. Both are also known as negative responses. Authenticated denial of existence uses cryptography to sign the negative response. However, if there is no answer, what is it that needs to be signed? To further complicate this matter, there is the desire to pre-generate negative responses that are applicable for all queries for non-existent names in the signed zone. See for the details. In this document, we will explain how authenticated denial of existence works. We begin by explaining the current technique in the DNS and work our way up to DNSSEC. We explain the first steps taken in DNSSEC and describe how NSEC and NSEC3 work. The NXT, NO, NSEC2 and DNSNR records also briefly make their appearance, as they have paved the way for NSEC and NSEC3. To complete the picture, we also need to explain DNS wildcards as these complicate matters, especially combined with CNAME records. Note: In this document, domain names in zone file examples will have a trailing dot, in the running text they will not. This text is written for people who have a fair understanding of DNSSEC. The following RFCs are not required reading, but they help in understanding the problem space. RFC 5155 - Hashed Authenticated Denial of Existence; RFC 4592 - The Role of Wildcards in the DNS. And these provide some general DNSSEC information. RFC 4033, RFC 4034, RFC 4035 , , - DNSSEC Specification; RFC 4956 - DNS Security (DNSSEC) Opt-In. This RFC has experimental status, but is a good read. These three drafts give some background information on the NSEC3 development. The NO record ; The NSEC2 record ; The DNSNR record . We start with the basics and take a look at NXDOMAIN handling in the DNS. To make it more visible we are going to use a small DNS zone, with 3 names (example.org, a.example.org and d.example.org) and 3 types (SOA, A and TXT). For brevity, the class is not shown (defaults to IN) and the SOA record is shortened, resulting in the following zone file: If a resolver asks for the TXT type belonging to a.example.org to the name server serving this zone, it sends the following question: a.example.org TXTThe name server looks in its zone data and generates an answer. In this case a positive one: "Yes it exists and this is the data", resulting in this reply: The status: NOERROR signals that everything is OK, id is an integer used to match questions and answers. In the ANSWER section, we find our answer. The AUTHORITY section holds the names of the name servers that have information concerning the example.org zone. Note that including this information is optional. If a resolver asks for b.example.org TXT it gets an answer that this name does not exist: In this case, we do not get an ANSWER section and the status is set to NXDOMAIN. From this the resolver concludes that b.example.org does not exist. The AUTHORITY section holds the SOA record of example.org that the resolver can use to cache the negative response. It is important to realize that NXDOMAIN is not the only type of does-not-exist. A name may exist, but the type you are asking for may not. This occurrence of non-existence is called a NODATA response. Let us ask our name server for a.example.org AAAA, and look at the answer: The status NOERROR shows that the a.example.org name exists, but the reply does not contain an ANSWER section. This differentiates a NODATA response from an NXDOMAIN response, the rest of the packet is very similar. The resolver has to put these pieces of information together and conclude that a.example.org exists, but it does not have an AAAA record. The above has to be translated to the security aware world of DNSSEC. But there are a few principles DNSSEC brings to the table: A name server is free to compute the answer and signature(s) on-the-fly, but the protocol is written with a "first sign, then load" attitude in mind. It is rather asymmetrical, but a lot of the design in DNSSEC stems from fact that you need to accommodate authenticated denial of existence. If the DNS did not have NXDOMAIN, DNSSEC would be a lot simpler, but a lot less useful! The DNS packet header is not signed. This means that a status: NXDOMAIN can not be trusted. In fact the entire header may be forged, including the AD bit (AD stands for Authentic Data, see RFC 3655 ), which may give some food for thought; DNS wildcards and CNAME records complicate matters significantly. More about this in later sections ( and ). The first principle implies that all denial of existence answers need to be pre-computed, but it is impossible to pre-compute (all conceivable) non-existence answers. A generic denial record which can be used in all denial of existence proofs is not an option: such a record is susceptible to replay attacks. When you are querying a name server for any record that actually exists, a man-in-the-middle could replay that generic denial record that is unlimited in its scope and it would be impossible to tell whether the response was genuine or spoofed. In other words, the generic record can be replayed to falsely deny all possible responses. We could also use the QNAME in the answer and sign that; essentially signing an NXDOMAIN response. While this approach could have worked technically, it is incompatible with off-line signing. The way this has been solved is by introducing a record that defines an interval between two existing names. Or to put it another way: it defines the holes (non-existing names) in the zone. This record can be signed beforehand and given to the resolver. and describe on-line signing techniques that are compatible with this scheme. Given all these troubles, why didn't the designers of DNSSEC go for the (easy) route and allowed for on-line signing? Well, at that time (pre 2000), on-line signing was not feasible with the then current hardware. Keep in mind that the larger servers get between 2000 and 6000 queries per second (qps), with peaks up to 20,000 qps or more. Scaling signature generation to these kind of levels is always a challenge. Another issue was (and is) key management, for on-line signing to work each authoritative name server needs access to the private key(s). This is considered a security risk. Hence, the protocol required not to rely on on-line signing. The road to the current solution (NSEC/NSEC3) was long. It started with the NXT (next) record. The NO (not existing) record was introduced, but never made it to RFC. Later on, NXT was superseded by the NSEC (next secure) record. From there it went through NSEC2/DNSNR to finally reach NSEC3 (next secure, version 3) in RFC 5155. The first attempt to specify authenticated denial of existence was NXT (RFC 2535 ). Section 5.1 of that RFC introduces the record: "The NXT resource record is used to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and to indicate what RR types are present for an existing name." By specifying what you do have, you implicitly tell what you don't have. NXT is superseded by NSEC. In the next section we explain how NSEC (and thus NXT) works. In RFC 3755 all the DNSSEC types were given new names, SIG was renamed RRSIG, KEY became DNSKEY and NXT was renamed to NSEC and a minor issue was fixed in the process, namely the type bitmap was redefined to allow more than 127 types to be listed (, Section 5.2). Just as NXT, NSEC is used to describe an interval between names: it indirectly tells a resolver which names do not exist in a zone. For this to work, we need our example.org zone to be sorted in canonical order (, Section 6.1), and then create the NSECs. We add three NSEC records, one for each name, and each one covers a certain interval. The last NSEC record points back to the first as required by the RFC, and depicted in . The first NSEC covers the interval between example.org and a.example.org; The second NSEC covers a.example.org to d.example.org; The third NSEC points back to example.org, and covers d.example.org to example.org (i.e. the end of the zone). As we have defined the intervals and put those in resource records, we now have something that can be signed. This signed zone is loaded into the name server. It looks like this: If a DNSSEC aware resolver asks for b.example.org, it gets back a status: NXDOMAIN packet, which by itself is meaningless (remember that the DNS packet header is not signed and thus can be forged). To be able to securely detect that b does not exist, there must also be a signed NSEC record which covers the name space where b lives. The record: does precisely that: b should come after a, but the next owner name is d.example.org, so b does not exist. Only by making that calculation, is a resolver able to conclude that the name b does not exist. If the signature of the NSEC record is valid, b is proven not to exist. We have authenticated denial of existence. Note that a man-in-the-middle may still replay this NXDOMAIN response when you're querying for, say, c.example.org. But it would not do any harm since it is provably the proper response to the query. NSEC records are also used in NODATA responses. In that case we need to look more closely at the type bitmap. The type bitmap in an NSEC record tells which types are defined for a name. If we look at the NSEC record of a.example.org, we see the following types in the bitmap: A, TXT, NSEC and RRSIG. So for the name a this indicates we must have an A, TXT, NSEC and RRSIG record in the zone. With the type bitmap of the NSEC record, a resolver can establish that a name is there, but the type is not. For example, if a resolver asks for a.example.org AAAA, the reply that comes back is: The resolver should check the AUTHORITY section and conclude that: a.example.org exists (because of the NSEC with that owner name) and; the type (AAAA) does not as it is not listed in the type bitmap. The techniques used by NSEC form the basics of authenticated denial of existence in DNSSEC. There were two issues with NSEC (and NXT). The first is that it allows for zone walking. NSEC records point from one name to another, in our example: example.org, points to a.example.org which points to d.example.org which points back to example.org. So we can reconstruct the entire example.org zone, thus defeating attempts to administratively block zone transfers ( Section 5.5). The second issue is that when a large, delegation-centric (, Section 1.1), zone deploys DNSSEC, every name in the zone gets an NSEC plus RRSIG. So this leads to a huge increase in the zone size (when signed). This would in turn mean that operators of such zones who are deploying DNSSEC, face up front costs. This could hinder DNSSEC adoption. These two issues eventually lead to NSEC3 which: Adds a way to garble the owner names, thus thwarting zone walking; Makes it possible to skip names for the next owner name. This feature is called Opt-Out (See ). It means not all names in your zone get an NSEC3 plus ditto signature, making it possible to "grow into" your DNSSEC deployment. Note that there are other ways to mitigate against zone walking. RFC 4470 [(#RFC4470) prevents zone walking by introducing minimally covering NSEC records. This technique is described in . Before we delve into NSEC3, let us first take a look at its predecessors: NO, NSEC2, and DNSNR. Long before NSEC was defined, the NO record was introduced. It was the first record to use the idea of hashed owner names, to fix the issue of zone walking that was present with the NXT record. It also fixed the type bitmap issue of the NXT record, but not in a space efficient way. At that time (around 2000) zone walking was not considered important enough to warrant the new record. People were also worried that DNSSEC deployment would be hindered by developing an alternate means of denial of existence. Thus the effort was shelved and NXT remained. When the new DNSSEC specification was written, people were still not convinced that zone walking was a problem that should be solved. So NSEC saw the light and inherited the two issues from NXT. Several years after, NSEC2 was introduced as a way to solve the two issues of NSEC. The NSEC2 draft contains the following paragraph: "This document proposes an alternate scheme which hides owner names while permitting authenticated denial of existence of non-existent names. The scheme uses two new RR types: NSEC2 and EXIST." When an authenticated denial of existence scheme starts to talk about EXIST records, it is worth paying extra attention. The EXIST record was defined as a record without RDATA that would be used to signal the presence of a domain name. From the draft: "In order to prove the nonexistence of a record that might be covered by a wildcard, it is necessary to prove the existence of its closest encloser. This record does that. Its owner is the closest encloser. It has no RDATA. If there is another RR that proves the existence of the closest encloser, this SHOULD be used instead of an EXIST record." The introduction of this record led to questions on what wildcards actually mean (especially in the context of DNSSEC). It is probably not a coincidence that "The Role of Wildcards in the Domain Name System" () was standardized before NSEC3 was. NSEC2 solved the zone walking issue by hashing (with SHA1 and a salt) the "next owner name" in the record, thereby making it useless for zone walking. But it did not have Opt-Out. The DNSNR record was another attempt that used hashed names to foil zone walking and it also introduced the concept of opting out (called "Authoritative Only Flag") which limited the use of DNSNR in delegation-centric zones. All these proposals didn't make it, but did provide valuable insights. To summarize: The NO record introduced hashing, but this idea lingered in the background for a long time; The NSEC2 record made it clear that wildcards were not completely understood; The DNSNR record used a new flag field in the RDATA to signal Opt-Out; From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. It incorporates both Opt-Out and the hashing of names. NSEC3 solves any issues people might have with NSEC, but it introduces some additional complexity. NSEC3 did not supersede NSEC, they are both defined for DNSSEC. So DNSSEC is blessed with two different means to perform authenticated denial of existence: NSEC and NSEC3. In NSEC3 every name is hashed, including the owner name. This means that NSEC3 chain is sorted in hash order, instead of canonical order. Because the owner names are hashed, the next owner name for example.org is unlikely to be a.example.org. Because the next owner name is hashed, zone walking becomes more difficult. To make it even more difficult to retrieve the original names, the hashing can be repeated several times each time taking the previous hash as input. To prevent the reuse of pre-generated hash values between zones a (per zone) salt can also be added. In the NSEC3 for example.org we have hashed the names thrice (, Section 5) and use the salt DEAD. Lets look at typical NSEC3 record: On the first line we see the hashed owner name: 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org, this is the hashed name of the fully qualified domain name (FQDN) example.org encoded as Base32 (). Note that even though we hashed example.org, the zone's name is added to make it look like a domain name again. In our zone, the basic format is Base32(SHA1(FQDN)).example.org. The next hashed owner name A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 (line 2) is the hashed version of d.example.org, represented as Base32. Note that d.example.org is used are the next owner name, because in the hash ordering, its hash comes after the hash of the zone's apex. Also note that .example.org is not added to the next hashed owner name, as this name always falls in the current zone. The "1 0 2 DEAD" section of the NSEC3 states: Hash Algorithm = 1 (SHA1, this is the default, no other hash algorithms are currently defined for use in NSEC3); Opt-Out = 0 (disabled); Hash Iterations = 2, this yields three iterations, as a zero value is already one iteration; Salt = "DEAD". At the end we see the type bitmap, which is identical to NSEC's bitmap, that lists the types present at the original owner name. Note that the type NSEC3 is absent from the list in the example above. This is due to the fact that the original owner name (example.org) does not have the NSEC3 type. It only exists for the hashed name. Names like 1.h.example.org hash to one label in NSEC3, 1.h.example.org becomes: 117gercprcjgg8j04ev1ndrk8d1jt14k.example.org when used as an owner name. This is an important observation. By hashing the names you lose the depth of a zone - hashing introduces a flat space of names, as opposed to NSEC. The name used above (1.h.example.org) creates an empty non-terminal. Empty non-terminals are domain names that have no RRs associated with them, and exist only because they have one or more sub-domains that do (, Section 1.3). The record: creates two names: 1.h.example.org that has the type: TXT; h.example.org which has no types. This is the empty non-terminal. An empty non-terminal will get an NSEC3 record, but not an NSEC record. In is shown how the resolver uses these NSEC3 records to validate the denial of existence proofs. Note that NSEC3 might not always be useful. For example, highly structures zones, like the reverse zones ip6.arpa and in-addr.arpa, can be walked even with NSEC3 due to their structure. Also the names in small, trivial zones can be easily guessed. In these cases, it does not help to defend against zone walking, but does add the computational load on authoritative servers and validators. Hashing mitigates the zone walking issue of NSEC. The other issue, the high costs of securing a delegation to an insecure zone, is tackled with Opt-Out. When using Opt-Out, names that are an insecure delegation (and empty non-terminals that are only derived from insecure delegations) don't require an NSEC3 record. For each insecure delegation, the zone size can be decreased (compared with a fully signed zone without using Opt-Out) with at least two records: one NSEC3 record and one corresponding RRSIG record. If the insecure delegation would introduce empty non-terminals, even more records can be omitted from the zone. Opt-Out NSEC3 records are not able to prove or deny the existence of the insecure delegations. In other words, those delegation do not benefit from the cryptographic security that DNSSEC provides. A recently discovered corner case () shows that not only those delegations remain insecure, also the empty non-terminal space that is derived from those delegations are insecure. Because the names in this empty non-terminal space do exist according to the definition in , the server should respond to queries for these names with a NODATA response. However, the validator requires an NSEC3 record proving the NODATA response (, Section 8.5): "The validator MUST verify that an NSEC3 RR that matches QNAME is present and that both the QTYPE and the CNAME type are not set in its Type Bit Maps field." A way to resolve this contradiction in the specification is to always provide empty non-terminals with an NSEC3 record, even if it is only derived from an insecure delegation. Whenever an authoritative server receives a query for a non-existing record, it has to hash the incoming query name to determine into which interval between two existing hashes it falls. To do that it needs to know the zone's specific NSEC3 parameters (hash iterations and salt). One way to learn them is to scan the zone during loading for NSEC3 records and glean the NSEC3 parameters from them. However, it would need to make sure that there is at least one complete set of NSEC3 records for the zone using the same parameters. Therefore, it would need to inspect all NSEC3 records. A more graceful solution was designed. The solution was to create a new record, NSEC3PARAM, which must be placed at the apex of the zone. Its role is to provide a fixed place where an authoritative name server can directly see the NSEC3 parameters used, and by putting it in the zone it allows for easy transfer to the secondaries. If NSEC3 were designed in the early days of DNS (+/- 1984) this information would probably have been put in the SOA record. So far, we have only talked about denial of existence in negative responses. However, denial of existence may also occur in positive responses, i.e., where the ANSWER section of the response is not empty. This can happen because of wildcards. Wildcards have been part of the DNS since the first DNS RFCs. They allow to define all names for a certain type in one go. In our example.org zone we could for instance add a wildcard record: For completeness, our (unsigned) zone now looks like this: If a resolver asks for z.example.org TXT, the name server will respond with an expanded wildcard, instead of an NXDOMAIN: Note however that the resolver can not detect that this answer came from a wildcard. It just sees the answer as-is. How will this answer look with DNSSEC? The RRSIG of the z.example.org TXT record indicates there is a wildcard configured. The RDATA of the signature lists a label count , Section 3.1.3., of two (not visible in the answer above), but the owner name of the signature has three labels. This mismatch indicates there is a wildcard *.example.org configured. An astute reader may notice that it appears as if a z.example.org RRSIG(TXT) is created out of thin air. This is not the case. The signature for z.example.org does not exist. The signature you are seeing is the one for *.example.org which does exist, only the owner name is switched to z.example.org. So even with wildcards, no signatures have to be created on the fly. The DNSSEC standard mandates that an NSEC (or NSEC3) is included in such responses. If it wasn't, an attacker could mount a replay attack and poison the cache with false data: Suppose that the resolver has asked for a.example.org TXT. An attacker could modify the packet in such way that it looks like the response was generated through wildcard expansion, even though there exists a record for a.example.org TXT. The tweaking simply consists of adjusting the ANSWER section to: Note the subtle difference from in the owner name. In this response we see a a.example.org TXT record, for which a record with different RDATA (See ) exist in the zone. Which would be a perfectly valid answer if we would not require the inclusion of an NSEC or NSEC3 record in the wildcard answer response. The resolver believes that a.example.org TXT is a wildcard record, and the real record is obscured. This is bad and defeats all the security DNSSEC can deliver. Because of this, the NSEC or NSEC3 must be present. Another way of putting this is that DNSSEC is there to ensure the name server has followed the steps as outlined in , Section 4.3.2 for looking up names in the zone. It explicitly lists wildcard look up as one of these steps (3c), so with DNSSEC this must be communicated to the resolver: hence the NSEC(3) record. So far, the maximum number of NSEC records a response will have is two: one for the denial of existence and another for the wildcard. We say maximum, because sometimes a single NSEC can prove both. With NSEC3, this is three (as to why, we will explain in the next section). When we take CNAME wildcard records into account, we can have more NSEC(3) records. For every wildcard expansion, we need to prove that the expansion was allowed. Lets add some CNAME wildcard records to our zone: A query for w.example.org A will result in the following response: The NSEC record *.a.example.org proves that wildcard expansion to w.a.example.org was appropriate: w.a. falls in the gap *.a to *.b. Similar, the NSEC record *.b.example.org proves that there was no direct match for w.b.example.org and *.c.example.org denies the direct match for w.c.example.org. DNAME records and wildcard names should not be used as reiterated in Section 3.3. We can have one or more NSEC3 records that deny the existence of the requested name and one NSEC3 record that deny wildcard synthesis. What do we miss? The short answer is that, due to the hashing in NSEC3 you loose the depth of your zone: Everything is hashed into a flat plane. To make up for this loss of information you need an extra record. To understand NSEC3, we will need two definitions: Introduced in , "The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name (consecutively, counting from the root label downward)." In our example, if the query name is x.2.example.org then example.org is the closest encloser; Introduced in the NSEC3 RFC, this is the closest encloser with one more label added to the left. So if example.org is the closest encloser for the query name x.2.example.org, 2.example.org is the next closer name. An NSEC3 closest encloser proof consists of: An NSEC3 record that matches the closest encloser. This means the unhashed owner name of the record is the closest encloser. This bit of information tells a resolver: "The name you are asking for does not exist, the closest I have is this". An NSEC3 record that covers the next closer name. This means it defines an interval in which the next closer name falls. This tells the resolver: "The next closer name falls in this interval, and therefore the name in your question does not exist. In fact, the closest encloser is indeed the closest I have". These two records already deny the existence of the requested name, so we do not need an NSEC3 record that covers the actual queried name: By denying the existence of the next closer name, you also deny the existence of the queried name. Note that with NSEC, the existence of all empty non-terminals between the two names are denied, hence implicitly contains the closest encloser. For a given query name, there is one (and only one) place where wildcard expansion is possible. This is the source of synthesis, and is defined (, Section 2.1.1 and Section 3.3.1) as: In other words, to deny wildcard synthesis, the resolver needs to know the hash of the source of synthesis. Since it does not know beforehand what the closest encloser of the query name is, it must be provided in the answer. Take the following example. We take our zone, and put two TXT records to it. The records added are 1.h.example.org and 3.3.example.org. It is signed with NSEC3, resulting in the following unsigned zone. The resolver asks the following: x.2.example.org TXT. This leads to an NXDOMAIN response from the server, which contains three NSEC3 records. A list of hashed owner names can be found in . Also see the numbers in that figure correspond with the following NSEC3 records: If we would follow the NSEC approach, the resolver is only interested in one thing. Does the hash of x.2.example.org fall in any of the intervals of the NSEC3 records it got? The hash of x.2.example.org is ndtu6dste50pr4a1f2qvr1v31g00i2i1. Checking this hash on the first NSEC3 yields that it does not fall in between the interval: 15bg9l6359f5ch23e34ddua6n1rihl9h and 1avvqn74sg75ukfvf25dgcethgq638ek. For the second NSEC3 the answer is also negative: the hash sorts outside the interval described by 1avvqn74sg75ukfvf25dgcethgq638ek and 75b9id679qqov6ldfhd8ocshsssb6jvq. And the third NSEC3, with interval 75b9id679qqov6ldfhd8ocshsssb6jvq to 8555t7qegau7pjtksnbchg4td2m0jnpj also isn't of any help. What is a resolver to do? It has been given the maximum amount of NSEC3s and they all seem useless. So this is where the closest encloser proof comes into play. And for the proof to work, the resolver needs to know what the closest encloser is. There must be an existing ancestor in the zone: a name must exist that is shorter than the query name. The resolver keeps hashing increasingly shorter names from the query name until an owner name of an NSEC3 matches. This owner name is the closest encloser. When the resolver has found the closest encloser, the next step is to construct the next closer name. This is the closest encloser with the last chopped label from query name pre-pended to it: "<last chopped label>.<closest encloser>". The hash of this name should be covered by the interval set in any of the NSEC3 records. Then the resolver needs to check the presence of a wildcard. It creates the wildcard name by pre-pending the asterisk label to the closest encloser: "*.<closest encloser>", and uses the hash of that. Going back to our example, the resolver must first detect the NSEC3 that matches the closest encloser. It does this by chopping up the query name, hashing each instance (with the same number of iterations and hash as the zone it is querying) and comparing that to the answers given. So it has the following hashes to work with: ndtu6dste50pr4a1f2qvr1v31g00i2i1, last chopped label: "<empty>"; 7t70drg4ekc28v93q7gnbleopa7vlp6q, last chopped label: "x"; 15bg9l6359f5ch23e34ddua6n1rihl9h, last chopped label: "2"; Of these hashes only one matches the owner name of one of the NSEC3 records: 15bg9l6359f5ch23e34ddua6n1rihl9h. This must be the closest encloser (unhashed: example.org). That's the main purpose of that NSEC3 record: tell the resolver what the closest encloser is. When using Opt-Out, it is possible that the actual closest encloser to the QNAME does not have an NSEC3 record. If so, we will have to do with the closest provable encloser, which is the closest enclosing authoritative name that does have a NSEC3 record. In the worst case, this is the NSEC3 record corresponding to the apex, this name must always have an NSEC3 record. With the closest (provable) encloser, the resolver constructs the next closer, which in this case is: 2.example.org; 2 is the last label chopped, when example.org is the closest encloser. The hash of this name should be covered in any of the other NSEC3s. And it is, 7t70drg4ekc28v93q7gnbleopa7vlp6q falls in the interval set by: 75b9id679qqov6ldfhd8ocshsssb6jvq and 8555t7qegau7pjtksnbchg4td2m0jnpj (this is our second NSEC3). So what does the resolver learn from this? example.org exists; 2.example.org does not exist. And if 2.example.org does not exist, there is also no direct match for x.2.example.org. The last step is to deny the existence of the source of synthesis, to prove that no wildcard expansion was possible. The resolver hashes *.example.org to 22670trplhsr72pqqmedltg1kdqeolb7 and checks that it is covered: in this case by the last NSEC3 (see ), the hash falls in the interval set by 1avvqn74sg75ukfvf25dgcethgq638ek and 75b9id679qqov6ldfhd8ocshsssb6jvq. This means there is no wildcard record directly below the closest encloser and x.2.example.org definitely does not exist. When we have validated the signatures, we reached our goal: authenticated denial of existence. One extra NSEC3 record plus additional signature may seem a lot just to deny the existence of the wildcard record, but we cannot leave it out. If the standard would not mandate the closest encloser NSEC3 record, but instead required two NSEC3 records: one to deny the query name and one to deny the wildcard record. An attacker could fool the resolver that the source of synthesis does not exist, while it in fact does. Suppose the wildcard record does exist, so our unsigned zone looks like this: The query x.2.example.org TXT should now be answered with: An attacker can deny this wildcard expansion by calculating the hash for the wildcard name *.2.example.org and searching for an NSEC3 record that covers that hash. The hash of *.2.example.org is fbq73bfkjlrkdoqs27k5qf81aqqd7hho. Looking through the NSEC3 records in our zone we see that the NSEC3 record of 3.3 covers this hash: This record also covers the query name x.2.example.org (ndtu6dste50pr4a1f2qvr1v31g00i2i1). Now an attacker adds this NSEC3 record to the AUTHORITY section of the reply to deny both x.2.example.org and any wildcard expansion. The net result is that the resolver determines that x.2.example.org does not exist, while in fact it should have been synthesized via wildcard expansion. With the NSEC3 matching the closest encloser example.org, the resolver can be sure that the wildcard expansion should occur at *.example.org and nowhere else. Coming back to the original question: why do we need up to three NSEC3 records to deny a requested name? The resolver needs to be explicitly told what the closest encloser is and this takes up a full NSEC3 record. Then, the next closer name needs to be covered in an NSEC3 record, and finally an NSEC3 must say something about whether wildcard expansion was possible. That makes three to tango. DNSSEC does not protect against denial of service attacks, nor does it provide confidentiality. For more general security considerations related to DNSSEC, please see RFC 4033, RFC 4034, RFC 4035 and RFC 5155 (, , and ). These RFCs are concise about why certain design choices have been made in the area of authenticated denial of existence. Implementations that do not correctly handle this aspect of DNSSEC, create a severe hole in the security DNSSEC adds. This is specifically troublesome for secure delegations: If an attacker is able to deny the existence of a DS record, the resolver cannot establish a chain of trust, and the resolver has to fall back to insecure DNS for the remainder of the query resolution. This document aims to fill this "documentation gap" and provide would-be implementors and other interested parties with enough background knowledge to better understand authenticated denial of existence. This document has no actions for IANA. This document would not be possible without the help of Ed Lewis, Roy Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, Lukas Wunner, Joe Abley, Ralf Weber, Geoff Huston, Dave Lawrence, Tony Finch and Mark Andrews. Also valuable was the source code of Unbound. (validator/val_nsec3.c) . Extensive feedback for early versions was received from Karst Koymans. Domain names - concepts and facilitiesInformation Sciences Institute (ISI)Domain Name System Security ExtensionsCyberCash, Inc.318 Acton StreetCarlisleMA01741US+1 508 287 4877+1 508 371 7148dee@cybercash.comIris Associates1 Technology Park DriveWestfordMA01886US+1 508 392 5276charlie_kaufman@iris.comThe Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases.The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.In addition, the security extensions provide for the optional authentication of DNS protocol transactions.Negative Caching of DNS Queries (DNS NCACHE)CSIRO - Mathematical and Information SciencesLocked Bag 17North Ryde NSW 2113AUSTRALIA+61 2 9325 3148Mark.Andrews@cmis.csiro.auApplicationsdomain name systemDNS[RFC1034] provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section 4.3.4]. Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name. Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver. DNS Security Introduction and RequirementsThe Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]Resource Records for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]Protocol Modifications for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]The Role of Wildcards in the Domain Name SystemThis is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]DNS Security (DNSSEC) Hashed Authenticated Denial of ExistenceThe Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]DNAME Redirection in the DNSThe DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]Domain Name System Security ExtensionsIBM65 Shindegan Hill RoadRR #1CarmelNY10512US+1 914 784 7913+1 914 784 3833dee3@us.ibm.comExtensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases.The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.This document incorporates feedback on RFC 2065 from early implementers and potential users.Redefinition of DNS Authenticated Data (AD) bitThis document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.Legacy Resolver Compatibility for Delegation Signer (DS)As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]Minimally Covering NSEC Records and DNSSEC On-line SigningThis document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]DNS Security (DNSSEC) Opt-InIn the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. This memo defines an Experimental Protocol for the Internet community.DNSSEC Non-Repudiation Resource RecordThis document describes the DNSNR Resource Record (RR) for the Non-Repudiation (NR) of Existence service in the context of the DNS Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or "Authenticated Denial of Existence" Resource Records. A signed DNSNR RR protects security-aware DNS components against false denial of existence of RRsets by providing the RR types that exist for its ownername, which optionally includes a non-authoritative delegation point NS RR type. Labels in the ownername and the RDATA may be a hash-value as a defense against zone traversal.DNSSEC NSEC2 Owner and RDATA FormatThe DNS Security (DNSSEC) NSEC resource record (RR) is intended to be used to provide authenticated denial of existence of DNS owner names and types; however, it also permits any user to obtain a listing of all DNS owner names in a zone. This can accomplished via successive DNS queries for all NSEC RRs in that zone.Authenticating denial of existence in DNS with minimum disclosureThis draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified. One solution, the NO record, is presented. The NO record differ from the NXT record by using a cryptographic hash value instead of the domain name. This prevent an adversery from collecting information by 'chaining' through a zone. It also remove delegation point concerns in NXT records. The document also describe hash truncation and record merging that reduces storage/network load. Technical Errata against RFC 5155 (not acknowledged)Unbound: a validating, recursive, and caching DNS resolverNLnet Labsunbound-users@nlnetlabs.nlPhreebird: a DNSSEC proxyAn NSEC record lists the next existing name in a zone, and thus makes it trivial to retrieve all the names from the zone. This can also be done with NSEC3, but an adversary will then retrieve all the hashed names. With DNSSEC on-line signing, zone walking can be prevented by faking the next owner name. To prevent retrieval of the next owner name with NSEC, a different, non-existing (according to the existence rules in []#RFC4592, Section 2.2) name is used. However, not just any name can be used because a validator may make assumptions on the size of the span the NSEC record covers. The span must be large enough to cover the QNAME, but not too large that it covers existing names. introduces a scheme for generating minimally covering NSEC records. These records use a next owner name that is lexically closer to the NSEC owner name than the actual next owner name, ensuring that no existing names are covered. The next owner name can be derived from the QNAME with the use of so-called epsilon functions. For example, to deny the existence of b.example.org in the zone from , the following NSEC record could have been generated: This record also proves that b.example.org also does not exist, but an adversary cannot use the next owner name in a zone walking attack. Note the type bitmap only has the RRSIG and NSEC set, because states: The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set. This is because the NSEC records may appear at names that did not exist before the zone was signed. In this case however, a.example.org exists with other RR types and we could have also set the A and TXT types in the bitmap. Because DNS ordering is very strict, the span should be shortened to a minimum. In order to do so, the last character in the leftmost label of the NSEC owner name needs to be decremented and the label must be filled with octets of value 255 until the label length reaches the maximum of 63 octets. The next owner name is the QNAME with a leading label with a single null octet added. This gives the following minimally covering record for b.example.org: The same principle of minimally covering spans can be applied to NSEC3 records. This mechanism has been dubbed "NSEC3 White Lies" when it was implemented in Phreebird . Here, the NSEC3 owner name is the hash of the QNAME minus one and the next owner name is the hash of the QNAME plus one. The following NSEC3 white lie denies b.example.org (recall this hashes to iuu8l5lmt76jeltp0bir3tmg4u3uu8e7): The type bitmap is empty in this case. If the hash of b.example.org - 1 is a collision with an existing name, the bitmap should have been filled with the RR types that exist at that name. This record actually denies the existence of the next closer name (which is conveniently b.example.org). Of course the NSEC3 records to match the closest encloser and the one to deny the wildcard are still required. These can be generated too: The following owner names are used in this document. The origin for these names is example.org. Original Name Hashed Name a04sknapca5al7qos3km2l9tl3p5okq4c1.h117gercprcjgg8j04ev1ndrk8d1jt14k@15bg9l6359f5ch23e34ddua6n1rihl9hh1avvqn74sg75ukfvf25dgcethgq638ek*22670trplhsr72pqqmedltg1kdqeolb7375b9id679qqov6ldfhd8ocshsssb6jvq27t70drg4ekc28v93q7gnbleopa7vlp6q3.38555t7qegau7pjtksnbchg4td2m0jnpjda6edkb6v8vl5ol8jnqqlt74qmj7heb84*.2fbq73bfkjlrkdoqs27k5qf81aqqd7hhobiuu8l5lmt76jeltp0bir3tmg4u3uu8e7x.2ndtu6dste50pr4a1f2qvr1v31g00i2i1[This section should be removed by the RFC editor before publishing] Initial document. Style and language changes; Figure captions; Security considerations added; Fix erroneous NSEC3 RR; Section on CNAMEs added; More detailed text on closest encloser proof. Lowercase NSEC3 hashed ownernames and add reference to Base32; Process the comments from Joe Abley and Geoff Huston. Added section about Opt-Out; Move experimental records in their own section; Added DNAME reference with respect to wildcards; Clarify the difference between the wildcard answers; Add more context about the NO record; Elaborate more about the EXIST records and its problems; Added more text about the NSEC3PARAM records; Apply assorted fixes throughout the document; Moved table with hashed owner names to appendix. Changed affiliation for R. Gieben; Some minor updates. Added NS record in all zone examples; Some tweaks in the text regarding on-line signing; Add more text on a non-working "generic non-existence records". Add appendix on on-line signing; Add text on usefulness of NSEC3. Minor fixes and adjustments. Removed a paragraph that wasn't clear. No other changes.