FW: CNAME Wildcard and Zone Propagation

[Rick LeMarr <RLEMARR@promus.com>]

Any comment or recommendations WRT STD13? 

-----Original Message-----
From:	Rick LeMarr 
Sent:	Thursday, August 12, 1999 7:19 AM
To:	'Acme Byte & Wire's Mr. DNS'
Cc:	Preston Wade; Dan Lasley
Subject:	RE: CNAME Wildcard and Zone Propagation

Thank you for your response.  Empirical evidence is not consistent with your
response.  My concern is my compliance with Internet standards.
I invite you to look at the DNS for doubletree.com:
doubletree.com  86400 IN        MX (pri=0) by
inbound.doubletree.com.criticalpath.net
doubletree.com  86400 IN        A       209.54.53.22
mail.doubletree.com     86400 IN        CNAME
mail.doubletree.com.criticalpath.net
*.doubletree.com        86400 IN        MX (pri=5) by
inbound.doubletree.com.criticalpath.net
*.doubletree.com        86400 IN        A       209.54.53.22
mail.*.doubletree.com   86400 IN        CNAME
mail.doubletree.com.criticalpath.net

This accomplishes my original goal.   If you notice the last record which is
required to resolve hostnames of the form mail.xxxxxx.doubletree.com, where
xxxxxx is any combination of legal characters for a label, this seems to be
a contradiction to your response. They do not resolve without the RR.
The STD13 notation does not specifically state that wildcards are only
allowed in the leftmost label.  It does state specifically in 4.3.2,
Algorithm that wildcard processing occurs starting with the left-most label.
More importantly, in 4.3.2.3.c it states:
	c. If at some label, a match is impossible (i.e., the corresponding
label does not exist), look to see if a the * label exists.
We did extensive testing with this with a number of variations and found
that without wildcard A record the wildcard CNAME record was ineffective.
Perhaps either I have an opportunity to understand STD13 better or STD13
could address wildcards better.
In either case, synthesized RRs are very beneficial with respect to
maintenance of DNS and STD13 lacks specificity.  Do you have any comment or
clarification?  If this apparent contradiction can be reconciled this would
be very good information to include in the FAQ.
Sincerely,
Rick LeMarr
Architect, Microsoft and Internet Engineering
Promus Hotels
(901)748-7922

-----Original Message-----
From:	Acme Byte & Wire's Mr. DNS [mailto:mr-dns@acmebw.com]
<mailto:[mailto:mr-dns@acmebw.com]> 
Sent:	Monday, July 19, 1999 6:43 PM
To:	Rick LeMarr
Subject:	Re: CNAME Wildcard and Zone Propagation


Hi, Rick.
I have a webmail interface with decentralized administration across some
1500 remote locations.  Administrative rights to create and delete accounts
are granted by subdomain with each location as its own subdomain.  I have
new subdomains coming and going daily but I don't want to update DNS RRs
every time.  It was envisioned that I could have the following DNS RRs to
enable this strategy:
mail.embassysuites.com. IN      CNAME
mail.embassysuites.com.criticalpath.net. 
mail.*.embassysuites.com.       IN      CNAME
mail.embassysuites.com.criticalpath.net. 
http://mail.xxxxx.embassysuites.com <http://mail.xxxxx.embassysuites.com>
resolves internally (BIND 4) but after submitting records to our ISPs (and
convincing them to allow it) querying any DNS server on the Internet returns
nothing.  Why?
Wildcards may only be the leftmost label of a domain name.  From
STD13/RFC1034:
The contents of the wildcard RRs follows the usual rules and formats for
RRs.  The wildcards in the zone have an owner name that controls the
query names they will match.  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 should be in the
authoritative data of the zone.  The wildcards potentially apply to
descendants of <anydomain>, but not to <anydomain> itself.  Another way
to look at this is that the "*" label always matches at least one whole
label and sometimes more, but always whole labels.

Mr. DNS
Acme Byte & Wire
mr-dns@acmebw.com <mailto:mr-dns@acmebw.com> 
www.acmebw.com/askmr.htm <http://www.acmebw.com/askmr.htm> 
Come meet Mr. DNS at our next DNS and BIND class!
See www.acmebw.com/training.htm <http://www.acmebw.com/training.htm>  for
the schedule
and to register for upcoming classes.