Re: Update of RFC 2606 based on the recent ICANN changes ?

Tony Finch <dot@dotat.at> Tue, 08 July 2008 19:02 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E64F28C2B8; Tue, 8 Jul 2008 12:02:46 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C774C28C2B1 for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 12:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ9fU-LpoWui for <ietf@core3.amsl.com>; Tue, 8 Jul 2008 12:02:43 -0700 (PDT)
Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id 22C4328C2BA for <ietf@ietf.org>; Tue, 8 Jul 2008 12:01:43 -0700 (PDT)
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38959) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1KGIRa-0003At-OV (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Tue, 08 Jul 2008 20:01:42 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KGIRa-0001V2-Ig (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Tue, 08 Jul 2008 20:01:42 +0100
Date: Tue, 08 Jul 2008 20:01:42 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: moore@network-heretics.com
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-Reply-To: <20080707133210.AWH55905@m1.imap-partners.net>
Message-ID: <alpine.LSU.1.00.0807081940180.8138@hermes-1.csi.cam.ac.uk>
References: <20080707133210.AWH55905@m1.imap-partners.net>
User-Agent: Alpine 1.00 (LSU 882 2007-12-20)
MIME-Version: 1.0
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Mon, 7 Jul 2008, moore@network-heretics.com wrote:

> > So who's going to explain to the Vatican that, sorry,
> > pope@va doesn't work any more?  Or will the US take
> > issue when addresses @as, which is part of the US,
> > don't work?  Or France about @gp and @mq, which are
> > as much part of France as Hawaii is part of the US?
>
> I'd be very surprised if any of these work as-is, with any reliability.
> They certainly won't work for email.  The assumption that fully
> qualified domain names contain at least one '.' is widespread in both
> protocol specifications and implementations.

I've been investigating this and I have discovered an oddity that I didn't
expect: Exim on my FreeBSD workstation handles TLD MXs without a problem,
but on my SuSE mail relays it fails. This is because of different
behaviours between the resolver code in the FreeBSD and GNU C libraries.
Both of them are based on the BIND resolver code so this is rather
surprising!

Exim uses res_search() to do DNS lookups. The postmaster can control the
resolver's treatment of single-component names using Exim's qualify_single
option, which controls the resolver's RES_DEFNAMES flag.

GNU libc refuses to resolve a single component domain name unless there's
a trailing dot (which there never is for a mail domain), or RES_DEFNAMES
is set and . is on the search list. Our mail relays use Exim's own seach
logic when looking up MXs so they switch RES_DEFNAMES off; therefore TLD
MXs do not work on those machines.

FreeBSD libc will resolve single-component names without trailing dots and
without RES_DEFNAMES set, so TLD MXs would work on FreeBSD. However,
FreeBSD's behaviour has varied in the past, and I suspect the same is true
for the upstream BIND resolver code - though I haven't checked the history
in detail.

So the question of whether TLD MXs work depends on the interactions
between lot of complicated option settings and software versions, and is
likely in practice to work or fail unpredictably.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
TYNE DOGGER: WEST 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 3 OR 4, THEN
SOUTHEAST 4 OR 5 LATER. SLIGHT OR MODERATE. SHOWERS, RAIN LATER. MODERATE OR
GOOD.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf