On Thu, 21 Sep 2006, Magnus Holmgren wrote:
> On Thursday 21 September 2006 14:33, Marc Haber took the opportunity to say:
> > Hi,
> >
> > When I have a bare host name like "torres" as a smarthost,
> > verification fails ("lookup of host "torres" failed in smarthost
> > router"). I can, however, deliver e-mail through the router, since
> > zugschlus.de is listed as search domain in /etc/resolv.conf and
> > torres.zugschlus.de exists.
> > [...]
> > Looks like exim is not properly honoring the search domains when doing
> > verification, but it is doing fine when actually routing.
>
> When I try, the lookup fails both when verifying and actually delivering.
> Maybe dns_init() is never called in your case. In most cases it is called as
> dns_init(FALSE, FALSE), which turns off RES_DEFNAMES (qualify unqualified
> names) and RES_DNSRCH (search parents), but host_find_bydns() calls it with
> the arguments set according to its whichrrs parameter.
>
> manualroute_router_entry() calls rf_lookup_hostlist(), which in turn uses
> host_find_byname() or host_find_bydns() depending on the options in the
> routing list. In the case of bydns, rf_lookup_hostlist() calls
> host_find_bydns() with the beforementioned flags in whichrrs unset, so in
> that case the lookup always fails. But host_find_byname() doesn't call
> dns_init() at all; thus the resolver uses the old options, whatever they may
> be. That is probably a bug.
OK, I've been looking at this. The fact that host_find_byname() doesn't
call dns_init() is quite deliberate. I assumed that the system functions
it calls (gethostbyname() and friends) would configure their DNS calls
exactly as they wanted them and that there couldn't be any influence
from the caller. After all, the calling program doesn't even know
whether these functions are going to use the DNS at all (you don't have
to set "dns" in /etc/nsswitch.conf).
I did some experiments on Gentoo Linux which were not very conclusive,
but it did seem that initializing the resolver beforehand had some
influence, though I could only make it influence IPv6 lookups, not IPv4
lookups, oddly.
Anyway, given that this does seem to be a possibility, I have
implemented the following change:
PH/16 It seems that the options setting for the resolver (RES_DEFNAMES and
RES_DNSRCH) can affect the behaviour of gethostbyname() and friends when
they consult the DNS. I had assumed they would set it the way they
wanted; and indeed my experiments on Linux seem to show that in some
cases they do (I could influence IPv6 lookups but not IPv4 lookups).
To be on the safe side, however, I have now made the interface to
host_find_byname() similar to host_find_bydns(), with an argument
containing the DNS resolver options. The host_find_byname() function now
sets these options at its start, just as host_find_bydns() does. The smtp
transport options dns_qualify_single and dns_search_parents are passed to
host_find_byname() when gethostbyname=TRUE in this transport. Other uses
of host_find_byname() use the default settings of RES_DEFNAMES
(qualify_single) but not RES_DNSRCH (search_parents).
I have committed the change, so it will be in tonight's snapshot.
> I don't know Phil's intentions, but it looks like you're supposed to use
> qualified names with the manualroute router.
I hadn't really thought about it at all. I usually expect people to use
fully qualified names, but if I had thought, I would have assumed that
you could set up external things (e.g. nsswitch.conf or /etc/hosts) to
handle this kind of issue.
Anyway, given that I have now added RES_DEFNAMES as a default setting
that should apply to the manualroute router, things might be different
for Marc. Let me know if what I've done has had any effect. Especially
if it's a *useful* effect!
Philip
--
Philip Hazel, University of Cambridge Computing Service.
