On Mon, Jan 27, 2014 at 06:51:51AM -0800, Todd Lyons wrote:
> >> My latest plans had involved using some of the same code written by
> >> Viktor Dukhovni for Postfix, to meet an API for the latest DANE/SMTP
> >> draft specification, into which I've had plenty of input, which has been
> >> taken on board and the result is a specification which Exim should be
> >> following.
>
> I've been looking at the specs and drafts (off and on) over the past
> couple of weeks. Honestly, it hasn't gelled in my brain.
> Individually, all the pieces make sense, but when I start thinking of
> where in the Exim code I would put the pieces, I don't make any
> forward progress. Defining the TLSA dns type is as far as I've
> gotten.
While I can't tell you where to start adding DANE support into
Exim, since I am not familiar with the Exim code base, I can tell
you (over a series of messages) how it fits into Postfix, which
would I think be helpful.
Step 1: DNSSEC support
-----------------------
- Postfix has a small "libdns" which wraps around "libresolv".
This returns results via a DNS_RR structure which is a linked
list of DNS records. The lookup function returns a lookup
status (ok, notfound, retry, hardfail) and on success sets a return
parameter to the head of the list.
- The Postfix libdns lookup function takes a set of resolver
flags (subset of flags supported by _res.options). These
are saved, set, and restored around every lookup:
/* flags is a subset of SAVE_FLAGS */
saved_options = (_res.options & SAVE_FLAGS);
_res.options &= ~saved_options;
_res.options |= flags;
len = res_search((char *) name, C_IN, type, reply->buf, reply->buf_len);
_res.options &= ~flags;
_res.options |= saved_options;
This deals with potentially unpredictable settings from other
libraries and makes sure that Postfix lookups always use the expected
flags (generally neither of RES_DNSRCH, RES_DEFNAMES) without
disturbing the extant value of _res.options for other callers.
- On platforms where RES_USE_DNSSEC is defined and non-zero I
added RES_USE_DNSSEC to the set of SAVED_FLAGS and made it
available to callers of the lookup functions. On these
platforms there is HEADER->ad bit in the res_search answer
header. This is used to determine whether the resolver
(presumed local and validating) determined a secure DNS
response. The "ad" bit is used to set the DNSSEC validation
status of each element of the DNS_RR list.
- When recursive CNAME expansion is performed by libdns (the
resolver may return a CNAME answer without "chasing" it to
the final requested record, as many do, in which case the
answer contains a list of CNAME records and the final result)
and its validation status is "insecure" (ad = 0), all downstream
replies from chasing of that CNAME lookup are also deemed insecure.
So the first task is to extend the Exim code that handles DNS
resolution to optionally perform DNSSEC lookups. This also avoids
breaking resolution of other names (database hostnames, ...) since
resolver flags are always restored to their initial state. Of
course *all* explicit DNS lookups by Exim would need to go through
such a library and Exim should not otherwise modify _res.options.
Then you need a configuration parameter ("router" setting I would
guess) that turns on DNSSEC lookups when performing MX resolution
or using DNS to resolve the address of non-MX destinations.
Postfix supports fallback to "native" address resolution (essentially
getaddrinfo() and such) when DNS lookups return "notfound". It is
essential to not that this fallback does not and did not happen on
lookup failure, it only takes place when DNS indicates the answer
does not exist. Results from "native" resolution are always marked
not validated.
When MX records are found, if the MX RRset is DNSSEC validated (ad
!= 0), then the name -> address resolution of each MX hostname is
also performed with RES_USE_DNSSEC, otherwise, if the MX RRset is
not DNSSEC validated, the resolution of the MX hostnames does not
bother with DNSSEC and they are automatically "insecure".
When you have DNSSEC support, we can discuss step 2. One might
argue that some users might be interested in knowing whether their
MX lookups, ... are DNSSEC validated, even without DANE. Though
Postfix does not do this (yet?), you could indicate the DNSSEC
security status of the MX host address in mail logs. Personally,
I don't see such logging as terribly useful.
I should note that another option is to use a DNSSEC validating
stub resolver in Exim (libunbound or ldns) with appropriate
application-defined trust anchors (plus handling of root zone key
rollover). With my IETF draft author hat off, I feel this would
be unwise (IIRC Phil agrees), such code IMHO belongs in the local
resolver and not in the MTA. This does not materially change most
of the above, what changes is that instead of looking at the "ad"
bit, you'll have more direct security status information from the
validating stub resolver library.
--
Viktor.
