IETF Logo Mail Archive

Re: [DNSOP] Clarifying referrals (#35)

Matthew Pounsett <matt@conundrum.com> Mon, 13 November 2017 18:37 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 D5774129ACD for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 10:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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_LOW=-0.7, 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 AdGvWbydYOMr for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 10:37:24 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 2D52B124BAC for <dnsop@ietf.org>; Mon, 13 Nov 2017 10:37:24 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id 189so21653492iow.10 for <dnsop@ietf.org>; Mon, 13 Nov 2017 10:37:23 -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=wq9jYjYbaQViDuOIwDUeeKhEVSKTCz8qVoOTiR9puHY=; b=zL2z5QYmVUL1USAmDUxHpUYBs8hRdcORxDWuRaxkubx3ucMmPc2mTVc+ScfhGdGlTM P0qRypJ75q8aeZcx8T9ihZlMXZOqfZHc9WuY+fu3SWDxhJO7JOj63Y63lHmKdP+Ucfkt LTuGqYCuUK1wa16GK13ccagNaBGi30IHcOawKfghIHjK8+hQvDwKC8lRzkWFqM092Yn4 e4+KlqzFmQg0NjUhHvxYGWIrM6cZx8ZryMDdpZscd5CZCtoj4fGtBz9Pg6TMkSqBIILb uvF28wL9OZxgKOsPTqOtO7emKTjmxrSnvCwkvvjsPD4PmhOtxGQLHVwfljEIgoWxZOXp spIQ==
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=wq9jYjYbaQViDuOIwDUeeKhEVSKTCz8qVoOTiR9puHY=; b=tNzj5i/G6laOfA3XNzIsOimz6O1zKQs37qpIxnbmFnBZY//RhRjnYEGHWPnnrLS6AU wNp2QZdlsCyK24cIZHozq/kJWKGAiHpMxfP8t0wdgN/PuyVMqOasRAgx4yM1R+kj5Zwr 4oUJij1QDvFpBKLwmwQp7Jhll6r4+8qLPUrL30g+qnUkbCl5TKxNnlya12pW64Rii+uA pHlkNd1aLlfDdX05iXESI7q6gmg80GWFWr5v+vIZ/udxweDINV3TpJ2ZRsY82iLMo5CP rM9JtX4524HW8nGzO70vdilJL3iJdEOGJ6s9u1r47LYh4CxhszQQFvBvh1wk0YFNxjeK AR4Q==
X-Gm-Message-State: AJaThX5f/EdY3n3mvQRm14dcSCpet9nuGEfaAbE8FEm0TN8+WXuXrxPU A2wny5CjjWr5cxYKMW9kSjz8+ZIDhWVY4eTi7ZoSf7HG
X-Google-Smtp-Source: AGs4zMaSRIyHhzJq3C63ooLLyGjSN2l3QpPTFZ8zW5fvIfybVR4o/cGxit/eVWBsfSrJsHWoAW/hmR3S5Ha+88w8LpA=
X-Received: by 10.107.170.153 with SMTP id g25mr7419901ioj.207.1510598243095; Mon, 13 Nov 2017 10:37:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.11.196 with HTTP; Mon, 13 Nov 2017 10:37:22 -0800 (PST)
In-Reply-To: <20171113085235.2fddd72a@p50.localdomain>
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>
From: Matthew Pounsett <matt@conundrum.com>
Date: Mon, 13 Nov 2017 10:37:22 -0800
Message-ID: <CAAiTEH_ikmAryaAXbKxVBHODfJx4Vohb7XWUPnqGw9s41ZR_Bg@mail.gmail.com>
To: jtk@aharp.iorc.depaul.edu
Cc: Andrew Sullivan <ajs@anvilwalrusden.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142ef84adaa51055de18fbc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9XSxow6_CsR_8kXcctX-bju4lSg>
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 18:37:26 -0000

On 13 November 2017 at 06:52, John Kristoff <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).   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.

v2.23.0 | Report a Bug | By Email