From owner-freebsd-current@FreeBSD.ORG Tue May 18 01:04:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6E9616A4CE for ; Tue, 18 May 2004 01:04:22 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1DB443D1D for ; Tue, 18 May 2004 01:04:18 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i4I8477E019740; Tue, 18 May 2004 01:04:11 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200405180804.i4I8477E019740@gw.catspoiler.org> Date: Tue, 18 May 2004 01:04:07 -0700 (PDT) From: Don Lewis To: fullermd@over-yonder.net In-Reply-To: <20040518063753.GB2038@over-yonder.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: 4711@chello.at cc: freebsd-current@FreeBSD.org cc: cyrille.lefevre@laposte.net Subject: Re: bind timeouts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 08:04:22 -0000 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 ...