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

Viktor Dukhovni <> Thu, 27 February 2014 21:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B086C1A02F5 for <>; Thu, 27 Feb 2014 13:38:35 -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 BUr8PDWMXVMA for <>; Thu, 27 Feb 2014 13:38:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3CD871A0292 for <>; Thu, 27 Feb 2014 13:38:34 -0800 (PST)
Received: by (Postfix, from userid 1034) id 427482AAC73; Thu, 27 Feb 2014 21:38:32 +0000 (UTC)
Date: Thu, 27 Feb 2014 21:38:32 +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 (+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 21:38:35 -0000

On Thu, Feb 27, 2014 at 09:44:01PM +0100, Petr Spacek wrote:

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

A feature IMHO.  Document the change, and tell administrators how
to mark the resolver list trusted.  Enhance NetworkManager to be
able to write trusted resolv.conf files when the DNS server list
comes from a secure source.

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

This fails open.  Given the dearth of DNSSEC applications that rely
on the AD bit, this is I think the right time to get the right

No changes are required in end-applications, just system configuration
management, this is an easy problem that should be addressed.

Marking /etc/resolv.conf explicitly untrusted, in every case where
it is not, is I think too fragile.