secondary MX (was Re: [TriLUG] co-lo or at home?)

[Tanner Lovelace]

On Fri, 2002-03-29 at 11:22, Mike Broome wrote:
 
> Can you point to a reference for that?  

Sure.  RFC1034, section 3.6.2 and RFC1912 section 2.4.  Here's the
quote from the first one:

   The domain system provides such a feature using the canonical name
   (CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
   specifies the corresponding canonical name in the RDATA section of
   the RR.  If a CNAME RR is present at a node, no other data should be
   present; this ensures that the data for a canonical name and its  
   aliases cannot be different.  This rule also insures that a cached
   CNAME can be used without checking with an authoritative server for
   other RR types.

Notice the part "If a CNAME RR is present at a node [i.e. a domain
name], no other data should be present;"

Here is the quote from RFC1912:

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.

The reasoning behind this is illustrated in the last sentence of the
first quote I provided.  I think, however, that for cases like yours
it's probably okay, but you should be aware of this.  If you wanted to
be *completely* inside the specification, you would probably need to
point your MX record at the A record of your dynamically provided
DNS.

> I also googled around a little and nothing jumped out at me about
> avoiding having a CNAME for an MX record.  (But since there are a
> gazillion hits for CNAME and MX record, I could have easily missed it.)
> 
I did "MX CNAME problems" and found the reference on the 3rd hit. YMMV.
(Just so you know, this was the URL I found the reference in:
http://www.rscott.org/dns/cname.html)


[..my concern about using this type of setup deleted..]

> This is a valid concern and does present a potential problem.  In our
> case, the dynamic IP address from our ISP does not change very often
> which helps to minimize the issue.  Of course, as the amount of mail
> being handled goes up and/or the frequency of changing the IP address
> goes up, the chance of hitting this condition increases.
>
> AFAIK, we have had this problem.  However ... if we have hit this
> condition and the server delivering the mail silently drops the mail
> rather than retries, we would be none the wiser.  I would expect most
> mail servers to retry a number of times on error conditions rather than
> giving up after the first try.

Hmm.. I think that might be part of the spec too.  Mail servers 
are not supposed to silently drop mail.  They should keep retrying
and after some amount of time, send an e-mail back to the original
sender saying they couldn't deliver the mail.
 
> I don't think I would recommend this setup for business critical mail
> handling, especially for large quantities of mail, but for personal use,
> it seems to work just fine.

Well, as long as it works, I wouldn't try to fix it. :-)

Tanner
-- 
Tanner Lovelace | lovelace at wayfarer.org | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
GPG Fingerprint = A66C 8660 924F 5F8C 71DA  BDD0 CE09 4F8E DE76 39D4
GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
         http://www.petitiononline.com/SSSCA/petition.html
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
 Those who are willing to sacrifice essential liberties for a little 
 order, will lose both and deserve neither.  --  Benjamin Franklin 

 History teaches that grave threats to liberty often come in times
 of urgency, when constitutional rights seem too extravagant to 
 endure.  --  Justice Thurgood Marshall, 1989 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20020329/e0734809/attachment.pgp>