Skip to main content

Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)
draft-nygren-dnsop-svcb-httpssvc-00

Document Type Replaced Internet-Draft (dnsop WG)
Expired & archived
Authors Benjamin M. Schwartz , Mike Bishop , Erik Nygren
Last updated 2019-10-20 (Latest revision 2019-09-23)
Replaces draft-nygren-httpbis-httpssvc, draft-schwartz-httpbis-dns-alt-svc
Replaced by draft-ietf-dnsop-svcb-httpssvc
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources GitHub Repository
GitHub Repository
Mailing list discussion
Stream WG state Adopted by a WG
Document shepherd Tim Wicinski
IESG IESG state Replaced by draft-ietf-dnsop-svcb-httpssvc
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to Tim Wicinski <tjw.ietf@gmail.com>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

This document specifies the "SVCB" and "HTTPSSVC" DNS resource record types to facilitate the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. SVCB records allow an origin to be served from multiple network locations, each with associated parameters (such as transport protocol configuration and keying material for encrypting TLS SNI). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPSSVC DNS 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: The specific name for this RR type is an open topic for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as they are easy to replace. Other names might include "B", "SRV2", "SVCHTTPS", "HTTPS", and "ALTSVC".

Authors

Benjamin M. Schwartz
Mike Bishop
Erik Nygren

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)