Re: [dane] An AD bit discussion

Mark Andrews <marka@isc.org> Thu, 27 February 2014 02:02 UTC

Return-Path: <marka@isc.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 6D5AF1A027B for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 18:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 j4O2a2Kw7kMC for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 18:02:46 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5837C1A0158 for <dane@ietf.org>; Wed, 26 Feb 2014 18:02:46 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F17EFC94E0 for <dane@ietf.org>; Thu, 27 Feb 2014 02:02:29 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393466565; bh=ofeBBQHIOKqT8LQR9JY6C82GgwR9JkyLY0q8omhllYQ=; h=To:From:References:Subject:In-reply-to:Date; b=hu2rYgv7BMOJ7UNh6dhxRZ0pFLJgsElfGdWUZOO6ORfWK9Ks0nLK78AiMY4tQLmvy YhTCjebhpv2fPuMNkrnba554/UH5czzbZBs69gBEsVmcLBjXiIa17wdIzX2Qk9D97y M931yChkmY4JdqiZ+ItZR29ZPU5MOal5yrP+8R7E=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for <dane@ietf.org>; Thu, 27 Feb 2014 02:02:29 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A555B16004A for <dane@ietf.org>; Thu, 27 Feb 2014 02:03:22 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7EE7516005C for <dane@ietf.org>; Thu, 27 Feb 2014 02:03:21 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7828C1070181 for <dane@ietf.org>; Thu, 27 Feb 2014 13:02:27 +1100 (EST)
To: dane@ietf.org
From: Mark Andrews <marka@isc.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> <20140226231649.GJ21390@mournblade.imrryr.org>
In-reply-to: Your message of "Wed, 26 Feb 2014 23:16:49 -0000." <20140226231649.GJ21390@mournblade.imrryr.org>
Date: Thu, 27 Feb 2014 13:02:27 +1100
Message-Id: <20140227020227.7828C1070181@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-_aDMU8y3hTFgo1AiSOKDVXoMtQ
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Thu, 27 Feb 2014 02:02:50 -0000

In message <20140226231649.GJ21390@mournblade.imrryr.org>;, Viktor Dukhovni writ
es:
> 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.

It wasn't to say that it was practical or best practice. Extending options
to set AD would be useful but there is no reason to wait for that to
happen.

> 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).

Or one could use res_nsearch/res_nquery and have it work in a threaded
envionment.  Personally I would be using res_{n}query in a MTA to avoid
any possibility of searching.

> #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.

res_search and res_query are on the same level.

         len = res_search(name, C_IN, type, reply->buf, reply->buf_len);
         len = res_query(name, C_IN, type, reply->buf, reply->buf_len);
 
Additionally res_search should only proceed to the next name on
NXDOMAIN.  Currently it is type sensitive which is a hold over from
the when always appended the first search element regardless of the
number of labels in it and handling wildcard MX records.  If you had
a MX record like

	*.element.in.search.list MX 0 some.server

you didn't want to stop a search for A records for foo.example.net.

> 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.
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org