IETF Logo Mail Archive

Re: [DNSOP] Authoritative servers announcing capabilities

Paul Vixie <paul@redbarn.org> Mon, 14 September 2020 19:17 UTC

Return-Path: <vixie@redbarn.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 4FD723A0DD1 for <dnsop@ietfa.amsl.com>; Mon, 14 Sep 2020 12:17:00 -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_HELO_NONE=0.001, 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 4Tx0EeIQI_Sh for <dnsop@ietfa.amsl.com>; Mon, 14 Sep 2020 12:16:55 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89503A0E8D for <dnsop@ietf.org>; Mon, 14 Sep 2020 12:16:51 -0700 (PDT)
Received: by family.redbarn.org (Postfix, from userid 716) id 7A212C3F1A; Mon, 14 Sep 2020 19:16:49 +0000 (UTC)
Date: Mon, 14 Sep 2020 19:16:49 +0000
From: Paul Vixie <paul@redbarn.org>
To: "libor.peltan" <libor.peltan@nic.cz>
Cc: dnsop@ietf.org
Message-ID: <20200914191649.ytslgopffey2oa5r@family.redbarn.org>
References: <20200912004747.62kehhyez3fxyez5@family.redbarn.org> <D852AD4D-4729-40C0-BFC7-B9D1FD08DAC7@nohats.ca> <20200912014026.pbdfem6jcqfqcwdb@family.redbarn.org> <7a5f3d09-edec-aa64-01e3-6aba02ab9c9d@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7a5f3d09-edec-aa64-01e3-6aba02ab9c9d@nic.cz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/S8A-W8YxM22FoY1aJ5_8cND0yuw>
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: Mon, 14 Sep 2020 19:17:00 -0000

On Mon, Sep 14, 2020 at 04:32:52PM +0200, libor.peltan wrote:
> ...
> 
> While it seems reasonable to disclose some properties of the zone by an
> extra zone RR (although it would probably require extra query!), the
> properties of DNS server will often vary since implementation diversity is a
> general recommendation.

+1.

> I don't know the foreseeable use-cases for this or similar kinds of
> properties signalization. ...

in _structured requirements definition_ (1982), author ken orr puts forth a
strong argument that "data which is not used will be wrong" (among other
strong arguments).

https://www.amazon.com/gp/offer-listing/B002V1CES2/ref=tmm_pap_used_olp_0?ie=UTF8&condition=used

> By the way, the operators tend to hide properties of their server
> implementations, rather than disclose it. See version.server. CH TXT ...

also +1.

-- 
Paul Vixie

v2.23.0 | Report a Bug | By Email