Re: [dane] An AD bit discussion
Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 26 February 2014 23:16 UTC
Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999831A030C for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 15:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6ejt5WWPDFa for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 15:16:51 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BD1A02F1 for <dane@ietf.org>; Wed, 26 Feb 2014 15:16:51 -0800 (PST)
Received: by mournblade.imrryr.org (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 <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140226231649.GJ21390@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> <20140226214220.GH21390@mournblade.imrryr.org> <20140226225059.9A0FC106CFB5@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140226225059.9A0FC106CFB5@rock.dv.isc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AkqaXXPN40_Nb0Vl8r0_RYzzO18
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=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). #define USER_FLAGS (RES_DEBUG | RES_DNSRCH | RES_DEFNAMES | RES_USE_DNSSEC) #define XTRA_FLAGS (RES_USE_EDNS0) #define SAVE_FLAGS (USER_FLAGS | XTRA_FLAGS) 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 nameservers. -- Viktor.
- Re: [dane] An AD bit discussion Paul Wouters
- [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Ondřej Surý
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Olafur Gudmundsson
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Wiley, Glen
- Re: [dane] An AD bit discussion James Cloos
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andreas Schulze
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion (correction) Petr Spacek
- Re: [dane] An AD bit discussion (+concerns from g… Petr Spacek
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion (+concerns from g… Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- [dane] Proposal: AD bit handling in stub-resolver… Petr Spacek
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] Proposal: AD bit handling in stub-reso… Viktor Dukhovni
- Re: [dane] An AD bit discussion Florian Weimer
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek