IETF Logo Mail Archive

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-resolver-information-01.txt

Tony Finch <dot@dotat.at> Mon, 17 February 2020 14:32 UTC

Return-Path: <dot@dotat.at>
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 D71F4120850 for <dnsop@ietfa.amsl.com>; Mon, 17 Feb 2020 06:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=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 K9utL1tRDsLk for <dnsop@ietfa.amsl.com>; Mon, 17 Feb 2020 06:32:00 -0800 (PST)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 F3487120846 for <dnsop@ietf.org>; Mon, 17 Feb 2020 06:31:59 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:52536) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1j3hRC-000YnW-SK (Exim 4.92.3) (return-path <dot@dotat.at>); Mon, 17 Feb 2020 14:31:54 +0000
Date: Mon, 17 Feb 2020 14:31:54 +0000
From: Tony Finch <dot@dotat.at>
To: Niall O'Reilly <niall.oreilly@ucd.ie>
cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop@ietf.org, Robert Mortimer <robm=40scramworks.net@dmarc.ietf.org>
In-Reply-To: <AC2B1A5C-154B-4111-86A3-298E1C1C6356@ucd.ie>
Message-ID: <alpine.DEB.2.20.2002171425580.12712@grey.csi.cam.ac.uk>
References: <158147423681.20010.1215769228895202180@ietfa.amsl.com> <Mailbird-d05777a4-cadd-4f3a-8a11-be497b917f90@scramworks.net> <C4715BA3-747A-4518-9F1F-37C21C6DB12D@icann.org> <AC2B1A5C-154B-4111-86A3-298E1C1C6356@ucd.ie>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zq_nyZ3ix6Co76NXDHr7NfQbyA0>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-resolver-information-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Feb 2020 14:32:03 -0000

Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
>
> I think that a clearer expression of the first case might be
>
>   any server that can act as both an authoritative server and a recursive
>   resolver MUST NOT answer queries that are defined in this protocol
>   whenever it is acting as an authoritative server.
>
> If this still seems to leave a contradiction, it may be worthwhile to
> view the distinction as a property of the transaction, rather than of
> the "portion of the server".  The server, if it receives a query for
> which it determines that an authoritative answer is appropriate, must
> not answer as if it were a recursive resolver.

The conditions for special recursive-only answers are queries with RD=1
that get responses with RA=1. (You might be able to allow queries with
RD=0 but I don't know if iterative clients that happen to be allowed RA=1
are likely to be confused by these answers.)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
partnership and community in all areas of life

v2.23.0 | Report a Bug | By Email