Re: [dane] An AD bit discussion
Paul Wouters <paul@nohats.ca> Thu, 27 February 2014 05:30 UTC
Return-Path: <paul@nohats.ca>
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 79FF61A03D4 for <dane@ietfa.amsl.com>;
Wed, 26 Feb 2014 21:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level:
X-Spam-Status: No,
score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
RP_MATCHES_RCVD=-0.547] 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 OE0-EeEr5AlA for
<dane@ietfa.amsl.com>; Wed, 26 Feb 2014 21:30:02 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by
ietfa.amsl.com (Postfix) with ESMTP id 0BA271A02CE for <dane@ietf.org>;
Wed, 26 Feb 2014 21:30:01 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca
(Postfix) with ESMTP id 5167F80D7E for <dane@ietf.org>;
Thu, 27 Feb 2014 00:29:58 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default;
t=1393478998; bh=lglVGsOc1fHnPIW25LN9ab35eJVAa8RxRAZk/hURio8=;
h=Date:From:To:Subject:In-Reply-To:References;
b=EoTH8a+FpE7HaIdRsi5rT+CRfIDAEa/+iVfJmb+1gIC1KPyOS8OifKtfG1GWFI4Sw
j28WKsleUGq6Zrh3vGqsK9KK8MQ7wL16D8a1eDqVrq2Ru6Ldw8HQRYPAvOA7JEF0PL
i8zF356BQfh+WD/VOSMeWXCG8ZBmlyveurHPNAjs=
Received: from localhost (paul@localhost) by bofh.nohats.ca
(8.14.7/8.14.7/Submit) with ESMTP id s1R5TvWA012572 for <dane@ietf.org>;
Thu, 27 Feb 2014 00:29:57 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 27 Feb 2014 00:29:57 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dane@ietf.org
In-Reply-To: <20140227044213.GO21390@mournblade.imrryr.org>
Message-ID: <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
<m3txbly9ui.fsf@carbon.jhcloos.org>
<alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca>
<20140227022347.GC73737@mx1.yitter.info>
<20140227031628.B4A1610765F9@rock.dv.isc.org>
<20140227034723.GA73861@mx1.yitter.info>
<20140227041753.3509810773A8@rock.dv.isc.org>
<20140227044213.GO21390@mournblade.imrryr.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-_CgJ4_LqIGIljNEo-hxZcXYf30
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 05:30:04 -0000
On Thu, 27 Feb 2014, Viktor Dukhovni wrote: > It sounds like there is no strong objection to defaulting to no > trust. Well, Andrew and I voiced concerns about breaking current common deployments. > So likely RedHat should proceed with extensions to resolv.conf to > express the trust status of the nameserver list, and improvements > to libresolv. The default stub-resolver policy can reasonably be > non-trust of all nameservers (typically from DHCP). But it is so much better for all server installs to just install a validating resolver, point resolv.conf to localhost, and use the DHCP obtained DNS servers (or admin configured DNS servers) as forwarders. Then all applications can trust the AD bit. That's a simply a reality that's possible today. Even upgrading machines to this is not that hard. The only really difficult case is the roaming device that has to deal with captive portals. dnssec-trigger+unbound isn't cutting it for the average user yet. While the glibc change would protect them, without dnssec-trigger+unbound they are in a complete insecure dns mess anyway, that I think a bogus AD flag is the least of the trouble. That's why I'm not really in favour of adding legacy to glibc or resolv.conf. Especially because there are also so few applications that actually do anything with AD bits, plus we are still working on API and DNSOP documents on how to improve/secure the DNS transport for talking to remote servers. Paul
- [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 Paul Wouters
- 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