IETF Logo Mail Archive

Re: [dane] An AD bit discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 27 February 2014 21:56 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 00B5B1A0262 for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 13:56:50 -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 4nwWl4grdWPH for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 13:56:48 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60B1A0139 for <dane@ietf.org>; Thu, 27 Feb 2014 13:56:48 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6F37C2AAC73; Thu, 27 Feb 2014 21:56:45 +0000 (UTC)
Date: Thu, 27 Feb 2014 21:56:45 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140227215645.GB21390@mournblade.imrryr.org>
References: <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> <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <alpine.LFD.2.10.1402271144500.24957@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1402271144500.24957@bofh.nohats.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1_b6SEL1OK5nPJ17fwJKS8gyqj8
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: Thu, 27 Feb 2014 21:56:50 -0000

On Thu, Feb 27, 2014 at 12:01:44PM -0500, Paul Wouters wrote:

> This has the same effect as stripping out forged AD bits, except real AD
> bits survive. It uses whatever nameservers the system has in
> /etc/resolv.conf. It supports overrides in /etc/hosts. It does not
> require glibc modification. It does not require various applications
> read new keywords in resolv.conf or new config files. It has no race
> conditions. It's a great band-aid until "tomorrow".

Oddly enough, unrelated to this thread, someone asked me today
whether there exist stub resolver libraries that can be configured
to trust AD=1, but *otherwise* perform local validation when AD=0.

Perhaps the local recursor is non-validating, or Petr's idea is
implemented and the AD bit is suppressed.  Either way, the application
can recover at the cost of performing internal verification, but only
when "necessary".

Anyone know of a library that can support this mode of operation?

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email