Subject: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-01.txt

From: [email-masked]
Date: Mon, 13 Jul 2020 13:35:50 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
	Filename        : draft-ietf-dnsop-svcb-https-01.txt
	Pages           : 42
	Date            : 2020-07-13

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS ClientHello).
   They also enable aliasing of apex domains, which is not possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This proposal is inspired by and based on recent DNS
   usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
   standing desires to have SRV or a functional equivalent implemented
   for HTTP).  These proposals each provide an important function but
   are potentially incompatible with each other, such as when an origin
   is load-balanced across multiple hosting providers (multi-CDN).
   Furthermore, these each add potential cases for adding additional
   record lookups in addition to AAAA/A lookups.  This design attempts
   to provide a unified framework that encompasses the key functionality
   of these proposals, as well as providing some extensibility for
   addressing similar future challenges.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
   working version of the document, open issues, etc. should all be
   available there.  The authors (gratefully) accept pull requests.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Jul 2020 10:03:36 +1000

Section 2.4.1.  AliasMode paragraph 2.  Why have "MUST NOT" here?                          

   The primary purpose of AliasMode is to allow aliasing at the zone
   apex, where CNAME is not allowed.  In AliasMode, TargetName MUST be
   the name of a domain that has SVCB, AAAA, or A records.  It MUST NOT
   be equal to the owner name, as this would cause a loop.

Nameservers and clients need to detect loops regardless of the number of
records that form the loop.  All this does is force vendors to write additional
code to detect this one sub-case of a loop.  These are also the only RR types
that need to have their owner names available to parse them.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Erik Nygren <[email-masked]>
Date: Tue, 14 Jul 2020 10:13:26 -0400

Would this be better as a SHOULD NOT?  Or just better to remove this,
or replace with non-normative txt?
Opened: https://github.com/MikeBishop/dns-alt-svc/issues/221

On Mon, Jul 13, 2020 at 8:03 PM Mark Andrews <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Jul 2020 14:10:59 -0400

I wanted to highlight some changes since the previous version, for folks
who don't want to try to parse the diff:

Substantive:
*  Added a "mandatory" SvcParamKey. The "mandatory" key allows the
publisher to indicate that some extensions can't be ignored.  If the client
gets a record with an unrecognized extension that is marked as mandatory,
it ignores the whole record.  This will allow publishers to selectively
break backwards compatibility, on a per-endpoint basis.

*  Adjusted resolution and ALPN algorithms.  The descriptions of the SVCB
client, recursive resolver, and TLS client behavior have all been improved
based on expert input.

*  Added the ability to indicate that a service does not exist.  Based on a
suggestion from Mark Andrews, we incorporated the ability to publish a
record indicating that the requested service is not available or does not
exist, paralleling several existing RR types.

Editorial:
*  Major terminology revisions:
"origin" -> "service" and other changes to align with URI terminology
instead of appropriating HTTP terminology
SvcDomainName -> TargetName, SvcFieldValue -> SvcParams, AliasForm ->
AliasMode, and other changes to the CamelCase names.

*  Revised ABNF description for precision and alignment with implementations