Re: [dane] An AD bit discussion

"Wiley, Glen" <> Wed, 26 February 2014 19:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 912441A0813 for <>; Wed, 26 Feb 2014 11:10:17 -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 fyWMNoZzzeaH for <>; Wed, 26 Feb 2014 11:10:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 517921A0726 for <>; Wed, 26 Feb 2014 11:10:00 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUw48B+7kn1CNfdXgyTu9+/; Wed, 26 Feb 2014 11:09:59 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s1QJ9wNw018442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Wed, 26 Feb 2014 14:09:58 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 14:09:58 -0500
From: "Wiley, Glen" <>
To: "" <>
Thread-Topic: [dane] An AD bit discussion
Thread-Index: AQHPMxefb3KO91hA20Sgmp6++Nrbq5rIIDMAgAAKhYCAAALmAP//uN4A
Date: Wed, 26 Feb 2014 19:09:57 +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: [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 19:10:17 -0000


Your mention of the getdns api is apropos since we just announced the beat
release of our implementation :)

An application using the getdns api can decide how it will take advantage
of the system files - for example whether it wants to use a search option
which is an improvement over the current approach in which applications
are not aware of whether a suffix was appended to a query.

I would add however that the same root operator that might add a suffix to
resolv.conf could do other nefarious things to resolvers on that host
since the root operator has significant opportunities for MITM attacks on
applications running on that host.

I think the specification takes the most reasonable approach by deferring
to the application to decide the extent to which it will respect
system-wide settings (even including trust anchors).
Glen Wiley

Sr. Engineer
The Hive, Verisign, Inc.

On 2/26/14 1:24 PM, "Viktor Dukhovni" <> wrote:

>On Wed, Feb 26, 2014 at 06:14:09PM +0000, Tony Finch wrote:
>> > 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.
>> Perhaps, though I think the AD flag is pretty benign.
>I think it requires EDNS0, but if that is already set, perhaps
>turning on AD by default is harmless.  This specific detail is
>perhaps more of a "dnsop" than "dane" question.
>By the way I just noticed that
>does not define the interaction of DNSSEC with:
>    getdns_return_t getdns_context_set_append_name(
>	getdns_context *context,
>	getdns_append_name_t value );
>    Specifies whether to append a suffix to the query string before
>    the API starts resolving a name. The value is
>    This controls whether or not to append the suffix given by
>    getdns_context_set_suffix
>Name appending breaks DNSSEC when any of the resulting zones are
>insecure and are tried before ultimately secure zones.  The validity
>of a request for a secure response for an under-specified query is
>IMHO questionable.
>	Viktor.
>dane mailing list