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

Mark Andrews <marka@isc.org> Thu, 06 August 2020 23:11 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 DB6F43A0796 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 16:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sx1tNmUDYdWw for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 16:11:27 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 590633A0788 for <dnsop@ietf.org>; Thu, 6 Aug 2020 16:11:27 -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 440A33AB00A; Thu, 6 Aug 2020 23:11:26 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 33F9B1600B8; Thu, 6 Aug 2020 23:11:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1D22E1600D2; Thu, 6 Aug 2020 23:11:26 +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 zP7AnPARVWas; Thu, 6 Aug 2020 23:11:26 +0000 (UTC)
Received: from [172.30.42.68] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id E24701600B8; Thu, 6 Aug 2020 23:11:24 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAH1iCioaitgh1JYNLcqawkg06WLG8FqmmDV0LkOrAaqUuNBNcQ@mail.gmail.com>
Date: Fri, 7 Aug 2020 09:11:19 +1000
Cc: Pieter Lexis <pieter.lexis@powerdns.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F828CCE-81C5-4354-874B-93D7CFC3E730@isc.org>
References: <00cfd965-bf69-d1cb-2df3-1a9bb110d7e0@powerdns.com> <CAHbrMsAJ-cbcW3v4T34f8-gzgzgHSkoBO545_Y3N8D6rof7Nmw@mail.gmail.com> <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com> <cd6021e7-4aad-c2fc-e9ef-948fbeab0809@powerdns.com> <8BC20DED-784F-4004-9E56-8BB2F6356FA7@isc.org> <9390cb8a-677f-7309-b466-c45643827b22@powerdns.com> <DCAF1704-B545-4AB8-8133-85E7280ADCD6@isc.org> <CAH1iCioaitgh1JYNLcqawkg06WLG8FqmmDV0LkOrAaqUuNBNcQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_4wfGuzM4Qv4_2mnOCMeMBKCg7U>
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: Thu, 06 Aug 2020 23:11:29 -0000


> On 7 Aug 2020, at 04:03, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> 
> 
> 
> On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews <marka@isc.org> wrote:
> 
> 
> I really don’t know how this thread got started with clear and unambiguous instructions to add all the records to the additional section.
> 
> The possibility of changing what is specified in the draft, was what started this thread.
> Your responses all suppose that it is not possible to change what is specified in the draft.
> It would be helpful (IMHO) to the conversation to give consideration to the contents of the thread, from the perspective that the specs in the draft are not absolutely set in stone and immutable.
> 
> Here's the quote from Ben:
> I think Section 4.1 is pretty clear that everything goes in the Additional section.  (But this can be changed!) 
>  
> 
> "Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records) and return them in the Additional Section of the response. Clients either use responses included in the additional section returned by the recursive resolver or perform necessary SVCB, A, and AAAA record resolutions. DNS authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional Section to responses for a SVCB query."
> 
> Yes this means you need may need to change additional section process to chase other records.  Named was already doing this for one type and with HTTPS and SVCB needing we made the processing general.  Yes, it also means that one has to add CNAMEs to the additional section when processing HTTPS or SVBC.
> 
> 
> We can all read, and we understand what the current draft says.
> That's NOT what is being discussed (how to interpret those words).
> What IS being discussed in this thread is whether it may be more sensible to align the process of handling the "alias" form in a manner more consistent with how CNAME processing happens.
> It is a proposal to change the spec itself, rather than an alternate interpretation of what the current draft of the spec says.
> 
> This is why I suggested that, while it is not CNAME per se, treating it as "constrained alias applicable only to SVCB queries" isn't a huge leap, and would simplify the code for handling alias form, on both the server and client side of a lookup.
> 
> If the standard says they belong in the Answer section (as I am suggesting), I think the expected BIND client-side handling of SVCB records (alias and non-alias, if in-bailiwick) and CNAME records if they are both placed in the answer section by the server should be okay, in both situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB handling logic is added.
> 
> Brian

What benefit is there in changing this now?  Moving the SVBC chain (graph actually) to the answer section.  I know I can follow a graph much easier in the additional section than I can in the answer section with simple depth limited recursion.  In the answer section I have to initiate multiple parallel recursions to complete the graph hitting different zones. What happens when one of those recursions fail? Do I return a partial answer? Do I SERVFAIL the entire query?  What if one returns NXDOMAN? With everything in the addition section those questions go away.  I return what I have.  I can initiate speculative queries for missing RRsets where I don’t have NODATA/NXDOMAIN cached so when the client comes back I have the response in cache.

The code point has been allocated.  Implementations have been written to the existing spec.  That’s what happens when you ask for a code point. You are saying:
* This is its wire form.
* This is its presentation form. 
* This is what the nameserver does. 
Now we can go play with the rest of the specification and tidy that up with nameservers that know about the code point. Working group chairs are supposed to believe the specification is in this state of readiness before asking for a early code point.

If you want to compare to CNAME and query for CNAME you get back exactly 1 CNAME record even if there is a chain of CNAME records.  The target is not followed.  This is RFC 1034 behaviour.

What I would like is for SVCB alias form to ONLY require looking for SVCB records and SVCB service mode to only require looking up address records.  At the moment there is a scatter gun approach though I may have missed something.  CNAME/DNAME records are found as a side effect of looking for other types.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org