Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie <paul@redbarn.org> Sun, 12 November 2017 17:20 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 77C251243FE for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 09:20:39 -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 60oPQxev74XG for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 09:20:38 -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 9A37412008A for <dnsop@ietf.org>; Sun, 12 Nov 2017 09:20:38 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (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 E757B61FA2; Sun, 12 Nov 2017 17:20:37 +0000 (UTC)
Message-ID: <5A0882E5.1080500@redbarn.org>
Date: Sun, 12 Nov 2017 09:20:37 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
CC: Andrew Sullivan <ajs@anvilwalrusden.com>, dnsop@ietf.org
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org>
In-Reply-To: <20171112131831.GA32208@laperouse.bortzmeyer.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1l4QS61Bs8yBx_gsedSkDtD4k1s>
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: Sun, 12 Nov 2017 17:20:39 -0000


Stephane Bortzmeyer wrote:
> On Sun, Nov 12, 2017 at 02:54:46AM -0500,
>   Andrew Sullivan<ajs@anvilwalrusden.com>  wrote
>   a message of 74 lines which said:
>
>> The second is a non-delegation referral (sometimes described as
>> "referral response", as distinct from the delegation response
>> above), where the server is not authoritative for any portion of the
>> QNAME.  In this case, the referred-to zone in the Authority section
>> is usually[1] the root zone (.).
>
> This is an upward referral and I tought it was frowned upon since the
> ISPrime attack (MUST NOT?  SHOULD NOT?)

it is frowned upon, but the strongest we can do is SHOULD NOT, since 
current implementations do it, and other current implementations must 
expect it.

-- 
P Vixie