Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 12 May 2021 20:44 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 CDBCE3A1506 for <dnsop@ietfa.amsl.com>; Wed, 12 May 2021 13:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 M5ZiGX6fLcvo for <dnsop@ietfa.amsl.com>; Wed, 12 May 2021 13:44:20 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 355443A1509 for <dnsop@ietf.org>; Wed, 12 May 2021 13:44:20 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id p12so31311411ljg.1 for <dnsop@ietf.org>; Wed, 12 May 2021 13:44:19 -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=ItmTFl6Q0MKM3vt/aRBVFnID3DFY+WBCOEHQakCcriU=; b=pSjEMfpVfHMjfz5FStlSrMBsy1+KbyZzNCKMqD4DLd2XjPkKXSwzQMpYv6EI8AgkbQ x00fnQ/LYxXFHC8OU8tmGnNVHHLAYInL23QVbn1Bbxy8s6zKTgMr7EjMnP09oVVnWJIn kPha2GZq47C3LLyIF5DYPpPwjsp3HVEz44XELpYZc7mfMXT6ng4A9NFllex3oaILkcry pA/Aw/lTi5I8z11djH1Yw/GZxxFZ7GGe4hcnfoP64eij5BN7KnyLq8U2dIw7sP8h1ShF FcfB1yhBlE+0oXKlY+cq2VgxpV1NIxWzniSvSnX9y8eZZAxH2eWw4U34BNxQf6MyHpPJ moCQ==
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=ItmTFl6Q0MKM3vt/aRBVFnID3DFY+WBCOEHQakCcriU=; b=BHYuH2QMUi2R/g4lW9Zq/CZL3bGPx00N6h305Lkc+5ii5JdRx3LONOtx8SA2OQlzo9 BZi5VXHjDVT7wy75BG0WBp/uEqBqUFJqFxDvdee4pv+KyyRMiz0fPQTGBiwJDwKDKcYP dsJEMitn1UmsTNPVqwHsgJdt2krsntYOYFFP9QYqHd8M/EeWRBSKLxS7WZ8cQoOfmugK XA2XjLBCq52ufZUEuB9zPSDCH96vVxoK4v/QPmwCsrnY6fBCSvG60tgF68c5ZY8bz6ZX 7FteOphu6SzHtmk9ddU693KjYjfhRE9jBp3o3F5Fr6G/jh0asz2/rlucftNJarOyQUu2 od1w==
X-Gm-Message-State: AOAM5304UQ/9jIhPMTWLw1MxfpTJH9LmWpetYl4r2/t79CTs6jq87RB8 gPwBKAl+U51lRs45NKNmrf+AiyzVF1LwV8LdmKU=
X-Google-Smtp-Source: ABdhPJwMHBJSDxUqMxXX/s7bWX5A+9B2gmPkT+RUMe0ku6M3V881o1yJtV/dmeZeyG/HNgS0fp2Llj9ZsVTf1kIVvYI=
X-Received: by 2002:a2e:4c19:: with SMTP id z25mr9731351lja.47.1620852257777; Wed, 12 May 2021 13:44:17 -0700 (PDT)
MIME-Version: 1.0
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com> <123fd984-a3e1-0d09-b745-9a7ed6260759@nic.cz> <CAHbrMsCrf8GS3N=HF53X-M0oq09yw_vKGFLU_qA6wt94-+vNXg@mail.gmail.com> <346afc4d-f8c2-7a2b-e606-344e15230e61@nic.cz> <6782960c9c8f84e1df330d6ddf4d2cfaa7b5d7a7.camel@powerdns.com> <CAMOjQcEHf0=nes+PGZWi7=18u_N5WaS7=i4Sd-9d+9+_BEypFA@mail.gmail.com>
In-Reply-To: <CAMOjQcEHf0=nes+PGZWi7=18u_N5WaS7=i4Sd-9d+9+_BEypFA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 12 May 2021 13:44:06 -0700
Message-ID: <CAH1iCirr9MhZ7LYkmsvihCdSCQmMfuWwn0beZX_CVr62RGnQGg@mail.gmail.com>
To: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000eeaad05c228130c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LmtUj2TIBC1VXSAiRh8nKeKz_8Y>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
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: Wed, 12 May 2021 20:44:25 -0000

On Wed, May 12, 2021 at 12:28 PM Eric Orth <ericorth=
40google.com@dmarc.ietf.org> wrote:

>
> I also oppose allowing multiple aliases within an RRSet.  This would allow
> aliasing trees, unreasonably exploding the complexity/performance scope of
> query followup logic in stubs and recursives.  In practice, I don't think
> this would actually make multiple aliases useful because I would then
> expect many stub/recursive implementations (including mine) to only make
> followup queries down a single branch of the alias tree.
>

The current version of the document only addresses DNS issues which result
from actual attacks. There do not appear to be any logic branches on
timeouts (or other similar failures) other than to abandon the SVCB
handling.

Having multiple AliasMode records within an RRset (with either the same or
different Priority) would provide an avenue for dealing with resolution
failure - which is one of the main reasons for any CDN customer to use
multiple CDNs, i.e. to avoid single points of failure (which includes the
DNS component of the CDN).

I think it would be reasonable to restrict the handling of SVCB processing
to allow multiple AliasMode records in a single RRset in the resolution of
SVCB, i.e. once a branch has been reached, follow the preferred branch
using the existing logic, and either abandon the other branch after the
first successful step in the resolution of the preferred branch, or
alternatively holding the entry point to the second branch (as a backup)
until the first branch's resolution has succeeded to the point of returning
ServiceMode records (and if resolution failure occurs before that point,
switching to the next branch).
This would be the equivalent to keeping a simple list, rather than needed
to handle full recursion tree-walking logic.

This is a suggestion only, but I think it has merit.
The current examples of "juggling CNAMEs" isn't really practical,
especially given TTLs on CNAMEs.
Having multiple RRs in an RRSET with various Priority values achieves the
equivalent function without requiring the domain owner to engage in active
management of DNS records. The latter approach is at best naive, at worst
harmful to deployment and use of SVCB in the real world.

I am a big fan of SVCB, and want it to succeed, so my comments should be
viewed in that light, please. This is about improving the proposal only.

Brian