Re: bind timeouts

On 18 May, Matthew D. Fuller wrote:
> On Tue, May 18, 2004 at 08:14:04AM +0200 I heard the voice of
> Christian Hiris, and lo! it spake thus:
>> 
>> As far as i know MX records _must_ have an A record.
> 
> RFC1035 states:
>     MX records cause type A additional section processing for the host
>     specified by EXCHANGE.  The use of MX RRs is explained in detail
>     in [RFC-974].
> 
> RFC974 says:
>     There is one other special case.  If the response contains an
>     answer which is a CNAME RR, it indicates that REMOTE is actually
>     an alias for some other domain name. The query should be repeated
>     with the canonical domain name.

That covers the intial lookup, meaning that a CNAME pointing to an MX is
legal.

Pointing an MX at a CNAME is likely to break the RFC 974 mail loop
prevention algorithm.  Just below the paragraph you quoted:

   If the response does not contain an error response, and does not
   contain aliases, its answer section should be a (possibly zero
   length) list of MX RRs for domain name REMOTE (or REMOTE's true
   domain name if REMOTE was a alias).  The next section describes how
   this list is interpreted.

[ snip ]

   It is possible that the list of MXs in the response to the query will
   be empty.  This is a special case.  If the list is empty, mailers
   should treat it as if it contained one RR, an MX RR with a preference
   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
   MX).  In addition, the mailer should do no further processing on the
   list, but should attempt to deliver the message to REMOTE.  The idea
   here is that if a domain fails to advertise any information about a
   particular name we will give it the benefit of the doubt and attempt
   delivery.

   If the list is not empty, the mailer should remove irrelevant RR's
   from the list according to the following steps.  Note that the order
   is significant.

      For each MX, a WKS query should be issued to see if the domain
      name listed actually supports the mail service desired.  MX RRs
      which list domain names which do not support the service should be
      discarded.  This step is optional, but strongly encouraged.

The WKS lookup is deprecated ..

      If the domain name LOCAL is listed as an MX RR, all MX RRs with a
      preference value greater than or equal to that of LOCAL's must be
      discarded.

This is the important part.  If an MX points to an alias for LOCAL, the
MTA may fail to trim this MX record (and the MX records with the same or
greater preference values) from the list, which may cause the MTA to
connect to itself in an attempt to deliver the message, or it may cause
the MTA to attempt to deliver the message using an MX record with a
higher preference number, which might loop the message right back to
this host.

The only ways of preventing this undesirable behavior are: 

        Configure the MTA with a list of all the aliases (CNAMEs) for
        LOCAL.  The MTA must be reconfigured whenever an alias is added
        or deleted.

        Look up the IP addresses for the domain names listed by the
        MX records an compare the list of IP addresses to the IP
        addresses of the MTA host.  This may require a number of DNS
        queries to be made before the first delivery attempt can be
        made.  It is not possible to attempt delivery if a domain name
        specified by one of the MX RRs with the lowest preference value
        is unresolvable due to a temporary DNS failure.

Example of the latter problem:

$ORIGIN example.com.
	IN MX	0	mail.subdomain1.example.com.
	IN MX	10	mail.subdomain2.example.com.

Using the latter anti-looping algorithm, the MTA must do a DNS lookup of
the IP address(es) of mail.subdomain1.example.com to verify that a
delivery attempt to mail.subdomain1.example.com would not connect back
to the local host.  If the MTA is unable to resolve the IP address(es)
of mail.subdomain1.example.com, it must not attempt to deliver the
message to mail.subdomain2.example.com because this could result in a
mail loop.

Disallowing MX RRs from pointing to CNAMEs and only using the official
host name means that the MTA can just do a simple string comparision to
prevent a loop.

> RFC2821 obsoletes 974, but says substantially the same in regards to
> CNAME's.  So, by the RFC's it's allowed.

RFC 2821 modifies this part of RFC 974:

   If it determines that it should relay the message without rewriting
   the address, it MUST sort the MX records to determine candidates for
   delivery.  The records are first ordered by preference, with the
   lowest-numbered records being most preferred.  The relay host MUST
   then inspect the list for any of the names or addresses by which it
   might be known in mail transactions.  If a matching record is found,
   all records at that preference level and higher-numbered ones MUST be
   discarded from consideration.  If there are no records left at that
   point, it is an error condition, and the message MUST be returned as
   undeliverable.  If records do remain, they SHOULD be tried, best
   preference first, as described above.

Which seems to say that the MTA must do IP address lookups on the names
specified by the MX records ...