Re: [DNSOP] DNSSEC AD bit handling in stub-resolvers

"Wiley, Glen" <> Wed, 26 February 2014 16:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C62A61A0454 for <>; Wed, 26 Feb 2014 08:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hRiQzHcGu0za for <>; Wed, 26 Feb 2014 08:02:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1732C1A0699 for <>; Wed, 26 Feb 2014 08:02:45 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUw4QI2oqf1lya/; Wed, 26 Feb 2014 08:02:46 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s1QG2gvb011937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 11:02:43 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 11:02:41 -0500
From: "Wiley, Glen" <>
To: Petr Spacek <>, "" <>
Thread-Topic: [DNSOP] DNSSEC AD bit handling in stub-resolvers
Thread-Index: AQHPMwm90JqcSVg1Qkyoc2fHUuWuKprHskSA
Date: Wed, 26 Feb 2014 16:02:41 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [DNSOP] DNSSEC AD bit handling in stub-resolvers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2014 16:02:52 -0000


Have you taken a look at the getdns API specification that Paul Hoffman
put together at ?

This addresses many of your points for both stub resolvers and a recursive
resolver that would run on a platform local to the applications.
Glen Wiley

Sr. Engineer
The Hive, Verisign, Inc.

On 2/26/14 10:44 AM, "Petr Spacek" <> wrote:

>I'm Petr Spacek from Red Hat's Identity Management group. We plan to
>support for DNSSEC (including DANE and others) in open-source software
>and we 
>would like to discuss the right implementation approach with you.
>We can see two very basic approaches:
>A) Do DNSSEC response validation in each application.
>B) Let recursive resolver do the validation and use AD bit in the
>We consider the first approach (i.e. each application doing response
>validation) too heavy-weight and hard to administer for various reasons:
>- Response validation is sensitive operation and application programmers
>should not do it themselves.
>- A variant where every application calls validation library is still not
>optimal. Experience with crypto libraries shows that there are many
>opportunities to use a library incorrectly (in a way which works but is
>- This approach has potential to create administrative nightmare if each
>application decides to maintain own set of trust anchors etc. We can see
>results of such approach in PKI world ...
>We believe that better approach is to centralize validation in local
>system-wide recursive resolver and use AD bit for signaling that data are
>trustworthy to applications. An application should use stub-resolver to
>to local recursive resolver and use received AD bit to decide e.g. if it
>possible to trust TLSA records or not.
>Unfortunately, there are use cases where neither a locally running
>resolver nor a trusted path to a remote resolver are available and
>of such is unacceptable.
>It seems that existing stub-resolvers unconditionally trust recursive
>resolvers and just forward the AD bit back and forth. This behavior is
>only if no application relays on the AD bit. In other words, supporting
>with current stub-resolvers practically requires to add a configuration
>'recursive resolver is un/trusted' to each and every DANE-enabled
>and library. (This is exactly what OpenSSH client does. An additional
>is that this value has to be maintained as network configuration changes
>We would like to make DNSSEC implementation in applications as simple and
>secure as possible. That is a reason why we are looking for a solution
>for a 
>case where AD bit can't be trusted because validating resolver is not
>available for whatever reason. It would allow applications to use AD bit
>without explicit configuration per-application if we solve this case
>Is there any 'standard' way to handle described situation?
>We have the following proposal (some people say it is controversial):
>- Extend stub-resolvers with a new call for resolver initialization: In
>of ldns it would be something like: ldns_resolver_new_frm_file_trusted()
>for glibc res_init_trusted().
>- The new call will initialize library as usual + read some system-wide
>configuration (it can be whatever, imagine for example a new file
>- Client applications will use the same API (except the initialization)
>to do 
>DNS queries.
>- When a DNS answer is received from network the stub-resolver will
>configuration read from /etc/resolv.trusted:
>-- If the particular recursive resolver is listed as trusted - pass AD
>bit to 
>the application.
>-- *Otherwise: Clear AD bit and pass the answer with AD=0 to the
>This allows an administrator to configure system-wide policy. In case
>locally running validating resolver or e.g. IPSec tunnel to trusted
>admin can declare it as trusted and nothing changes. However, this
>allows the system to be safe even in configurations *without* validating
>resolver. No explicit configuration in application is need, just one
>system-wide setting.
>It could seem like a minor improvement or a hack, but it allows
>to trust the AD bit unconditionally and as a result it significantly
>simplifies DNSSEC implementation and configuration on client machines. We
>that this simple approach will allow us to implement and deploy DANE and
>similar technologies widely.
>This proposal can be seen as temporary solution before secure transport
>mechanisms like IPSec or CGA-TSIG are widely available and used. The main
>advantage is that it is easy to implement and it doesn't require any new
>technology so we can use it in applications today.
>We would like to hear your opinions and recommendations for this area.
>Thank you for your time.
>Petr Spacek
>Software Engineer
>Red Hat
>DNSOP mailing list