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

Eric Orth <> Wed, 12 May 2021 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4F933A4BAF for <>; Wed, 12 May 2021 14:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KJi9iJ00RRmo for <>; Wed, 12 May 2021 14:44:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C0413A399A for <>; Wed, 12 May 2021 14:30:59 -0700 (PDT)
Received: by with SMTP id r8so32491487ybb.9 for <>; Wed, 12 May 2021 14:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QKhm/+zaOqkpHAN9TV/zrjXVg0D49j6dYoB7pJ4UO5E=; b=rvUCo9VKA84zKz4iJoUfCoGNZXbTXmOEWSEBbpEgsaxvDa/aS4v11wN/F/eYx+Qbmk l+yMmbHbQBretoa9+G8540FqcHaFg2qufQAJ0GhJiOs/SHE4zICt90sifxlaZV46ZmBG qzbaCxYCza3023wigCs6gK+wNKJJV3p2Gd0d7OcCZjdHhrpg0AJYkV76jziEV/ovLP/x 01eAoL8J+mHmkoB5BrrFAVSMbo/lrpqFesjhuXaMkIvn5Oc/E/d2Dq4F31xyh/Ffpy6k eYBoEvQeWhT6vmOTZOZmFI639t8Wut97SOzaKfVfl57vktQ3Q/+QvS/yE8HwTAWM1v1a HVnQ==
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=QKhm/+zaOqkpHAN9TV/zrjXVg0D49j6dYoB7pJ4UO5E=; b=WCEw1abTVfd4qCFbIxgCPWZn46NVmA8Dtkd6pEgVhapyxEVVRalTstSEyA2Dwu8a/S vk84wHQqRsSXV2WstoWH5w46I2pd1nDAhruSG4/xvDJOPhoNuDkopZzW0V2XOJsAK/sQ oz1VwesKRih9RUu3agIJxoQ3ARviBXB0hujZxQ2C2K54edTw9T4j/vII6awueaan5bH9 sLLguY5QFNAQExAjYt7C0BRrgc4wsBFfErTR0IG4556S7cnLsQpM98H+q9bHlyUsQTGK mQ3qTXwsjjt3CmH0qtBD3R2TjeifKl6g+06lX/X3cupKs1rjiLwHYVqBbXECWesSH43Y QOaQ==
X-Gm-Message-State: AOAM530k3kXK3s6aXWWOWgh6977dse06mRC1deqtWFhfg2TmRXzlP6TU xZz0S/jdceK7YKmqsKjhbsm1IYVnOFzqYYj+uN8zhgvXFiTmpA==
X-Google-Smtp-Source: ABdhPJynLtcSOeKYQz4+EHi/IJ3qhxle6pteCVpODW9Wv2ybgOvcUeN9EEs2Kvz5L2+Vdx68tWZdmaQQ/SpYCh2Nd98=
X-Received: by 2002:a5b:f41:: with SMTP id y1mr54234653ybr.163.1620855056720; Wed, 12 May 2021 14:30:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Wed, 12 May 2021 17:30:44 -0400
Message-ID: <>
To: Brian Dickson <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000e3e38005c228b922"
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: Wed, 12 May 2021 21:44:42 -0000

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

> On Wed, May 12, 2021 at 12:28 PM Eric Orth <ericorth=
>> 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.

Is the primary concern here resolution failures or connection failures? I
suppose this could help recover from resolution failures, but I would be
surprised if that is the concern in mind when people are configuring
multiple redundant CDNs.

For connection failures, such decisions can only be made on the client
making the connection attempts, so it's not clear to me what behavior we
should suggest for recursives.  I'm already concerned enough with
persuading recursives to do the support here that we want, so unless a
recursive operator/implementor speaks up here to explain why it wouldn't be
an issue, I'm guessing we wouldn't see a lot of full support if we say they
must/should fully follow all branches.

A client could use RFC 8305 (or similar logic) to attempt connections via
one alias branch and move to others (separately queried) only on connection
failures.  But my client doesn't currently support RFC 8305, so we're
unable to reasonably and performantly use separate branches conditionally
on connection failures.  Assuming many other clients would be in a similar
position, I worry that even if we make multiple aliases possible, this
would create a defacto standard that only a single alias is allowed if you
want your domain to be compatible with all the clients.

> 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