Re: Beating the spam filter ...

In article <d45c6$44d18d49$d08d6db4$30149@xxxxxxxxxxxxxxx>,
"Taylor, Grant" <gtaylor@xxxxxxxxxxxxxxxxx> wrote:

On 08/02/06 23:17, Bill Cole wrote:
[...]
http://www.rfc-editor.org/rfc/rfc1034.txt section 3.6.2

What specifically are you referencing? Are you referencing the fact that
CNAMEs that point to a name in another domain should point to a canonical
name? Or are you referencing the fact that a CNAME should be the only RR
for the given name of the CNAME RR?

"Domain names in RRs which point at another name should always point at
the primary name and not the alias. "


http://www.ietf.org/rfc/rfc1912.txt section 2.4

"... [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
974] explicitly states that MX records shall not point to an alias defined
by a CNAME. This results in unnecessary indirection in accessing the data,
and DNS resolvers and servers need to work more to get the answer. If you
really want to do this, you can accomplish the same thing by using a
preprocessor such as m4 on your host files. ..."

This section seems to reference RFC 974 for the reason given above.

http://www.rfc-editor.org/rfc/rfc2181.txt section 10.3

"... The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is the
specification clear on this point, but using an alias in either of these
positions neither works as well as might be hoped, nor well fulfills the
ambition that may have led to this approach. This domain name must have as
its value one or more address records. Currently those will be A records,
however in the future other record types giving addressing information may
be acceptable. It can also have other RRs, but never a CNAME RR. ..."

This is the only case that I see in your referenced RFCs that use the
phrase "MUST NOT", which is a commonly accepted phrase to emphatically say
no, "Thou Shall Not!". Any argument that I might pose will diminish
against the "MUST NOT" phrase.

Re-read the 1912 wording.

Besides which, it is important to understand the evolution of wording in
RFC's and in the solemnity of their composition and reading over the
years. The modern formalized wording is the result of both real
confusion and people engaging textual analysis arguments about their
meaning that would make constitutional lawyers and biblical translators
eyes glaze over.

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.


However, the very next paragraph states:

"... Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless extra
queries that are easily anticipated when the first was made. ..."

Which leads me back to my belief that this "MUST NOT" statement is
motivated by the perceived need for efficiency. A need that I still hold
in question.

All very good points.

Now I pose my scenario and question for equally as thought provoking input:

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?

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.


CNAMEs, which "SHALL NOT" be used are an obvious solution for any thing
other than mail, and will work quite well for mail save for the "SHALL NOT"
(for the questionable reason).

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.

To accomplish such with out using CNAMEs, mx.hosting-company.tld would have
to use A record(s) that resolve to the IP address(es) of the current mail
server. Thus it would be extremely easy to end up with a situation where
you have an A record that resolves to an IP that does not reverse resolve
to the original name.

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.

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

Sure, you could set up all the DNS zones to point to
the canonical name of the mail server from the outset, but what do you do
when you change the mail server? Update all the DNS zones? This is
practical if you only have a few (read < 50) zones to update. Where does
this become not practical?

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

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.

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.



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

IMHO this is MORE WRONG than using a CNAME in an MX record.

Everyone is entitled to their opinions. Your opinion is not
well-grounded in the coverage of the two issues in the DNS formal spec.
You are free to believe that the world is flat as well...

It is my firm
opinion that a (normal) host has EXACTLY 1 (ONE) FQDN. Said host's name
SHOULD be the only thing that resolves to the IP(s), which reverse resolve
to the original name.

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)



So, I leave you with my response to your points, which were good. However,
I remind you of your own words, "... RFCs are not law, but they do define
ways to be inter operable. ...", while adding one word, "more". Thus, your
statement becomes "... RFC's are not lawa, but they do define ways to be
_more_ inter operable. ...". I have always viewed RFCs as being VERY good
guidelines suggestions that are usually very accurate for most. However,
seeing as how they are guidelines / suggestions, they leave things open to
interpretation and adaptation for each situation.

Comments? Suggestions? Complaints? Flaws in my (ill)logic? All the
above, please.

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.

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

Relevant Pages

  • Re: Beating the spam filter ...
    ... Are you referencing the fact that CNAMEs that point to a name in another domain should point to a canonical name? ... Or are you referencing the fact that a CNAME should be the only RR for the given name of the CNAME RR? ... 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 it would be extremely easy to end up with a situation where you have an A record that resolves to an IP that does not reverse resolve to the original 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: Deliberate DNS Poisoning
    ... I need to deliberatly poison dns queries for a "walled garden" type ... to root servers; ... to add records or delegations for the names you do want to resolve. ... 555 IN CNAME ...
    (microsoft.public.windows.server.dns)
  • Re: Can not resolve ecx.images-amazon.com.
    ... Could you please explain the steps to resolve this issue? ... Windows 2003 DNS servers and I cannot load images form amazon.com. ... An Alias (cname) record can not be added to this DNS name. ... I have no problem resolving these names with my Win2k3 or Win2k DNS servers. ...
    (microsoft.public.windows.server.dns)
  • Re: Beating the spam filter ...
    ... I'm not too sure about the PTR records though. ... Maybe a MTA will banner and HELO with its nodename, but pointing MX ... The typical uses I'm aware of for using DNS ... One general problem with CNAME records is that there isn't a solid ...
    (comp.mail.sendmail)