Re: Beating the spam filter ...

In article <70a8a$44d3f411$d08d6db4$24045@xxxxxxxxxxxxxxx>,
"Taylor, Grant" <gtaylor@xxxxxxxxxxxxxxxxx> wrote:

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?

No, you just don't change that name. There's no reason to do so. Change
the A record to point to a new address, or have each domain point to a
name in their own domain so they can point it where they please.


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.

No, I meant the other way around. An alias name cannot have multiple
canonical names. A name that is the LHS of one CNAME cannot be the LHS
of any other records.


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?

Well, I think RFC1912 is flawed in a few ways when you try to apply it
to the modern world. In some ways it was an essay on running an academic
network in the mid-90's.


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?

Yes.

I personally
believe (that is to say my opinion is) that this is bad form to do so.

People have all sorts of odd personal beliefs.

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".

I don't run any systems where hostname takes a -f flag, but I suspect it
is probably akin to the POSIX uname -n. A nodename.

It is important to note that when the "nodename" concept was originated,
Unix networking mostly meant UUCP, a networking system where the One
True Name concept was very important and applied quite strongly.

DNS really doesn't enforce or even really encourage that concept, and
common practices have made it increasingly pointless to publish the
nodename of a host publicly in association with any specific service.
Maybe a MTA will banner and HELO with its nodename, but pointing MX
records at it is a bit restrictive.

[...]
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.

MX records have absolutely nothing to do with outbound mail, so I'm not
sure of the relevance. The typical uses I'm aware of for using DNS
symmetry checking in spam filtering tend to start with the HELO argument
or reverse DNS from the connecting IP address, not a name from the RHS
of any MX. What sort of filtering are you thinking of?

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?

Why do you care about the "real name" so much?

Certainly any Unix-ish machine will have a nodename, but there's no
reason that it needs to be ANY of the names found through rDNS of any of
its public IP addresses, much less the IP's on which it happens to be
listening on port 25 because there are MX's leading there.

For over a decade, scconsult.com has had the same primary MX record
pointing at sc1.scconsult.com. There has never been a machine accepting
that mail with that nodename at the OS level, and that's been 3 distinct
machines using 7 different IP addresses for the name over the years.
This causes no trouble. It does mean I can make another machine into my
primary mail exchanger without changing any DNS records.

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.

Not so. If they are pointing at the same name, and the IP changes, one A
record in one zone needs to change. The MX records stay the same. They
point at the name, not the IP.

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.

The CNAME in that scenario serves no purpose for an IP change. It only
helps if you want to change the "real name" of the mail server.

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"?

$ hostname -f
hostname: illegal option -- f
usage: hostname [-s] [name-of-host]

Why do you want me to change my nodename to "-f" I wonder... :)

(true story: 2 years ago a colleague with a Linux book and a data center
full of Sun machines changed all their nodenames to "-a" in the middle
of the day with a poorly tested script... )

I generally don't let random strangers who want to mail me run anything
on my machines, so they have no business caring about what happens if
they were to run 'hostname' with or without flags. I see no compelling
reason to differentiate nodenames clearly in DNS.

Another consideration: a host may not even have it nodename associated
with any IP address that it has an MTA listening on.

[...]

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.

Why not? Because it causes some resolvers to not find the IP address
that they should connect to for mail delivery. That should not happen if
the universe was following the Postel Robustness Principle, but they
don't, and pointing MX's at aliases certainly does not qualify as
"conservative" anyway...

The fact that it has been a deprecated practice for 20 years in RFC's is
secondary.

[...]
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?

DNS allows multiple A records for a name and multiple PTR records for
addresses. There is no prohibition of or even recommendation against
publishing multiple names in DNS for a host equivalently. In fact, as
you've demonstrated, a principle that a host must have one dominant name
expressed in DNS interferes with following other rules that are
explicitly stated.

--
Now where did I hide that website...
.

Relevant Pages

  • 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: Use of FQDN in key (Was: Solaris 10)
    ... If its one host or your own private network, ... DNS, ... >>There may be hosts from multiple subdomains in one realm. ... Argonne National Laboratory ...
    (comp.protocols.kerberos)
  • Re: Beating the spam filter ...
    ... 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. ... It is perfectly reasonable to have multiple names with A records resolving to the same address. ...
    (comp.mail.sendmail)
  • Re: New DNS Setup
    ... DNS service and configured a new primary zone named mydomain.net ... the hostname to resolve? ... Do I need an A record or anything or is the single CNAME ... If you are pointing the CNAME to the DNS server's host name, ...
    (microsoft.public.windows.server.dns)
  • Re: Use of FQDN in key (Was: Solaris 10)
    ... >> i.e. host names in Kerberos are always FQDN. ... > DNS works perfectly, ... There may be hosts from multiple subdomains in one realm. ... a host may have multiple IP addresses. ...
    (comp.protocols.kerberos)