|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Greg A. Woods (woods
weird.com)Date: Thu Nov 01 2001 - 13:04:34 CST
[ On Thursday, November 1, 2001 at 11:37:52 (-0500), Meng Weng Wong wrote: ]
> Subject: Re: "MX->CNAME considered harmful" considered harmful.
>
> I addressed exactly this issue in my original argument. The
> complex phrasing of the above paragraph tends to
> short-circuit normal critical evaluation and produces a sort
> of cognitive kneejerk reaction.
Sorry, I missed your original argument. However my reference to the
"canonical" explanation in RFC 974 was only meant as an example. The
DNS RFCs themselves are quite explicit about this rule too and would
also have to be updated to allow the additional complexity you suggest.
There's really not a lot of difference structurally between how NS
records are defined and used than from MX RRs, except of course that NS
RRs are also self-referential in a way.
> The RFC974 scenario above lost its strength when sendmail's
> Cw was introduced. Under postfix, mydestination solves the
> same problem.
Those are hacks -- manual workarounds that should not be necessary. The
server should be able to use the DNS to figure out on its own whether or
not it's supposed to handle messages for a given target domain.
In smail though you do have to be explicit or else you get a kind of
``it looks like I'm the primary MX, but I'm not configured to handle
this domain'' bounce.... :-)
> Could you provide more details please?
>
> If the resolver instead returned only the CNAME record and
> expected the calling application to further resolve the
> canonical name to its IP address, then there would be a
> problem, because we can't expect all applications to do
> their own CNAME resolution.
That's exactly the scenario I'm proposing may exist.
For example in Smail the "raw" DNS reply is parsed and CNAMEs are
explicitly followed (if allowed by the local configuration -- there's a
feature to set the number of levels they can be followed, and it can be
set to one or zero).
I've got a couple of wimpy little SMTP test tools that do similar
relatively low-level DNS lookups too.
> But the resolver library makes CNAMEs transparent to the
> calling application, so I don't see the objection.
If you use the high-level resolver stuff, yes.... The problem is that
the high-level resolver routines (get*by*() or the newer get*info()) are
not really suitable for use in an SMTP server that cares a lot about
doing DNS checks (and barely suitable for use in an SMTP client). The
APIs are just not flexible and complete enough. That's why, for
example, Smail has its own intermediate API for doing DNS-related stuff,
which calls res_search() et al to do the actual packet pumping.
> I don't want to make things more complex. In practice I
> don't do MX->CNAME at all. What I am doing is playing
> scientist in search of The Truth; I submit that avoiding
> MX->CNAME is the postmaster's version of not stepping on
> cracks or walking under ladders.
CNAMEs necessarily make things more complex. Ideally they would not
exist. Where they are allowed now is severely limited so that DNS
administrators aren't given more rope than they really need.
-- Greg A. Woods+1 416 218-0098 VE3TCP <gwoods
acm.org> <woods
robohack.ca> Planix, Inc. <woods
planix.com>; Secrets of the Weird <woods
weird.com> - To unsubscribe, send mail to majordomo
postfix.org with content (not subject): unsubscribe postfix-users
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]