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

Erik Nygren <> Sat, 15 May 2021 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29F083A0E46 for <>; Sat, 15 May 2021 08:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rok0ESXIGT3a for <>; Sat, 15 May 2021 08:00:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45D333A0E44 for <>; Sat, 15 May 2021 08:00:52 -0700 (PDT)
Received: by with SMTP id b19-20020a05600c06d3b029014258a636e8so1124899wmn.2 for <>; Sat, 15 May 2021 08:00:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VxXG8mJezIGXgb1R2u4e6sVZ6vRiYni/tEoTNZ3khNg=; b=Vi7IkKoueyWFQXxazkGUOk7c0QzBF7GabPVNrPj5v1Qr8eSYAaj5EkBOUXlOSvFLHw IUm3rlnHWYYgL5kg8htrpTk5sJMigWigpDGndepQsz7lFG9V32uhJVRfU09nQzDxx8V1 E732nqVb1/Ebrc07JumtCfVbB/lBmHgppXEoqTFOKBxEHxsqVLj5Ekmttbcaa5xPb/HL LS+i20l1u5/071MdPcqbhGcenOMGE+nNeh0sarY9CulB40KWu5iDg4iZQTwdPm5/6xY6 IATcjwoPkdW8aVbcP6jSj4x7NMEhFLqFxyZCtWP178IY/rukTWa4jXKc0Ui62xdBxruw N8tg==
X-Gm-Message-State: AOAM533NJsy716ILdTdJ/E3D2AuF/4eDfs/UAurvGhe6dnBHIPUe4ICp URvxRab4rL59oH/ElcGetBpd0xtAe3ikFhhyc/o=
X-Google-Smtp-Source: ABdhPJzIh+W42HSWXf4nMlWV19AUE6PlWylfCM1NN8kzq534lGzqm7XZgQbazYjxCHlYsLQkacfYvgkM5OFB0wq30NM=
X-Received: by 2002:a1c:2786:: with SMTP id n128mr15125127wmn.82.1621090850361; Sat, 15 May 2021 08:00:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Erik Nygren <>
Date: Sat, 15 May 2021 11:00:38 -0400
Message-ID: <>
To: Brian Dickson <>
Cc: Eric Orth <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000048d4e305c25fa034"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 May 2021 15:00:55 -0000

On Wed, May 12, 2021 at 4:44 PM Brian Dickson <>

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

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.