Re: [DNSOP] refer-down

"John Levine" <johnl@taugh.com> Tue, 29 May 2018 01:34 UTC

Return-Path: <johnl@iecc.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 D8E7612D957 for <dnsop@ietfa.amsl.com>; Mon, 28 May 2018 18:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.753
X-Spam-Level:
X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=E1CKCNL7; dkim=pass (1536-bit key) header.d=taugh.com header.b=WH0hCSEL
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 O-gTO4rknH7L for <dnsop@ietfa.amsl.com>; Mon, 28 May 2018 18:34:09 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA0212D953 for <dnsop@ietf.org>; Mon, 28 May 2018 18:34:09 -0700 (PDT)
Received: (qmail 54088 invoked from network); 29 May 2018 01:34:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d346.5b0cae0f.k1805; bh=Q9kaIxIoJtVq2r+0Y0Mn9i1c4R/gDszkzK9TrthFmBA=; b=E1CKCNL7t9Xkn+bAPWdzTE9n67qf3NPD55sYRjlmguD/et8vCOOXygKij0ApOaWeKGww3Qn65tkhC+dTvF6fSvIs9lKJmJEGd4YFpTVp52jL7zE5nZ2cfcdQsrgVSpcFWmEs7Bh6ORU45PP4uEs3GWFg4ru6oiSmQiWz2uIYr/dNFSY86CD7b7d152RF8LhT9nOhJPXLdp7fjtzZdq2WPz3iFmtk6f5Q9SDLpOS+XvjimGYhGvl81/EKhRULd/3u
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d346.5b0cae0f.k1805; bh=Q9kaIxIoJtVq2r+0Y0Mn9i1c4R/gDszkzK9TrthFmBA=; b=WH0hCSELV1vB72V5m/B3aXiqk1dCDjEKp/rA2IKZYUD9ENmyx46GEol2Onsj01WngUOiss9uNN2h1Qf5JGFX2zih1Uykf3caH88Vp2hwmbpnylqDMnnP5xW1VB4Dj4hSWCAARNREnpvArVeKlwVdFDOyjBqRUvJxZaiPP11ZuvlVcaFRAAbJyxraKs2XQxXAafrGHTAOI23YM5ME75pXuZfQlHvk4gT9uAq3Dbgb8R6aZMcAD09FGwl/tmnsSH3+
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 29 May 2018 01:34:07 -0000
Received: by ary.qy (Postfix, from userid 501) id 0C55F273EFA2; Mon, 28 May 2018 21:34:06 -0400 (EDT)
Date: Mon, 28 May 2018 21:34:06 -0400
Message-Id: <20180529013407.0C55F273EFA2@ary.qy>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
Cc: ajs@anvilwalrusden.com
In-Reply-To: <20180528184759.GI12038@mx4.yitter.info>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/aQaqF0zNQfvygxRSuBIDmYckkDk>
Subject: Re: [DNSOP] refer-down
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, 29 May 2018 01:34:11 -0000

> Also, you're the only person who's commented directly and that makes
> me think the WG isn't going to do much review of it

Sheesh, it's a national holiday in the US and UK today.  Some of us
were out having picnics.

I like it because I like anything that makes the DNS simpler.  I'd
make the advice clearer, authoritative servers that want to
interoperate MUST refuse out of zone requests.  (I realize there are
some clients that will misinterpret that but they're already so broken
it's hard to care if they are now differently broken.)  It's MUST
rather than SHOULD because of course you can do what you want, but you
will not interoperate with a standard compliant client by returning
anything else.

I'd also like to consider offering clearer advice on what do do when a
recursive server gets an authoritative query.  Is there any situation
other than misconfiguration or testing when that would happen?  Are we
doing anyone a real favor by returning anything other than REFUSED?

R's,
John