Re: [dane] An AD bit discussion

Viktor Dukhovni <> Wed, 26 February 2014 17:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 041871A070B for <>; Wed, 26 Feb 2014 09:36:36 -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 QEVMWtKCg-T0 for <>; Wed, 26 Feb 2014 09:36:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E9A301A00AE for <>; Wed, 26 Feb 2014 09:36:32 -0800 (PST)
Received: by (Postfix, from userid 1034) id 588552AAC73; Wed, 26 Feb 2014 17:36:30 +0000 (UTC)
Date: Wed, 26 Feb 2014 17:36:30 +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 17:36:36 -0000

On Wed, Feb 26, 2014 at 05:24:37PM +0000, Tony Finch wrote:

> > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
> >    configuration mechanism will allow white-listing nameservers and
> >    will always be on the whitelist.
> That sounds like a fair plan.

It is in fact problematic if both and another nameserver
are listed.  The correct semantics of that are hard to define.  It
makes more sense to define a boolean primitive that marks all the
nameservers collectively as either trusted or not.

> Question: along with this change are you planning to change the resolver
> to set the AD flag in queries when the nameserver is known to be safe?
> Usually the AD flag only appears in responses if the query had the AD or
> DO flags set. DO is a bit wasteful for clients that only care about the AD
> bit. However the only DNSSEC switch that libc resolvers currently have is
> options edns0 (which implies DO).

The RES_USE_DNSSEC flag turns on the "DO" bit.  I would be surprised
if RES_USE_EDNS0 enabled "DO".  As for setting the "AD" bit in the
request automatically, it probably should still require an explicit
indication of interest from the application or be set via a default
option value /etc/resolv.conf.