IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Wed, 12 February 2020 16:48 UTC

Return-Path: <paul.hoffman@icann.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 B2B29120825 for <dnsop@ietfa.amsl.com>; Wed, 12 Feb 2020 08:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 sGurtSEp4dbi for <dnsop@ietfa.amsl.com>; Wed, 12 Feb 2020 08:48:57 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 994DC1208D8 for <dnsop@ietf.org>; Wed, 12 Feb 2020 08:48:57 -0800 (PST)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 01CGmrxv031217 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Feb 2020 16:48:54 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 Feb 2020 08:48:51 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Wed, 12 Feb 2020 08:48:52 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Robert Mortimer <robm=40scramworks.net@dmarc.ietf.org>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-01.txt
Thread-Index: AQHV4cROJUELksk5MEKR3618E2ij8Q==
Date: Wed, 12 Feb 2020 16:48:52 +0000
Message-ID: <C4715BA3-747A-4518-9F1F-37C21C6DB12D@icann.org>
References: <158147423681.20010.1215769228895202180@ietfa.amsl.com> <Mailbird-d05777a4-cadd-4f3a-8a11-be497b917f90@scramworks.net>
In-Reply-To: <Mailbird-d05777a4-cadd-4f3a-8a11-be497b917f90@scramworks.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_B3B530FE-749C-4A35-AA80-0B7133E1A617"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-12_08:2020-02-11, 2020-02-12 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RFitPVQzhpoeKVwD_dFOR0xdPvI>
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: Wed, 12 Feb 2020 16:48:59 -0000

On Feb 12, 2020, at 1:59 AM, Robert Mortimer <robm=40scramworks.net@dmarc.ietf.org> wrote:
> 
> I may be missing something obvious but this draft seems to contradict it self as it says in the introduction:
> 
> "Authoritative servers MUST NOT answer queries that are defined in this protocol."
> 
> and then goes onto say in section 2:
> 
> "if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for the addresses on which it responds."
> 
> I also wonder what the correct behavior is for a server which is both recursive and authoritative - is it prohibited from supporting this protocol by that first "MUST NOT"? 

Good call. Would it make both parts clearer if the introduction instead said:

   Because the information returned in this protocol only applies to recursive
   resolvers, servers that are acting as both authoritative servers and recursive
   resolvers MUST only answer queries that are intended for the recursive
   resolver portion of the server. Servers that are only authoritative servers
   MUST NOT answer queries that are defined in this protocol.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email