├── .github └── workflows │ ├── archive.yml │ ├── ghpages.yml │ ├── publish.yml │ └── update.yml ├── .gitignore ├── .travis.yml ├── CONTRIBUTING.md ├── LICENSE.md ├── Makefile ├── README.md ├── alt-svc-notes.md ├── draft-ietf-dnsop-svcb-https.md ├── draft-ietf-tls-svcb-ech.md ├── draft-schwartz-httpbis-dns-alt-svc.md └── svcb-implementations.md /.github/workflows/archive.yml: -------------------------------------------------------------------------------- 1 | name: "Archive Issues and Pull Requests" 2 | 3 | on: 4 | schedule: 5 | - cron: '0 0 * * 0,2,4' 6 | repository_dispatch: 7 | types: [archive] 8 | workflow_dispatch: 9 | 10 | jobs: 11 | build: 12 | name: "Archive Issues and Pull Requests" 13 | runs-on: ubuntu-latest 14 | steps: 15 | - name: "Checkout" 16 | uses: actions/checkout@v2 17 | 18 | - name: "Update Archive" 19 | uses: martinthomson/i-d-template@v1 20 | with: 21 | make: archive 22 | token: ${{ github.token }} 23 | 24 | - name: "Update GitHub Pages" 25 | uses: martinthomson/i-d-template@v1 26 | with: 27 | make: gh-archive 28 | token: ${{ github.token }} 29 | 30 | - name: "Save Archive" 31 | uses: actions/upload-artifact@v2 32 | with: 33 | path: archive.json 34 | -------------------------------------------------------------------------------- /.github/workflows/ghpages.yml: -------------------------------------------------------------------------------- 1 | name: "Update Editor's Copy" 2 | 3 | on: 4 | push: 5 | paths-ignore: 6 | - README.md 7 | - CONTRIBUTING.md 8 | - LICENSE.md 9 | - .gitignore 10 | pull_request: 11 | paths-ignore: 12 | - README.md 13 | - CONTRIBUTING.md 14 | - LICENSE.md 15 | - .gitignore 16 | 17 | jobs: 18 | build: 19 | name: "Update Editor's Copy" 20 | runs-on: ubuntu-latest 21 | steps: 22 | - name: "Checkout" 23 | uses: actions/checkout@v2 24 | 25 | - name: "Cache Setup" 26 | id: cache-setup 27 | run: | 28 | mkdir -p "$HOME"/.cache/xml2rfc 29 | echo "::set-output name=path::$HOME/.cache/xml2rfc" 30 | date -u "+::set-output name=date::%FT%T" 31 | 32 | - name: "Cache References" 33 | uses: actions/cache@v2 34 | with: 35 | path: | 36 | ${{ steps.cache-setup.outputs.path }} 37 | .targets.mk 38 | key: refcache-${{ steps.cache-setup.outputs.date }} 39 | restore-keys: | 40 | refcache-${{ steps.cache-setup.outputs.date }} 41 | refcache- 42 | 43 | - name: "Build Drafts" 44 | uses: martinthomson/i-d-template@v1 45 | with: 46 | token: ${{ github.token }} 47 | 48 | - name: "Update GitHub Pages" 49 | uses: martinthomson/i-d-template@v1 50 | if: ${{ github.event_name == 'push' }} 51 | with: 52 | make: gh-pages 53 | token: ${{ github.token }} 54 | 55 | - name: "Archive Built Drafts" 56 | uses: actions/upload-artifact@v2 57 | with: 58 | path: | 59 | draft-*.html 60 | draft-*.txt 61 | -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: "Publish New Draft Version" 2 | 3 | on: 4 | push: 5 | tags: 6 | - "draft-*" 7 | 8 | jobs: 9 | build: 10 | name: "Publish New Draft Version" 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: "Checkout" 14 | uses: actions/checkout@v2 15 | 16 | # See https://github.com/actions/checkout/issues/290 17 | - name: "Get Tag Annotations" 18 | run: git fetch -f origin ${{ github.ref }}:${{ github.ref }} 19 | 20 | - name: "Cache Setup" 21 | id: cache-setup 22 | run: | 23 | mkdir -p "$HOME"/.cache/xml2rfc 24 | echo "::set-output name=path::$HOME/.cache/xml2rfc" 25 | date -u "+::set-output name=date::%FT%T" 26 | 27 | - name: "Cache References" 28 | uses: actions/cache@v2 29 | with: 30 | path: | 31 | ${{ steps.cache-setup.outputs.path }} 32 | .targets.mk 33 | key: refcache-${{ steps.date.outputs.date }} 34 | restore-keys: | 35 | refcache-${{ steps.date.outputs.date }} 36 | refcache- 37 | 38 | - name: "Build Drafts" 39 | uses: martinthomson/i-d-template@v1 40 | with: 41 | token: ${{ github.token }} 42 | 43 | - name: "Upload to Datatracker" 44 | uses: martinthomson/i-d-template@v1 45 | with: 46 | make: upload 47 | 48 | - name: "Archive Submitted Drafts" 49 | uses: actions/upload-artifact@v2 50 | with: 51 | path: "draft-*-[0-9][0-9].xml" 52 | -------------------------------------------------------------------------------- /.github/workflows/update.yml: -------------------------------------------------------------------------------- 1 | name: "Update generated files" 2 | # This rule is not run automatically. 3 | # It can be run manually to update all of the files that are part 4 | # of the template, specifically: 5 | # - README.md 6 | # - CONTRIBUTING.md 7 | # - .note.xml 8 | # - .github/CODEOWNERS 9 | # - Makefile 10 | # 11 | # 12 | # This might be useful if you have: 13 | # - added, removed, or renamed drafts (including after adoption) 14 | # - added, removed, or changed draft editors 15 | # - changed the title of drafts 16 | # 17 | # Note that this removes any customizations you have made to 18 | # the affected files. 19 | on: workflow_dispatch 20 | 21 | jobs: 22 | build: 23 | name: "Update files" 24 | runs-on: ubuntu-latest 25 | steps: 26 | - name: "Checkout" 27 | uses: actions/checkout@v2 28 | 29 | - name: "Update generated files" 30 | uses: martinthomson/i-d-template@v1 31 | with: 32 | make: update-files 33 | token: ${{ github.token }} 34 | 35 | - name: "Push Update" 36 | run: git push 37 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.redxml 2 | *.txt 3 | *.html 4 | *.pdf 5 | *.upload 6 | .tags 7 | *~ 8 | *.swp 9 | /*-[0-9][0-9].xml 10 | .refcache 11 | .targets.mk 12 | venv/ 13 | issues.json 14 | pulls.json 15 | report.xml 16 | lib 17 | draft-schwartz-httpbis-dns-alt-svc-latest.xml 18 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: python 2 | sudo: false 3 | dist: trusty 4 | 5 | addons: 6 | apt: 7 | packages: 8 | - python-pip 9 | - xsltproc 10 | 11 | env: 12 | global: 13 | - GOPATH="${TRAVIS_BUILD_DIR}/.go_workspace" 14 | - mmark_src=github.com/miekg/mmark/mmark 15 | - mmark=./mmark 16 | 17 | install: 18 | - pip install xml2rfc 19 | - if head -1 -q *.md | grep '^\-\-\-' >/dev/null 2>&1; then gem install --no-doc kramdown-rfc2629; fi 20 | - if head -1 -q *.md | grep '^%%%' >/dev/null 2>&1; then go get "$mmark_src" && go build "$mmark_src"; fi 21 | 22 | script: 23 | - make 24 | - make issues || make issues DISABLE_ISSUE_FETCH=true && make gh-issues 25 | - make gh-pages 26 | 27 | deploy: 28 | provider: script 29 | script: make upload 30 | skip_cleanup: true 31 | on: 32 | tags: true 33 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This repository relates to activities in the Internet Engineering Task Force 4 | ([IETF](https://www.ietf.org/)). All material in this repository is considered 5 | Contributions to the IETF Standards Process, as defined in the intellectual 6 | property policies of IETF currently designated as 7 | [BCP 78](https://www.rfc-editor.org/info/bcp78), 8 | [BCP 79](https://www.rfc-editor.org/info/bcp79) and the 9 | [IETF Trust Legal Provisions (TLP) Relating to IETF Documents](http://trustee.ietf.org/trust-legal-provisions.html). 10 | 11 | Any edit, commit, pull request, issue, comment or other change made to this 12 | repository constitutes Contributions to the IETF Standards Process 13 | (https://www.ietf.org/). 14 | 15 | You agree to comply with all applicable IETF policies and procedures, including, 16 | BCP 78, 79, the TLP, and the TLP rules regarding code components (e.g. being 17 | subject to a Simplified BSD License) in Contributions. 18 | 19 | 20 | ## Other Resources 21 | 22 | Discussion of this work occurs on the 23 | [httpbis working group mailing list](https://mailarchive.ietf.org/arch/browse/httpbis/) 24 | ([subscribe](https://www.ietf.org/mailman/listinfo/httpbis)). In addition to 25 | contributions in github, you are encouraged to participate in discussions there. 26 | 27 | **Note**: Some working groups adopt a policy whereby substantive discussion of 28 | technical issues needs to occur on the mailing list. 29 | 30 | You might also like to familiarize yourself with other 31 | [working group documents](https://datatracker.ietf.org/wg/httpbis/documents/). 32 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | See the 4 | [guidelines for contributions](https://github.com/MikeBishop/dns-alt-svc/blob/master/CONTRIBUTING.md). 5 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | LIBDIR := lib 2 | include $(LIBDIR)/main.mk 3 | 4 | $(LIBDIR)/main.mk: 5 | ifneq (,$(shell grep "path *= *$(LIBDIR)" .gitmodules 2>/dev/null)) 6 | git submodule sync 7 | git submodule update $(CLONE_ARGS) --init 8 | else 9 | git clone -q --depth 10 $(CLONE_ARGS) \ 10 | -b main https://github.com/martinthomson/i-d-template $(LIBDIR) 11 | endif 12 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # SVCB, HTTPSSVC, and ALTSVC DNS records 2 | 3 | This is the working area for the individual Internet-Drafts "Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)" (formerly "HTTPSSVC service location and parameter specification via the DNS (DNS HTTPSVC)") and "Finding HTTP Alternative Services via the Domain Name Service". 4 | 5 | ## Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) 6 | 7 | draft-ietf-dnsop-svcb-httpssvc 8 | 9 | * [Editor's Copy](https://MikeBishop.github.io/dns-alt-svc/#go.draft-ietf-dnsop-svcb-httpssvc-latest.html) 10 | * [Individual Draft](https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-httpssvc/) 11 | * [Compare Editor's Copy to Individual Draft](https://MikeBishop.github.io/dns-alt-svc/#go.draft-ietf-dnsop-svcb-httpssvc-latest.diff) 12 | 13 | See also [here for a list of implementations](svcb-implementations.md). 14 | 15 | ## Finding HTTP Alternative Services via the Domain Name Service 16 | 17 | draft-schwartz-httpbis-dns-alt-svc 18 | 19 | * [Editor's Copy](https://MikeBishop.github.io/dns-alt-svc/#go.draft-schwartz-httpbis-dns-alt-svc-latest.html) 20 | * [Individual Draft](https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-latest) 21 | * [Compare Editor's Copy to Individual Draft](https://MikeBishop.github.io/dns-alt-svc/#go.draft-schwartz-httpbis-dns-alt-svc-latest.diff) 22 | 23 | ## Building the Draft 24 | 25 | Formatted text and HTML versions of the draft can be built using `make`. 26 | 27 | ```sh 28 | $ make 29 | ``` 30 | 31 | This requires that you have the necessary software installed. See 32 | [the instructions](https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md). 33 | 34 | 35 | ## Contributing 36 | 37 | See the 38 | [guidelines for contributions](https://github.com/MikeBishop/dns-alt-svc/blob/master/CONTRIBUTING.md). 39 | -------------------------------------------------------------------------------- /alt-svc-notes.md: -------------------------------------------------------------------------------- 1 | # Alt-Svc ideas related to HTTPSSVC and ESNI 2 | 3 | This file contains notes related to Alt-Svc that were removed 4 | from draft-ietf-dnsop-svcb-httpssvc. This includes some 5 | requirements or specifications that have been considered 6 | during development of that draft but are no longer part of it. 7 | 8 | ## Populating Alt-Used 9 | 10 | When using an HTTPSSVC RR in ServiceForm, all clients SHOULD 11 | include the "Alt-Used" HTTP header (Section 5 of {{!RFC7838}}). 12 | The header's value (in ABNF) SHOULD be 13 | 14 | uri-host ":" port 15 | 16 | where uri-host is the final value of HOST ({client-behavior}) minus 17 | the trailing ".", and port is the port number in use. 18 | 19 | ---- 20 | 21 | Per {{?AltSvc}}, please add the following entry to the HTTP Alt-Svc 22 | Parameter Registry: 23 | 24 | | Alt-Svc Parameter | Meaning | Reference | 25 | | ----------------- | --------------------------- | --------------- | 26 | | esniconfig | Encrypted SNI configuration | (This document) | 27 | 28 | 29 | ---- 30 | 31 | {{map2altsvc}} defines a limited mapping between Alt-Svc ({{!AltSvc}}) values 32 | and the SVCB ServiceForm. Protocols using SVCB may use this Alt-Svc 33 | mapping if they also use Alt-Svc. 34 | 35 | ---- 36 | 37 | If the client has a cached Alt-Svc entry that is expiring, the 38 | client MAY perform an HTTPSSVC query to refresh the entry. 39 | 40 | ---- 41 | 42 | # Mapping between HTTPSSVC and Alt-Svc {#map2altsvc} 43 | 44 | Conversion between HTTPSSVC's ServiceForm and Alt-Svc is possible. 45 | Note that conversion in either direction can be lossy, because 46 | some parameters are only defined for HTTPSSVC or Alt-Svc. 47 | 48 | To construct an Alt-Svc Field Value (as defined in Section 4 of 49 | {{!AltSvc}}) from an HTTPSSVC record: 50 | 51 | * The SvcDomainName is mapped into the uri-host portion of alt-authority 52 | with the trailing "." removed. 53 | (If SvcDomainName is ".", the special handling described in 54 | {{svcdomainnamedot}} MUST be applied first.) 55 | 56 | * The SvcParamValue of the "port" service parameter, or 443 if no such 57 | parameter is present, is written to the port portion of the alt-authority. 58 | 59 | * The SvcParamValue of the "alpn" service parameter is mapped to the 60 | protocol-id. This MUST follow the normalization and encoding 61 | requirements for protocol-id specified in {{!AltSvc}} Section 3. 62 | This parameter is MANDATORY. 63 | 64 | * The DNS TTL is mapped to the "ma" (max age) Alt-Svc parameter. 65 | 66 | * For SVCB parameters with defined mappings to HTTPS Alt-Svc, each should be 67 | included as an Alt-Svc parameter, typically as the SvcParamKey name 68 | "=" a defined encoding of the SvcParamValue. 69 | 70 | Converting an Alt-Svc Field Value into an HTTPSSVC record follows the reverse 71 | of this procedure. 72 | 73 | Conversion between HTTPSSVC and Alt-Svc Field Value MUST ignore any 74 | SvcParamKeys and Alt-Svc parameters that are unrecognized or do not have 75 | a defined mapping. 76 | 77 | For example, if the operator of https://www.example.com 78 | intends to include an HTTP response header like 79 | 80 | Alt-Svc: h3="svc.example.net:8003"; ma=3600; foo=123, \ 81 | h2="svc.example.net:8002"; ma=3600; foo=123 82 | 83 | they could also publish an HTTPSSVC DNS RRSet like 84 | 85 | www.example.com. 3600 IN HTTPSSVC 2 svc.example.net. ( 86 | alpn=h3 port=8003 foo=123 ) 87 | HTTPSSVC 3 svc.example.net. ( 88 | alpn=h2 port=8002 foo=123 ) 89 | 90 | Where "foo" is a hypothetical future HTTPSSVC and Alt-Svc parameter. 91 | 92 | This data type can also be represented as an Unknown RR as described in 93 | {{!RFC3597}}: 94 | 95 | www.example.com. 3600 IN TYPE??? \\# TBD:WRITEME 96 | 97 | ## Multiple records and preference ordering {#pri} 98 | 99 | Server operators MAY publish multiple ServiceForm HTTPSSVC 100 | records as an RRSet. When converting a collection of alt-values 101 | into an HTTPSSVC RRSet, the server operator MUST set the 102 | overall TTL to a value no larger than the minimum 103 | of the "max age" values (following Section 5.2 of {{!RFC2181}}). 104 | 105 | Each RR corresponds to exactly one alt-value, as described 106 | in Section 3 of {{!AltSvc}}. 107 | 108 | As discussed in {{svcfieldpri}}, HTTPSSVC RRs with 109 | a smaller SvcFieldPriority value SHOULD be sorted ahead of and given 110 | preference over RRs with a larger SvcFieldPriority value. 111 | 112 | When constructing equivalent Alt-Svc headers from an RRSet: 113 | 114 | 1. The RRs SHOULD be ordered by increasing SvcFieldPriority, with shuffling 115 | for equal SvcFieldPriority values. Clients MAY choose to further 116 | prioritize alt-values where address records are immediately 117 | available for the alt-value's SvcDomainName. 118 | 2. The client SHOULD concatenate the thus-transformed-and-ordered 119 | SvcFieldValues in the RRSet, separated by commas. (This is 120 | semantically equivalent to receiving multiple Alt-Svc HTTP response 121 | headers, according to Section 3.2.2 of {{?HTTP=RFC7230}}). 122 | 123 | 124 | ## Additional examples 125 | 126 | The following: 127 | 128 | www.example.com. 7200 IN CNAME svc.example.net. 129 | example.com. 7200 IN HTTPSSVC 0 svc.example.net. 130 | svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. ( 131 | alpn=h3 port=8003 esniconfig="ABC..." ) 132 | svc.example.net. 7200 IN HTTPSSVC 3 . ( 133 | alpn=h2 port=8002 esniconfig="123..." ) 134 | 135 | is equivalent to the Alt-Svc record: 136 | 137 | Alt-Svc: h3="svc3.example.net:8003"; esniconfig="ABC..."; ma=7200, \ 138 | h2="svc.example.net:8002"; esniconfig="123..."; ma=7200 139 | 140 | for the origins of both "https://www.example.com" and "https://example.com". 141 | 142 | ## SNI Alt-Svc parameter 143 | 144 | Defining an Alt-Svc sni= parameter 145 | (such as from {{!AltSvcSNI=I-D.bishop-httpbis-sni-altsvc}}) would 146 | have provided some benefits to clients and servers not implementing ESNI, 147 | such as for specifying that "_wildcard.example.com" could be sent as an SNI 148 | value rather than the full name. There is nothing precluding SVCB from 149 | being used with an sni= parameter if one were to be defined, but it 150 | is not included here to reduce scope, complexity, and additional potential 151 | security and tracking risks. 152 | 153 | -------------------------------------------------------------------------------- /draft-ietf-dnsop-svcb-https.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) 3 | abbrev: SVCB and HTTPS RRs for DNS 4 | docname: draft-ietf-dnsop-svcb-https-latest 5 | date: {DATE} 6 | category: std 7 | 8 | ipr: trust200902 9 | area: General 10 | workgroup: DNSOP Working Group 11 | keyword: Internet-Draft 12 | 13 | stand_alone: yes 14 | pi: [toc, sortrefs, symrefs] 15 | 16 | author: 17 | - 18 | ins: B. Schwartz 19 | name: Ben Schwartz 20 | organization: Google 21 | email: ietf@bemasc.net 22 | - 23 | ins: M. Bishop 24 | name: Mike Bishop 25 | org: Akamai Technologies 26 | email: mbishop@evequefou.be 27 | - 28 | ins: E. Nygren 29 | name: Erik Nygren 30 | org: Akamai Technologies 31 | email: erik+ietf@nygren.org 32 | 33 | normative: 34 | 35 | informative: 36 | FETCH: 37 | title: "Fetch Living Standard" 38 | date: May 2020 39 | target: "https://fetch.spec.whatwg.org/" 40 | --- abstract 41 | 42 | This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) 43 | types to facilitate the lookup of information needed to make connections 44 | to network services, such as for HTTP origins. SVCB records 45 | allow a service to be provided from multiple alternative endpoints, 46 | each with associated parameters (such as transport protocol 47 | configuration), and are extensible to support future uses 48 | (such as keys for encrypting the TLS ClientHello). They also 49 | enable aliasing of apex domains, which is not possible with CNAME. 50 | The HTTPS RR is a variation of SVCB for use with HTTP {{!HTTP=I-D.ietf-httpbis-semantics}}. 51 | By providing more information to the client before it attempts to 52 | establish a connection, these records offer potential benefits to 53 | both performance and privacy. 54 | 55 | TO BE REMOVED: This document is being collaborated on in Github at: 56 | [https://github.com/MikeBishop/dns-alt-svc](https://github.com/MikeBishop/dns-alt-svc). 57 | The most recent working version of the document, open issues, etc. should all be 58 | available there. The authors (gratefully) accept pull requests. 59 | 60 | --- middle 61 | 62 | # Introduction 63 | 64 | The SVCB ("Service Binding") and HTTPS RRs provide clients with complete instructions 65 | for access to a service. This information enables improved 66 | performance and privacy by avoiding transient connections to a suboptimal 67 | default server, negotiating a preferred protocol, and providing relevant 68 | public keys. 69 | 70 | For example, HTTP clients currently resolve only A and/or AAAA records for 71 | the origin hostname, learning only its IP addresses. If an HTTP client learns 72 | more about the origin before connecting, it may be able to upgrade "http" URLs 73 | to "https", enable HTTP/3 or Encrypted ClientHello {{?ECH=I-D.ietf-tls-esni}}, 74 | or switch to an 75 | operationally preferable endpoint. It is highly desirable to minimize the 76 | number of round-trips and lookups required to 77 | learn this additional information. 78 | 79 | The SVCB and HTTPS RRs also help when the operator of a service 80 | wishes to delegate operational control to one or more other domains, e.g. 81 | delegating the origin "https://example.com" to a service 82 | operator endpoint at "svc.example.net". While this case can sometimes 83 | be handled by a CNAME, that does not cover all use-cases. CNAME is also 84 | inadequate when the service operator needs to provide a bound 85 | collection of consistent configuration parameters through the DNS 86 | (such as network location, protocol, and keying information). 87 | 88 | This document first describes the SVCB RR as a general-purpose resource 89 | record that can be applied directly and efficiently to a wide range 90 | of services ({{svcb}}). It also describes the rules for defining other 91 | SVCB-compatible RR types ({{svcb-compatible}}), starting with the HTTPS 92 | RR type ({{https}}), which provides improved efficiency and convenience 93 | with HTTP by avoiding the need for an Attrleaf label {{!Attrleaf=RFC8552}} 94 | ({{httpsnames}}). 95 | 96 | The SVCB RR has two modes: 1) "AliasMode", which simply delegates operational 97 | control for a resource; 2) "ServiceMode", which binds together 98 | configuration information for a service endpoint. 99 | ServiceMode provides additional key=value parameters 100 | within each RDATA set. 101 | 102 | ## Goals of the SVCB RR 103 | 104 | The goal of the SVCB RR is to allow clients to resolve a single 105 | additional DNS RR in a way that: 106 | 107 | * Provides alternative endpoints that are authoritative for the service, 108 | along with parameters associated with each of these endpoints. 109 | * Does not assume that all alternative endpoints have the same parameters 110 | or capabilities, or are even 111 | operated by the same entity. This is important, as DNS does not 112 | provide any way to tie together multiple RRSets for the same name. 113 | For example, if www.example.com is a CNAME alias that switches 114 | between one of three CDNs or hosting environments, successive queries 115 | for that name may return records that correspond to different environments. 116 | * Enables CNAME-like functionality at a zone apex (such as 117 | "example.com") for participating protocols, and generally 118 | enables delegation of operational authority for an origin within the 119 | DNS to an alternate name. 120 | 121 | Additional goals specific to HTTPS RRs and the HTTP use-cases include: 122 | 123 | * Connect directly to HTTP/3 (QUIC transport) 124 | alternative endpoints {{?HTTP3=I-D.ietf-quic-http}} 125 | * Support non-default TCP and UDP ports 126 | * Enable SRV-like benefits (e.g. apex delegation, as mentioned above) for HTTP, 127 | where SRV {{?SRV=RFC2782}} has not been widely adopted 128 | * Provide an HSTS-like indication {{?HSTS=RFC6797}} signaling that the "https" 129 | scheme should be used instead of "http" for all HTTP requests to this host and port (see 130 | {{hsts}}). 131 | * Enable the conveyance of Encrypted ClientHello {{ECH}} keys associated 132 | with an alternative endpoint. 133 | 134 | ## Overview of the SVCB RR 135 | 136 | This subsection briefly describes the SVCB RR with forward references to 137 | the full exposition of each component. (As mentioned above, this all 138 | applies equally to the HTTPS RR which shares 139 | the same encoding, format, and high-level semantics.) 140 | 141 | The SVCB RR has two modes: AliasMode ({{alias-mode}}), which aliases a name 142 | to another name, and ServiceMode ({{service-mode}}), which provides connection 143 | information bound to a service endpoint domain. Placing both forms in a single 144 | RR type allows clients to 145 | fetch the relevant information with a single query ({{svcb-names}}). 146 | 147 | The SVCB RR has two required fields and one optional field. The fields are: 148 | 149 | 1. SvcPriority ({{pri}}): The priority of this record (relative to others, 150 | with lower values preferred). A value of 0 indicates AliasMode. 151 | 2. TargetName: The domain name of either the alias target (for 152 | AliasMode) or the alternative endpoint (for ServiceMode). 153 | 3. SvcParams (optional): A list of key=value pairs 154 | describing the alternative endpoint at 155 | TargetName (only used in ServiceMode and otherwise ignored). 156 | Described in {{presentation}}. 157 | 158 | Cooperating DNS recursive resolvers will perform subsequent record 159 | resolution (for SVCB, A, and AAAA records) and return them in the 160 | Additional Section of the response ({{recursive-behavior}}). Clients either use responses 161 | included in the additional section returned by the recursive resolver 162 | or perform necessary SVCB, A, and AAAA record resolutions ({{client-behavior}}). DNS 163 | authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME 164 | records in the Additional Section to responses for a SVCB query ({{authoritative-behavior}}). 165 | 166 | In ServiceMode, the SvcParams of the SVCB RR 167 | provide an extensible data model for describing alternative 168 | endpoints that are authoritative for a service, along with 169 | parameters associated with each of these alternative endpoints ({{keys}}). 170 | 171 | For HTTP use-cases, the HTTPS RR ({{https}}) enables many of the benefits of Alt-Svc 172 | {{?AltSvc=RFC7838}} 173 | without waiting for a full HTTP connection initiation (multiple roundtrips) 174 | before learning of the preferred alternative, 175 | and without necessarily revealing the user's 176 | intended destination to all entities along the network path. 177 | 178 | 179 | ## Terminology 180 | 181 | Our terminology is based on the common case where the SVCB record is used to 182 | access a resource identified by a URI whose `authority` field contains a DNS 183 | hostname as the `host`. 184 | 185 | * The "service" is the information source identified by the `authority` and 186 | `scheme` of the URI, capable of providing access to the resource. For "https" 187 | URIs, the "service" corresponds to an "origin" {{?RFC6454}}. 188 | * The "service name" is the `host` portion of the authority. 189 | * The "authority endpoint" is the authority's hostname and a port number implied 190 | by the scheme or specified in the URI. 191 | * An "alternative endpoint" is a hostname, port number, and other associated 192 | instructions to the client on how to reach an instance of service. 193 | 194 | Additional DNS terminology intends to be consistent 195 | with {{?DNSTerm=RFC8499}}. 196 | 197 | SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, 198 | and future RR types that share SVCB's formats and registry are 199 | collectively known as SVCB-compatible RR types. The contraction "SVCB" is also 200 | used to refer to this system as a whole. 201 | 202 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 203 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 204 | "MAY", and "OPTIONAL" in this document are to be interpreted as 205 | described in BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they 206 | appear in all capitals, as shown here. 207 | 208 | 209 | 210 | # The SVCB record type {#svcb} 211 | 212 | The SVCB DNS resource record (RR) type (RR type 64) 213 | is used to locate alternative endpoints for a service. 214 | 215 | The algorithm for resolving SVCB records and associated 216 | address records is specified in {{client-behavior}}. 217 | 218 | Other SVCB-compatible resource record types 219 | can also be defined as-needed (see {{svcb-compatible}}). In particular, the 220 | HTTPS RR (RR type 65) provides special handling 221 | for the case of "https" origins as described in {{https}}. 222 | 223 | SVCB RRs are extensible by a list of SvcParams, which are pairs consisting of a 224 | SvcParamKey and a SvcParamValue. Each SvcParamKey has a presentation name and a 225 | registered number. Values are in a format specific to the SvcParamKey. Each 226 | SvcParam has a specified presentation format (used in zone files) and 227 | wire encoding 228 | (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys 229 | and their formats are defined in {{keys}}. 230 | 231 | ## Zone file presentation format {#presentation} 232 | 233 | The presentation format `` of the record ({{!RFC1035, Section 5.1}}) has 234 | the form: 235 | 236 | SvcPriority TargetName SvcParams 237 | 238 | The SVCB record is defined specifically within 239 | the Internet ("IN") Class ({{!RFC1035, Section 3.2.4}}). 240 | 241 | SvcPriority is a number in the range 0-65535, 242 | TargetName is a `` ({{!RFC1035, Section 5.1}}), 243 | and the SvcParams are a whitespace-separated list, with each SvcParam 244 | consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey. 245 | SvcParamKeys are subject to IANA control ({{svcparamregistry}}). 246 | 247 | Each SvcParamKey SHALL appear at most once in the SvcParams. 248 | In presentation format, SvcParamKeys are lower-case alphanumeric strings. 249 | Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-". 250 | In ABNF {{!RFC5234}}, 251 | 252 | alpha-lc = %x61-7A ; a-z 253 | SvcParamKey = 1*63(alpha-lc / DIGIT / "-") 254 | SvcParam = SvcParamKey ["=" SvcParamValue] 255 | SvcParamValue = char-string ; See Appendix A 256 | value = *OCTET ; Value before key-specific parsing 257 | 258 | The SvcParamValue is parsed using the 259 | character-string decoding algorithm ({{decoding}}), producing a `value`. 260 | The `value` is then validated and converted into wire-format in a manner 261 | specific to each key. 262 | 263 | When the optional "=" and SvcParamValue are omitted, the `value` is 264 | interpreted as empty. 265 | 266 | Arbitrary keys can be represented using the unknown-key presentation format 267 | "keyNNNNN" where NNNNN is the numeric 268 | value of the key type without leading zeros. 269 | A SvcParam in this form SHALL be parsed as specified above, and 270 | the decoded `value` SHALL be used as its wire format encoding. 271 | 272 | For some SvcParamKeys, the `value` corresponds to a list or set of 273 | items. Presentation formats for such keys SHOULD use a comma-separated list 274 | ({{value-list}}). 275 | 276 | SvcParams in presentation format MAY appear in any order, but keys MUST NOT be 277 | repeated. 278 | 279 | ## RDATA wire format 280 | 281 | The RDATA for the SVCB RR consists of: 282 | 283 | * a 2-octet field for SvcPriority as an integer in network 284 | byte order. 285 | * the uncompressed, fully-qualified TargetName, represented as 286 | a sequence of length-prefixed labels as in {{Section 3.1 of !RFC1035}}. 287 | * the SvcParams, consuming the remainder of the record 288 | (so smaller than 65535 octets and constrained by the RDATA 289 | and DNS message sizes). 290 | 291 | When the list of SvcParams is non-empty, it contains a series of 292 | SvcParamKey=SvcParamValue pairs, represented as: 293 | 294 | * a 2-octet field containing the SvcParamKey as an 295 | integer in network byte order. (See {{iana-keys}} for the defined values.) 296 | * a 2-octet field containing the length of the SvcParamValue 297 | as an integer between 0 and 65535 in network byte order. 298 | * an octet string of this length whose contents are the SvcParamValue in a 299 | format determined by the SvcParamKey. 300 | 301 | SvcParamKeys SHALL appear in increasing numeric order. 302 | 303 | Clients MUST consider an RR malformed if: 304 | 305 | * the end of the RDATA occurs within a SvcParam. 306 | * SvcParamKeys are not in strictly increasing numeric order. 307 | * the SvcParamValue for an SvcParamKey does not have the expected format. 308 | 309 | Note that the second condition implies that there are no duplicate 310 | SvcParamKeys. 311 | 312 | If any RRs are malformed, the client MUST reject the entire RRSet and 313 | fall back to non-SVCB connection establishment. 314 | 315 | 316 | ## SVCB query names {#svcb-names} 317 | 318 | When querying the SVCB RR, a service is translated into a QNAME by prepending 319 | the service name with a label indicating the scheme, prefixed with an underscore, 320 | resulting in a domain name like "_examplescheme.api.example.com.". This 321 | follows the Attrleaf naming pattern {{Attrleaf}}, so the scheme MUST be 322 | registered appropriately with IANA (see {{other-standards}}). 323 | 324 | Protocol mapping documents MAY specify additional underscore-prefixed labels 325 | to be prepended. For schemes that specify a port ({{Section 3.2.3 326 | of ?URI=RFC3986}}), one reasonable possibility is to prepend the indicated port 327 | number if a non-default port number is specified. We term this behavior 328 | "Port Prefix Naming", and use it in the examples throughout this document. 329 | 330 | See {{httpsnames}} for the HTTPS RR behavior. 331 | 332 | When a prior CNAME or SVCB record has aliased to 333 | a SVCB record, each RR SHALL be returned under its own owner name, as in 334 | ordinary CNAME processing ({{!RFC1034, Section 3.6.2}}). For details, see 335 | the recommendations regarding aliases for clients ({{client-behavior}}), 336 | servers ({{server-behavior}}), and zones ({{zone-structures}}). 337 | 338 | Note that none of these forms alter the origin or authority for validation 339 | purposes. 340 | For example, TLS clients MUST continue to validate TLS certificates 341 | for the original service name. 342 | 343 | As an example, the owner of example.com could publish this record: 344 | 345 | _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 346 | 347 | to indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". 348 | The owner of example.net, in turn, could publish this record: 349 | 350 | svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( 351 | alpn="bar" port="8004" ) 352 | 353 | to indicate that these services are served on port number 8004, 354 | which supports the protocol "bar" and its associated transport in 355 | addition to the default transport protocol for "foo://". 356 | 357 | (Parentheses are used to ignore a line break in DNS zone file presentation 358 | format ({{RFC1035, Section 5.1}}).) 359 | 360 | ## Interpretation 361 | 362 | ### SvcPriority {#pri} 363 | 364 | When SvcPriority is 0 the SVCB record is in AliasMode ({{alias-mode}}). 365 | Otherwise, it is in ServiceMode ({{service-mode}}). 366 | 367 | Within a SVCB RRSet, 368 | all RRs SHOULD have the same Mode. 369 | If an RRSet contains a record in AliasMode, the recipient MUST ignore 370 | any ServiceMode records in the set. 371 | 372 | RRSets are explicitly unordered collections, so the 373 | SvcPriority field is used to impose an ordering on SVCB RRs. 374 | A smaller SvcPriority indicates that the domain owner recommends use of this 375 | record over ServiceMode RRs with a larger SvcPriority value. 376 | 377 | When receiving an RRSet containing multiple SVCB records with the 378 | same SvcPriority value, clients SHOULD apply a random shuffle within a 379 | priority level to the records before using them, to ensure uniform 380 | load-balancing. 381 | 382 | 383 | ### AliasMode {#alias-mode} 384 | 385 | In AliasMode, the SVCB record aliases a service to a 386 | TargetName. SVCB RRSets SHOULD only have a single resource 387 | record in AliasMode. If multiple are present, clients or recursive 388 | resolvers SHOULD pick one at random. 389 | 390 | The primary purpose of AliasMode is to allow aliasing at the zone 391 | apex, where CNAME is not allowed (see e.g. {{?RFC1912, Section 2.4}}). 392 | In AliasMode, the TargetName will 393 | be the name of a domain that resolves to SVCB, 394 | AAAA, and/or A records. (See {{svcb-compatible}} for aliasing of SVCB-compatible RR types.) 395 | Unlike CNAME, AliasMode records do not affect the resolution of other RR 396 | types, and apply only to a specific service, not an entire domain name. 397 | 398 | The AliasMode TargetName SHOULD NOT be equal 399 | to the owner name, as this would result in a loop. 400 | In AliasMode, recipients MUST ignore any SvcParams that are present. 401 | Zone-file parsers MAY emit a warning if an AliasMode record has SvcParams. 402 | The use of SvcParams in AliasMode records is currently not defined, but a 403 | future specification could extend AliasMode records to include SvcParams. 404 | 405 | For example, the operator of foo://example.com:8080 could 406 | point requests to a service operating at foosvc.example.net 407 | by publishing: 408 | 409 | _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. 410 | 411 | Using AliasMode maintains a separation of concerns: the owner of 412 | foosvc.example.net can add or remove ServiceMode SVCB records without 413 | requiring a corresponding change to example.com. Note that if 414 | foosvc.example.net promises to always publish a SVCB record, this AliasMode 415 | record can be replaced by a CNAME at the same owner name, which would likely 416 | improve performance. 417 | 418 | AliasMode is especially useful for SVCB-compatible RR types that do not 419 | require an underscore prefix, such as the HTTPS RR type. For example, 420 | the operator of https://example.com could point requests to a server 421 | at svc.example.net by publishing this record at the zone apex: 422 | 423 | example.com. 3600 IN HTTPS 0 svc.example.net. 424 | 425 | Note that the SVCB record's owner name MAY be the canonical name 426 | of a CNAME record, and the TargetName MAY be the owner of a CNAME 427 | record. Clients and recursive resolvers MUST follow CNAMEs as normal. 428 | 429 | To avoid unbounded alias chains, clients and recursive resolvers MUST impose a 430 | limit on the total number of SVCB aliases they will follow for each resolution 431 | request. This limit MUST NOT be zero, i.e. implementations MUST be able to 432 | follow at least one AliasMode record. The exact value of this limit 433 | is left to implementations. 434 | 435 | Zones that require following multiple AliasMode records could encounter 436 | compatibility and performance issues. 437 | 438 | As legacy clients will not know to use this record, service 439 | operators will likely need to retain fallback AAAA and A records 440 | alongside this SVCB record, although in a common case 441 | the target of the SVCB record might offer better performance, and 442 | therefore would be preferable for clients implementing this specification 443 | to use. 444 | 445 | AliasMode records only apply to queries for the specific RR type. 446 | For example, a SVCB record cannot alias to an HTTPS record, 447 | nor vice-versa. 448 | 449 | ### ServiceMode {#service-mode} 450 | 451 | In ServiceMode, the TargetName and SvcParams within each resource record 452 | associate an alternative endpoint for the service with its connection 453 | parameters. 454 | 455 | Each protocol scheme that uses SVCB MUST define a protocol mapping that 456 | explains how SvcParams are applied for connections of that scheme. 457 | Unless specified otherwise by the 458 | protocol mapping, clients MUST ignore any SvcParam that they do 459 | not recognize. 460 | 461 | Some SvcParams impose requirements on other SvcParams in the RR. A 462 | ServiceMode RR is called "self-consistent" if its SvcParams all comply with 463 | each other's requirements. Clients MUST reject any RR whose recognized 464 | SvcParams are not self-consistent, and MAY reject the entire RRSet. To 465 | help zone operators avoid this condition, zone-file implementations SHOULD 466 | enforce self-consistency as well. 467 | 468 | ## Special handling of "." in TargetName {#dot} 469 | 470 | If TargetName has the value "." (represented in the wire format as a 471 | zero-length label), special rules apply. 472 | 473 | ### AliasMode {#aliasdot} 474 | 475 | For AliasMode SVCB RRs, a TargetName of "." indicates that the service 476 | is not available or does not exist. This indication is advisory: 477 | clients encountering this indication MAY ignore it and attempt to connect 478 | without the use of SVCB. 479 | 480 | ### ServiceMode 481 | 482 | For ServiceMode SVCB RRs, if TargetName has the value ".", then the 483 | owner name of this record MUST be used as the effective TargetName. 484 | If the record has a wildcard owner name in the zone file, the recipient 485 | SHALL use the response's synthesized owner name as the effective TargetName. 486 | 487 | For example, in the following example "svc2.example.net" 488 | is the effective TargetName: 489 | 490 | example.com. 7200 IN HTTPS 0 svc.example.net. 491 | svc.example.net. 7200 IN CNAME svc2.example.net. 492 | svc2.example.net. 7200 IN HTTPS 1 . port=8002 493 | svc2.example.net. 300 IN A 192.0.2.2 494 | svc2.example.net. 300 IN AAAA 2001:db8::2 495 | 496 | 497 | 498 | # Client behavior {#client-behavior} 499 | 500 | "SVCB resolution" is the process of enumerating the priority-ordered endpoints 501 | for a service, as performed by the client. SVCB resolution is implemented as follows: 502 | 503 | 1. Let $QNAME be the service name plus appropriate prefixes for the 504 | scheme (see {{svcb-names}}). 505 | 506 | 2. Issue a SVCB query for $QNAME. 507 | 508 | 3. If an AliasMode SVCB record is returned for $QNAME (after following CNAMEs 509 | as normal), set $QNAME to its TargetName (without 510 | additional prefixes) and loop back to step 2, 511 | subject to chain length limits and loop detection heuristics (see 512 | {{client-failures}}). 513 | 514 | 4. If one or more "compatible" ({{mandatory}}) ServiceMode records are returned, 515 | these represent the alternative endpoints. 516 | 517 | 5. Otherwise, SVCB resolution has failed, and the list of known endpoints is 518 | empty. 519 | 520 | This procedure does not rely on any recursive or authoritative DNS server to 521 | comply with this specification or have any awareness of SVCB. 522 | 523 | A client is called "SVCB-optional" if it can connect without the use of 524 | ServiceMode records, and "SVCB-reliant" otherwise. Clients for pre-existing 525 | protocols (e.g. HTTP) SHALL implement SVCB-optional behavior (except as 526 | noted in {{client-failures}} or when modified by future specifications). 527 | 528 | SVCB-optional clients SHOULD issue in parallel any other DNS queries that might 529 | be needed for connection establishment if the SVCB record is absent, in order to minimize delay 530 | in that case and enable the optimizations discussed in {{optimizations}}. 531 | 532 | Once SVCB resolution has concluded, whether successful or not, 533 | if at least one AliasMode record was processed, 534 | SVCB-optional clients SHALL append to the priority list an 535 | endpoint consisting of the final value of $QNAME, the authority 536 | endpoint's port number, and no SvcParams. (This endpoint will be 537 | attempted before falling back to non-SVCB connection modes. This ensures that 538 | SVCB-optional clients will make use of an AliasMode record whose TargetName has 539 | A and/or AAAA records but no SVCB records.) 540 | 541 | The client proceeds with connection establishment using the resolved list of 542 | endpoints. Clients SHOULD try higher-priority alternatives first, with 543 | fallback to lower-priority alternatives. Clients resolve AAAA and/or A 544 | records for the selected TargetName, and MAY choose between them using an 545 | approach such as Happy Eyeballs {{!HappyEyeballsV2=RFC8305}}. 546 | 547 | If the client is SVCB-optional, and connecting using this list of endpoints has 548 | failed, the client now attempts to use non-SVCB connection modes. 549 | 550 | Some important optimizations are discussed in {{optimizations}} 551 | to avoid additional latency in comparison to ordinary AAAA/A lookups. 552 | 553 | ## Handling resolution failures {#client-failures} 554 | 555 | If DNS responses are cryptographically protected (e.g. using DNSSEC or 556 | TLS {{!DoT=RFC7858}}{{!DoH=RFC8484}}), and SVCB resolution fails 557 | due to an authentication error, SERVFAIL response, transport error, or 558 | timeout, the client SHOULD abandon its attempt to reach the service, even 559 | if the client is SVCB-optional. Otherwise, an active attacker 560 | could mount a downgrade attack by denying the user access to the SvcParams. 561 | 562 | A SERVFAIL error can occur if the domain is DNSSEC-signed, the recursive 563 | resolver is DNSSEC-validating, and the attacker is between the recursive 564 | resolver and the authoritative DNS server. A transport error or timeout can 565 | occur if an active attacker between the client and the recursive resolver is 566 | selectively dropping SVCB queries or responses, based on their size or 567 | other observable patterns. 568 | 569 | If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD 570 | apply the same validation policy to SVCB. Otherwise, an attacker could 571 | defeat the A/AAAA protection by forging SVCB responses that direct the 572 | client to other IP addresses. 573 | 574 | If DNS responses are not cryptographically protected, clients MAY treat 575 | SVCB resolution failure as fatal or nonfatal. 576 | 577 | If the client is unable to complete SVCB resolution due to its chain length 578 | limit, the client MUST fall back to the authority endpoint, as if the 579 | origin's SVCB record did not exist. 580 | 581 | ## Clients using a Proxy 582 | 583 | Clients using a domain-oriented transport proxy like HTTP CONNECT 584 | ({{!RFC7231, Section 4.3.6}}) or SOCKS5 ({{!RFC1928}}) have the option to 585 | use named destinations, in which case the client does not perform 586 | any A or AAAA queries for destination domains. If the client is configured 587 | to use named 588 | destinations with a proxy that does not provide SVCB query capability 589 | (e.g. through an affiliated DNS resolver), the client would have to perform 590 | SVCB resolution separately, likely disclosing the destinations to additional parties than just the proxy. 591 | Clients in this configuration SHOULD arrange for a separate SVCB resolution 592 | procedure with appropriate privacy properties. If this is not possible, 593 | SVCB-optional clients MUST disable SVCB resolution entirely, and SVCB-reliant 594 | clients MUST treat the configuration as invalid. 595 | 596 | If the client does use SVCB and named destinations, the client SHOULD follow 597 | the standard SVCB resolution process, selecting the smallest-SvcPriority 598 | option that is compatible with the client and the proxy. When connecting 599 | using a SVCB record, clients MUST provide the final TargetName and port to the 600 | proxy, which will perform any required A and AAAA lookups. 601 | 602 | This arrangement has several benefits: 603 | 604 | * Compared to disabling SVCB: 605 | - It allows the client to use the SvcParams, if present, which are 606 | only usable with a specific TargetName. The SvcParams may 607 | include information that enhances performance (e.g. alpn) and privacy. 608 | - It allows the service to delegate the apex domain. 609 | 610 | * Compared to providing the proxy with an IP address: 611 | - It allows the proxy to select between IPv4 and IPv6 addresses for the 612 | server according to its configuration. 613 | - It ensures that the proxy receives addresses based on its network 614 | geolocation, not the client's. 615 | - It enables faster fallback for TCP destinations with multiple addresses 616 | of the same family. 617 | 618 | # DNS Server Behavior {#server-behavior} 619 | 620 | ## Authoritative servers {#authoritative-behavior} 621 | 622 | When replying to a SVCB query, authoritative DNS servers SHOULD return 623 | A, AAAA, and SVCB records in the Additional Section for any TargetNames 624 | that are in the zone. If the zone is signed, the server SHOULD also 625 | include positive or negative DNSSEC responses for these records in the Additional 626 | section. 627 | 628 | See {{ecs}} for exceptions. 629 | 630 | ## Recursive resolvers {#recursive-behavior} 631 | 632 | Whether the recursive resolver is aware of SVCB or not, the normal response 633 | construction process (i.e. unknown RR type resolution under {{!RFC3597}}) 634 | generates the Answer section of the response. 635 | Recursive resolvers that are aware of SVCB SHOULD help the client to 636 | execute the procedure in {{client-behavior}} with minimum overall 637 | latency by incorporating additional useful information into the 638 | Additional section of the response as follows: 639 | 640 | 1. Incorporate the results of SVCB resolution. If the recursive resolver's 641 | local chain length limit (which may be different from the client's limit) has 642 | been reached, terminate. 643 | 644 | 2. If any of the resolved SVCB records are in AliasMode, choose one of them 645 | at random, and resolve SVCB, A, and AAAA records for its 646 | TargetName. 647 | 648 | - If any SVCB records are resolved, go to step 1. 649 | 650 | - Otherwise, incorporate the results of A and AAAA resolution, and 651 | terminate. 652 | 653 | 3. All the resolved SVCB records are in ServiceMode. Resolve A and AAAA 654 | queries for each TargetName (or for the owner name if TargetName 655 | is "."), incorporate all the results, and terminate. 656 | 657 | In this procedure, "resolve" means the resolver's ordinary recursive 658 | resolution procedure, as if processing a query for that RRSet. 659 | This includes following any aliases that the resolver would ordinarily 660 | follow (e.g. CNAME, DNAME {{?DNAME=RFC6672}}). Errors or anomalies in 661 | obtaining additional records MAY cause this process to terminate, but 662 | MUST NOT themselves cause the resolver to send a failure response. 663 | 664 | See {{alias-mode}} for additional safeguards for recursive resolvers 665 | to implement to mitigate loops. 666 | 667 | See {{incomplete-response}} for possible optimizations of this procedure. 668 | 669 | ### DNS64 670 | 671 | DNS64 resolvers synthesize responses to AAAA queries for names that only 672 | have an A record ({{Section 5.1.7 of !RFC6147}}). SVCB-aware DNS64 673 | resolvers SHOULD apply the same synthesis logic when resolving AAAA 674 | records for the TargetName for inclusion as Additionals (Step 2 in 675 | {{recursive-behavior}}), and MAY omit the Additional A records. 676 | 677 | DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the IP 678 | hints in the SvcParams ({{svcparamkeys-iphints}}). Modifying the IP hints 679 | would break DNSSEC validation for the SVCB record and would not improve 680 | performance when the above recommendation is implemented. 681 | 682 | ## General requirements 683 | 684 | Recursive resolvers MUST be able to convey SVCB records with unrecognized 685 | SvcParamKeys, and MAY treat the entire SvcParams portion of the record as 686 | opaque, even if the contents are invalid. Alternatively, recursive 687 | resolvers MAY report an error such as SERVFAIL to avoid returning a 688 | SvcParamValue that is invalid according to the SvcParam's specification. 689 | For complex value types whose interpretation might differ 690 | between implementations or have additional future 691 | allowed values added (e.g. URIs or "alpn"), resolvers 692 | SHOULD limit validation to specified constraints. 693 | 694 | When responding to a query that includes the DNSSEC OK bit ({{!RFC3225}}), 695 | DNSSEC-capable recursive and authoritative DNS servers MUST accompany 696 | each RRSet in the Additional section with the same DNSSEC-related records 697 | that they would send when providing that RRSet as an Answer (e.g. RRSIG, NSEC, 698 | NSEC3). 699 | 700 | According to {{Section 5.4.1 of !RFC2181}}, "Unauthenticated RRs received 701 | and cached from ... the additional data section ... should not be cached in 702 | such a way that they would ever be returned as answers to a received query. 703 | They may be returned as additional information where appropriate.". 704 | Recursive resolvers therefore MAY cache records from the Additional section 705 | for use in populating Additional section responses, and MAY cache them 706 | for general use if they are authenticated by DNSSEC. 707 | 708 | ## EDNS Client Subnet (ECS) {#ecs} 709 | 710 | The EDNS Client Subnet option (ECS, {{!RFC7871}}) allows recursive 711 | resolvers to request IP addresses that are suitable for a particular client 712 | IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams), 713 | or direct users to a subnet-specific TargetName, so recursive resolvers 714 | SHOULD include the same ECS option in SVCB queries as in A/AAAA queries. 715 | 716 | According to {{Section 7.3.1 of !RFC7871}}, "Any records from \[the 717 | Additional section\] MUST NOT be tied to a network". Accordingly, 718 | when processing a response whose QTYPE is SVCB-compatible, 719 | resolvers SHOULD treat any records in the Additional section as having 720 | SOURCE PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified 721 | in the ECS option. Authoritative servers MUST omit such records if they are 722 | not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to 723 | zero. This will cause the resolver to perform a follow-up query that can 724 | receive properly tailored ECS. (This is similar to the usage of CNAME with 725 | ECS discussed in {{!RFC7871, Section 7.2.1}}.) 726 | 727 | Authoritative servers that omit Additional records can avoid the added 728 | latency of a follow-up query by following the advice in {{zone-performance}}. 729 | 730 | # Performance optimizations {#optimizations} 731 | 732 | For optimal performance (i.e. minimum connection setup time), clients 733 | SHOULD implement a client-side DNS cache. 734 | Responses in the Additional section of a SVCB response SHOULD be placed 735 | in cache before performing any follow-up queries. 736 | With this behavior, and conforming DNS servers, 737 | using SVCB does not add network latency to connection setup. 738 | 739 | To improve performance when using a non-conforming recursive resolver, clients 740 | SHOULD issue speculative A and/or AAAA queries in parallel with each SVCB 741 | query, based on a predicted value of TargetName (see {{zone-performance}}). 742 | 743 | After a ServiceMode RRSet is received, clients MAY try more than one option 744 | in parallel, and MAY prefetch A and AAAA records for multiple TargetNames. 745 | 746 | ## Optimistic pre-connection and connection reuse 747 | 748 | If an address response arrives before the corresponding SVCB response, the 749 | client MAY initiate a connection as if the SVCB query returned NODATA, but 750 | MUST NOT transmit any information that could be altered by the SVCB response 751 | until it arrives. For example, future SvcParamKeys could be defined that 752 | alter the TLS ClientHello. 753 | 754 | Clients 755 | implementing this optimization SHOULD wait for 50 milliseconds before 756 | starting optimistic pre-connection, as per the guidance in 757 | {{HappyEyeballsV2}}. 758 | 759 | A SVCB record is consistent with a connection 760 | if the client would attempt an equivalent connection when making use of 761 | that record. If a SVCB record is consistent with an active or in-progress 762 | connection C, the client MAY prefer that record and use C as its connection. 763 | For example, suppose the client receives this SVCB RRSet for a protocol 764 | that uses TLS over TCP: 765 | 766 | _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 767 | ipv6hint=2001:db8::1 port=1234 ) 768 | SVCB 2 svc2.example.net. ( 769 | ipv6hint=2001:db8::2 port=1234 ) 770 | 771 | If the client has an in-progress TCP connection to `[2001:db8::2]:1234`, 772 | it MAY proceed with TLS on that connection, even 773 | though the other record in the RRSet has higher priority. 774 | 775 | If none of the SVCB records are consistent 776 | with any active or in-progress connection, 777 | clients proceed with connection establishment as described in 778 | {{client-behavior}}. 779 | 780 | ## Generating and using incomplete responses {#incomplete-response} 781 | 782 | When following the procedure in {{recursive-behavior}}, recursive 783 | resolvers MAY terminate the procedure early and produce a reply that omits 784 | some of the associated RRSets. This is REQUIRED when the chain length limit 785 | is reached ({{recursive-behavior}} step 1), but might also be appropriate 786 | when the maximum response size is reached, or when responding before fully 787 | chasing dependencies would improve performance. When omitting certain 788 | RRSets, recursive resolvers SHOULD prioritize information for 789 | smaller-SvcPriority records. 790 | 791 | As discussed in {{client-behavior}}, clients MUST be able to fetch additional 792 | information that is required to use a SVCB record, if it is not included 793 | in the initial response. As a performance optimization, if some of the SVCB 794 | records in the response can be used without requiring additional DNS queries, 795 | the client MAY prefer those records, regardless of their priorities. 796 | 797 | # SVCB-compatible 798 | 799 | An RR type is called "SVCB-compatible" if it permits an implementation that is 800 | identical to SVCB in its: 801 | 802 | * RDATA presentation format 803 | * RDATA wire format 804 | * IANA registry used for SvcParamKeys 805 | * Authoritative server Additional Section processing 806 | * Recursive resolution process 807 | * Relevant Class (i.e. Internet ("IN") {{!RFC1035}}) 808 | 809 | This allows authoritative and recursive DNS servers to apply identical 810 | processing to all SVCB-compatible RR types. 811 | 812 | All other behaviors described as applying to the SVCB RR also apply 813 | to all SVCB-compatible RR types unless explicitly stated otherwise. 814 | When following an AliasMode record ({{alias-mode}}) of RR type $T , the 815 | followup query to the TargetName MUST also be for type $T. 816 | 817 | This document defines one SVCB-compatible RR type (other than SVCB itself): 818 | the HTTPS RR type ({{https}}), which avoids Attrleaf label prefixes {{?Attrleaf=RFC8552}} in order to improve 819 | compatibility with wildcards and CNAMEs, which are widely used with HTTP. 820 | 821 | Standards authors should consider carefully whether to use SVCB or define a 822 | new SVCB-compatible RR type, as this choice cannot easily be reversed after 823 | deployment. 824 | 825 | # Initial SvcParamKeys {#keys} 826 | 827 | A few initial SvcParamKeys are defined here. These keys are useful for the 828 | "https" scheme, and most are expected to be generally applicable to other 829 | schemes as well. 830 | 831 | Each new protocol 832 | mapping document MUST specify which keys are applicable and safe to use. 833 | Protocol mappings MAY alter the interpretation of SvcParamKeys but MUST NOT 834 | alter their presentation or wire formats. 835 | 836 | ## "alpn" and "no-default-alpn" {#alpn-key} 837 | 838 | The "alpn" and "no-default-alpn" SvcParamKeys together 839 | indicate the set of Application Layer Protocol Negotiation (ALPN) 840 | protocol identifiers {{!ALPN=RFC7301}} 841 | and associated transport protocols supported by this service endpoint (the 842 | "SVCB ALPN set"). 843 | 844 | As with Alt-Svc {{AltSvc}}, each ALPN protocol identifier is used to 845 | identify the application protocol and associated suite 846 | of protocols supported by the endpoint (the "protocol suite"). 847 | The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that this 848 | service endpoint, described by TargetName and the other parameters (e.g. 849 | "port") offers service with the protocol suite associated with this ALPN identifier. 850 | 851 | Clients filter the set of ALPN identifiers to match the protocol suites they 852 | support, and this informs the underlying transport protocol used (such 853 | as QUIC-over-UDP or TLS-over-TCP). ALPN protocol identifiers that do not uniquely 854 | identify a protocol suite (e.g. an Identification Sequence that 855 | can be used with both TLS and DTLS) are not compatible with this 856 | SvcParamKey and MUST NOT be included in the SVCB ALPN set. 857 | 858 | ### Representation 859 | 860 | ALPNs are identified by their registered "Identification Sequence" 861 | (`alpn-id`), which is a sequence of 1-255 octets. 862 | 863 | alpn-id = 1*255OCTET 864 | 865 | For "alpn", the presentation `value` SHALL be 866 | a comma-separated list ({{value-list}}) 867 | of one or more `alpn-id`s. Zone file implementations MAY disallow the 868 | "," and "\\" characters instead of implementing the `value-list` escaping 869 | procedure, relying on the opaque key format (e.g. `key1=\002h2`) in the 870 | event that these characters are needed. 871 | 872 | The wire format value for "alpn" consists of at least one 873 | `alpn-id` prefixed by its length as a single octet, and these length-value 874 | pairs are concatenated to form the SvcParamValue. These pairs MUST exactly 875 | fill the SvcParamValue; otherwise, the SvcParamValue is malformed. 876 | 877 | For "no-default-alpn", the presentation and wire format values MUST be 878 | empty. When "no-default-alpn" is specified in an RR, 879 | "alpn" must also be specified in order for the RR 880 | to be "self-consistent" ({{service-mode}}). 881 | 882 | Each scheme that uses this SvcParamKey defines a "default set" of ALPNs 883 | that are supported by nearly all clients and servers, which MAY 884 | be empty. To determine the SVCB ALPN set, the client starts with the list of 885 | `alpn-id`s from the "alpn" SvcParamKey, and adds the default set unless the 886 | "no-default-alpn" SvcParamKey is present. 887 | 888 | ### Use 889 | 890 | To establish a connection to the endpoint, clients MUST 891 | 892 | 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB ALPN set 893 | that the client supports. 894 | 2. Let Intersection-Transports be the set of transports (e.g. TLS, DTLS, QUIC) 895 | implied by the protocols in SVCB-ALPN-Intersection. 896 | 3. For each transport in Intersection-Transports, construct a ProtocolNameList 897 | containing the Identification Sequences of all the client's supported ALPN 898 | protocols for that transport, without regard to the SVCB ALPN set. 899 | 900 | For example, if the SVCB ALPN set is \["http/1.1", "h3"\], and the client 901 | supports HTTP/1.1, HTTP/2, and HTTP/3, the client could attempt to connect using 902 | TLS over TCP with a ProtocolNameList of \["http/1.1", "h2"\], and could also 903 | attempt a connection using QUIC, with a ProtocolNameList of \["h3"\]. 904 | 905 | Once the client has constructed a ClientHello, protocol negotiation in that 906 | handshake proceeds as specified in {{!ALPN}}, without regard to the SVCB ALPN 907 | set. 908 | 909 | Clients MAY implement a fallback procedure, using a less-preferred transport 910 | if more-preferred transports fail to connect. This fallback behavior is 911 | vulnerable to manipulation by a network attacker who blocks the more-preferred 912 | transports, but it may be necessary for compatibility with existing networks. 913 | 914 | With this procedure in place, an attacker who can modify DNS and network 915 | traffic can prevent a successful transport connection, but cannot otherwise 916 | interfere with ALPN protocol selection. This procedure also ensures that 917 | each ProtocolNameList includes at least one protocol from the SVCB ALPN set. 918 | 919 | Clients SHOULD NOT attempt connection to a service endpoint whose SVCB 920 | ALPN set does not contain any supported protocols. 921 | 922 | To ensure 923 | consistency of behavior, clients MAY reject the entire SVCB RRSet and fall 924 | back to basic connection establishment if all of the compatible RRs indicate 925 | "no-default-alpn", even if connection could have succeeded using a 926 | non-default alpn. 927 | 928 | Zone operators SHOULD ensure that at least one RR in each RRSet supports the 929 | default transports. This enables compatibility with the greatest number of 930 | clients. 931 | 932 | ## "port" {#svcparamkeys-port} 933 | 934 | The "port" SvcParamKey defines the TCP or UDP port 935 | that should be used to reach this alternative endpoint. 936 | If this key is not present, clients SHALL use the authority endpoint's port 937 | number. 938 | 939 | The presentation `value` of the SvcParamValue is a single decimal integer 940 | between 0 and 65535 in ASCII. Any other `value` (e.g. an empty value) 941 | is a syntax error. To enable simpler parsing, this SvcParam MUST NOT contain 942 | escape sequences. 943 | 944 | The wire format of the SvcParamValue 945 | is the corresponding 2 octet numeric value in network byte order. 946 | 947 | If a port-restricting firewall is in place between some client and the service 948 | endpoint, changing the port number might cause that client to lose access to 949 | the service, so operators should exercise caution when using this SvcParamKey 950 | to specify a non-default port. 951 | 952 | ## "ipv4hint" and "ipv6hint" {#svcparamkeys-iphints} 953 | 954 | The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to 955 | reach the service. If A and AAAA records for TargetName are locally 956 | available, the client SHOULD ignore these hints. Otherwise, clients 957 | SHOULD perform A and/or AAAA queries for TargetName as in 958 | {{client-behavior}}, and clients SHOULD use the IP address in those 959 | responses for future connections. Clients MAY opt to terminate any 960 | connections using the addresses in hints and instead switch to the 961 | addresses in response to the TargetName query. Failure to use A and/or 962 | AAAA response addresses could negatively impact load balancing or other 963 | geo-aware features and thereby degrade client performance. 964 | 965 | The presentation `value` SHALL be a comma-separated list ({{value-list}}) 966 | of one or more IP addresses of the appropriate 967 | family in standard textual format {{!RFC5952}}{{!RFC4001}}. To enable simpler parsing, 968 | this SvcParamValue MUST NOT contain escape sequences. 969 | 970 | The wire format for each parameter is a sequence of IP addresses in network 971 | byte order (for the respective address-family). 972 | Like an A or AAAA RRSet, the list of addresses represents an 973 | unordered collection, and clients SHOULD pick addresses to use in a random order. 974 | An empty list of addresses is invalid. 975 | 976 | When selecting between IPv4 and IPv6 addresses to use, clients may use an 977 | approach such as Happy Eyeballs {{!HappyEyeballsV2}}. 978 | When only "ipv4hint" is present, NAT64 clients may synthesize 979 | IPv6 addresses as specified in {{!RFC7050}} or ignore the "ipv4hint" key and 980 | wait for AAAA resolution ({{client-behavior}}). 981 | For best performance, server operators SHOULD include an "ipv6hint" parameter 982 | whenever they include an "ipv4hint" parameter. 983 | 984 | These parameters are intended to minimize additional connection latency 985 | when a recursive resolver is not compliant with the requirements in 986 | {{server-behavior}}, and SHOULD NOT be included if most clients are using 987 | compliant recursive resolvers. When TargetName is the origin hostname 988 | or the owner name (which can be written as "."), server operators 989 | SHOULD NOT include these hints, because they are unlikely to convey any 990 | performance benefit. 991 | 992 | ## "mandatory" {#svcparamkey-mandatory} 993 | 994 | See {{mandatory}}. 995 | 996 | # ServiceMode RR compatibility and mandatory keys {#mandatory} 997 | 998 | In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not 999 | function correctly for clients that ignore this SvcParamKey. Each SVCB 1000 | protocol mapping SHOULD specify a set of keys that are "automatically 1001 | mandatory", i.e. mandatory if they are present in an RR. The SvcParamKey 1002 | "mandatory" is used to indicate any mandatory keys for this RR, in addition to 1003 | any automatically mandatory keys that are present. 1004 | 1005 | A ServiceMode RR is considered "compatible" by a client if the client 1006 | recognizes all the mandatory keys, and their values indicate that successful 1007 | connection establishment is possible. If the SVCB RRSet contains 1008 | no compatible RRs, the client will generally act as if the RRSet is empty. 1009 | 1010 | The presentation `value` SHALL be a comma-separated list 1011 | ({{value-list}}) of one or more valid 1012 | SvcParamKeys, either by their registered name or in the unknown-key format 1013 | ({{presentation}}). Keys MAY appear in any order, but MUST NOT appear more 1014 | than once. For self-consistency ({{service-mode}}), listed keys MUST also 1015 | appear in the SvcParams. 1016 | 1017 | To enable simpler parsing, this 1018 | SvcParamValue MUST NOT contain escape sequences. 1019 | 1020 | For example, the following is a valid list of SvcParams: 1021 | 1022 | ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint 1023 | 1024 | In wire format, the keys are represented by their numeric values in 1025 | network byte order, concatenated in strictly increasing numeric order. 1026 | 1027 | This SvcParamKey is always automatically mandatory, and MUST NOT appear in its 1028 | own value-list. Other automatically mandatory keys SHOULD NOT appear in the 1029 | list either. (Including them wastes space and otherwise has no effect.) 1030 | 1031 | # Using Service Bindings with HTTP {#https} 1032 | 1033 | Use of any protocol with SVCB requires a protocol-specific mapping 1034 | specification. This section specifies the mapping for the "http" and "https" 1035 | URI schemes {{!HTTP}}. 1036 | 1037 | To enable special handling for HTTP use-cases, 1038 | the HTTPS RR type is defined as a SVCB-compatible RR type, 1039 | specific to the "https" and "http" schemes. Clients MUST NOT 1040 | perform SVCB queries or accept SVCB responses for "https" 1041 | or "http" schemes. 1042 | 1043 | The presentation format of the record is: 1044 | 1045 | Name TTL IN HTTPS SvcPriority TargetName SvcParams 1046 | 1047 | All the SvcParamKeys defined in {{keys}} are permitted for use in 1048 | HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1". 1049 | The "automatically mandatory" keys ({{mandatory}}) are "port" 1050 | and "no-default-alpn". (As described in {{mandatory}}, clients must 1051 | either implement these keys or ignore any RR in which they appear.) 1052 | Clients that restrict the destination port in "https" URIs 1053 | (e.g. using the "bad ports" list from {{FETCH}}) SHOULD apply the 1054 | same restriction to the "port" SvcParam. 1055 | 1056 | The presence of an HTTPS RR for an origin also indicates 1057 | that clients should connect securely and use the "https" scheme, as 1058 | discussed in {{hsts}}. This allows HTTPS RRs to apply to 1059 | pre-existing "http" scheme URLs, while ensuring that the client uses a 1060 | secure and authenticated connection. 1061 | 1062 | The HTTPS RR parallels the concepts 1063 | introduced in the HTTP Alternative Services proposed standard 1064 | {{AltSvc}}. Clients and servers that implement HTTPS RRs are 1065 | not required to implement Alt-Svc. 1066 | 1067 | ## Query names for HTTPS RRs {#httpsnames} 1068 | 1069 | The HTTPS RR uses Port Prefix Naming ({{svcb-names}}), 1070 | with one modification: if the scheme is "https" and the port is 443, 1071 | then the client's original QNAME is 1072 | equal to the service name (i.e. the origin's hostname), 1073 | without any prefix labels. 1074 | 1075 | By removing the Attrleaf labels {{Attrleaf}} 1076 | used in SVCB, this construction enables offline DNSSEC signing of 1077 | wildcard domains, which are commonly used with HTTP. Using the 1078 | service name as the owner name of the HTTPS record, without prefixes, 1079 | also allows the targets of existing CNAME chains 1080 | (e.g. CDN hosts) to start returning HTTPS RR responses without 1081 | requiring origin domains to configure and maintain an additional 1082 | delegation. 1083 | 1084 | Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB. 1085 | 1086 | Clients always convert "http" URLs to "https" before performing an 1087 | HTTPS RR query using the process described in {{hsts}}, so domain owners 1088 | MUST NOT publish HTTPS RRs with a prefix of "_http". 1089 | 1090 | Note that none of these forms alter the HTTPS origin or authority. 1091 | For example, clients MUST continue to validate TLS certificate 1092 | hostnames based on the origin. 1093 | 1094 | ## Comparison with Alt-Svc 1095 | 1096 | Publishing a ServiceMode HTTPS RR in DNS is intended 1097 | to be similar to transmitting an Alt-Svc field value over 1098 | HTTP, and receiving an HTTPS RR is intended to be similar to 1099 | receiving that field value over HTTP. However, there are some 1100 | differences in the intended client and server behavior. 1101 | 1102 | ### ALPN usage 1103 | 1104 | Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs. The 1105 | meaning and use of these IDs is discussed in {{use}}. 1106 | 1107 | ### Untrusted channel 1108 | 1109 | HTTPS records do not require or provide any assurance of authenticity. (DNSSEC 1110 | signing and verification, which would provide such assurance, are OPTIONAL.) 1111 | The DNS resolution process is modeled as an untrusted channel that might be 1112 | controlled by an attacker, so 1113 | Alt-Svc parameters that cannot be safely received in this model MUST NOT 1114 | have a corresponding defined SvcParamKey. For example, there is no 1115 | SvcParamKey corresponding to the Alt-Svc "persist" parameter, because 1116 | this parameter is not safe to accept over an untrusted channel. 1117 | 1118 | ### Cache lifetime 1119 | 1120 | There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) parameter. 1121 | Instead, server operators encode the expiration time in the DNS TTL. 1122 | 1123 | The appropriate TTL value might be different from the "ma" value 1124 | used for Alt-Svc, depending on the desired efficiency and 1125 | agility. Some DNS caches incorrectly extend the lifetime of DNS 1126 | records beyond the stated TTL, so server operators cannot rely on 1127 | HTTPS RRs expiring on time. Shortening the TTL to compensate 1128 | for incorrect caching is NOT RECOMMENDED, as this practice impairs the 1129 | performance of correctly functioning caches and does not guarantee 1130 | faster expiration from incorrect caches. Instead, server operators 1131 | SHOULD maintain compatibility with expired records until they observe 1132 | that nearly all connections have migrated to the new configuration. 1133 | 1134 | ### Granularity 1135 | 1136 | Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1137 | Field Value specifically to the client. When using an HTTPS RR, 1138 | groups of clients will necessarily receive the same SvcParams. 1139 | Therefore, HTTPS RRs are not suitable for uses that require 1140 | single-client granularity. 1141 | 1142 | ## Interaction with Alt-Svc 1143 | 1144 | Clients that implement support for both Alt-Svc and HTTPS records and 1145 | are making a connection based on a cached Alt-Svc response SHOULD 1146 | retrieve any HTTPS records for the Alt-Svc alt-authority, and ensure that 1147 | their connection attempts are consistent with both the Alt-Svc parameters 1148 | and any received HTTPS SvcParams. If present, the HTTPS record's TargetName 1149 | and port are used for connection establishment (as in {{client-behavior}}). 1150 | For example, suppose that 1151 | "https://example.com" sends an Alt-Svc field value of: 1152 | 1153 | ~~~ HTTP 1154 | Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443" 1155 | ~~~ 1156 | 1157 | The client would retrieve the following HTTPS records: 1158 | 1159 | alt.example. IN HTTPS 1 . alpn=h2,h3 foo=... 1160 | alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 foo=... 1161 | _8443._https.example.com. IN HTTPS 1 alt3.example. ( 1162 | port=9443 alpn=h2,h3 foo=... ) 1163 | 1164 | Based on these inputs, the following connection attempts would always be 1165 | allowed: 1166 | 1167 | * HTTP/2 to `alt.example:443` 1168 | * HTTP/3 to `alt3.example:9443` 1169 | * Fallback to the client's non-Alt-Svc connection behavior 1170 | 1171 | The following connection attempts would not be allowed: 1172 | 1173 | * HTTP/3 to `alt.example:443` (not consistent with Alt-Svc) 1174 | * Any connection to `alt2b.example` (no ALPN consistent with both the HTTPS 1175 | record and Alt-Svc) 1176 | * HTTPS over TCP to any port on `alt3.example` (not consistent with Alt-Svc) 1177 | 1178 | Suppose that "foo" is a SvcParamKey that renders the client SVCB-reliant. 1179 | The following Alt-Svc-only connection attempts would be allowed only if 1180 | the client does not support "foo", as they rely on SVCB-optional fallback 1181 | behavior: 1182 | 1183 | * HTTP/2 to `alt2.example:443` 1184 | * HTTP/3 to `example.com:8443` 1185 | 1186 | Alt-authorities SHOULD carry the same SvcParams as the origin unless 1187 | a deviation is specifically known to be safe. 1188 | As noted in {{Section 2.4 of AltSvc}}, clients MAY disallow any Alt-Svc 1189 | connection according to their own criteria, e.g. disallowing Alt-Svc 1190 | connections that lack support for privacy features that are available on 1191 | the origin endpoint. 1192 | 1193 | ## Requiring Server Name Indication 1194 | 1195 | Clients MUST NOT use an HTTPS RR response unless the 1196 | client supports TLS Server Name Indication (SNI) and 1197 | indicates the origin name in the TLS ClientHello (which might be 1198 | encrypted via a future specification such as ECH). 1199 | This supports the conservation of IP addresses. 1200 | 1201 | Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicate 1202 | the origin, not the TargetName. 1203 | 1204 | ## HTTP Strict Transport Security {#hsts} 1205 | 1206 | An HTTPS RR directs the client to communicate with this host only over a 1207 | secure transport, similar to HTTP Strict Transport Security {{HSTS}}. 1208 | Prior to making an "http" scheme request, the client SHOULD perform a lookup 1209 | to determine if any HTTPS RRs exist for that origin. To do so, 1210 | the client SHOULD construct a corresponding "https" URL as follows: 1211 | 1212 | 1. Replace the "http" scheme with "https". 1213 | 1214 | 2. If the "http" URL explicitly specifies port 80, specify port 443. 1215 | 1216 | 3. Do not alter any other aspect of the URL. 1217 | 1218 | This construction is equivalent to {{Section 8.3 of HSTS}}, point 5. 1219 | 1220 | If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRs, 1221 | or any compatible ServiceMode HTTPS RRs (see {{mandatory}}), the client 1222 | SHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status code 1223 | with this "https" URL in the "Location" field. (Receipt of an incompatible ServiceMode RR does not 1224 | trigger the redirect behavior.) 1225 | Because HTTPS RRs are received over an often-insecure channel (DNS), 1226 | clients MUST NOT place any more trust in this signal than if they 1227 | had received a 307 (Temporary Redirect) response over cleartext HTTP. 1228 | 1229 | Publishing an HTTPS RR has the potential to have unexpected results 1230 | or a loss in functionality in cases where the "http" resource neither 1231 | redirects to the "https" resource nor references the same underlying resource. 1232 | 1233 | When an "https" connection fails due to an error in the underlying secure 1234 | transport, such as an error in certificate validation, some clients 1235 | currently offer a "user recourse" that allows the user to bypass the 1236 | security error and connect anyway. 1237 | When making an "https" scheme request to an origin with an HTTPS RR, 1238 | either directly or via the above redirect, such a client MAY remove the user 1239 | recourse option. Origins that publish HTTPS RRs therefore MUST NOT rely 1240 | on user recourse for access. For more information, see {{Section 8.4 and 1241 | Section 12.1 of HSTS}}. 1242 | 1243 | ## Use of HTTPS RRs in other protocols 1244 | 1245 | All HTTP connections to named origins are eligible to use HTTPS RRs, even 1246 | when HTTP is used as part of another protocol or without an explicit HTTP 1247 | URL. For example, clients that 1248 | support HTTPS RRs and implement the altered WebSocket {{!WebSocket=RFC6455}} 1249 | opening handshake from the W3C Fetch specification {{FETCH}} SHOULD use HTTPS RRs 1250 | for the `requestURL`. 1251 | 1252 | When HTTP is used in a context where URLs or redirects are not applicable 1253 | (e.g. connections to an HTTP proxy), clients that find a corresponding HTTPS RR 1254 | SHOULD implement a security upgrade behavior equivalent to the one specified in 1255 | {{hsts}}. 1256 | 1257 | Such protocols MAY define their own SVCB mappings, which MAY 1258 | be defined to take precedence over HTTPS RRs. 1259 | 1260 | # Zone Structures 1261 | 1262 | ## Structuring zones for flexibility 1263 | 1264 | Each ServiceMode RRSet can only serve a single scheme. The scheme is indicated 1265 | by the owner name and the RR type. For the generic SVCB RR type, this means that 1266 | each owner name can only be used for a single scheme. The underscore prefixing 1267 | requirement ({{svcb-names}}) ensures that this is true for the initial query, 1268 | but it is the responsibility of zone owners to choose names that satisfy this 1269 | constraint when using aliases, including CNAME and AliasMode records. 1270 | 1271 | When using the generic SVCB RR type with aliasing, zone owners SHOULD choose alias 1272 | target names that indicate the scheme in use (e.g. `foosvc.example.net` for 1273 | `foo://` schemes). This will help to avoid confusion when another scheme needs to 1274 | be added to the configuration. When multiple port numbers are in use, it may be 1275 | helpful to repeat the prefix labels in the alias target name (e.g. 1276 | `_1234._foo.svc.example.net`). 1277 | 1278 | ## Structuring zones for performance {#zone-performance} 1279 | 1280 | To avoid a delay for clients using a nonconforming recursive resolver, 1281 | domain owners SHOULD minimize the use of AliasMode records, and SHOULD 1282 | choose TargetName according to a predictable convention that is known 1283 | to the client, so that clients can issue A and/or AAAA queries for TargetName 1284 | in advance (see {{optimizations}}). Unless otherwise specified, the 1285 | convention is to set TargetName to the service name for an initial 1286 | ServiceMode record, or to "." if it is reached via an alias. 1287 | 1288 | $ORIGIN example.com. ; Origin 1289 | foo 3600 IN CNAME foosvc.example.net. 1290 | _8080._foo.foo 3600 IN CNAME foosvc.example.net. 1291 | bar 300 IN AAAA 2001:db8::2 1292 | _9090._bar.bar 3600 IN SVCB 1 bar key65444=... 1293 | 1294 | $ORIGIN example.net. ; Service provider zone 1295 | foosvc 3600 IN SVCB 1 . key65333=... 1296 | foosvc 300 IN AAAA 2001:db8::1 1297 | {: title="foo://foo.example.com:8080 is delegated to foosvc.example.net, but bar://bar.example.com:9090 is served locally."} 1298 | 1299 | Domain owners SHOULD avoid using a TargetName that is below a DNAME, as 1300 | this is likely unnecessary and makes responses slower and larger. 1301 | Also, zone structures that require following more than 8 aliases 1302 | (counting both AliasMode and CNAME records) are NOT RECOMMENDED. 1303 | 1304 | ## Operational considerations 1305 | 1306 | Note that some implementations may not allow A or AAAA records on names 1307 | starting with an underscore due to various interpretations of RFCs. 1308 | This could be an operational issue when the TargetName contains an attrleaf label, 1309 | as well as using an TargetName of "." when the owner name contains an attrleaf label. 1310 | 1311 | ## Examples 1312 | 1313 | ### Protocol enhancements 1314 | 1315 | Consider a simple zone of the form: 1316 | 1317 | $ORIGIN simple.example. ; Simple example zone 1318 | @ 300 IN A 192.0.2.1 1319 | AAAA 2001:db8::1 1320 | 1321 | The domain owner could add this record: 1322 | 1323 | @ 7200 IN HTTPS 1 . alpn=h3 1324 | 1325 | to indicate that https://simple.example supports QUIC 1326 | in addition to HTTP/1.1 over TLS over TCP (the implicit default). 1327 | The record could also include other information (e.g. non-standard port). 1328 | For https://simple.example:8443, the record would be: 1329 | 1330 | _8443._https 7200 IN HTTPS 1 . alpn=h3 1331 | 1332 | These records also respectively tell clients to replace the scheme with "https" when 1333 | loading http://simple.example or http://simple.example:8443. 1334 | 1335 | ### Apex aliasing 1336 | 1337 | Consider a zone that is using CNAME aliasing: 1338 | 1339 | $ORIGIN aliased.example. ; A zone that is using a hosting service 1340 | ; Subdomain aliased to a high-performance server pool 1341 | www 7200 IN CNAME pool.svc.example. 1342 | ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1343 | @ 300 IN A 192.0.2.1 1344 | IN AAAA 2001:db8::1 1345 | 1346 | With HTTPS RRs, the owner of aliased.example could alias the apex by 1347 | adding one additional record: 1348 | 1349 | @ 7200 IN HTTPS 0 pool.svc.example. 1350 | 1351 | With this record in place, HTTPS-RR-aware clients will use the same 1352 | server pool for aliased.example and www.aliased.example. (They will 1353 | also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR-aware 1354 | clients will just ignore the new record. 1355 | 1356 | Similar to CNAME, HTTPS RRs have no impact on the origin name. 1357 | When connecting, clients will continue to treat the authoritative 1358 | origins as "https://www.aliased.example" and "https://aliased.example", 1359 | respectively, and will validate TLS server certificates accordingly. 1360 | 1361 | ### Parameter binding 1362 | 1363 | Suppose that svc.example's primary server pool supports HTTP/3, but its 1364 | backup server pool does not. This can be expressed in the following form: 1365 | 1366 | $ORIGIN svc.example. ; A hosting provider. 1367 | pool 7200 IN HTTPS 1 . alpn=h2,h3 1368 | HTTPS 2 backup alpn=h2 port=8443 1369 | pool 300 IN A 192.0.2.2 1370 | AAAA 2001:db8::2 1371 | backup 300 IN A 192.0.2.3 1372 | AAAA 2001:db8::3 1373 | 1374 | This configuration is entirely compatible with the "Apex aliasing" example, 1375 | whether the client supports HTTPS RRs or not. If the client does support 1376 | HTTPS RRs, all connections will be upgraded to HTTPS, and clients will 1377 | use HTTP/3 if they can. Parameters are "bound" to each server pool, so 1378 | each server pool can have its own protocol, port number, etc. 1379 | 1380 | ### Multi-CDN {#multicdn} 1381 | 1382 | The HTTPS RR is intended to support HTTPS services operated by 1383 | multiple independent entities, such as different Content Delivery 1384 | Networks (CDNs) or different hosting providers. This includes 1385 | the case where a service is migrated from one operator to another, 1386 | as well as the case where the service is multiplexed between 1387 | multiple operators for performance, redundancy, etc. 1388 | 1389 | This example shows such a configuration, with www.customer.example 1390 | having different DNS responses to different queries, either over time 1391 | or due to logic within the authoritative DNS server: 1392 | 1393 | ; This zone contains/returns different CNAME records 1394 | ; at different points-in-time. The RRset for "www" can 1395 | ; only ever contain a single CNAME. 1396 | 1397 | ; Sometimes the zone has: 1398 | $ORIGIN customer.example. ; A Multi-CDN customer domain 1399 | www 900 IN CNAME cdn1.svc1.example. 1400 | 1401 | ; and other times it contains: 1402 | $ORIGIN customer.example. 1403 | www 900 IN CNAME customer.svc2.example. 1404 | 1405 | ; and yet other times it contains: 1406 | $ORIGIN customer.example. 1407 | www 900 IN CNAME cdn3.svc3.example. 1408 | 1409 | ; With the following remaining constant and always included: 1410 | $ORIGIN customer.example. ; A Multi-CDN customer domain 1411 | ; The apex is also aliased to www to match its configuration 1412 | @ 7200 IN HTTPS 0 www 1413 | ; Non-HTTPS-aware clients use non-CDN IPs 1414 | A 203.0.113.82 1415 | AAAA 2001:db8:203::2 1416 | 1417 | ; Resolutions following the cdn1.svc1.example 1418 | ; path use these records. 1419 | ; This CDN uses a different alternative service for HTTP/3. 1420 | $ORIGIN svc1.example. ; domain for CDN 1 1421 | cdn1 1800 IN HTTPS 1 h3pool alpn=h3 1422 | HTTPS 2 . alpn=h2 1423 | A 192.0.2.2 1424 | AAAA 2001:db8:192::4 1425 | h3pool 300 IN A 192.0.2.3 1426 | AAAA 2001:db8:192:7::3 1427 | 1428 | ; Resolutions following the customer.svc2.example 1429 | ; path use these records. 1430 | ; Note that this CDN only supports HTTP/2. 1431 | $ORIGIN svc2.example. ; domain operated by CDN 2 1432 | customer 300 IN HTTPS 1 . alpn=h2 1433 | 60 IN A 198.51.100.2 1434 | A 198.51.100.3 1435 | A 198.51.100.4 1436 | AAAA 2001:db8:198::7 1437 | AAAA 2001:db8:198::12 1438 | 1439 | ; Resolutions following the cdn3.svc3.example 1440 | ; path use these records. 1441 | ; Note that this CDN has no HTTPS records. 1442 | $ORIGIN svc3.example. ; domain operated by CDN 3 1443 | cdn3 60 IN A 203.0.113.8 1444 | AAAA 2001:db8:113::8 1445 | 1446 | Note that in the above example, the different CDNs have different 1447 | configurations and different capabilities, but clients will use HTTPS RRs 1448 | as a bound-together unit. 1449 | 1450 | Domain owners should be cautious when using a multi-CDN configuration, as it 1451 | introduces a number of complexities highlighted by this example: 1452 | 1453 | * If CDN 1 supports a desired protocol or feature, and CDN 2 does not, the 1454 | client is vulnerable to 1455 | downgrade by a network adversary who forces clients to get CDN 2 records. 1456 | 1457 | * Aliasing the apex to its subdomain simplifies the zone file but likely 1458 | increases resolution latency, especially when using a non-HTTPS-aware 1459 | recursive resolver. An alternative would be to alias the zone 1460 | apex directly to a name managed by a CDN. 1461 | 1462 | * The A, AAAA, and HTTPS resolutions are independent lookups, so resolvers may 1463 | observe and follow different CNAMEs to different CDNs. 1464 | Clients may thus find that the A and AAAA responses do not correspond to the 1465 | TargetName in the HTTPS response, and will need to perform additional 1466 | queries to retrieve the correct IP addresses. 1467 | Including ipv6hint and ipv4hint will reduce the performance 1468 | impact of this case. 1469 | 1470 | * If not all CDNs publish HTTPS records, clients will sometimes 1471 | receive NODATA for HTTPS queries (as with cdn3.svc3.example above), 1472 | but could receive A/AAAA records from a different CDN. Clients will 1473 | attempt to connect to this CDN without the benefit of its HTTPS 1474 | records. 1475 | 1476 | ### Non-HTTP uses 1477 | 1478 | For protocols other than HTTP, the SVCB RR and an Attrleaf label {{Attrleaf}} 1479 | will be used. For example, to reach an example resource of 1480 | "baz://api.example.com:8765", the following SVCB 1481 | record would be used to alias it to "svc4-baz.example.net." 1482 | which in-turn could return AAAA/A records and/or SVCB 1483 | records in ServiceMode: 1484 | 1485 | _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1486 | 1487 | HTTPS RRs use similar Attrleaf labels if the origin contains 1488 | a non-default port. 1489 | 1490 | # Interaction with other standards {#other-standards} 1491 | 1492 | This standard is intended to reduce connection latency and 1493 | improve user privacy. Server operators implementing this standard 1494 | SHOULD also implement TLS 1.3 {{!RFC8446}} and OCSP Stapling 1495 | {{!RFC6066}}, both of which confer substantial performance and privacy 1496 | benefits when used in combination with SVCB records. 1497 | 1498 | To realize the greatest privacy benefits, this proposal is intended for 1499 | use over a privacy-preserving DNS transport (like DNS over TLS 1500 | {{DoT}} or DNS over HTTPS {{DoH}}). 1501 | However, performance improvements, and some modest privacy improvements, 1502 | are possible without the use of those standards. 1503 | 1504 | Any specification for use of SVCB with a protocol MUST have an entry for its 1505 | scheme under the SVCB RR type in the IANA DNS Underscore Global Scoped Entry 1506 | Registry {{Attrleaf}}. The scheme MUST have an entry in the IANA URI Schemes 1507 | Registry {{!RFC7595}}, and MUST have a defined specification for use 1508 | with SVCB. 1509 | 1510 | 1511 | 1512 | # Security Considerations 1513 | 1514 | SVCB/HTTPS RRs permit distribution over untrusted 1515 | channels, and clients are REQUIRED to verify that the alternative endpoint 1516 | is authoritative for the service (similar to {{Section 2.1 of AltSvc}}). 1517 | Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1518 | and using SVCB and HTTPS RRs. 1519 | 1520 | Clients MUST ensure that their DNS cache is partitioned for each local 1521 | network, or flushed on network changes, to prevent a local adversary in one 1522 | network from implanting a forged DNS record that allows them to 1523 | track users or hinder their connections after they leave that network. 1524 | 1525 | An attacker who can prevent SVCB resolution can deny clients any associated 1526 | security benefits. A hostile recursive resolver can always deny service to 1527 | SVCB queries, but network intermediaries can often prevent resolution as well, 1528 | even when the client and recursive resolver validate DNSSEC and use a secure 1529 | transport. These downgrade attacks can prevent the "https" upgrade provided by 1530 | the HTTPS RR ({{hsts}}), and disable any other protections coordinated via 1531 | SvcParams. To prevent downgrades, {{client-failures}} 1532 | recommends that clients abandon the connection attempt when such an attack is 1533 | detected. 1534 | 1535 | A hostile DNS intermediary might forge AliasMode "." records ({{aliasdot}}) as 1536 | a way to block clients from accessing particular services. Such an adversary 1537 | could already block entire domains by forging erroneous responses, but this 1538 | mechanism allows them to target particular protocols or ports within a domain. 1539 | Clients that might be subject to such attacks SHOULD ignore AliasMode "." 1540 | records. 1541 | 1542 | A hostile DNS intermediary or origin can return SVCB records indicating any IP 1543 | address and port number, including IP addresses inside the local network and 1544 | port numbers assigned to internal services. If the attacker can influence the 1545 | client's payload (e.g. TLS session ticket contents), and an internal service 1546 | has a sufficiently lax parser, it's possible that the attacker could gain 1547 | unintended access. (The same concerns apply to SRV records, HTTP Alt-Svc, 1548 | and HTTP redirects.) As a mitigation, SVCB mapping documents SHOULD indicate 1549 | any port number restrictions that are appropriate for the supported transports. 1550 | 1551 | # Privacy Considerations 1552 | 1553 | Standard address queries reveal the user's intent to access a particular 1554 | domain. This information is visible to the recursive resolver, and to 1555 | many other parties when plaintext DNS transport is used. SVCB queries, 1556 | like queries for SRV records and other specific RR types, additionally 1557 | reveal the user's intent to use a particular protocol. This is not 1558 | normally sensitive information, but it should be considered when adding 1559 | SVCB support in a new context. 1560 | 1561 | # IANA Considerations 1562 | 1563 | ## SVCB RRType 1564 | 1565 | This document defines a new DNS RR type, SVCB, whose value 64 has 1566 | been allocated by IANA from the "Resource Record (RR) TYPEs" 1567 | registry on the "Domain Name System (DNS) Parameters" page: 1568 | 1569 | * Type: SVCB 1570 | * Value: 64 1571 | * Meaning: General Purpose Service Binding 1572 | * Reference: This document 1573 | 1574 | ## HTTPS RRType 1575 | 1576 | This document defines a new DNS RR type, "HTTPS", whose value 65 has 1577 | been allocated by IANA from the "Resource Record (RR) TYPEs" 1578 | registry on the "Domain Name System (DNS) Parameters" page: 1579 | 1580 | * Type: HTTPS 1581 | * Value: 65 1582 | * Meaning: Service Binding type for use with HTTP 1583 | * Reference: This document 1584 | 1585 | ## New registry for Service Parameters {#svcparamregistry} 1586 | 1587 | IANA is requested to create a new registry, entitled 1588 | "Service Parameter Keys (SvcParamKeys)". This registry defines the namespace 1589 | for parameters, including string representations and numeric 1590 | SvcParamKey values. This registry is shared with other SVCB-compatible 1591 | RR types, such as the HTTPS RR. 1592 | 1593 | ACTION: create this registry, on a new page entitled 1594 | "DNS Service Bindings (SVCB)" under the "Domain Name System (DNS) Parameters" 1595 | category. 1596 | 1597 | ### Procedure 1598 | 1599 | A registration MUST include the following fields: 1600 | 1601 | * Number: wire format numeric identifier (range 0-65535) 1602 | * Name: unique presentation name 1603 | * Meaning: a short description 1604 | * Format Reference: pointer to specification text 1605 | * Change Controller: Person or entity, with contact information if appropriate. 1606 | 1607 | The characters in the registered Name MUST be lower-case alphanumeric or "-" 1608 | ({{presentation}}). The name MUST NOT start with "key" or "invalid". 1609 | 1610 | New entries in this registry are subject to an Expert Review registration 1611 | policy ({{!RFC8126, Section 4.5}}). The designated expert MUST ensure that 1612 | the Format Reference is stable and publicly available, and that it specifies 1613 | how to convert the SvcParamValue's presentation format to wire format. The 1614 | Format Reference MAY be any individual's Internet-Draft, or a document from 1615 | any other source with similar assurances of stability and availability. 1616 | An entry MAY specify a Format Reference of 1617 | the form "Same as (other key Name)" if it uses the same presentation and wire 1618 | formats as an existing key. 1619 | 1620 | This arrangement supports the development of new parameters while ensuring that 1621 | zone files can be made interoperable. 1622 | 1623 | ### Initial contents {#iana-keys} 1624 | 1625 | The "Service Binding (SVCB) Parameter Registry" shall initially 1626 | be populated with the registrations below: 1627 | 1628 | | Number | Name | Meaning | Format Reference | Change Controller | 1629 | | ----------- | ------ | ---------------------- | ---------------------------------------- | ----------------- | 1630 | | 0 | mandatory | Mandatory keys in this RR | (This document) {{mandatory}} | IETF | 1631 | | 1 | alpn | Additional supported protocols | (This document) {{alpn-key}} | IETF | 1632 | | 2 | no-default-alpn | No support for default protocol | (This document) {{alpn-key}} | IETF | 1633 | | 3 | port | Port for alternative endpoint | (This document) {{svcparamkeys-port}} | IETF | 1634 | | 4 | ipv4hint | IPv4 address hints | (This document) {{svcparamkeys-iphints}} | IETF | 1635 | | 5 | ech | RESERVED (will be used for ECH) | N/A | IETF | 1636 | | 6 | ipv6hint | IPv6 address hints | (This document) {{svcparamkeys-iphints}} | IETF | 1637 | | 65280-65534 | N/A | Private Use | (This document) | IETF | 1638 | | 65535 | N/A | Reserved ("Invalid key") | (This document) | IETF | 1639 | 1640 | ## Other registry updates 1641 | 1642 | Per {{Attrleaf}}, please add the following entry to the DNS Underscore 1643 | Global Scoped Entry Registry: 1644 | 1645 | | RR TYPE | _NODE NAME | Meaning | Reference | 1646 | | --------- | ---------- | ----------------- | --------------- | 1647 | | HTTPS | _https | HTTPS SVCB info | (This document) | 1648 | 1649 | 1650 | # Acknowledgments and Related Proposals 1651 | 1652 | There have been a wide range of proposed solutions over the years to 1653 | the "CNAME at the Zone Apex" challenge proposed. These include 1654 | {{?I-D.bellis-dnsop-http-record}}, 1655 | {{?I-D.ietf-dnsop-aname}}, and others. 1656 | 1657 | Thank you to Ian Swett, Ralf Weber, Jon Reed, 1658 | Martin Thomson, Lucas Pardue, Ilari Liusvaara, 1659 | Tim Wicinski, Tommy Pauly, Chris Wood, David Benjamin, 1660 | Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, 1661 | Craig Taylor, Dan McArdle, Brian Dickson, 1662 | Willem Toorop, Pieter Lexis, Puneet Sood, 1663 | Olivier Poitrey, Mashooq Muhaimen, 1664 | Tom Carpay, and many others for their feedback 1665 | and suggestions on this draft. 1666 | 1667 | 1668 | --- back 1669 | 1670 | # Decoding text in zone files {#decoding} 1671 | 1672 | DNS zone files are capable of representing arbitrary octet sequences in 1673 | basic ASCII text, using various delimiters and encodings. The algorithm 1674 | for decoding these character-strings is defined in {{Section 5.1 of RFC1035}}. 1675 | Here we summarize the allowed input to that algorithm, using ABNF: 1676 | 1677 | ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 1678 | non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 1679 | ; non-digit is VCHAR minus DIGIT 1680 | non-digit = %x21-2F / %x3A-7E 1681 | ; dec-octet is a number 0-255 as a three-digit decimal number. 1682 | dec-octet = ( "0" / "1" ) 2DIGIT / 1683 | "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 1684 | escaped = "\" ( non-digit / dec-octet ) 1685 | contiguous = 1*( non-special / escaped ) 1686 | quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 1687 | char-string = contiguous / quoted 1688 | 1689 | The decoding algorithm allows `char-string` to represent any `*OCTET`, 1690 | using quoting to group values (e.g., those with internal whitespace), and 1691 | escaping to represent each non-printable octet as a single `escaped` sequence. 1692 | In this document, this algorithm is referred to as "character-string decoding". 1693 | The algorithm is the same as used by `` in RFC 1035, 1694 | although the output length in this document is not limited to 255 octets. 1695 | 1696 | ## Decoding a comma-separated list {#value-list} 1697 | 1698 | In order to represent lists of items in zone files, this specification uses 1699 | comma-separated lists. When the allowed items in the list cannot contain "," 1700 | or "\\", this is trivial. (For simplicity, empty items are not allowed.) 1701 | A value-list parser that splits on "," and prohibits items containing "\\" 1702 | is sufficient to comply with all requirements in this document. This 1703 | corresponds to the `simple-comma-separated` syntax: 1704 | 1705 | ; item-allowed is OCTET minus "," and "\". 1706 | item-allowed = %x00-2B / %x2D-5B / %x5D-FF 1707 | simple-item = 1*item-allowed 1708 | simple-comma-separated = [simple-item *("," simple-item)] 1709 | 1710 | For implementations that allow "," and "\\" in item values, the following 1711 | escaping syntax applies: 1712 | 1713 | item = 1*OCTET 1714 | escaped-item = 1*(item-allowed / "\," / "\\") 1715 | comma-separated = [escaped-item *("," escaped-item)] 1716 | 1717 | Decoding of value-lists happens after character-string decoding. 1718 | For example, consider these `char-string` SvcParamValues: 1719 | 1720 | "part1,part2,part3\\,part4\\\\" 1721 | part1\,\p\a\r\t2\044part3\092,part4\092\\ 1722 | 1723 | These inputs are equivalent: character-string decoding either of them would 1724 | produce the same `value`: 1725 | 1726 | part1,part2,part3\,part4\\ 1727 | 1728 | Applying comma-separated list decoding to this `value` would produce a list 1729 | of three `item`s: 1730 | 1731 | part1 1732 | part2 1733 | part3,part4\ 1734 | 1735 | # HTTP Mapping Summary 1736 | 1737 | This table serves as a non-normative summary of the HTTP mapping for SVCB 1738 | ({{https}}). Future protocol mappings may provide a similar summary table. 1739 | 1740 | | | | 1741 | | ---------------------------------------- | ---------------------------------------- | 1742 | | **Mapped scheme** | "https" | 1743 | | **Other affected schemes** | "http", "wss", "ws", (other HTTP-based) | 1744 | | **RR type** | HTTPS (65) | 1745 | | **Name prefix** | None for port 443, else `_$PORT._https` | 1746 | | **Automatically Mandatory Keys** | `port`, `no-default-alpn` | 1747 | | **SvcParam defaults** | `alpn`: \["http/1.1"\] | 1748 | | **Special behaviors** | HTTP to HTTPS upgrade | 1749 | | **Keys that records must include** | None | 1750 | 1751 | # Comparison with alternatives 1752 | 1753 | The SVCB and HTTPS RR types closely resemble, 1754 | and are inspired by, some existing 1755 | record types and proposals. A complaint with all of the alternatives 1756 | is that web clients have seemed unenthusiastic about implementing 1757 | them. The hope here is that by providing an extensible solution that 1758 | solves multiple problems we will overcome the inertia and have a path 1759 | to achieve client implementation. 1760 | 1761 | ## Differences from the SRV RR type 1762 | 1763 | An SRV record {{SRV}} can perform a similar function to the SVCB record, 1764 | informing a client to look in a different location for a service. 1765 | However, there are several differences: 1766 | 1767 | * SRV records are typically mandatory, whereas SVCB is intended to be optional 1768 | when used with pre-existing protocols. 1769 | * SRV records cannot instruct the client to switch or upgrade 1770 | protocols, whereas SVCB can signal such an upgrade (e.g. to 1771 | HTTP/2). 1772 | * SRV records are not extensible, whereas SVCB and HTTPS RRs 1773 | can be extended with new parameters. 1774 | * SRV records specify a "weight" for unbalanced randomized load-balancing. 1775 | SVCB only supports balanced randomized load-balancing, although weights 1776 | could be added via a future SvcParam. 1777 | 1778 | ## Differences from the proposed HTTP record 1779 | 1780 | Unlike {{?I-D.bellis-dnsop-http-record}}, this approach is 1781 | extensible to cover Alt-Svc and Encrypted ClientHello use-cases. Like that 1782 | proposal, this addresses the zone apex CNAME challenge. 1783 | 1784 | Like that proposal, it remains necessary to continue to include 1785 | address records at the zone apex for legacy clients. 1786 | 1787 | 1788 | ## Differences from the proposed ANAME record 1789 | 1790 | Unlike {{?I-D.ietf-dnsop-aname}}, this approach is extensible to 1791 | cover Alt-Svc and ECH use-cases. This approach also does not 1792 | require any changes or special handling on either authoritative or 1793 | primary servers, beyond optionally returning in-bailiwick additional records. 1794 | 1795 | Like that proposal, this addresses the zone apex CNAME challenge 1796 | for clients that implement this. 1797 | 1798 | However, with this SVCB proposal, it remains necessary to continue 1799 | to include address records at the zone apex for legacy clients. 1800 | If deployment of this standard is successful, the number of legacy clients 1801 | will fall over time. As the number of legacy clients declines, the operational 1802 | effort required to serve these users without the benefit of SVCB indirection 1803 | should fall. Server operators can easily observe how much traffic reaches this 1804 | legacy endpoint, and may remove the apex's address records if the observed legacy 1805 | traffic has fallen to negligible levels. 1806 | 1807 | ## Comparison with separate RR types for AliasMode and ServiceMode 1808 | 1809 | Abstractly, functions of AliasMode and ServiceMode are independent, 1810 | so it might be tempting to specify them as separate RR types. However, 1811 | this would result in a serious performance impairment, because clients 1812 | cannot rely on their recursive resolver to follow SVCB aliases (unlike 1813 | CNAME). Thus, clients would have to issue queries for both RR types 1814 | in parallel, potentially at each step of the alias chain. Recursive 1815 | resolvers that implement the specification would, upon receipt of a 1816 | ServiceMode query, emit both a ServiceMode and an AliasMode query to 1817 | the authoritative. Thus, splitting the RR type would double, or in 1818 | some cases triple, the load on clients and servers, and would not 1819 | reduce implementation complexity. 1820 | 1821 | # Test vectors 1822 | These test vectors only contain the RDATA portion of SVCB/HTTPS records in 1823 | presentation format, generic format ({{!RFC3597}}) and wire format. The wire 1824 | format uses hexadecimal (\xNN) for each non-ascii byte. As the wireformat is 1825 | long, it is broken into several lines. 1826 | 1827 | ## AliasMode 1828 | 1829 | example.com. HTTPS 0 foo.example.com. 1830 | 1831 | \# 19 ( 1832 | 00 00 ; priority 1833 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 1834 | ) 1835 | 1836 | \x00\x00 # priority 1837 | \x03foo\x07example\x03com\x00 # target 1838 | {: title="AliasMode"} 1839 | 1840 | ## ServiceMode 1841 | 1842 | example.com. SVCB 1 . 1843 | 1844 | \# 3 ( 1845 | 00 01 ; priority 1846 | 00 ; target (root label) 1847 | ) 1848 | 1849 | \x00\x01 # priority 1850 | \x00 # target, root label 1851 | {: title="TargetName is \".\""} 1852 | 1853 | example.com. SVCB 16 foo.example.com. port=53 1854 | 1855 | \# 25 ( 1856 | 00 10 ; priority 1857 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 1858 | 00 03 ; key 3 1859 | 00 02 ; length 2 1860 | 00 35 ; value 1861 | ) 1862 | 1863 | \x00\x10 # priority 1864 | \x03foo\x07example\x03com\x00 # target 1865 | \x00\x03 # key 3 1866 | \x00\x02 # length: 2 bytes 1867 | \x00\x35 # value 1868 | {: title="Specifies a port"} 1869 | 1870 | example.com. SVCB 1 foo.example.com. key667=hello 1871 | 1872 | \# 28 ( 1873 | 00 01 ; priority 1874 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 1875 | 02 9b ; key 667 1876 | 00 05 ; length 5 1877 | 68 65 6c 6c 6f ; value 1878 | ) 1879 | 1880 | \x00\x01 # priority 1881 | \x03foo\x07example\x03com\x00 # target 1882 | \x02\x9b # key 667 1883 | \x00\x05 # length 5 1884 | hello # value 1885 | {: title="A generic key and unquoted value"} 1886 | 1887 | example.com. SVCB 1 foo.example.com. key667="hello\210qoo" 1888 | 1889 | \# 32 ( 1890 | 00 01 ; priority 1891 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 1892 | 02 9b ; key 667 1893 | 00 09 ; length 9 1894 | 68 65 6c 6c 6f d2 71 6f 6f ; value 1895 | ) 1896 | 1897 | \x00\x01 # priority 1898 | \x03foo\x07example\x03com\x00 # target 1899 | \x02\x9b # key 667 1900 | \x00\x09 # length 9 1901 | hello\xd2qoo # value 1902 | {: title="A generic key and quoted value with a decimal escape"} 1903 | 1904 | example.com. SVCB 1 foo.example.com. ( 1905 | ipv6hint="2001:db8::1,2001:db8::53:1" 1906 | ) 1907 | 1908 | \# 55 ( 1909 | 00 01 ; priority 1910 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 1911 | 00 06 ; key 6 1912 | 00 20 ; length 32 1913 | 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address 1914 | 20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01 ; second address 1915 | ) 1916 | 1917 | \x00\x01 # priority 1918 | \x03foo\x07example\x03com\x00 # target 1919 | \x00\x06 # key 6 1920 | \x00\x20 # length 32 1921 | \x20\x01\x0d\xb8\x00\x00\x00\x00 1922 | \x00\x00\x00\x00\x00\x00\x00\x01 # first address 1923 | \x20\x01\x0d\xb8\x00\x00\x00\x00 1924 | \x00\x00\x00\x00\x00\x53\x00\x01 # second address 1925 | {: title="Two quoted IPv6 hints"} 1926 | 1927 | example.com. SVCB 1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33" 1928 | 1929 | \# 35 ( 1930 | 00 01 ; priority 1931 | 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 1932 | 00 06 ; key 6 1933 | 00 10 ; length 16 1934 | 20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address 1935 | ) 1936 | 1937 | \x00\x01 # priority 1938 | \x07example\x03com\x00 # target 1939 | \x00\x06 # key 6 1940 | \x00\x10 # length 16 1941 | \x20\x01\x0d\xb8\x01\x22\x03\x44 1942 | \x00\x00\x00\x00\xc0\x00\x02\x21 # address 1943 | {: title="An IPv6 hint using the embedded IPv4 syntax"} 1944 | 1945 | example.com. SVCB 16 foo.example.org. ( 1946 | alpn=h2,h3-19 mandatory=ipv4hint,alpn 1947 | ipv4hint=192.0.2.1 1948 | ) 1949 | 1950 | \# 48 ( 1951 | 00 10 ; priority 1952 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 1953 | 00 00 ; key 0 1954 | 00 04 ; param length 4 1955 | 00 01 ; value: key 1 1956 | 00 04 ; value: key 4 1957 | 00 01 ; key 1 1958 | 00 09 ; param length 9 1959 | 02 ; alpn length 2 1960 | 68 32 ; alpn value 1961 | 05 ; alpn length 5 1962 | 68 33 2d 31 39 ; alpn value 1963 | 00 04 ; key 4 1964 | 00 04 ; param length 4 1965 | c0 00 02 01 ; param value 1966 | ) 1967 | 1968 | \x00\x10 # priority 1969 | \x03foo\x07example\x03org\x00 # target 1970 | \x00\x00 # key 0 1971 | \x00\x04 # param length 4 1972 | \x00\x01 # value: key 1 1973 | \x00\x04 # value: key 4 1974 | \x00\x01 # key 1 1975 | \x00\x09 # param length 9 1976 | \x02 # alpn length 2 1977 | h2 # alpn value 1978 | \x05 # alpn length 5 1979 | h3-19 # alpn value 1980 | \x00\x04 # key 4 1981 | \x00\x04 # param length 4 1982 | \xc0\x00\x02\x01 # param value 1983 | {: title="SvcParamKey ordering is arbitrary in presentation format but 1984 | sorted in wire format"} 1985 | 1986 | example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2" 1987 | example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2 1988 | 1989 | \# 35 ( 1990 | 00 10 ; priority 1991 | 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 1992 | 00 01 ; key 1 1993 | 00 0c ; param length 12 1994 | 08 ; alpn length 8 1995 | 66 5c 6f 6f 2c 62 61 72 ; alpn value 1996 | 02 ; alpn length 2 1997 | 68 32 ; alpn value 1998 | ) 1999 | 2000 | \x00\x10 # priority 2001 | \x03foo\x07example\x03org\x00 # target 2002 | \x00\x01 # key 1 2003 | \x00\x0c # param length 12 2004 | \x08 # alpn length 8 2005 | f\oo,bar # alpn value 2006 | \x02 # alpn length 2 2007 | h2 # alpn value 2008 | {: title="An alpn value with an escaped comma and an escaped 2009 | backslash in two presentation formats"} 2010 | 2011 | 2012 | ## Failure cases 2013 | 2014 | This subsection contains test vectors which are not 2015 | compliant with this document. The various reasons for non-compliance 2016 | are explained with each example. 2017 | 2018 | example.com. SVCB 1 foo.example.com. ( 2019 | key123=abc key123=def 2020 | ) 2021 | {: title="Multiple instances of the same SvcParamKey"} 2022 | 2023 | example.com. SVCB 1 foo.example.com. mandatory 2024 | example.com. SVCB 1 foo.example.com. alpn 2025 | example.com. SVCB 1 foo.example.com. port 2026 | example.com. SVCB 1 foo.example.com. ipv4hint 2027 | example.com. SVCB 1 foo.example.com. ipv6hint 2028 | {: title="Missing SvcParamValues that must be nonempty"} 2029 | 2030 | example.com. SVCB 1 foo.example.com. no-default-alpn=abc 2031 | {: title="The \"no-default-alpn\" SvcParamKey value must be empty"} 2032 | 2033 | example.com. SVCB 1 foo.example.com. mandatory=key123 2034 | {: title="A mandatory SvcParam is missing"} 2035 | 2036 | example.com. SVCB 1 foo.example.com. mandatory=mandatory 2037 | {: title="The \"mandatory\" SvcParamKey must not be included in the 2038 | mandatory list"} 2039 | 2040 | example.com. SVCB 1 foo.example.com. ( 2041 | mandatory=key123,key123 key123=abc 2042 | ) 2043 | {: title="Multiple instances of the same SvcParamKey in 2044 | the mandatory list"} 2045 | 2046 | # Change history 2047 | 2048 | (This section to be removed by the RFC editor.) 2049 | 2050 | * draft-ietf-dnsop-svcb-https-12 2051 | * Split out Encrypted Client Hello (ECH) to a separate draft 2052 | and convert all remaining references to informative. 2053 | 2054 | * draft-ietf-dnsop-svcb-https-11 2055 | * Narrow set of post-IESG clarifications: 2056 | * Clarify that that the fallback addition of the 2057 | QNAME was for the AliasMode case 2058 | * Note that some implementations may not allow A/AAAA 2059 | records on names starting with an underscore 2060 | 2061 | * draft-ietf-dnsop-svcb-https-10 2062 | * Clarify rationale for two recommendations 2063 | 2064 | * draft-ietf-dnsop-svcb-https-09 2065 | * Extensive adjustments based on IESG reviews, including: 2066 | * IANA registry changed to Expert Review policy 2067 | * Adjustments to the use of normative language 2068 | * Revised and expanded description of HSTS behavior 2069 | * Expanded discussion of CNAME handling 2070 | * Discussion of SvcParams in AliasMode records 2071 | * Restructured ABNF for comma-separated lists 2072 | * Additional references and many other minor clarifications 2073 | * Other changes include: 2074 | * New section on interaction with DNS64 2075 | * New text on the interpretation of wildcard owner names 2076 | * Adjusted guidance on default ALPN enforcement 2077 | * Removed mention of IPv4-mapped IPv6 2078 | 2079 | * draft-ietf-dnsop-svcb-https-08 2080 | * Extensive structural and editorial adjustments based on area reviews, 2081 | including: 2082 | * A new section on SVCB-compatible record types 2083 | * Reorganized description of client behavior 2084 | * Test vectors are now in titled figures 2085 | * Adjusted mapping summary 2086 | * Improve description of rules for resolver handling of invalid 2087 | SvcParamValues. 2088 | * New text on cross-transport fallback (e.g. QUIC vs. TCP) 2089 | * Improved explanation of use with domain-oriented transport proxies 2090 | * HTTP terminology adjusted to match draft-ietf-httpbis-semantics 2091 | * Improved and corrected IANA instructions 2092 | 2093 | * draft-ietf-dnsop-svcb-https-07 2094 | * Editorial improvements following AD review. 2095 | 2096 | * draft-ietf-dnsop-svcb-https-06 2097 | * Add requirements for HTTPS origins that also use Alt-Svc 2098 | * Remove requirement for comma-escaping related to unusual ALPN values 2099 | * Allow resolvers to reject invalid SvcParamValues, with additional 2100 | guidance 2101 | 2102 | * draft-ietf-dnsop-svcb-https-05 2103 | * Specify interaction with EDNS Client Subnet and Additional section caching 2104 | * Rename "echconfig" to "ech" 2105 | * Add a suite of test vectors (both valid and invalid) and more examples 2106 | * Clarify requirements for resolvers' (non-)use of SvcParams 2107 | * Clarify guidance regarding default ALPN values 2108 | 2109 | * draft-ietf-dnsop-svcb-https-04 2110 | * Simplify the IANA instructions (pure First Come First Served) 2111 | * Recommend against publishing chains of >8 aliases 2112 | * Clarify requirements for using SVCB with a transport proxy 2113 | * Adjust guidance for Port Prefix Naming 2114 | * Minor editorial updates 2115 | 2116 | * draft-ietf-dnsop-svcb-https-03 2117 | * Simplified escaping of comma-separated values 2118 | * Reorganized client requirements 2119 | * Added a warning about port filtering for cross-protocol attacks 2120 | * Clarified self-consistency rules for SvcParams 2121 | * Added a non-normative mapping summary table for HTTPS 2122 | 2123 | * draft-ietf-dnsop-svcb-https-02 2124 | * Added a Privacy Considerations section 2125 | * Adjusted resolution fallback description 2126 | * Clarified status of SvcParams in AliasMode 2127 | * Improved advice on zone structuring and use with Alt-Svc 2128 | * Improved examples, including a new Multi-CDN example 2129 | * Reorganized text on value-list parsing and SvcPriority 2130 | * Improved phrasing and other editorial improvements throughout 2131 | 2132 | * draft-ietf-dnsop-svcb-https-01 2133 | * Added a "mandatory" SvcParamKey 2134 | * Added the ability to indicate that a service does not exist 2135 | * Adjusted resolution and ALPN algorithms 2136 | * Major terminology revisions for "origin" and CamelCase names 2137 | * Revised ABNF 2138 | * Include allocated RR type numbers 2139 | * Various corrections, explanations, and recommendations 2140 | 2141 | * draft-ietf-dnsop-svcb-https-00 2142 | * Rename HTTPSSVC RR to HTTPS RR 2143 | * Rename "an SVCB" to "a SVCB" 2144 | * Removed "design considerations and open issues" section and some other "to be removed" text 2145 | 2146 | * draft-ietf-dnsop-svcb-httpssvc-03 2147 | * Revised chain length limit requirements 2148 | * Revised IANA registry rules for SvcParamKeys 2149 | * Require HTTPS clients to implement SNI 2150 | * Update terminology for Encrypted ClientHello 2151 | * Clarifications: non-default ports, transport proxies, HSTS procedure, WebSocket behavior, wire format, IP hints, inner/outer ClientHello with ECH 2152 | * Various textual and ABNF corrections 2153 | 2154 | * draft-ietf-dnsop-svcb-httpssvc-02 2155 | * All changes to Alt-Svc have been removed 2156 | * Expanded and reorganized examples 2157 | * Priority zero is now the definition of AliasForm 2158 | * Repeated SvcParamKeys are no longer allowed 2159 | * The "=" sign may be omitted in a key=value pair if the value is also empty 2160 | * In the wire format, SvcParamKeys must be in sorted order 2161 | * New text regarding how to handle resolution timeouts 2162 | * Expanded description of recursive resolver behavior 2163 | * Much more precise description of the intended ALPN behavior 2164 | * Match the HSTS specification's language on HTTPS enforcement 2165 | * Removed 'esniconfig=""' mechanism and simplified ESNI connection logic 2166 | 2167 | * draft-ietf-dnsop-svcb-httpssvc-01 2168 | * Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 2169 | * Make the "untrusted channel" concept more precise. 2170 | * Make SvcFieldPriority = 0 the definition of AliasForm, instead of a requirement. 2171 | 2172 | * draft-ietf-dnsop-svcb-httpssvc-00 2173 | * Document an optimization for optimistic pre-connection. (Chris Wood) 2174 | * Relax IP hint handling requirements. (Eric Rescorla) 2175 | 2176 | * draft-nygren-dnsop-svcb-httpssvc-00 2177 | * Generalize to an SVCB record, with special-case 2178 | handling for Alt-Svc and HTTPS separated out 2179 | to dedicated sections. 2180 | * Split out a separate HTTPSSVC record for 2181 | the HTTPS use-case. 2182 | * Remove the explicit SvcRecordType=0/1 and instead 2183 | make the AliasForm vs ServiceForm be implicit. 2184 | This was based on feedback recommending against 2185 | subtyping RR type. 2186 | * Remove one optimization. 2187 | 2188 | * draft-nygren-httpbis-httpssvc-03 2189 | * Change redirect type for HSTS-style behavior 2190 | from 302 to 307 to reduce ambiguities. 2191 | 2192 | * draft-nygren-httpbis-httpssvc-02 2193 | * Remove the redundant length fields from the wire format. 2194 | * Define a SvcDomainName of "." for SvcRecordType=1 2195 | as being the HTTPSSVC RRNAME. 2196 | * Replace "hq" with "h3". 2197 | 2198 | * draft-nygren-httpbis-httpssvc-01 2199 | * Fixes of record name. Replace references to "HTTPSVC" with "HTTPSSVC". 2200 | 2201 | * draft-nygren-httpbis-httpssvc-00 2202 | * Initial version 2203 | -------------------------------------------------------------------------------- /draft-ietf-tls-svcb-ech.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings 3 | abbrev: ECH in SVCB 4 | docname: draft-ietf-tls-svcb-ech-latest 5 | date: {DATE} 6 | category: std 7 | 8 | ipr: trust200902 9 | area: Security 10 | workgroup: TLS Working Group 11 | keyword: Internet-Draft 12 | 13 | stand_alone: yes 14 | pi: [toc, sortrefs, symrefs] 15 | 16 | author: 17 | - 18 | ins: B. Schwartz 19 | name: Ben Schwartz 20 | organization: Google 21 | email: ietf@bemasc.net 22 | - 23 | ins: M. Bishop 24 | name: Mike Bishop 25 | org: Akamai Technologies 26 | email: mbishop@evequefou.be 27 | - 28 | ins: E. Nygren 29 | name: Erik Nygren 30 | org: Akamai Technologies 31 | email: erik+ietf@nygren.org 32 | 33 | --- abstract 34 | 35 | To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. 36 | 37 | --- middle 38 | 39 | # Overview 40 | 41 | The Service Bindings framework {{!SVCB=I-D.ietf-dnsop-svcb-https}} allows server operators to publish a detailed description of their service in the Domain Name System {{!RFC1034}} using SVCB or HTTPS records. Each SVCB record describes a single "alternative endpoint", and contains a collection of "SvcParams" that can be extended with new kinds of information that may be of interest to a client. Clients can use the SvcParams to improve the privacy, security, and performance of their connection to this endpoint. 42 | 43 | This specification defines a new SvcParam to enable the use of TLS Encrypted ClientHello {{!ECH=I-D.ietf-tls-esni}} in TLS-based protocols. This SvcParam can be used in SVCB, HTTPS or any future SVCB-compatible DNS records, and is intended to serve as the primary bootstrap mechanism for ECH. 44 | 45 | # SvcParam for ECH configuration {#ech-param} 46 | 47 | The "ech" SvcParamKey is defined for conveying the ECH configuration of an alternative endpoint. It is applicable to all TLS-based protocols (including DTLS {{?RFC9147}} and QUIC version 1 {{?RFC9001}}) unless otherwise specified. 48 | 49 | In wire format, the value of the parameter is an ECHConfigList ({{Section 4 of !ECH}}), including the redundant length prefix. In presentation format, the value is the ECHConfigList in Base 64 Encoding ({{Section 4 of !RFC4648}}). Base 64 is used here to simplify integration with TLS server software. To enable simpler parsing, this SvcParam MUST NOT contain escape sequences. 50 | 51 | # Server behavior 52 | 53 | When publishing a record containing an "ech" parameter, the publisher MUST ensure that all IP addresses of TargetName correspond to servers that have access to the corresponding private key or are authoritative for the public name. (See {{Section 7.2.2 of !ECH}} for more details about the public name.) Otherwise, connections will fail entirely. 54 | 55 | # Client behavior {#ech-client-behavior} 56 | 57 | This section describes client behavior in using ECH configurations provided in SVCB or HTTPS records. 58 | 59 | ## Disabling fallback 60 | 61 | The SVCB-optional client behavior specified in ({{Section 3 of !SVCB}}) permits clients to fall back to a direct connection if all SVCB options fail. This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH. Accordingly, ECH-capable SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded (as defined in {{Section 3 of !SVCB}}) and all alternative endpoints have an "ech" SvcParam. 62 | 63 | ## ClientHello construction 64 | 65 | When ECH is in use, the TLS ClientHello is divided into an unencrypted "outer" and an encrypted "inner" ClientHello. The outer ClientHello is an implementation detail of ECH, and its contents are controlled by the ECHConfig in accordance with {{ECH}}. The inner ClientHello is used for establishing a connection to the service, so its contents may be influenced by other SVCB parameters. For example, the requirements related to ALPN protocol identifiers in {{Section 7.1.2 of SVCB}} apply only to the inner ClientHello. Similarly, it is the inner ClientHello whose Server Name Indication identifies the desired service. 66 | 67 | ## Performance optimizations 68 | 69 | Prior to retrieving the SVCB records, the client does not know whether they contain an "ech" parameter. As a latency optimization, clients MAY prefetch DNS records that will only be used if this parameter is not present (i.e. only in SVCB-optional mode). 70 | 71 | The "ech" SvcParam alters the contents of the TLS ClientHello if it is present. Therefore, clients that support ECH MUST NOT issue any TLS ClientHello until after SVCB resolution has completed. (See {{Section 5.1 of !SVCB}}). 72 | 73 | # Interaction with HTTP Alt-Svc 74 | 75 | HTTP clients that implement both HTTP Alt-Svc {{?RFC7838}} and the HTTPS record type {{!SVCB}} can use them together, provided that they only perform connection attempts that are "consistent" with both sets of parameters ({{Section 9.3 of !SVCB}}). At the time of writing, there is no defined parameter related to ECH for Alt-Svc. Accordingly, a connection attempt that uses ECH is considered "consistent" with an Alt-Svc Field Value that does not mention ECH. 76 | 77 | Origins that publish an "ech" SvcParam in their HTTPS record SHOULD also publish an HTTPS record with the "ech" SvcParam for every alt-authority offered in its Alt-Svc Field Values. Otherwise, clients might reveal the name of the server in an unencrypted ClientHello to an alt-authority. 78 | 79 | If all HTTPS records for an alt-authority contain "ech" SvcParams, the client MUST adopt SVCB-reliant behavior (as in {{disabling-fallback}}) for that RRSet. This precludes the use of certain connections that Alt-Svc would otherwise allow, as discussed in {{Section 9.3 of !SVCB}}. 80 | 81 | ## Security Considerations 82 | 83 | A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: a network intermediary can block connections to the endpoints that support ECH, causing the client to fall back to a non-ECH endpoint. This configuration is NOT RECOMMENDED. Zone owners who do use such a mixed configuration SHOULD mark the RRs with "ech" as more preferred (i.e. lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary. 84 | 85 | Use of ECH yields an anonymity set of cardinality equal to the number of ECH-enabled server domains supported by a given client-facing server. Thus, even with an encrypted ClientHello, an attacker who can enumerate the set of ECH-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ECH-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. 86 | 87 | # IANA Considerations 88 | 89 | IANA is instructed to modify the Service Binding (SVCB) Parameter Keys Registry entry for "ech" as follows: 90 | 91 | | Number | Name | Meaning | Format Reference | Change Controller | 92 | | ----------- | ------ | ---------------------- | ---------------------------------------- | ----------------- | 93 | | 5 | ech | TLS Encrypted ClientHello Config | (This document) | IETF | 94 | -------------------------------------------------------------------------------- /draft-schwartz-httpbis-dns-alt-svc.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Finding HTTP Alternative Services via the Domain Name Service 3 | abbrev: Alt-Svc via DNS 4 | docname: draft-schwartz-httpbis-dns-alt-svc-latest 5 | date: {DATE} 6 | category: std 7 | 8 | ipr: trust200902 9 | area: General 10 | workgroup: HTTP Working Group 11 | keyword: Internet-Draft 12 | 13 | stand_alone: yes 14 | pi: [toc, sortrefs, symrefs] 15 | 16 | author: 17 | - 18 | ins: B. Schwartz 19 | name: Ben Schwartz 20 | organization: Google 21 | email: bemasc@google.com 22 | - 23 | ins: M. Bishop 24 | name: Mike Bishop 25 | org: Akamai Technologies 26 | email: mbishop@evequefou.be 27 | 28 | normative: 29 | 30 | informative: 31 | 32 | --- abstract 33 | The HTTP Alternative Services (Alt-Svc) mechanism allows an 34 | HTTP origin to be served from multiple network endpoints, and over 35 | multiple protocols. However, the client must first contact the 36 | origin server, in order to learn of the alternative services. This 37 | draft proposes a straightforward mapping of Alt-Svc into 38 | DNS, allowing clients to learn of these services before their first 39 | contact with the origin. This arrangement offers potential benefits to 40 | both performance and privacy. 41 | 42 | --- middle 43 | 44 | # Introduction 45 | 46 | The HTTP Alternative Services standard {{!AltSvc=RFC7838}} defines 47 | 48 | * an extensible data model for describing alternative network endpoints 49 | that are authoritative for an origin 50 | * the "Alt-Svc Field Value", a text format for representing this 51 | information 52 | * standards for sending information in this format from a server to a 53 | client over HTTP/1.1 and HTTP/2. 54 | 55 | Together, these components provide a toolkit that has proven useful and 56 | effective for informing a client of alternative services for an origin. 57 | However, making use of an alternative service requires contacting the 58 | origin server first. This creates an obvious performance cost: users 59 | wait for a full HTTP connection initiation (multiple roundtrips) before 60 | learning of an alternative service that is preferred by the origin. The 61 | first connection also publicly reveals the user's intended destination 62 | to all entities along the network path. 63 | 64 | This draft proposes a straightforward mechanism to distribute the 65 | Alt-Svc Field Value, in its standard text format, through 66 | the DNS. If a client receives this information during DNS resolution, 67 | it can skip the initial connection and proceed directly to an 68 | alternative service. 69 | 70 | ## Terminology 71 | For consistency with {{!AltSvc}}, we adopt the following definitions 72 | 73 | * An "origin" is an information source as in {{!RFC6454}}. 74 | * The "origin server" is the server that the client would reach when 75 | accessing the origin in the absence of Alt-Svc. 76 | * An "alternative service" is a different server that can serve the 77 | origin. 78 | 79 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 80 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 81 | "MAY", and "OPTIONAL" in this document are to be interpreted as 82 | described in BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they 83 | appear in all capitals, as shown here. 84 | 85 | # The ALTSVC record type 86 | 87 | The ALTSVC DNS resource record (RR) type (RRTYPE ???) is used to 88 | associate an Alternative Service Field Value with an origin. 89 | Abstractly, the origin consists of a scheme (typically "https"), a host 90 | name, and a port (typically "443"). 91 | 92 | In the case of the ALTSVC RR, the origin is represented by prefixing the 93 | port and scheme with "_", then concatenating them with the host, 94 | resulting in a domain name like "_443._https.www.example.com.". 95 | 96 | The IANA DNS Underscore Global Scoped Entry Registry 97 | {{!Attrleaf=I-D.ietf-dnsop-attrleaf}} MUST have an entry under the ALTSVC RRType 98 | for this scheme. The scheme SHOULD have an entry in the IANA URI Schemes 99 | Registry {{!RFC7595}}. The scheme SHOULD be one for which Alt-Svc is defined 100 | (currently "http" or "https"). 101 | 102 | The RDATA portion of an ALTSVC resource record contains an Alt-Svc 103 | Field Value, exactly as defined in Section 4 of {{!AltSvc}}. 104 | 105 | For example, if the operator of https://www.example.com 106 | intends to include an HTTP response header like 107 | 108 | Alt-Svc: h2=":8000"; ma=60 109 | 110 | They would also publish an ALTSVC DNS record like 111 | 112 | _443._https.www.example.com. 60S IN ALTSVC "h2=\\":8000\\"" 113 | 114 | This data type can be represented as an Unknown RR as described in 115 | {{!RFC3597}}: 116 | 117 | _443._https.www.example.com. 60S IN TYPE??? \\# 10 68323D223A3830303022 118 | 119 | This construction is intended to be extensible in two ways. First, 120 | any extensions that are made to the Alt-Svc format for transmission over 121 | HTTPS are also applicable here, unless expressly mentioned otherwise. 122 | Second, including the scheme in the DNS name allows for ALTSVC to serve 123 | schemes other than HTTPS, such as HTTP with Opportunistic Security 124 | {{?RFC8164}} and any future schemes for which Alt-Svc may be defined. 125 | 126 | ## Comparison with alternatives 127 | 128 | The ALTSVC record type closely resembles some existing record types. 129 | 130 | ### Differences from the SRV RRTYPE 131 | 132 | An SRV record can perform a similar function to the ALTSVC record, 133 | informing a client to look in a different location for a service. 134 | However, there are several differences: 135 | 136 | * SRV records are typically mandatory, whereas clients will always 137 | continue to function correctly without making use of Alt-Svc. 138 | * SRV records cannot instruct the client to switch or upgrade 139 | protocols, whereas Alt-Svc can signal such an upgrade (e.g. to 140 | HTTP/2). 141 | * SRV records are not extensible, whereas Alt-Svc can be extended with 142 | new parameters. For example, this is what allows the privacy 143 | improvements related to SNI selection in {{!AltSvcSNI}}. 144 | * Using SRV records would not allow a client to skip processing of the 145 | Alt-Svc information in a subsequent connection, so it does not confer 146 | a performance advantage. 147 | 148 | ### Differences from the TXT RRTYPE 149 | 150 | The ALTSVC record uses an identical format to a TXT record, and could 151 | be implemented as such. However, we define a new record type for 152 | clarity, and to respect the use of TXT for human-readable notes as 153 | recommended in {{?RFC5507}}. 154 | 155 | # Differences from Alt-Svc as transmitted over HTTP 156 | 157 | Publishing an ALTSVC record in DNS is intended to be equivalent to 158 | transmitting this field value over HTTP, and receiving an ALTSVC record 159 | is intended to be equivalent to receiving this field value over HTTP. 160 | However, there are some small differences in the intended client and 161 | server behavior. 162 | 163 | ## Omitting Max Age 164 | 165 | When publishing an ALTSVC record in DNS, server operators MUST omit the 166 | "ma" parameter, which encodes the "max age" (i.e. expiration time) of 167 | an Alt-Svc Field Value. Instead, server operators SHOULD encode the 168 | expiration time in the DNS TTL, and MUST NOT set a TTL longer than the 169 | intended "max age". 170 | 171 | When receiving an ALTSVC record, clients MAY synthesize a new "ma" 172 | parameter from the DNS TTL, in order to interoperate with Alt-Svc processing 173 | subsystems. 174 | 175 | ## Multiple records and values 176 | 177 | Server operators MAY publish multiple ALTSVC records as an RRSET. When 178 | publishing an RRSET with multiple ALTSVC 179 | records, the server operator MUST set the overall TTL to the minimum 180 | of the "max age" values (following Section 5.2 of {{!RFC2181}}). 181 | Each RR can contain multiple alt-values separated by commas, as described 182 | in Section 3 of {{!AltSvc}}. As specified there, "the order of values 183 | relects the server's preference". 184 | 185 | When receiving an RRSET containing multiple ALTSVC records, clients 186 | SHOULD apply a random shuffle to the records before using them, to 187 | ensure randomized load-balancing. This is consistent with DNS rules for 188 | interpretation of RRSETs, which are regarded as unordered collections. 189 | 190 | After shuffling the RRSET, the client SHOULD concatenate all the values 191 | in the RRSET, separated by commas. (This is semantically equivalent to 192 | receiving multiple Alt-Svc HTTP response headers, according to Section 3.2.2 193 | of {{?HTTP=RFC7230}}). 194 | 195 | ## Interaction with other standards 196 | 197 | The purpose of this standard is to reduce connection latency and 198 | improve user privacy. Server operators implementing this standard 199 | SHOULD also implement TLS 1.3 {{!I-D.ietf-tls-tls13}} and OCSP Stapling 200 | {{!RFC6066}}, both of which confer substantial performance and privacy 201 | benefits when used in combination with ALTSVC records. 202 | 203 | To realize the greatest privacy benefits, this proposal is intended for 204 | use with a privacy-preserving DNS transport (like DNS over TLS 205 | {{!RFC7858}} or DNS over HTTPS {{!DOH=I-D.ietf-doh-dns-over-https}}), 206 | and with the "SNI" Alt-Svc Parameter 207 | {{!AltSvcSNI=I-D.bishop-httpbis-sni-altsvc}}. However, performance 208 | improvements, and some modest privacy improvements, are possible without 209 | the use of those standards. 210 | 211 | ## Granularity and lifetime control 212 | 213 | Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 214 | Field Value specifically to the client. When using an ALTSVC DNS 215 | record, groups of clients will necessarily receive the same Alt-Svc 216 | Field Value. Therefore, this standard is not suitable for servers that 217 | require single-client granularity in Alt-Svc. Server operators that 218 | want to serve different Alt-Svc Field Values to different geographic 219 | or network regions SHOULD configure their authoritative DNS server to 220 | respect the EDNS0 Client Subnet extension {{?RFC7871}}. 221 | 222 | Some DNS caching systems incorrectly extend the lifetime of DNS 223 | records beyond the stated TTL. Server operators MUST NOT rely on 224 | ALTSVC records expiring on time, and MAY shorten the TTL to compensate. 225 | 226 | # Client behaviors 227 | 228 | ## Cache interaction 229 | 230 | If the client has an Alt-Svc cache, and a usable Alt-Svc value is 231 | present in that cache, then the client SHOULD NOT issue an ALTSVC DNS 232 | query. Instead, the client SHOULD proceed with alternative service 233 | connection as usual. 234 | 235 | If the client has a cached Alt-Svc entry that is expiring, the 236 | client MAY perform an ALTSVC query to refresh the entry. 237 | 238 | ## Optimizing for performance 239 | 240 | Clients that are optimizing for performance (i.e. minimum connection 241 | setup time) SHOULD implement the following connection sequence: 242 | 243 | 1. Issue address (AAAA and/or A) queries, immediately followed by the 244 | ALTSVC query. 245 | 1. If an ALTSVC response is received first, proceed with alternative 246 | service connection and ignore the address responses if they are no 247 | longer relevant. 248 | 1. Otherwise, initiate connection to the origin server. 249 | 1. As soon as an Alt-Svc field value is received, through the DNS or 250 | over HTTP, proceed with alternative service connection. Do not 251 | abort this connection if an Alt-Svc field value is received from the 252 | other source later. 253 | 254 | If the ALTSVC and address queries return approximately simultaneously, 255 | this process typically saves three roundtrips on a fresh connection 256 | that uses Alt-Svc: one each for TCP, TLS 1.3, and HTTP. (On subsequent 257 | connections, the Alt-Svc information is expected to be cached, so this 258 | procedure does not apply.) 259 | 260 | If a client can cache Alt-Svc entries that were received over both HTTP 261 | and DNS, the client MAY prefer entries that were received over HTTP. 262 | These records may be more narrowly targeted for the specific client. 263 | 264 | As an additional optimization, when choosing among multiple Alt-Svc 265 | values, clients MAY prefer those that will not require an address 266 | query, either because the corresponding address record is 267 | already in cache or because the host is an IP address. 268 | 269 | Note that this procedure does not rely on recursive resolvers handling 270 | the ALTSVC record type correctly. If ALTSVC queries receive spurious 271 | NXDOMAIN responses, or even no response at all, connections will proceed 272 | as usual without any delay. 273 | 274 | ## Optimizing for privacy 275 | 276 | Clients that are optimizing for privacy SHOULD implement {{!AltSvcSNI}} 277 | and DNS over a secure transport (e.g. {{!RFC7858}} or {{!DOH}}). 278 | Use of a secure transport is important not only for privacy protection, 279 | but also to ensure that queries for the new ALTSVC RRTYPE are handled 280 | correctly. Additionally, these clients SHOULD implement the following 281 | connection sequence: 282 | 283 | 1. Issue the ALTSVC DNS query first, immediately followed by the 284 | address queries. 285 | 1. Wait for the ALTSVC record response. 286 | 1. If the response is nonempty, proceed with alternative service 287 | connection and ignore the address query responses. 288 | 1. Otherwise, wait for the address queries and connect as usual. 289 | 290 | Note that this process is also expected to be faster than Alt-Svc over 291 | HTTP in the case of HTTP Opportunistic Upgrade Probing (Section 2 of 292 | {{?RFC8164}}). 293 | 294 | # Security Considerations 295 | 296 | Alt-Svc Field Values are intended for distribution over untrusted 297 | channels, and clients are REQUIRED to verify that the alternative 298 | service is authoritative for the origin (Section 2.1 of {{!AltSvc}}). 299 | Therefore, DNSSEC signing and validation are OPTIONAL for publishing 300 | and using ALTSVC records. 301 | 302 | # IANA Considerations 303 | 304 | Per {{?RFC6895}}, please add the following entry to the data type 305 | range of the Resource Record (RR) TYPEs registry: 306 | 307 | | TYPE | Meaning | Reference | 308 | | ------ | ------------- | --------------- | 309 | | ALTSVC | Alt-Svc Value | (This document) | 310 | 311 | Per {{?Attrleaf}}, please add the following entries to the DNS Underscore 312 | Global Scoped Entry Registry: 313 | 314 | | RR TYPE | _NODE NAME | Meaning | Reference | 315 | | ------- | ---------- | ----------------- | --------------- | 316 | | ALTSVC | _https | Alt-Svc for HTTPS | (This document) | 317 | | ALTSVC | _http | Alt-Svc for HTTP | (This document) | 318 | 319 | --- back 320 | 321 | -------------------------------------------------------------------------------- /svcb-implementations.md: -------------------------------------------------------------------------------- 1 | The following are known implementations 2 | of [draft-ietf-dnsop-svcb-https](https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/) 3 | 4 | Please feel free to submit PRs to update this page. 5 | 6 | # Production / shipped implementations # 7 | 8 | ## iOS & macOS ## 9 | 10 | iOS 14 (September 2020) and macOS 11 (November 2020) support HTTPS/SVCB records. Type 65 (HTTPS) is requested 11 | for all URLSession or Network.framework connections that use an http or https scheme, or use ports 80 or 443. 12 | 13 | ## PowerDNS ## 14 | 15 | Implemented in [PowerDNS 4.4.0](https://doc.powerdns.com/authoritative/changelog/4.4.html#change-4.4.0), December 2020. 16 | 17 | ## Knot DNS ## 18 | 19 | Supported since [Knot DNS 3.0.3](https://gitlab.nic.cz/knot/knot-dns/-/releases/v3.0.3), December 2020. 20 | 21 | ## Perl Net::DNS ## 22 | 23 | Implemented in [Net::DNS 1.26](https://www.net-dns.org/blog/2020/08/05/netdns-1-26-released/), August 2020. 24 | 25 | ## dnspython ## 26 | 27 | Implemented [in dnspython 2.1.0](https://dnspython.readthedocs.io/en/stable/whatsnew.html#id1), January 2021. 28 | 29 | ## dnsjava ## 30 | 31 | Supported [in dnsjava 3.3.0](https://github.com/dnsjava/dnsjava/blob/master/Changelog), September 2020. 32 | 33 | ## miekg/dns (Go) ## 34 | 35 | [Supported](https://github.com/miekg/dns/pull/1067) since v1.1.35, October 2020. 36 | 37 | ## trust-dns (Rust) ## 38 | 39 | Implemented in [trust-dns 0.21.0](https://github.com/bluejekyll/trust-dns/blob/main/CHANGELOG.md#0201), March 2021. 40 | 41 | # Services supporting SVCB/HTTPS records # 42 | 43 | ## Cloudflare ## 44 | 45 | Cloudflare's authoritative DNS servers reply to HTTPS queries for domains for 46 | which Cloudflare provides HTTPS termination. 47 | 48 | The following domains can be used for testing (along any other domain served by 49 | Cloudflare): blog.cloudflare.com, www.cloudflare.com, cdnjs.cloudflare.com, 50 | cloudflare-http3.com, cloudflare-http2.com, cloudflare-http1.com. 51 | 52 | ## Akamai services ## 53 | 54 | Akamai Global Traffic Management (load balancing) and Edge DNS (authoritative DNS) [support the use of HTTPS and SVCB records](https://community.akamai.com/customers/s/article/NetworkOperatorCommunityNewSVCBHTTPSResourceRecordsinthewild20201128135350) (November 2020). 55 | 56 | Akamai CacheServe (recursive resolver) supports HTTPS records. [As of February 2021](https://indico.dns-oarc.net/event/37/contributions/810/attachments/784/1413/dns-https-rr-final.pdf), HTTPS QTYPEs accounted for several percent of queries. 57 | 58 | ## Google Public DNS JSON API ## 59 | 60 | The Google Public DNS JSON API supports [typed serialization](https://dns.google/query?name=blog.cloudflare.com&rr_type=HTTPS&ecs=) of SVCB and HTTPS records (March 2021). 61 | 62 | ## NS1 ## 63 | 64 | NS1 authoritative DNS supports [SVCB and HTTPS](https://ns1.com/blog/ns1-announces-support-for-svcb-and-https-records) records (July 2022). 65 | 66 | # Pre-release and public testing implementations # 67 | 68 | ## Firefox ## 69 | 70 | Firefox supports HTTPS RR since Firefox 81. It is currently disabled and can be enabled by changing prefs: network.dns.upgrade_with_https_rr and network.dns.use_https_rr_as_altsvc (type about:config in the address bar and search for the prefs; set them to true). At the moment this is only supported if DoH is enabled. 71 | 72 | ## Chrome ## 73 | 74 | Chrome 88 [performs HTTPS queries](https://groups.google.com/a/chromium.org/g/blink-dev/c/brZTXr6-2PU) in some configurations (e.g. when Secure DNS is enabled on the Beta channel, December 2020). 75 | 76 | ## NSD ## 77 | 78 | Support [is implemented](https://github.com/NLnetLabs/nsd/blob/master/doc/ChangeLog) in the development branch (April 2021). 79 | 80 | # Under development # 81 | 82 | ## BIND9 ## 83 | 84 | [Work-in-progress implementation for BIND9](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2135) 85 | 86 | * Author: Mark Andrews \ 87 | * Tracker: [BIND9 GL 1132](https://gitlab.isc.org/isc-projects/bind9/-/issues/1132) 88 | * Version: Implement draft-ietf-dnsop-svcb-https-01 (work-in-progress) 89 | ** Previous versions implemented draft-nygren-httpbis-httpssvc-02 (and -01) and draft-nygren-dnsop-svcb-httpssvc-00 90 | ** Previous versions used TYPENN of HTTPS/65482 and SVBC/65481 91 | 92 | ## Unbound ## 93 | 94 | * Prototype of draft-nygren-httpbis-httpssvc-02 during IETF 105 hackathon 95 | 96 | ## Others ## 97 | 98 | --------------------------------------------------------------------------------