Re: [dane] An AD bit discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 27 February 2014 02:18 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80F1A07C1 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 18:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqhoPj52HnIe for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 18:18:39 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A548C1A0686 for <dane@ietf.org>; Wed, 26 Feb 2014 18:18:39 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A28F2AAD0C; Thu, 27 Feb 2014 02:18:38 +0000 (UTC)
Date: Thu, 27 Feb 2014 02:18:38 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140227021838.GM21390@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <20140226194208.GA19694@solar.andreasschulze.de> <20140226212540.26889106C669@rock.dv.isc.org> <20140226214220.GH21390@mournblade.imrryr.org> <20140226225059.9A0FC106CFB5@rock.dv.isc.org> <20140226231649.GJ21390@mournblade.imrryr.org> <20140227020227.7828C1070181@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140227020227.7828C1070181@rock.dv.isc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5EuxGlz7gG2EecwciT_Q2QzrHyM
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 02:18:41 -0000

On Thu, Feb 27, 2014 at 01:02:27PM +1100, Mark Andrews wrote:

> Additionally res_search should only proceed to the next name on
> NXDOMAIN.  Currently it is type sensitive which is a hold over from
> the when always appended the first search element regardless of the
> number of labels in it and handling wildcard MX records.  If you had
> a MX record like
> 
> 	*.element.in.search.list MX 0 some.server
> 
> you didn't want to stop a search for A records for foo.example.net.

Looking at somewhat recent NetBSD source:

    switch (statp->res_h_errno) {
    case NO_DATA:
	    got_nodata++;
	    /* FALLTHROUGH */
    case HOST_NOT_FOUND:
	    /* keep trying */
	    break;
    case TRY_AGAIN:
	    if (hp->rcode == SERVFAIL) {
		    /* try next search element, if any */
		    got_servfail++;
		    break;
	    }
	    /* FALLTHROUGH */
    default:
	    /* anything else implies that we're done */
	    done++;
    }

we see that searching continues with NXDOMAIN, NODATA, and also
SERVFAIL!  As no tracking of the security status of NXDOMAIN or
NODATA takes place, unaware applications can get false "secure"
results when RES_DNSRCH is enabled.

I don't know how the new "getdns" handles mixing of DNSSEC and
appending suffixes.

-- 
	Viktor.