Re: [dane] An AD bit discussion

Viktor Dukhovni <> Wed, 26 February 2014 21:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6579A1A036D for <>; Wed, 26 Feb 2014 13:42:25 -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 C9Vue4aU_kJj for <>; Wed, 26 Feb 2014 13:42:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 30DF91A02C3 for <>; Wed, 26 Feb 2014 13:42:22 -0800 (PST)
Received: by (Postfix, from userid 1034) id 5C8A82AAD0C; Wed, 26 Feb 2014 21:42:20 +0000 (UTC)
Date: Wed, 26 Feb 2014 21:42:20 +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 21:42:25 -0000

On Thu, Feb 27, 2014 at 08:25:40AM +1100, Mark Andrews wrote:

> The history of the AD bit in responses and it meaning.
> RFC 1035 -> AD=0
> RFC 2535 -> AD=0/1 (records gone through validation) 
> RCC 3225 (DO introduced)
> RFC 3655 -> AD=0/1 (DO=1 required, answer and authority sections all secure)
> RFC 3755 (type code roll)
> RFC 4035 -> AD=0/1 (DO=1 required, answer and authority sections all secure)
> RFC 6840 -> AD=0/1 (DO=1 or AD=1 required, answer and authority sections all
> 		    secure)

Thanks, this is very useful.  It remains only to determine whether
for platforms on which the proposed designs are being contemplated,
one can reasonably expect the target (reachable securely, typically
local) resolvers to support AD=1 in the query.

This information seems to me to be more likely available to the
administrator configuring *static* resolv.conf settings, than to
an application author or user.

Therefore, my gut reaction is that applications that want the AD
bit need to be able to ask for it, and the stub resolver library
determines how to get the job done with help from resolv.conf.

The stub resolver library may be able to get away with sending AD=1
instead of DO=1 and getting a more compact reply.  And may suppress
RRSIG elements in the answer, authority and additional sections when
the DO=1 was used because AD=1 was not known to be supported.

This still leaves us with the question of how libresolv clients
should signal their interest in the AD bit?  At the very least the
application needs to know that DNSSEC support is not simply

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