3. Impact of a Wildcard Domain Name on a Response

The algorithm in RFC 1034, section 4.3.2, is unchanged, except as specified in section 3.3.3 of this document. The issue is the interpretation of the algorithm in RFC 1034, section 4.3.2, step 3, part 'c', as indicated in RFC 1034's section 4.3.3, defining wildcards.

In the following explanations, where RFC 1034 is mentioned, the text applies when any update to RFC 1034 (such as [RFC2672] defining DNAME) is applied as well.

3.1 Step 2

Step 2 of the search algorithm is to "find the longest match possible". It has been argued that a cached referral answers the question of "longest match" and eliminates the need to continue with the subsequent steps. This is incorrect. Completing step 2 includes determining if there is a longer match available further along in the DNS hierarchy.

3.2 Step 3

Step 3 of the search algorithm in RFC 1034, section 4.3.2, is where wildcards are invoked, but only if a resource record set matching the query's type is not found at the domain name. This is part 'c' of step 3. The statement is:

# c. If at some label, a match is impossible (i.e., the
#    corresponding label does not exist), look to see if [...]
#    the "*" label exists.
#
#    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. [...]

3.3 Part 'c'

This is the discussion on the "look to see" text quoted from RFC 1034's section 4.3.2, step 3, part 'c'.

3.3.1 Closest Encloser and the Source of Synthesis

The "closest encloser" is the node in the zone's tree of existing domain names that has the most labels matching a query name (consecutively, counting from the root label downward). Each match is a "label match" and the count of the number of labels that match is the "closest encloser proof". The closest encloser is, in a sense, the deepest existing domain name in the zone that is an ancestor of the query name.

The "source of synthesis" is the wildcard domain name immediately descending from the closest encloser, provided that a wildcard domain name appears at that location in the zone. The source of synthesis is determined by prepending the asterisk label ("*") to the closest encloser.

The use of the phrase "source of synthesis" to describe the wildcard domain name involved in wildcard synthesis provides a useful term and does not cause problems in describing the use of names that have an asterisk label not at the leftmost label position because they are not wildcard domain names.

3.3.2 Closest Encloser and Source of Synthesis Examples

To illustrate, using the example zone in section 2.2.1:

For a query name of "host.example.", the closest encloser is "example." and the source of synthesis is "*.example.".

For a query name of "a.host.example.", the closest encloser is "host.example." and the source of synthesis would be "*.host.example.", except that this wildcard domain name is not a part of the zone and does not exist.

For a query name of "_telnet._tcp.host.example.", there is an exact match, and there is no source of synthesis. This is because an exact match has priority over wildcard matching.

For a query name of "_dns._udp.host.example.", the closest encloser is "host.example." and the source of synthesis is "*.host.example.", except that this wildcard domain name does not exist in the zone and there is no source of synthesis.

For a query name of "*.example.", there is an exact match, and there is no source of synthesis.

For a query name of "a..example.", the closest encloser is ".example." and the source of synthesis is "..example.", which does not exist in the zone, so there is no source of synthesis.

For a query name of "_telnet._tcp..example.", the closest encloser is ".example." and the source of synthesis is "..example.", which does not exist in the zone, so there is no source of synthesis.

For a query name of "host3..example.", the closest encloser is ".example." and the source of synthesis is "..example.", which does not exist in the zone. There is no source of synthesis. What is instructive in this case is that "host3.*.example." exists, but is not a source of synthesis for itself or any other name.

The point in these examples is not what the name servers would answer as an authority (whether an answer, or referral or NXDOMAIN or NOERROR/NODATA), but the identification of the closest encloser and source of synthesis.

3.3.3 Type Matching

RFC 1034, section 4.3.3, says:

# 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.

And

# 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.

The first quoted section describes synthesizing records from the wildcard RRSet by changing the owner name of the RR. The second quoted section says to "match RRs ... against QTYPE" and only copying when matching. Clearly, only the RRs of type QTYPE can be copied, as is the case for all name matches. There is never a CNAME match when QTYPE is not CNAME (or if QTYPE is ANY). The existence of a CNAME prevents the existence of any other types.

In the case of a wildcard CNAME, the CNAME RRSet does not match non-CNAME queries and is not used for synthesis. This is akin to a CNAME RRSet present in a terminal node being ignored when the type sought is not CNAME or ANY.

For wildcard CNAME RRSets, the statement describing synthesis has been changed, as from RFC 1034:

# 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.

To:

# 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.
# If QTYPE is CNAME, continue with step 3.d.
# If QTYPE is not CNAME and a CNAME RRSet exists at the node,
# copy the CNAME RRSet into the answer section,
# but set the owner of the RRSet to be QNAME,
# and not the node with the "*" label.
# Go to step 6.

The confusion is caused by this paragraph in RFC 1034:

# To illustrate the use of wildcard RRs, suppose a large company with
# a large IT staff wanted to provide a TELNET gateway

The confusion is caused by an example that seems to imply that a CNAME RR synthesized from a wildcard is then used to obtain an address to answer an A query. One interpretation is that wildcards are a kind of "macro expansion", and the example is how one would answer an A query when there is a wildcard CNAME. Another interpretation is that it is a special case. A third interpretation is that wildcards should be expanded when zone data is loaded into the server, and then applied without the special expansion rules.

The working group has adopted the position that the example is anomalous and serves to confuse rather than educate. By changing the wording of the algorithm, the example is revealed to be an incorrect usage of wildcards.