RFC 4592
The Role of Wildcards in the Domain Name System
RFC 4592: The Role of Wildcards in the Domain Name System 🎀
okay bestie, let's get into it 💅 RFC 4592 is an Internet standards track doc, so it's official protocol stuff. It was written by E. Lewis from NeuStar and dated July 2006. It updates RFC 1034 and RFC 2672, and the header has no "Obsoletes" line, so it doesn't replace anything. Its whole job is to clean up how DNS wildcards are defined. 🧚
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
okay so this is an update to the wildcard definition in RFC 1034 🦋 they changed how wildcards and CNAME work together, they got rid of an error condition, and they reworded some of the key concept words around wildcards. the goal isn't to change what wildcards do, it's to make the RFC 1034 definition way clearer ✨
Table of Contents
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. The Original Definition ....................................3
1.3. Roadmap to This Document ...................................4
1.3.1. New Terms ...........................................5
1.3.2. Changed Text ........................................5
1.3.3. Considerations with Special Types ...................5
1.4. Standards Terminology ......................................6
2. Wildcard Syntax .................................................6
2.1. Identifying a Wildcard .....................................6
2.1.1. Wildcard Domain Name and Asterisk Label .............6
2.1.2. Asterisks and Other Characters ......................7
2.1.3. Non-terminal Wildcard Domain Names ..................7
2.2. Existence Rules ............................................7
2.2.1. An Example ..........................................8
2.2.2. Empty Non-terminals .................................9
2.2.3. Yet Another Definition of Existence ................10
2.3. When Is a Wildcard Domain Name Not Special? ...............10
3. Impact of a Wildcard Domain Name on a Response .................10
3.1. Step 2 ....................................................11
3.2. Step 3 ....................................................11
3.3. Part 'c' ..................................................12
3.3.1. Closest Encloser and the Source of Synthesis .......12
3.3.2. Closest Encloser and Source of Synthesis Examples ..13
3.3.3. Type Matching ......................................13
4. Considerations with Special Types ..............................14
4.1. SOA RRSet at a Wildcard Domain Name .......................14
4.2. NS RRSet at a Wildcard Domain Name ........................14
4.2.1. Discarded Notions ..................................15
4.3. CNAME RRSet at a Wildcard Domain Name .....................16
4.4. DNAME RRSet at a Wildcard Domain Name .....................16
4.5. SRV RRSet at a Wildcard Domain Name .......................17
4.6. DS RRSet at a Wildcard Domain Name ........................17
4.7. NSEC RRSet at a Wildcard Domain Name ......................18
4.8. RRSIG at a Wildcard Domain Name ...........................18
4.9. Empty Non-terminal Wildcard Domain Name ...................18
5. Security Considerations ........................................18
6. References .....................................................18
6.1. Normative References ......................................18
6.2. Informative References ....................................19
7. Others Contributing to the Document ............................191. Introduction ✨
so RFC 1034 has sections 4.3.2 and 4.3.3 that explain how answers get synthesized from special resource records (RRs) called wildcards 🌸 the problem is that RFC 1034's explanation is incomplete and kinda confusing. this doc adds more detail and makes some limited changes to fix inconsistencies that caused interoperability problems. it does NOT expand what the original service was meant to do 💅
the vibe is staying true to the spirit and style of the original docs, so this one avoids telling DNS implementations how they have to handle wildcards 🫶 it only describes what's needed for interoperability and doesn't restrict implementation choices. they also tried really hard to keep backward compatibility issues to a minimum for anything that follows RFC 1034.
this doc is focused on wildcards as RFC 1034 defines them. it says nothing about other ways of synthesizing resource record sets (RRSets), and it doesn't discuss any alternatives either 🦋
1.1. Motivation
lowkey, lots of DNS implementations do their own thing with wildcards, in different ways, and they drift away from the original definition 💀 clarifying the original documents was needed even without anything else, but the real push came from the engineering of the DNS security extensions [RFC4033]. because wildcards were so unclear, the design of authenticated denial got tangled up with them 😭
this document is supposed to keep its changes minimal. it only documents what's needed based on what implementers have actually experienced, and it stays as close to the original document as possible. to show that it's clarifying and adjusting (not redefining wildcards), it repeats the relevant parts of RFC 1034 word for word so you can compare old and new text easily 🎀
1.2. The Original Definition
the definition of "wildcard" is made up of two pieces: the algorithm a name server uses to prepare a response (in RFC 1034's section 4.3.2), and the way a resource record (set) gets identified as a source of synthetic data (section 4.3.3) 🧚
this is the definition of "wildcard" as it shows up in RFC 1034, section 4.3.3:
# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*". Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs. When the appropriate conditions are met, the
# name server creates RRs with an owner name equal to the query name
# and contents taken from the wildcard RRs.this passage is the first place the algorithm uses the term wildcard. in this definition, "wildcard" means resource records. but other people have used "wildcard" to mean domain names, and also to describe the practice of relying on wildcards to generate answers 🍓 so yeah, we obviously need clear, unambiguous terminology when we talk about wildcards.
the wildcard part of preparing a response is in step 3, part 'c' of RFC 1034's section 4.3.2, which is titled "Algorithm". fun fact: "wildcard" doesn't actually appear in the algorithm. it just refers to the "*" label instead. section 3 of this document breaks that part of the "Algorithm" down in detail, and this is where that relevant portion starts:
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if [...]
# the "*" label exists.the scope of this doc is the RFC 1034 definition of wildcards, plus what updates to related docs mean for them, like DNS Security (DNSSEC). alternate ways of synthesizing answers aren't considered 🌈 (also, there's no reference listed for them, because no document is known to describe any alternate schemes. they've only come up on mailing lists.)
1.3. Roadmap to This Document
this doc has three jobs 🦋
- Defines new terms
- Makes minor changes to avoid conflicting concepts
- Describes the actions of certain resource records as wildcards
1.3.1. New Terms
two new terms get defined here: "asterisk label" and "wildcard domain name". they're defined in section 2.1.1 ✨
to help explain what the wildcard role is in the name server algorithm in RFC 1034, section 4.3.2, we also define "source of synthesis" and "closest encloser". those definitions are in section 3.3.1. and "label match" is defined in section 3.2 🎀
the new terms are just there to make wildcard talk clearer. terminology doesn't directly affect implementations, so no stress 💅
1.3.2. Changed Text
the definition of "existence" is changed a little bit. implementations won't notice it, but it's needed to make the descriptions more precise. the change is in section 2.2.3 🌸
RFC 1034, section 4.3.3, seems to ban having two asterisk labels in a wildcard owner name. this document removes that restriction entirely. the change and what it means are covered in section 2.1.3 😭
when a source of synthesis owns a CNAME RR, the actions are now changed to match what happens when an exact match name owns a CNAME RR. this is an addition to the words in RFC 1034, section 4.3.2, step 3, part 'c'. the discussion is in section 3.3.3 🦋
only that last change actually affects implementations. the new definition of existence isn't a protocol impact, and the change to the name restriction probably won't matter much, since RFC 1034 never said when or how to enforce that restriction 🙈
1.3.3. Considerations with Special Types
this doc describes what wildcard RRSets mean for "interesting" types, and also for empty non-terminal wildcards 🧚 it's been hard to understand these situations because those types get special processing when they're the result of an exact match. section 4 covers all of that 💜
none of these discussions change how implementations work. they just write down what's already known about these types, with a lot more detail ✨
1.4. Standards Terminology
this document does not use terms as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] 🎀
quotes from RFC 1034 are marked with a '#' at the start of the line. when the doc mentions "4.3.2", that means RFC 1034's section 4.3.2, which is simply titled "Algorithm" 💖
2. Wildcard Syntax 🌸
the syntax of a wildcard is the same as any other DNS resource record, across all classes and types. the only thing that really stands out is the owner name 💅
because wildcards are encoded as resource records with special names, they get included in zone transfers and incremental zone transfers [RFC1995], just like non-wildcard resource records do. honestly this got overlooked until people started talking about alternative approaches to wildcards on mailing lists 🙈
2.1. Identifying a Wildcard
to describe wildcards more accurately, the definition has to start with the domain names that show up as owners. so we need two new terms: "asterisk label" and "wildcard domain name" 🦋
2.1.1. Wildcard Domain Name and Asterisk Label 🎀
okay so a "wildcard domain name" is any name whose initial (leftmost, or least significant) label is, in binary format:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)bestie, look at those two octets 👀. The first one is the normal label type and length for a 1-octet-long label, and the second one is the ASCII code [RFC20] for the '*' character. Literally just a one-letter star label, periodt 💅
A label that equals that value is called an "asterisk label" ⭐
RFC 1034 said a wildcard is "a resource record owned by a wildcard domain name". So the wildcard is the record, and the name is the thing that owns it 🦋
2.1.2. Asterisks and Other Characters 💜
Only the label value from section 2.1.1 counts as an asterisk label. Any name that starts with a different label is never a wildcard domain name, no exceptions 🙅♀️
Labels like 'the*' and '**' look kinda star-adjacent, but they are NOT asterisk labels, so they don't make a wildcard domain name. Not me being picky, it's just how it works ✨
2.1.3. Non-terminal Wildcard Domain Names 🌸
Okay so section 4.3.3 of RFC 1034 said this:
# .......................... The owner name of the wildcard RRs is
# of the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels......................and this restriction is now REMOVED 🗑️ The original wording was incomplete, and after years of real-world operation it doesn't do anything useful anymore 😭
There were three reasons people gave for having it, and honestly none of them survived contact with reality:
- One was that it meant there would never be subdomains of wildcard domain names. But the restriction as written still allows something like
"example.*.example.", so that goal was never really met 🙈 - Another was that wildcard domain names aren't meant to be empty non-terminals. But that situation doesn't break the algorithm in 4.3.2 anyway 🤷♀️
- Finally, "nested" wildcard domain names aren't ambiguous once the closest encloser concept had been written down 🧚
So here's the deal. A wildcard domain name can have subdomains. You do not need to go digging through the subdomains to check whether there's another asterisk label somewhere in there 🫶
A wildcard domain name can also be an empty non-terminal. (More on empty non-terminals in the next sections, don't worry.) In that case, any lookup that runs into it ends the same way it would for any other empty non-terminal match 🌈
2.2. Existence Rules 🌟
The idea that a domain name "exists" shows up in the definition of wildcards. Here's what section 4.3.3 of RFC 1034 says:
# Wildcard RRs do not apply:
#
...
# - When the query name or a name between the wildcard domain and
# the query name is know[n] to exist. . . .So "existence" is a super important concept if you want to get wildcards. The problem is that RFC 1034's definition of what exists is kinda unclear 😭 So in sections 2.2.2. and 2.2.3, we take another look at what existence means 🔍
2.2.1. An Example 🍓
Let's look at a complete zone so existence makes sense:
$ORIGIN example.
example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wildcard"
*.example. 3600 MX 10 host1.example.
sub.*.example. 3600 TXT "this is not a wildcard"
host1.example. 3600 A 192.0.2.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net.Drawing the domain names as a tree helps a lot, trust me 🌳
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| | |
| | |
sub _tcp _tcp
| |
| |
_ssh _sshThese responses would be synthesized from one of the wildcards in the zone:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host3.example. IN MX ..."
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will reflect "no error, but no data"
because there is no A RR set at '*.example.'
QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
the answer will be "foo.bar.example. IN TXT ..."
because bar.example. does not exist, but the wildcard
does.And these responses would NOT be synthesized from any of the wildcards in the zone:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
because sub.*.example. exists
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut)
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. existsThe last example points out a really common misconception 🙈 People think a wildcard "blocks itself", meaning a wildcard doesn't match its own subdomains. So *.example. does NOT match all the names in the example. zone. It just fails to match the names below *.example.. If you want to cover names under *.example., you need another wildcard domain name, *.*.example., which covers everything except its own subdomains 💅
2.2.2. Empty Non-terminals 🦋
Empty non-terminals [RFC2136, section 7.16] are domain names that own no resource records but DO have subdomains that do. In section 2.2.1, _tcp.host1.example. is an example of an empty non-terminal name. Empty non-terminals come from this bit of text in section 3.1 of RFC 1034:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.The parenthesized "which may be empty" is what makes empty non-terminals explicitly recognized, and it's how they "exist" 🧚
Now, if you read that paragraph super pedantically, you could decide that every possible domain exists, up to the suggested limit of 255 octets for a domain name [RFC1035] 😵💫 For example, www.example. may have an A RR, and as far as anyone's concerned it's a leaf of the tree. But the definition can also be taken to mean that sub.www.example. exists too, even with no data. And by that logic, every possible domain exists, from the root on down. Chaotic 💀
RFC 1034 also defines "an authoritative name error indicating that the name does not exist" in section 4.3.1. So clearly that wasn't what the original definition was going for, which is why we need the updated definition in the next section 🫶
2.2.3. Yet Another Definition of Existence 👑
RFC 1034's wording is fixed by the following paragraph:
The domain name space is a tree structure. Nodes in the tree either own at least one RRSet and/or have descendants that collectively own at least one RRSet. A node may exist with no RRSets only if it has descendants that do; this node is an empty non-terminal.
A node with no descendants is a leaf node. Empty leaf nodes do not exist.
Note that at a zone boundary, the domain name owns data, including the NS RR set. In the delegating zone, the NS RR set is not authoritative, but that is of no consequence here. The domain name owns data; therefore, it exists. ✨
2.3. When Is a Wildcard Domain Name Not Special? 🙅♀️
When a wildcard domain name shows up in a message's query section, no special processing happens. An asterisk label in a query name only matches a single, corresponding asterisk label in the existing zone tree when the 4.3.2 algorithm is being followed.
When a wildcard domain name shows up in the resource data of a record, no special processing happens either. An asterisk label in that context literally just means an asterisk. Just a star, bestie ⭐
3. Impact of a Wildcard Domain Name on a Response 🌈
RFC 1034 describes how wildcards affect response generation in its section 4.3.2. That passage has the algorithm a server follows when it builds a response. Inside that algorithm, step 3, part 'c' defines how the wildcard behaves 💖
The algorithm in section 4.3.2 is not meant to be pseudo-code. Its steps aren't meant to be followed in strict order. The "algorithm" is a suggested way of implementing the requirements. So in step 3, parts 'a', 'b', and 'c' don't have to be implemented in that order, as long as what the implemented code does still complies with the protocol's specification 🫶
3.1. Step 2 🗺️
Step 2 of section 4.3.2 reads:
# 2. Search the available zones for the zone which is the nearest
# ancestor to QNAME. If such a zone is found, go to step 3,
# otherwise step 4.This is where the most appropriate zone for the response gets chosen. The big deal here is that all of step 3 happens within that one zone. That matters when you're thinking about whether an SOA RR can ever be used for synthesis 👑
3.2. Step 3 🔍
Step 3 is made up of three parts, labeled 'a', 'b', and 'c'. But the start of the step is important and needs some explaining.
# 3. Start matching down, label by label, in the zone. The
# matching process can terminate several ways:The word 'matching' means label matching. The idea comes from viewing the zone as a tree of existing names. The query name is treated as an ordered sequence of labels, as if the name were a path from the root to the owner of the desired data. (Which it is, see the 3rd paragraph of RFC 1034, section 3.1.) 🌳
Label matching of a query name ends in exactly one of three choices, parts 'a', 'b', or 'c'. Either the name is found, the name is below a cut point, or the name is not found 🦋
Once one of the parts is chosen, the other parts are not considered. For example, you don't execute part 'c' and then switch the execution path to finish in part 'b'. Label matching is also done independently of the query type (QTYPE) 🙅♀️
Parts 'a' and 'b' aren't a problem for this clarification, since they don't have anything to do with record synthesis. Part 'a' is an exact match that results in an answer. Part 'b' is a referral 💅
3.3. Part 'c' ✨
The context for part 'c' is that label matching the query name's labels has led to a spot where there's no corresponding label in the tree. It's as if the lookup has "fallen off the tree" 😭
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if [...]
# the "*" label exists.To help describe what it means to look 'to see if [...] the "*" label exists', a term was coined for the last domain (node) that got matched. That term is "closest encloser" 🎀
3.3.1. Closest Encloser and the Source of Synthesis ✨
okay so the closest encloser is the node in the zone's tree of existing domain names that matches the MOST labels with the query name 🌳 (consecutively, counting from the root label downward). Every match is a "label match," and the order of the labels stays the same. bestie, it's giving detective energy 🔍
The closest encloser is, by definition, an existing name in the zone 💅 It might be an empty non-terminal, or even a wildcard domain name itself 🙈 In no circumstances is the closest encloser used to synthesize records for the current query. Literally never 🚫
Now the source of synthesis is defined in the context of a query process as the wildcard domain name that sits immediately below the closest encloser, as long as that wildcard domain name exists 🧚 "Immediately descending" means the source of synthesis has a name of this form:
<asterisk label>.<closest encloser>.A source of synthesis doesn't guarantee that there's an RRSet to use for synthesis 😭 It could even be an empty non-terminal. Ngl, that's the plot twist.
If the source of synthesis doesn't exist (it's not on the domain tree), there won't be any wildcard synthesis. There's no search for an alternate, so don't go looking 🙅♀️
The big idea: for any given lookup process, there is at most one place where wildcard synthetic records can be obtained 🎯 If the source of synthesis doesn't exist, the lookup ends right there, and it does not go hunting for other wildcard records. Main character energy is knowing when to stop 💖
3.3.2. Closest Encloser and Source of Synthesis Examples ✨
Let's make it visual! Using the example zone in section 2.2.1 of this document, this chart shows QNAMEs with their closest enclosers 🍓
QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source
_dns._udp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
foobar.*.example. *.example. no sourceNotice how foobar.*.example. has *.example. as its closest encloser but still has no source 💀 The asterisk being in the query doesn't magically make a source appear, so iykyk 🫶
3.3.3. Type Matching 🎀
RFC 1034 wraps up part 'c' with this:
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
#
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.The last paragraph is where the QTYPE's role gets explained 👑 Based on implementation feedback and the similarities between part 'a' and part 'c', this passage got a change ✨
The change is to add the following text to part 'c', right before the instruction to "go to step 6":
If the data at the source of synthesis is a CNAME, and QTYPE
doesn't match CNAME, copy the CNAME RR into the answer section of
the response changing the owner name to the QNAME, change QNAME to
the canonical name in the CNAME RR, and go back to step 1.Honestly? This is basically the same text as part 'a', which covers processing CNAME RRSets. Consistency is so slay 💅🌈
4. Considerations with Special Types ✨
Sections 2 and 3 of this document talk about wildcard synthesis with respect to names in the domain tree, and they ignore the impact of types 🙈 This section looks at what happens when wildcards have specific types. These are the types that have proven the hardest to understand: SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG, and "none", which means empty non-terminal wildcard domain names 🧚
4.1. SOA RRSet at a Wildcard Domain Name 💖
A wildcard domain name that owns an SOA RRSet means that the domain is at the root of the zone, aka the apex 👑 It can't be a source of synthesis, because a source of synthesis is by definition a descendant node (of the closest encloser), and a zone apex sits at the top of the zone. Sad, but true 😭
Even so, a wildcard domain name owning an SOA RRSet can never be a source of synthesis, and there's no reason to forbid owning an SOA RRSet anyway 🦋
Here's an example zone:
$ORIGIN *.example.
@ 3600 IN SOA <SOA RDATA>
3600 NS ns1.example.com.
3600 NS ns1.example.net.
www 3600 TXT "the www txt record"A query for www.*.example.'s TXT record would still find the "the www txt record" answer ✨ The asterisk label only becomes significant when section 4.3.2, step 3, part 'c' is in effect.
Of course, there would also need to be a delegation in the parent zone, "example.", for this to work. That's covered in the next section 🫶
4.2. NS RRSet at a Wildcard Domain Name 🌸
Now that DNSSEC [RFC4033, RFC4034, RFC4035] is in place, the semantics of a wildcard domain name owning an NS RRSet have become kinda poorly defined 😭 The dilemma comes from a conflict between the rules for synthesis in part 'c' and the fact that the resulting synthesis generates a record the zone is not authoritative for. In a DNSSEC signed zone, the mechanics of signature management (generating them and including them in a message) have also become unclear 🙈
The salient points of the working group's discussion on this topic are summarized in section 4.2.1.
As a result of those discussions, there is no definition given for wildcard domain names owning an NS RRSet. The semantics are left undefined until there's a clear need to have a set defined, and until there's a clear direction to go in. Operationally, including wildcard NS RRSets in a zone is discouraged, but not barred 🚫
4.2.1. Discarded Notions 🗑️
Before DNSSEC, a wildcard domain name owning an NS RRSet seemed workable, and there are deployments that use implementations supporting it 🧃 Continuing to allow this in the specification isn't tenable with DNSSEC. The reason is that the synthesis of the NS RRSet happens in a zone that has delegated away responsibility for the name. This "unauthorized" synthesis isn't a problem for the base DNS protocol, but DNSSEC, which affirms the authorization model for DNS, exposes the problem 👀
Outright banning wildcards of type NS is also untenable, because the DNS protocol doesn't define how to handle "illegal" data. Implementations may choose not to load a zone, but there's no protocol definition for it. It gets more complicated because the ban has to cover dynamic update [RFC2136] and zone transfers, as well as loading at the master server. The case of a client (a resolver or caching server) getting a wildcard of type NS in a reply would also have to be considered 😵💫
Given the daunting challenge of fully defining how to ban such records, dealing with existing implementations that permit them today is another complication. There are uses of wildcard domain names owning NS RRSets out there 🌍
One compromise that was proposed would have redefined wildcards of type NS so they're not used in synthesis. That compromise fell apart because it would have required significant edits to the DNSSEC signing and validation work. (Again, DNSSEC catches unauthorized data 🛡️)
With no clear consensus forming on a solution to this dilemma, and with the realization that wildcards of type NS are a rarity in operations, the best course of action is to leave this open-ended until "it matters" ✨
4.3. CNAME RRSet at a Wildcard Domain Name 🦋
The issue of a CNAME RRSet owned by a wildcard domain name prompted a suggested change to the last paragraph of step 3c of the algorithm in 4.3.2. That changed text appears in section 3.3.3 of this document 💜
4.4. DNAME RRSet at a Wildcard Domain Name 🚨
Ownership of a DNAME [RFC2672] RRSet by a wildcard domain name is a threat to the coherency of the DNS, so it's to be avoided or outright rejected 😤 A DNAME like this creates non-deterministic synthesis of rules that get fed to different caches. As the caches get fed the different rules (in an unpredictable manner), they stop being coherent. ("As caches are fed" refers to the storage, in a cache, of records obtained in responses by recursive or iterative servers.)
Say one cache, answering a recursive request, obtains this record:
"a.b.example. DNAME foo.bar.example.net."and another cache obtains this one:
"b.example. DNAME foo.bar.example.net."Both were generated from this record:
"*.example. DNAME foo.bar.example.net."by an authoritative server 🖥️
The DNAME specification isn't clear on whether DNAME records in a cache are used to rewrite queries. Some interpretations say the rewrite happens, and others say it doesn't 🤷♀️ If rewriting does occur, a query for "sub.a.b.example. A" may be rewritten as "sub.foo.bar.tld. A" by the former caching server, and as "sub.a.foo.bar.tld. A" by the latter. Coherency is lost, and an operational nightmare ensues 💀
There's another reason to avoid wildcard DNAME records: such a record could synthesize a DNAME owned by "sub.foo.bar.example." and "foo.bar.example.". The DNAME definition has a restriction that no domain exists below a DNAME-owning domain, so the wildcard DNAME is to be avoided 🙅♀️
4.5. SRV RRSet at a Wildcard Domain Name 🧜♀️
The definition of the SRV RRset is in RFC 2782 [RFC2782]. In the definition of the record, there's some confusion over the term "Name." The definition reads as follows:
# The format of the SRV RR
...
# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
# Name
# The domain this RR refers to. The SRV RR is unique in that the
# name one searches for is not this name; the example near the end
# shows this clearly.Don't confuse the definition's "Name" with the owner name 🙃 Once you remove the _Service and _Proto labels from the owner name of the SRV RRSet, what's left could be a wildcard domain name, but that's immaterial to the SRV RRSet.
For example, if an SRV record is the following:
_foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.*.example is a wildcard domain name, and although it's the Name of the SRV RR, it isn't the owner (domain name). The owner domain name is _foo._udp.*.example., which is not a wildcard domain name 🌸
A query for the SRV RRSet of "_foo._udp.bar.example." (class IN) will match the name ".example." (assuming there's no bar.example.), and it will not match the SRV record shown. If there's no SRV RRSet at ".example.", the answer section will reflect that. It'll be empty, or it'll be a CNAME RRset 🫠
The confusion is probably from mixing the specification of the SRV RR with the description of a "use case" 💭
4.6. DS RRSet at a Wildcard Domain Name 🌙
A DS RRSet owned by a wildcard domain name is meaningless and harmless 🧁 This statement is made in the context that an NS RRSet at a wildcard domain name is undefined. At a non-delegation point, a DS RRSet has no value, because no corresponding DNSKEY RRSet will be used in DNSSEC validation. If there is a synthesized DS RRSet, it alone won't be very useful, since it exists in the context of a delegation point 💖
4.7. NSEC RRSet at a Wildcard Domain Name
okay bestie, wildcard domain names in DNSSEC signed zones get an NSEC RRSet 🔐✨. Synthesis of these only happens when the query exactly matches the record 🎯. The synthesized NSEC RRs aren't harmful, because they will never be used in negative caching or to generate a negative response [RFC2308] 🙅♀️💖.
4.8. RRSIG at a Wildcard Domain Name
RRSIG records are present at a wildcard domain name in a signed zone 🦋, and they get synthesized right along with the data someone asked for 🎀. Yes, the owner name is synthesized, but that's not a problem, because the label count in the RRSIG tells the verifying code to ignore it 💅.
4.9. Empty Non-terminal Wildcard Domain Name
If the source of synthesis is an empty non-terminal 🌸, the response comes back with no error in the return code and no RRSet in the answer section 🧚.
5. Security Considerations 🔒
okay this section is SERIOUS bestie 😭🔥. This document is refining the specifications so it's more likely that security can be added to DNS 🛡️. No functional additions are being made. It's just refining what counts as proper, which helps the DNS, its security, and its predictability all grow up together 🌈👑.
6. References 📚
6.1. Normative References
- [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. 🔤
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🌐
- [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 📘
- [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. 🔁
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🗝️
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. 💾
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. 🧭
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 📍
- [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. 🛠️
6.2. Informative References
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. ✏️
7. Others Contributing to the Document 🫶
this doc is the work of a big working group 👯♀️. The editor just recorded their collective wisdom 🧠✨. Comments can be sent to the editor or to the DNSEXT WG mailing list, namedroppers@ops.ietf.org 💌.
Editor's Address 📮
Edward Lewis
NeuStar
46000 Center Oak Plaza
Sterling, VA
20166, US
Phone: +1-571-434-5468
EMail: ed.lewis@neustar.bizFull Copyright Statement ©️
Copyright (C) The Internet Society (2006) 🌸. This document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 🦋.
This document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙈.
Intellectual Property ⚖️
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights might be available. It also doesn't claim it has made any independent effort to find those rights 🕵️♀️. Info on how RFC rights work can be found in BCP 78 and BCP 79 📖.
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses, or the results of any attempt to get a general license for implementers or users, are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🗂️.
The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 📬💜.
Acknowledgement 🙏
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖✨.
📦 where this page comes from
- ietf: rfc4592 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms