[DNSOP] Fwd: Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

Mark Andrews <marka@isc.org> Wed, 05 August 2020 21:40 UTC

Return-Path: <marka@isc.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 05F5F3A0FB2 for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 14:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 VUNbHlYEy9kT for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 14:40:25 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 557FB3A0FB1 for <dnsop@ietf.org>; Wed, 5 Aug 2020 14:40:25 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2C2033AB006 for <dnsop@ietf.org>; Wed, 5 Aug 2020 21:40:25 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2223A16005B for <dnsop@ietf.org>; Wed, 5 Aug 2020 21:40:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 111E1160097 for <dnsop@ietf.org>; Wed, 5 Aug 2020 21:40:25 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id P8NGa-vuOvOE for <dnsop@ietf.org>; Wed, 5 Aug 2020 21:40:24 +0000 (UTC)
Received: from [172.30.42.68] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 2ED4D16005B for <dnsop@ietf.org>; Wed, 5 Aug 2020 21:40:24 +0000 (UTC)
From: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7BB8B3E1-6F06-4F4E-AFA7-A95622302E97"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
Message-Id: <2FE5E7AE-8702-4D2F-AC73-0720A4717A79@isc.org>
References: <E8D4629D-2FF9-455E-BBED-8F10917B69C8@isc.org>
To: dnsop <dnsop@ietf.org>
Date: Thu, 6 Aug 2020 07:40:21 +1000
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6gDWk4LYwc3wHnd6-kTSkmr8KQE>
Subject: [DNSOP] Fwd: Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
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: Wed, 05 Aug 2020 21:40:27 -0000


> Begin forwarded message:
> 
> From: Mark Andrews <marka@isc.org>
> Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
> Date: 6 August 2020 at 06:50:41 AEST
> To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
> 
> 
> 
>> On 6 Aug 2020, at 03:07, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org <mailto:bemasc=40google.com@dmarc.ietf.org>> wrote:
>> 
>> On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis <pieter.lexis@powerdns.com <mailto:pieter.lexis@powerdns.com>> wrote:
>> ...
>> Do *both* alias-target{1,2}.example.net <http://example.net/>|SVBC records end up in the
>> ADDITIONAL section. Or are they (as is the case with an in-zone CNAME)
>> considered an answer and should they go into the ANSWER section?
>> 
>> I think Section 4.1 is pretty clear that everything goes in the Additional section.  (But this can be changed!) 
> 
> It MUST go in the additional section.  It is not actually a alias.  It is a record that says what the names of the servers for the server are.  This is no different to MX or SRV in that usage.  Just stop using the loaded word “ALIAS” as it isn’t a alias.
> 
>> I find the alias mode semantics (on the DNS-level) unclear and
>> under-specified in the draft. I look forward to guidance from the authors.
>> 
>> And I look forward to guidance from you!  How do you think it should work?  Send text!
>> 
>> Personally, I'd like to know which of these questions actually need to be resolved in the standard, and which can safely be left to the discretion of implementors.  Is there a compatibility concern with any of these questions, or is it only a question of consistency across implementations?
>> 
>> Conceptually, AliasMode is not a CNAME: it only affects SVCB queries (not other RR types), and can safely be implemented entirely as an RFC 3597 Unknown RR Type.  That suggests that it is at least safe, and perhaps least-surprising, for the authoritative server to put all responses for other owner names in the Additional section, as the current text seems to indicate fairly clearly.
>> 
>> P..S. The text on this point has recently changed: https://github.com/MikeBishop/dns-alt-svc/pull/199#discussion_r444979971.  One of the questions there is what should happen for AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick.  The draft says "Clients and recursive resolvers MUST follow CNAMEs as normal.", but it no longer says anything about authoritatives.
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org <mailto:marka@isc.org>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org