Re: [dane] An AD bit discussion (+concerns from glibc camp)

Petr Spacek <> Thu, 27 February 2014 20:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11EFD1A0649 for <>; Thu, 27 Feb 2014 12:44:08 -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 nAMJEpncLTxa for <>; Thu, 27 Feb 2014 12:44:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 19DA01A0141 for <>; Thu, 27 Feb 2014 12:44:06 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id s1RKi3bl027164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Thu, 27 Feb 2014 15:44:03 -0500
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id s1RKi1TY018679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <>; Thu, 27 Feb 2014 15:44:03 -0500
Message-ID: <>
Date: Thu, 27 Feb 2014 21:44:01 +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: [dane] An AD bit discussion (+concerns from glibc camp)
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: Thu, 27 Feb 2014 20:44:08 -0000

On 27.2.2014 21:04, Petr Spacek wrote:
>>>> For example current software like Postfix or OpenSSH client will
>>>> 'just work' without any change. AD bit will be handled in special
>>>> way only if the resolver library is initialized with the new call.
>>> As the developer of the Postfix DANE interface, I'd rather Postfix
>>> AD bit handling were subject to default system policy, and would
>>> ask the administrator to set system policy accordingly.  Once APIs
>>> for querying the stub-resolver behaviour (AD suppressed or trusted)
>>> become widely available, Postfix will start using them to sanity
>>> check its TLS policy settings (can't use DANE when stub resolver
>>> suppresses AD support).
> I 100 % agree with your point of view.
> The problem is that our glibc maintainer explicitly refused to change default
> behavior (i.e. mask AD bit until admin white-lists given resolver in
> /etc/resolv.conf) because it could break some (potentially) existing
> applications. That is a reason why we invented "init_trusted()" concept.
> Could you give us some detailed thoughts about compatibility?
> I guess that we will have the same discussion about compatibility again and
> again with many upstream developers from many DNS libraries so any detailed
> analysis will be handy.

I'm adding quote from our glibc maintainer:

 >>>> Carlos O'Donell <> wrote:
>>>>> Consider a RHEL7 or RHEL6 system using the present meaning of
>>>>> `nameserver' in /etc/resolv.conf, on a secure network with a trusted
>>>>> recursive resolver using DNSSEC for some given domains. In this
>>>>> configuration any application using the AD bit works as expected.
>>>>> The system administrators ensured there was trust between the recursive
>>>>> resolver and the client stub resolver. This is how a user might configure
>>>>> their corporate network, and even better they might also use 802.1x
>>>>> with no rogue or untrusted systems on their network.
>>>>> If we release a z-stream or y-stream glibc that inverts the definition
>>>>> of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for
>>>>> a query, and clears the AD bit) then applications in such a configuration
>>>>> as described above that rely on the AD bit forwarding may cease to
>>>>> function correctly.
>>>>> That is why I do not want to change the existing meaning of `nameserver'
>>>>> and why we should not change any of the existing meanings of entries in
>>>>> /etc/resolv.conf. Thus for compatibility I suggest adding a new option
>>>>> `untrusted' for use by such applications as NetworkManager to put
>>>>> untrusted DNS server (acquired from untrusted DHCP results) into.
>>>>> Let me be clear though, if I didn't care about breaking customer
>>>>> configurations, I'd make this change, but I think we would be doing
>>>>> a disservice to our users by breaking valid existing DNSSEC uses.

Petr^2 Spacek