Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie <paul@redbarn.org> Tue, 28 November 2017 23:19 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 1FA65128B44 for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 15:19:03 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 nSq-kqIJG9bD for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 15:19:01 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A202B126C26 for <dnsop@ietf.org>; Tue, 28 Nov 2017 15:19:01 -0800 (PST)
Received: from [172.31.1.47] (unknown [222.128.198.2]) (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 7FAC961FA2; Tue, 28 Nov 2017 23:19:00 +0000 (UTC)
Message-ID: <5A1DEEE1.3070809@redbarn.org>
Date: Tue, 28 Nov 2017 15:18:57 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>
CC: dnsop@ietf.org
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FbFT4BoxZAdM4E2l_c07xRdtaJQ>
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: Tue, 28 Nov 2017 23:19:03 -0000


Andrew Sullivan wrote:
> Dear colleagues,
>
> Joe Abley and I have just submitted a draft
> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
> that is intended to capture the discussion here about referrals and
> how to describe them.  It is intended for BCP, and it discourages
> upward referrals by authoritative servers.
>
> That leaves the task of the referrals definition.  I have some new
> text below:
>
> ---%<---cut here---
>
> ...
>
> The second is an upward referral (sometimes described as "root
> referral" or just "referral response", as distinct from the delegation
> response above), where the server is not authoritative for any portion
> of the QNAME.  When this happens, the referred-to zone in the
> Authority section is usually the root zone (.).  In normal DNS
> operation, this kind of response is not strictly speaking required to
> work, and in practice some authoritative server operators will not
> return referral responses beyond those required for delegation.
>
> ...
>
> ---cut here--->%---
>
> Comments, please.  Also, Joe and I solicit comments on the referrals
> draft proper, but it would be nice to put that in a different thread.

what would "to work" mean in the above text? if you ask some authority 
server a question, it is either authoritative for some part of it in 
which case you'll get NOERROR and either an answer or a referral, or it 
is not authoritative and nothing it can tell you will help in any way 
other than some kind of "i am not authoritative for any part of the 
question you have asked me".

that an upward referral could "work" in the above-reference sense seems 
to imply that the authority server you've queried, knows more about 
where the zone really is, than you could learn by walking down from the 
root. that's a walking talking nonsequitur. could you tell me what you 
really mean by "to work" since it can't possibly be that?

-- 
P Vixie