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

"Robert Mortimer" <robm@scramworks.net> Thu, 13 February 2020 09:40 UTC

Return-Path: <robm@scramworks.net>
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 4629C1200C4 for <dnsop@ietfa.amsl.com>; Thu, 13 Feb 2020 01:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scramworks.net
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 1ySdnDOxAt42 for <dnsop@ietfa.amsl.com>; Thu, 13 Feb 2020 01:40:35 -0800 (PST)
Received: from knid.scramworks.net (knid.scramworks.net [IPv6:2a01:4f8:c17:50eb::2]) (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 7E54512007A for <dnsop@ietf.org>; Thu, 13 Feb 2020 01:40:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=scramworks.net; s=bofh; h=References:In-Reply-To:Cc:To:From:Subject: Message-ID:Date:MIME-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bUoq1lQP6SXGres7lRaYYkRvRlri/FzbaKuWaLb3dyw=; b=iUpm/HcWIKmCuCTvQEIKrK6JB NxgwiuNiiX+MvnVxWaABFQep3PYZSe6FK3/ntvLL756UPQZ59YJu0uESRTNHpoIXklu/YuKbmAtL0 58n/KWD1CcmH+rNkksCggWRxB2cf42NrP9Bb3e03xF8rNYn8oxgI+8Yv5qmqhZ0NV64+I=;
Received: from host-78-146-5-137.as13285.net ([78.146.5.137] helo=[192.168.1.107]) by knid.scramworks.net with esmtpsa (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from <robm@scramworks.net>) id 1j2Ayx-0005DR-Hz; Thu, 13 Feb 2020 09:40:28 +0000
Content-Type: multipart/alternative; boundary="----=_NextPart_47759534.203306141174"
MIME-Version: 1.0
Date: Thu, 13 Feb 2020 09:39:25 +0000
Message-ID: <Mailbird-aa3e2371-c39e-4468-8046-09a8626a6b30@scramworks.net>
From: Robert Mortimer <robm@scramworks.net>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop@ietf.org
In-Reply-To: <C4715BA3-747A-4518-9F1F-37C21C6DB12D@icann.org>
References: <158147423681.20010.1215769228895202180@ietfa.amsl.com> <Mailbird-d05777a4-cadd-4f3a-8a11-be497b917f90@scramworks.net> <C4715BA3-747A-4518-9F1F-37C21C6DB12D@icann.org>
User-Agent: Mailbird/2.7.9.0
X-Mailbird-ID: Mailbird-aa3e2371-c39e-4468-8046-09a8626a6b30@scramworks.net
X-Spam-Score-SW: -1.0 (-)
X-SW-Scan: 92b2e2270b41c18a5569277fe5287bef
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SRyyJsmiqC4euW3Gq20cPnyxWBs>
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: Thu, 13 Feb 2020 09:40:38 -0000

That would be clearer or possibly just change that first "MUST NOT" to 
"Authoritative only servers MUST NOT answer queries that are defined in this protocol."

As the advice that: 


"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." 


Surely means that it is answering a query made to the authoritative part so would again be contradicted by saying:
"MUST only answer queries that are intended for the recursive resolver portion of the server."

Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&amp;utm_medium=email&amp;utm_campaign=sent-from-mailbird]
On 12/02/2020 16:50:16, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Feb 12, 2020, at 1:59 AM, Robert Mortimer 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_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop