Re: [exim] Exim can't resolve hostname of database when seco…

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: exim-users
Subject: Re: [exim] Exim can't resolve hostname of database when second email is sended in one TCP connection
On 2013-11-17 at 17:24 +0000, Viktor Dukhovni wrote:
> Perhaps what I propose below is impractical for Exim, but otherwise,
> I think it makes sense to not change default DNS behaviour except
> when performing MX lookups and resolving MX host IP addresses.


We have a number of contexts where DNS resolution is done, with explicit
routing to hosts, which can be looked up in various different ways
depending upon configuration. All of those call dns_init() before they
start, and loosely speaking, they change `_res.options`.

More accurately, they change the resolver object, whatever that might
happen to be, which is `_res` on "everything except NetBSD", I believe,
and something more dynamic on NetBSD. (Boy did that change cause
fallout on HP-UX and its ilk, needing to know the _type_ of _res,
portably).

We don't reset afterwards. At present, without looking, my recollection
is that there are too many error paths out of the DNS lookups to make
that a sane proposition, but if/when we revamp DNS handling to put our
own DNS API more firmly in there, your suggestion is, obviously, the
right thing to do.

My vague tentative thought has been to use a GetDNS API implementation,
falling back to _res handling, once we have an actual implementation of
that new(ish) spec.

> when flags includes "RES_USE_DNSSEC", the additional flag RES_EDNSO
> is automatically added to flags and its current setting to saved_options.


http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l156

We already provide an Exim level option `dns_use_edns0` to let an admin
explicitly turn on RES_EDNS0 without touching /etc/resolv.conf
(especially useful if that file doesn't support `options edns0`), which
can help when dealing with remote MX sets of unusually large size.

The code correctly (I believe) handles the interactions of
`dns_use_dnssec` and `dns_use_edns0`, explicitly turning on the latter
unless it has already been explicitly overriden to off by the
administrator, in which case dns_use_dnssec is forced off too, the
debug-log records what happened, etc.

If you can spot any flaws, besides that we mutate persisted state and
don't deal with external libraries using DNS too, please let me know so
I can fix it. :)

-Phil