Re: [dane] An AD bit discussion

Viktor Dukhovni <> Wed, 26 February 2014 15:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BAA71A0676 for <>; Wed, 26 Feb 2014 07:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FgBODqZdciZX for <>; Wed, 26 Feb 2014 07:57:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2FE081A066E for <>; Wed, 26 Feb 2014 07:57:54 -0800 (PST)
Received: by (Postfix, from userid 1034) id 276072AAD0C; Wed, 26 Feb 2014 15:57:52 +0000 (UTC)
Date: Wed, 26 Feb 2014 15:57:52 +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
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 15:57:59 -0000

On Wed, Feb 26, 2014 at 09:12:20AM -0500, Paul Wouters wrote:

> 4 In the ideal world tomorrow, each host has its own automatically
>   configured, perfectly working validing DNS server and resolv.conf can
>   be ignored or is always hardcoded with nameserver

This is also my ideal world of tomorrow.

> Now for my question. Until we reach 4), what should we do with the AD
> bit in getaddrinfo() ?

I was not aware of any mechanism in getaddrinfo() to communicate
the AD bit?  Is this a new getaddrinfo() implementation with features
I've not looked at yet?

Also getaddrinfo() typically uses RES_DEFNAMES and RES_SEARCH,
which make the meaning of any security bit rather ambiguous.
When the input is not a fully-qualified DNS name, what is it
the user has learned to be secure?

What happens when one of the domains on the search list returns
NXDOMAIN (without proof non-existence), but a subsequent suffix
yields a "secure" result?

I am fairly confident that security is rather elusive when the
input name is only partially specified.  Lots of ways to get
this wrong.