Re: Beating the spam filter ...

On 08/03/06 15:37, Bill Cole wrote:
In the end, the RFC's describe how to be interoperable. The RFC's that touch on the matter agree that pointing an MX at a name that has a CNAME record is bad practice.

I'll agree to that.

Consider a small company that hosts email and the likes for many clients. Presume if you will that the zone file for each of the company's clients uses the name of the hosting company's SMTP server as it's own SMTP server. I.e. client-domain-1.tld IN MX mx.hosting-company.tld.

Now consider if you will the desire of the hosting company to have a level of abstraction for the host name of mx.hosting-company.tld such that they can freely move the SMTP service from host to host, or add additional hosts to a pool with out the need to update all the client DNS zones. Thus the hosting-company uses a CNAME for mx.hosting-company.tld to reference the back end SMTP servers that they want their clients to use at the time.

How is this any easier with CNAME's than A's? How is it not *more complicated* with CNAME's?

This may or may not be easier to set up, but it is easier to maintain down the road. Presume that the company is hosting email for 1000 (other) domains. Would it be easier to update the DNS RR for one company or all 1000 companies in addition to the main record for the hosting company?

It is perfectly reasonable and common to have multiple A records for one name. It is dead wrong to have multiple CNAME records for one name. It is perfectly reasonable to have multiple names with A records resolving to the same address. Your scenario doesn't really make much sense.

What do you mean by "... dead wrong to have multiple CNAME records for one name. ..."? Do you mean to say that it is wrong to have the following?

host.company.tld. IN A 1.2.3.4
ftp.company.tld. IN CNAME host.company.tld.
smtp.company.tld. IN CNAME host.company.tld.
pop3.company.tld. IN CNAME host.company.tld.
imap.company.tld. IN CNAME host.company.tld.
www.company.tld. IN CNAME host.company.tld.

If this is indeed wrong (in your opinion), I invite you to re-read part of RFC 1912 towards the bottom of page 6. Here is the pertinent quote:

"... Don't go overboard with CNAMEs. Use them when renaming hosts, but plan to get rid of them (and inform your users). However CNAMEs are useful (and encouraged) for generalized names for servers -- `ftp' for your ftp server, `www' for your Web server, `gopher' for your Gopher server, `news' for your Usenet news server, etc. ..."

In this case, the RFC suggests ("... encouraged ...") that such CNAMEing be done.

What do you think?

I would be willing to agree that RFC 1912 discourages using CNAMEs to provide alternate names for hosts on things other than ""service names. If you rename a host it is acceptable to use a CNAME for the old name for a while but "... plan to get rid of them ...".

What do you mean by "... It is perfectly reasonable to have multiple names with A records resolving to the same address. ..."? Would you use A records with the same IP address in all the records above? I personally believe (that is to say my opinion is) that this is bad form to do so. My problem with the multiple A records is that it leads to ambiguity as to what the real host name is as reported by "hostname -f".

Not really a questionable reason at all. Complex mail systems always need to beware of the risk of their MX responses breaking the size limit on UDP DNS. Layering abstraction unnecessarily and adding in a need to include the CNAME and A records in an MX response raises the risks of hitting that wall.

"... Not really a questionable reason at all. ..." is your opinion. Mine is that it is questionable. I would be willing to bet that we are both gentlemen enough to agree to disagree on this issue.

How is the UDP length limit any different for MX records than it is for any other record? (I have a theory, but I want to see what you say first.) If there were indeed unnecessary layers of abstraction added, I would agree. However, if the layers are needed for some sort of company structure layout (reasonability of such a structure aside) I would not consider such unnecessary.

Which is a far less problematic situation than the MX->alias one, which actually will not be followed by some resolvers. Asymmetrical A/PTR resolution is not a circumstance that causes anything to not work, absent very unwise forms of paranoid configuration.

Unfortunately such "... very unwise forms of paranoid configuration. ..." is becoming more and more common place in spam filtering.

And of course such a mismatch is easily avoided. There's nothing wrong with an address having multiple PTR's.

If you have multiple names resolve to the same address and the same address resolve to multiple names how do you know which name is the real name of the host verses those that are aliases? What if such a host committed some sort of abuse (spam, attack, misconfiguration, etc) where an administrator of the system being abused needs to contact the administrator of the abuser. What sort of confusion would ensue if a single IP address reverse resolved to 10 names? What if it was 100, or even 1000 names? How many names can fit in the UDP packet before the length is exceeded?

Why would you NEED to change that name in that usage?

*cough* *blink* *blink* *cough*

If there are 100 domains (DNS zones) that are using the same mail server and the server's IP changes, you would have to update ALL the zones. That is unless the MX records for the zones used a CNAME to point to the mail server's FQDN in another domain. In this case, only one name would have to be updated.

That's a serious question. Remember: there's no reason not to have multiple names with A records pointing to the same address and multiple PTR records for an address pointing to different names. The CNAME only serves to get in the way.

I disagree.

a.b.c. IN A 1.2.3.4
d.e.f. IN A 1.2.3.4
g.h.i. IN A 1.2.3.4
j.k.l. IN A 1.2.3.4
m.n.o. IN A 1.2.3.4
p.q.r. IN A 1.2.3.4
s.t.u. IN A 1.2.3.4
v.w.x. IN A 1.2.3.4

4.3.2.1.in-addr.arpa. IN PTR a.b.c.
4.3.2.1.in-addr.arpa. IN PTR d.e.f.
4.3.2.1.in-addr.arpa. IN PTR g.h.i.
4.3.2.1.in-addr.arpa. IN PTR j.k.l.
4.3.2.1.in-addr.arpa. IN PTR m.n.o.
4.3.2.1.in-addr.arpa. IN PTR p.q.r.
4.3.2.1.in-addr.arpa. IN PTR s.t.u.
4.3.2.1.in-addr.arpa. IN PTR v.w.x.

Can you tell me which one is the real FQDN of the host as reported by "hostname -f"?

Now consider:

a.b.c. IN A 1.2.3.4
d.e.f. IN CNAME a.b.c.
g.h.i. IN CNAME a.b.c.
j.k.l. IN CNAME a.b.c.
m.n.o. IN CNAME a.b.c.
p.q.r. IN CNAME a.b.c.
s.t.u. IN CNAME a.b.c.
v.w.x. IN CNAME a.b.c.

4.3.2.1.in-addr.arpa. IN PTR a.b.c.

Can you tell me which one is the real FQDN of the host as reported by "hostname -f"?

Aside from its application to classless reverse delegation and a few other very narrow cases, the CNAME record type has not really turned out to be a wise inclusion in DNS.

I strongly disagree on this. However I again think we can agree to disagree.

Now you may say, what is wrong with having multiple A records resolve to one (or more) IPs that do not reverse resolve back to the original name?

Why yes, I would, although I see no reason for them not to have reverse resolution...

To answer the question that I asked on your behalf. Why not use a CNAME that indicates that the name that you are using is NOT the fqdn of the system you are trying to reach.

The reason I see is the ambiguity created by the above scenario.

Everyone is entitled to their opinions. Your opinion is not well-grounded in the coverage of the two issues in the DNS formal spec.

Indeed.

You are free to believe that the world is flat as well...

No, NO, NO! The world is a 5 sided object!

That's an amazingly anachronistic view, and it doesn't fit the design of DNS (which could have been far simpler if that principle had been intended as mandatory, rather than simply common practice.) Have you thought it through and looked at the ways it is not followed by many millions of names? (hint: HTTP name-based virtual hosts)

Am I parachronistic or prochronistic? Can you please explain how my view does not fit the design of DNS?

host.consultant.tld. IN A 1.2.3.4
www.consultant.tld. IN CNAME host.consultant.tld.
www.client.tld. IN CNAME host.consultant.tld.
www.personal.tld. IN CNAME host.consultant.tld.

I *think* I have thought it through fairly well. Oh, let's not forget:

4.3.2.1.in-addr.arpa. IN PTR host.consultant.tld.

This seems fairly straight forward and unambiguous to me. Maybe I should have stated more clearly that just because "... a (normal) host has EXACTLY 1 (ONE) FQDN. ..." does not mean that there can not be CNAMEs that resolve to the said FQDN.

I think your argument is grounded in a tenet of faith that is not consistent with the design of DNS and leads you to view a practice that has been considered a poor one for all of the 20 years that MX records have existed as an acceptable one.

As I stated last night before I went to sleep, I will agree with this. However, I am interested in, if you will, your explanation of the design goals of DNS and how I'm not being consistent. Will you please do me the honor of such an explanation?



Grant. . . .


P.S. Please do not let my strange attempts of respect and humor to come off as flame bait as that is not the case at all. Apologies around if that is how they were received.
.

Relevant Pages

  • Re: Beating the spam filter ...
    ... touch on the matter agree that pointing an MX at a name that has a CNAME ... of abstraction for the host name of mx.hosting-company.tld such that they ... to a pool with out the need to update all the client DNS zones. ... It is dead wrong to have multiple CNAME records for one name. ...
    (comp.mail.sendmail)
  • Re: MX-only domains dying?
    ... I've always thought of the www host as being an artifact of the good old days of the web where DNS was used as part of the maintenance methodology - if you needed to service a box you switched the IP in DNS to the hot spare. ... Using service names allows you to have each respective serviceresolve to different address, thus allowing you to spread services across different hosts. ... If you are wondering why I have A records for domainN.tld verses a CNAME record, I have never been able to get CNAME records to co-exist with any other record type for a given name. ...
    (comp.mail.sendmail)
  • Re: FW: DNS Question
    ... Subject: DNS Question ... record for new domains we host instead of a CNAME. ... CNAME only that does not at some point to a valid A record. ... Changing an include file changes all the zone files that include it, ...
    (freebsd-questions)
  • Re: DNS Question
    ... I have been asked by my co-workers and sales why I always create a A record for new domains we host instead of a CNAME. ... Somewhere, in a class far far away, I was taught a DNS zone had to have a A record to function properly. ...
    (freebsd-questions)
  • Re: Porblems with Lycos.com host lookup.
    ... See RFC 1034 and RFC ... 3600 IN CNAME mail-bigmail1.bo3.lycos.com. ... Host bigmail1.lycosmail.lycos.com not found: 2 ... ers: info: FORMERR resolving 'http://bigmail1.lycosmail.lyco= ...
    (comp.protocols.dns.bind)