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

Brian Dickson <> Fri, 07 August 2020 08:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F83A3A0D0E for <>; Fri, 7 Aug 2020 01:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jRgAomDpXpGy for <>; Fri, 7 Aug 2020 01:14:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AB3D3A0D0F for <>; Fri, 7 Aug 2020 01:14:19 -0700 (PDT)
Received: by with SMTP id r7so496327vsq.5 for <>; Fri, 07 Aug 2020 01:14:18 -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=Gys+Tt+9YusJTgU7EFQ0pdLdT0v9HDeHufItOwgSuOM=; b=s6jNl3AU9qiuebwVAoqQbungcjaB3+2/mBKFAjCWiEu+G8P5fEjMBrusDb1vfvqRY+ AgnzE32e8Gqa1RtUDRJ3A5k7IIWnNMNrOnaxJebGLSSe4N4u/KKtFvOYoQfzW/4nBan2 QEzTWjHOojaO19gNwKg00/Wxa3qUcdkpzvZiJX3komb7uDc8JNaoww/KlhWCPDIjX2fG uue273J68AkMD3Ttm7CRBCqCmuIiYBSP11u+MSjqu3d/fjQhoge8TdKciMNvOoj8Ix6Q l1MIEYA9qHZKACfCT+r2zJGGXca1r2WLVMHYtOevus9ZNiI7hWrgXod0kbd0RTMPNVTG Zbaw==
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=Gys+Tt+9YusJTgU7EFQ0pdLdT0v9HDeHufItOwgSuOM=; b=SUvpqTtME2iwUMVNdaKZ8BpxO69qtl8wSQBsZFJcKzTlyDLlq3xVZSni9DxGTRk5jW 0tyzCjcujdsTANwUFuLIbsJtpdQyAMhaCsSjltVffy4sXyrMWxZH7rAkY2cgT9GOyHP1 pEl1oPEQ13l6hMiDYEOpzT4dUKIehHH0hCP4PadBxSz22UoFsnZTdx9ZYXIFR8oOSzU3 9hm5t89y2J/VQsAQ3RrFHBCn10OhY2nxM0Q1GsxznfiFGn3AIVa/YUOUgOGPlaf/qWjA fMBfdqSAOdvHx3yKDR9N43j9cLKZ4ZFUYnufDmACbvpM6Srjh6RmPhflwP6qsBPxYDC5 bAdg==
X-Gm-Message-State: AOAM530uHQd5xhdsfrrhtwfWVYwkgIatflhPP8va5DkBNpQzBes4OZBP h9nwCzJgMoMmLIl4s/1EuaUSFE9X2M7LPmlmR6OHl4DG6Uo=
X-Google-Smtp-Source: ABdhPJyCqr/kjvrhEZLRiNaZOosd3Cu3sdEPgHstpULp0gDzc3U8O38rPJAS7IMtPvj/JZ1PpP5JeJx6QNJ4j6sFBUA=
X-Received: by 2002:a67:30d5:: with SMTP id w204mr9607857vsw.219.1596788057890; Fri, 07 Aug 2020 01:14:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 07 Aug 2020 01:14:06 -0700
Message-ID: <>
To: Mark Andrews <>
Cc: Pieter Lexis <>, Ben Schwartz <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000f8e24c05ac4530f5"
Archived-At: <>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
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: Fri, 07 Aug 2020 08:14:20 -0000

On Thu, Aug 6, 2020 at 9:42 PM Mark Andrews <> wrote:

> Sorry you just broke DNSSEC if there are more than one AliasForm records.
> More than one is permitted with the same name.

Good point.

"More than one is permitted" is the case only because of the current spec.
I don't see any explanation for why this is (or needs to be) the case.
What would be wrong with changing the spec to prohibit more than one
AliasForm record at a given name?

Now, suppose only one AliasForm is permitted (just like CNAME), what
downside would there be?
The handling of multiple AliasForms at a given name should be handled in
the same way that having more than one CNAME is handled.
That seems like it wouldn't be hard.

And as far as I can tell, the ServiceForm is the thing for handling the
multi-CDN, availability, etc. issues. It's the right tool for the multiple
RR situation.

> And how do you do that with a graph?  This is the multiple QNAME problem.

So, other than at the terminus of the ultimate set of ServiceForm SVCBs,
why should this even be a graph, rather than a chain?
Does reducing this to a chain fix the multiple QNAME problem?

The ServiceForm records all clearly need to be processed so that the
correct set of answers is returned to the client. I'm not proposing any
changes to that part of the spec.

Having only a single AliasForm record allowed at any given owner name would
avoid any forking.

Additionally, much of the text and the examples suggests that where
possible zone administrators should use CNAME instead of AliasForm, i.e.
everywhere other than at a zone apex.
That would seem incompatible with the alternative of intentionally allowing
or encouraging multiple AliasForm records (which, unlike ServiceForm
records, do not have a priority field.)

I think it's not much of a stretch to change the SHOULD to a MUST (on only
one AliasForm), and I think that fixes a lot of the remaining issues.

I'm willing to drop the Answer vs Additional section for in-bailiwick
TargetName (plus A/AAAA) placement.
(However, I'm not the only person in the WG other than the authors; others
may have stronger feelings about this, since at least one person concurred
with my original post.)
It's up to the WG on this latter issue (placement), I'm good with whatever
the consensus is.