IETF Logo Mail Archive

Re: [DNSOP] Authoritative servers announcing capabilities

Robert Edmonds <edmonds@mycre.ws> Sat, 12 September 2020 01:34 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 2A5223A09FD for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 18:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 fClzXH3_7AWe for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 18:34:03 -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 6C5093A0A04 for <dnsop@ietf.org>; Fri, 11 Sep 2020 18:34:03 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 1366312CC9BE; Fri, 11 Sep 2020 21:34:02 -0400 (EDT)
Date: Fri, 11 Sep 2020 21:34:02 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20200912013402.GB703318@mycre.ws>
References: <20200912004747.62kehhyez3fxyez5@family.redbarn.org> <D852AD4D-4729-40C0-BFC7-B9D1FD08DAC7@nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D852AD4D-4729-40C0-BFC7-B9D1FD08DAC7@nohats.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Eusd8EKg2hQhX_KxNP1L1xF6Te4>
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:34:05 -0000

Paul Wouters wrote:
> On Sep 11, 2020, at 20:48, Paul Vixie <paul@redbarn.org> wrote:
> > 
> > On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote:
> >> and why is it a RR type at all.  An EDNS option or a opcode is better suited
> >> for this sort of thing.
> > 
> > +1.
> 
> An RR type can be signed and distributed differently and allow for preloading of (distributed) caches which enhanced the decentralization of recursive DNS servers.

As described in -00, a cached and re-distributed AUTHINFO RR is useless
unless you know what nameserver address it applies to, and if an
AUTHINFO RR isn't trustworthy unless it's signed then the AUTHINFO RR
would need to embed the nameserver address that it applies to so that
that information can be signed and validated as well.

-- 
Robert Edmonds

v2.23.0 | Report a Bug | By Email