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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 15 May 2021 20:05 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 B4A6A3A1A28 for <dnsop@ietfa.amsl.com>; Sat, 15 May 2021 13:05:37 -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 GVK-jjwH5dul for <dnsop@ietfa.amsl.com>; Sat, 15 May 2021 13:05:33 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 DE6C73A1A23 for <dnsop@ietf.org>; Sat, 15 May 2021 13:05:32 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id z13so3173409lft.1 for <dnsop@ietf.org>; Sat, 15 May 2021 13:05:32 -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=k6FWK590alGZQGAN+K3xlA4HLXmfxwlnmoiGX/bt2Gg=; b=tveOa7cQHIAeBxQRnmDi9qp+6l8Sxo/bwRvTkhEIh0cuHb9NLWOtLOVIWesHU/3IBE Dgh020xzgBwwKcxohhPiYObeKPtCj1PNPw/g08bHVkcd24PyTI4NZ+TIUaGND9955g6T WULS/ubiaBymi+kbon4iQtz/RV8tF4SUM5//hnFkvJmIiHqRKs3GtNVAi5XYptU794Nu qb1RrWGW2F0qXs0kewt5vgaDu6JLVLFro3Nx0MZks1RC8JzlgMfBFCCoCEr1BbXJ39D4 dwYwkV/glP2bRHelu+dJuBVeMEhLtUgLiCEup+v/KjhIoyCRap+fO31JcWHrK9MlNDTX Z6Rg==
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=k6FWK590alGZQGAN+K3xlA4HLXmfxwlnmoiGX/bt2Gg=; b=bQpH8iRXEEsAVl93NnRp98n21sfdb+/cyBCDKt/AmrCYenH6B2aj1JzbCmdrM2pfB5 Y47CTYcLjLNMmkvr694BJIcxzY9RWLFBgG4C+JRJXdhF40ezikNTfwJ+K7OmE7C4tlQV f63D5EJJQWy81RrI2T4ynhBgrASPuNJCl928q/00jVkq/2sQK4PGj80tgur2amO+k5WJ eU7f0NK3grMqSguVOwTmvquztO3zWmn2LQLG9O8w79xUGy57FL4XO74HKkXahiNN6cAN z6xP/FoL3HR+Tsdj3fwtNMEjtGhtnPMacnEPK88RfIsj/+sDlG9olT8SS9uo54YpbWAV 3X7w==
X-Gm-Message-State: AOAM531NmcTlAMvTprTj5Oxbqpiuc1gguYmv54mtpHlRwiAlgivepkcY /vXRRD42p/I6QIi1suLbWVUvsK4xLFO6PwDt9dUJxbTv
X-Google-Smtp-Source: ABdhPJwhbHM3HXEw6yNqRXxzSwHYtwUHCG18wPnc+AWUMEcp9NzRRGrURhubwdacGQSW2xFch3NWd1Y0CI0eMwFBO7o=
X-Received: by 2002:a05:6512:3f04:: with SMTP id y4mr37443117lfa.458.1621109130493; Sat, 15 May 2021 13:05:30 -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> <CAH1iCirr9MhZ7LYkmsvihCdSCQmMfuWwn0beZX_CVr62RGnQGg@mail.gmail.com> <CAKC-DJix_K+Hd+Vfck1kEr_zheihXTYptaiy7cSDavKRSLa+fw@mail.gmail.com>
In-Reply-To: <CAKC-DJix_K+Hd+Vfck1kEr_zheihXTYptaiy7cSDavKRSLa+fw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Sat, 15 May 2021 13:05:18 -0700
Message-ID: <CAH1iCiqOwwQ8OprT8FuNsKw4=AOr-njn20XtO6urfdf6grc4oA@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: Eric Orth <ericorth=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd844905c263e126"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6mE9GOgCzDSVksDlNX1raA4I1ho>
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: Sat, 15 May 2021 20:05:38 -0000

On Sat, May 15, 2021 at 8:00 AM Erik Nygren <erik+ietf@nygren.org> wrote:

> On Wed, May 12, 2021 at 4:44 PM Brian Dickson <
> brian.peter.dickson@gmail.com> wrote:
>
>>
>> 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.
>>
>
> A question would be whether this adds more to client complexity than even
> advanced clients would
> be willing to implement.  Multiple Alias records pointing to independent
> CDNs is only useful if clients
> pop all the way back to that point to try another tree in the case where
> connecting to the services
> at the end of the first Alias record path fails.
>

Currently, the singular AliasMode (chain, but non-forking chain) still
requires potentially multiple ServiceMode records to be handled, including
queries for A and AAAA records for the TargetNames (or inclusion of those
by the Authority server etc.)
Resolving each AliasMode chain (if a single single sit "fork" occurs) to
the ServiceMode records of all the forks, would result in a set of
ServiceMode records. All of the handling of ServiceMode records from each
of the forks could be done effectively the way they are today, with the
results of each ServiceMode's evaluation being kept in the sorted order (as
is already the case).

It goes from the current method of:
AliasMode -> .... -> sorted list of ServiceMode records (possibly sorted in
random order if two or more of the same SvcPriority exist)
to:
Priority-sorted AliasMode set -> ... multiple sets of ServiceMode records
[each set corresponding to the AliasMode], respectively sorted within those
groupings according to the SvcPriority of the ServiceMode records within
each set.

The words are more complex than the implementation; the end result can be
treated as a single sorted list (and handled by whatever existing code for
handling connections and failures from the singular AliasMode case).


>
> This also only covers a small number of the "juggling CNAMEs" multi-CDN
> setups today.
> Many/most seem to take factors of cost, geographic location, and
> performance into account,
> so multiple Alias records wouldn't solve this but would just add another
> place for more complexity.
>

There are almost no multi-CDN setups today, BECAUSE of the lack of
SVCB/HTTPS records.
If a CDN customer is making use of any sort of non-standard apex "cname",
they CANNOT use multiple CDNs.

Reading more into the "why" of almost no multiple-CDN setups than that, is
{insert appropriate logical fallacy name here}.

There are additional reasons for needing multiple CDNs, on at least a
temporary basis, such as migrating between CDN providers.

And finally, the use of same-priority multiple CDNs allows the client to
pick the best choice of destination based on local network effects
(latency, loss). This may not be the case at initial connection time, but
might be relevant over the longer term.
What is optimal for behavior on a cold cache, may not continue to be
optimal on a warm cache, or during global or local network issues.

Brian