Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie <paul@redbarn.org> Mon, 13 November 2017 19:28 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 79D30129B06 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 11:28:46 -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 9tdJqS3bqMjw for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 11:28:45 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35353120721 for <dnsop@ietf.org>; Mon, 13 Nov 2017 11:28:45 -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 2A08361FA2; Mon, 13 Nov 2017 19:28:44 +0000 (UTC)
Message-ID: <5A09F26B.40705@redbarn.org>
Date: Mon, 13 Nov 2017 11:28:43 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.20 (Windows/20171012)
MIME-Version: 1.0
To: Matthew Pounsett <matt@conundrum.com>
CC: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
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> <c66000fbd9174916a1142650298c7632@XCASPRD01-DFT.dpu.depaul.edu> <20171113085235.2fddd72a@p50.localdomain> <CAAiTEH_ikmAryaAXbKxVBHODfJx4Vohb7XWUPnqGw9s41ZR_Bg@mail.gmail.com> <5A09EAA6.5010305@redbarn.org> <CAAiTEH_U6eSZhSHbztwKF0xvem2e6PENG34JftGGmizdsAJJpg@mail.gmail.com>
In-Reply-To: <CAAiTEH_U6eSZhSHbztwKF0xvem2e6PENG34JftGGmizdsAJJpg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gR1F5wj4Np-PCpEcM3WlqnycXys>
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 19:28:46 -0000


Matthew Pounsett wrote:
>
>
> On 13 November 2017 at 10:55, Paul Vixie <paul@redbarn.org
> <mailto:paul@redbarn.org>> wrote:
>
> > why is this nor a broken configuration?
>
>
> It's my understanding that SERVFAIL indicates that the server sending
> the RCODE–or in the case of a recursive response, the upstream
> authoritative server–has a broken configuration.  I don't believe
> SERVFAIL indicates "you followed a lame delegation."  As far as I'm
> aware, we don't have a clearly defined signal for that, which is why
> many implementations chose to use REFUSED in that case.

someone asking you an RD=0 question about a zone you're not 
authoritative for indicates a misconfiguration somewhere. this is what 
SERVFAIL is for, because at the signalling level, it tells the client 
that no possible query about that name can succeed, and it ought to stop 
sending questions like that to this server. it's no different in 
principle from "i'm out of disk space, so i can't fetch the zone, so 
even though i'm supposed to be a secondary, i can't do it right now."

> > http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/
>
> I haven't got the time this morning to search release notes, but I'm
> fairly sure that in 2012, when you wrote that article, current versions
> of BIND were already handing out REFUSED to indicate "I'm not
> authoritative for that."  At the very least it began doing that not long
> after.

the implication of REFUSED is that if someone else asked this question, 
we might be able to answer. so if BIND is doing what you say, it's wrong.

> ... If that were a problem, given BIND's market share, we should be
> seeing widespread brokenness, but I don't think we are–none that's
> making it from my support department to me or to our hostmaster@
> accounts, at any rate.

yikes! you remind me of the guy who said on nanog a few years back that 
since he wasn't seeing spoofed-source ddos attacks any more, we should 
all stop worrying about them.

your lived experience can be cause for concern, but never for complacency.

-- 
P Vixie