On Mon, Nov 18, 2013 at 11:02:24AM -0800, Phil Pennock wrote:
> 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. :)
Users are generally not fond of unpredictable behaviour, so I think
you should plan to save/restore DNS options around every call when
you get a chance to wrap up existing DNS logic in a higher level
interface for Exim.
I am probably not going to read the code any time soon. The only
specific comment at this time is that when you're working on DANE
support and performing MX or TLSA lookups (including any resulting
CNAME chasing) you'll want (RES_USE_DNSSEC | RES_EDNS0) and not
(RES_DNSRCH | RES_DEFNAMES). I don't know whether it is OK to
leave RES_USE_DNSSEC enabled for all subsequent DNS queries as a
side-effect of TLSA lookups.
Speaking of DANE, the GnuTLS support for DANE is currently woefully
incomplete (I could reasonably say broken). So when it comes time
to do DANE over GnuTLS you'll probably want to take the same approach
I took with OpenSSL, which is to transmogrify the peer's chain into
a form acceptable to the existing CA-PKI logic, and use only the
legacy features of GnuTLS, rather than the separate GnuTLS DANE
library (which is useful only in so far as it points to the relevant
GnuTLS API elements one might use to do the job properly).
--
Viktor.
