IETF Logo Mail Archive

Re: [DNSOP] Authoritative servers announcing capabilities

Ray Bellis <ray@bellis.me.uk> Sat, 19 September 2020 09:51 UTC

Return-Path: <ray@bellis.me.uk>
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 8BC693A0D2C for <dnsop@ietfa.amsl.com>; Sat, 19 Sep 2020 02:51:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.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 C4iL-YUwb10l for <dnsop@ietfa.amsl.com>; Sat, 19 Sep 2020 02:51:14 -0700 (PDT)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::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 DB7AF3A0CE8 for <dnsop@ietf.org>; Sat, 19 Sep 2020 02:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: 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=tBoBWuHmvfrmPnF5/tgO2gTVzi1XEYzE9J7/LM8u4c0=; b=iZaYz7UcUz4i/Q7VQJsgx2boMP 0tfO9XUR0ENVieOi2ytnEH0sHeLjdKuoLQUpdoNrID0GT9YWsn3cX0Ia8twXHU9hqa4SC1B1ZoegT CuxnWnSfHJjXosaWXq8pdPj/9k5eVbWmFqk+idnjg5AE3cFxaY8YFnjddyC41rk7SqcA=;
Received: from [216.213.184.174] (port=52657 helo=home-mbp.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1kJZWR-0006ni-61 (Exim 4.89) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Sat, 19 Sep 2020 10:51:11 +0100
To: dnsop@ietf.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>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <f8b3ff10-a1a2-ae5b-8e14-14625c49177e@bellis.me.uk>
Date: Sat, 19 Sep 2020 10:51:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <7a5f3d09-edec-aa64-01e3-6aba02ab9c9d@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/M6q1Q8yHA9QElcVjuEheEo34-Fk>
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, 19 Sep 2020 09:51:16 -0000


On 14/09/2020 15:32, libor.peltan wrote:
> Let me leave some personal opnion/comments on this AUTHINFO idea, 
> although I don't know the background here.
> 
> There are multiple kinds of "capabilities" of an authoritative server.
> 
> Some of them are properties of the zone, some are properties of the DNS 
> server implementation, some are properties of the operational policy. 
> For examples: DNS algorithm, EDNS version, network MTU, respectively.
> 
> 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.

The initial drafts of what became DNS Stateful Operations (RFC 8490) 
included something akin to a server capabilities exchange / negotiation.

Personally I think EDNS is the wrong place for negotiating server 
properties because unless you're using TCP there's no guarantee that the 
server whose properties you've cached is going to be the one that 
answers the next query you send to that address.

The flip side is that RFC 8490 support is currently rare, and is perhaps 
one of those server capabilities one wants to find out about :p

Ray

v2.23.0 | Report a Bug | By Email