[DNSOP] SVCB proposals

Ben Schwartz <bemasc@google.com> Thu, 18 February 2021 15:37 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873463A1383 for <dnsop@ietfa.amsl.com>; Thu, 18 Feb 2021 07:37:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn_XtDXpMDDD for <dnsop@ietfa.amsl.com>; Thu, 18 Feb 2021 07:37:07 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86CC3A136B for <dnsop@ietf.org>; Thu, 18 Feb 2021 07:37:07 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id u20so2388822iot.9 for <dnsop@ietf.org>; Thu, 18 Feb 2021 07:37:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wvLizVQ9xu4neAgIySd37Fjoxs3Z+4t3eTDDMcki1AA=; b=LQJltjlHWStycG6eujlktlSYeIGzc0fT2Ux7dKMWgyQGYxg86772bYwDSU8Tv3IFMa iFDaOI4OOfkr8oBuL+F1Xt6MwgxsRCe7cFkvMy8j/DaLVBQOysBTUc71x8OauocWvp1+ xgwAi/RwZAFMXfdAuMUPgimhrYR4eo4GdM4JMzLAmkpg4t265um9e7rrIvlLl/hu9F2g USUKBGIc2xlLHmDnChS8B1Kmx/TVq1YTaQir7OEUCh7nMbH/WDof9rvmVQJkBi3oyzwr H0WNE0vfmiQT+oxBaVMTmWCHlRWmgUbgThLNQ7ViF4N6EV3b6YbLEkemw0ig6iw2eGXl Pw6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wvLizVQ9xu4neAgIySd37Fjoxs3Z+4t3eTDDMcki1AA=; b=HZ/2HW8d/dFURY+ardnje5dQCSgYFJSamdvtPaFznSROXET8TJUpV0uASRSJe/tilA zWxlYMs/i3rQ1RE71IwlH9xqQPF5gWun7nj//MXbwdTRVa4WY1bv5NFXknekeFm9bIfz qELJXRXP2nTm3vY7R4fnNTNjBMoeKpX7t18XrbthS8idYVz/ADIxoW7Kf0FJtNMouPGE LYA1Z0m5dWVGTPz67jwiZznyIhTmcqvR4MK0BzIAq7SFD9OmF6LeYHhJ/sj1/Fgpr/kN 2EAgTyjbN/Zs1Cefg1esmcOkS1NB4SpTXv628XOcXPwNHMSOHCWJawwVLFTuCfrJcBym zslw==
X-Gm-Message-State: AOAM532roSwY5QpdakxaKQEnFSa/BsOo1P9VELT8X/P/6LRKOYJRRcHs Gn6DKb+8aCXvLTqrTf7lVRLR9VuSKD9z/aWDlw+q6THC/EEd+w==
X-Google-Smtp-Source: ABdhPJxTsIIwjqnZ4Z/TLMN2+Rc/Hj9WEe0c/CRqhBI8rwl0+juqMUUAHKTqSOXLHRKYeC0KkyC5pkDpCUwpMWO62+4=
X-Received: by 2002:a05:6602:2486:: with SMTP id g6mr4018138ioe.134.1613662626452; Thu, 18 Feb 2021 07:37:06 -0800 (PST)
MIME-Version: 1.0
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 18 Feb 2021 10:36:55 -0500
Message-ID: <CAHbrMsCJ1AE2D8TL=q2STq0MpFYFLpuF8CFQKiSzhwi+TqdOyA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000aa22cc05bb9e1b9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/i_U0MtYuQXT2xeiRMGkzK_pmWrU>
Subject: [DNSOP] SVCB proposals
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 15:37:10 -0000

The SVCB/HTTPS RR draft is nearing completion, but there are a few
remaining topics on which the authors would appreciate feedback from the
working group.  Personally, I've written up three proposed changes that
would benefit from broader input.  Please share your thoughts.

1. Change IANA policy to Specification Required
(https://github.com/MikeBishop/dns-alt-svc/pull/262/files)

The current proposed IANA policy for SvcParamKeys has allocatable ranges
under three different policies ("Standards Action", "Expert Review",
and "First Come First Served").  This is very flexible and enables
experimentation, but creates compatibility risk: a FCFS SvcParamKey could
be allocated without a clear specification of its zone file syntax, leading
to zone file portability issues.

This proposal would replace all these ranges with a uniform Specification
Required policy.  The required documentation is minimal: it is only
required to describe the zone file format.

2. Skip the default port prefix
(https://github.com/MikeBishop/dns-alt-svc/pull/230/files)

Using SVCB with a new protocol requires the initial QNAME to end with
_(scheme).$HOSTNAME.  The current text suggests (non-normatively) to add
_$PORT for endpoints that are identified by a port number.  This turns out
to be inelegant for protocols that almost always use the default port.  For
example, in the DNS mapping (draft-schwartz-svcb-dns), this would
correspond to names like "_53._dns.resolver.example".

This proposal would change the guidance to skip the port prefix when
starting with the default port (like "_dns.resolver.example").

3. Add a SHOULD-level chain length limit for zone owners
https://github.com/MikeBishop/dns-alt-svc/pull/294/files

Constructing huge chains of CNAME and AliasMode records is clearly a bad
idea, but how huge is too huge?  This change suggests not to use more than
8.  This doesn't change the requirements for resolvers (which are free to
impose any limit greater than zero) but it might help us to converge on
common behavior.

--Ben Schwartz