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

Ben Schwartz <bemasc@google.com> Fri, 07 August 2020 02:13 UTC

Return-Path: <bemasc@google.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 E82193A0CF1 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 19:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 L2Xs5kKMVEfy for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 19:13:24 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 EBA1F3A0CEB for <dnsop@ietf.org>; Thu, 6 Aug 2020 19:13:23 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id x5so386877wmi.2 for <dnsop@ietf.org>; Thu, 06 Aug 2020 19:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nWaVQJs/e7tYOKcD7ikhbX/3quKYe59DbUYEw4+bLo4=; b=SyYHTbVqvUr9F2jvpV++vci8aNKAXimeaGXDxagE3ANbrifV2qaUXRt9Er0EZCQghZ tWg7Imp2JnQlywDjluR1fhP0dZtc3XJqLvUEppYbwo8iYlk7J31IjjfS9iBu8sYNs9bH o+stZ7B5k6mAOtFFRzIKW4fG9KSZqqz5WuulRQ+Eu36ku8doFgUULv7zIngG4S7kQM40 Ey6W9jk970Bo4IVNe8OHqZGCaeB3brjwmG6aoBaOLZjhGkNooV+maH897v6kucSXyjHW yoCQLZc7dUGMUZvU05v5ETtQWraI5WhtKWuqMNBqWTtvk93iVI59Y0hsVP9gV688YIyQ geaQ==
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=nWaVQJs/e7tYOKcD7ikhbX/3quKYe59DbUYEw4+bLo4=; b=XPHsnpM5ABRy7XHS7oQ98wAjLIqeOB0+nbuHAZaOJtrLYvHaFE11qH4Mt1+SHoeoRK wejWkEOrQL23BTRziFXkuZeEnSyoWW+jybZf7xrELD18H7o2Z8PWYcZEOQM8ANiAJe+J Ke8SNkzcgETlATvJKECEV50XUyI1cM2HmlIyH5VxcF/hqKlYLgCqOrYfyHNfcr9PVz0y 7Yh8bPhPgGlAaEUHaDYLVPTtY0G3BWh2+J9KRiRLrEAagAYwtBI5GxBO/zhvXWngLTtK SNXPbw2J+kRUlLPZDqVGW3DFLHxnjkt3L6dfgxgQ/dzum1051sMQ4DNl6neDJ1BdtR6e bCxQ==
X-Gm-Message-State: AOAM533zOJokmSNeHng2YX8HrYOop2KZkNVAFGw8MfWjMmPRn9bDojEQ 51aJIH5cak6jym/L5yr85SQn4XNcjC75yqDwA7q6Sg==
X-Google-Smtp-Source: ABdhPJzntYXVuMxiV9/gN1CMZpXSXzAxGZDqIfQ0/up/3YCuO9RuMZOEoroownXB4ZcjJQHHUKsiGQ4vJ0zRCMggDFU=
X-Received: by 2002:a1c:7918:: with SMTP id l24mr9916278wme.132.1596766401304; Thu, 06 Aug 2020 19:13:21 -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>
In-Reply-To: <CAH1iCipP7p8UayYAgzWSO3CTYZryJX_NVqPJka4je982wjsrKQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 6 Aug 2020 22:13:09 -0400
Message-ID: <CAHbrMsA0bbqJE=BGgyO+SCKB3BtVAu4E4TDzK-43quPWrSRPiw@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Mark Andrews <marka@isc.org>, Pieter Lexis <pieter.lexis@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000035a71e05ac40265c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6oYcgHg-cWs_sRSHpCOkFN0gnig>
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:13:26 -0000

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

My main concern with "chain in Answer" is that SVCB-aware recursive
resolvers are required to handle SVCB responses from non-SVCB-aware
Authoritatives, so they can't rely on any followup records being present.
That seems to match well with the semantics of Additional, whose contents
are not reliably present, and less well with the semantics of Answer, whose
contents are normally reliable.

--Ben

On Thu, Aug 6, 2020 at 9:55 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:
...

> So, specifically:
> 2.4.1, paragraph 2, sentence 2:
>
>> In AliasMode, TargetName MUST be
>> the name of a domain that has SVCB, AAAA, or A records
>
> However, same section, a few paragraphs later, we get the following
> sentence:
>
>> Note that the SVCB record's owner name MAY be the canonical name of a
>
> CNAME record, and the TargetName MAY be the owner of a CNAME record.
>
>
> I'm good with either of these, but obviously it has to be one or the other
> -- possibly a CNAME, or never a CNAME.
>

It's definitely "possibly a CNAME", with the second quoted sentence
intended as a clarification of what is meant by "domain that has".  I agree
that this text could be clearer.

>