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

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 07 August 2020 02:49 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 E44C43A0D1F for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 19:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2ERfAWGBJ5sK for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 19:49:18 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B1F3A0D1E for <dnsop@ietf.org>; Thu, 6 Aug 2020 19:49:18 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id a21so228201vsh.11 for <dnsop@ietf.org>; Thu, 06 Aug 2020 19:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s19yBYsR7v37b9HRa1WyEvy94Ka9r1hJ3/6tJNXaOK0=; b=MWE+PHkUMXTF24UDppatPEY23Iffa5jCs07Yk7dkwpK0ndfuRePjscY2ZuEc7ljguu vtSiw3U+1lkVnN7V835J8nvvOTftTDAtVBnIg9zIKD51YPs+ec1IwWjQzGJ9EBegxczb jMRHLW2LbnU4hBhmtyvpIPxbqqU8Bd+ql7r1KVVFbh7x0yaMAHtaYOhcU28PlJiNQiVC 5HIqhBr7spsWQ/zBUWBBFOOaJHfKtvaVwdXkTE+36NiL8/iBB6H6skkBXUTIhmOLgi5Y TIEInktqdvIMILUzmcRl+umY8QXX1wDDH0uD2o78dgLNHBDmRi8lMn/itBwckBbSji0I oFqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s19yBYsR7v37b9HRa1WyEvy94Ka9r1hJ3/6tJNXaOK0=; b=FjPK8PBvhzR4QYb2yH6zeqc1m9b6//UZo8Ve4ex7hYduH1273AhLhLE/AU8J8fWBtn kP+7krlGbc0hsvWZ/kgUU0hU6jpqbrONu6+txU/ECHhzhGrOo4VSzoZqo2oXyUQUKK5a t0YzVW+KVakBB5nMG726/HRJ5/EbUvH63IwdcWAHJyyov/K+n4C2m5aoLJPpOZ+hXZS+ OINkfLVKr/U8rMmrW3I74DRe3IqETJPTNdhz8EGxnhA5+TYTHifbv8e1xTIz+9LZ3Zdo DXP3bKjAif5yjlRq0Vj1opofo2f0GitebYvRmFM+6WSAgrOmPegAvX2YSH9rP2ToIEHu gTeQ==
X-Gm-Message-State: AOAM533ffe+EpaKznI+oJmidH9MY6VcYFWC+3t531/Yc1Rz042yzBxUr FQUqv2srFmlI+uOLjeDnahTRaFqH6ju+vu/EOiw=
X-Google-Smtp-Source: ABdhPJyqs91dHL5MeRQq0OpQrSXcSH2QgYBlh4PZMO4cA+rOQzpwehhlHVf6Ln2inGfQykwi3k6WvDkew3UZVZutNH4=
X-Received: by 2002:a67:e81:: with SMTP id 123mr8642390vso.75.1596768557722; Thu, 06 Aug 2020 19:49:17 -0700 (PDT)
MIME-Version: 1.0
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> <9F828CCE-81C5-4354-874B-93D7CFC3E730@isc.org> <CAH1iCipP7p8UayYAgzWSO3CTYZryJX_NVqPJka4je982wjsrKQ@mail.gmail.com> <CAHbrMsA0bbqJE=BGgyO+SCKB3BtVAu4E4TDzK-43quPWrSRPiw@mail.gmail.com>
In-Reply-To: <CAHbrMsA0bbqJE=BGgyO+SCKB3BtVAu4E4TDzK-43quPWrSRPiw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 6 Aug 2020 19:49:06 -0700
Message-ID: <CAH1iCiphv+H0HxvNsjJ3Kgtn+z4AKrreKeX57tcOATHBx2B9RQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Mark Andrews <marka@isc.org>, Pieter Lexis <pieter.lexis@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000abf0a705ac40a64d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/exVC7G6YG_BdbrhbtEChDoBIsRw>
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: Fri, 07 Aug 2020 02:49:21 -0000

On Thu, Aug 6, 2020 at 7:13 PM Ben Schwartz <bemasc@google.com> wrote:

> Brian,
>
> I think arguing about the strength of the analogies to CNAME (Answer) vs
> SRV (Additional) is going to be a slow path to consensus.  Apart from that
> analogy, I'm not sure I understand your motivating use case.  Could you
> write a small example zone where you think the "chain in Answer" behavior
> has a clear advantage over "chain in Additional"?
>

Sure. Here are two very similar examples, where the first one I think is
required to put the entire chain in the Answer for ${reasons}. (Take as
ready any underscore prefixing needed to make this make sense...)

whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-common-thing.example.com.
my-common-thing.example.com. CNAME my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB <not=0> <stuff>

whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB <not=0> <stuff>

The motivation here is that the optimization of adding in-bailiwick records
should, to maximize the benefit to the resolver and to the authority
server, process the second CNAME of the first example.

However, if the placement of the in-bailiwick TargetName's records is in
the Additional section, this is somewhat more complex. Either the CNAME
processing has to happen before the TargetName and CNAME canonical name
records are collectively placed in the Additional section, or the
Additional section must now also process the CNAME. Not doing either of
those would leave a "dangling CNAME" in the Additional section, which would
then necessitate an additional query round-trip from the recursive to
authoritative.

Putting them all in the Answer section, means normal Answer section
handling would basically handle the second CNAME "for free".

This is all opportunistic behavior. It doesn't matter whether the extra
records are added or not, so their absence from either section does not
imply their non-existence, nor does it imply the authoritative server is
aware or unaware of SVCB.

I'm not sure I understand why having them be in the Answer section is any
different from having them be in the Additional section, when it comes to
their handling upon receipt by a recursive resolver.

If the rules were "Put any SVCB records into the Answer section along with
CNAME records found while obtaining them", then the only records that
should be in the Additional section would be A/AAAA records and related
DNSSEC records (and possibly CNAMEs found when obtaining the A/AAAA
records?).
I think this actually simplifies the processing:
The ServiceForm SVCB record(s) might not be present (based on whether the
authoritative is SVCB-aware and whether it is doing the addition of those
records), but IF they are present, they are in the Answer section.
This ALSO means that the only reason for anything being in the Additional
section is if there are A or AAAA records returned, which (hopefully)
implies the presence of a ServiceForm SVCB record.
The only other reason A/AAAA records should be in the Additional section,
is if there is a delegation, in which case there should be stuff in the
Authority section too.

So basically, it becomes:
AliasForm only in Answer -> not in-bailiwick, or not SVCB-aware. Either
way, another query is needed.
AliasForm plus Service Form in Answer -> Check Additional for A/AAAA
records, or query for them if not found
(Both of the above possibly also include CNAMEs in the chain)
CNAME chain only in the Answer -> not in bailiwick, need another query.
No Data in the Answer, Authority has a delegation -> follow the delegation,
possibly use Additional section for glue.

I think this is pretty simple logic, and I don't see the problem... could
you point out the problem if there is one?

Brian

>