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

Petr Spacek <> Wed, 26 February 2014 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 353E41A06A3 for <>; Wed, 26 Feb 2014 08:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xMhlay23aaDC for <>; Wed, 26 Feb 2014 08:03:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E6DDF1A0683 for <>; Wed, 26 Feb 2014 08:03:10 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id s1QG38mB009330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Wed, 26 Feb 2014 11:03:08 -0500
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id s1QG2uuG004497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <>; Wed, 26 Feb 2014 11:03:02 -0500
Message-ID: <>
Date: Wed, 26 Feb 2014 17:02:56 +0100
From: Petr Spacek <>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
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:03:15 -0000


Paul Wouters and me have accidentally open threads about the same topic on 
this list and also on dane-list. I guess that this discussion fits better to 
dane-list so please discuss there.

I'm sorry for the noise.

Petr Spacek

On 26.2.2014 16:44, Petr Spacek wrote:
> Greetings,
> I'm Petr Spacek from Red Hat's Identity Management group. We plan to extend
> 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 application.
> 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 not
> secure).
> - 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 talk
> to local recursive resolver and use received AD bit to decide e.g. if it is
> possible to trust TLSA records or not.
> Unfortunately, there are use cases where neither a locally running validating
> resolver nor a trusted path to a remote resolver are available and deployment
> 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 okay
> only if no application relays on the AD bit. In other words, supporting DANE
> with current stub-resolvers practically requires to add a configuration option
> 'recursive resolver is un/trusted' to each and every DANE-enabled application
> and library. (This is exactly what OpenSSH client does. An additional problem
> is that this value has to be maintained as network configuration changes over
> time.)
> 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 somehow.
> 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 case
> of ldns it would be something like: ldns_resolver_new_frm_file_trusted() or
> 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
> /etc/resolv.trusted).
> - 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 consult
> 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 application.*
> This allows an administrator to configure system-wide policy. In case with
> locally running validating resolver or e.g. IPSec tunnel to trusted resolver
> admin can declare it as trusted and nothing changes. However, this mechanism
> 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 applications
> to trust the AD bit unconditionally and as a result it significantly
> simplifies DNSSEC implementation and configuration on client machines. We hope
> 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.