Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 13 November 2017 03:27 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 D11A6129415 for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 19:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=LwzhBmJe; dkim=pass (1024-bit key) header.d=yitter.info header.b=ACFrQGum
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 V8d2AC0Z7iXV for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 19:27:25 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FA0129408 for <dnsop@ietf.org>; Sun, 12 Nov 2017 19:27:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6E259BF56B for <dnsop@ietf.org>; Mon, 13 Nov 2017 03:26:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510543608; bh=Kbyy9+5GyEmvMKpzJ4haVadgbByQorYJXDyEwru/3HQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LwzhBmJeX944+fyxVGpEqdcn8uxRk3MPg3R5OreS4Ogk2uJpCDuJcEVNJ1QMu5hdm Hm2zOyHGJ4tv0bWZBaN8KK3DEp3/5yEtVfD94eWjjwF8LjXCbXkw1xaH4ZBx7Y/MJc 2w/YFuE3mSnSLSKXoWSYbPH2TWr8UzphAp1wr/rU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uROe_fcIp8PO for <dnsop@ietf.org>; Mon, 13 Nov 2017 03:26:47 +0000 (UTC)
Date: Sun, 12 Nov 2017 22:26:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510543607; bh=Kbyy9+5GyEmvMKpzJ4haVadgbByQorYJXDyEwru/3HQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ACFrQGumoZUls8smIwgQxmPY1/GI2rlbmrZP1vaP1ib14a+mxtkV6vVzPJj0z912j 9Pba9BZeGlAPjZckLhqAHnkg3NzcNCtz4Akv8uzC5m4LZ2izWZl4Eu7OK9C1T+Xmts c85m9rnv/GjfgluTpkj89GNBEKfoyK5XqWl9MnHc=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5A09068A.3030206@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cJVgoWtG0rHyie0dJ8zZPyrA7sE>
Subject: Re: [DNSOP] Clarifying referrals (#35)
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, 13 Nov 2017 03:27:33 -0000

Hi,

This is quite a helpful response, thanks.  I wonder whether more of it
ought to go in discussion (or a new draft), however.  For I'm struck
by this:

On Sun, Nov 12, 2017 at 06:42:18PM -0800, Paul Vixie wrote:
> > always be generated using only local data, and either contains the
> > answer to the question or a referral to other name servers "closer" to
> > the desired information.
> 
> the operative phrase is '"closer" to'. this is repeated in 4.3.1:

If I ask the authoritative server for example.com about a name
label.example.net, in a graph-theoretic sense the NS RRset for the
root zone is clearly closer to label.example.net than anything else I
can give.  So the upward referral doesn't seem prohibited by this at
all; on the contrary, it seems like a requirement.  Maybe I need to
read this again with better glasses.

The current approaches that people have for this are either NODATA
responses and REFUSED.  Only the latter seems obviously consistent
with the text, though I'm aware that there's controversy over using
REFUSED here.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com