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

Brian Dickson <> Fri, 07 August 2020 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A3ED3A0F0F for <>; Fri, 7 Aug 2020 10:41:02 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yhyv_TBXN7rZ for <>; Fri, 7 Aug 2020 10:41:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA1E23A0ECA for <>; Fri, 7 Aug 2020 10:41:00 -0700 (PDT)
Received: by with SMTP id r63so653834uar.9 for <>; Fri, 07 Aug 2020 10:41:00 -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=v8uMOjuOl2UsBR7l1UYS4LYQp+LyC0cLDUuS7SIiL9E=; b=e1DmErcpWWzZAM6hgJH46xjjPiDmuX/nc9MS3WtQkc8N7dzlqpbnKwHg4tXUElYdLb VEipKCQkjdjkLFiM1rYIVi04gtW6Yo6ttB1rVt0vIBx9uRnptpm2VOiA2aT6dum/gGFr HWdmF/FVDAQLKFGHzDgciYJcYXVTnwoZq0CfZ4+ACoo1b52MH90ewHTxB/SLf0pxPPd7 9temV1VQYCJRPF/CCNDRomc2JyfVF47d1+0Q/XpRGGH5sTKIo7v/z0oN8w4owRud4UnX fdJrCmN4BGmBG+GIZuR1i29P7LORx5osUOmcQ5s7jIJfUfXjDMfe8LCxDqFq8tkowJA0 4fRA==
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=v8uMOjuOl2UsBR7l1UYS4LYQp+LyC0cLDUuS7SIiL9E=; b=l/jJSVlzcMn2vEM59Mzw9SP5z0wSCtcNOn/NGpvdf/WQ3mmkqZSjjBArZaQ2iCxXJl KRf/7v91KzGWtFuW+w6ixrBEO8AMv9hwvmXyuczf5HkPkMjImJkczjxoV+YCrKXmecxA Aiu+mjlyWEhd1HuyEf5EL5QIeh+gNz4fDOLjIHrN3DQb18sF3xRbW2jEHohjGo3kodef rbRn0BP8gD88slp32OMURTgAVtMOMXWxcNiulgNVwKbU5tfmySH/KS27EgejfUp3o53+ XbtdeEIZGizTwka9BPjV01SVMKjCwBSnS1wK0Bt0lI9jv+OYH2abednWE8ac/WTOCaCQ svTg==
X-Gm-Message-State: AOAM532l8BDj6HxfvQhfbgkNIIjyJgUTIYOuufIBwqdt9umFOKspiAJz wmnM4Z6A08OUXWMYcQA63R2bkK6URWQsaFBtNEo=
X-Google-Smtp-Source: ABdhPJyqlHK3n9WZVUOmudKH1qdBjmJ7XaS1c7xS4WbIv++sZVofa6N8eyephFyNiLAL9P/bYziaXYDfJ/H7g6I+EUw=
X-Received: by 2002:ab0:6253:: with SMTP id p19mr6006221uao.48.1596822059867; Fri, 07 Aug 2020 10:40:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 7 Aug 2020 10:40:48 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Mark Andrews <>, Pieter Lexis <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000a5e67a05ac4d1bf4"
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 17:41:02 -0000

On Fri, Aug 7, 2020 at 7:42 AM Ben Schwartz <> wrote:

> On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson <
>> wrote:
>> "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?
> The current text says "SVCB RRSets SHOULD only have a single resource
> record in AliasMode."  Early drafts say "RRSets MUST only have a single
> resource record in this form." (
>  I
> believe this was changed because declaring that RRSets MUST only have one
> record, and also declaring what recipients should do if there are more than
> one, seemed like a contradiction.  Also, round-robin AliasForm seemed
> harmless, and potentially useful for multi-CDN.
No, it isn't a contradiction. If it is forbidden, you have to handle
non-compliance. That's just protocol 101.
Also, it may be messy to try to be prescriptive on what to do?
Maybe just provide loose guidance to implementers to the effect of, "You
have to handle this situation for multiple CNAMEs. Using the same logic for
that is the right thing to do." Even if how multiple CNAMEs isn't
necessarily well spelled out in the RFCs, it isn't a problem that I see
causing major problems on various DNS implementations (at least as far as I
The same guidance would be applicable regardless of where in the ecosystem
the issues are handled, from APIs to UIs to auth to recursive to client.
Not sure how anyone feels about that as guidance, but I think it would make
the document pretty easy to understand and minimize any confusion.

> 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.
> Correct, ServiceForm is the intended solution for multi-CDN.  Using
> round-robin AliasForm for multi-CDN would give less fallback capability to
> clients (they could only use one CDN or the other), but would reduce
> coupling between the CDN and customer (no need to copy SvcParams into the
> customer zones, where they might be hard to update).
So, it's really only a minor convenience thing, not a blocker per se. I.e.
making multiple AliasForm entries a "MUST NOT", would not prevent someone
from being able to use multiple CDNs, it would just be slightly less
My issue with the round-robin impact is doing so would very likely make
diagnosing or solving problems when multiple CDNs are involved, extremely
difficult and confusing, at the one place where you really don't want
things to be confusing or difficult to diagnose.
It's a non-deterministic behavior in a place without any real way to figure
out what is happening.
One of the main benefits of the parameters in the ServiceForm is that you
can re-prioritize if equal-weight stuff is having problems, and that allows
both diagnosis and fixes to problems that are discovered (lower the weight
of the broken thing.)

I think bringing back the prohibition on multiple AliasForm records at an
owner name is the wisest choice.