Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie <paul@redbarn.org> Wed, 29 November 2017 03:08 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 B6C0912706D for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 19:08:06 -0800 (PST)
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 WWMHDf2ccqTa for <dnsop@ietfa.amsl.com>; Tue, 28 Nov 2017 19:08:05 -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 A3B7E1200C1 for <dnsop@ietf.org>; Tue, 28 Nov 2017 19:08:05 -0800 (PST)
Received: from [192.168.43.106] (unknown [223.104.3.191]) (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 F303C61FA2 for <dnsop@ietf.org>; Wed, 29 Nov 2017 03:08:04 +0000 (UTC)
Message-ID: <5A1E2491.9070805@redbarn.org>
Date: Tue, 28 Nov 2017 19:08:01 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info>
In-Reply-To: <20171129014748.7rrm2tvwdnjdl6ss@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/k_dVbGo7FAtxNpY6X8f-uYEDanI>
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: Wed, 29 Nov 2017 03:08:07 -0000


Andrew Sullivan wrote:
> On Tue, Nov 28, 2017 at 03:18:57PM -0800, Paul Vixie wrote:
>
>> what would "to work" mean in the above text?
>
> "Not strictly speaking required to work" was intended to observe that,
> if you didn't get a referral under this condition, nothing ought to
> break (or, if it did, it was already broken).

that's fatally unclear.

> ... The point is in contrast to the downward referrals case, which
> _must_ work or delegation doesn't. I'm nervous about someone running
> off saying, "IETF says referrals don't work," which is clearly not
> the point.

then the thing to say would be "a referral should always be downward, 
and if a non-downward referral is received, it should be treated as a 
network data configuration error".

>> 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?
>
> Indeed, it is not that. Suggestions on how to make this clearer are
> welcome.

Evan Hunt wrote:
> I'd suggest something like "this response is not strictly speaking
> necessary, as it provides no information the resolver didn't already
> have; resolution can succeed without it."

i don't think we can walk this path without touching the "should" fire.

-- P Vixie