OSEC

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 (woodsweird.com)
Date: Thu Nov 01 2001 - 13:04:34 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    [ 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 <gwoodsacm.org> <woodsrobohack.ca> Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com> - To unsubscribe, send mail to majordomopostfix.org with content (not subject): unsubscribe postfix-users