On Thu, 11 Sep 2003, Chris Hughes wrote:
> > Non-fully qualified names are dangerous if used in DNS lookups, because
> > you can never be sure how the resolver is going to treat them.
>
> Well, you can if it's your DNS! ;)
Well, your own evidence shows that certain kinds of lookup, though not
directly to the DNS, behave differently in Solaris and Linux, so I think
my general point stands.
> > You didn't quote the full code extract, which reads:
> >
> > _res.options &= ~(RES_DNSRCH | RES_DEFNAMES);
> > _res.options |= (qualify_single? RES_DEFNAMES : 0) |
> > (search_parents? RES_DNSRCH : 0);
>
> Yes, but why does exim remove those (default on both Linux and Solaris)
It removes them so that it can set them if it wants to. That is, it
wants to be sure of their settings, and not make any assumptions about
operating system defaults. I am trying to avoid OS differences.
> resolver options - particularly if its going to do a gethostbyname() call
> later anyway
That function doesn't know anything about the general sequence of
control flow. In particular, it doesn't know if a gethostbyname() call
will follow. From the dnslookup router, for example, it won't.
> Exim probably shouldn't be mixing gethostbyname() and direct resolver
> calls anyway. Solaris seems to do the 'right thing' and keep them
> divorced, but you have to cater for Linux too.
The current state has evolved as a compromise that gets it right, or
nearly right, most of the time. Previous versions of Exim did one or the
other, and there was a default of gethostbyname. (You can still force
one or the other, only, by specifying byname or bydns, incidentally.)
However, this turned out to be bad in some cases. The following two
entries from the ChangeLog for release 4.11 are relevant:
89. When a host was looked up using gethostbyname() (or the more recent
getipnodebyname() on IPv6 systems), Exim was not inspecting the error code
on failure. Thus, any failure was treated as "host not found". Exim now
checks for temporary errors, so the behaviour of "byname" and "bydns"
lookups in this respect should be the same. However, on some OS it has been
observed that getipnodebyname() gives HOST_NOT_FOUND for names for which a
DNS lookup gives TRY_AGAIN. See also change 125 below.
125. Changed the default way of finding an IP address in both the manualroute
and queryprogram routers. Exim now does a DNS lookup; if that yields
HOST_NOT_FOUND, it tries calling getipnodebyname() (or gethostbyname()).
See also change 89 above.
The idea is to avoid the bad behaviour mentioned in 89. But note, as I
said, you can force it to use one or the other if you want. This
behaviour is just the default.
> > Or, if you must use the DNS, find a way of detecting the .domain.name so
> > that you can use a fully-qualified name. For example, if the
> > .domain.name is always the same as that of $primary_hostname, you could
> > use some string expansion manipulation to extract it.
>
> I must, I must. Is this something that can be done within the exim
> configuration?
Yes. Something along the lines of
${if match{$primary_hostname}{^[^.]+(.*)}{$1}}
will give you the .domain of your host (if $primary_hostname is a.b.c.d
it will yield .b.c.d). Regular expressions are your friend.
> I can't help but think that this is something that exim should address
> itself. Same exim version and same config file behaving differently
> depending on the OS its running on - that's not supposed to happen!
I cannot do much if the underlying OS calls behave differently.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
