So, for an ignoramus such as me, does that mean that an SRV record
starting with _http. could be used to redirect HTTP in a clean way?
Presumably, however, the WREC community needs finer granularity than that.
Brian
ned.freed@innosoft.com wrote:
>
> > > 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