Subject: Re: Wildcards and SRV records

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 11 Oct 1998 20:59:44 -0400

I don't recall seeing any answer to the message below.  Inability to
do SRV wildcarding seems like a defect.  Extending * to permit one
star label either at the beginning or interior to me owner name seems
to fix that.  I don't see any particular advantage in all the "_"
restrictions suggestyed below.  But if an interior "*" acts pretty
much like current wildcards and returns an answer with a complete
synthesized name, you have a real problem with DNSSEC.  In particular,
the SIG covering the wildcard RR in the zone covers the form with the
"*" (since you can't precalculate signatures over the approximately
infinite number of substitutions that could occur).  With just a
leading *, this is easy because there are not many possibilities and
the original length is encoded into the SIG.  But with an interior
star, either SIG would have to change to permit more information about
the original owner name or you need to start just returning the
wildcard name for without substitution...

Thanks,
Donald

From:  Andrew Draper <[email-masked]>
Message-ID:  <[email-masked]>
To:  "Namedroppers mailing list" <[email-masked]>
Date:  Mon, 7 Sep 1998 16:21:10 +0100 
Sender:  [email-masked]

>The current DNS specs allow for the use of wildcard records to "fill in" host 
>names which do not exist, for example:
>
>*.madge.com.            IN  MX 50 mailserver.madge.com.
>
>If I were to try and do this using the SRV record then I suppose that I would
>end up with a record such as:
>
>_smtp._tcp.*.madge.com. IN SRV 50 0 25 mailserver.madge.com.
>
>By my reading of RFC1034 this is illegal (wildcards can only appear as the
>first label in an name).
>
>While this does not seem useful in the case of SMTP (the owner of a domain
>could just use MX records instead) there are probably other protocols where
>wildcard records will be needed.  One example is h.323, where a lookup for
>SRV records is being proposed as the method of resolving an email-address
>into the address of a server which can be used to contact the person
>specified.
>
>To implement this I suggest that we should define a new type of wildcard
>record - for the sake of description call this a non-underscore wildcard and
>represent it as "*_" within zone files (although better names and
>representations are probably possible).
>
>The non-underscore wildcard is allowed to be present as the leftmost label
>of a name, or following one or more labels which start with underscores, but
>not following labels which don't start with underscores.  Only one
>non-underscore wildcard is allowed in a name.
>
>The non-underscore wildcard matches one or more labels which don't start
>with an underscore, providing that the labels to the left and right of the
>wildcard all match.
>
>Obviously, implementation of the non-underscore wildcard would be optional
>for a server, and transparent for a client.  It requires no changes to bits
>on the wire.
>
>It does however mean that it must be possible for a server to tell whether a
>label is part of a standard domain label or is the service or protocol value
>for a SRV lookup.  I would thus prefer that the underscores remain in the
>definition of the SRV record.
>
>Is the non-underscore wildcard a good idea?
>
>Regards,
>
>    Andy.
>
>-- 
>Andrew Draper - Principal Development Engineer - WAVE Software
>Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks.
>mailto:[email-masked]  phone:+44 1753 661329
>pgp fingerprint D6 ED 72 4F 96 BB CA 2D  68 74 4C E0 CB B9 0B 3F