Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

Paul Vixie <paul@redbarn.org> Tue, 05 January 2021 22:12 UTC

Return-Path: <paul@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 118EA3A0062 for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 14:12:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 grHTzge22Rzy for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 14:12:14 -0800 (PST)
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 9A9FB3A09B5 for <dnsop@ietf.org>; Tue, 5 Jan 2021 14:12:13 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:f517:a635:6f34:59a8] (unknown [IPv6:2001:559:8000:c9:f517:a635:6f34:59a8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 6ECD1C3F03; Tue, 5 Jan 2021 22:12:11 +0000 (UTC)
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: "libor.peltan" <libor.peltan@nic.cz>, dnsop <dnsop@ietf.org>
References: <160435342340.5690.11246183519764836508@ietfa.amsl.com> <CAHbrMsCfxhv_fiSMuZNb+Rx=p_oa-Z682sAj8D4y7YkAf0=Lgg@mail.gmail.com> <500fe764-612b-a7d6-3d2c-efbf02d1b75c@nic.cz> <CAHbrMsDbYZ=JUGN8Cgy9Dhotzd=7Tg5iX6UyNBtEaLP-F6fF8g@mail.gmail.com>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <b5334883-fed3-ce75-0ea2-faedd81a7e1b@redbarn.org>
Date: Tue, 05 Jan 2021 14:12:09 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.43
MIME-Version: 1.0
In-Reply-To: <CAHbrMsDbYZ=JUGN8Cgy9Dhotzd=7Tg5iX6UyNBtEaLP-F6fF8g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cvOJzS_GGhzzCSUCXEFYb0WOD9c>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.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: Tue, 05 Jan 2021 22:12:16 -0000

a small matter.

Ben Schwartz wrote on 2021-01-05 09:42:
> 
> 
> On Wed, Dec 30, 2020 at 4:39 AM libor.peltan <libor.peltan@nic.cz
> <mailto:libor.peltan@nic.cz>> wrote:
> 
>     Hi Ben, all,
>     i'd like to ask for some clarification of expected Authoritative
>     server behaviour around Alias SVCB records:
> 
>     1) when there are multiple Alias SVCB records for an owner name,
> 
> As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource
> record in AliasMode".  So this "should" not happen. 

can you specify that if it does happen, the client behaviour should be
the same as if there are no matching records? otherwise clients will
have degrees of freedom, which i think would not end well.

> 
>     should the Authoritative server put targeted records into
>     Additionals for all of them, or just pick one?
> 
> I think the answer is "whatever you would do with CNAME".  Just like
> CNAME, there really should only be one record in the RRSet. If you put
> more than one AliasMode record in the RRSet ... you're doing it wrong
> (but the resolver will still do something reasonable).

to be clear, for CNAME the referenced records are added to the answer
section, not as in this case the additional section.