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

Brian Dickson <> Tue, 05 January 2021 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 730253A0AEE for <>; Tue, 5 Jan 2021 14:56:55 -0800 (PST)
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 oNfVDM79OUFO for <>; Tue, 5 Jan 2021 14:56:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC6F63A0AC4 for <>; Tue, 5 Jan 2021 14:56:53 -0800 (PST)
Received: by with SMTP id p128so367285vkf.12 for <>; Tue, 05 Jan 2021 14:56:53 -0800 (PST)
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=nsFSqASfERwn6Oi1IuluBxDxwo/zVbOVYUdqnecqjnQ=; b=YXRNnvtHZk5CLER2Wf8joVS/27BKF0ipaB9tK+srclw5Guf7URfJPd4gLVaw2PPZ8W nEj/uf7QHj273EHUjbkfJdaQB+o8k+fVw564zfNVDMofTB9IK2x+As8CKXDouMsL7XBr Mr/oUKoK3HcRHmfrIWy32N35hsGWQl19GolLBhuQbcJd00niFJ9sfe3YGDIGxKJjRUMz EKgdJHK5cUEclXqY7BOtf0ofVRU9ZN0WpajW0HyTXDbHkXHGYZXTPCn/5ij+KucsBaM3 BHFmuf++ozq+DyEfgA5Y87D9YETUOuZlHQssJrg9cq2d/6iJegsUEdw+1Y3VfP+PYw4O uPYw==
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=nsFSqASfERwn6Oi1IuluBxDxwo/zVbOVYUdqnecqjnQ=; b=O8+lhvAJKbZaLJhHvMz4W7UV190LY0oX1ffGhkek8OIUyV0s4JOzKx1ndp0Kg2/yRt PUORszmcHDLuKr6yLTG0lEC8qmz+kL33KKvtdv8+ERl7kw7N7GXt8MuLP2/e9Qz0zq5i x7zc1RO/BgBCrmyjcUK3jhsivkc0+uddaQ9A0mRIF3FlWiy3aR+HRCTGk8CUSW6x8cHF bO9R825SVtKwLNvgmTCcGZIUXEXRqGhEPTf+1z5Mkuk9C3IkrfZQeMKs3Hh9M5GycgCT /0OpV8mlZXbAp4ZgR2Yf5kDyPL0b0gpMtIT/XN6LjEtym6GNIR2XfT2/PnStmWfdJr6t +DRg==
X-Gm-Message-State: AOAM5321iSrBUxQ7dVGJhSyXoiaTA+dreH8D0RWAm9FpRUIPzi2ggPbf Mfg0WApyuIuI32W3lgDukR6GgL7xmeFR0UcGbO4=
X-Google-Smtp-Source: ABdhPJwqLAtpapKWaYkjso+DT6SjXjZ8SoJ6BVxdLwv1EUOQL+vNQgQ9KrIDhXlZDvMehX3lIKAnpVVpK8AsLEZ7iVM=
X-Received: by 2002:a1f:ab43:: with SMTP id u64mr1241658vke.3.1609887412755; Tue, 05 Jan 2021 14:56:52 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 05 Jan 2021 14:56:41 -0800
Message-ID: <>
To: Eric Orth <>
Cc: Ben Schwartz <>, "libor.peltan" <>, dnsop <>, Paul Vixie <>
Content-Type: multipart/alternative; boundary="0000000000005da2ef05b82f1fac"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.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: Tue, 05 Jan 2021 22:56:55 -0000

On Tue, Jan 5, 2021 at 2:29 PM Eric Orth <ericorth=> wrote:

> Besides future-proofing for potential changes, I think the current rule
> keeps us more flexible for handling obscure cornercases.  If there's any
> reasonable chance that some obscure usecase in the future might make it
> difficult for an authoritative to ensure only one alias is in place, it
> seems to me better for the only-one-alias rule to stay a SHOULD-level rule
> and keep the prescribed behavior for clients to reasonably handle it if
> broken.
> I wouldn't want to change to completely enforcing only-one-alias unless
> the authoritative implementers are confident that they will always be able
> to absolutely ensure that they are compliant.

Speaking only for one authoritative implementer (GoDaddy), I am confident
that we will always be able to absolutely ensure we are compliant.
We have the exact same authority enforcement for CNAME, one per owner name.

Given that this is new, greenfield stuff, I'd actually prefer a MUST rather
than a SHOULD. Any updates to accommodate new use cases SHOULD be new RFCs
that Update this RFC, that's the general way of progressing DNS standards,

As far as corner cases go, the only situation where two different RDATA
values could arise that I can think of, would be where the loosely coherent
nature of DNS comes into play (different authority servers with different
versions of the zone while the zone is in flux, or possibly a zone served
by authority servers operated by different parties.)

However, a resolver would either have one of those values in its cache (and
thus not query for a potentially different record), or not, in which case
only one authority should be queried at a time.  Thus the ability to obtain
multiple (different) RDATA values, if enforced on the authority server, is

If it isn't possible for more than one RDATA to be returned (atomically, in
a single query/response), I'd almost prefer removing the handling of "pick
one", and replace it with treating a response with multiple RDATA values as
a FORMERR (and try another authority, etc.)