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

Mark Andrews <marka@isc.org> Thu, 06 August 2020 13:22 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 2FC3C3A0BA6 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 06:22:16 -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 s3qYdQ79YqPA for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 06:22:14 -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 A13683A0BA5 for <dnsop@ietf.org>; Thu, 6 Aug 2020 06:22:14 -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 9A2A53AB003; Thu, 6 Aug 2020 13:22:13 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8E8551600D2; Thu, 6 Aug 2020 13:22:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 730A21600B8; Thu, 6 Aug 2020 13:22:13 +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 KUGFq2FcAeRj; Thu, 6 Aug 2020 13:22:13 +0000 (UTC)
Received: from [172.30.42.68] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 46F15160042; Thu, 6 Aug 2020 13:22:12 +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: <9390cb8a-677f-7309-b466-c45643827b22@powerdns.com>
Date: Thu, 6 Aug 2020 23:22:09 +1000
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCAF1704-B545-4AB8-8133-85E7280ADCD6@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>
To: Pieter Lexis <pieter.lexis@powerdns.com>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XKNhRUcAm8hR4E8RaldpzNnl3IU>
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 13:22:16 -0000


> On 6 Aug 2020, at 20:28, Pieter Lexis <pieter.lexis@powerdns.com> wrote:
> 
> On 8/5/20 11:13 PM, Mark Andrews wrote:
>>> On 6 Aug 2020, at 04:51, Pieter Lexis <pieter.lexis@powerdns.com> wrote:
>>> On 8/5/20 8:03 PM, Brian Dickson wrote:
>>>> (I am not sure of the question/issue of including the SOA, or where that
>>>> would go, but I'll defer to anyone who knows or has an opinion. My gut
>>>> says, do whatever gets done for CNAME.)
>>> 
>>> The SOA MUST go in the packet. As a compliant resolver talking to an
>>> auth that does not implement SVCB will follow the chain and the auth
>>> will respond with NODATA (and thus the SOA).
>> 
>> You make a SVCB query you will get a CNAME if it exists at the QNAME, SVCB
>> if it exists at the QNAME or you will get NODATA if neither exists.
> If you
>> find a CNAME you repeat at the target of the CNAME.
>> 
>> If the server is SVCB aware it will then process the SVCB RRset and
> add those
>> records to the additional section, if any of those trigger additional
> section
>> processing those records too get added to the additional section.  This is
>> consistent with STD 13 that says words to the effect of “add anything
> useful” (I’m
>> not going to look up the exact words).  The additional section rules
> for SVCB say
>> to add CNAME, SVCB, A and AAAA to the additional section.
> 
> The semantic rules for the Alias form lead me to believe that an SVCB at
> the targetname *is* an answer to the question (no other SVCB at that
> ownername, at the very least no Service mode SVCB at that name).

SVCB is NOT A CNAME and despite it being called “ALIAS FORM” it does not produce the equivalent of CNAME processing in the ANSWER section.

I really don’t know how this thread got started with clear and unambiguous instructions to add all the records to the additional section.

"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.

> The end-clients (browsers, other programs actually querying for
> SVCB/HTTPS)
> 
> Looking at section 5.4.1 ("Ranking Data") of RFC 2181, a non-SVCB
> recursor might accept the data in the answer section:
> 
>  […]
>  + Data from the answer section of a non-authoritative answer, and
>    non-authoritative data from the answer section of authoritative
>    answers,
>  + Additional information from an authoritative answer,
>    Data from the authority section of a non-authoritative answer,
>    Additional information from non-authoritative answers.
> 
> On the other hand, a non-SVCB-aware resolver might even choose to drop
> both the data in the ANSWER and ADDITIONAL section that do not match the
> original QNAME. Thus only serving its client the SVCB alias record in
> the ANSWER section, leading to the end-client re-querying for the
> targetname SVCB record.
> 
> It would be good to know what most implementations do when they
> encounter in-bailiwick data with a different owner name in both the
> ANSWER and ADDITIONAL sections. Then the SCVB draft can pick the right
> method:
> 
> * Semantically correct (chained SVCB in ANSWER, using 'CNAME chasing')
> * Backwards compatible (All related data in ADDITIONAL)

Named ignores anything it is not expecting.  That said adding DNAME to the answer section caused problems (answers being rejected because a DNAME was present).  Adding unexpected stuff to the ANSWER section is always fought with problems.  If a client falls over because stuff was added to the additional section then the client is broken.

> Best regards,
> 
> Pieter
> 
> -- 
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com

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