RFC 7129
Authenticated Denial of Existence in the DNS
RFC 7129: Authenticated Denial of Existence in the DNS 🎀
Okay bestie, this one is a whole vibe. It's an Independent Submission, which means it wasn't sent through an IETF working group. It's Request for Comments: 7129 and it's written by R. Gieben (Google) and W. Mekking (NLnet Labs). The category is Informational 💅, the ISSN is 2070-1721, and it's dated February 2014. The title block doesn't list anything it obsoletes or updates, so there's no drama there. 🌸
(Part 1 of 6 ✨)
Abstract
Okay so, authenticated denial of existence is how a resolver can prove that a domain name just… isn't there 💀. It's also how the server says "this name exists, but it doesn't have the exact record type you asked for," which is so specific and iconic 😭. When a negative DNS Security Extensions (DNSSEC) response goes out, the name server usually attaches up to two NSEC records. With NSEC version 3 (NSEC3), that number goes up to three 🔥.
This document is basically the extra background and context you need for the NSEC and NSEC3 mechanisms that DNSSEC uses to give these authenticated denial-of-existence answers. It's giving explainer era 🧚.
Status of This Memo
Not gonna lie, this part is a bit formal, but I'll keep it real. This document is not an Internet Standards Track specification 🙈. It's published just for information.
It's a contribution to the RFC Series and it's independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make no statement about whether it's good for implementing or deploying. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 for the details ✨.
For the current status of this doc, any errata, and how to send feedback, check this link: http://www.rfc-editor.org/info/rfc7129 🦋
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they explain your rights and restrictions when it comes to this document 📜.
Table of Contents
1. Introduction ....................................................3
2. Denial of Existence .............................................4
2.1. NXDOMAIN Responses .........................................4
2.2. NODATA Responses ...........................................5
3. Secure Denial of Existence ......................................6
3.1. NXT ........................................................7
3.2. NSEC .......................................................7
3.3. NODATA Responses ...........................................9
3.4. Drawbacks of NSEC .........................................10
4. Experimental and Deprecated Mechanisms: NO, NSEC2, and DNSNR ...11
5. NSEC3 ..........................................................12
5.1. Opt-Out ...................................................14
5.2. Loading an NSEC3 Zone .....................................15
5.3. Wildcards in the DNS ......................................15
5.4. CNAME Records .............................................18
5.5. The Closest Encloser NSEC3 Record .........................19
5.6. Three to Tango ............................................24
6. Security Considerations ........................................25
7. Acknowledgments ................................................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................26
Appendix A. Online Signing: Minimally Covering NSEC Records .......28
Appendix B. Online Signing: NSEC3 White Lies ......................29
Appendix C. List of Hashed Owner Names ............................291. Introduction ✨
DNSSEC can be a bit of a lot, and some parts of the spec are way harder to wrap your head around than others 😭. One of those parts is "authenticated denial of existence" 💀.
Denial of existence is the mechanism that tells a resolver a certain domain name does not exist. It's also used to signal that a domain name exists but doesn't have the specific RR type you were asking for 🙈.
The first case is called a nonexistent domain (NXDOMAIN) ([RFC2308], Section 2.1), and the second is called a NODATA response ([RFC2308], Section 2.2). Both of them are also known as negative responses 🌸.
Authenticated denial of existence uses cryptography to sign the negative response. But wait, if there's no answer, what exactly is getting signed? 🤔 And it gets messier, because people want to pre-generate negative responses that work for every query about nonexistent names in the signed zone. See Section 3 for the details 💅.
In this doc, we're going to explain how authenticated denial of existence works. We start with the current technique in the DNS and work our way up to DNSSEC. Then we look at the first steps DNSSEC took, and how NSEC and NSEC3 work. The NXT, NO, NSEC2, and DNSNR records also make brief cameos, because they paved the way for NSEC and NSEC3 🦋.
To get the full picture, we also have to explain DNS wildcards, since they make everything more complicated, especially when they're combined with CNAME records 🌈.
Note: In this document, domain names in zone file examples will have a trailing dot, but in the running text they will not. This text is written for people who already have a fair understanding of DNSSEC. The following RFCs aren't required reading, but they help with understanding the problem space 📚.
- [RFC5155] -- DNS Security (DNSSEC) Hashed Authenticated Denial of Existence;
- [RFC4592] -- The Role of Wildcards in the Domain Name System.
And these give some general DNSSEC info 🧚:
- [RFC4033], [RFC4034], and [RFC4035] -- DNSSEC specifications;
- [RFC4956] -- DNS Security (DNSSEC) Opt-In. This RFC has an Experimental status but is a really good read ✨.
These three documents give some background on how NSEC3 was developed 🍓:
- The NO record [DNSEXT];
- The NSEC2 record [DNSEXT-NSEC2];
- The DNSNR record [DNSNR-RR].
2. Denial of Existence 🌸
Let's start with the basics and look at NXDOMAIN handling in the DNS. To make it easier to see, we're going to use a small DNS zone with three names ("example.org", "a.example.org", and "d.example.org") and four types (SOA, NS, A, and TXT). For brevity, the class isn't shown (it defaults to IN) and the SOA record is shortened, so here's the zone file 💖:
example.org. SOA ( ... )
example.org. NS a.example.org.
a.example.org. A 192.0.2.1
TXT "a record"
d.example.org. A 192.0.2.1
TXT "d record"Figure 1: The Unsigned "example.org" Zone
2.1. NXDOMAIN Responses 🔥
If a resolver asks the name server serving this zone for the TXT type belonging to "a.example.org", it sends the question: "a.example.org TXT" 💌.
The name server checks its zone data and makes an answer. In this case it's a positive one: "Yes, it exists and here's the data" ✨, and the reply looks like this:
;; status: NOERROR, id: 28203
;; ANSWER SECTION:
a.example.org. TXT "a record"
;; AUTHORITY SECTION:
example.org. NS a.example.org.The "status: NOERROR" means everything is OK, and the "id" is an integer used to match questions to answers 🎀. In the ANSWER section we find our answer. The AUTHORITY section holds the names of the name servers that have info about the "example.org" zone. Note that including this information is optional 🧚.
If a resolver asks for "b.example.org TXT", it gets an answer saying this name does not exist 💀:
;; status: NXDOMAIN, id: 7042
;; AUTHORITY SECTION:
example.org. SOA ( ... )Here there's no ANSWER section, and the status is set to NXDOMAIN. From that, the resolver concludes that "b.example.org" does not exist 🙈. The AUTHORITY section holds the SOA record of "example.org", which the resolver can use to cache the negative response 🦋.
2.2. NODATA Responses 💅
It's really important to realize that NXDOMAIN isn't the only kind of does-not-exist response 😭. A name can exist while the type you asked for doesn't. This kind of nonexistence is called a NODATA response. Let's ask our name server for "a.example.org AAAA" and check the answer:
;; status: NOERROR, id: 7944
;; AUTHORITY SECTION:
example.org. SOA ( ... )The status NOERROR shows that the "a.example.org" name exists, but the reply doesn't contain an ANSWER section. This is how you tell a NODATA response apart from an NXDOMAIN response. The rest of the packet looks pretty much the same 👑. The resolver has to put these pieces together and conclude that "a.example.org" exists but doesn't have a "AAAA" record 🌈.
3. Secure Denial of Existence ✨
okay so now we translate all of that into the security-aware world of DNSSEC 🔐 but DNSSEC comes in with a few principles that are kind of a big deal:
- 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 the 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" cannot be trusted. In fact, the entire header may be forged, including the AD bit (AD stands for Authentic Data; see [RFC3655]), which may give some food for thought 🫠
- DNS wildcards and CNAME records complicate matters significantly. See more about this later in Sections 5.3 and 5.4. 👀
The first principle implies that all denial-of-existence answers need to be precomputed, but it is impossible to precompute (all conceivable) nonexistence answers. 💀
A generic denial record that can be used in all denial-of-existence proofs is not an option, bestie. 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, which has unlimited 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. It's giving total chaos 🌪️
We could also use the QNAME in the answer and sign that, which is basically signing an NXDOMAIN response. While this approach could have worked technically, it is incompatible with offline signing. 🙅♀️
So the way this got solved is by introducing a record that defines an interval between two existing names. Or, to put it another way, it defines the holes (nonexisting names) in the zone. This record can be signed beforehand and given to the resolver. Appendices A and B describe online 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 allow for online signing? Well, at that time (pre 2000), online 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 kinds of levels is always a challenge. Another issue was (and is) key management. For online signing to work, _each_ authoritative name server needs access to the private key(s). This is considered a security risk. Hence, the protocol is required not to rely on on-line signing. 🔑🚫
The road to the current solution (NSEC/NSEC3) was long, bestie 🛣️ It started with the NXT (next) record. The NO (not existing) record was introduced, but it never made it into an 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. 🎉
3.1. NXT 🧩
The first attempt to specify authenticated denial of existence was NXT ([RFC2535]). Section 5.1 of RFC 2535 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. Lowkey genius 🧠 NXT is superseded by NSEC. In the next section, we explain how NSEC (and thus NXT) works. 💅
3.2. NSEC 🫶
In [RFC3755], all the DNSSEC types were given new names: SIG was renamed RRSIG, KEY became DNSKEY, and NXT was renamed NSEC. A minor issue was fixed in the process too: the type bitmap was redefined to allow more than 127 types to be listed ([RFC2535], Section 5.2). Glow-up energy ✨
Just like 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 ([RFC4034], Section 6.1), and then we 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 RFC 4034 and depicted in Figure 2. 🔁
- 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. Yesss 🙌
example.org
**
+-- ** <--+
(1) / . . \ (3)
/ . . \
| . . |
v . . |
** (2) **
a.example.org ** ---------> ** d.example.orgFigure 2: The NSEC records of "example.org". The arrows represent NSEC records, starting from the apex.
This signed zone is loaded into the name server. It looks like this, and honestly it's a whole vibe 🌸
example.org. SOA ( ... )
DNSKEY ( ... )
NS a.example.org.
NSEC a.example.org. NS SOA RRSIG NSEC DNSKEY
RRSIG(NS) ( ... )
RRSIG(SOA) ( ... )
RRSIG(NSEC) ( ... )
RRSIG(DNSKEY) ( ... )
a.example.org. A 192.0.2.1
TXT "a record"
NSEC d.example.org. A TXT RRSIG NSEC
RRSIG(A) ( ... )
RRSIG(TXT) ( ... )
RRSIG(NSEC) ( ... )
d.example.org. A 192.0.2.1
TXT "d record"
NSEC example.org. A TXT RRSIG NSEC
RRSIG(A) ( ... )
RRSIG(TXT) ( ... )
RRSIG(NSEC) ( ... )Figure 3: The signed and sorted "example.org" zone with the added NSEC records (and signatures). For brevity, the class is not shown (defaults to IN) and the SOA, DNSKEY, and RRSIG records are shortened.
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 that covers the name space where "b" lives.
The record:
a.example.org. NSEC d.example.org. A TXT RRSIG NSECdoes precisely that! "b" should come after "a", but the next owner name is "d.example.org", so "b" does not exist. Math check passed 🧮💖
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! 🥹 A similar NSEC record needs to be included to deny wildcard expansion, see Section 5.3.
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 provable that this is the proper response to the query. Replay all you want, it's still the right answer 🤷♀️
3.3. NODATA Responses 🎀
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:
;; status: NOERROR, id: 44638
;; AUTHORITY SECTION:
example.org. SOA ( ... )
example.org. RRSIG(SOA) ( ... )
a.example.org. NSEC d.example.org. A TXT RRSIG NSEC
a.example.org. RRSIG(NSEC) ( ... )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 exist, as it is not listed in the type bitmap.
The techniques used by NSEC form the basics of authenticated denial of existence in DNSSEC. Main character energy for real 👑
3.4. Drawbacks of NSEC 😬
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 ([RFC2065], Section 5.5). Oops 🫣
The second issue is that when a large, delegation-centric ([RFC5155], 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 led 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 Section 5.1). 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 zone walking. RFC 4470 [RFC4470] prevents zone walking by introducing minimally covering NSEC records. This technique is described in Appendix A. 🦋
Before we delve into NSEC3, let us first take a look at its predecessors: NO, NSEC2, and DNSNR. 🧚
4. Experimental and Deprecated Mechanisms: NO, NSEC2, and DNSNR ✨
okay so before NSEC even existed, there was this record called NO 🧚. It was the first one to use hashed owner names to fix the zone walking problem that NXT had. It also fixed NXT's type bitmap issue, just not in a space-efficient way. Around 2000, zone walking wasn't considered important enough to justify a new record, and people were worried that DNSSEC deployment would get slowed down by making a whole alternate way to do denial of existence. So the effort got shelved and NXT stayed. 😔
Then the new DNSSEC specification [RFC4034] was written, and people still weren't convinced zone walking was a real problem worth solving. So NSEC showed up and inherited both issues from NXT. Lowkey iconic that it had the same problems 💀
Several years later, NSEC2 came along to fix the two issues NSEC had. The NSEC2 document [DNSEXT-NSEC2] has this 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.
Whenever an authenticated denial-of-existence scheme starts talking about EXIST records, you have to pay extra attention 👀. The EXIST record was defined as a record with no RDATA that signals the presence of a domain name. From [DNSEXT-NSEC2]:
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 EXIST record led to questions about what wildcards actually mean, especially in the context of DNSSEC. It's probably not a coincidence that "The Role of Wildcards in the Domain Name System" [RFC4592] got standardized before NSEC3 did 🌸.
NSEC2 solved zone walking by hashing the "next owner name" in the record with SHA1 and a salt, which makes it useless for zone walking 🙌. But it did not have Opt-Out, and that's a big miss.
The DNSNR record was another attempt. It also used hashed names to foil zone walking, and it introduced the concept of opting out, called "Authoritative Only Flag". That limited the use of DNSNR in delegation-centric zones 🍓.
None of these proposals made it, but they gave us really 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.
5. NSEC3 🎀
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 does bring some extra complexity 😅.
NSEC3 did not supersede NSEC. They are both defined for DNSSEC, so DNSSEC is blessed with two different means of performing authenticated denial of existence: NSEC and NSEC3 👑. In NSEC3, every name is hashed, including the owner name. That means the 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". And since the next owner name is hashed too, zone walking becomes way harder 🕵️♀️.
To make it even harder to retrieve the original names, the hashing can be repeated several times, with each round taking the previous hash as input. And to stop pre-generated hash values from being reused between zones, a (per-zone) salt can be added too 🧂. In the NSEC3 for "example.org", we hashed the names thrice ([RFC5155], Section 5) and used the salt "DEAD". Let's look at a typical NSEC3 record:
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. (
NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84
NS SOA RRSIG DNSKEY NSEC3PARAM )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 [RFC4648]. Note that even though we hashed "example.org", the zone's name gets added back so it looks 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. "d.example.org" is the next owner name because, in hash ordering, its hash comes after the hash of the zone's apex. Also, ".example.org" isn't added to the next hashed owner name, since this name always falls in the current zone 🌈.
The "1 0 2 DEAD" segment of the NSEC3 record says:
- Hash Algorithm = 1 (SHA1 is the default; no other hash algorithms are currently defined for use in NSEC3; see Section 3.1.1 of [RFC5155]);
- Opt-Out = 0 (disabled; see Section 6 of [RFC5155]);
- Hash Iterations = 2 (this yields three iterations, as a zero value is already one iteration; see Section 3.1.3 of [RFC5155]);
- Salt = "DEAD" (see Section 3.1.5 of [RFC5155].
At the end, we see the type bitmap, which is identical to NSEC's bitmap and lists the types present at the original owner name. Note that the type NSEC3 is absent from the list in the example above. That's because the original owner name ("example.org") doesn't have the NSEC3 type. It only exists on the hashed name 🙈.
Names like "1.h.example.org" hash to one label in NSEC3, so "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 creates 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 subdomains that do ([RFC5155], Section 1.3). Here's the record:
1.h.example.org. TXT "1.h record"It 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 Section 5.5, we show 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 structured zones, like the reverse zones ip6.arpa and in-addr.arpa, can be walked even with NSEC3 because of their structure. Also, the names in small, trivial zones can be easily guessed. In these cases, NSEC3 doesn't help defend against zone walking, but it does add computational load on authoritative servers and validators 😬.
5.1. Opt-Out 🚪
Hashing mitigates the zone-walking issue of NSEC. The other issue, the high cost 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 Opt-Out) by 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 delegations do not benefit from the cryptographic security that DNSSEC provides.
A recently discovered corner case (see RFC Errata ID 3441 [Err3441]) shows that not only do those delegations remain insecure, but so does the empty non-terminal space derived from them 😱.
Because the names in this empty non-terminal space do exist according to the definition in [RFC4592], the server should respond to queries for these names with a NODATA response. However, the validator requires an NSEC3 record proving the NODATA response ([RFC5155], 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's only derived from an insecure delegation 🫶.
5.2. Loading an NSEC3 Zone 📥
Whenever an authoritative server receives a query for a non-existing record, it has to hash the incoming query name to determine which interval between two existing hashes it falls into. 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 there's 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 in use. And by putting it in the zone, it allows for easy transfer to the secondaries 🚀💖.
5.3. Wildcards in the DNS ✨
Okay so, up to now we've only talked about denial of existence in negative responses 🙈 But denial of existence can also show up in positive responses, where the ANSWER section is not empty. The culprit? Wildcards 🃏
Wildcards have been part of the DNS since the very first DNS RFCs. They let you define all names for a certain type in one go 🧚 In our "example.org" zone, we could add a wildcard record like this:
*.example.org. TXT "wildcard record"For completeness, our (unsigned) zone now looks like this 💜
example.org. SOA ( ... )
example.org. NS a.example.org.
*.example.org. TXT "wildcard record"
a.example.org. A 192.0.2.1
TXT "a record"
d.example.org. A 192.0.2.1
TXT "d record"Figure 4: The example.org Zone with a Wildcard Record
If a resolver asks for "z.example.org TXT", the name server responds with an expanded wildcard instead of an NXDOMAIN 🦋
;; status: NOERROR, id: 13658
;; ANSWER SECTION:
z.example.org. TXT "wildcard record"Now, the resolver can't tell that this answer came from a wildcard 🤷♀️ It just sees the answer as is. So how does this answer look with DNSSEC? 👀
;; status: NOERROR, id: 51790
;; ANSWER SECTION:
z.example.org. TXT "wildcard record"
z.example.org. RRSIG(TXT) ( ... )
;; AUTHORITY SECTION:
d.example.org. NSEC example.org. A TXT RRSIG NSEC
d.example.org. RRSIG(NSEC) ( ... )Figure 5: A Response with an Expanded Wildcard and DNSSEC
The RRSIG of the "z.example.org" TXT record is basically waving a flag saying "hey, there's a wildcard configured!" 🚩 The RDATA of the signature lists a label count, [RFC4034], Section 3.1.3., of two (not visible in the figure above), but the owner name of the signature has three labels. That mismatch tells us there's a wildcard "*.example.org" configured. Iconic detective work, honestly 🕵️♀️
An astute reader may notice that it looks like a "z.example.org" RRSIG(TXT) got created out of thin air 😳 It didn't! The signature for "z.example.org" does not exist. The signature you're seeing is the one for "*.example.org", which does exist. Only the owner name got 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 these responses 🔒 If it wasn't, an attacker could pull off a replay attack and poison the cache with false data 💀 Say the resolver asked for "a.example.org TXT". An attacker could tweak the packet so it looks like the response came from wildcard expansion, even though a record actually exists for "a.example.org TXT" 😭
The tweak is simply adjusting the ANSWER section to:
;; status: NOERROR, id: 31827
;; ANSWER SECTION:
a.example.org. TXT "wildcard record"
a.example.org. RRSIG(TXT) ( ... )Figure 6: A Forged Response without the Expanded Wildcard
Notice the subtle difference from Figure 5 in the owner name 👀 In this response we get an "a.example.org TXT" record, even though a record with different RDATA (see Figure 4) exists in the zone. Sneaky, sneaky 🦹♀️
That would be a perfectly valid answer if we didn't require the inclusion of an NSEC or NSEC3 record in the wildcard answer response. The resolver would believe "a.example.org TXT" is a wildcard record, and the real record gets obscured. That's bad, and it defeats all the security DNSSEC can deliver 😤 Because of this, the NSEC or NSEC3 must be present.
Another way of putting it: DNSSEC is there to make sure the name server followed the steps in [RFC1034], Section 4.3.2 for looking up names in the zone. That section explicitly lists wildcard lookup as one of those steps (3c), so with DNSSEC this has to be communicated to the resolver. Hence, the NSEC or NSEC3 record 💖
5.4. CNAME Records 💅
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 goes up to three (we'll explain why in the next section, don't worry 🎀).
When we take CNAME wildcard records into account, we can end up with more NSEC or NSEC3 records. For every wildcard expansion, we need to prove that the expansion was allowed. Let's add some CNAME wildcard records to our zone 🌸
example.org. SOA ( ... )
example.org. NS a.example.org.
*.example.org. TXT "wildcard record"
a.example.org. A 192.0.2.1
TXT "a record"
*.a.example.org. CNAME w.b
*.b.example.org. CNAME w.c
*.c.example.org. A 192.0.2.1
d.example.org. A 192.0.2.1
TXT "d record"
w.example.org. CNAME w.aFigure 7: A Wildcard CNAME Chain Added to the "example.org" Zone
A query for "w.example.org A" gets you this response 🦋
;; status: NOERROR, id: 4307
;; ANSWER SECTION:
w.example.org. CNAME w.a.example.org.
w.example.org. RRSIG(CNAME) ( ... )
w.a.example.org. CNAME w.b.example.org.
w.a.example.org. RRSIG(CNAME) ( ... )
w.b.example.org. CNAME w.c.example.org.
w.b.example.org. RRSIG(CNAME) ( ... )
w.c.example.org. A 192.0.2.1
w.c.example.org. RRSIG(A) ( ... )
;; AUTHORITY SECTION:
*.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC
*.a.example.org. RRSIG(NSEC) ( ... )
*.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC
*.b.example.org. RRSIG(NSEC) ( ... )
*.c.example.org. NSEC d.example.org. A RRSIG NSEC
*.c.example.org. RRSIG(NSEC) ( ... )The NSEC record ".a.example.org" proves that the wildcard expansion to "w.a.example.org" was appropriate, since "w.a." falls in the gap from ".a" to ".b" ✨ Similarly, the NSEC record ".b.example.org" proves 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 [RFC6672], Section 3.3. 🚫
5.5. The Closest Encloser NSEC3 Record
okay so we can have one or more NSEC3 records that deny the name you asked for, plus one NSEC3 record that denies wildcard synthesis. but what do we miss? 🤔
the short answer: because NSEC3 hashes everything, your zone loses its depth. every name gets squished into one flat plane 🥞. to make up for that lost info, you need one extra record.
before we dive in, we need two definitions 📚:
Closest encloser: introduced in [RFC4592]. the closest encloser is the node in the zone's tree of existing domain names that matches the most labels of 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" 🫶
Next closer name: introduced in [RFC5155]. this is the closest encloser with one more label added on the left. so if "example.org" is the closest encloser for "x.2.example.org", then "2.example.org" is the "next closer name" ✨
an NSEC3 "closest encloser proof" is made of two things 💅:
- an NSEC3 record that matches the "closest encloser". that means the unhashed owner name of the record is the closest encloser. this tells the resolver: "the name you asked for doesn't exist, and the closest thing I have is this one" 🙈
- an NSEC3 record that covers the "next closer name". that means it defines an interval where the "next closer name" lands. this tells the resolver: "the next closer name falls in this interval, so the name in your question doesn't exist. and yeah, the closest encloser really is the closest I've got" 💀
these two records already deny the requested name, so we don't need an NSEC3 record that covers the actual queried name at all. by denying the next closer name, you also deny the queried name. no notes 🎀
also, with NSEC, the existence of every empty non-terminal between the two names gets denied, which means it implicitly contains the closest encloser 🧚
for any given query name, there is exactly one place where wildcard expansion is possible. this is the "source of synthesis", and it's defined in ([RFC4592], Sections 2.1.1 and 3.3.1) as:
<asterisk label>.<closest encloser>so, to deny wildcard synthesis, the resolver needs to know the hash of the source of synthesis. the resolver doesn't know ahead of time what the closest encloser of the query name is, so that info has to be included in the answer 🌸
let's look at an example. we have a zone with two TXT records. the records added are "1.h.example.org" and "3.3.example.org". it gets signed with NSEC3, which gives us this unsigned zone:
example.org. SOA ( ... )
example.org. NS a.example.org.
1.h.example.org. TXT "1.h record"
3.3.example.org. TXT "3.3 record"Figure 8: The TXT records in example.org. These records create two empty non-terminals: h.example.org and 3.example.org.
the resolver asks: "x.2.example.org TXT". the server answers with NXDOMAIN, and that response contains three NSEC3 records. you can find a list of hashed owner names in Appendix C 📖. also check out Figure 9. the numbers in that figure match these NSEC3 records:
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. (
NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG
DNSKEY NSEC3PARAM )
1avvqn74sg75ukfvf25dgcethgq638ek.example.org. (
NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ )
75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. (
NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG )if we went with the NSEC approach, the resolver only cares about one thing: does the hash of "x.2.example.org" fall inside any of the intervals from the NSEC3 records it got? 👀
example.org
**
+-- ** . . . . . . . . . . .
(1) / . ^ . .
/ . | . .
| . | . .
v . | . .
** | (2) ** ++
h.example.org ** ----+----> ** 3.example.org ++ 2.example.org
. / . | .
. / (5) . | (3) .
. / . | .
. / . v .
1.h.example.org ** ** ++
** <--------- ** 3.3.example.org ++ x.2.example.org
(4)Figure 9: "x.2.example.org" does not exist. The five arrows represent the NSEC3 records; the ones numbered (1), (2), and (3) are the NSEC3s returned in our answer. "2.example.org" is covered by (3) and "x.2.example.org" is covered by (4).
the hash of "x.2.example.org" is ndtu6dste50pr4a1f2qvr1v31g00i2i1. checking it against the first NSEC3 shows it doesn't fall in the interval from 15bg9l6359f5ch23e34ddua6n1rihl9h to 1avvqn74sg75ukfvf25dgcethgq638ek. the second NSEC3 is a no too, because the hash sorts outside the interval from 1avvqn74sg75ukfvf25dgcethgq638ek to 75b9id679qqov6ldfhd8ocshsssb6jvq. and the third NSEC3, with the interval from 75b9id679qqov6ldfhd8ocshsssb6jvq to 8555t7qegau7pjtksnbchg4td2m0jnpj, isn't helpful either 😭
so what's a resolver supposed to do? it got the max number of NSEC3s and they all look useless 🥺
this is where the closest encloser proof saves the day ✨. for the proof to work, the resolver needs to know what the closest encloser is. there has to be an existing ancestor in the zone, meaning a name that's shorter than the query name. the resolver keeps hashing increasingly shorter names taken from the query name until an NSEC3 owner name matches. that owner name is the closest encloser 🔍
once the resolver has the closest encloser, the next step is building the next closer name. that's the closest encloser with the last chopped label from the query name stuck on the front: "<last chopped label>.<closest encloser>". the hash of this name should be covered by the interval in one of the NSEC3 records 💖
then the resolver has to check for a wildcard. it builds the wildcard name by putting the asterisk label in front of the closest encloser, "*.<closest encloser>", and hashes that 🦋
back to our example: the resolver first has to find the NSEC3 that matches the closest encloser. it does this by chopping up the query name, hashing each piece (using the same number of iterations and the same hash as the zone it's querying), and comparing those hashes to the answers. so it ends up with these hashes to work with:
x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1", last chopped label: "<empty>"2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q", last chopped label: "x"example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h", last chopped label: "2"
only one of these hashes matches the owner name of an NSEC3 record: "15bg9l6359f5ch23e34ddua6n1rihl9h". that has to be the closest encloser, which unhashes to "example.org". that's the main job of that NSEC3 record: tell the resolver what the closest encloser is 🎀
when Opt-Out is in use, the actual closest encloser of the QNAME might not have an NSEC3 record at all. if that happens, we have to settle for the closest provable encloser, which is the closest enclosing authoritative name that does have an NSEC3 record. in the worst case, that's the NSEC3 record for the apex, because that name must always have an NSEC3 record 🙈
with the closest (provable) encloser in hand, the resolver builds the next closer name. here that's "2.example.org", because "2" is the last label chopped when "example.org" is the closest encloser. the hash of this name should be covered by one of the other NSEC3 records. and guess what? it is 😳. "7t70drg4ekc28v93q7gnbleopa7vlp6q" falls in the interval from "75b9id679qqov6ldfhd8ocshsssb6jvq" to "8555t7qegau7pjtksnbchg4td2m0jnpj" (that's our second NSEC3) 🔥
so what does the resolver learn from all this?
- "example.org" exists;
- "2.example.org" does not exist.
and if "2.example.org" doesn't exist, then there's also no direct match for "x.2.example.org". the last step is denying the source of synthesis, which proves no wildcard expansion was possible 💅
the resolver hashes "*.example.org" to 22670trplhsr72pqqmedltg1kdqeolb7 and checks that it's covered. in this case, the last NSEC3 (see Figure 9) covers it, because the hash falls in the interval from "1avvqn74sg75ukfvf25dgcethgq638ek" to "75b9id679qqov6ldfhd8ocshsssb6jvq". that means there's no wildcard record directly below the closest encloser, and "x.2.example.org" definitely does not exist 🫶
once we've validated the signatures, we've hit our goal: authenticated denial of existence 🏆
5.6. Three to Tango
one extra NSEC3 record plus an additional signature might feel like a lot just to deny a wildcard record, but we can't skip it 😤. if the standard didn't require the closest encloser NSEC3 record and instead asked for two NSEC3 records (one to deny the query name and one to deny the wildcard record), an attacker could trick the resolver into thinking the source of synthesis doesn't exist, when it really does 💀.
now suppose the wildcard record does exist, so our unsigned zone looks like this:
example.org. SOA ( ... )
example.org. NS a.example.org.
*.example.org. TXT "wildcard record"
1.h.example.org. TXT "1.h record"
3.3.example.org. TXT "3.3 record"the query "x.2.example.org TXT" should now be answered with:
x.2.example.org. TXT "wildcard record"an attacker can shut down this wildcard expansion by working out the hash of the wildcard name ".2.example.org" and looking for an NSEC3 record that covers that hash. the hash of ".2.example.org" is "fbq73bfkjlrkdoqs27k5qf81aqqd7hho". checking the NSEC3 records in our zone, we find that the NSEC3 record for "3.3" covers this hash:
8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. (
NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG )that same record also covers the query name "x.2.example.org" ("ndtu6dste50pr4a1f2qvr1v31g00i2i1") 🙈
now the attacker adds this NSEC3 record to the AUTHORITY section of the reply, which denies both "x.2.example.org" and any wildcard expansion. the net result is that the resolver decides "x.2.example.org" doesn't exist, even though it should have been synthesized from the wildcard. with the NSEC3 matching the closest encloser "example.org" in place, the resolver can be sure the wildcard expansion should happen at "*.example.org" and nowhere else 🧚
so, back to the original question: why do we need up to three NSEC3 records to deny a requested name? the resolver has to be told explicitly what the "closest encloser" is, and that takes up a full NSEC3 record. then the next closer name has to be covered by an NSEC3 record. and finally, an NSEC3 has to say something about whether wildcard expansion was possible. that's three to tango 💜✨
6. Security Considerations ✨
okay bestie, this section is SERIOUS but also kind of iconic 💅. DNSSEC does not protect against denial-of-service attacks 🙅♀️, and it does not provide confidentiality 🤐. If you want the general security tea on DNSSEC, go read [RFC4033], [RFC4034], [RFC4035], and [RFC5155] 📚.
Those RFCs are kinda brief about why certain design choices got made in the area of authenticated denial of existence 🥺. So if an implementation doesn't handle this part correctly, it creates a severe hole in the security DNSSEC is supposed to add 😭🚨. This is especially chaotic for secure delegations 💀. If an attacker can deny that a Delegation Signer (DS) record exists, the resolver can't build a chain of trust, and it has to fall back to insecure DNS for the rest of the query resolution 🙀. Not it. 🙅♀️
This document is here to fill that "documentation gap" 📖✨, giving would-be implementors and other curious people enough background to actually understand authenticated denial of existence 🧠💖.
7. Acknowledgments 🫶
This document would not exist 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 👑🌸. The source code of Unbound ("validator/val_nsec3.c") [Unbound] was also super valuable 🙌.
Extensive feedback on early versions came from Karst Koymans 💜.
8. References 📚
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012.8.2. Informative References
[DNSEXT-NSEC2]
Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", Work in
Progress, October 2004.
[DNSEXT] Josefsson, S., "Authenticating denial of existence in DNS
with minimum disclosure", Work in Progress, November 2000.
[DNSNR-RR] Arends, R., "DNSSEC Non-Repudiation Resource Record", Work
in Progress, June 2004.
[Err3441] RFC Errata, Errata ID 3441, RFC 5155,
<http://www.rfc-editor.org>.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
and DNSSEC On-line Signing", RFC 4470, April 2006.
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
(DNSSEC) Opt-In", RFC 4956, July 2007.
[Unbound] NLnet Labs, "Unbound: a validating, recursive, and caching
DNS resolver", 2006, <http://unbound.net>.
[phreebird]
Kaminsky, D., "Phreebird: a DNSSEC proxy", January 2011,
<http://dankaminsky.com/phreebird/>.Appendix A. Online Signing: Minimally Covering NSEC Records 🌈
An NSEC record lists the next existing name in a zone, which makes it trivial to retrieve all the names from the zone 🫣. You can do this with NSEC3 too, but then an adversary retrieves all the hashed names 🕵️♀️. With DNSSEC online signing, zone walking can be stopped by faking the next owner name 🎭.
To stop people grabbing the next owner name with NSEC, a different name is used, one that doesn't exist (according to the existence rules in [RFC4592], Section 2.2) 🙅♀️. But you can't just pick any name, because a validator may make assumptions about how big the span the NSEC record covers is. The span has to be big enough to cover the QNAME, but not so big that it covers existing names 📏.
[RFC4470] introduces a scheme for generating minimally covering NSEC records 🎀. These use a next owner name that is lexically closer to the NSEC owner name than the real next owner name, so no existing names get covered 💫. The next owner name can be derived from the QNAME using so-called epsilon functions 🧮.
For example, to deny the existence of "b.example.org" in the zone from Section 3.2, this NSEC record could have been generated:
a.example.org. NSEC c.example.org. RRSIG NSECThis record also proves that "b.example.org" doesn't exist, but an adversary _cannot_ use the next owner name in a zone-walking attack 🛑. The type bitmap only has RRSIG and NSEC set, because [RFC4470] says:
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 NSEC records may show up at names that didn't exist before the zone was signed 🤓. In this case, though, "a.example.org" exists with other RR types, so we could also have set the A and TXT types in the bitmap 💅.
Since DNS ordering is very strict, the span should be shortened to a minimum 📐. To do that, the last character in the leftmost label of the NSEC owner name gets decremented, and the label is 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" 🍓:
a\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
\255\255\255\255\255\255\255\255\255\255\255.example.org. (
NSEC \000.b.example.org. RRSIG NSEC )Appendix B. Online Signing: NSEC3 White Lies 🦋
The same idea of minimally covering spans works for NSEC3 records too 🌸. This mechanism got dubbed "NSEC3 White Lies" when it was implemented in Phreebird [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" (fyi, this hashes to "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7") 🔍:
iuu8l5lmt76jeltp0bir3tmg4u3uu8e6.example.org. (
NSEC3 1 0 2 DEAD IUU815LMT76JELTP0BIR3TMG4U3UU8E8 )The type bitmap is empty in this case. If the hash of "b.example.org" - 1 collides 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 that match the closest encloser and deny the wildcard are still required ✨. These can be generated too:
# Matching `example.org`: `15bg9l6359f5ch23e34ddua6n1rihl9h`
15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. (
NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9I NS SOA RRSIG
DNSKEY NSEC3PARAM )
# Covering `*.example.org`: `22670trplhsr72pqqmedltg1kdqeolb7`
22670trplhsr72pqqmedltg1kdqeolb6.example.org.(
NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8 )Appendix C. List of Hashed Owner Names 🧚
The following owner names are used in this document 🎀. The origin for these names is "example.org" 🌍.
+----------------+-------------------------------------+
| Original Name | Hashed Name |
+----------------+-------------------------------------+
| "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" |
| "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" |
| "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" |
| "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" |
| "*" | "22670trplhsr72pqqmedltg1kdqeolb7" |
| "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" |
| "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" |
| "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" |
| "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" |
| "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" |
| "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" |
| "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" |
+----------------+-------------------------------------+
Table 1: Hashed Owner Names for "example.org" in Hash OrderAuthors' Addresses 💌
R. (Miek) Gieben
Google
EMail: miek@google.com
W. (Matthijs) Mekking
NLnet Labs
Science Park 400
Amsterdam 1098 XH
NL
EMail: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/📦 where this page comes from
- ietf: rfc7129 2014-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms