Subject: Update to Proposed Standard RFC 2181

From: "Rick LeMarr" <[email-masked]>
Date: Tue, 5 Oct 1999 16:56:29 -0500

Please give consideration for request and comment...

Wildcard usage in non-terminal domain labels is unclear and current DNS
server implementations handle such records inconsistently.  RFC 1034 section
4.3.2. Algorithm, paragraph 3.c states that a wildcard may be expected at
some label.  However, section 4.3.3 has been quoted to imply usage
restriction to the left-most label.  Current and past versions of BIND do
not complain of wildcard usage in any label of a CNAME and properly
synthesize RRs in response to query.  Other DNS server implementations
result in no RR answer as is the expectation from upcoming release of BIND
9.  This update is also necessary to ensure backward compatibility for
precedent implementations of wildcard usage.

Wildcards in non-terminal labels serve a legitimate and useful purpose to
reduce the frequency of database updates and reduce the number of RRs needed
for certain domain naming strategies.  A business may have multiple remote
sites identified by 3rd level domain labels which parallel an established
naming convention.  A centralized service provider may offer several
information services such as email, directory, www, etc., identified by a
4th level domain label.  A common load balancing architecture with dedicated
hardware for each service would use the DNS to point any one service to a
single IP address.  The DNS RRs may look like this:

mail.site1.anycorp.com  IN      CNAME   mail.isp.net
mail.site2.anycorp.com  IN      CNAME   mail.isp.net
mail.isp.net    IN      A       10.20.30.40

ldap.site1.anycorp.com  IN      CNAME   ldap.isp.net
ldap.site2.anycorp.com  IN      CNAME   ldap.isp.net
ldap.isp.net    IN      A       10.20.30.41

www.site1.anycorp.com   IN      CNAME   www.isp.net
www.site2.anycorp.com   IN      CNAME   www.isp.net
www.isp.net     IN      A       10.20.30.42

ftp.site1.anycorp.com   IN      CNAME   ftp.isp.net
ftp.site2.anycorp.com   IN      CNAME   ftp.isp.net
ftp.isp.net     IN      A       10.20.30.43

irc.site1.anycorp.com   IN      CNAME   irc.isp.net
irc.site2.anycorp.com   IN      CNAME   irc.isp.net
irc.isp.net     IN      A       10.20.30.43

If anycorp.com remote sites were frequently created and deleted
corresponding DNS updates would be necessary.  The DNS maintenance can be
mitigated by using a wildcard in the 3rd node label:

Mail.*.anycorp.com      IN      CNAME   mail.isp.net
Ldap.*.anycorp.com      IN      CNAME   ldap.isp.net
www.*.anycorp.com       IN      CNAME   www.isp.net
ftp.*.anycorp.com       IN      CNAME   ftp.isp.net
irc.*.anycorp.com       IN      CNAME   irc.isp.net

The following changes to RFC 2181 seek to reinforce wildcard handling as
specified in the DNS standard:

1. Abstract

   This document considers some areas that have been
   identified as problems with the specification of the
   Domain Name System, and proposes remedies for the
   defects identified.  Eight separate issues are considered:

     + IP packet header address usage from multi-homed servers,
     + TTLs in sets of records with the same name, class, and type,
     + correct handling of zone cuts,
     + three minor issues concerning SOA records and their use,
     + the precise definition of the Time to Live (TTL)
     + Use of the TC (truncated) header bit
     + the issue of what is an authoritative, or canonical, name,
     + the issue of what makes a valid DNS label,
     + and wildcard usage in non-terminal labels.

   The first six of these are areas where the correct behavior has been
   somewhat unclear, we seek to rectify that.  The other three are already
   adequately specified, however the specifications seem to be sometimes
   ignored.  We seek to reinforce the existing specifications.

12. Non-terminal Domain Label Wildcards

    Wildcard labels may be used in any label of a domain name to synthesize
RRs.
    STD 13 only limits usage to a single label of a domain name.  It is
    inappropriate to interpret examples of wildcard usage as current or
complete
    as stated in STD 13 section 1, STATUS OF THIS MEMO.  Wildcard handling
is
    adequately specified in paragraph 3.c of STD 13 section 4.3.2,
Algorithm.
    The QNAME node of the query corresponding to the wildcard node replaces
the
    wildcard node in the response.

Thank you,
Rick LeMarr

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 06 Oct 1999 10:58:48 -0700

the fact that some versions of BIND answer inconsistently is due to bugs
in BIND.  the fact that BIND doesn't reject nonterminal wildcards at the
time the zone is loaded is due to ambiguities in RFC 1035.

nonterminal wildcards would have to be completely specified, not simply
enabled, before they could be thought to work reliably.  and since a
correct implementation of (the ambiguous) RFC 1035 could refuse to handle
this case, the behaviour you want would be a protocol revision subject
to the version level arbitration of EDNS.

i personally think it's a bad idea, but that if you want to pursue it, you
have a lot of work cut out for yourself.

---

From: Bob Halley <[email-masked]>
Date: 07 Oct 1999 13:42:46 -0700

Your proposed changes to wildcards conflict with DNSSEC.

RFC 2535 section 4.1.3 describes how DNSSEC signatures work in cases
where the response is the result of wildcard substitution.  The method
used is not compatible with the '*' in any position other than the
leftmost label.

Other methods may be possible, though I suspect there would be
significant protocol complications.  Regardless of those issues,
allowing '*' in other positions would also impose a requirement for
yet more proof that there are no matching wildcards in negative
responses, further increasing the size of replies and amount of effort
required to generate them.

I think the proposed changes should not be adopted.

/Bob

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 11 Oct 1999 10:19:41 -0400

> Please give consideration for request and comment...

I have done that. 

 > restriction to the left-most label.

4.3.3 clearly outlaws multiple wildcards. 
4.3.3 examples show only at terminal labels. 
You are right it is not clear if non terminal wildcards are allowed or not.
The second question that must be asked is:
	Are non terminal wild cards a good thing or not? 

 >                                     Current and past versions of BIND do
 > synthesize RRs in response to query. 

This is actually an artifact of how BIND-[48] store names rather than 
anything explicitly written in the code (I checked). Bind stores each label
expansion in a separate hash table and if there is no match it performs
a wildcard match at all levels.

 >                                       Other DNS server implementations

There is also a document RFC2535 that specifies security extensions
to DNS. In DNSSEC there is NO allowance for non terminal wildcards.
For a good reason, it is impossible for resolver to determine from the
name in the answer where the wildcard expansion took place, thus it is 
impossible
to verify the expansion, without falling back on verifying only the name after
the wildcard. Thus if you express mail.*.some.domain it is impossible to 
retain the semantics that the terminal name can only be mail. 
And while we are on DNSSEC issues you must specify sort order for non terminal 
wildcards in a zone and think about how many NXT records must be returned when
there are multiple possible non terminal records that could be returned for 
a query of an NON existant name to prove that the name does not exist and
there is no wild card match. 

In your proposal you express that non-terminal wild cards can not expand to
multiple labels, this is a good restriction. 

Then there is the interaction of non terminal wildcards and delegations.
What are the semantics? 

 > irc.*.anycorp.com       IN      CNAME   irc.isp.net

This looks like you want to force lots more complexity into DNS to save
you from having to store a few records and not have to maintain 
accurate information in your DNS zone files. 
A simple PERL script can accomplish the same result with out any protocol 
changes.
Or even simpler approach is to use the $ORIGIN and $INCLUDE directives
in BIND to accomplish this:
A file called "services" containss following records:

mail	IN	CNAME	mail.isp.net.
www	IN	CNAME	www.isp.net.
ftp	IN	CNAME	ftp.isp.net.
ldap	IN	CNAME 	ldap.isp.net.

and your zone file contains:

$ORIGIN site1.anycorp.com.
$INCLUDE services
$ORIGIN site2.anycorp.com.
$INCLUDE services

Please consider all other alternatives before pushing on this idea, because of 
the
far reaching side effects of this on the design and implmentation of DNS 
servers.

	Olafur