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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 7 Jul 2008, moore@xxxxxxxxxxxxxxxxxxxx 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@xxxxxxxx>  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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]