4. Considerations with Special Types

This is a summary of the actions for various types. Most of these provisions are due to whether RRs of a type may coexist or not. Some are simply observations.

4.1 SOA RRSet at a Wildcard Domain Name

A wildcard domain name owning an SOA RRSet means that the domain is at the apex of the zone and is a wildcard domain name. This is a refinement of the definition of SOA in RFC 1035, in which the SOA RR is present at the apex of the zone. This is a clarification only; there is no intention to signal a change in the specification.

Ownership of SOA records by a wildcard domain name has undefined effect. To avoid a situation in which wildcards are used to synthesize SOA records, an SOA record MUST NOT be the only record at a wildcard domain name.

This prohibition has implications for AXFR and IXFR, which are not discussed here.

4.2 NS RRSet at a Wildcard Domain Name

RFC 1034 places a restriction on the ownership of NS records in section 4.2.2:

# If a CNAME RR is present at a node, no other data should be
# present; this ensures that the data for a canonical name and its
# aliases cannot be different.  This rule also insures that a
# cached CNAME can be used without checking with an authoritative
# server for other RR types.

There is an important distinction to be made between a delegation point name and a domain name that appears in the RDATA of a delegation. The former is a name that has an NS RRSet; the latter is a name that may have A or AAAA RRSets. For example, with the delegation:

  foo.example. NS ns1.example.
  ns1.example. A 192.0.2.1

the name "foo.example." is the delegation point name, and "ns1.example." is a name that appears in the RDATA. The name "foo.example." has an NS RRSet. The name "ns1.example." has an A RRSet. This is a very important distinction, as wildcard synthesis can apply to the latter but not the former.

A wildcard domain name is not a delegation point. Synthesis of an NS RRSet has not been defined. Some previous DNS work considered allowing synthesis of delegation points, but this possibility has been rejected. RFC 1034 says:

# A particular subzone and the associated NS RRs are added to the
# zone when the domain administrator decides to delegate the
# subzone, by adding the subzone's NS RRs to the parent zone.

The decision to delegate is made when the NS RRs are added to the zone. The phrase "adding NS RRs to a zone" has been interpreted to mean that delegation points are added by explicit configuration. The term "wildcard" does not appear in the delegation portion of RFC 1034 (section 4.2.2). Thus, wildcards are intentionally not to be used for NS RRs.

With synthesis of NS not allowed, there is no additional work for the server performing synthesis.

4.2.1 Discarded Notions

At one time, there was a distinction made between synthesizing a delegation point, synthesizing in-zone data, and synthesizing name server names. As this document specifies that the synthesis of a delegation point is not permitted, there is no need to explore this distinction further. Similarly, there is no need to make a distinction between in-zone wildcard matches and matches of name server names.

4.3 CNAME RRSet at a Wildcard Domain Name

The interaction of CNAMEs and wildcards is updated in section 3.3.3 of this document. A CNAME RRSet at a wildcard domain name can only be used to synthesize CNAME RRs. A wildcard domain name that owns a CNAME RRSet cannot own any other resource records.

4.4 DNAME RRSet at a Wildcard Domain Name

Ownership of a DNAME [RFC2672] RRSet by a wildcard domain name represents a threat to the coherency of the DNS and is to be avoided or outright rejected. Such a DNAME RRSet represents non-deterministic synthesis of rules fed to different caches. As caches are fed the different rules (in an unpredictable manner) the caches will cease to be coherent. ("As caches are fed" refers to the storage in a cache of records obtained in responses by recursive or iterative servers.)

For example, assume one cache, responding to a recursive request, obtains the following record:

  "a.b.example. DNAME foo.bar.example.net."

and another cache obtains:

  "b.example.  DNAME foo.bar.example.net."

both generated from the record:

  "*.example. DNAME foo.bar.example.net."

by an authoritative server.

The DNAME specification is not clear on whether DNAME records in a cache are used to rewrite queries. In some interpretations, the rewrite occurs; in others, it does not. Allowing for the occurrence of rewriting, queries for "sub.a.b.example. A" may be rewritten as "sub.foo.bar.tld. A" by the former caching server and may be rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is lost, and an operational nightmare ensues.

Another justification for a recommendation to avoid the use of wildcard DNAME records is the observation that such a record could synthesize a DNAME owned by "sub.foo.bar.example." and "foo.bar.example.". There is a restriction in the DNAME definition that no domain exist below a DNAME-owning domain; hence, the wildcard DNAME is to be avoided.

4.5 SRV RRSet at a Wildcard Domain Name

The definition of the SRV RRset is RFC 2782 [RFC2782]. In the definition of the record, there is 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.

Do not confuse the definition "Name" with the owner name. That is, once removing the _Service and _Proto labels from the owner name of the SRV RRSet, what remains could be a wildcard domain name but this is 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 is the Name of the SRV RR, it is not 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 result in a match of the name ".example." (assuming there is no bar.example.) and not a match of the SRV record shown. If there is no SRV RRSet at ".example.", the answer section will reflect that (be empty or a CNAME RRset).

The confusion is likely based on the mixture of the specification of the SRV RR and 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 (no corresponding DNSKEY RRSet will be used in DNSSEC validation). If there is a synthesized DS RRSet, it alone will not be very useful as it exists in the context of a delegation point.

4.7 NSEC RRSet at a Wildcard Domain Name

Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet. Synthesis of these records will only occur when the query exactly matches the record. Synthesized NSEC RRs will not be harmful as 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 will be present at a wildcard domain name in a signed zone and will be synthesized along with data sought in a query. The fact that the owner name is synthesized is not a problem as the label count in the RRSIG will instruct the verifying code to ignore it.

4.9 Empty Non-terminal Wildcard Domain Name

If a source of synthesis is an empty non-terminal, then the response will be one of no error in the return code and no RRSet in the answer section.