IETF Logo Mail Archive

Re: [DNSOP] Clarifying referrals (#35)

Matthew Pounsett <matt@conundrum.com> Mon, 13 November 2017 19:12 UTC

Return-Path: <matt@conundrum.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 96A3C124C27 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 11:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com
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 KD6WEErxUIgY for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 11:12:54 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C53120721 for <dnsop@ietf.org>; Mon, 13 Nov 2017 11:12:54 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id w127so4381478iow.11 for <dnsop@ietf.org>; Mon, 13 Nov 2017 11:12:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I+2Z5Ouer93RC2e+D7BZOuh6WKdMrIlCOzhLTFdOmo0=; b=XGZqEObEAxOB92pfH5ZoeRCA22MvbFOozbqrKdWXJ+5gMm67zM+OYRj11d7YGPamqk oh5N0Sza/dAdCfrAmbzBo153d0Hxv1n0cUUQm36MIYg00SuBWWJonAsM2QWBwQfB7Ydg wUOadckq4hCvXBqfU/b5dNiUw2m5poWUUQPYsggVT3fU43wigMnCKcy09otbwRDjKkAU sYfvdTsDLhAZYn9DzlXSDETo19M15XSIbgA22RBbmj/rFuOQSlv1MLVoiANqbDgTpXew xebOHHPdBcHkALHexVhNHUI+9kIiY3aSVJ5uk9MOHFkW23DQwkQq64yoD3FZxEoe2JTF hUxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I+2Z5Ouer93RC2e+D7BZOuh6WKdMrIlCOzhLTFdOmo0=; b=KH4dCdPnmI+AlGnd9LxMHOGduuInXElWO1o1p1p+iptKysBdBJpOHS32qDu6YxQG/e h0b25K6QhygzgISCPhGmKSjvXdg2UabtNmkJ+2cy3ICPZ9dQxxF8Bfn2NFmY4o8MMf9F wOS5x7nLlrcS0uI7++DgUMrHsjrjy4Ocou6NBTscE9d+GTPwZSlJ/CfFEwH/RhfeV86N Jo6WVjGYubvX5O22k0RjUq9q7gHB87jBVt30jWMUXDqD/x4qwelIv0oRSSOc4VURRkuE UTRECtx+hKUBY4q0T0g1UqYSiWAdTNYTOOIQ6rGp7NvRNjckM3nBqwVuQ532njgUX+wh NzGQ==
X-Gm-Message-State: AJaThX69dyF/qJyZwN3k9d03W+uxNf4uTSC9akGzzux4CXJjd8Qil75o FbHtsDoDT+u9GcPu2tkgN8zQ5grPIeBu6L1lTPbbpw==
X-Google-Smtp-Source: AGs4zMY5LzQ7aZ1rpTpsJj9qH6tLQg8BwSQTCGjJWoMTuAa9+Fyl7VmDhXHxW1IA9e0FaXDrTk4sa4bKPPhik+ubztg=
X-Received: by 10.107.128.1 with SMTP id b1mr7751139iod.164.1510600373522; Mon, 13 Nov 2017 11:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.11.196 with HTTP; Mon, 13 Nov 2017 11:12:52 -0800 (PST)
In-Reply-To: <5A09EAA6.5010305@redbarn.org>
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>
From: Matthew Pounsett <matt@conundrum.com>
Date: Mon, 13 Nov 2017 11:12:52 -0800
Message-ID: <CAAiTEH_U6eSZhSHbztwKF0xvem2e6PENG34JftGGmizdsAJJpg@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" <dnsop@ietf.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Content-Type: multipart/alternative; boundary="001a113f8fd0a96904055de20e0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jB0KvCtBJITIY12ZsQZLBMtcOA4>
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:12:56 -0000

On 13 November 2017 at 10:55, Paul Vixie <paul@redbarn.org> wrote:

>
>
> Matthew Pounsett wrote:
>
>>
>>
>> On 13 November 2017 at 06:52, John Kristoff <jtk@depaul.edu
>> <mailto:jtk@depaul.edu>> wrote:
>>
>>     REFUSED does not seem ideal to me either, but what if anything might
>> be
>>     better is probably ripe discussion in a new draft.
>>
>> It makes perfect sense to me.  REFUSED is an indication that the querier
>> has been blocked from asking that question (or receiving the answer they
>> requested) by configuration, as distinct from a broken configuration
>> preventing them from getting that answer (SERVFAIL).
>>
>
> 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.


>
> ... Given that upward
>> referrals have obvious problems (There is no protocol or process to tell
>> a TLD operator "I am not authoritative for that delegation someone else
>> asked you to point at me") it seems to me that REFUSED is the only
>> obvious choice for indicating that an authoritative-only server is not
>> authoritative for anything at or below the QNAME.
>>
>
> i strongly disagree. this is not an administrative denial scenario. see,
> again:
>
>
> 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.   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.

v2.14.0 | Report a Bug | By Email