Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

Evan Hunt <each@isc.org> Fri, 13 April 2018 16:31 UTC

Return-Path: <each@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71936126DC2 for <dnsop@ietfa.amsl.com>; Fri, 13 Apr 2018 09:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wh5iFgJUHnX7 for <dnsop@ietfa.amsl.com>; Fri, 13 Apr 2018 09:31:35 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E379A1201FA for <dnsop@ietf.org>; Fri, 13 Apr 2018 09:31:35 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B37CC3AB042; Fri, 13 Apr 2018 16:31:35 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 9C6A1216C1C; Fri, 13 Apr 2018 16:31:35 +0000 (UTC)
Date: Fri, 13 Apr 2018 16:31:35 +0000
From: Evan Hunt <each@isc.org>
To: bert hubert <bert.hubert@powerdns.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsop@ietf.org
Message-ID: <20180413163135.GA28695@isc.org>
References: <20180413144707.GA4767@server.ds9a.nl> <623F11C7-6E4D-40F5-8AD1-8F7E92C8C7F9@vpnc.org> <20180413151152.GB4767@server.ds9a.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180413151152.GB4767@server.ds9a.nl>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/r4uYccnNBt2lbhR8YxEkV7LMqyE>
Subject: Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2018 16:31:37 -0000

On Fri, Apr 13, 2018 at 05:11:52PM +0200, bert hubert wrote:
> RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
> in step 2 we look up the best zone again for the target of the CNAME. I have
> not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
> consult other zones it is authoritative for. There might be millions of
> these btw, operated by other people.

The search algorithm has been updated a few times (most recently 6672, I
believe?) but AFAIK this phrasing remains in effect, and probably ought to
be clarified in a future document. That said, it's up to you what zones you
consider "available" in step 2, and there's no reason you can't limit the
set of available zones to the ones that were in bailiwick for the original
query, so you're not breaking any rules.

I could have sworn there was an RFC published several years ago concerning
the prevention of cache poisoning, which specified that resolvers had to
ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
google skills, or did I dream the whole thing?

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.