> > I think there is one "bug": In section 3.6 you are saying that
> > SRV records can achieve a diversion mechanism similar to MX records.
> > I don't think that is the case since it would require non-terminal
> > wildcards as in
> > _ftp._tcp.*.example.com
> > to do a diversion akin to MX records - such things are not allowed in
> > the DNS.
> The MX wildcard doesn't work the way people think. It only matches if there
> is no other record with the same name, for example an A record or CNAME. It
> is also the case that the wildcard only works when the wildcard itself is
> the first label in the name, and not third like the example above for what
> one wants in SRVs.
The way I've dealt with this for MX records is to use a preprocessor to
generate the database for the domain. The preprocessor has rules that tell it
when *.foo.com is specified and a.foo.com appears as an A or CNAME without its
own MX to add an explicit MX entry for a.foo.com that duplicates the wildcard
entry's value. It is a reasonably straightforward thing to do. And besides, you
want to run your tables through a preprocessor to make sure there are PTR
records for all the A records and similar boring stuff.
I see no reason why a similar preprocessor could not be used to generate
the necessary SRV records so that wildcard SRV records appear to work.
> For operations with DNS in Sweden, I have only seen one place where MX
> wildcards really work, and that is when you have a domain which is not at
> all connected to the Internet, and mail is going for that domain (and
> sub-domains) via UUCP or such non-internet protocols. THEN one can create
> the wildcard MX. In all other cases, you can get so confused by the
> matching rules between wildcard in MX and other RR types that I always
> recommend people to if nothing else generate the resource records they need.
FWIW, one place where we've found simple wildcard MX entries to be quite useful
is to map the subdomains of a given system's name back onto itself. We
routinely use such subdomains to provide various special email services
(gateways to other mail systems, for example), and since this segment of the
namespace never has A records in it that correspond to these service names we
don't have a problem with the limited scope of MX wildcards. And perhaps more
to the point, it saves us having to mess with the DNS every time one of these
services gets defined. This can be a big win, especially when dealing with a
site where the DNS stuff is managed by different people than the mail systems
and the DNS people are, shall we say, less than responsive to change requests.
> I.e. what one wants (normally) is to have all mail to all subdomains to a
> parent domain go to the same host. You don't want arbitrary tokens (also
> non-existing subdomains) to go to the mail host, because the error to the
> sender of the email might be confusing, and not reflect the existence of
> the subdomain or not.
> So, yes, wildcards are somewhat useful, but MX wildcards doesn't work well,
> and no, we don't have wildcards for SRV records, BUT one can quite easilly
> generate all RR one need in the scripts one have anyways(?) to keep the
> zones together. I.e. this doesn't need to be a function of DNS, but the
> tool one uses to keep the zone up to date.
Exactly. And not only is generating explicit entries of this sort fairly
simple, it keeps a bunch of wildcard handling complexity out of the DNS server
itself. And that I view as a Good Thing -- we're well past the point where all
the extra entries you end up with as a result of this are significant, whereas
the deployment costs of bug fixes for broken wildcard handling code grow
more significant every day.
Ned
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST