IETF Logo Mail Archive

Re: [DNSOP] Authoritative servers announcing capabilities

Robert Edmonds <edmonds@mycre.ws> Sat, 12 September 2020 01:29 UTC

Return-Path: <edmonds@mycre.ws>
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 E314F3A09FD for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 18:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 CZnND35iM-Kh for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 18:29:36 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E753A09FA for <dnsop@ietf.org>; Fri, 11 Sep 2020 18:29:36 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id DF12912CC9BC; Fri, 11 Sep 2020 21:29:35 -0400 (EDT)
Date: Fri, 11 Sep 2020 21:29:35 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20200912012935.GA703318@mycre.ws>
References: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3OKFtd2qlF4bn5L-QUvBUVHoByg>
Subject: Re: [DNSOP] Authoritative servers announcing capabilities
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: Sat, 12 Sep 2020 01:29:38 -0000

Paul Hoffman wrote:
> The responses will be signed if the zone for which the server is authoritative is signed, meaning that validating resolvers can get authenticated information about the server if that would influence how they treat responses from the server.

How does the zone signer know the capabilities of the nameservers that
will serve the zone and what does it do if the capabilities of those
servers differ? It sounds like this is incompatible with offline
signing.

Must a primary nameserver exclude AUTHINFO RR's from outgoing AXFRs to
secondary nameservers? Must secondary nameservers fail, filter, or
replace an incoming AXFR if it contains an AUTHINFO RR? By making this
an RR it seems like it would be easy to inadvertently serve an incorrect
AUTHINFO RR.

I think this should be an EDNS option rather than an RR and if integrity
protection beyond that of plain DNS is needed, it can be combined with
COOKIE, SIG(0), TSIG, DoT, etc.

-- 
Robert Edmonds

v2.23.0 | Report a Bug | By Email