IETF Logo Mail Archive

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

Tony Finch <dot@dotat.at> Mon, 10 August 2020 22:17 UTC

Return-Path: <dot@dotat.at>
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 0C5D83A0DFB; Mon, 10 Aug 2020 15:17:11 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 0f4wkU0pP1g1; Mon, 10 Aug 2020 15:17:09 -0700 (PDT)
Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (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 1DD603A0DE8; Mon, 10 Aug 2020 15:17:03 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55970) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1k5G6G-000E9A-nx (Exim 4.92.3) (return-path <dot@dotat.at>); Mon, 10 Aug 2020 23:17:00 +0100
Date: Mon, 10 Aug 2020 23:17:00 +0100
From: Tony Finch <dot@dotat.at>
To: Brian Dickson <brian.peter.dickson@gmail.com>
cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>, Pieter Lexis <pieter.lexis@powerdns.com>
In-Reply-To: <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2008102304160.21650@grey.csi.cam.ac.uk>
References: <00cfd965-bf69-d1cb-2df3-1a9bb110d7e0@powerdns.com> <CAHbrMsAJ-cbcW3v4T34f8-gzgzgHSkoBO545_Y3N8D6rof7Nmw@mail.gmail.com> <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Wfm9DtOd3zafDvsWlYpSW827zOA>
Subject: Re: [DNSOP] 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: Mon, 10 Aug 2020 22:17:11 -0000

Brian Dickson <brian.peter.dickson@gmail.com> wrote:
>
> What I would suggest is the following, paraphrased (i.e. please clean it up
> before using in the I-D, if you agree it's the right semantics):
>
>    - In-bailiwick CNAME, SVCB, A, and AAAA records SHOULD be added (and for
>    CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be iteratively
>    processed for inclusion)
>    - CNAME and SVCB records MUST be placed in the Answer section (because
>    of existing CNAME rules and because of RRTYPE match to the query)
>    - A and AAAA records MUST be placed in the Additional section (since
>    those would not match the query RRTYPE of SVCB)

I've only skimmed this thread, so I might be repeating something that's
already agreed... but I want to emphasize that a new RR type specification
will have impossible interop problems if it tries to put records in the
ANSWER section that aren't expected by existing DNS software.

"Unexpected" means anything that isn't part of a CNAME or DNAME chain on
the way from the original query name to an RRset of the query type.

If a resolver queries for the owner of SVCB record (or a CNAME pointing at
one) then anything related to the RDATA of the SVCB record(s) has to go in
the ADDITIONAL section, or there will be sadness.

It was a very long time before DNAME was usable and even within the last
10 years there was software that would choke on DNAME records in the
ANSWER section that it didn't expect.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Shannon, Rockall: Variable 2 to 4. Moderate, occasionally slight. Drizzle.
Moderate or poor.

v2.23.0 | Report a Bug | By Email