Re: [dane] An AD bit discussion

Viktor Dukhovni <> Wed, 26 February 2014 23:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 999831A030C for <>; Wed, 26 Feb 2014 15:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d6ejt5WWPDFa for <>; Wed, 26 Feb 2014 15:16:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1B0BD1A02F1 for <>; Wed, 26 Feb 2014 15:16:51 -0800 (PST)
Received: by (Postfix, from userid 1034) id 737232AAC73; Wed, 26 Feb 2014 23:16:49 +0000 (UTC)
Date: Wed, 26 Feb 2014 23:16:49 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] An AD bit discussion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2014 23:16:53 -0000

On Thu, Feb 27, 2014 at 09:50:59AM +1100, Mark Andrews wrote:

> > With RES_USE_DNSSEC #defined, the application knows that the run-time
> > promises to send DO=1.  There needs to be a similar option bit one
> > can test for at compile-time, and use to signal that the stub-resolver
> > library should return AD bits without RRSIGs (or with RRSIGs not
> > specifically required if it is easier to pass them along if returned).
> Setting AD isn't that hard.  For DANE you aren't going to want to use
> res_search() to retrieve the TLSA record so this just unwraps res_query().
> 	res_mkquery(...,query,...);
> 	query[3] |= 0x08; // set ad in request
> 	res_send(query,...);

Thanks for the proof of concept!  From an application developer
perspective, I'd like to suggest that this is not terribly practical
as an application interface.  The decision is made in the wrong place
if this is application code, rather than stub resolver internal code.

For example, Postfix uses res_search for everything, including TLSA
lookups, but being single-threaded, it can safely make temporary
changes in _res.options before each lookup (the original value is
restored when the lookup completes).

	saved_options = (_res.options & SAVE_FLAGS);
        _res.options &= ~saved_options;
        _res.options |= flags;
        len = res_search(name, C_IN, type, reply->buf, reply->buf_len);
        _res.options &= ~flags;
        _res.options |= saved_options;

Here "flags" is always a subset of "saved_options" that is set for
the current query, the remainder (including RES_DEFNAMES and
RES_DNSRCH) are cleared, unless explicitly requested in "flags".

This is about the lowest level of the libresolv API that Postfix
will use.  Also control over whether the right bit to send is "AD=1"
in the header or "DO=1" in the OPT pseudo-header really belongs
in stub resolver configuration, not in Postfix.

What would make more sense, is the ability to request pre-validated
responses (AD without RRSIG if possible), and have the stub-resolver,
based on /etc/resolv.conf settings, figure out the best way to
satisfy the request.

A new RES_IGNORE_RRSIG or similar option could be used in combination
with RES_USE_DNSSEC signal that an application wants "AD" in
responses, but is not interested in RRSIGs (though might still
get them).  The library would send whichever of "AD=1" or "DO=1"
is specified in resolv.conf as being supported by the designated