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

Paul Vixie <paul@redbarn.org> Mon, 16 April 2018 15:38 UTC

Return-Path: <paul@redbarn.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 BD3D012E870 for <dnsop@ietfa.amsl.com>; Mon, 16 Apr 2018 08:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WgLb3vzCTuKg for <dnsop@ietfa.amsl.com>; Mon, 16 Apr 2018 08:38:09 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592BB12778E for <dnsop@ietf.org>; Mon, 16 Apr 2018 08:38:09 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:e5ec:a53d:3a52:438a] (unknown [IPv6:2001:559:8000:c9:e5ec:a53d:3a52:438a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E46597594C; Mon, 16 Apr 2018 15:38:08 +0000 (UTC)
Message-ID: <5AD4C35D.3010108@redbarn.org>
Date: Mon, 16 Apr 2018 08:38:05 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: bert hubert <bert.hubert@powerdns.com>
CC: Tony Finch <dot@dotat.at>, dnsop@ietf.org
References: <20180413144707.GA4767@server.ds9a.nl> <alpine.DEB.2.11.1804161511370.27682@grey.csi.cam.ac.uk> <20180416151333.GA9879@server.ds9a.nl>
In-Reply-To: <20180416151333.GA9879@server.ds9a.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WF106cd1zVpX7kpSqdagyp8F-xs>
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: Mon, 16 Apr 2018 15:38:11 -0000

one thing to note is that when the server is authoritative for more than 
one zone, a cname that crosses from one such zone to another is allowed 
by 1035 to be chased. however, the resolver has no reason to accept 
out-of-zone records, since it cannot be sure that a new query in the 
bailiwick of the second zone would be answered the same way (or by the 
same server.) after kashpureff, we ignore the out-of-zone data and 
re-fetch it. this strongly calls for an update to 1035, since akamai and 
other CDN's are sending multi-zone cname chains, and they need to know 
that they should not do that, and also, resolver implementers need to 
know that they should be stripping any answer from the response whose 
owner name is not in-bailiwick with their QNAME.