From 1963e71c9dbc2a563513ab9fa25b2606f71b7779 Mon Sep 17 00:00:00 2001 From: Pawel Kowalik <2063440-pawel-kow@users.noreply.gitlab.com> Date: Mon, 22 Jul 2024 06:39:54 +0000 Subject: [PATCH] RELEASE: draft-kowalik-regext-domainconnect-00 --- .devcontainer/Dockerfile | 17 +- .devcontainer/bin/md2rfc | 34 + .devcontainer/devcontainer.json | 3 +- .vscode/settings.json | 1 - ...draft-kowalik-regext-domainconnect-00.adoc | 273 +- ...t-kowalik-regext-domainconnect-00.err.html | 137 + ...draft-kowalik-regext-domainconnect-00.html | 3339 +++++++++-------- ...ft-kowalik-regext-domainconnect-00.rfc.xml | 1214 +++--- ... draft-kowalik-regext-domainconnect-00.txt | 2616 +++++++------ 9 files changed, 4056 insertions(+), 3578 deletions(-) create mode 100644 .devcontainer/bin/md2rfc rename draft-domain-connect-04.adoc => draft-kowalik-regext-domainconnect-00.adoc (91%) create mode 100644 draft-kowalik-regext-domainconnect-00.err.html rename draft-domain-connect-04.html => draft-kowalik-regext-domainconnect-00.html (59%) rename draft-domain-connect-04.rfc.xml => draft-kowalik-regext-domainconnect-00.rfc.xml (64%) rename draft-domain-connect-04.txt => draft-kowalik-regext-domainconnect-00.txt (62%) diff --git a/.devcontainer/Dockerfile b/.devcontainer/Dockerfile index 04ee5c7..baea413 100644 --- a/.devcontainer/Dockerfile +++ b/.devcontainer/Dockerfile @@ -1,4 +1,13 @@ -FROM docker.io/paulej/rfctools -RUN sudo dnf -y update && sudo dnf -y install git ruby ruby-devel -RUN bash -c "curl -L https://raw.githubusercontent.com/metanorma/metanorma-linux-setup/master/centos.sh | bash" && \ - curl -L https://raw.githubusercontent.com/metanorma/metanorma-linux-setup/master/install-gems.sh | bash +FROM ghcr.io/ietf-tools/xml2rfc-base:latest + +RUN apt-get -y update && apt-get -y install curl && apt-get -y clean + +RUN bash -c curl -L https://raw.githubusercontent.com/metanorma/metanorma-linux-setup/master/ubuntu.sh | bash && curl -L https://raw.githubusercontent.com/metanorma/metanorma-linux-setup/master/install-gems.sh | bash + +# Put the md2rfc script in place +COPY bin/md2rfc /usr/bin/ + +RUN apt-get -y update && apt-get -y install git nano default-jre && apt-get -y clean + +# Specify the working directory when a container is started +WORKDIR /rfc \ No newline at end of file diff --git a/.devcontainer/bin/md2rfc b/.devcontainer/bin/md2rfc new file mode 100644 index 0000000..5130eb8 --- /dev/null +++ b/.devcontainer/bin/md2rfc @@ -0,0 +1,34 @@ +#!/bin/bash +# +# This script will invoke mmark to convert markdown to xml2rfc format, +# then it will invoke xml2rfc to produce an outout text file +# +# One may specify one or more markdown files (with the .md extension). +# + +# Ensure that at least one file was specified +if [ $# -eq 0 ] ; then + echo "usage: md2rfc [ ...]" + exit 1; +fi + +# Loop through all of the specified .md files to produce .txt and .pdf files +# as output +while [ $# -gt 0 ] ; do + MDFILE=$1 + shift + XMLFILE=$(echo $MDFILE | sed 's/\.md$/.xml/') + TXTFILE=$(echo $MDFILE | sed 's/\.md$/.txt/') + PDFFILE=$(echo $MDFILE | sed 's/\.md$/.pdf/') + HTMLFILE=$(echo $MDFILE | sed 's/\.md$/.html/') + + if [ x"$MDFILE" == x"$XMLFILE" ] ; then + echo "Error: $MDFILE is not a .md file" + exit 1 + else + mmark "$MDFILE" > "$XMLFILE" && \ + xml2rfc --v3 --text "$XMLFILE" -o "$TXTFILE" && \ + xml2rfc --v3 --pdf "$XMLFILE" -o "$PDFFILE" && \ + xml2rfc --v3 --html "$XMLFILE" -o "$HTMLFILE" + fi +done diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index 85e04d6..c0d25d3 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -15,7 +15,8 @@ "eamodio.gitlens", "donjayamanne.githistory", "asciidoctor.asciidoctor-vscode", - "Gruntfuggly.todo-tree" + "Gruntfuggly.todo-tree", + "ms-azuretools.vscode-docker" ], // Use 'forwardPorts' to make a list of ports inside the container available locally. diff --git a/.vscode/settings.json b/.vscode/settings.json index 92117ba..aa697e4 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,4 +1,3 @@ { - "asciidoc.antora.enableAntoraSupport": true, "editor.wordWrap": "wordWrapColumn" } \ No newline at end of file diff --git a/draft-domain-connect-04.adoc b/draft-kowalik-regext-domainconnect-00.adoc similarity index 91% rename from draft-domain-connect-04.adoc rename to draft-kowalik-regext-domainconnect-00.adoc index e34bdf3..b253fba 100644 --- a/draft-domain-connect-04.adoc +++ b/draft-kowalik-regext-domainconnect-00.adoc @@ -1,33 +1,29 @@ -= Domain Connect API - Communications between DNS Provider and Services += Domain Connect Protocol - DNS provisioning between Services and DNS Providers :mn-document-class: ietf :mn-output-extensions: rfc,txt,html :doctype: internet-draft :abbrev: Domain Connect :intended-series: standard -:submission-type: ad-sponsored -:docnumber: draft-kowalik-art-domainconnect-04 +:submission-type: IETF +:docnumber: draft-kowalik-regext-domainconnect-00 :status: informational :ipr: trust200902 :area: Applications and Real-Time -:workgroup: Registration Protocols Extensions? +:workgroup: Registration Protocols Extensions :keyword: dns -:revdate: 2024-07-19- - +:revdate: 2024-07-19 :givenname: Pawel :surname: Kowalik :email: pawel.kowalik@denic.de :affiliation: DENIC eG -:street: -:city: -:region: -:code: +:street: Theodor-Stern-Kai 1 +:city: Frankfurt am Main +:code: 60596 :country: DE :contributor-uri: https://denic.de - :givenname_2: Arnold :surname_2: Blinn :email_2: arnold@arnoldblinn.com - :givenname_3: Jody :surname_3: Kolker :email_3: jkolker@godaddy.com @@ -38,14 +34,16 @@ :code_3: 85260 :country_3: US :contributor-uri_3: https://www.godaddy.com - :givenname_4: Sami :surname_4: Kerola :email_4: kerolasa@cloudflare.com -:affiliation_4: Cloudflare +:affiliation_4: Cloudflare, Inc. +:street_4: 101 Townsend St +:city_4: San Francisco +:region_4: CA +:code_4: 94107 :country_4: US :contributor-uri_4: https://cloudflare.com - :specversion: 2.2 :revnumber: 63 :source-highlighter: prettify @@ -56,7 +54,8 @@ :toc: auto :toclevels: 4 -This document provides information related to the Domain Connect API that was built to support communications between DNS Providers and Service Providers (hosting, social, email, hardware, etc.). + +This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. == Introduction @@ -78,7 +77,7 @@ direct manipulation of individual DNS records. [glossary] [toc=exclude] :sectnums!: -=== Terminology +== Terminology The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. @@ -143,32 +142,19 @@ and control of the settings being changed to enable a service. And the system is more secure as templates are controlled and contained. == End User Flows +=== General information +To attach a domain name to a service provided by a Service Provider, the customer would first enter their domain name. -To attach a domain name to a service provided by a Service Provider, the -customer would first enter their domain name. - -Instead of relying on examination of the nameservers and mapping these -to DNS Providers, DNS Provider discovery is handled through simple -records in DNS and an API. The Service Provider queries for a specific -record in the zone that returns a REST endpoint to initiate the -protocol. When this endpoint is called, a Domain Connect compliant DNS Provider returns -information about that domain and how to configure it using Domain -Connect. +Instead of relying on examination of the nameservers and mapping these to DNS Providers, DNS Provider discovery is handled through simple records in DNS and an API. The Service Provider queries for a specific record in the zone that returns a REST endpoint to initiate the protocol. When this endpoint is called, a Domain Connect compliant DNS Provider returns information about that domain and how to configure it using Domain Connect. To apply the changes to DNS, there are two use cases. The -first is a synchronous web flow, and the second is an asynchronous flow -using oAuth and an API. +first is a synchronous web flow, and the second is an asynchronous flow using OAuth and an API. -It is noted that a DNS Provider may choose to only implement one -of the flows. As a matter of practice many Service Providers are based -on the synchronous flow, with only a handful of them based on the -asynchronous oAuth flow. So many DNS providers may opt to only implement -the synchronous flow. +It is noted that a DNS Provider may choose to only implement one of the flows. As a matter of practice many Service Providers are based on the synchronous flow, with only a handful of them based on the asynchronous OAuth flow. So many DNS providers may opt to only implement the synchronous flow. -It is also be noted that individual services may work with the -synchronous flow only, the asynchronous flow only, or with both. +It is also be noted that individual services may work with the synchronous flow only, the asynchronous flow only, or with both. -==== The Synchronous Flow +=== The Synchronous Flow This flow is tailored for the Service Provider that requires a one time synchronous change to DNS. @@ -288,8 +274,7 @@ after the changes are applied. If invoked in place, the user must be navigated b to the Service Provider after the changes are applied. === The Asynchronous Flow - -The asynchronous oAuth flow is tailored for the Service Provider that +The asynchronous OAuth flow is tailored for the Service Provider that wishes to make changes to DNS asynchronously with respect to the user interaction, or wishes to make multiple or additional changes to DNS over time. @@ -429,8 +414,6 @@ authoritative. This does not indicate the authoritative nameservers; for this th would be queried. |======================================================================= -As an example, the JSON returned by this call might contain. - [source,json] ---- { @@ -442,8 +425,10 @@ As an example, the JSON returned by this call might contain. "urlAPI": "https://api.domainconnect.virtucondomains.example", "width": 750, "height": 750, - "urlControlPanel": "https://domaincontrolpanel.virtucondomains.example/?domain=%domain%", - "nameServers": ["ns01.virtucondomainsdns.example", "ns02.virtucondomainsdns.example"] + "urlControlPanel": "https://domaincontrolpanel.virtucondomains.ex + ample/?domain=%domain%", + "nameServers": ["ns01.virtucondomainsdns.example", "ns02.virtucon + domainsdns.example"] } ---- @@ -486,7 +471,7 @@ discovery are in the form of URLs. The first set of endpoints are for the UX that the Service Provider links to. These are for the synchronous flow where the user can click to grant consent and have changes applied, and for the -asynchronous oAuth flow where the user can grant consent for +asynchronous OAuth flow where the user can grant consent for OAuth access. The second set of endpoints are for the REST API. @@ -517,7 +502,8 @@ the JSON payload during DNS Provider discovery. ---- GET -{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId} +{urlAPI}/v2/domainTemplates/providers/{providerId}/services +/{serviceId} ---- This URL is be used by the Service Provider to determine if the DNS @@ -547,12 +533,13 @@ call was successful. The response OPTIONALLY contains the version or template. |======================================================================= ==== Apply Template - +===== Apply Template URL [source] ---- GET -{urlSyncUX}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties] +{urlSyncUX}/v2/domainTemplates/providers/{providerId}/services +/{serviceId}/apply?[properties] ---- This is the URL where the user is sent to apply a template to a domain they own. @@ -561,7 +548,6 @@ It is called from the Service Provider to start the synchronous Domain Connect P This URL can be called in one of two ways. ===== New Browser Window - The first is through a new browser tab or in a popup browser window. The DNS Provider signs the user in if necessary, verifies domain ownership, and asks for confirmation @@ -587,7 +573,7 @@ passed back as state= on the redirect_uri. If authorization could not be obtained or an error has occurred, the parameter error= must be appended. For consistency with the asynchronous OAuth flows the valid values for the error parameter will be as -specified in OAuth 2.0 RFC 6749 (4.1.2.1. Error Response - "error" +specified in OAuth 2.0 <> (4.1.2.1. Error Response - "error" parameter). Valid values are: invalid_request, unauthorized_client, access_denied, unsupported_response_type, invalid_scope, server_error, and temporarily_unavailable. @@ -692,7 +678,9 @@ An example query string: ---- GET -https://web-connect.dnsprovider.example/v2/domainTemplates/providers/exampleservice.example/services/template1/apply?domain=example.com&IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello +https://web-connect.dnsprovider.example/v2/domainTemplates/providers/ +exampleservice.example/services/template1/apply?domain=example.com +&IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello ---- This call indicates that the Service Provider wishes to connect the @@ -702,7 +690,7 @@ owned by them (template1). In this example, there are two variables in this template, "IP" and "RANDOMTEXT". These variables are passed as name/value pairs. ==== Security Considerations - +===== Risk of phishing with open template parameters By applying a template with parameters there is a security consideration that must be taken into account. @@ -714,8 +702,7 @@ this link, they would land on the DNS Provider site to confirm the change. To the user, this would appear to be a valid request to configure the domain. Yet the IP would be hijacking the service. -Not all templates have this problem. But when they do, there are several -options. +Not all templates have this problem. But when they do, there are several options. ===== Disable Synchronous @@ -733,12 +720,12 @@ properly URL encoded and of the form: [source] ---- -sig=V2te9zWMU7G3plxBTsmYSJTvn2vzMvNwAjWQ%2BwTe91DxuJhdVf4cVc4vZBYfEYV7u5 -d7PzTO7se7OrkhyiB7TpoJJW1yB5qHR7HKM5SZldUsdtg5%2B1SzEtIX0Uq8b2mCmQF%2FuJ -GXpqCyFrEajvpTM7fFKPk1kuctmtkjV7%2BATcvNPLWY7KyE4%2Bqc8jpfN61cP5l8iA4krA -a3%2BfTro5cmWR8YUJ5yrnRs6KT4b5D71HFvOUk0sGEUddUUlsyRQKRHUFN6HjEya50YDHfZ -JlYHkHlK0xX6Yqeii9QZ2I35U9eJbSvZGQko5beqviWFXdsVDbvd3DYcbSHgJq9%2FXoMTTw -%3D%3D +sig=V2te9zWMU7G3plxBTsmYSJTvn2vzMvNwAjWQ%2BwTe91DxuJhdVf4cVc4vZBYfEYV +7u5d7PzTO7se7OrkhyiB7TpoJJW1yB5qHR7HKM5SZldUsdtg5%2B1SzEtIX0Uq8b2mCmQ +F%2FuJGXpqCyFrEajvpTM7fFKPk1kuctmtkjV7%2BATcvNPLWY7KyE4%2Bqc8jpfN61cP +5l8iA4krAa3%2BfTro5cmWR8YUJ5yrnRs6KT4b5D71HFvOUk0sGEUddUUlsyRQKRHUFN6 +HjEya50YDHfZJlYHkHlK0xX6Yqeii9QZ2I35U9eJbSvZGQko5beqviWFXdsVDbvd3DYcb +SHgJq9%2FXoMTTw%3D%3D ---- The Service Provider generates this signature using a private key. As indicated, @@ -763,12 +750,12 @@ records may exist for the DNS TXT query. For example, a public key of: [source] .Example public key (line breaks are there for brevity) ---- -MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN4BHkkv0SBjAzIc4gr -YLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzLIZLNyMfI6qiXnM+HMd4b -yp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfyR/XSEWC5u16EBNvRnNAOAvZYUd -WqVyQvXsjnxQot8KcK0QP8iHpoL/1dbdRy2opRPQ2FdZpovUgknybq/6FkeDtW7uCQ6Mvu4Q -xcUa3+WP9nYHKtgWip/eFxpeb+qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX2ZZVDvG3biTpeJz -6iRzjGg6MfGxXZHjI8weDjXrJwIDAQAB +MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN4BHkkv0SBjAzIc +4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzLIZLNyMfI6qiXnM ++HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfyR/XSEWC5u16EBNvRn +NAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1dbdRy2opRPQ2FdZpovUgknybq/6FkeD +tW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX +2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8weDjXrJwIDAQAB ---- may contain several TXT records. The records would be of the form: @@ -776,13 +763,13 @@ may contain several TXT records. The records would be of the form: [source] .Example public key broken down into DNS records (line breaks are there for brevity) ---- -p=1,a=RS256,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN4BH -kkv0SBjAzIc4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzLIZLNyM -fI6qiXnM+HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfy +p=1,a=RS256,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN +4BHkkv0SBjAzIc4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzL +IZLNyMfI6qiXnM+HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfy -p=2,a=RS256,d=R/XSEWC5u16EBNvRnNAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1dbd -Ry2opRPQ2FdZpovUgknybq/6FkeDtW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+qLvcLH -f1h0JXtxLVdyy6OLk3f2JRYUX2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8 +p=2,a=RS256,d=R/XSEWC5u16EBNvRnNAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1 +dbdRy2opRPQ2FdZpovUgknybq/6FkeDtW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+ +qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8 p=3,a=RS256,d=weDjXrJwIDAQAB @@ -877,7 +864,7 @@ url in the browser. As such it is recommend that enablement of a service be based on verification of changes to DNS. === Asynchronous Flow: OAuth - +==== General information Using the OAuth flow is a more advanced use case needed by Service Providers that have more complex configurations that may require multiple steps and/or are asynchronous from the user’s interaction. @@ -971,7 +958,7 @@ authorization code will be appended to this URI as a query parameter of Similar to the synchronous flow, upon error the DNS provider may append an error code as query parameter "error". These errors are also from the -oAuth 2.0 RFC 6749 (4.1.2.1. Error Response - "error" parameter). Valid +OAuth 2.0 <> (4.1.2.1. Error Response - "error" parameter). Valid values include: invalid_request, unauthorized_client, access_denied, unsupported_response_type, invalid_scope, server_error, and temporarilly_unavailable. An OPTIONAL error_description suitable for @@ -1044,7 +1031,7 @@ template required for conflict detection. This includes variables used in hosts data in certain TXT records. |======================================================================= -==== oAuth Flow: Requesting an Access Token +==== OAuth Flow: Requesting an Access Token [source] ---- @@ -1054,7 +1041,7 @@ POST ---- Once authorization has been granted, the Service Provider must use the -Authorization Code provided to request an Access Token. The oAuth +Authorization Code provided to request an Access Token. The OAuth specification recommends that the Authorization Code be a short lived token, and a reasonable recommended setting is ten minutes. As such this exchange needs to be completed before that time has expired or the @@ -1074,7 +1061,7 @@ user could create a domain that returns a false __domainconnect_ TXT record, and subsequently a JSON call to their own server for the API end point. By doing so, they could then run Domain Connect on their domain and retrieve the secret. -As such the urlAPI used for oAuth by the Service Provider should be maintained per DNS +As such the urlAPI used for OAuth by the Service Provider should be maintained per DNS Provider and not the value retrieved during discovery. The following table describes the POST parameters that must be included in the @@ -1187,7 +1174,8 @@ value vs. the value returned during discovery here as well. ---- POST -{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties] +{urlAPI}/v2/domainTemplates/providers/{providerId}/services +/{serviceId}/apply?[properties] ---- The primary function of the API is to apply a template to a customer @@ -1288,7 +1276,9 @@ passed as name/value pairs. ---- POST -https://connect.dnsprovider.example/v2/domainTemplates/providers/exampleservice.example/services/template1/apply?IP=192.0.2.42&RANDOMTEXT=shm%3A1542108821%3AHello&force=1 +https://connect.dnsprovider.example/v2/domainTemplates/providers/ +exampleservice.example/services/template1/apply?IP=192.0.2.42 +&RANDOMTEXT=shm%3A1542108821%3AHello&force=1 ---- The API must validate the access token, and that the domain belongs to @@ -1378,7 +1368,8 @@ Implementation of this call is OPTIONAL. If not supported a 501 MUST be returned ---- POST -{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/revert?domain={domain}&host={host} +{urlAPI}/v2/domainTemplates/providers/{providerId}/services +/{serviceId}/revert?domain={domain}&host={host} ---- This API allows the removal of a template from a customer domain/host @@ -1396,7 +1387,8 @@ An example query string might look like: ---- POST -https://connect.dnsprovider.example/v2/domainTemplates/providers/exampleservice.example/services/template1/revert?domain=example.com +https://connect.dnsprovider.example/v2/domainTemplates/providers +/exampleservice.example/services/template1/revert?domain=example.com ---- Allowed parameters: @@ -1432,8 +1424,7 @@ Response codes Success, Authorization, and Errors are identical to above with the addition of the 501 code. ==== OAuth Flow: Revoking access - -Like all oAuth flows, the user may revoke the access at any time using +Like all OAuth flows, the user may revoke the access at any time using UX at the DNS Provider site. As such the Service Provider needs to be aware that their access to the API may be denied. @@ -1475,7 +1466,7 @@ A template is defined as a standard JSON data structure containing the following |String |serviceId |(REQUIRED) The name or identifier of the template. -This is used in URLs to identify the template. It is also used in the scope parameter for oAuth. It must not contain space characters, and must be URL friendly. +This is used in URLs to identify the template. It is also used in the scope parameter for OAuth. It must not contain space characters, and must be URL friendly. |*Service Name* |String @@ -1618,28 +1609,20 @@ Each record will contain the following elements. |*Type* |enum -|type| -(REQUIRED) Describes the type of record in DNS, or the operation impacting DNS. +|type +|(REQUIRED) Describes the type of record in DNS, or the operation impacting DNS. + -Valid values include: A, AAAA, CNAME, MX, TXT, SRV, or SPFM +Valid values include: A, AAAA, CNAME, MX, TXT, SRV, or SPFM + -For each type, additional fields would be REQUIRED. - -A: host, pointsTo, TTL - -AAAA: host, pointsTo, TTL - -CNAME: host, pointsTo, TTL (host must not be null or @ unless `hostRequired` is defined `true` for the template) - -NS: host, pointsTo, TTL (host must not be null or @ unless `hostRequired` is defined `true` for the template) - -TXT: host, data, TTL, txtConflictMatchingMode, txtConflictMatchingPrefix - -MX: host, pointsTo, TTL, priority - -SRV: name, target, TTL, priority, protocol, service, weight, port - -SPFM: host, spfRules +For each type, additional fields would be REQUIRED. + +* A: host, pointsTo, TTL + +* AAAA: host, pointsTo, TTL + +* CNAME: host, pointsTo, TTL (host must not be null or @ unless `hostRequired` is defined `true` for the template) + +* NS: host, pointsTo, TTL (host must not be null or @ unless `hostRequired` is defined `true` for the template) + +* TXT: host, data, TTL, txtConflict-MatchingMode, txtConflict-MatchingPrefix + +* MX: host, pointsTo, TTL, priority + +* SRV: name, target, TTL, priority, protocol, service, weight, port + +* SPFM: host, spfRules + |*Group Id* |String @@ -1653,47 +1636,47 @@ not contain variables. |essential |(OPTIONAL) This parameter indicates how the record is treated during conflict detection with -existing templates. +existing templates. + -If the DNS Provider is not implementing applied template state in DNS this is ignored. +If the DNS Provider is not implementing applied template state in DNS this is ignored. + -Always (default) - record MUST be applied and kept with the template +Always (default) - record MUST be applied and kept with the template + OnApply - record MUST be applied but can be later removed without dropping the whole -template +template + |*Host* |String |host | -(REQUIRED) The host for A, AAAA, CNAME, NS, TXT, and MX values. +(REQUIRED) The host for A, AAAA, CNAME, NS, TXT, and MX values. + -This value is relative to the applied host and domain, unless trailed by a ".". +This value is relative to the applied host and domain, unless trailed by a ".". + A value of empty or @ indicates the root of the applied host and domain. In other words -"[host.]example.com.". +"[host.]example.com.". + This value should not contain variables unless absolutely necessary. This is discussed -below. +below. + |*Name* |String |name -|The name for the SRV record. +|The name for the SRV record. + This value is relative to the applied host and domain. A value of empty or @ indicates -the root of the applied host and domain. +the root of the applied host and domain. + This value should not contain variables unless absolutely necessary. This is discussed -below. +below. + |[[pointsto-record]]*Points To* |String |pointsTo | -The pointsTo location for A, AAAA, CNAME, NS and MX records. +The pointsTo location for A, AAAA, CNAME, NS and MX records. + -A value of empty or @ indicates the host and domain name being applied or [host.]example.com +A value of empty or @ indicates the host and domain name being applied or [host.]example.com + |*TTL* |Int @@ -1718,7 +1701,7 @@ None, All, or Prefix. The default value is None. <>. |*Priority* @@ -2091,7 +2074,8 @@ although is often inconsistent with the modifier. If a customer installed Mailer1 and Newsletter1, their combined SPF record ought to be something like: ---- -v=spf1 include:spf.mailer1.example include:_spf.newsletter.example ~all +v=spf1 include:spf.mailer1.example include:_spf.newsletter.example + ~all ---- We combined the two rules, and in this case picked the least restrictive all modifier. @@ -2103,7 +2087,8 @@ The challenge with SPF records and Domain Connect is that an individual service One solution to this problem is to merge all related records. At the highest level, this means taking everything between the “v=spf1” and the “all” from each of the records and merging them together, terminating with hard-coded modifier on _all_ at the end. For an SPF record to fulfill it's purpose of protection against malicious email delivery, Domain Connect advises a fixed modifier _"~"_ advising lower rating of the messages from other sources not specified in SPF. This setup offers a reasonable level of protection of mail delivery, on the other side does not reject the message in case forwarding facility is in place. ---- -@ TXT v=spf1 include:spf.mailer1.example include:_spf.newsletter.example ~all +@ TXT v=spf1 include:spf.mailer1.example include:_spf.newsletter.exam +ple ~all ---- The other would be to write intermediate records, and reference these locally. @@ -2139,7 +2124,7 @@ Some DNS Providers may decide not to support the SPFM record. The following alte [[repository-and-integrity]] === Public Template Repository - +==== General information The Public Template Repository is an open accessible location where Service Providers MAY publish their Service Templates in the format specified in this specification. DNS Providers MAY support all of the published templates, just a subset or none of them according @@ -2214,16 +2199,13 @@ One exception is the domain/host name. This is because a fully qualified domain The values for providerId/serviceId in the template and passed through URIs in the path or query string are case sensitive. Different rules apply to the file naming in the <>. == Extensions/Exclusions - -Additional record types and/or extensions to records in the template can -be implemented on a per DNS Provider basis. However, care should be -taken when defining extensions so as to not conflict with other +=== General information +Additional record types and/or extensions to records in the template can be implemented on a per DNS Provider basis. However, care should be taken when defining extensions so as to not conflict with other protocols and standards. Certain record names are reserved for use in -DNS for protocols like DNSSEC (DNSKEY, RRSIG) at the registry level. +DNS for protocols like DNSSEC (DNSKEY, RRSIG) <> at the registry level. Defining these OPTIONAL extensions in an open manner as part of this -specification is done to provide consistency. The following are the initial -OPTIONAL extensions a DNS Provider/Service Provider may support. +specification is done to provide consistency. The following are the initial OPTIONAL extensions a DNS Provider/Service Provider may support. === APEXCNAME @@ -2297,11 +2279,11 @@ The authors wish to thank the following persons for their feedback and suggestio - Roger Carney of GoDaddy Inc. - Chris Ambler of GoDaddy Inc. -- Jody Kolker of GoDaddy Inc. == Change History === Change from 03 to 04 - Version synchronized with 2.2 version rev. 66 of the public Domain Connect specification. + Version synchronized with 2.2 version rev. 66 of the public Domain + Connect specification. === Change from 02 to 03 @@ -2328,12 +2310,14 @@ The authors wish to thank the following persons for their feedback and suggestio == Normative References * [[[RFC2119,RFC 2119]]] +* [[[RFC7208,RFC 7208]]] +* [[[RFC6749,RFC 6749]]] [bibliography] == Informative References * [[[RFC8174,RFC 8174]]] -* [[[RFC7208,RFC 7208]]] +* [[[RFC9364,RFC 9364]]] [appendix] == Examples @@ -2348,7 +2332,7 @@ The authors wish to thank the following persons for their feedback and suggestio "serviceName": "Wordpress by example.com", "version": 1, "logoUrl": "https://www.example.com/images/billthecat.jpg", - "description": "This connects your domain to our super cool web hosting", + "description": "This connects your domain to our web hosting", "records": [ { "type": "A", @@ -2437,8 +2421,8 @@ Consider a DNS Zone before a template application: ---- $ORIGIN example.com. -@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 1800 -1209600 3600 +@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 +1800 1209600 3600 @ 3600 IN NS ns11.example.net. @ 3600 IN NS ns12.example.net. @ 3600 IN A 192.0.2.1 @@ -2482,14 +2466,15 @@ The following DNS Zone should be generated after the template is applied: ---- $ORIGIN example.com. -@ 3600 IN SOA ns11.example.net. support.example.net. 2017050920 7200 1800 -1209600 3600 +@ 3600 IN SOA ns11.example.net. support.example.net. 2017050920 7200 +1800 1209600 3600 @ 3600 IN NS ns11.example.net. @ 3600 IN NS ns12.example.net. @ 1800 IN A 203.0.113.2 @ 3600 IN MX 10 mx1.example.net. @ 3600 IN MX 10 mx2.example.net. -@ 1800 IN TXT "v=spf1 a include:spf.example.org include:spf.hoster.example ~all" +@ 1800 IN TXT "v=spf1 a include:spf.example.org include:spf.hoster.ex +ample ~all" www 1800 IN A 203.0.113.2 ---- @@ -2503,8 +2488,8 @@ Consider a DNS Zone before a template application: ---- $ORIGIN example.com. -@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 1800 -1209600 3600 +@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 +1800 1209600 3600 @ 3600 IN NS ns11.example.net. @ 3600 IN NS ns12.example.net. ---- @@ -2542,8 +2527,8 @@ Expected result in the DNS Zone ---- $ORIGIN example.com. -@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 1800 -1209600 3600 +@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 +1800 1209600 3600 @ 3600 IN NS ns11.example.net. @ 3600 IN NS ns12.example.net. @ 3600 IN MX 10 mx1.example.net. @@ -2570,11 +2555,13 @@ Expected result in the DNS Zone ---- $ORIGIN example.com. -@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 1800 -1209600 3600 +@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200 +1800 1209600 3600 @ 3600 IN NS ns11.example.net. @ 3600 IN NS ns12.example.net. @ 3600 IN MX 10 mx1.example.net. @ 3600 IN MX 10 mx2.example.net. -@ 3600 IN TXT "v=spf1 a include:spf.example.net include:_spf.newsletter.example ~all" +@ 3600 IN TXT "v=spf1 a include:spf.example.net include:_spf.newslett +er. +example ~all" ---- diff --git a/draft-kowalik-regext-domainconnect-00.err.html b/draft-kowalik-regext-domainconnect-00.err.html new file mode 100644 index 0000000..7ef7cdf --- /dev/null +++ b/draft-kowalik-regext-domainconnect-00.err.html @@ -0,0 +1,137 @@ +./draft-kowalik-regext-domainconnect-00.err.html errors + + +

./draft-kowalik-regext-domainconnect-00.err.html errors

+

Metanorma XML Syntax

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LineIDMessageContextSeverity
XML Line 000004:54attribute "format" not allowed here; expected attribute "locale",​ "script" or "type"
2
XML Line 000006:56attribute "format" not allowed here; expected attribute "locale",​ "script" or "type"
2
XML Line 000029:75element "workgroup" not allowed here; expected the element end-tag or element "committee"
2
XML Line 000030:88attribute "obligation" not allowed here; expected attribute "language", "numbered", "removeInRFC", "script" or "toc"
2
XML Line 000033:77attribute "obligation" not allowed here; expected attribute "language", "numbered", "removeInRFC", "script" or "toc"
2
XML Line 000398:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 001279:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 001849:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 001914:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002257:79attribute "inline-header" not allowed here; expected attribute "language", "numbered", "obligation", "removeInRFC", "script" or "toc"
2
XML Line 002261:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002309:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002328:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002368:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002420:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002459:68attribute "lang" not allowed here; expected attribute "markers" or "number"
2
XML Line 002486:40attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002493:143attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002495:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002497:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002499:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002502:40attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002509:143attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002512:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002514:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002517:40attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002524:143attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002526:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002528:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002532:40attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002539:143attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002540:94found attribute "format",​ but no attributes allowed here
2
XML Line 002542:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002544:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002546:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002548:40attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002555:143attribute "format" not allowed here; expected attribute "language", "locale" or "script"
2
XML Line 002557:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002559:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2
XML Line 002561:28attribute "format" not allowed here; expected attribute "language", "locale",​ "script" or "type"
2

+
diff --git a/draft-domain-connect-04.html b/draft-kowalik-regext-domainconnect-00.html
similarity index 59%
rename from draft-domain-connect-04.html
rename to draft-kowalik-regext-domainconnect-00.html
index 236e536..20c37ec 100644
--- a/draft-domain-connect-04.html
+++ b/draft-kowalik-regext-domainconnect-00.html
@@ -4,37 +4,34 @@
 
 
 
-Domain Connect API - Communications between DNS Provider and Services
-
-
+Domain Connect Protocol - DNS provisioning between Services and DNS Providers
 
+
+
+
 
-
-
+
+
 
-
+
 
 
 
 
         
         
 
-
+
 
 
-
+
-
-
+
+

 

 Internet-Draft
 Domain ConnectApril 2022July 2024
 

 
Carney, et al.Expires 29 October 2022Kowalik, et al.Expires 23 January 2025
 [Page]
 

 

@@ -1203,39 +1228,43 @@
 
Workgroup:

 
Registration Protocols Extensions

 
Internet-Draft:

-
draft-carney-regext-domainconnect-04

+
draft-kowalik-regext-domainconnect-00

 
:

 

 
Published:

 

-
+
     

 
Intended Status:

-
Informational

+
Standards Track

 
Expires:

-

+

 
Authors:

 

 

-      
R. Carney

-
GoDaddy Inc.

+      
P. Kowalik

+
DENIC eG

 

 

       
A. Blinn

 

 

-      
P. Kowalik

-
IONOS SE

+      
J. Kolker

+
GoDaddy Inc.

+

+

+      
S. Kerola

+
Cloudflare, Inc.

 

 

 
 
-
Domain Connect API - Communications between DNS Provider and Services

-

+
Domain Connect Protocol - DNS provisioning between Services and DNS Providers

+

 

       
Abstract

-

-
This document provides information related to the Domain Connect API that was built to support communications between DNS Providers and Service Providers (hosting, social, email, hardware, etc.).

+

+
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers.

 

 

 

@@ -1258,7 +1287,7 @@ 

         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."

 

-        This Internet-Draft will expire on 29 October 2022.

+        This Internet-Draft will expire on 23 January 2025.

 
 

 
 

@@ -1285,465 +1317,489 @@ 
 
 
 

-

+

 

+      

+1. Acknowledgements
+      

+

+
The authors wish to thank the following persons for their feedback and suggestions as well as for the previous work on the standard:

+

+
    
+
  • Roger Carney of GoDaddy Inc.
+
    • 
+        
  • Chris Ambler of GoDaddy Inc.
+
    • 
+      

+

+

+

+

       

-1. Introduction
+2. Introduction
       

 

-
Configuring a service at a Service Provider to work with a domain has historically been a complex task that is difficult for users.

+
Configuring a service at a Service Provider to work with a domain has historically been a complex task that is difficult for users.

 

 

-
Typically, a customer would try to configure their service by entering their domain name with the Service Provider. The Service Provider then used a number of techniques with mixed reliability to discover the DNS Provider. This might include DNS queries for nameservers, queries to whois, and mapping tables to determine the registrar or the company providing DNS.

+
Typically, a customer would try to configure their service by entering their domain name with the Service Provider. The Service Provider then used a number of techniques with mixed reliability to discover the DNS Provider. This might include DNS queries for nameservers, queries to whois, and mapping tables to determine the registrar or the company providing DNS.

 

 

-
Once the Service Provider discovered the DNS Provider, they typically gave the customer instructions for proper configuration of DNS. This might include help text, screen shots, or even links to the appropriate tools.

+
Once the Service Provider discovered the DNS Provider, they typically gave the customer instructions for proper configuration of DNS. This might include help text, screen shots, or even links to the appropriate tools.

 

 

-
Discovery of the DNS Provider in this manner is unreliable, and providing instructions to users would present a number of technologies (DNS record types, TTLs, Hostnames, etc.) and processes they didn't understand. These instructions authored by the Service Provider often quickly become out of date, further confusing the issue for users.

+
Discovery of the DNS Provider in this manner is unreliable, and providing instructions to users would present a number of technologies (DNS record types, TTLs, Hostnames, etc.) and processes they didn't understand. These instructions authored by the Service Provider often quickly become out of date, further confusing the issue for users.

 

 

-
The goal of this specificatoin is to create a system where Service Providers can easily enable their applications/services to work with the domain names of their customers. This includes both discovery of the DNS Provider and subsequent modification of DNS.

+
The goal of this specificatoin is to create a system where Service Providers can easily enable their applications/services to work with the domain names of their customers. This includes both discovery of the DNS Provider and subsequent modification of DNS.

 

 

-
The system will be implemented using simple web based interactions and
+
The system will be implemented using simple web based interactions and
 standard authentication protocols. The creation and modification of DNS
 settings will be done through the application of templates instead of
-direct manipulation of individual DNS records.

+direct manipulation of individual DNS records.

+

+

 

 

-

-        

-1.1. Terminology
-        

-

-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

-

-

-

-          
Service Providers

-          

-            

-
refers to entities that provide products and
+

+      

+3. Terminology
+      

+

+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

+

+

+

+        
Service Providers

+        

+          

+
refers to entities that provide products and
 services attached to domain names. Examples include web hosting
 providers (such as Wix or SquareSpace), email Service Providers (such as
 Microsoft or Google) and potentially even hardware manufacturers with
 DNS-enabled devices like home routers or automation controls (such as
-Linksys, Nest, and Philips).

+Linksys, Nest, and Philips).

 

 

-          

-
DNS Providers

-          

-            

-
refers to entities that provide DNS services such as
+        

+
DNS Providers

+        

+          

+
refers to entities that provide DNS services such as
 registrars (such as GoDaddy or 1and1) or standalone DNS services (like
-CloudFlare).

+Cloudflare).

 

 

-          

-
Registrar

-          

-            

-
refers to entities that register domain names with registries.
+        

+
Registrar

+        

+          

+
refers to entities that register domain names with registries.
 It is noted that the DNS Provider and Registrar can be different entities for a
-given domain name and DNS Zone.

+given domain name and DNS Zone.

 

 

-          

-
Customer/User

-          

-            

-
refers to the end-user of these services.

+        

+
Customer/User

+        

+          

+
refers to the end-user of these services.

 

 

-          

-
Templates/Service Templates

-          

-            

-
refers to a file that describes a set of
-changes to DNS and domain functionality to enable a specific service.

+        

+
Templates/Service Templates

+        

+          

+
refers to a file that describes a set of
+changes to DNS and domain functionality to enable a specific service.

 

 

-          

-
Public Template Repository

-          

-            

-
refers to a public repository of Templates
-in a standarised format (read more: Section 6.11).

+        

+
Public Template Repository

+        

+          

+
refers to a public repository of Templates
+in a standarised format (read more: Section 9.11).

 

 

-          

-
Root Domain

-          

-            

-
refers to a registered domain (e.g. example.com or
-example.co.uk), or to a delegated zone in DNS.

+        

+
Root Domain

+        

+          

+
refers to a registered domain (e.g. example.com or
+example.co.uk), or to a delegated zone in DNS.

 

 

-          

-
Sub Domain

-          

-            

-
refers to a sub-domain of a root domain (e.g.
-sub.example.com or sub.example.co.uk).

+        

+
Sub Domain

+        

+          

+
refers to a sub-domain of a root domain (e.g.
+sub.example.com or sub.example.co.uk).

 

 

-        

+      

 

 

 

 

-

-

 

-

+

       

-2. Protocol design
+4. Protocol design
       

 

-

+

         

-2.1. Templates
+4.1. Templates
         

-

-
Templates are core to Domain Connect, as they fully describe a service owned by
+

+
Templates are core to Domain Connect, as they fully describe a service owned by
 a Service Provider and contain all of the information necessary to
-enable and operate/maintain the service in the form of a set of records.

+enable and operate/maintain the service in the form of a set of records.

 

-

-
The individual records in a template may be identified by a groupId. This allows for
+

+
The individual records in a template may be identified by a groupId. This allows for
 the application of templates in different stages. For example, an email
 provider might first set a TXT record to verify the domain, and later
 set an MX record to configure email delivery. While done separately,
-both changes are fundamentally part of the same service.

+both changes are fundamentally part of the same service.

 

-

-
Templates may also contain variable portions, as often values of data in
+

+
Templates may also contain variable portions, as often values of data in
 DNS change based on the implementation and/or user of the
 service (e.g. the IP address of a service, a customer id,
-etc.).

+etc.).

 

-

-
The template is defined by the Service Provider and manually onboarded with the DNS
+

+
The template is defined by the Service Provider and manually onboarded with the DNS
 Provider, according to a template definition published in
-the Public Repository (Section 6.11) or agreed out-of-band between
-the Service Provider and the DNS Provider.

+the Public Repository (Section 9.11) or agreed out-of-band between
+the Service Provider and the DNS Provider.

 

-

-
By basing the protocol on templates instead of DNS Records, several
+

+
By basing the protocol on templates instead of DNS Records, several
 advantages are achieved. The DNS Provider has very explicit knowledge
 and control of the settings being changed to enable a service. And the
-system is more secure as templates are controlled and contained.

+system is more secure as templates are controlled and contained.

+

+

 

 

 

 

-

-        

-2.2. End User Flows
+

+      

+5. End User Flows
+      

+

+

+        

+5.1. General information
         

-

-
To attach a domain name to a service provided by a Service Provider, the
-customer would first enter their domain name.

-

-

-
Instead of relying on examination of the nameservers and mapping these
-to DNS Providers, DNS Provider discovery is handled through simple
-records in DNS and an API. The Service Provider queries for a specific
-record in the zone that returns a REST endpoint to initiate the
-protocol. When this endpoint is called, a Domain Connect compliant DNS Provider returns
-information about that domain and how to configure it using Domain
-Connect.

-

-

-
To apply the changes to DNS, there are two use cases. The
-first is a synchronous web flow, and the second is an asynchronous flow
-using oAuth and an API.

-

-

-
It is noted that a DNS Provider may choose to only implement one
-of the flows. As a matter of practice many Service Providers are based
-on the synchronous flow, with only a handful of them based on the
-asynchronous oAuth flow. So many DNS providers may opt to only implement
-the synchronous flow.

-

-

-
It is also be noted that individual services may work with the
-synchronous flow only, the asynchronous flow only, or with both.

+

+
To attach a domain name to a service provided by a Service Provider, the customer would first enter their domain name.

+

+

+
Instead of relying on examination of the nameservers and mapping these to DNS Providers, DNS Provider discovery is handled through simple records in DNS and an API. The Service Provider queries for a specific record in the zone that returns a REST endpoint to initiate the protocol. When this endpoint is called, a Domain Connect compliant DNS Provider returns information about that domain and how to configure it using Domain Connect.

+

+

+
To apply the changes to DNS, there are two use cases. The
+first is a synchronous web flow, and the second is an asynchronous flow using OAuth and an API.

+

+

+
It is noted that a DNS Provider may choose to only implement one of the flows. As a matter of practice many Service Providers are based on the synchronous flow, with only a handful of them based on the asynchronous OAuth flow. So many DNS providers may opt to only implement the synchronous flow.

+

+

+
It is also be noted that individual services may work with the synchronous flow only, the asynchronous flow only, or with both.

+

+

 

 

-

-          

-2.2.1. The Synchronous Flow
-          

-

-
This flow is tailored for the Service Provider that requires a one time
-synchronous change to DNS.

+

+        

+5.2. The Synchronous Flow
+        

+

+
This flow is tailored for the Service Provider that requires a one time
+synchronous change to DNS.

 

-

-
The user first enters their domain name at the Service Provider
-website.

+

+
The user first enters their domain name at the Service Provider
+website.

 

-

+

 

-            

-

+          

+

 
+-----------------------------------------------+
-| http://acmewebsiteserviceprovider.com         |
+| https://acmewebsiteserviceprovider.example    |
 +-----------------------------------------------+
 | ACME Web Site Service Provider                |
 |                                               |
@@ -1763,19 +1819,19 @@ 

 

 
Figure 1:
 Service Provider domain input
-            

+          
 

-

-
After the Service Provider determines the DNS Provider using discovery,
+

+
After the Service Provider determines the DNS Provider using discovery,
 the Service Provider should display a link to the user indicating
-that they can "Connect their Domain" to the service.

+that they can "Connect their Domain" to the service.

 

-

+

 

-            

-

+          

+

 
+-----------------------------------------------+
-| http://acmewebsiteserviceprovider.com         |
+| https://acmewebsiteserviceprovider.example    |
 +-----------------------------------------------+
 | ACME Web Site Service Provider                |
 |                                               |
@@ -1792,33 +1848,33 @@ 

 

 
Figure 2:
 Service Provider displays discovery results and offers setup with a DNS provider
-            

+          
 

-

-
After clicking the link, the user is directed to a browser window on the
+

+
After clicking the link, the user is directed to a browser window on the
 DNS Provider's site. This may be done in another tab or in a new
 browser window, but may also be an in place navigation with a return
 url. This link passes the domain name being modified, the service
 provider/template being enabled, and any additional parameters (variables)
-needed to apply the template and configure the service.

+needed to apply the template and configure the service.

 

-

-
Once at the DNS Provider site, the user is asked to authenticate
-if necessary.

+

+
Once at the DNS Provider site, the user is asked to authenticate
+if necessary.

 

-

+

 

-            

-

+          

+

 
+-----------------------------------------------+
-| http://virtucondomains.com                    |
+| https://virtucondomains.example               |
 +-----------------------------------------------+
 | Virtucon Domains                              |
 |                                               |
 | Please sign in to Virtucon domains            |
 |                                               |
 |                 +-------------------------+   |
-| Login           |user@xyz.com             |   |
+| Login           |user@xyz.example         |   |
 |                 +-------------------------+   |
 |                                               |
 |                 +-------------------------+   |
@@ -1834,22 +1890,22 @@ 

 

 
Figure 3:
 DNS provider user authentication
-            

+          
 

-

-
After authenticating at the DNS Provider, the DNS Provider must verify
+

+
After authenticating at the DNS Provider, the DNS Provider must verify
 the DNS zone of the domain name is controlled by the user. The DNS Provider must verify
 other parameters passed in are valid, and must prompt the user for consent to
 make the changes to DNS. The DNS Provider may also warn
 the user of services that would be disabled by applying this change to
-DNS.

+DNS.

 

-

+

 

-            

-

+          

+

 
+-----------------------------------------------+
-| http://virtucondomains.com                    |
+| https://virtucondomains.example               |
 +-----------------------------------------------+
 | Virtucon Domains                              |
 |                                               |
@@ -1867,110 +1923,111 @@ 

 

 
Figure 4:
 User authorization at the DNS provider of the DNS setup for ACME
-            

+          
 

-

-
Assuming the user grants this consent, the DNS changes are be applied.

+

+
Assuming the user grants this consent, the DNS changes are be applied.

 

-

-
If invoked in a pop-up window or tab, the browser window should be closed
+

+
If invoked in a pop-up window or tab, the browser window should be closed
 after the changes are applied. If invoked in place, the user must be navigated back
-to the Service Provider after the changes are applied.

+to the Service Provider after the changes are applied.

 

 

 

 

-

-          

-2.2.2. The Asynchronous Flow
-          

-

-
The asynchronous oAuth flow is tailored for the Service Provider that
+

+        

+5.3. The Asynchronous Flow
+        

+

+
The asynchronous OAuth flow is tailored for the Service Provider that
 wishes to make changes to DNS asynchronously with respect to the user
 interaction, or wishes to make multiple or additional changes to DNS
-over time.

+over time.

 

-

-
The asynchronous flow begins similarly
+

+
The asynchronous flow begins similarly
 to the synchronous flow. The Service Provider determines the
 DNS Provider and links to a consent dialog at the DNS Provider. Once at
 the DNS Provider the user signs in, control of the DNS zone for the domain is
-verified, and consent is granted.

+verified, and consent is granted.

 

-

-
Instead of applying the DNS changes on user consent, OAuth access is
+

+
Instead of applying the DNS changes on user consent, OAuth access is
 granted to the Service Provider. An OAuth access code is generated and
 handed back to the Service Provider. The Service Provider then requests
-an access (bearer) token.

+an access (bearer) token.

 

-

-
The permission granted in the OAuth token is a right for the Service
+

+
The permission granted in the OAuth token is a right for the Service
 Provider to apply a requested template (or templates) to the specific
-domain (and specific subdomains) DNS under control of a specific user at the DNS Provider.

-

-

-
The Service Provider would later call the an API to apply a template
-using the access token.

+domain (and specific subdomains) DNS under control of a specific user at the DNS Provider.

 

-

-
Additional parameters must be passed as name/value pairs when applying
-the template.

+

+
The Service Provider would later call the API of the DNS provider to apply a template
+using the access token.

 

-

+

+
Additional parameters must be passed as name/value pairs when applying
+the template.

 

 

 

 

 

 

-

+

       

-3. DNS Provider Discovery
+6. DNS Provider Discovery
       

-

-
To facilitate discovery of the DNS Provider from a domain name DNS is utilized. This is
-done by returning a TXT record for _domainconnect in the zone.

+

+
To facilitate discovery of the DNS Provider from a domain name DNS is utilized. This is
+done by returning a TXT record for _domainconnect in the zone.

 

-

-
An example of the contents of this record:

+

+
An example of the contents of this record:

 

-

-

-
domainconnect.virtucondomains.com

+

+

+
domainconnect.virtucondomains.example

 

 

-

-
As a practical matter of implementation, the DNS Provider may or may not
+

+
As a practical matter of implementation, the DNS Provider may or may not
 contain a copy of this data in each and every zone. Instead, the DNS
 Provider must simply respond to the DNS query for the
-_domainconnect TXT record with the appropriate data.

+_domainconnect TXT record with the appropriate data.

 

-

-
How this is implemented is up to the DNS Provider.

+

+
How this is implemented is up to the DNS Provider.

 

-

-
For example, the DNS Provider may not store the data inside a TXT record
+

+
For example, the DNS Provider may not store the data inside a TXT record
 for the domain, opting instead to put a CNAME in the zone and have the
 TXT record in the target of the CNAME. Another DNS Provider may simply
 respond with the appropriate records at the DNS layer without having the data in each
-zone.

+zone.

 

-

-
The URL prefix returned is subsequently used by the Service Provider to
+

+
The URL prefix returned is subsequently used by the Service Provider to
 determine the additional settings for using Domain Connect on this
-domain at the DNS Provider. This is done by calling a REST API.

+domain at the DNS Provider. This is done by calling a REST API.

 

-

-

-
GET
+

+

+
GET
 
-https://{_domainconnect}/v2/{domain}/settings

+https://{_domainconnect}/v2/{domain}/settings

 

 

-

-
This must return a JSON structure containing the settings to use for Domain Connect on the domain name (passed in on the path) at the DNS Provider. This JSON structure must contain the following fields unless otherwise specified.

+

+
This must return a JSON structure containing the settings to use for
+Domain Connect on the domain name (passed in on the path) at the DNS
+Provider. This JSON structure must contain the following fields unless
+otherwise specified.

 

-

+

 
-            
+            
-            
+            
-            
+            

         
 Table 1:
@@ -1999,8 +2056,8 @@ 

 
             
providerId
             StringUnique identifier for the DNS Provider. To ensure non-coordinated uniqueness,
-this should be the domain name of the DNS Provider (e.g. virtucom.com).(REQUIRED) Unique identifier for the DNS Provider. To ensure non-coordinated uniqueness,
+this should be the domain name of the DNS Provider (e.g. virtucom.example).
           

           

             
@@ -2008,7 +2065,7 @@ 

 

             providerName
             StringThe name of the DNS Provider.(REQUIRED) The name of the DNS Provider.
           

           

             
@@ -2045,7 +2102,7 @@ 

 

             urlAPI
             StringThe URL Prefix for the REST API(REQUIRED) The URL Prefix for the REST API
           

           

             
@@ -2091,41 +2148,40 @@ 

         

       

 

-

-
As an example, the JSON returned by this call might contain.

-

-

-

-
{
-    "providerId": "virtucondomains.com",
+

+

+
{
+    "providerId": "virtucondomains.example",
     "providerName": "Virtucon Domains",
     "providerDisplayName": "Virtucon Domains",
-    "urlSyncUX": "https://domainconnect.virtucondomains.com",
-    "urlAsyncUX": "https://domainconnect.virtucondomains.com",
-    "urlAPI": "https://api.domainconnect.virtucondomains.com",
+    "urlSyncUX": "https://domainconnect.virtucondomains.example",
+    "urlAsyncUX": "https://domainconnect.virtucondomains.example",
+    "urlAPI": "https://api.domainconnect.virtucondomains.example",
     "width": 750,
     "height": 750,
-    "urlControlPanel": "https://domaincontrolpanel.virtucondomains.com/?domain=%domain%",
-    "nameServers": ["ns01.virtucondomainsdns.com", "ns02.virtucondomainsdns.com"]
-}

+    "urlControlPanel": "https://domaincontrolpanel.virtucondomains.ex
+    ample/?domain=%domain%",
+    "nameServers": ["ns01.virtucondomainsdns.example", "ns02.virtucon
+    domainsdns.example"]
+}

 

 

-

-
Discovery must work on the root domain (zone) only. Bear in mind that
+

+
Discovery must work on the root domain (zone) only. Bear in mind that
 zones can be delegated to other users, making this information valuable to
 Service Providers since DNS changes may be different for an apex zone vs.
-a sub-domain for an individual service.

+a sub-domain for an individual service.

 

-

-
The Service Provider must handle the condition when a query for the
+

+
The Service Provider must handle the condition when a query for the
 _domainconnect TXT record suceeds, but a call to query for the JSON fails.
 This can happen if the zone is hosted with another DNS Provider, but contains an
-incorrect _domainconnect TXT record.

+incorrect _domainconnect TXT record.

 

-

-
The DNS Provider must return a 404 if they do not contain the zone.

+

+
The DNS Provider must return a 404 if they do not contain the zone.

 

-

+

 

         
 Table 2:
@@ -2160,83 +2216,84 @@ 

 
 
 

-

+

       

-4. Applying Domain Connect
+7. Applying Domain Connect
       

 

-

+

         

-4.1. Endpoints
+7.1. Endpoints
         

-

-
The Domain Connect endpoints returned in the JSON during
-discovery are in the form of URLs.

+

+
The Domain Connect endpoints returned in the JSON during
+discovery are in the form of URLs.

 

-

-
The first set of endpoints are for the UX that the Service Provider
+

+
The first set of endpoints are for the UX that the Service Provider
 links to. These are for the synchronous flow where the user can click
 to grant consent and have changes applied, and for the
-asynchronous oAuth flow where the user can grant consent for
-OAuth access.

+asynchronous OAuth flow where the user can grant consent for
+OAuth access.

 

-

-
The second set of endpoints are for the REST API.

+

+
The second set of endpoints are for the REST API.

 

-

-
All endpoints begin with a root URL for the DNS Provider such as:

+

+
All endpoints begin with a root URL for the DNS Provider such as:

 

-

-

-
https://connect.dnsprovider.com

+

+

+
https://connect.dnsprovider.example

 

 

-

-
They may also include any prefix at the discretion of the DNS Provider.
-For example:

+

+
They may also include any prefix at the discretion of the DNS Provider.
+For example:

 

-

-

-
https://connect.dnsprovider.com/api

+

+

+
https://connect.dnsprovider.example/api

 

 

-

-
The root URLs for the UX endpoints and the API endpoints are returned in
-the JSON payload during DNS Provider discovery.

+

+
The root URLs for the UX endpoints and the API endpoints are returned in
+the JSON payload during DNS Provider discovery.

 

 

 

 

-

+

         

-4.2. Synchronous Flow
+7.2. Synchronous Flow
         

 

-

+

           

-4.2.1. Query Supported Template
+7.2.1. Query Supported Template
           

-

-

-
GET
+

+

+
GET
 
-{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}

+{urlAPI}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}

 

 

-

-
This URL is be used by the Service Provider to determine if the DNS
-Provider supports a specific template through the synchronous flow.

+

+
This URL is be used by the Service Provider to determine if the DNS
+Provider supports a specific template through the synchronous flow.

 

-

-
Returning a status of 200 without a body indicates the template is supported.
+

+
Returning a status of 200 without a body indicates the template is supported.
 The DNS provider may decide to disclose the version of the template
-in a JSON object with field version (see: version field (Section 5.2))
-or the full JSON object of deployed template.

+in a JSON object with field version (see: version field (Section 8.2)
+or the full JSON object of deployed template.

 

-

-
Returning a status of 404 indicates the template is not supported.

+

+
Returning a status of 404 indicates the template is not supported.

 

-

+

 

             
 Table 3:
@@ -2271,118 +2328,126 @@ 

 
 
 

-

+

           

-4.2.2. Apply Template
+7.2.2. Apply Template
           

-

-

-
GET
+

+

+            

+7.2.2.1. Apply Template URL
+            

+

+

+
GET
 
-{urlSyncUX}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties]

+{urlSyncUX}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}/apply?[properties]

+

 

+

+
This is the URL where the user is sent to apply a template to a domain they own.
+It is called from the Service Provider to start the synchronous Domain Connect Protocol.

 

-

-
This is the URL where the user is sent to apply a template to a domain they own.
-It is called from the Service Provider to start the synchronous Domain Connect Protocol.

+

+
This URL can be called in one of two ways.

 

-

-
This URL can be called in one of two ways.

+

 

 

-

+

             

-4.2.2.1. New Browser Window
+7.2.2.2. New Browser Window
             

-

-
The first is through a new browser tab or in a popup browser window.
+

+
The first is through a new browser tab or in a popup browser window.
 The DNS Provider signs the user
 in if necessary, verifies domain ownership, and asks for confirmation
 before application of the template. After application of the template,
-the DNS Provider should automatically close the browser tab or window.

+the DNS Provider should automatically close the browser tab or window.

 

 

 

 

-

+

             

-4.2.2.2. Same Browser Window
+7.2.2.3. Same Browser Window
             

-

-
The second is in the current browser tab/window. As above the DNS
+

+
The second is in the current browser tab/window. As above the DNS
 Provider signs the user in if necessary, verifies the user control of the DNS Zone for the domain,
 and asks for confirmation before application of the template. After
 application of the template (or cancellation by the user), the DNS
-Provider must redirect the browser to a return URL (redirect_uri).

+Provider must redirect the browser to a return URL (redirect_uri).

 

-

-
Several parameters must be appended to the end of this redirect_uri.

+

+
Several parameters must be appended to the end of this redirect_uri.

 

 
    
-
  • 
-                
    
-
    State
    
+
  • 
+                
    
+
    State
    
 
    
-
    
-
    If a state parameter is passed in on the query string, this must be
-passed back as state= on the redirect_uri.
    
+
    
+
    If a state parameter is passed in on the query string, this must be
+passed back as state= on the redirect_uri.
    
 
    
 
    • 
-              
  • 
-                
    
-
    Error
    
+              
  • 
+                
    
+
    Error
    
 
    
-
    
-
    If authorization could not be obtained or an error has occurred, the
+
    
+
    If authorization could not be obtained or an error has occurred, the
 parameter error= must be appended. For consistency with the asynchronous
 OAuth flows the valid values for the error parameter will be as
-specified in OAuth 2.0 RFC 6749 (4.1.2.1. Error Response - "error"
+specified in OAuth 2.0 [RFC6749] (4.1.2.1. Error Response - "error"
 parameter). Valid values are: invalid_request, unauthorized_client,
 access_denied, unsupported_response_type, invalid_scope, server_error,
-and temporarily_unavailable.
    
+and temporarily_unavailable.
    
 
    
 
    • 
-              
  • 
-                
    
-
    Error Description
    
+              
  • 
+                
    
+
    Error Description
    
 
    
-
    
-
    When an error occurs, an OPTIONAL error description containing a
-developer focused error description may be returned.
    
+
    
+
    When an error occurs, an OPTIONAL error description containing a
+developer focused error description may be returned.
    
 
    
-
    
-
    Under normal
+
    
+
    Under normal
 operation the access_denied error can be returned for a number of
 reasons. For example, the user may not have access to the account that
 owns the domain. Even if they do and successfully sign-in, the account
-or the domain may be suspended.
    
+or the domain may be suspended.
    
 
    
-
    
-
    It is unlikely that the DNS Provider would want to leak this information
-to the Service Provider, and as such the description may be vague.
    
+
    
+
    It is unlikely that the DNS Provider would want to leak this information
+to the Service Provider, and as such the description may be vague.
    
 
    
-
    
-
    There is one piece of information that may be interesting to communicate
+
    
+
    There is one piece of information that may be interesting to communicate
 to the Service Provider. This is when the end user decided to cancel the
 operation. If the DNS Provider wishes to communicate this to the
 Service Provider, when the error=access_denied the error_description may
 contain the prefix "user_cancel". Again, this is left to the discretion
-of the DNS Provider.
    
+of the DNS Provider.
    
 
    
 
    • 
             

-

-
To prevent an open redirect, unless the request is digitally signed the redirect_uri
-must be within the domains specified in the template in syncRedirectDomain.

+

+
To prevent an open redirect, unless the request is digitally signed the redirect_uri
+must be within the domains specified in the template in syncRedirectDomain.

 

 

 

 

-

+

             

-4.2.2.3. Parameters/properties
+7.2.2.4. Parameters/properties
             

-

+

 
-                  
@@ -2436,7 +2501,7 @@ 

                     Name/Value Pairs
 
                   

-                  
@@ -2478,350 +2543,386 @@ 

                   

+                
+                  
+                  
+                  
+                

               
 Table 4:
@@ -2401,7 +2466,7 @@ 

                     Domain
 
                   
domainThe domain name being configured. This is the root domain (the
+                  (REQUIRED) The domain name being configured. This is the root domain (the
 registered domain or delegated zone).
                 

                 
*Any key that will be used as a replacement for the "% surrounded" variables in the
+                  (REQUIRED) Any key that will be used as a replacement for the "% surrounded" variables in the
 template. The name portion of this API call corresponds to
 the variable(s) specified in the template and the value corresponds to the value that will
 be used when applying the template.sig
                   (OPTIONAL) A signature of the query string. See Security Considerations section below.
                 

+                    Key
+key(OPTIONAL) A value containing the host in DNS where the public key for the signature can be
+obtained. The domain for this host is in the template in syncPubKeyDomain. See Security
+Considerations section below.

               
             

 

-

-
An example query string:

+

+
An example query string:

 

-

-

-
GET
+

+

+
GET
 
-https://web-connect.dnsprovider.com/v2/domainTemplates/providers/exampleservice.domainconnect.org/services/template1/apply?domain=example.com&IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello

+https://web-connect.dnsprovider.example/v2/domainTemplates/providers/
+exampleservice.example/services/template1/apply?domain=example.com
+&#x26;IP=192.168.42.42&#x26;RANDOMTEXT=shm%3A1542108821%3AHello

 

 

-

-
This call indicates that the Service Provider wishes to connect the
+

+
This call indicates that the Service Provider wishes to connect the
 domain example.com to the service using the template identified by the
-composite key of the provider (exampleservice.domainconnect.org) and the service template
+composite key of the provider (exampleservice.example) and the service template
 owned by them (template1). In this example, there are two variables in this
-template, "IP" and "RANDOMTEXT". These variables are passed as name/value pairs.

+template, "IP" and "RANDOMTEXT". These variables are passed as name/value pairs.

 

 

 

 
 
 

-

+

           

-4.2.3. Security Considerations
+7.2.3. Security Considerations
           

-

-
By applying a template with parameters there is a security
-consideration that must be taken into account.

+

+

+            

+7.2.3.1. Risk of phishing with open template parameters
+            

+

+
By applying a template with parameters there is a security
+consideration that must be taken into account.

 

-

-
Consider the template above where the IP address of the A record is
+

+
Consider the template above where the IP address of the A record is
 passed in through a variable. A bad actor could generate a URL with a
 malicious IP and phish users by sending out emails asking them to "re-configure" their
 service. If an end user is convinced to click on
 this link, they would land on the DNS Provider site to confirm the
 change. To the user, this would appear to be a valid request to
-configure the domain. Yet the IP would be hijacking the service.

+configure the domain. Yet the IP would be hijacking the service.

 

-

-
Not all templates have this problem. But when they do, there are several
-options.

+

+
Not all templates have this problem. But when they do, there are several options.

+

+

 

 

-

+

             

-4.2.3.1. Disable Synchronous
+7.2.3.2. Disable Synchronous
             

-

-
One option is to disable the synchronous flow and use
+

+
One option is to disable the synchronous flow and use
 asynchronous OAuth. This can be controlled with the syncBlock
 value from the template. However, as will be seen below OAuth has a higher
 implementation burden and requires onboarding between each Service and
-DNS Provider.

+DNS Provider.

 

 

 

 

-

+

             

-4.2.3.2. Digitally Sign Requests
+7.2.3.3. Digitally Sign Requests
             

-

-
Another option is to digitally sign the query string. A
+

+
Another option is to digitally sign the query string. A
 signature is appended as an additional query string parameter,
-properly URL encoded and of the form:

+properly URL encoded and of the form:

 

-

-

-
sig=NLOQQm6ikGC2FlFvFZqIFNCZqlaC4B%2FQDwS6iCwIElMWhXMgRnRE17zhLtdLFieWkyqKa4I%2FOoFaAgd%2FAl%2ByzDd3sM2X1JVF5ELjTlj84jZ4KOEIdnbgkEeO%2FTkYRrPkwcmcHMwc4RuX%2Fqio8vKYxJaKLKeVGpUNSKo7zkq3XIRgyxoLSRKxmlSTHFAz4LvYXPWo6SHDoVcRvElWj18Um13sSXuX4KhtOLym2yImHpboEi4m2Ziigc%2BNHZE0VvHUR7wZgDaB01z8hFm5ATF%2B8swjandMRf2Lr4Syv4qTxMNT61r62EWFkt5t9nhxMgss6z4pfDVFZ3vYwSJDGuRpEQ%3D%3D

+

+

+
sig=V2te9zWMU7G3plxBTsmYSJTvn2vzMvNwAjWQ%2BwTe91DxuJhdVf4cVc4vZBYfEYV
+7u5d7PzTO7se7OrkhyiB7TpoJJW1yB5qHR7HKM5SZldUsdtg5%2B1SzEtIX0Uq8b2mCmQ
+F%2FuJGXpqCyFrEajvpTM7fFKPk1kuctmtkjV7%2BATcvNPLWY7KyE4%2Bqc8jpfN61cP
+5l8iA4krAa3%2BfTro5cmWR8YUJ5yrnRs6KT4b5D71HFvOUk0sGEUddUUlsyRQKRHUFN6
+HjEya50YDHfZJlYHkHlK0xX6Yqeii9QZ2I35U9eJbSvZGQko5beqviWFXdsVDbvd3DYcb
+SHgJq9%2FXoMTTw%3D%3D

 

 

-

-
The Service Provider generates this signature using a private key. As indicated,
-this signature is generated from the query string properly URL encoded.

+

+
The Service Provider generates this signature using a private key. As indicated,
+this signature is generated from the query string properly URL encoded.

 

-

-
The Service provider must publish their public key and place it in a DNS TXT
+

+
The Service provider must publish their public key and place it in a DNS TXT
 record in a domain specified in the template in syncPubKeyDomain. To allow for key
-rotation, the host name of the TXT record must be appended as another variable on the query string of the form:

+rotation, the host name of the TXT record must be appended as another variable on the query string of the form:

 

-

-

-
key=_dcpubkeyv1

+

+

+
key=_dcpubkeyv1

 

 

-

-
This example indicates that the public key can be found by doing a DNS
+

+
This example indicates that the public key can be found by doing a DNS
 query for a TXT record called _dcpubkeyv1 in the domain specified in the
-syncPubKeyDomain from the template.

-

-

-
To account for DNS Servers with limits to the size of a TXT record, multiple
-records may exist for the DNS TXT query. For example, a public key of:

-

-

-

-
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1dCqv7JEzUOfbhWKB9mTRsv3O9Vzy1Tz3UQlIDGpnVrTPBJDQTXUhxUMREEOBKo+rOjHZqfYnSmlkgu1dnBEO8bsELQL8GjS4zsjdA53gRk2SDxuzcB4fK+NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf50qP2/jMNs2G+KTlk3dBHx3wtqYLvdcop1Tk5xBD64BPJ9uwm8KlDNHe+8O+cC9j04Ji8B2K0/PzAj90xnb8XJy/EM124hpT9lMgpHKBUvdeurJYweC6oP41gsTf5LrpjnyIy9j5FHPCQIDAQAB

-

-

-

-
may contain several TXT records. The records would be of the form:

-

-

-

-
p=1,a=RS256,t=x509,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1dCqv7JEzUOfbhWKB9mTRsv3O9Vzy1Tz3UQlIDGpnVrTPBJDQTXUhxUMREEOBKo+rOjHZqfYnSmlkgu1dn
-
-p=2,a=RS256,t=x509,d=BEO8bsELQL8GjS4zsjdA53gRk2SDxuzcB4fK+NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf5
+syncPubKeyDomain from the template.

+

+

+
To account for DNS Servers with limits to the size of a TXT record, multiple
+records may exist for the DNS TXT query. For example, a public key of:

+

+

+

+
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN4BHkkv0SBjAzIc
+4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzLIZLNyMfI6qiXnM
++HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfyR/XSEWC5u16EBNvRn
+NAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1dbdRy2opRPQ2FdZpovUgknybq/6FkeD
+tW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX
+2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8weDjXrJwIDAQAB

+

+

+

+
may contain several TXT records. The records would be of the form:

+

+

+

+
p=1,a=RS256,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN
+4BHkkv0SBjAzIc4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzL
+IZLNyMfI6qiXnM+HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfy
 
-p=3,a=RS256,t=x509,d=NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf50qP2/jMNs2G+KTlk3dBHx3wtqYLvdcop1Tk5xBD64BPJ9
+p=2,a=RS256,d=R/XSEWC5u16EBNvRnNAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1
+dbdRy2opRPQ2FdZpovUgknybq/6FkeDtW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+
+qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8
 
-p=4,a=RS256,t=x509,d=uwm8KlDNHe+8O+cC9j04Ji8B2K0/PzAj90xnb8XJy/EM124hpT9lMgpHKBUvdeurJYweC6oP41gsTf5LrpjnyIy9j5FHPCQIDAQAB

+p=3,a=RS256,d=weDjXrJwIDAQAB
 

 

-

-
Here the public key is broken into four records in DNS, and the data
+

+
Here the public key is broken into four records in DNS, and the data
 also indicates that the signing algorithm is an RSA Signature with
 SHA-256 using an x509 certificate. The value for "a" if omitted will be
-assumed to be RS256, and for "t" will be assumed to be x509.

+assumed to be RS256, and for "t" will be assumed to be x509.

 

-

-
Note: The only algorithm currently supported is SHA-256 with x509 certificates. The values
-are placed here for future compatibility.

+

+
Note: The only algorithm currently supported is SHA-256 with x509 certificates. The values
+are placed here for future compatibility.

 

-

-
The above data was generated for a query string:

+

+
The above data was generated for a query string:

 

-

-

-
a=1&b=2&ip=10.10.10.10&domain=foobar.com

+

+

+
a=1&b=2&ip=10.10.10.10&domain=example.net

 

 

-

-
Signing the query string by the Service Provider is OPTIONAL. Not
+

+
Signing the query string by the Service Provider is OPTIONAL. Not
 all Services Provider templates require or are able to provide this level of security.
 Presence of the syncPubKeyDomain in the template indicates that the template requires
-signature verification.

+signature verification.

 

-

-
Notes:

+

+
Notes:

 

-

-
The digital signature will be generated on the full query string only,
-excluding the sig and key parameters. This is everything after the ?, except the sig and key values.

+

+
The digital signature will be generated on the full query string only,
+excluding the sig and key parameters. This is everything after the ?, except the sig and key values.

 

-

-
The values of each query string value key/value pair must be properly URL Encoded
-before the signature is generated.

+

+
The values of each query string value key/value pair must be properly URL Encoded
+before the signature is generated.

 

 

 

 

-

+

             

-4.2.3.3. Warnings
+7.2.3.4. Warnings
             

-

-
Some applications aren't able to use OAuth and/or sign requests.

+

+
Some applications aren't able to use OAuth and/or sign requests.

 

-

-
If the template require variables, and OAuth and signing isn't available,
-the flag warnPhishing must be set to true in the template.

+

+
If the template require variables, and OAuth and signing isn't available,
+the flag warnPhishing must be set to true in the template.

 

-

-
When set this indicates to the DNS Provider that they should display extra warnings to
+

+
When set this indicates to the DNS Provider that they should display extra warnings to
 the user to have them verify the link was/is from a reputable source before applying
-the template.

+the template.

 

 

 

 

 

 

-

+

           

-4.2.4. Shared Templates
+7.2.4. Shared Templates
           

-

-
Some templates can be called by multiple companies, or be used for different purposes.

+

+
Some templates can be called by multiple companies, or be used for different purposes.

 

-

-
For example, most services are sold and provided by the same company. However, some
+

+
For example, most services are sold and provided by the same company. However, some
 Service Providers have a reseller channel. This allows the service to be
 provided by the Service Provider, but sold through third parties.
-It is often this third party reseller that configures DNS.

+It is often this third party reseller that configures DNS.

 

-

-
While each reseller could enable Domain Connect, this is inefficient for
+

+
While each reseller could enable Domain Connect, this is inefficient for
 the DNS Providers. Enabling a single template that is shared by multiple
-resellers would be more optimal.

+resellers would be more optimal.

 

-

-
As another example, some templates may be used for different purposes by the same company.

+

+
As another example, some templates may be used for different purposes by the same company.

 

-

-
To facilitate these use cases, the ability to pass in additional context for the display
+

+
To facilitate these use cases, the ability to pass in additional context for the display
 of the providerName and serviceName is enabled. This is only allowed when the template enables the capability
-through the sharedProviderName and/or sharedServiceName flags.

+through the sharedProviderName and/or sharedServiceName flags.

 

-

-
Note: The shared flag used to be used for this purpose, but has been deprecated.

+

+
Note: The shared flag used to be used for this purpose, but has been deprecated.

 

-

-
The exact message presented to the user is up to the DNS Provider. However it is recommended
+

+
The exact message presented to the user is up to the DNS Provider. However it is recommended
 that these fields be used to augment the display of the serviceName and providerName from the template,
-not replace it.

+not replace it.

 

-

-
Note: When a Service Provider has a large reseller channel, it is highly
+

+
Note: When a Service Provider has a large reseller channel, it is highly
 recommended that the Service Provider creates an API for their resellers
 to ease the implementation of Domain Connect. There are elements of convenience in doing
 this around Domain Discovery and URL Formatting. But this would be required
-if the template required signatures.

+if the template required signatures.

 

 

 

 

-

+

           

-4.2.5. Verification of Changes
+7.2.5. Verification of Changes
           

-

-
There are circumstances where the Service Provider may wish to verify
+

+
There are circumstances where the Service Provider may wish to verify
 that the template was successfully applied. Without Domain Donnect, this
 typically involved the Service Provider querying DNS to see if the
-changes to DNS had been made.

+changes to DNS had been made.

 

-

-
This same technique works with Domain Connect, and if necessary can be
+

+
This same technique works with Domain Connect, and if necessary can be
 triggered either manually on the Service Provider site or automatically
 upon page/window activation in the browser when the browser window for
-the DNS Provider is closed.

+the DNS Provider is closed.

 

-

-
When the redirect_uri is used and an error is not present in the URI,
+

+
When the redirect_uri is used and an error is not present in the URI,
 the Service Provider can not assume the changes were applied to DNS. While true in most
 circumstances, users can tamper with or alter the return
 url in the browser. As such it is recommend that enablement of a service
-be based on verification of changes to DNS.

+be based on verification of changes to DNS.

 

 

 

 
 
 

-

+

         

-4.3. Asynchronous Flow: OAuth
+7.3. Asynchronous Flow: OAuth
         

-

-
Using the OAuth flow is a more advanced use case needed by Service
+

+

+          

+7.3.1. General information
+          

+

+
Using the OAuth flow is a more advanced use case needed by Service
 Providers that have more complex configurations that may require
-multiple steps and/or are asynchronous from the user's interaction.

+multiple steps and/or are asynchronous from the user's interaction.

 

-

-
Details of an OAuth implementation are beyond the scope of this
+

+
Details of an OAuth implementation are beyond the scope of this
 specification. Instead, an overview of how OAuth is used by Domain
-Connect is given here.

+Connect is given here.

 

-

-
Not all DNS Providers will support the asyncronous flow. As such it is
+

+
Not all DNS Providers will support the asyncronous flow. As such it is
 recommended that Service Providers relying on an OAuth implementation also
-implement a synchronous implementation.

+implement a synchronous implementation.

+

+

 

 

-

+

           

-4.3.1. OAuth Flow: Setup
+7.3.2. OAuth Flow: Setup
           

-

-
Service providers wishing to use the OAuth flow must register as an
+

+
Service providers wishing to use the OAuth flow must register as an
 OAuth client with each DNS provider. This is a manual
-process.

+process.

 

-

-
To register, the Service Provider would provide (in addition to their
+

+
To register, the Service Provider would provide (in addition to their
 template) any configuration necessary for the DNS Providers OAuth
 implementation. This includes valid URLs and Domains for redirects upon
-success or errors.

+success or errors.

 

-

-
Note: The validity of redirects are very important in any OAuth implementation.
+

+
Note: The validity of redirects are very important in any OAuth implementation.
 Most OAuth vulnerabilities are a combination of an open redirect and/or a
-compromised secret.

+compromised secret.

 

-

-
In return, the DNS provider will give the Service Provider a client id
+

+
In return, the DNS provider will give the Service Provider a client id
 and a secret which will be used when requesting tokens. For simplicity the client
-id should be the same as the providerId.

+id should be the same as the providerId.

 

 

 

 

-

+

           

-4.3.2. OAuth Flow: Getting an Authorization Code
+7.3.3. OAuth Flow: Getting an Authorization Code
           

-

-

-
GET
+

+

+
GET
 
-{urlAsyncUX}/v2/domainTemplates/providers/{providerId}

+{urlAsyncUX}/v2/domainTemplates/providers/{providerId}

 

 

-

-
To initiate the OAuth flow the Service Provider first links to the DNS
-Provider to gain consent.

+

+
To initiate the OAuth flow the Service Provider first links to the DNS
+Provider to gain consent.

 

-

-
This endpoint is similar to the synchronous flow described above. The DNS Provider
+

+
This endpoint is similar to the synchronous flow described above. The DNS Provider
 must authenticate the user, verify the user has control of the DNS Zone for the domain, and ask the user for
 permission. Instead of permission to make a change to DNS, the permission
 is now to allow the Service Provider to
 make the changes on their behalf. Similarly the
 DNS Provider may warn the user that (the eventual)
 application of a template might change existing records and/or disrupt
-existing services attached to the domain.

+existing services attached to the domain.

 

-

-
While the variables for the applied template would be provided later,
+

+
While the variables for the applied template would be provided later,
 the values of some variables may be necessary to determine conflicts. As
 such, any variables impacting conflicting records should be provided
 in the consent flow. Today this includes variables in hosts, and
 variables in the data portion for certain TXT records. As conflict
-resolution evolves, this list may grow.

+resolution evolves, this list may grow.

 

-

-
The protocol allows for the Service Provider to gain consent to apply
+

+
The protocol allows for the Service Provider to gain consent to apply
 multiple templates. These templates are specified in the scope parameter. It
 also allows for the Service Provider to gain consent to apply these templates to the domain
 or to the domain with multiple sub-domains. These are specified in the domain and host
 parameter. If conflict detection is implemented
-by the DNS Provider, they should account for all permutations.

+by the DNS Provider, they should account for all permutations.

 

-

-
The scope parameter is a space separated list (as per the OAuth protocol)
+

+
The scope parameter is a space separated list (as per the OAuth protocol)
 of the template serviceIds. The host parameter is an OPTIONAL comma separated
 list of hosts. A blank entry for the host implies the template can be
-applied to the root domain. For example:

+applied to the root domain. For example:

 

-

+

 
-                
+                
-                
+                
-                
+                

             
 Table 5:
@@ -2839,46 +2940,46 @@ 

             
             

               
scope=t1+t2&domain=example.comscope=t1+t2=example.com
                 Templates "t1" and "t2" can be applied to example.com
               

               
scope=t1+t2&domain=example.com&host=sub1,sub2scope=t1+t2=example.com=sub1,sub2
                 Templates "t1" and "t2" can be applied to sub1.example.com or sub2.example.com
               

               
scope=t1+t2&domain=example.com&host=sub1,scope=t1+t2=example.com=sub1,
                 Templates "t1" and "t2" can be applied to example.com or sub1.example.com
               

             
           

 

-

-
Upon successful authorization/verification/consent from the user, the
+

+
Upon successful authorization/verification/consent from the user, the
 DNS Provider will direct the end user's browser to the redirect URI. The
 authorization code will be appended to this URI as a query parameter of
-"code=" as per the OAuth specification.

+"code=" as per the OAuth specification.

 

-

-
Similar to the synchronous flow, upon error the DNS provider may append
+

+
Similar to the synchronous flow, upon error the DNS provider may append
 an error code as query parameter "error". These errors are also from the
-oAuth 2.0 RFC 6749 (4.1.2.1. Error Response - "error" parameter). Valid
+OAuth 2.0 [RFC6749] (4.1.2.1. Error Response - "error" parameter). Valid
 values include: invalid_request, unauthorized_client, access_denied,
 unsupported_response_type, invalid_scope, server_error, and
 temporarilly_unavailable. An OPTIONAL error_description suitable for
 developers may also be returned at the discretion of the DNS Provider.
-The same considerations as in the synchronous flow apply here.

+The same considerations as in the synchronous flow apply here.

 

-

-
The state value passed into the call must be passed back on the query
-string as "state=".

+

+
The state value passed into the call must be passed back on the query
+string as "state=".

 

-

-
The following table describes the values in the query
+

+
The following table describes the values in the query
 string parameters for the request for the OAuth consent flow that must be included unless otherwise
-indicated

+indicated

 

-

+

 
-                
+                
-                
@@ -2919,7 +3020,7 @@ 

                   Redirect URI
 
                 

-                
@@ -2935,7 +3036,7 @@ 

                   Scope
 
                 

-                
@@ -2965,64 +3066,73 @@ 

 to pass state value back to the caller. It will be returned as a parameter appended to
 the redirect_url described above.
               

+              
+                
+                
+                
+              

             
 Table 6:
@@ -2897,7 +2998,7 @@ 

                   Domain
 
                 
domainThe domain name being configured. This is the root domain (the registered domain or delegated zone).(REQUIRED) The domain name being configured. This is the root domain (the registered domain or delegated zone).
               

               

                 
@@ -2911,7 +3012,7 @@ 

                   Client Id
 

                 client_idThe client id that was provided by the DNS provider to the service provider
+                (REQUIRED) The client id that was provided by the DNS provider to the service provider
 during registration. It is recommended that this should be the same as the providerId in the template.
               

               
redirect_uriThe location to direct the client's browser upon successful authorization or upon error.
+                (REQUIRED) The location to direct the client's browser upon successful authorization or upon error.
 Validation of the redirect_uri will be done by the DNS Provider to match the values provided during onboarding.
               

               
scopeThe OAuth scope corresponds to the requested templates. This is list of space separated
+                (REQUIRED) The OAuth scope corresponds to the requested templates. This is list of space separated
 serviceIds.
               

               

+                  Name/Value Pairs
+*(OPTIONAL) Any key that will be used as a replacement for the "% surrounded" value(s) in a
+template required for conflict detection. This includes variables used in hosts and
+data in certain TXT records.

             
           

 

 

 

 

-

+

           

-4.3.3. oAuth Flow: Requesting an Access Token
+7.3.4. OAuth Flow: Requesting an Access Token
           

-

-

-
POST
+

+

+
POST
 
-{urlAPI}/v2/oauth/access_token

+{urlAPI}/v2/oauth/access_token

 

 

-

-
Once authorization has been granted, the Service Provider must use the
-Authorization Code provided to request an Access Token. The oAuth
+

+
Once authorization has been granted, the Service Provider must use the
+Authorization Code provided to request an Access Token. The OAuth
 specification recommends that the Authorization Code be a short lived
 token, and a reasonable recommended setting is ten minutes. As such this
 exchange needs to be completed before that time has expired or the
-process will need to be repeated.

+process will need to be repeated.

 

-

-
This token exchange is typically done via a server to server API call from the
+

+
This token exchange is typically done via a server to server API call from the
 Service Provider to the DNS Provider using a POST. When called in this manner a
 secret is provided
-along with the Authorization Code.

+along with the Authorization Code.

 

-

-
OAuth does allow for retrieving the access token without a secret. This is typically
+

+
OAuth does allow for retrieving the access token without a secret. This is typically
 done when the OAuth client is a client application.
-When onboarding with the DNS Provider this would need to be enabled.

+When onboarding with the DNS Provider this would need to be enabled.

 

-

-
When the secret is provided (which is the normal case), care must be taken. A malicious
+

+
When the secret is provided (which is the normal case), care must be taken. A malicious
 user could create a domain that returns a false _domainconnect TXT record, and
 subsequently a JSON call to their own server for the API end point. By doing so, they
-could then run Domain Connect on their domain and retrieve the secret.

+could then run Domain Connect on their domain and retrieve the secret.

 

-

-
As such the urlAPI used for oAuth by the Service Provider should be maintained per DNS
-Provider and not the value retrieved during discovery.

+

+
As such the urlAPI used for OAuth by the Service Provider should be maintained per DNS
+Provider and not the value retrieved during discovery.

 

-

-
The following table describes the POST parameters that must be included in the
+

+
The following table describes the POST parameters that must be included in the
 request for the access token unless otherwise indicated.
 The parameters should be accepted via the
 query string or the body of the post. This is again particularly
 important for the client_secret, as passing secrets via a query string
-is generally frowned upon given that various systems often log URLs.

+is generally frowned upon given that various systems often log URLs.

 

-

-
The body of the post is application/json encoded.

+

+
The body of the post is application/json encoded.

 

-

+

 
-                
@@ -3051,7 +3161,7 @@ 

                   Redirect URI
 
                 

-                
@@ -3060,14 +3170,14 @@ 

                   Grant type
 
                 

-                
+                
-                
@@ -3075,17 +3185,17 @@ 

                   Client Secret
 
                 

-                
+                

             
 Table 7:
@@ -3041,7 +3151,7 @@ 

                   Authorization Code/Refresh Code
 
                 
code/refresh_tokenThe authorization code that was
+                (REQUIRED) The authorization code that was
 provided in the previous step when the customer accepted the
 authorization request, or the refresh_token for a subsequent access
 token.redirect_uri(OPTIONAL) This is required if a redirect_uri was
+                (OPTIONAL) This is REQUIRED if a redirect_uri was
 passed to request the authorization code. When included, it needs to be
 the same redirect_uri provided in this step.
               
grant_typeThe type of code in the request. Usually the string 'authorization_code' or 'refresh_token'(REQUIRED) The type of code in the request. Usually the string 'authorization_code' or 'refresh_token'
               

               

                 
                   Client ID
 
                 client_idThis is the client id that was provided by the DNS provider to the Service Provider during
+                (REQUIRED) This is the client id that was provided by the DNS provider to the Service Provider during
 registration
               

               
client_secretThe secret provided to the Service Provider during registration. Typically required
-unless the rare circumstance with secret-less oAuth.(REQUIRED) The secret provided to the Service Provider during registration. Typically required
+unless the rare circumstance with secret-less OAuth.
               

             
           

 

-

-
Upon successful token exchange, the DNS Provider will return a response
-with 4 properties in the body of the response.

+

+
Upon successful token exchange, the DNS Provider will return a response
+with 4 properties in the body of the response.

 

-

+

 

             
 Table 8:
@@ -3125,7 +3235,7 @@ 

             
           

 

-

+

 

             
 Table 9:
@@ -3160,88 +3270,89 @@ 

 
 
 

-

+

           

-4.3.4. OAuth Flow: Making Requests with Access Tokens
+7.3.5. OAuth Flow: Making Requests with Access Tokens
           

-

-
Once the Service Provider has the access token, they can call the DNS
+

+
Once the Service Provider has the access token, they can call the DNS
 Provider's API to make changes to DNS on the domain by applying and (OPTIONALLY)
 removing authorized templates. These templates can be applied to the
-root domain or to any sub-domain of the root domain that has been authorized.

+root domain or to any sub-domain of the root domain that has been authorized.

 

-

-
All calls to this API pass the access token in the Authorization Header
+

+
All calls to this API pass the access token in the Authorization Header
 of the request to the call to the API. More details can be found in the
-OAuth specifications, but as an example:

+OAuth specifications, but as an example:

 

-

-

-
GET /resource/1 HTTP/1.1
+

+

+
GET /resource/1 HTTP/1.1
 
 Host: example.com
 
-Authorization: Bearer mF_9.B5f-4.1JqM

+Authorization: Bearer mF_9.B5f-4.1JqM

 

 

-

-
While the calls below do not have the same security consideration of
+

+
While the calls below do not have the same security consideration of
 passing the secret, it is recommend that the urlAPI be from a stored
-value vs. the value returned during discovery here as well.

+value vs. the value returned during discovery here as well.

 

 

 

 

-

+

           

-4.3.5. OAuth Flow: Apply Template to Domain.
+7.3.6. OAuth Flow: Apply Template to Domain.
           

-

-

-
POST
+

+

+
POST
 
-{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties]

+{urlAPI}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}/apply?[properties]

 

 

-

-
The primary function of the API is to apply a template to a customer
-domain.

+

+
The primary function of the API is to apply a template to a customer
+domain.

 

-

-
While the providerId is implied in the authorization, this is on the
+

+
While the providerId is implied in the authorization, this is on the
 path for consistency with the synchronous flows and other APIs. If not
-matching what was authorized, an error must be returned.

+matching what was authorized, an error must be returned.

 

-

-
When applying a template to a domain, it is possible that a conflict may
+

+
When applying a template to a domain, it is possible that a conflict may
 exist with previous settings. While it is recommended that conflicts be
 detected when the user grants consent, because OAuth is asynchronous it
-is possible that a new conflict was introduced by the user.

+is possible that a new conflict was introduced by the user.

 

-

-
While it is up to the DNS Provider to determine what constitutes a
+

+
While it is up to the DNS Provider to determine what constitutes a
 conflict (see section on Conflicts below), when one is detected calling
 this API must return an error. This error should enumerate the
-conflicting records in a format described below.

+conflicting records in a format described below.

 

-

-
Because the user often isn't present at the time of this error, it is up the
+

+
Because the user often isn't present at the time of this error, it is up the
 Service Provider to determine how to handle this condition. Some providers
 may decide to notify the user. Others may decide to apply their template
 anyway using the "force" parameter. This parameter will bypass error
 checks for conflicts, and after the call the service will be in its
-desired state.

+desired state.

 

-

-
Calls to apply a template via OAuth require the following parameters
+

+
Calls to apply a template via OAuth require the following parameters
 posted to the above URL unless otherwise indicated.
 The DNS Provider must accept parameters in query string or body of this
-post.

+post.

 

-

-
The body is application/json encoded.

+

+
The body is application/json encoded.

 

-

+

 
-                
@@ -3277,7 +3388,7 @@ 

                   Name/Value Pairs
 
                 

-                

             
 Table 10:
@@ -3260,7 +3371,7 @@ 

                   Domain
 
                 
domainThe root domain name being configured. It must match the domain that was authorized
+                (REQUIRED) The root domain name being configured. It must match the domain that was authorized
 in the token.
               

               
*Any variable fields consumed by
+                (REQUIRED) Any variable fields consumed by
 this template. The name portion of this API call corresponds to the
 variable(s) specified in the record and the value corresponds to the
 value that must be used when applying the template as per the
@@ -3327,37 +3438,39 @@ 

 

                 instanceId
                 (OPTIONAL) Only applicable to templates supporting multiple instances
-(see multiInstance (Section 5.2) template property). Allows for later
+(see multiInstance (Section 8.2) template property). Allows for later
 removal of one template instance by DNS Providers storing this information.
               

             
           

 

-

-
An example call is below. In this example, it is contemplated that there
+

+
An example call is below. In this example, it is contemplated that there
 are two variables in this template, "IP" and "RANDOMTEXT" which both require
 values. These variables are
-passed as name/value pairs.

+passed as name/value pairs.

 

-

-

-
POST
+

+

+
POST
 
-https://connect.dnsprovider.com/v2/domainTemplates/providers/exampleservice.domainconnect.org/services/template1/apply?IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello&force=1

+https://connect.dnsprovider.example/v2/domainTemplates/providers/
+exampleservice.example/services/template1/apply?IP=192.0.2.42
+&#x26;RANDOMTEXT=shm%3A1542108821%3AHello&#x26;force=1

 

 

-

-
The API must validate the access token, and that the domain belongs to
+

+
The API must validate the access token, and that the domain belongs to
 the customer and is represented by the token being presented. Any errors
 with variables, conflicting templates, or problems with the state of the
-domain are returned; otherwise the template is applied.

+domain are returned; otherwise the template is applied.

 

-

-
Results of this call can include information indicating success or an
+

+
Results of this call can include information indicating success or an
 error. Errors will be 400 status codes, with the following codes
-defined.

+defined.

 

-

+

 

             
 Table 11:
@@ -3419,18 +3532,18 @@ 

             
           

 

-

-
When a 409 is returned, the body of the response should contain details of
+

+
When a 409 is returned, the body of the response should contain details of
 the conflicting records. This should be JSON containing the error code, a message
 suitable for developers, and an array of tuples containing the
-conflicting records type, host, and data element.

+conflicting records type, host, and data element.

 

-

-
As an example:

+

+
As an example:

 

-

-

-
{
+

+

+
{
     "code": "409",
     "message": "Conflicting records",
     "records": [
@@ -3445,59 +3558,61 @@ 

             "data": "random ip"
         }
     ]
-}

+}

 

 

-

-
In this example, the Service Provider tried to apply a new hosting
-template. The domain had an existing service applied for hosting.

+

+
In this example, the Service Provider tried to apply a new hosting
+template. The domain had an existing service applied for hosting.

 

 

 

 

-

+

           

-4.3.6. OAuth Flow: Revert Template
+7.3.7. OAuth Flow: Revert Template
           

-

-
This call reverts the application of a specific template from a domain.

+

+
This call reverts the application of a specific template from a domain.

 

-

-
Implementation of this call is OPTIONAL. If not supported a 501 MUST be returned.

+

+
Implementation of this call is OPTIONAL. If not supported a 501 MUST be returned.

 

-

-

-
POST
+

+

+
POST
 
-{urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/revert?domain={domain}&host={host}

+{urlAPI}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}/revert?domain={domain}&host={host}

 

 

-

-
This API allows the removal of a template from a customer domain/host
-using an OAuth request.

+

+
This API allows the removal of a template from a customer domain/host
+using an OAuth request.

 

-

-
The provider and service name in the URL must match the values provided during authorization.

+

+
The provider and service name in the URL must match the values provided during authorization.

 

-

-
This call must validate that the template exists and has been
+

+
This call must validate that the template exists and has been
 applied to the domain by the Service Provider, or a warning must be
-returned that the call would have no effect.

+returned that the call would have no effect.

 

-

-
An example query string might look like:

+

+
An example query string might look like:

 

-

-

-
POST
+

+

+
POST
 
-https://connect.dnsprovider.com/v2/domainTemplates/providers/exampleservice.domainconnect.org/services/template1/revert?domain=example.com

+https://connect.dnsprovider.example/v2/domainTemplates/providers
+/exampleservice.example/services/template1/revert?domain=example.com

 

 

-

-
Allowed parameters:

+

+
Allowed parameters:

 

-

+

 
-                
@@ -3524,7 +3639,7 @@ 

                   Host
 
                 

-                
@@ -3534,31 +3649,31 @@ 

 
                 

             
 Table 12:
@@ -3516,7 +3631,7 @@ 

                   Domain
 
                 
domainThe root domain name being configured. It
+                (REQUIRED) The root domain name being configured. It
 must match the domain that was authorized in the token.
               

               
hostThe host name of the sub domain of the root domain that was authorized in the token.
+                (OPTIONAL) The host name of the sub domain of the root domain that was authorized in the token.
 If omitted or left blank, the template is being applied to the root
 domain.
               
instanceId
                 (OPTIONAL) Only applicable to templates supporting multiple instances
-(see multiInstance (Section 5.2) template property). For DNS Provider
+(see multiInstance (Section 8.2) template property). For DNS Provider
 storing information about applied templates allows removal of single instance
 of template. If missing all instances of template should be removed.
               

             
           

 

-

-
The DNS Provider should be able to accept these on the query string or in the body of the POST with application/json encoding.

+

+
The DNS Provider should be able to accept these on the query string or in the body of the POST with application/json encoding.

 

-

-
Response codes Success, Authorization, and Errors are identical to
-above with the addition of the 501 code.

+

+
Response codes Success, Authorization, and Errors are identical to
+above with the addition of the 501 code.

 

 

 

 

-

+

           

-4.3.7. OAuth Flow: Revoking access
+7.3.8. OAuth Flow: Revoking access
           

-

-
Like all oAuth flows, the user may revoke the access at any time using
+

+
Like all OAuth flows, the user may revoke the access at any time using
 UX at the DNS Provider site. As such the Service Provider needs to be
-aware that their access to the API may be denied.

+aware that their access to the API may be denied.

 

 

 

@@ -3567,38 +3682,38 @@ 

 
 
 

-

+

       

-5. Domain Connect Objects and Templates
+8. Domain Connect Objects and Templates
       

 

-

+

         

-5.1. Template Versioning
+8.1. Template Versioning
         

-

-
If a breaking change is made to a template it is recommended that a new template be created. While on the surface versioning looks appealing, in reality this is rarely needed.

+

+
If a breaking change is made to a template it is recommended that a new template be created. While on the surface versioning looks appealing, in reality this is rarely needed.

 

-

-
Any changes to the template need to account for existing customers with settings in DNS, some applied through Domain Connect and some manual. So when changes are made, they are often backward compatible.

+

+
Any changes to the template need to account for existing customers with settings in DNS, some applied through Domain Connect and some manual. So when changes are made, they are often backward compatible.

 

-

-
Note that when a template changes, it does need to be on-boarded with the DNS Providers.

+

+
Note that when a template changes, it does need to be on-boarded with the DNS Providers.

 

-

-
The version field (Section 5.2) of the template definition serves the purpose of transparency between the DNS Provider and the Service Provider in case of such changes.

+

+
The version field (Section 8.2) of the template definition serves the purpose of transparency between the DNS Provider and the Service Provider in case of such changes.

 

 

 

 

-

+

         

-5.2. Template Definition
+8.2. Template Definition
         

-

-
A template is defined as a standard JSON data structure containing the following data. Fields are required unless otherwise indicated.

+

+
A template is defined as a standard JSON data structure containing the following data. Fields are required unless otherwise indicated.

 

-

+

 
-              
+              
-              
+              
-              
+              
-              
+              
-              
+              

           
 Table 13:
@@ -3619,7 +3734,7 @@ 

 
               
String
               providerIdThe unique identifier of the Service Provider that created this template. This is used in the URLs to identify the Service Provider. To ensure non-coordinated uniqueness, this should be the domain name of the Service Provider (e.g. exampleservice.domainconnect.org).(REQUIRED) The unique identifier of the Service Provider that created this template. This is used in the URLs to identify the Service Provider. To ensure non-coordinated uniqueness, this should be the domain name of the Service Provider (e.g. exampleservice.example).
             

             

               
@@ -3627,7 +3742,7 @@ 

 

               String
               providerNameThe name of the Service Provider suitable for display. This may be displayed to the user on the DNS Provider consent UX.(REQUIRED) The name of the Service Provider suitable for display. This may be displayed to the user on the DNS Provider consent UX.
             

             

               
@@ -3635,8 +3750,8 @@ 

 

               String
               serviceIdThe name or identifier of the template.
-This is used in URLs to identify the template. It is also used in the scope parameter for oAuth. It must not contain space characters, and must be URL friendly.(REQUIRED) The name or identifier of the template.
+This is used in URLs to identify the template. It is also used in the scope parameter for OAuth. It must not contain space characters, and must be URL friendly.
             

             

               
@@ -3644,7 +3759,7 @@ 

 

               String
               serviceNameThe name of the service suitable for display to the user. This may be displayed to the user on the DNS Provider consent UX.(REQUIRED) The name of the service suitable for display to the user. This may be displayed to the user on the DNS Provider consent UX.
             

             

               
@@ -3769,7 +3884,7 @@ 

 

               Array of Template Records
               recordsA list of records for the template.(REQUIRED) A list of records for the template.
             

           
         

@@ -3777,66 +3892,66 @@ 

 

 

 

-

+

         

-5.3. Template Record
+8.3. Template Record
         

-

-
Each template record is an entry that contains a type and several
-other values depending on the type.

+

+
Each template record is an entry that contains a type and several
+other values depending on the type.

 

-

-
Many of these values can contain variables. There are three built in variables.

+

+
Many of these values can contain variables. There are three built in variables.

 

 
    
-
  • %host%: This is the host passed from the query string
+
  • %host%: This is the host passed from the query string
 
    • 
-          
  • %domain%: This is the domain passed from the query string
+          
  • %domain%: This is the domain passed from the query string
 
    • 
-          
  • %fqdn%: This is the fully qualified domain name e.g. [host.]domain
+          
  • %fqdn%: This is the fully qualified domain name e.g. [host.]domain
 
    • 
         

-

-
The @ symbol has special meaning, and can be used in the host/name field or in
-the pointsTo/data field in isolation.

+

+
The @ symbol has special meaning, and can be used in the host/name field or in
+the pointsTo/data field in isolation.

 

-

-
For the host/name field it is a shortcut for the value "%fqdn%.". When applying the
+

+
For the host/name field it is a shortcut for the value "%fqdn%.". When applying the
 template to a domain only, it represents "example.com.". When applying with a sub-domain
-(host) it represents "subdomain.example.com.".

+(host) it represents "subdomain.example.com.".

 

-

-
Note: The trailing dot here is similar to the bind protocol, which indicates the value
-is absolute. Without the trailing ".", the value in this field is relative to the [host.]domain.com
-value.

+

+
Note: The trailing dot here is similar to the bind notation, which indicates the value
+is absolute. Without the trailing ".", the value in this field is relative to the [host.]example.com
+value.

 

-

-
For the pointsTo/data field it is a shortcut for for the "%fqdn%". When appling
+

+
For the pointsTo/data field it is a shortcut for for the "%fqdn%". When appling
 the template to a domain only, it represents "example.com". When applying with a sub-
-domain (host) it represents "subdomain.example.com".

+domain (host) it represents "subdomain.example.com".

 

-

-
Note: The pointsTo and data files are always absolute for these fields.

+

+
Note: The pointsTo and data files are always absolute for these fields.

 

-

-
It is noted that as a best practice the variable portions should be constrained
-to as small as possible a portion of the resulting DNS record.

+

+
It is noted that as a best practice the variable portions should be constrained
+to as small as possible a portion of the resulting DNS record.

 

-

-
For example, say a Service Provider requires a CNAME of one of three
+

+
For example, say a Service Provider requires a CNAME of one of three
 values for their users: s01.example.com, s02.example.com, and
-s03.example.com.

+s03.example.com.

 

-

-
The value in the template could simply contain %servercluster%, and the
+

+
The value in the template could simply contain %servercluster%, and the
 fully qualified string passed in. Alternatively, the value in the
 template could contain %var%.example.com and a value of 01, 02, or 03 passed in.
-By placing more fixed data into the template, the template is more secure.

+By placing more fixed data into the template, the template is more secure.

 

-

-
Each record will contain the following elements.

+

+
Each record will contain the following elements.

 

-

+

 
-              
+For each type, additional fields would be REQUIRED.

+* A: host, pointsTo, TTL

+* AAAA: host, pointsTo, TTL

+* CNAME: host, pointsTo, TTL (host must not be null or @ unless hostRequired is defined true for the template)

+* NS: host, pointsTo, TTL (host must not be null or @ unless hostRequired is defined true for the template)

+* TXT: host, data, TTL, txtConflict-MatchingMode, txtConflict-MatchingPrefix

+* MX: host, pointsTo, TTL, priority

+* SRV: name, target, TTL, priority, protocol, service, weight, port

+* SPFM: host, spfRules

+
+template

+
-              
+below.

+
-              
+below.

+
-              
+A value of empty or @ indicates the host and domain name being applied or [host.]example.com

+
+A value of empty or @ indicates the host and domain name being applied or [host.]example.com
+None, All, or Prefix. The default value is None. See below (Section 9.3).
-              
+              
+SPFM records into final SPF TXT record. See Section 9.10.

           
 Table 14:
@@ -3857,27 +3972,20 @@ 

 
               
enum
               typeDescribes the type of record in DNS, or the operation impacting DNS.
-
-Valid values include: A, AAAA, CNAME, MX, TXT, SRV, or SPFM
-
-For each type, additional fields would be required.
-
-A: host, pointsTo, TTL
-
-AAAA: host, pointsTo, TTL
-
-CNAME: host, pointsTo, TTL (host must not be null or @)
-
-NS: host, pointsTo, TTL (host must not be null or @)
+              (REQUIRED) Describes the type of record in DNS, or the operation impacting DNS.

 
-TXT: host, data, TTL, txtConflictMatchingMode, txtConflictMatchingPrefix
+Valid values include: A, AAAA, CNAME, MX, TXT, SRV, or SPFM

 
-MX: host, pointsTo, TTL, priority
-
-SRV: name, target, TTL, priority, protocol, service, weight, port
-
-SPFM: host, spfRules		
             

             

               
@@ -3897,14 +4005,15 @@ 

               
essential
               (OPTIONAL)
 This parameter indicates how the record is treated during conflict detection with
-existing templates.
+existing templates.

 
-If the DNS Provider is not implementing applied template state in DNS this is ignored.
+If the DNS Provider is not implementing applied template state in DNS this is ignored.

 
-Always (default) - record MUST be applied and kept with the template
+Always (default) - record MUST be applied and kept with the template

 
 OnApply - record MUST be applied but can be later removed without dropping the whole
-template		
             

             

               
@@ -3912,15 +4021,16 @@ 

 

               String
               hostThe host for A, AAAA, CNAME, NS, TXT, and MX values.
+              (REQUIRED) The host for A, AAAA, CNAME, NS, TXT, and MX values.

 
-This value is relative to the applied host and domain, unless trailed by a ".".
+This value is relative to the applied host and domain, unless trailed by a ".".

 
 A value of empty or @ indicates the root of the applied host and domain. In other words
-"[host.]domain.com.".
+"[host.]example.com.".

 
 This value should not contain variables unless absolutely necessary. This is discussed
-below.		
             

             

               
@@ -3928,13 +4038,14 @@ 

 

               String
               nameThe name for the SRV record.
+              The name for the SRV record.

 
 This value is relative to the applied host and domain. A value of empty or @ indicates
-the root of the applied host and domain.
+the root of the applied host and domain.

 
 This value should not contain variables unless absolutely necessary. This is discussed
-below.		
             

             

               
@@ -3942,9 +4053,10 @@ 

 

               String
               pointsToThe pointsTo location for A, AAAA, CNAME, NS and MX records.
+              The pointsTo location for A, AAAA, CNAME, NS and MX records.

 
-A value of empty or @ indicates the host and domain name being applied or [host.]domain.com		
             

             

               
@@ -3963,7 +4075,7 @@ 

               
data
               The data for a TXT record in DNS.
 
-A value of empty or @ indicates the host and domain name being applied or [host.]domain.com
             

             

               
@@ -3972,7 +4084,7 @@ 

               
String
               txtConflictMatchingMode
               Describes how conflicts on the TXT record are detected. Possible values are
-None, All, or Prefix. The default value is None. See below (Section 6.3).
             

             

               
@@ -3980,8 +4092,8 @@ 

 

               String
               txtConflictMatchingPrefixThe prefix to detect conflicts when txtConflictMatchingMode is "Prefix". This
-must not contain variables. See below (Section 6.3).The prefix to detect conflicts when txtConflict-MatchingMode is "Prefix". This
+must not contain variables. See below (Section 9.3).
             

             

               
@@ -4038,7 +4150,7 @@ 

               
String
               spfRules
               These are desired rules for the SPF TXT record. These rules will be merged with other
-SPFM records into final SPF TXT record. See Section 6.10.
             

           
         

@@ -4048,133 +4160,133 @@ 

 

 

 

-

+

       

-6. Template Considerations
+9. Template Considerations
       

 

-

+

         

-6.1. Template State in DNS
+9.1. Template State in DNS
         

-

-
DNS Providers may chose to maintain state inside records in DNS indicating the templates
-writing the records. Other providers may chose to not maintain this state.

+

+
DNS Providers may chose to maintain state inside records in DNS indicating the templates
+writing the records. Other providers may chose to not maintain this state.

 

-

-
A DNS Provider that maintains this state may be able to provide an improved experience for
+

+
A DNS Provider that maintains this state may be able to provide an improved experience for
 customers, telling them the services enabled. They also may be able to have more
-advanced handling of conflicts.

+advanced handling of conflicts.

 

-

-
To make the implementation burden reasonable for DNS Providers, Domain Connect does not dictate the approach.

+

+
To make the implementation burden reasonable for DNS Providers, Domain Connect does not dictate the approach.

 

 

 

 

-

+

         

-6.2. Disclosure of Changes and Conflicts
+9.2. Disclosure of Changes and Conflicts
         

-

-
It is left to the discretion of the DNS Provider to determine what is disclosed to the user
+

+
It is left to the discretion of the DNS Provider to determine what is disclosed to the user
 when granting permission and/or applying changes to DNS.
 This includes disclosing the records being applied and the records
-that may be overwritten.

+that may be overwritten.

 

-

-
For changes being made, one DNS Provider
+

+
For changes being made, one DNS Provider
 may decide to simply tell the user the name of the service being enabled. Another
 may decide to display the records being set. And another
-may progressively display both.

+may progressively display both.

 

-

-
For conflict detection, one DNS Provider may simply overwrite
+

+
For conflict detection, one DNS Provider may simply overwrite
 changed records without warning. Another may detect conflicts and warn the user of the
 records that will change. And another may implement logic to further detect, warn, and
 remove any of the existing templates that overlap with the new template once applied
-(this assumes they are a DNS Provider that maintains template state in DNS).

+(this assumes they are a DNS Provider that maintains template state in DNS).

 

-

-
As an example, consider applying a template that sets two records
+

+
As an example, consider applying a template that sets two records
 (recordA and recordB) into a zone. Next consider applying a second template that
 overlaps with the first template (recordB and recordC). If the DNS maintains template state
 and removes conflicting templates, applying the second template would remove the first
 template. Application of the second template would conflict with recordB and the entire
-first template would be removed.

+first template would be removed.

 

-

-
Manual changes made by the user at the DNS Provider may also have
+

+
Manual changes made by the user at the DNS Provider may also have
 appropriate warnings in place to prevent unwanted changes; with
-overrides being possible and removal of conflicting templates.

+overrides being possible and removal of conflicting templates.

 

-

-
For the synchronous flow, this happens while the user is present.

+

+
For the synchronous flow, this happens while the user is present.

 

-

-
For the asynchronous flow, the consent UX is similar. However, the changes are made later
+

+
For the asynchronous flow, the consent UX is similar. However, the changes are made later
 using the API and OAuth. The DNS Provider may decide to detect conflicts and
 return these from the API without applying the change using the proper response code.
-If the force parameter is set, the changes must be applied regardless of conflicts.

+If the force parameter is set, the changes must be applied regardless of conflicts.

 

-

-
It is ultimately left to the DNS Provider to determine the amount of
+

+
It is ultimately left to the DNS Provider to determine the amount of
 disclosure and/or conflict detection. The only requirement is that after
-a template is applied the new records must be applied in totality.

+a template is applied the new records must be applied in totality.

 

-

-
A reasonable set of recommendations for the UX might consist of:

+

+
A reasonable set of recommendations for the UX might consist of:

 

 
    
-
  • The consent UX should inform the customer of the service that will be
+
  • The consent UX should inform the customer of the service that will be
 enabled. If the customer want to know the specifics, the DNS
 Provider could provide a "show details" link to the user. This could
-display to them the specific records that are being set in DNS.
+display to them the specific records that are being set in DNS.
 
    • 
-          
  • If there are conflicts, either at the template or record level, the
+          
  • If there are conflicts, either at the template or record level, the
 consent UX should warn the user about these conflicts. For templates,
 this would be services that would be disabled. For records, this would be
-records that would be deleted or overwritten. This could be progressively disclosed.
+records that would be deleted or overwritten. This could be progressively disclosed.
 
    • 
         

 

 

 

-

+

         

-6.3. Record Types and Conflicts
+9.3. Record Types and Conflicts
         

-

-
Conflict detection done by the DNS provider prior to template application has to take
+

+
Conflict detection done by the DNS provider prior to template application has to take
 into consideration specifics of each DNS record type. The rules outlined below
 ensure predictable conflict resolution between DNS providers. Each rule applies to
-the records on the very same host, unless specifed otherwise.

+the records on the very same host, unless specifed otherwise.

 

 
    
-
  • CNAME record conflicts with TXT, MX, AAAA, A and existing CNAME records, and any other records of these
-types conflict with an existing CNAME record. Note: CNAME records cannot be at the root of the zone.
+
  • CNAME record conflicts with TXT, MX, AAAA, A and existing CNAME records, and any other records of these
+types conflict with an existing CNAME record. Note: CNAME records cannot be at the root of the zone.
 
    • 
-          
  • NS records conflict with all other records. This includes of the same host, and for any record ending with the NS host. For example, an NS record of foo will conflict with any foo, www.foo, bar.foo, etc. Similarly all
-other record type conflict with NS records in the same manner.
+          
  • NS records conflict with all other records. This includes of the same host, and for any record ending with the NS host. For example, an NS record of foo will conflict with any foo, www.foo, bar.foo, etc. Similarly all
+other record type conflict with NS records in the same manner.
 
    • 
-          
  • MX, SRV records always conflict with records of the same type
+          
  • MX, SRV records always conflict with records of the same type
 
    • 
-          
  • A and AAAA records conflict with any other A and/or AAAA record, to avoid IPv4
-and IPv6 pointing to different services.
+          
  • A and AAAA records conflict with any other A and/or AAAA record, to avoid IPv4
+and IPv6 pointing to different services.
 
    • 
-          
  • 
-            
    
-
    TXT records conflict detection is handled looking at txtConflictMatchingMode
-parameter
    
+          
  • 
+            
    
+
    TXT records conflict detection is handled looking at txtConflictMatchingMode
+parameter
    
 
    
 
      
-
    • None: This indicates that the TXT records do not conflict with any other TXT
-record. This is the default setting, if not specified.
+
    • None: This indicates that the TXT records do not conflict with any other TXT
+record. This is the default setting, if not specified.
 
      • 
-              
    • All: This indicates that the TXT records conflict with any other TXT record
+              
    • All: This indicates that the TXT records conflict with any other TXT record
 
      • 
-              
    • Prefix: This indicates that TXT record conflict with any other TXT containing value starting with
-txtConfictMatchingPrefix
+              
    • Prefix: This indicates that TXT record conflict with any other TXT containing value starting with
+txtConflictMatchingPrefix
 
      • 
             
    
 
    • 
@@ -4182,237 +4294,237 @@ 
    
 

 

 

-

+

         

-6.4. Apply, Re-apply, and Multi-Instance
+9.4. Apply, Re-apply, and Multi-Instance
         

-

-
There is an additional consideration for DNS Providers that maintain the state of an applied
-template when re-applying a template.

+

+
There is an additional consideration for DNS Providers that maintain the state of an applied
+template when re-applying a template.

 

-

-
To avoid unnecessary conflict warnings to the user, under normal use when re-applying a
-template such a DNS Provider should remove the previously applied template on the same host.

+

+
To avoid unnecessary conflict warnings to the user, under normal use when re-applying a
+template such a DNS Provider should remove the previously applied template on the same host.

 

-

-
This may not be desireable for all templates, as a limited set of templates are designed to
-be applied multiple times. To faciliate this the template can have the flag multiInstance (Section 5.2)
+

+
This may not be desireable for all templates, as a limited set of templates are designed to
+be applied multiple times. To faciliate this the template can have the flag multiInstance (Section 8.2)
 set. This tells the DNS Provider that the template is expected to be written multiple times
-and that a re-apply must not remove previous instances.

+and that a re-apply must not remove previous instances.

 

-

-
This setting only impacts DNS Providers that maintain applied template state. DNS Providers
+

+
This setting only impacts DNS Providers that maintain applied template state. DNS Providers
 that do not maintain applied template state must rely on the normal conflict
-resolution rules, and this flag has no impact.

+resolution rules, and this flag has no impact.

 

 

 

 

-

+

         

-6.5. Non-essential records
+9.5. Non-essential records
         

-

-
Typically a template specifies a list of DNS records which are required for the service.
+

+
Typically a template specifies a list of DNS records which are required for the service.
 There may be cases where some records are only required for a very short period of time,
 and removing or altering the record later (either by the end user or through application
-of another template) should not trigger conflict detection.

+of another template) should not trigger conflict detection.

 

-

-
This can be controlled by the essential (Section 5.3) property of a record in
-the template.

+

+
This can be controlled by the essential (Section 8.3) property of a record in
+the template.

 

-

-
Again, this setting only impacts DNS Providers that maintain applied template state.

+

+
Again, this setting only impacts DNS Providers that maintain applied template state.

 

 

 

 

-

+

         

-6.6. Template Scope
+9.6. Template Scope
         

-

-
For DNS Providers that maintain template state, an individual template is scoped to the set of records applied to a
+

+
For DNS Providers that maintain template state, an individual template is scoped to the set of records applied to a
 fully qualified domain. This includes the root domain and the host (aka
-sub-domain) at apply time.

+sub-domain) at apply time.

 

-

-
As an example, if a template is applied on domain=example.com&host=sub1
-a later application of the template on domain=example.com&host=sub2 must be
+

+
As an example, if a template is applied on domain=example.com=sub1
+a later application of the template on domain=example.com=sub2 must be
 treated as a distinct template. If a conflict is detected later
 with the records set into "sub2.example.com",
-only the records set with this template would be removed.

+only the records set with this template would be removed.

 

 

 

 

-

+

         

-6.7. Host/Name in Template
+9.7. Host/Name in Template
         

-

-
Template records contain the host name of the record to set into the zone (called name
+

+
Template records contain the host name of the record to set into the zone (called name
 for SRV records). This value must be considered relative to the domain/host when
-the template is applied, unless followed by a trailing ".".

+the template is applied, unless followed by a trailing ".".

 

-

-
Consider a template record of type A with a host value of "xyz". When the template is
-applied to a domain=foo.com and an empty host value, the resulting zone after the template
-is applied will contain an A record of "xyz" (or "xyz.foo.com." in bind format).

+

+
Consider a template record of type A with a host value of "xyz". When the template is
+applied to a domain=example.com and an empty host value, the resulting zone after the template
+is applied will contain an A record of "xyz" (or "xyz.example.com." in bind format).

 

-

-
If the same template is applied to a domain=foo.com and host=bar, the zone will contain an A
-record of "xyz.bar" (or "xyz.bar.foo.com." in bind format).

+

+
If the same template is applied to a domain=example.com and host=bar, the zone will contain an A
+record of "xyz.bar" (or "xyz.bar.example.com." in bind format).

 

-

-
A value of @ for host in the template is a placeholder for an empty value. In other words @
-would point to "bar.foo.com." when the same template is applied to domain=foo.com and host=bar.

+

+
A value of @ for host in the template is a placeholder for an empty value. In other words @
+would point to "bar.example.com." when the same template is applied to domain=example.com and host=bar.

 

 

 

 

-

+

         

-6.8. PointsTo in Template
+9.8. PointsTo in Template
         

-

-
Template records of certain types contain the pointsTo value to set in the zone. For
-record types such as CNAME where this can be a fully qualified domain name.

+

+
Template records of certain types contain the pointsTo value to set in the zone. For
+record types such as CNAME where this can be a fully qualified domain name.

 

-

-
A value of @ in pointsTo field in the template is a shortcut for the fully qualified domain
-name of the domain/host being applied.

+

+
A value of @ in pointsTo field in the template is a shortcut for the fully qualified domain
+name of the domain/host being applied.

 

-

-
Consider a template record of type CNAME with a pointsTo value of "@". After a template of
-domain=foo.com and an empty host is applied, the pointsTo value (or corresponding field) in
-the resulting zone would be "foo.com". After a template of domain=foo.com
-with host=bar is applied, the points to value would be "bar.foo.com".

+

+
Consider a template record of type CNAME with a pointsTo value of "@". After a template of
+domain=example.com and an empty host is applied, the pointsTo value (or corresponding field) in
+the resulting zone would be "example.com". After a template of domain=example.com
+with host=bar is applied, the points to value would be "bar.example.com".

 

-

-
Any domain in a pointsTo field in a template must be considered fully qualified and not
-relative.

+

+
Any domain in a pointsTo field in a template must be considered fully qualified and not
+relative.

 

 

 

 

-

+

         

-6.9. Variables
+9.9. Variables
         

 

-

+

           

-6.9.1. Variables and Host/Name in Template
+9.9.1. Variables and Host/Name in Template
           

-

-
While templates do allow for variables in a host or name field values, these should be used
-very sparingly.

+

+
While templates do allow for variables in a host or name field values, these should be used
+very sparingly.

 

-

-
As an example, consider setting up hosting for a site. But instead of
+

+
As an example, consider setting up hosting for a site. But instead of
 applying the template to a domain/host, the name of the host is
-placed as a variable in the template.

+placed as a variable in the template.

 

-

-
Such a template might contain an A record of the form:

+

+
Such a template might contain an A record of the form:

 

-

-

-
{
+

+

+
{
     "type": "A",
     "host": "%var%",
-    "pointsTo": "2.2.2.2",
+    "pointsTo": "192.0.2.2",
     "ttl": 1800
-}

+}

 

 

-

-
This template could be applied on a domain like example.com with the var set
-to "sub", "sub1", "sub2", etc.

+

+
This template could be applied on a domain like example.com with the var set
+to "sub", "sub1", "sub2", etc.

 

-

-
Application of this template would be at the domain level for
+

+
Application of this template would be at the domain level for
 "example.com". This causes problems for application/re-application
-of the template, conflict detection, and template removal.

+of the template, conflict detection, and template removal.

 

-

-
Since this template would be applied to the domain only, DNS providers that maintain
+

+
Since this template would be applied to the domain only, DNS providers that maintain
 template state would remove previous instances of the template before re-application.
 This means applying this template with var=sub
 would result in the A record for sub.example.com to be set to
-the value 2.2.2.2. Later, applying the template on "example.com" with the
+the value 192.0.2.2. Later, applying the template on "example.com" with the
 var=sub2 should remove the old template before setting the new one. sub.example.com
 would be removed, and sub2.example.com would be set to the value
-2.2.2.2.

+192.0.2.2.

 

-

-
Furthermore, determining conflicts would be impossible when the user is granting consent
-for asynchronous operations (OAuth). This is because the host would be indeterminate.

+

+
Furthermore, determining conflicts would be impossible when the user is granting consent
+for asynchronous operations (OAuth). This is because the host would be indeterminate.

 

-

-
To solve this problem, templates are scoped to a domain and a host
+

+
To solve this problem, templates are scoped to a domain and a host
 value. For synchronous operations, the host value is specified in the url.
 For asynchronous operations, permissions are granted for specific host values, whose value
-is later specified when applying the template.

+is later specified when applying the template.

 

-

-
Note: There are some templates that utilize CNAME or TXT records with host values containing
+

+
Note: There are some templates that utilize CNAME or TXT records with host values containing
 some form of user identification for validation of domain ownership, and these are often
-passed in variables.

+passed in variables.

 

-

-
To support this use case, variables are allowed for the host name. But only in this
-limited circumstance.

+

+
To support this use case, variables are allowed for the host name. But only in this
+limited circumstance.

 

 

 

 

-

+

           

-6.9.2. Variable Values
+9.9.2. Variable Values
           

-

-
To allow for the use of the host name or domain name in templates, the
+

+
To allow for the use of the host name or domain name in templates, the
 values of %host% and %domain% are available. A third value of %fqdn% is also available. This
-value is the result of combining the host and domain name with the necessary ".".

+value is the result of combining the host and domain name with the necessary ".".

 

-

-
For example, with the query string "domain=example.com&host=", %fqdn% in a template would be
+

+
For example, with the query string "domain=example.com=", %fqdn% in a template would be
 "example.com", and with
-"domain=example.com&host=sub1", %fqdn% in a template would be "sub1.example.com".

+"domain=example.com=sub1", %fqdn% in a template would be "sub1.example.com".

 

 

 

 

-

+

           

-6.9.3. Variables and Security
+9.9.3. Variables and Security
           

-

-
As discussed, with variables consideration is necessary to prevent certain styles of
-phishing attacks.

+

+
As discussed, with variables consideration is necessary to prevent certain styles of
+phishing attacks.

 

-

-
The more static the value in the template record, the more secure the template. When static values are not possible, a carefully crafted link could hijack DNS settings.

+

+
The more static the value in the template record, the more secure the template. When static values are not possible, a carefully crafted link could hijack DNS settings.

 

-

-
Mitigations to this are discussed above.

+

+
Mitigations to this are discussed above.

 

 

 

 

-

+

           

-6.9.4. Variable Examples
+9.9.4. Variable Examples
           

-

-
Example template:

+

+
Example template:

 

-

-

-
[{
+

+

+
[{
     "type": "CNAME",
     "host": "www",
     "pointsTo": "@",
@@ -4421,45 +4533,45 @@ 

 {
     "type": "A",
     "host": "@",
-    "pointsTo": "1.1.1.1",
+    "pointsTo": "192.0.2.1",
     "ttl": 1800
-}]

+}]

 

 

-

-
Template applied with domain=foo.com and host parameter missing or empty:

+

+
Template applied with domain=example.com and host parameter missing or empty:

 

-

-

-
www 1800 IN CNAME foo.com.
-@   1800 IN A 1.1.1.1

+

+

+
www 1800 IN CNAME example.com.
+@   1800 IN A 192.0.2.1

 

 

-

-
alternatively

+

+
alternatively

 

-

-

-
www.foo.com.    1800 IN CNAME foo.com.
-foo.com.        1800 IN A 1.1.1.1

+

+

+
www.example.com.    1800 IN CNAME example.com.
+example.com.        1800 IN A 192.0.2.1

 

 

-

-
Template applied with domain=foo.com and host=bar:

+

+
Template applied with domain=example.com and host=bar:

 

-

-

-
www.bar 1800 IN CNAME bar.foo.com.
-bar     1800 IN A 1.1.1.1

+

+

+
www.bar 1800 IN CNAME bar.example.com.
+bar     1800 IN A 192.0.2.1

 

 

-

-
alternatively

+

+
alternatively

 

-

-

-
www.bar.foo.com.    1800 IN CNAME bar.foo.com.
-bar.foo.com.        1800 IN A 1.1.1.1

+

+

+
www.bar.example.com.    1800 IN CNAME bar.example.com.
+bar.example.com.        1800 IN A 192.0.2.1

 

 

 

@@ -4467,227 +4579,236 @@ 

 

 

 

-

+

         

-6.10. SPF TXT Record
+9.10. SPF TXT Record
         

 

-

+

           

-6.10.1. What is SPF?
+9.10.1. What is SPF?
           

-

-
SPF stands for Sender Policy Framework specified in
-[RFC7208]. It is a
+

+
SPF stands for Sender Policy Framework specified in
+[RFC7208]. It is a
 record that specifies a list of authorized host names and/or IP addresses from which mail
-can originate from for a given domain name.

+can originate from for a given domain name.

 

-

-
It manifests itself as a TXT record.  The format of which starts with v=spf1 followed by a list of "rules" of
+

+
It manifests itself as a TXT record.  The format of which starts with v=spf1 followed by a list of "rules" of
 what to include/exclude.  If a rule passes, the mail is allowed. If it fails, it moves to the next rule.
-Typical record might appear as:

+Typical record might appear as:

 

-

-

-
v=spf1 include:policy.exampleprovider.com -all

+

+

+
v=spf1 include:policy.exampleprovider.example -all

 

 

-

-
This is an SPF record with two rules.  The first rule indicates that the rules for SPF record
-policy.exampleprovider.com be included in this record. The second rule is a catch all (_all). The default modifier for a rule is pass (+). Other modifiers are hard failure(-), soft failure (~) and neutral (?).

+

+
This is an SPF record with two rules.  The first rule indicates that the rules for SPF record
+policy.exampleprovider.example be included in this record. The second rule is a catch all (_all). The default modifier for a rule is pass (+). Other modifiers are hard failure(-), soft failure (~) and neutral (?).

 

-

-
Note: A failure in SPF doesn't mean delivery won't happen, however depending on the policies of the receiving
-system, messages classified with hard failure or soft failure may not be delivered or marked as spam.

+

+
Note: A failure in SPF doesn't mean delivery won't happen, however depending on the policies of the receiving
+system, messages classified with hard failure or soft failure may not be delivered or marked as spam.

 

-

-
The use of "all" at the end  is pretty common, although some providers mark it as ~ (soft fail) or ? (neutral).
+

+
The use of "all" at the end  is pretty common, although some providers mark it as ~ (soft fail) or ? (neutral).
 The reality is that a good SPF record is tuned based on what services are attached to a domain. Not just one
-individual service.

+individual service.

 

 

 

 

-

+

           

-6.10.2. Multiple Services
+9.10.2. Multiple Services
           

-

-
If only one email sending service were active, the SPF record recommended by the provider is sufficient. But
-mail from a domain can often come from several different services.

+

+
If only one email sending service were active, the SPF record recommended by the provider is sufficient. But
+mail from a domain can often come from several different services.

 

-

-
A very typical use case might be end user mail and an email newsletter service.
-Let's look at the SPF records recommended for individual services.

+

+
A very typical use case might be end user mail and an email newsletter service.
+Let's look at the SPF records recommended for individual services.

 

-

-
Mailer1: v=spf1 include:spf.mailer1.com -all
-Newsletter1: v=spf1 include:_spf.newsletter.net ~all

+

+
Mailer1: v=spf1 include:spf.mailer1.example -all
+Newsletter1: v=spf1 include:_spf.newsletter.example ~all

 

-

-
All of these examples use the include syntax. This is fairly common. The use of all at the end is common,
-although is often inconsistent with the modifier.

+

+
All of these examples use the include syntax. This is fairly common. The use of all at the end is common,
+although is often inconsistent with the modifier.

 

-

-
If a customer installed Mailer1 and Newsletter1, their combined SPF record ought to be something like:

+

+
If a customer installed Mailer1 and Newsletter1, their combined SPF record ought to be something like:

 

-

-

-
v=spf1 include:spf.mailer1.com include:_spf.newsletter.net ~all

+

+

+
v=spf1 include:spf.mailer1.example include:_spf.newsletter.example
+ ~all

 

 

-

-
We combined the two rules, and in this case picked the least restrictive all modifier.

+

+
We combined the two rules, and in this case picked the least restrictive all modifier.

 

 

 

 

-

+

           

-6.10.3. SPF Record Merging
+9.10.3. SPF Record Merging
           

-

-
The challenge with SPF records and Domain Connect is that an individual service might recommend an SPF record. If only one service were active, this would be accurate. But with several services together only the DNS Provider is able to determine the valid shape of a SPF TXT record.

+

+
The challenge with SPF records and Domain Connect is that an individual service might recommend an SPF record. If only one service were active, this would be accurate. But with several services together only the DNS Provider is able to determine the valid shape of a SPF TXT record.

 

-

-
One solution to this problem is to merge all related records. At the highest level, this means taking everything between the "v=spf1" and the "all" from each of the records and merging them together, terminating with hard-coded modifier on all at the end.  For an SPF record to fulfill it's purpose of protection against malicious email delivery, Domain Connect advises a fixed modifier "~" advising lower rating of the messages from other sources not specified in SPF. This setup offers a reasonable level of protection of mail delivery, on the other side does not reject the message in case forwarding facility is in place.

+

+
One solution to this problem is to merge all related records. At the highest level, this means taking everything between the "v=spf1" and the "all" from each of the records and merging them together, terminating with hard-coded modifier on all at the end.  For an SPF record to fulfill it's purpose of protection against malicious email delivery, Domain Connect advises a fixed modifier "~" advising lower rating of the messages from other sources not specified in SPF. This setup offers a reasonable level of protection of mail delivery, on the other side does not reject the message in case forwarding facility is in place.

 

-

-

-
@ TXT v=spf1 include:spf.mailer1.com include:_spf.newsletter.net ~all

+

+

+
@ TXT v=spf1 include:spf.mailer1.example include:_spf.newsletter.exam
+ple ~all

 

 

-

-
The other would be to write intermediate records, and reference these locally.

+

+
The other would be to write intermediate records, and reference these locally.

 

-

-

-
r1.example.com. TXT v=spf1 include:spf.mailer1.com ~all
-r2.example.com. TXT v=spf1 include:_spf.newsletter.net ~all
-@ TXT v=spf1 include:r1.example.com include:r2.example.com ~all

+

+

+
r1.example.com. TXT v=spf1 include:spf.mailer1.example ~all
+r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
+@ TXT v=spf1 include:r1.example.com include:r2.example.com ~all

 

 

-

-
There are advantages and disadvantages to both approaches.  SPF records have a limit of 10 DNS lookups and record length is limited to 255 characters.  So depending on the embedded records both approaches might have advantages.

+

+
There are advantages and disadvantages to both approaches.  SPF records have a limit of 10 DNS lookups and record length is limited to 255 characters.  So depending on the embedded records both approaches might have advantages.

 

-

-
The implementation would be left to the DNS Provider, but to facilitate this SPF records must NOT be included in templates.  Instead, we introduce a new pseudo-record type in the template called SPFM. This has the following attribute:

+

+
The implementation would be left to the DNS Provider, but to facilitate this SPF records must NOT be included in templates.  Instead, we introduce a new pseudo-record type in the template called SPFM. This has the following attribute:

 

-

-

-            
spfRules

-            

-              

-
Determines the desired rules, basically everything but leading "v=spf1" and trailing all rule -  see: SPF Rules (Section 5.3)

+

+

+            
spfRules

+            

+              

+
Determines the desired rules, basically everything but leading "v=spf1" and trailing all rule -  see: SPF Rules (Section 8.3)

 

 

           

 

 

-

-
When a template is added or removed with an SPFM record in the template, some code would need to take the aggregate value of all SPFM records in all templates applied as well as existing SPF TXT record on the host and recalculate the resulting SPF TXT record. In case several sources specify the same rule with a different policy DNS Provider SHOULD apply the least restrictive one as a result. soft failure SHOULD be preferred over hard failure, neutral SHOULD be preferred over soft failure.

+

+
When a template is added or removed with an SPFM record in the template, some code would need to take the aggregate value of all SPFM records in all templates applied as well as existing SPF TXT record on the host and recalculate the resulting SPF TXT record. In case several sources specify the same rule with a different policy DNS Provider SHOULD apply the least restrictive one as a result. soft failure SHOULD be preferred over hard failure, neutral SHOULD be preferred over soft failure.

 

-

-
DNS Provider SHOULD also allow the end user to modify the SPF record after merging.

+

+
DNS Provider SHOULD also allow the end user to modify the SPF record after merging.

 

-

-
Due to merging step in between, the resulting SPF TXT records are considered non-essential (see: Section 6.5). That means the user may decide to override the final calculated value or remove the whole SPF record. This action must not lead to removal of any related templates in conflict detection and template integrity routines if implemented by the DNS provider.

+

+
Due to merging step in between, the resulting SPF TXT records are considered non-essential (see: Section 9.5). That means the user may decide to override the final calculated value or remove the whole SPF record. This action must not lead to removal of any related templates in conflict detection and template integrity routines if implemented by the DNS provider.

 

-

-
If the existing TXT record makes the merging operation not possible, the DNS provider must handle this situation the same way as a conflict and either let the end-user resolve it in the UX (both in Synchronous and Asynchronous flow) or return the conflict as an error in the Asynchronous flow unless the force=true parameter is used, effectively removing the existing record.

+

+
If the existing TXT record makes the merging operation not possible, the DNS provider must handle this situation the same way as a conflict and either let the end-user resolve it in the UX (both in Synchronous and Asynchronous flow) or return the conflict as an error in the Asynchronous flow unless the force=true parameter is used, effectively removing the existing record.

 

-

-
Service providers should avoid exact match checking content of TXT SPF record, as it might be strongly influenced by the DNS Provider merging strategy and user actions.

+

+
Service providers should avoid exact match checking content of TXT SPF record, as it might be strongly influenced by the DNS Provider merging strategy and user actions.

 

-

-
See Appendix A.5.

+

+
See Appendix A.5.

 

 

 

 

-

+

           

-6.10.4. Alternatives
+9.10.4. Alternatives
           

-

-
Some DNS Providers may decide not to support the SPFM record. The following alternative solution should allow general interoperability of the templates for those providers: onboard the templates with SPFM record in variable-compatible form using a regular TXT record with content "v=spf1 %spfRules% ~all", using property essential=OnApply set to avoid removal of the whole template by a conflict.

+

+
Some DNS Providers may decide not to support the SPFM record. The following alternative solution should allow general interoperability of the templates for those providers: onboard the templates with SPFM record in variable-compatible form using a regular TXT record with content "v=spf1 %spfRules% ~all", using property essential=OnApply set to avoid removal of the whole template by a conflict.

 

 

 

 

 

 

-

+

         

-6.11. Public Template Repository
+9.11. Public Template Repository
         

-

-
The Public Template Repository is an open accessible location where Service Providers
+

+

+          

+9.11.1. General information
+          

+

+
The Public Template Repository is an open accessible location where Service Providers
 MAY publish their Service Templates in the format specified in this specification.
 DNS Providers MAY support all of the published templates, just a subset or none of them according
-to own onboarding policies (see also: Section 7.1).

+to own onboarding policies (see also: Section 10.1).

 

-

-
The template format is intended largely for documentation and communication between the DNS Providers and
+

+
The template format is intended largely for documentation and communication between the DNS Providers and
 Service Providers, and there are no codified endpoints for creation or modification of these objects.
-Instead, Domain Connect references a template by ID.

+Instead, Domain Connect references a template by ID.

 

-

-
As such, DNS Providers may or may not use templates in this format in
+

+
As such, DNS Providers may or may not use templates in this format in
 their internal implementations. By defining a standard template format,
 it is believed it will make it easier for Service Providers to share
-their configuration across DNS Providers.

+their configuration across DNS Providers.

+

+

 

 

-

+

           

-6.11.1. Repository Location
+9.11.2. Repository Location
           

-

-
The  repository of the templates is maintained under
-https://github.com/Domain-Connect/templates.

+

+
The  repository of the templates is maintained under
+https://github.com/Domain-Connect/templates.

 

 

 

 

-

+

           

-6.11.2. File naming requirements
+9.11.3. File naming requirements
           

-

-
The file names in this repository MUST be all lower case, including the providerId
+

+
The file names in this repository MUST be all lower case, including the providerId
 and serviceId. As a result, while the providerId and serviceId can be mixed case,
-all providerIds and serviceIds in this repository must be unique when lower case.

+all providerIds and serviceIds in this repository must be unique when lower case.

 

-

-
Templates MUST be named according the following pattern: providerId.serviceId.json

+

+
Templates MUST be named according the following pattern: providerId.serviceId.json

 

-

-

-
providerId: Acme.com
+

+

+
providerId: example.com
 serviceId: WebsiteBuilder
 
-Template file name: acme.com.websitebuilder.json

+Template file name: example.com.websitebuilder.json

 

 

 

 

 

-

+

           

-6.11.3. Template Integrity
+9.11.4. Template Integrity
           

-

-
Implementers are responsible for data integrity and should use the
+

+
Implementers are responsible for data integrity and should use the
 record type field to validate that variable input meets the criteria for
-each different data type.

+each different data type.

 

-

-
Hard-coded host names are the responsibility of the DNS Provider to
+

+
Hard-coded host names are the responsibility of the DNS Provider to
 protect. That is, DNS Providers are responsible for ensuring that host
 names do not interfere with known values (such as m. or www. or mail.)
 or internal names that provide critical functionality that is outside
-the scope of this specification.

+the scope of this specification.

 

 

 

@@ -4696,217 +4817,215 @@ 

 

 

 

-

+

       

-7. General considerations
+10. General considerations
       

 

-

+

         

-7.1. Onboarding
+10.1. Onboarding
         

-

-
This specification is an open standard that describes the protocol, messages and formats
+

+
This specification is an open standard that describes the protocol, messages and formats
 used to enable Domain Connect between a Service Provider and a DNS
-Provider.

+Provider.

 

-

-
Any Service Provider is free to define and publish a template. However, the terms
+

+
Any Service Provider is free to define and publish a template. However, the terms
 and conditions for a DNS Provider onboarding a Service Provider
 template is beyond the scope of this document. A DNS Provider can
 be selective in what templates they support, can require a contractual
-relationship, or even charge a fee for onboarding.

+relationship, or even charge a fee for onboarding.

 

-

-
One way a Service Provider can be selective in which DNS Providers they accept is to
+

+
One way a Service Provider can be selective in which DNS Providers they accept is to
 implement a whitelist of providerIds. A Service Provider who chooses to whitelist must
 use providerId to distinguish between unique DNS Providers. The DNS providerId is typically
-a domain name.

+a domain name.

 

 

 

 

-

+

         

-7.2. Case Sensitivity
+10.2. Case Sensitivity
         

-

-
All values are case sensitive. This includes variable names, values, parameters and objects
-returned.

+

+
All values are case sensitive. This includes variable names, values, parameters and objects
+returned.

 

-

-
One exception is the domain/host name. This is because a fully qualified domain name is case insensitive.

+

+
One exception is the domain/host name. This is because a fully qualified domain name is case insensitive.

 

-

-
The values for providerId/serviceId in the template and passed through URIs in the path or query string are case sensitive. Different rules apply to the file naming in the Public Template Repository (Section 6.11.2).

+

+
The values for providerId/serviceId in the template and passed through URIs in the path or query string are case sensitive. Different rules apply to the file naming in the Public Template Repository (Section 9.11.3).

 

 

 

 

 

 

-

+

       

-8. Extensions/Exclusions
+11. Extensions/Exclusions
       

-

-
Additional record types and/or extensions to records in the template can
-be implemented on a per DNS Provider basis. However, care should be
-taken when defining extensions so as to not conflict with other
+

+

+        

+11.1. General information
+        

+

+
Additional record types and/or extensions to records in the template can be implemented on a per DNS Provider basis. However, care should be taken when defining extensions so as to not conflict with other
 protocols and standards. Certain record names are reserved for use in
-DNS for protocols like DNSSEC (DNSKEY, RRSIG) at the registry level.

+DNS for protocols like DNSSEC (DNSKEY, RRSIG) [RFC9364] at the registry level.

 

-

-
Defining these OPTIONAL extensions in an open manner as part of this
-specification is done to provide consistency. The following are the initial
-OPTIONAL extensions a DNS Provider/Service Provider may support.

+

+
Defining these OPTIONAL extensions in an open manner as part of this
+specification is done to provide consistency. The following are the initial OPTIONAL extensions a DNS Provider/Service Provider may support.

+

+

 

 

-

+

         

-8.1. APEXCNAME
+11.2. APEXCNAME
         

-

-
Some Service Providers desire the behavior of a CNAME record, but in the
+

+
Some Service Providers desire the behavior of a CNAME record, but in the
 apex record. This would allow for an A Record at the root of the domain
-but dynamically determined at runtime.

+but dynamically determined at runtime.

 

-

-
The recommended record type for DNS Providers that wish to support this
+

+
The recommended record type for DNS Providers that wish to support this
 is an APEXCNAME record. Additional fields included with this record
-would include pointsTo and TTL.

+would include pointsTo and TTL.

 

-

-
Defining a standard for such functionality in DNS is beyond the scope of
+

+
Defining a standard for such functionality in DNS is beyond the scope of
 this specification. But for DNS Providers that support this
 functionality, using the same record type name across DNS Providers
-allows template reuse.

+allows template reuse.

 

 

 

 

-

+

         

-8.2. Redirection
+11.3. Redirection
         

-

-
Some Service Providers desire a redirection service associated with the
+

+
Some Service Providers desire a redirection service associated with the
 A Record. A typical example is a service that requires a redirect of the
 domain (e.g. example.com) to the www variant (www.example.com). The www
-would often contain a CNAME.

+would often contain a CNAME.

 

-

-
Since implementation of a redirection service is typically simple, it is
+

+
Since implementation of a redirection service is typically simple, it is
 recommended that service providers implement redirection on their own.
 But for DNS Providers that have a redirection service, supporting simple
-templates with this functionality may be desired.

+templates with this functionality may be desired.

 

-

-
While technically not a "record" in DNS, when supporting this OPTIONAL
+

+
While technically not a "record" in DNS, when supporting this OPTIONAL
 functionality it is recommended that this should be implemented using two new
-record types.

+record types.

 

-

-
REDIR301 and REDIR302 would implement 301 and 302 redirects
+

+
REDIR301 and REDIR302 would implement 301 and 302 redirects
 respectively. Associated with this record would be a single field called
-the "target", containing the target url of the redirect.

+the "target", containing the target url of the redirect.

 

 

 

 

-

+

         

-8.3. Nameservers
+11.4. Nameservers
         

-

-
Several service providers have asked for functionality supporting an
+

+
Several service providers have asked for functionality supporting an
 update to the nameserver records at the registry associated with the
-domain.

+domain.

 

-

-
When implementing this, two records should be provided. NS1 and NS2,
-each containing a pointsTo argument.

+

+
When implementing this, two records should be provided. NS1 and NS2,
+each containing a pointsTo argument.

 

-

-
It will be noted that a nameserver update would require that the DNS
-Provider is the registrar. This is not always the case.

+

+
It will be noted that a nameserver update would require that the DNS
+Provider is the registrar. This is not always the case.

 

-

-
This functionality is again deemed as OPTIONAL and up to the DNS
-Provider to determine if they will support this.

+

+
This functionality is again deemed as OPTIONAL and up to the DNS
+Provider to determine if they will support this.

 

 

 

 

-

+

         

-8.4. DS (DNSSEC)
+11.5. DS (DNSSEC)
         

-

-
Requests have been made to allow for updates to the DS record for
+

+
Requests have been made to allow for updates to the DS record for
 DNSSEC. This record is required at the registry to enable DNSSEC, but
-can only be written by the registrar.

+can only be written by the registrar.

 

-

-
For DNS Providers that support this record, the record type should be
-DS. Values will be keyTag, algorithm, digestType, and digest.

+

+
For DNS Providers that support this record, the record type should be
+DS. Values will be keyTag, algorithm, digestType, and digest.

 

-

-
Again it should be noted that a DS update would require that the DNS
-Provider is the registrar, and is again deemed as OPTIONAL and up to the
-DNS Provider to determine if they will support.

+

+
Again it should be noted that a DS update would require that the DNS
+Provider is the registrar, and is again deemed as optional and up to the
+DNS Provider to determine if they will support.

 

 

 

 

 

 

-

+

       

-9. IANA Considerations
-      

-

-
TODO

-

-

-

-

-

-      

-10. Acknowledgments
+12. IANA Considerations
       

-

-
The authors wish to thank the following persons for their feedback and suggestions:

+

+
None.

 

-
    
-
  • Chris Ambler of GoDaddy Inc.
-
    • 
-        
  • Jody Kolker of GoDaddy Inc.
-
    • 
-      

 

 

 

-

+

       

-11. Change History
+13. Change History
       

 

-

+

         

-11.1. Change from 03 to 04
-      

+13.1. Change from 03 to 04
+        

+

+

+          

+

+
Version synchronized with 2.2 version rev. 66 of the public Domain
+Connect specification.

+

+

+
Figure 5

+

 
 
 

-

+

         

-11.2. Change from 02 to 03
+13.2. Change from 02 to 03
         

-

-

-          

-

+

+

+          

+

 
Added width/height JSON values returned by DNS Provider Discovery.
 Corrected text of GET method for getting the authorization token.
 Added clarifying text to Group ID description parameter of the apply
@@ -4915,72 +5034,80 @@ 

 Implementation Considerations section.

 

 

-
Figure 5

+
Figure 6

 

 

 

 

-

+

         

-11.3. Change from 01 to 02
+13.3. Change from 01 to 02
         

-

-

-          

-

+

+

+          

+

 
Added new GET method for Service Providers to determine if the DNS
 Provider supports a specific template.  Some other minor edits for
 clarification.

 

 

-
Figure 6

+
Figure 7

 

 

 

 

-

+

         

-11.4. Change from 00 to 01
+13.4. Change from 00 to 01
         

-

-

-          

-

+

+

+          

+

 
Minor edits and clarifications found during implementation.

 

 

-
Figure 7

+
Figure 8

 

 

 

 
 
 

-

+

       

-12. Normative References
+14. Normative References
       

 

 
[RFC2119]

+      

+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", IETF, DOI 10.17487/RFC2119, BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>. 

+

+
[RFC7208]

+      

+Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", IETF, DOI 10.17487/RFC7208, RFC 7208, , <https://www.rfc-editor.org/info/rfc7208>. 

+

+
[RFC6749]

     

-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>. 

+Hardt, D., "The OAuth 2.0 Authorization Framework", IETF, DOI 10.17487/RFC6749, RFC 6749, , <https://www.rfc-editor.org/info/rfc6749>. 
 

 

 

 

 

-

+

       

-13. Informative References
+15. Informative References
       

 

 
[RFC8174]

       

-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>. 

+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", IETF, DOI 10.17487/RFC8174, BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>. 
 

-
[RFC7208]

+
[RFC9364]

     

-Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, RFC 7208, DOI 10.17487/RFC7208, , <https://www.rfc-editor.org/info/rfc7208>. 

+Hoffman, P., "DNS Security Extensions (DNSSEC)", IETF, DOI 10.17487/RFC9364, BCP 237, RFC 9364, , <https://www.rfc-editor.org/info/rfc9364>. 
 

 

 

@@ -4995,45 +5122,44 @@ 

         

 A.1. Example Template
         

-

-

-
{
+

+

+
{
     "providerId": "example.com",
     "providerName": "Example Web Hosting",
     "serviceId": "hosting",
     "serviceName": "Wordpress by example.com",
     "version": 1,
     "logoUrl": "https://www.example.com/images/billthecat.jpg",
-    "description": "This connects your domain to our super cool web hosting",
-    "launchURL" : "https://www.example.com/connectlaunch",
+    "description": "This connects your domain to our web hosting",
     "records": [
         {
-            "groupId" : "service",
             "type": "A",
+            "groupId": "service",
             "host": "www",
             "pointsTo": "%var1%",
-            "ttl": "%var2%"
+            "ttl": 600
         },
         {
-            "groupId" : "service",
             "type": "A",
+            "groupId": "service",
             "host": "m",
-            "pointsTo": "%var3%",
-            "ttl": "%var2%"
+            "pointsTo": "%var2%",
+            "ttl": 600
         },
         {
-            "groupId" : "service",
             "type": "CNAME",
+            "groupId": "service",
             "host": "webmail",
-            "pointsTo": "%var4%",
-            "ttl": "%var2%"
+            "pointsTo": "%var3%",
+            "ttl": 600
         },
         {
-            "groupId" : "verification",
             "type": "TXT",
+            "groupId": "verification",
             "host": "example",
-            "data": "%var5%",
-            "ttl": "%var2%"
+            "ttl": 600,
+            "data": "%var4%"
         }
     ]
 }

@@ -5051,20 +5177,20 @@ 

 section of the template would have a single record of type "A" and could
 have a value of:

 

-

-

-
[{
+

+

+
[{
     "type": "A",
     "host": "www",
-    "pointsTo": "192.168.1.1",
+    "pointsTo": "192.0.2.1",
     "ttl": 600
 }]

 

 

-

+

 
This would have no variable substitution and the application of this
 template to a domain would simply set the host name "www" to the IP
-address "192.168.1.1"

+address "192.0.2.1"

 

 

 

@@ -5078,12 +5204,12 @@ 

 variable, the template would have a single record of type "A" and could
 have a value of:

 
-

-

-
[{
+

+

+
[{
     "type": "A",
     "host": "@",
-    "pointsTo": "192.168.1.%srv%",
+    "pointsTo": "198.51.100.%srv%",
     "ttl": 600
 }]

 

@@ -5092,13 +5218,13 @@ 

 
A query string with a key/value pair of

 

 

-

-
srv=2

+

+
srv=2

 

 

-

+

 
would cause the application of this template to a domain to set the host
-name for the apex A record to the IP address "192.168.1.2" with a TTL of
+name for the apex A record to the IP address "198.51.100.2" with a TTL of
 600

 

 
@@ -5111,46 +5237,46 @@ 

 

 
Consider a DNS Zone before a template application:

 

-

-

-
$ORIGIN test-domain.com.
+

+

+
$ORIGIN example.com.
 
-@ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-1209600 3600
-@ 3600 IN NS ns11.acme.net.
-@ 3600 IN NS ns12.acme.net.
-@ 3600 IN A 1.1.1.1
-@ 3600 IN A 1.1.1.2
+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.
+@ 3600 IN A 192.0.2.1
+@ 3600 IN A 192.0.2.2
 @ 3600 IN AAAA 2001:db8:1234:0000:0000:0000:0000:0000
 @ 3600 IN AAAA 2001:db8:1234:0000:0000:0000:0000:0001
-@ 3600 IN MX 10 mx1.acme.net.
-@ 3600 IN MX 10 mx2.acme.net.
-@ 3600 IN TXT "v=spf1 a include:spf.acme.com ~all"
-www 3600 IN CNAME other.host.com.

+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 3600 IN TXT "v=spf1 a include:spf.example.org ~all"
+www 3600 IN CNAME other.host.example.

 

 

 

 
Now application of the following template:

 

-

-

-
[
+

+

+
[
     {
         "type":"A",
         "host":"@",
-        "pointsTo":"2.2.2.2",
+        "pointsTo":"203.0.113.2",
         "ttl":"1800"
     },
     {
         "type":"A",
         "host":"www",
-        "pointsTo":"2.2.2.2",
+        "pointsTo":"203.0.113.2",
         "ttl":"1800"
     },
     {
         "type":"SPFM",
         "host":"@",
-        "spfRules":"a include:spf.hoster.com"
+        "spfRules":"a include:spf.hoster.example"
     }
 ]

 

@@ -5158,19 +5284,20 @@ 

 

 
The following DNS Zone should be generated after the template is applied:

 

-

-

-
$ORIGIN test-domain.com.
+

+

+
$ORIGIN example.com.
 
-@ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050920 7200 1800
-1209600 3600
-@ 3600 IN NS ns11.acme.net.
-@ 3600 IN NS ns12.acme.net.
-@ 1800 IN A 2.2.2.2
-@ 3600 IN MX 10 mx1.acme.net.
-@ 3600 IN MX 10 mx2.acme.net.
-@ 1800 IN TXT "v=spf1 a include:spf.acme.com include:spf.hoster.com ~all"
-www 1800 IN A 2.2.2.2

+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050920 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.
+@ 1800 IN A 203.0.113.2
+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 1800 IN TXT "v=spf1 a include:spf.example.org include:spf.hoster.ex
+ample ~all"
+www 1800 IN A 203.0.113.2

 

 

 
@@ -5183,40 +5310,40 @@ 

 

 
Consider a DNS Zone before a template application:

 

-

-

-
$ORIGIN test-domain.com.
+

+

+
$ORIGIN example.com.
 
-@ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-1209600 3600
-@ 3600 IN NS ns11.acme.net.
-@ 3600 IN NS ns12.acme.net.

+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.

 

 

 

 
Now application of the following template of Mail service:

 

-

-

-
[
+

+

+
[
     {
         "type":"MX",
         "host":"@",
         "priority": "10",
-        "pointsTo":"mx1.acme.net",
+        "pointsTo":"mx1.example.net",
         "ttl":"1800"
     },
     {
         "type":"MX",
         "host":"www",
         "priority": "10",
-        "pointsTo":"mx2.acme.net",
+        "pointsTo":"mx2.example.net",
         "ttl":"1800"
     },
     {
         "type":"SPFM",
         "host":"@",
-        "spfRules":"a include:spf.acme.net"
+        "spfRules":"a include:spf.example.net"
     }
 ]

 

@@ -5224,30 +5351,30 @@ 

 

 
Expected result in the DNS Zone

 

-

-

-
$ORIGIN test-domain.com.
+

+

+
$ORIGIN example.com.
 
-@ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-1209600 3600
-@ 3600 IN NS ns11.acme.net.
-@ 3600 IN NS ns12.acme.net.
-@ 3600 IN MX 10 mx1.acme.net.
-@ 3600 IN MX 10 mx2.acme.net.
-@ 3600 IN TXT "v=spf1 a include:spf.acme.net ~all"

+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.
+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 3600 IN TXT "v=spf1 a include:spf.example.net ~all"

 

 

 

 
In the next step application of the following template of Newsletter
 service:

 

-

-

-
[
+

+

+
[
     {
         "type":"SPFM",
         "host":"@",
-        "spfRules":"include:_spf.newsletter.com"
+        "spfRules":"include:_spf.newsletter.example"
     }
 ]

 

@@ -5255,17 +5382,19 @@ 

 

 
Expected result in the DNS Zone

 

-

-

-
$ORIGIN test-domain.com.
+

+

+
$ORIGIN example.com.
 
-@ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-1209600 3600
-@ 3600 IN NS ns11.acme.net.
-@ 3600 IN NS ns12.acme.net.
-@ 3600 IN MX 10 mx1.acme.net.
-@ 3600 IN MX 10 mx2.acme.net.
-@ 3600 IN TXT "v=spf1 a include:spf.acme.net include:_spf.newsletter.com ~all"

+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.
+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 3600 IN TXT "v=spf1 a include:spf.example.net include:_spf.newslett
+er.
+example ~all"

 

 

 
@@ -5278,19 +5407,18 @@ 

 Authors' Addresses
       

 

-        
R Carney

-
GoDaddy Inc.

-
14455 N. Hayden Rd. #219

-

-Scottsdale,  

-
United States of America

+        
P Kowalik

+
DENIC eG

+
Theodor-Stern-Kai 1

+
Frankfurt am Main

+
Germany

 
 

 URI:
-http://www.godaddy.com
+https://denic.de
 

 

 

@@ -5301,18 +5429,35 @@ 

 

 
 

-        
P Kowalik

-
IONOS SE

-
Elgendorfer Str. 57

-
Montabaur

-
Germany

+        
J Kolker

+
GoDaddy Inc.

+
14455 N. Hayden Rd. #219

+

+Scottsdale,  

+
United States of America

+
+

+URI:
+https://www.godaddy.com
+

+

+

+        
S Kerola

+
Cloudflare, Inc.

+
101 Townsend St

+

+San Francisco,  

+
United States of America

 
 

 URI:
-https://ionos.com
+https://cloudflare.com
 

 

 
diff --git a/draft-domain-connect-04.rfc.xml b/draft-kowalik-regext-domainconnect-00.rfc.xml
similarity index 64%
rename from draft-domain-connect-04.rfc.xml
rename to draft-kowalik-regext-domainconnect-00.rfc.xml
index 960fe14..9546b32 100644
--- a/draft-domain-connect-04.rfc.xml
+++ b/draft-kowalik-regext-domainconnect-00.rfc.xml
@@ -1,4 +1,4 @@
-
+
 
 
 
@@ -8,50 +8,69 @@
 
 
 
-
+
   
-    Domain Connect API - Communications between DNS Provider and Services
-    
-    
-    
-      GoDaddy Inc.
+    Domain Connect Protocol - DNS provisioning between Services and DNS Providers
+    
+    
+    
+      DENIC eG
       

         
-          14455 N. Hayden Rd. #219
-          Scottsdale
-          US
+          Theodor-Stern-Kai 1
+          Frankfurt am Main
+          DE
         
-        rcarney@godaddy.com
-        http://www.godaddy.com
+        pawel.kowalik@denic.de
+        https://denic.de
       

     
     
       

         
         arnold@arnoldblinn.com
-        
       

     
-    
-      IONOS SE
+    
+      GoDaddy Inc.
       

         
-          Elgendorfer Str. 57
-          Montabaur
-          Germany
+          14455 N. Hayden Rd. #219
+          Scottsdale
+          US
         
-        pawel.kowalik@ionos.com
-        https://ionos.com
+        jkolker@godaddy.com
+        https://www.godaddy.com
+      

+    
+    
+      Cloudflare, Inc.
+      

+        
+          101 Townsend St
+          San Francisco
+          US
+        
+        kerolasa@cloudflare.com
+        https://cloudflare.com
       

     
     Applications and Real-Time
     Registration Protocols Extensions
-    
+    
 
-This document provides information related to the Domain Connect API that was built to support communications between DNS Providers and Service Providers (hosting, social, email, hardware, etc.).
+This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers.
 
   
   
+    
Acknowledgements
+
+The authors wish to thank the following persons for their feedback and suggestions as well as for the previous work on the standard:
+
+
  • Roger Carney of GoDaddy Inc.
    • 
+
  • Chris Ambler of GoDaddy Inc.
    • 
+

+

     
Introduction
 
 Configuring a service at a Service Provider to work with a domain has historically been a complex task that is difficult for users.
@@ -68,103 +87,92 @@
 standard authentication protocols. The creation and modification of DNS
 settings will be done through the application of templates instead of
 direct manipulation of individual DNS records.
+

+    
Terminology
 
-
Terminology
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14   when, and only when, they appear in all capitals, as shown here.
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14   when, and only when, they appear in all capitals, as shown here.
 
-
Service Providers
refers to entities that provide products and
+
Service Providers
refers to entities that provide products and
 services attached to domain names. Examples include web hosting
 providers (such as Wix or SquareSpace), email Service Providers (such as
 Microsoft or Google) and potentially even hardware manufacturers with
 DNS-enabled devices like home routers or automation controls (such as
 Linksys, Nest, and Philips).
-
DNS Providers
refers to entities that provide DNS services such as
+
DNS Providers
refers to entities that provide DNS services such as
 registrars (such as GoDaddy or 1and1) or standalone DNS services (like
-CloudFlare).
-
Registrar
refers to entities that register domain names with registries.
+Cloudflare).
+
Registrar
refers to entities that register domain names with registries.
 It is noted that the DNS Provider and Registrar can be different entities for a
 given domain name and DNS Zone.
-
Customer/User
refers to the end-user of these services.
-
Templates/Service Templates
refers to a file that describes a set of
+
Customer/User
refers to the end-user of these services.
+
Templates/Service Templates
refers to a file that describes a set of
 changes to DNS and domain functionality to enable a specific service.
-
Public Template Repository
refers to a public repository of Templates
+
Public Template Repository
refers to a public repository of Templates
 in a standarised format (read more: ).
-
Root Domain
refers to a registered domain (e.g. example.com or
+
Root Domain
refers to a registered domain (e.g. example.com or
 example.co.uk), or to a delegated zone in DNS.
-
Sub Domain
refers to a sub-domain of a root domain (e.g.
+
Sub Domain
refers to a sub-domain of a root domain (e.g.
 sub.example.com or sub.example.co.uk).
 

-

 

     
Protocol design
 
 
Templates
 
-Templates are core to Domain Connect, as they fully describe a service owned by
+Templates are core to Domain Connect, as they fully describe a service owned by
 a Service Provider and contain all of the information necessary to
 enable and operate/maintain the service in the form of a set of records.
 
-The individual records in a template may be identified by a groupId. This allows for
+The individual records in a template may be identified by a groupId. This allows for
 the application of templates in different stages. For example, an email
 provider might first set a TXT record to verify the domain, and later
 set an MX record to configure email delivery. While done separately,
 both changes are fundamentally part of the same service.
 
-Templates may also contain variable portions, as often values of data in
+Templates may also contain variable portions, as often values of data in
 DNS change based on the implementation and/or user of the
 service (e.g. the IP address of a service, a customer id,
 etc.).
 
-The template is defined by the Service Provider and manually onboarded with the DNS
+The template is defined by the Service Provider and manually onboarded with the DNS
 Provider, according to a template definition published in
 the Public Repository or agreed out-of-band between
 the Service Provider and the DNS Provider.
 
-By basing the protocol on templates instead of DNS Records, several
+By basing the protocol on templates instead of DNS Records, several
 advantages are achieved. The DNS Provider has very explicit knowledge
 and control of the settings being changed to enable a service. And the
 system is more secure as templates are controlled and contained.
 

+

+    
End User Flows
 
-
End User Flows
+
General information
 
-To attach a domain name to a service provided by a Service Provider, the
-customer would first enter their domain name.
+To attach a domain name to a service provided by a Service Provider, the customer would first enter their domain name.
 
-Instead of relying on examination of the nameservers and mapping these
-to DNS Providers, DNS Provider discovery is handled through simple
-records in DNS and an API. The Service Provider queries for a specific
-record in the zone that returns a REST endpoint to initiate the
-protocol. When this endpoint is called, a Domain Connect compliant DNS Provider returns
-information about that domain and how to configure it using Domain
-Connect.
+Instead of relying on examination of the nameservers and mapping these to DNS Providers, DNS Provider discovery is handled through simple records in DNS and an API. The Service Provider queries for a specific record in the zone that returns a REST endpoint to initiate the protocol. When this endpoint is called, a Domain Connect compliant DNS Provider returns information about that domain and how to configure it using Domain Connect.
 
-To apply the changes to DNS, there are two use cases. The
-first is a synchronous web flow, and the second is an asynchronous flow
-using oAuth and an API.
+To apply the changes to DNS, there are two use cases. The
+first is a synchronous web flow, and the second is an asynchronous flow using OAuth and an API.
 
-It is noted that a DNS Provider may choose to only implement one
-of the flows. As a matter of practice many Service Providers are based
-on the synchronous flow, with only a handful of them based on the
-asynchronous oAuth flow. So many DNS providers may opt to only implement
-the synchronous flow.
+It is noted that a DNS Provider may choose to only implement one of the flows. As a matter of practice many Service Providers are based on the synchronous flow, with only a handful of them based on the asynchronous OAuth flow. So many DNS providers may opt to only implement the synchronous flow.
 
-It is also be noted that individual services may work with the
-synchronous flow only, the asynchronous flow only, or with both.
+It is also be noted that individual services may work with the synchronous flow only, the asynchronous flow only, or with both.
+

 
 
The Synchronous Flow
 
-This flow is tailored for the Service Provider that requires a one time
+This flow is tailored for the Service Provider that requires a one time
 synchronous change to DNS.
 
-The user first enters their domain name at the Service Provider
+The user first enters their domain name at the Service Provider
 website.
 
-

+

 
-Service Provider domain inputService Provider domain input
 |                                               |
 +-----------------------------------------------+]]>

 
-After the Service Provider determines the DNS Provider using discovery,
+After the Service Provider determines the DNS Provider using discovery,
 the Service Provider should display a link to the user indicating
 that they can "Connect their Domain" to the service.
 
-

+

 
-Service Provider displays discovery results and offers setup with a DNS providerService Provider displays discovery results and offers setup with a DNS provider
 |                                               |
 +-----------------------------------------------+]]>

 
-After clicking the link, the user is directed to a browser window on the
+After clicking the link, the user is directed to a browser window on the
 DNS Provider's site. This may be done in another tab or in a new
 browser window, but may also be an in place navigation with a return
 url. This link passes the domain name being modified, the service
 provider/template being enabled, and any additional parameters (variables)
 needed to apply the template and configure the service.
 
-Once at the DNS Provider site, the user is asked to authenticate
+Once at the DNS Provider site, the user is asked to authenticate
 if necessary.
 
-

+

 
-DNS provider user authenticationDNS provider user authentication
 |                                               |
 +-----------------------------------------------+]]>

 
-After authenticating at the DNS Provider, the DNS Provider must verify
+After authenticating at the DNS Provider, the DNS Provider must verify
 the DNS zone of the domain name is controlled by the user. The DNS Provider must verify
 other parameters passed in are valid, and must prompt the user for consent to
 make the changes to DNS. The DNS Provider may also warn
 the user of services that would be disabled by applying this change to
 DNS.
 
-

+

 
-User authorization at the DNS provider of the DNS setup for ACMEUser authorization at the DNS provider of the DNS setup for ACME
 |                                               |
 +-----------------------------------------------+]]>

 
-Assuming the user grants this consent, the DNS changes are be applied.
+Assuming the user grants this consent, the DNS changes are be applied.
 
-If invoked in a pop-up window or tab, the browser window should be closed
+If invoked in a pop-up window or tab, the browser window should be closed
 after the changes are applied. If invoked in place, the user must be navigated back
 to the Service Provider after the changes are applied.
 

 
 
The Asynchronous Flow
 
-The asynchronous oAuth flow is tailored for the Service Provider that
+The asynchronous OAuth flow is tailored for the Service Provider that
 wishes to make changes to DNS asynchronously with respect to the user
 interaction, or wishes to make multiple or additional changes to DNS
 over time.
 
-The asynchronous flow begins similarly
+The asynchronous flow begins similarly
 to the synchronous flow. The Service Provider determines the
 DNS Provider and links to a consent dialog at the DNS Provider. Once at
 the DNS Provider the user signs in, control of the DNS zone for the domain is
 verified, and consent is granted.
 
-Instead of applying the DNS changes on user consent, OAuth access is
+Instead of applying the DNS changes on user consent, OAuth access is
 granted to the Service Provider. An OAuth access code is generated and
 handed back to the Service Provider. The Service Provider then requests
 an access (bearer) token.
 
-The permission granted in the OAuth token is a right for the Service
+The permission granted in the OAuth token is a right for the Service
 Provider to apply a requested template (or templates) to the specific
 domain (and specific subdomains) DNS under control of a specific user at the DNS Provider.
 
-The Service Provider would later call the an API to apply a template
+The Service Provider would later call the API of the DNS provider to apply a template
 using the access token.
 
-Additional parameters must be passed as name/value pairs when applying
+Additional parameters must be passed as name/value pairs when applying
 the template.
 

-

 

     
DNS Provider Discovery
 
-To facilitate discovery of the DNS Provider from a domain name DNS is utilized. This is
+To facilitate discovery of the DNS Provider from a domain name DNS is utilized. This is
 done by returning a TXT record for _domainconnect in the zone.
 
-An example of the contents of this record:
+An example of the contents of this record:
 
-
+
 
 
-As a practical matter of implementation, the DNS Provider may or may not
+As a practical matter of implementation, the DNS Provider may or may not
 contain a copy of this data in each and every zone. Instead, the DNS
 Provider must simply respond to the DNS query for the
 _domainconnect TXT record with the appropriate data.
 
-How this is implemented is up to the DNS Provider.
+How this is implemented is up to the DNS Provider.
 
-For example, the DNS Provider may not store the data inside a TXT record
+For example, the DNS Provider may not store the data inside a TXT record
 for the domain, opting instead to put a CNAME in the zone and have the
 TXT record in the target of the CNAME. Another DNS Provider may simply
 respond with the appropriate records at the DNS layer without having the data in each
 zone.
 
-The URL prefix returned is subsequently used by the Service Provider to
+The URL prefix returned is subsequently used by the Service Provider to
 determine the additional settings for using Domain Connect on this
 domain at the DNS Provider. This is done by calling a REST API.
 
-
 
 
-This must return a JSON structure containing the settings to use for Domain Connect on the domain name (passed in on the path) at the DNS Provider. This JSON structure must contain the following fields unless otherwise specified.
+This must return a JSON structure containing the settings to use for
+Domain Connect on the domain name (passed in on the path) at the DNS
+Provider. This JSON structure must contain the following fields unless
+otherwise specified.
 
-properties of the settings data structure
FieldKeyTypeDescription
Provider IdproviderIdStringUnique identifier for the DNS Provider. To ensure non-coordinated uniqueness,
-this should be the domain name of the DNS Provider (e.g. virtucom.com).
Provider NameproviderNameStringThe name of the DNS Provider.
Provider Display NameproviderDisplayNameString(OPTIONAL) The name of the DNS Provider that should be displayed by the Service Provider.
+properties of the settings data structure
FieldKeyTypeDescription
Provider IdproviderIdString(REQUIRED) Unique identifier for the DNS Provider. To ensure non-coordinated uniqueness,
+this should be the domain name of the DNS Provider (e.g. virtucom.example).
Provider NameproviderNameString(REQUIRED) The name of the DNS Provider.
Provider Display NameproviderDisplayNameString(OPTIONAL) The name of the DNS Provider that should be displayed by the Service Provider.
 This may change per domain for some DNS Providers that power multiple brands.
UX URL Prefix for Synchronous FlowsurlSyncUXString(OPTIONAL) The URL Prefix for linking to the UX of Domain Connect for the synchronous flow
 at the DNS Provider. If not returned, the DNS Provider is not supporting the synchronous
 flow on this domain.
UX URL Prefix for Asynchronous FlowsurlAsyncUXString(OPTIONAL) The URL Prefix for linking to the UX elements of Domain Connect for the
 asynchronous flow at the DNS Provider. If not returned, the DNS Provider is not supporting
-the asynchronous flow on this domain.
API URL PrefixurlAPIStringThe URL Prefix for the REST API
Width of WindowwidthNumber(OPTIONAL) This is the desired width of the window for granting consent when navigated in a
+the asynchronous flow on this domain.
API URL PrefixurlAPIString(REQUIRED) The URL Prefix for the REST API
Width of WindowwidthNumber(OPTIONAL) This is the desired width of the window for granting consent when navigated in a
 popup. Default value if not returned should be 750px.
Height of WindowheightNumber(OPTIONAL) This is the desired height of the window for granting consent when navigated in
 a popup. Default value if not returned should be 750px.
UX URL Control PanelurlControlPanelString(OPTIONAL) This is a URL to the control panel for editing DNS at the DNS Provider.
 This field allows a Service Provider whose template isn't supported at the DNS Provider
@@ -348,64 +358,64 @@ replaced with the domain name.
Name Server
 authoritative. This does not indicate the authoritative nameservers; for this the registry
 would be queried.

 
-As an example, the JSON returned by this call might contain.
-
-
 
 
-Discovery must work on the root domain (zone) only. Bear in mind that
+Discovery must work on the root domain (zone) only. Bear in mind that
 zones can be delegated to other users, making this information valuable to
 Service Providers since DNS changes may be different for an apex zone vs.
 a sub-domain for an individual service.
 
-The Service Provider must handle the condition when a query for the
+The Service Provider must handle the condition when a query for the
 _domainconnect TXT record suceeds, but a call to query for the JSON fails.
 This can happen if the zone is hosted with another DNS Provider, but contains an
 incorrect _domainconnect TXT record.
 
-The DNS Provider must return a 404 if they do not contain the zone.
+The DNS Provider must return a 404 if they do not contain the zone.
 
-HTTP status codes for the settings end-point
StatusResponseDescription
Success2xxA response of an http status code of 2xx indicates that the
+HTTP status codes for the settings end-point
StatusResponseDescription
Success2xxA response of an http status code of 2xx indicates that the
 call was successful. The response is the JSON described above.
Not Found404A response of a 404 indicates that the DNS Provider does not have the zone.

 
     
Applying Domain Connect
 
 
Endpoints
 
-The Domain Connect endpoints returned in the JSON during
+The Domain Connect endpoints returned in the JSON during
 discovery are in the form of URLs.
 
-The first set of endpoints are for the UX that the Service Provider
+The first set of endpoints are for the UX that the Service Provider
 links to. These are for the synchronous flow where the user can click
 to grant consent and have changes applied, and for the
-asynchronous oAuth flow where the user can grant consent for
+asynchronous OAuth flow where the user can grant consent for
 OAuth access.
 
-The second set of endpoints are for the REST API.
+The second set of endpoints are for the REST API.
 
-All endpoints begin with a root URL for the DNS Provider such as:
+All endpoints begin with a root URL for the DNS Provider such as:
 
-
+
 
 
-They may also include any prefix at the discretion of the DNS Provider.
+They may also include any prefix at the discretion of the DNS Provider.
 For example:
 
-
+
 
 
-The root URLs for the UX endpoints and the API endpoints are returned in
+The root URLs for the UX endpoints and the API endpoints are returned in
 the JSON payload during DNS Provider discovery.
 

 
@@ -413,40 +423,45 @@ the JSON payload during DNS Provider discovery.
 
 
Query Supported Template
 
-
+{urlAPI}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}]]>
 
 
-This URL is be used by the Service Provider to determine if the DNS
+This URL is be used by the Service Provider to determine if the DNS
 Provider supports a specific template through the synchronous flow.
 
-Returning a status of 200 without a body indicates the template is supported.
+Returning a status of 200 without a body indicates the template is supported.
 The DNS provider may decide to disclose the version of the template
-in a JSON object with field version (see: version field)
+in a JSON object with field version (see: version field
 or the full JSON object of deployed template.
 
-Returning a status of 404 indicates the template is not supported.
+Returning a status of 404 indicates the template is not supported.
 
-https status codes for the Query Supported Template end-point
StatusResponseDescription
Success2xxA response of an http status code of 2xx indicates that the
+https status codes for the Query Supported Template end-point
StatusResponseDescription
Success2xxA response of an http status code of 2xx indicates that the
 call was successful. The response OPTIONALLY contains the version or template.
Not Found404A response of a 404 indicates that the template is not supported

 
 
 
Apply Template
 
-Apply Template URL
 
-{urlSyncUX}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties]]]>
+
 
-This is the URL where the user is sent to apply a template to a domain they own.
+
+This is the URL where the user is sent to apply a template to a domain they own.
 It is called from the Service Provider to start the synchronous Domain Connect Protocol.
 
-This URL can be called in one of two ways.
+This URL can be called in one of two ways.
+

 
 
New Browser Window
 
-The first is through a new browser tab or in a popup browser window.
+The first is through a new browser tab or in a popup browser window.
 The DNS Provider signs the user
 in if necessary, verifies domain ownership, and asks for confirmation
 before application of the template. After application of the template,
@@ -455,41 +470,41 @@ the DNS Provider should automatically close the browser tab or window.
 
 
Same Browser Window
 
-The second is in the current browser tab/window. As above the DNS
+The second is in the current browser tab/window. As above the DNS
 Provider signs the user in if necessary, verifies the user control of the DNS Zone for the domain,
 and asks for confirmation before application of the template. After
 application of the template (or cancellation by the user), the DNS
 Provider must redirect the browser to a return URL (redirect_uri).
 
-Several parameters must be appended to the end of this redirect_uri.
+Several parameters must be appended to the end of this redirect_uri.
 
-
  • State
-If a state parameter is passed in on the query string, this must be
+
    • State
+If a state parameter is passed in on the query string, this must be
 passed back as state= on the redirect_uri.
 
      • 
-
    • Error
-If authorization could not be obtained or an error has occurred, the
+
    • Error
+If authorization could not be obtained or an error has occurred, the
 parameter error= must be appended. For consistency with the asynchronous
 OAuth flows the valid values for the error parameter will be as
-specified in OAuth 2.0 RFC 6749 (4.1.2.1. Error Response - "error"
+specified in OAuth 2.0  (4.1.2.1. Error Response - "error"
 parameter). Valid values are: invalid_request, unauthorized_client,
 access_denied, unsupported_response_type, invalid_scope, server_error,
 and temporarily_unavailable.
 
      • 
-
    • Error Description
-When an error occurs, an OPTIONAL error description containing a
+
    • Error Description
+When an error occurs, an OPTIONAL error description containing a
 developer focused error description may be returned.
 
-Under normal
+Under normal
 operation the access_denied error can be returned for a number of
 reasons. For example, the user may not have access to the account that
 owns the domain. Even if they do and successfully sign-in, the account
 or the domain may be suspended.
 
-It is unlikely that the DNS Provider would want to leak this information
+It is unlikely that the DNS Provider would want to leak this information
 to the Service Provider, and as such the description may be vague.
 
-There is one piece of information that may be interesting to communicate
+There is one piece of information that may be interesting to communicate
 to the Service Provider. This is when the end user decided to cancel the
 operation. If the DNS Provider wishes to communicate this to the
 Service Provider, when the error=access_denied the error_description may
@@ -498,20 +513,20 @@ of the DNS Provider.
 
      • 
 
    
 
-To prevent an open redirect, unless the request is digitally signed the redirect_uri
+To prevent an open redirect, unless the request is digitally signed the redirect_uri
 must be within the domains specified in the template in syncRedirectDomain.
 

 
 
Parameters/properties
 
-query parameters of the apply call in the sync flow
PropertyRequest ParameterDescription
DomaindomainThe domain name being configured. This is the root domain (the
+query parameters of the apply call in the sync flow
PropertyRequest ParameterDescription
Domaindomain(REQUIRED) The domain name being configured. This is the root domain (the
 registered domain or delegated zone).
Hosthost(OPTIONAL) This is the host name of the sub domain. If left blank, the template is being
 applied to the root domain. Otherwise the template is applied to the sub domain of the
 domain.
Redirect URIredirect_uri(OPTIONAL) The location to direct the client browser to upon successful authorization, or
 upon error. If omitted the DNS Provider will close the browser window upon
 completion. It must be scoped to the syncRedirectDomain from the template, or the request
 must be signed.
Statestate(OPTIONAL) A random and unique string passed along to prevent CSRF, or to pass back state.
-It must be returned as a parameter when redirecting to the redirect_uri described above.
Name/Value Pairs*Any key that will be used as a replacement for the "% surrounded" variables in the
+It must be returned as a parameter when redirecting to the redirect_uri described above.
Name/Value Pairs*(REQUIRED) Any key that will be used as a replacement for the "% surrounded" variables in the
 template. The name portion of this API call corresponds to
 the variable(s) specified in the template and the value corresponds to the value that will
 be used when applying the template.
Provider NameproviderName(OPTIONAL) This parameter allows for the caller to provide additional text for display
@@ -523,18 +538,22 @@ with the template serviceName. It should be used to augment the serviceName valu
 from the template, not replace it. This parameter is only allowed when the
 "sharedServiceName" attribute is set in the template.
Group IdgroupId(OPTIONAL) This parameter specifies the groups from the template to apply.
 If no group is specified, all groups are applied. Multiple groups may be specified in a
-comma delimited format.
Signaturesig(OPTIONAL) A signature of the query string. See Security Considerations section below.

+comma delimited format.
Signaturesig(OPTIONAL) A signature of the query string. See Security Considerations section below.
Keykey(OPTIONAL) A value containing the host in DNS where the public key for the signature can be
+obtained. The domain for this host is in the template in syncPubKeyDomain. See Security
+Considerations section below.

 
-An example query string:
+An example query string:
 
-
+https://web-connect.dnsprovider.example/v2/domainTemplates/providers/
+exampleservice.example/services/template1/apply?domain=example.com
+&IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello]]>
 
 
-This call indicates that the Service Provider wishes to connect the
+This call indicates that the Service Provider wishes to connect the
 domain example.com to the service using the template identified by the
-composite key of the provider (exampleservice.domainconnect.org) and the service template
+composite key of the provider (exampleservice.example) and the service template
 owned by them (template1). In this example, there are two variables in this
 template, "IP" and "RANDOMTEXT". These variables are passed as name/value pairs.
 

@@ -542,10 +561,12 @@ template, "IP" and "RANDOMTEXT". These variables are passed as name/value pairs.
 
 
Security Considerations
 
-By applying a template with parameters there is a security
+
Risk of phishing with open template parameters
+
+By applying a template with parameters there is a security
 consideration that must be taken into account.
 
-Consider the template above where the IP address of the A record is
+Consider the template above where the IP address of the A record is
 passed in through a variable. A bad actor could generate a URL with a
 malicious IP and phish users by sending out emails asking them to "re-configure" their
 service. If an end user is convinced to click on
@@ -553,12 +574,12 @@ this link, they would land on the DNS Provider site to confirm the
 change. To the user, this would appear to be a valid request to
 configure the domain. Yet the IP would be hijacking the service.
 
-Not all templates have this problem. But when they do, there are several
-options.
+Not all templates have this problem. But when they do, there are several options.
+

 
 
Disable Synchronous
 
-One option is to disable the synchronous flow and use
+One option is to disable the synchronous flow and use
 asynchronous OAuth. This can be controlled with the syncBlock
 value from the template. However, as will be seen below OAuth has a higher
 implementation burden and requires onboarding between each Service and
@@ -567,79 +588,91 @@ DNS Provider.
 
 
Digitally Sign Requests
 
-Another option is to digitally sign the query string. A
+Another option is to digitally sign the query string. A
 signature is appended as an additional query string parameter,
 properly URL encoded and of the form:
 
-
+
 
 
-The Service Provider generates this signature using a private key. As indicated,
+The Service Provider generates this signature using a private key. As indicated,
 this signature is generated from the query string properly URL encoded.
 
-The Service provider must publish their public key and place it in a DNS TXT
+The Service provider must publish their public key and place it in a DNS TXT
 record in a domain specified in the template in syncPubKeyDomain. To allow for key
 rotation, the host name of the TXT record must be appended as another variable on the query string of the form:
 
-
+
 
 
-This example indicates that the public key can be found by doing a DNS
+This example indicates that the public key can be found by doing a DNS
 query for a TXT record called _dcpubkeyv1 in the domain specified in the
 syncPubKeyDomain from the template.
 
-To account for DNS Servers with limits to the size of a TXT record, multiple
+To account for DNS Servers with limits to the size of a TXT record, multiple
 records may exist for the DNS TXT query. For example, a public key of:
 
-
+
 
 
-may contain several TXT records. The records would be of the form:
+may contain several TXT records. The records would be of the form:
 
-
 
-p=4,a=RS256,t=x509,d=uwm8KlDNHe+8O+cC9j04Ji8B2K0/PzAj90xnb8XJy/EM124hpT9lMgpHKBUvdeurJYweC6oP41gsTf5LrpjnyIy9j5FHPCQIDAQAB]]>
 
-
-Here the public key is broken into four records in DNS, and the data
+Here the public key is broken into four records in DNS, and the data
 also indicates that the signing algorithm is an RSA Signature with
 SHA-256 using an x509 certificate. The value for "a" if omitted will be
 assumed to be RS256, and for "t" will be assumed to be x509.
 
-Note: The only algorithm currently supported is SHA-256 with x509 certificates. The values
+Note: The only algorithm currently supported is SHA-256 with x509 certificates. The values
 are placed here for future compatibility.
 
-The above data was generated for a query string:
+The above data was generated for a query string:
 
-
+
 
 
-Signing the query string by the Service Provider is OPTIONAL. Not
+Signing the query string by the Service Provider is OPTIONAL. Not
 all Services Provider templates require or are able to provide this level of security.
 Presence of the syncPubKeyDomain in the template indicates that the template requires
 signature verification.
 
-Notes:
+Notes:
 
-The digital signature will be generated on the full query string only,
+The digital signature will be generated on the full query string only,
 excluding the sig and key parameters. This is everything after the ?, except the sig and key values.
 
-The values of each query string value key/value pair must be properly URL Encoded
+The values of each query string value key/value pair must be properly URL Encoded
 before the signature is generated.
 

 
 
Warnings
 
-Some applications aren't able to use OAuth and/or sign requests.
+Some applications aren't able to use OAuth and/or sign requests.
 
-If the template require variables, and OAuth and signing isn't available,
+If the template require variables, and OAuth and signing isn't available,
 the flag warnPhishing must be set to true in the template.
 
-When set this indicates to the DNS Provider that they should display extra warnings to
+When set this indicates to the DNS Provider that they should display extra warnings to
 the user to have them verify the link was/is from a reputable source before applying
 the template.
 

@@ -647,30 +680,30 @@ the template.
 
 
Shared Templates
 
-Some templates can be called by multiple companies, or be used for different purposes.
+Some templates can be called by multiple companies, or be used for different purposes.
 
-For example, most services are sold and provided by the same company. However, some
+For example, most services are sold and provided by the same company. However, some
 Service Providers have a reseller channel. This allows the service to be
 provided by the Service Provider, but sold through third parties.
 It is often this third party reseller that configures DNS.
 
-While each reseller could enable Domain Connect, this is inefficient for
+While each reseller could enable Domain Connect, this is inefficient for
 the DNS Providers. Enabling a single template that is shared by multiple
 resellers would be more optimal.
 
-As another example, some templates may be used for different purposes by the same company.
+As another example, some templates may be used for different purposes by the same company.
 
-To facilitate these use cases, the ability to pass in additional context for the display
+To facilitate these use cases, the ability to pass in additional context for the display
 of the providerName and serviceName is enabled. This is only allowed when the template enables the capability
 through the sharedProviderName and/or sharedServiceName flags.
 
-Note: The shared flag used to be used for this purpose, but has been deprecated.
+Note: The shared flag used to be used for this purpose, but has been deprecated.
 
-The exact message presented to the user is up to the DNS Provider. However it is recommended
+The exact message presented to the user is up to the DNS Provider. However it is recommended
 that these fields be used to augment the display of the serviceName and providerName from the template,
 not replace it.
 
-Note: When a Service Provider has a large reseller channel, it is highly
+Note: When a Service Provider has a large reseller channel, it is highly
 recommended that the Service Provider creates an API for their resellers
 to ease the implementation of Domain Connect. There are elements of convenience in doing
 this around Domain Discovery and URL Formatting. But this would be required
@@ -679,17 +712,17 @@ if the template required signatures.
 
 
Verification of Changes
 
-There are circumstances where the Service Provider may wish to verify
+There are circumstances where the Service Provider may wish to verify
 that the template was successfully applied. Without Domain Donnect, this
 typically involved the Service Provider querying DNS to see if the
 changes to DNS had been made.
 
-This same technique works with Domain Connect, and if necessary can be
+This same technique works with Domain Connect, and if necessary can be
 triggered either manually on the Service Provider site or automatically
 upon page/window activation in the browser when the browser window for
 the DNS Provider is closed.
 
-When the redirect_uri is used and an error is not present in the URI,
+When the redirect_uri is used and an error is not present in the URI,
 the Service Provider can not assume the changes were applied to DNS. While true in most
 circumstances, users can tamper with or alter the return
 url in the browser. As such it is recommend that enablement of a service
@@ -699,49 +732,52 @@ be based on verification of changes to DNS.
 
 
Asynchronous Flow: OAuth
 
-Using the OAuth flow is a more advanced use case needed by Service
+
General information
+
+Using the OAuth flow is a more advanced use case needed by Service
 Providers that have more complex configurations that may require
 multiple steps and/or are asynchronous from the user's interaction.
 
-Details of an OAuth implementation are beyond the scope of this
+Details of an OAuth implementation are beyond the scope of this
 specification. Instead, an overview of how OAuth is used by Domain
 Connect is given here.
 
-Not all DNS Providers will support the asyncronous flow. As such it is
+Not all DNS Providers will support the asyncronous flow. As such it is
 recommended that Service Providers relying on an OAuth implementation also
 implement a synchronous implementation.
+

 
 
OAuth Flow: Setup
 
-Service providers wishing to use the OAuth flow must register as an
+Service providers wishing to use the OAuth flow must register as an
 OAuth client with each DNS provider. This is a manual
 process.
 
-To register, the Service Provider would provide (in addition to their
+To register, the Service Provider would provide (in addition to their
 template) any configuration necessary for the DNS Providers OAuth
 implementation. This includes valid URLs and Domains for redirects upon
 success or errors.
 
-Note: The validity of redirects are very important in any OAuth implementation.
+Note: The validity of redirects are very important in any OAuth implementation.
 Most OAuth vulnerabilities are a combination of an open redirect and/or a
 compromised secret.
 
-In return, the DNS provider will give the Service Provider a client id
+In return, the DNS provider will give the Service Provider a client id
 and a secret which will be used when requesting tokens. For simplicity the client
 id should be the same as the providerId.
 

 
 
OAuth Flow: Getting an Authorization Code
 
-
 
 
-To initiate the OAuth flow the Service Provider first links to the DNS
+To initiate the OAuth flow the Service Provider first links to the DNS
 Provider to gain consent.
 
-This endpoint is similar to the synchronous flow described above. The DNS Provider
+This endpoint is similar to the synchronous flow described above. The DNS Provider
 must authenticate the user, verify the user has control of the DNS Zone for the domain, and ask the user for
 permission. Instead of permission to make a change to DNS, the permission
 is now to allow the Service Provider to
@@ -750,184 +786,187 @@ DNS Provider may warn the user that (the eventual)
 application of a template might change existing records and/or disrupt
 existing services attached to the domain.
 
-While the variables for the applied template would be provided later,
+While the variables for the applied template would be provided later,
 the values of some variables may be necessary to determine conflicts. As
 such, any variables impacting conflicting records should be provided
 in the consent flow. Today this includes variables in hosts, and
 variables in the data portion for certain TXT records. As conflict
 resolution evolves, this list may grow.
 
-The protocol allows for the Service Provider to gain consent to apply
+The protocol allows for the Service Provider to gain consent to apply
 multiple templates. These templates are specified in the scope parameter. It
 also allows for the Service Provider to gain consent to apply these templates to the domain
 or to the domain with multiple sub-domains. These are specified in the domain and host
 parameter. If conflict detection is implemented
 by the DNS Provider, they should account for all permutations.
 
-The scope parameter is a space separated list (as per the OAuth protocol)
+The scope parameter is a space separated list (as per the OAuth protocol)
 of the template serviceIds. The host parameter is an OPTIONAL comma separated
 list of hosts. A blank entry for the host implies the template can be
 applied to the root domain. For example:
 
-examples of scope and host parameter values in the async flow
Query StringDescription
scope=t1+t2&domain=example.comTemplates "t1" and "t2" can be applied to example.com
scope=t1+t2&domain=example.com&host=sub1,sub2Templates "t1" and "t2" can be applied to sub1.example.com or sub2.example.com
scope=t1+t2&domain=example.com&host=sub1,Templates "t1" and "t2" can be applied to example.com or sub1.example.com

+examples of scope and host parameter values in the async flow
Query StringDescription
scope=t1+t2=example.comTemplates "t1" and "t2" can be applied to example.com
scope=t1+t2=example.com=sub1,sub2Templates "t1" and "t2" can be applied to sub1.example.com or sub2.example.com
scope=t1+t2=example.com=sub1,Templates "t1" and "t2" can be applied to example.com or sub1.example.com

 
-Upon successful authorization/verification/consent from the user, the
+Upon successful authorization/verification/consent from the user, the
 DNS Provider will direct the end user's browser to the redirect URI. The
 authorization code will be appended to this URI as a query parameter of
 "code=" as per the OAuth specification.
 
-Similar to the synchronous flow, upon error the DNS provider may append
+Similar to the synchronous flow, upon error the DNS provider may append
 an error code as query parameter "error". These errors are also from the
-oAuth 2.0 RFC 6749 (4.1.2.1. Error Response - "error" parameter). Valid
+OAuth 2.0  (4.1.2.1. Error Response - "error" parameter). Valid
 values include: invalid_request, unauthorized_client, access_denied,
 unsupported_response_type, invalid_scope, server_error, and
 temporarilly_unavailable. An OPTIONAL error_description suitable for
 developers may also be returned at the discretion of the DNS Provider.
 The same considerations as in the synchronous flow apply here.
 
-The state value passed into the call must be passed back on the query
+The state value passed into the call must be passed back on the query
 string as "state=".
 
-The following table describes the values in the query
+The following table describes the values in the query
 string parameters for the request for the OAuth consent flow that must be included unless otherwise
 indicated
 
-query parameters of the authorization end-point in async flow
PropertyKeyDescription
DomaindomainThe domain name being configured. This is the root domain (the registered domain or delegated zone).
Hosthost(OPTIONAL) An list of comma separated host names upon which the template may be applied. An empty string implies the root.
Client Idclient_idThe client id that was provided by the DNS provider to the service provider
-during registration. It is recommended that this should be the same as the providerId in the template.
Redirect URIredirect_uriThe location to direct the client's browser upon successful authorization or upon error.
+query parameters of the authorization end-point in async flow
PropertyKeyDescription
Domaindomain(REQUIRED) The domain name being configured. This is the root domain (the registered domain or delegated zone).
Hosthost(OPTIONAL) An list of comma separated host names upon which the template may be applied. An empty string implies the root.
Client Idclient_id(REQUIRED) The client id that was provided by the DNS provider to the service provider
+during registration. It is recommended that this should be the same as the providerId in the template.
Redirect URIredirect_uri(REQUIRED) The location to direct the client's browser upon successful authorization or upon error.
 Validation of the redirect_uri will be done by the DNS Provider to match the values provided during onboarding.
Response typeresponse_type(OPTIONAL) If included it must be the string 'code' to indicate an authorization code
-is being requested.
ScopescopeThe OAuth scope corresponds to the requested templates. This is list of space separated
+is being requested.
Scopescope(REQUIRED) The OAuth scope corresponds to the requested templates. This is list of space separated
 serviceIds.
Provider NameproviderName(OPTIONAL) This parameter allows for the caller to provide additional text for display
 with the template providerName. This text should be used to augment the providerName value
 from the template, not replace it.
Service NameserviceName(OPTIONAL) This parameter allows for the caller to provide additional text for display
 with the template serviceName(s). It should be used to augment the serviceName value(s)
 from the template, not replace.
Statestate(OPTIONAL) This is a random, unique string passed along to prevent CSRF or
 to pass state value back to the caller. It will be returned as a parameter appended to
-the redirect_url described above.

+the redirect_url described above.
Name/Value Pairs*(OPTIONAL) Any key that will be used as a replacement for the "% surrounded" value(s) in a
+template required for conflict detection. This includes variables used in hosts and
+data in certain TXT records.

 

 
-
oAuth Flow: Requesting an Access Token
+
OAuth Flow: Requesting an Access Token
 
-
 
 
-Once authorization has been granted, the Service Provider must use the
-Authorization Code provided to request an Access Token. The oAuth
+Once authorization has been granted, the Service Provider must use the
+Authorization Code provided to request an Access Token. The OAuth
 specification recommends that the Authorization Code be a short lived
 token, and a reasonable recommended setting is ten minutes. As such this
 exchange needs to be completed before that time has expired or the
 process will need to be repeated.
 
-This token exchange is typically done via a server to server API call from the
+This token exchange is typically done via a server to server API call from the
 Service Provider to the DNS Provider using a POST. When called in this manner a
 secret is provided
 along with the Authorization Code.
 
-OAuth does allow for retrieving the access token without a secret. This is typically
+OAuth does allow for retrieving the access token without a secret. This is typically
 done when the OAuth client is a client application.
 When onboarding with the DNS Provider this would need to be enabled.
 
-When the secret is provided (which is the normal case), care must be taken. A malicious
+When the secret is provided (which is the normal case), care must be taken. A malicious
 user could create a domain that returns a false _domainconnect TXT record, and
 subsequently a JSON call to their own server for the API end point. By doing so, they
 could then run Domain Connect on their domain and retrieve the secret.
 
-As such the urlAPI used for oAuth by the Service Provider should be maintained per DNS
+As such the urlAPI used for OAuth by the Service Provider should be maintained per DNS
 Provider and not the value retrieved during discovery.
 
-The following table describes the POST parameters that must be included in the
+The following table describes the POST parameters that must be included in the
 request for the access token unless otherwise indicated.
 The parameters should be accepted via the
 query string or the body of the post. This is again particularly
 important for the client_secret, as passing secrets via a query string
 is generally frowned upon given that various systems often log URLs.
 
-The body of the post is application/json encoded.
+The body of the post is application/json encoded.
 
-parameters of the token end-point
PropertyKeyDescription
Authorization Code/Refresh Codecode/refresh_tokenThe authorization code that was
+parameters of the token end-point
PropertyKeyDescription
Authorization Code/Refresh Codecode/refresh_token(REQUIRED) The authorization code that was
 provided in the previous step when the customer accepted the
 authorization request, or the refresh_token for a subsequent access
-token.
Redirect URIredirect_uri(OPTIONAL) This is required if a redirect_uri was
+token.
Redirect URIredirect_uri(OPTIONAL) This is REQUIRED if a redirect_uri was
 passed to request the authorization code. When included, it needs to be
-the same redirect_uri provided in this step.
Grant typegrant_typeThe type of code in the request. Usually the string 'authorization_code' or 'refresh_token'
Client IDclient_idThis is the client id that was provided by the DNS provider to the Service Provider during
-registration
Client Secretclient_secretThe secret provided to the Service Provider during registration. Typically required
-unless the rare circumstance with secret-less oAuth.

+the same redirect_uri provided in this step.
Grant typegrant_type(REQUIRED) The type of code in the request. Usually the string 'authorization_code' or 'refresh_token'
Client IDclient_id(REQUIRED) This is the client id that was provided by the DNS provider to the Service Provider during
+registration
Client Secretclient_secret(REQUIRED) The secret provided to the Service Provider during registration. Typically required
+unless the rare circumstance with secret-less OAuth.

 
-Upon successful token exchange, the DNS Provider will return a response
+Upon successful token exchange, the DNS Provider will return a response
 with 4 properties in the body of the response.
 
-properties of the token end-point response
PropertyDescription
access_tokenThe access token to be used when making API requests
token_typeAlways the string "bearer"
expires_inThe number of seconds until the access_token expires
refresh_tokenThe token that can be used to request new access tokens when this one has expired.

+properties of the token end-point response
PropertyDescription
access_tokenThe access token to be used when making API requests
token_typeAlways the string "bearer"
expires_inThe number of seconds until the access_token expires
refresh_tokenThe token that can be used to request new access tokens when this one has expired.

 
-http status codes of the token end-point response
StatusResponseDescription
Success2xxA response of an http status code of 2xx indicates that the
+http status codes of the token end-point response
StatusResponseDescription
Success2xxA response of an http status code of 2xx indicates that the
 call was successful. The response is the JSON described above.
Errors4**All other responses indicate an error.

 
 
 
OAuth Flow: Making Requests with Access Tokens
 
-Once the Service Provider has the access token, they can call the DNS
+Once the Service Provider has the access token, they can call the DNS
 Provider's API to make changes to DNS on the domain by applying and (OPTIONALLY)
 removing authorized templates. These templates can be applied to the
 root domain or to any sub-domain of the root domain that has been authorized.
 
-All calls to this API pass the access token in the Authorization Header
+All calls to this API pass the access token in the Authorization Header
 of the request to the call to the API. More details can be found in the
 OAuth specifications, but as an example:
 
-
 
 
-While the calls below do not have the same security consideration of
+While the calls below do not have the same security consideration of
 passing the secret, it is recommend that the urlAPI be from a stored
 value vs. the value returned during discovery here as well.
 

 
 
OAuth Flow: Apply Template to Domain.
 
-
+{urlAPI}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}/apply?[properties]]]>
 
 
-The primary function of the API is to apply a template to a customer
+The primary function of the API is to apply a template to a customer
 domain.
 
-While the providerId is implied in the authorization, this is on the
+While the providerId is implied in the authorization, this is on the
 path for consistency with the synchronous flows and other APIs. If not
 matching what was authorized, an error must be returned.
 
-When applying a template to a domain, it is possible that a conflict may
+When applying a template to a domain, it is possible that a conflict may
 exist with previous settings. While it is recommended that conflicts be
 detected when the user grants consent, because OAuth is asynchronous it
 is possible that a new conflict was introduced by the user.
 
-While it is up to the DNS Provider to determine what constitutes a
+While it is up to the DNS Provider to determine what constitutes a
 conflict (see section on Conflicts below), when one is detected calling
 this API must return an error. This error should enumerate the
 conflicting records in a format described below.
 
-Because the user often isn't present at the time of this error, it is up the
+Because the user often isn't present at the time of this error, it is up the
 Service Provider to determine how to handle this condition. Some providers
 may decide to notify the user. Others may decide to apply their template
 anyway using the "force" parameter. This parameter will bypass error
 checks for conflicts, and after the call the service will be in its
 desired state.
 
-Calls to apply a template via OAuth require the following parameters
+Calls to apply a template via OAuth require the following parameters
 posted to the above URL unless otherwise indicated.
 The DNS Provider must accept parameters in query string or body of this
 post.
 
-The body is application/json encoded.
+The body is application/json encoded.
 
-query parameters of the apply end-point in the async flow
PropertyKeyDescription
DomaindomainThe root domain name being configured. It must match the domain that was authorized
+query parameters of the apply end-point in the async flow
PropertyKeyDescription
Domaindomain(REQUIRED) The root domain name being configured. It must match the domain that was authorized
 in the token.
Hosthost(OPTIONAL) The host name of the sub domain of the root domain that was authorized in the
 token. If omitted or left blank, the template is being applied to the root
-domain.
Name/Value Pairs*Any variable fields consumed by
+domain.
Name/Value Pairs*(REQUIRED) Any variable fields consumed by
 this template. The name portion of this API call corresponds to the
 variable(s) specified in the record and the value corresponds to the
 value that must be used when applying the template as per the
@@ -945,26 +984,28 @@ in the template being applied.
InstanceId<
 (see multiInstance template property). Allows for later
 removal of one template instance by DNS Providers storing this information.

 
-An example call is below. In this example, it is contemplated that there
+An example call is below. In this example, it is contemplated that there
 are two variables in this template, "IP" and "RANDOMTEXT" which both require
 values. These variables are
 passed as name/value pairs.
 
-
+https://connect.dnsprovider.example/v2/domainTemplates/providers/
+exampleservice.example/services/template1/apply?IP=192.0.2.42
+&RANDOMTEXT=shm%3A1542108821%3AHello&force=1]]>
 
 
-The API must validate the access token, and that the domain belongs to
+The API must validate the access token, and that the domain belongs to
 the customer and is represented by the token being presented. Any errors
 with variables, conflicting templates, or problems with the state of the
 domain are returned; otherwise the template is applied.
 
-Results of this call can include information indicating success or an
+Results of this call can include information indicating success or an
 error. Errors will be 400 status codes, with the following codes
 defined.
 
-http status codes of the apply end-point in the async flow
StatusResponseDescription
Success2xxA response of an http status code of 204 indicates that
+http status codes of the apply end-point in the async flow
StatusResponseDescription
Success2xxA response of an http status code of 204 indicates that
 call was successful and the template applied. Note that any 200 level
 code must be considered a success.
Bad Request400A response of a 400 indicates that the server cannot process the request because it
 was malformed or had errors. This response code is intended for programming errors.
Unauthorized401A response of a 401 indicates that caller is not
@@ -976,14 +1017,14 @@ not equal to 1.
Error

 
-When a 409 is returned, the body of the response should contain details of
+When a 409 is returned, the body of the response should contain details of
 the conflicting records. This should be JSON containing the error code, a message
 suitable for developers, and an array of tuples containing the
 conflicting records type, host, and data element.
 
-As an example:
+As an example:
 
-
 }]]>
 
 
-In this example, the Service Provider tried to apply a new hosting
+In this example, the Service Provider tried to apply a new hosting
 template. The domain had an existing service applied for hosting.
 
 
 
OAuth Flow: Revert Template
 
-This call reverts the application of a specific template from a domain.
+This call reverts the application of a specific template from a domain.
 
-Implementation of this call is OPTIONAL. If not supported a 501 MUST be returned.
+Implementation of this call is OPTIONAL. If not supported a 501 MUST be returned.
 
-
+{urlAPI}/v2/domainTemplates/providers/{providerId}/services
+/{serviceId}/revert?domain={domain}&host={host}]]>
 
 
-This API allows the removal of a template from a customer domain/host
+This API allows the removal of a template from a customer domain/host
 using an OAuth request.
 
-The provider and service name in the URL must match the values provided during authorization.
+The provider and service name in the URL must match the values provided during authorization.
 
-This call must validate that the template exists and has been
+This call must validate that the template exists and has been
 applied to the domain by the Service Provider, or a warning must be
 returned that the call would have no effect.
 
-An example query string might look like:
+An example query string might look like:
 
-
+https://connect.dnsprovider.example/v2/domainTemplates/providers
+/exampleservice.example/services/template1/revert?domain=example.com]]>
 
 
-Allowed parameters:
+Allowed parameters:
 
-query parameters of the revert end-point in the async flow
PropertyKeyDescription
DomaindomainThe root domain name being configured. It
-must match the domain that was authorized in the token.
HosthostThe host name of the sub domain of the root domain that was authorized in the token.
+query parameters of the revert end-point in the async flow
PropertyKeyDescription
Domaindomain(REQUIRED) The root domain name being configured. It
+must match the domain that was authorized in the token.
Hosthost(OPTIONAL) The host name of the sub domain of the root domain that was authorized in the token.
 If omitted or left blank, the template is being applied to the root
 domain.
InstanceIdinstanceId(OPTIONAL) Only applicable to templates supporting multiple instances
 (see multiInstance template property). For DNS Provider
 storing information about applied templates allows removal of single instance
 of template. If missing all instances of template should be removed.

 
-The DNS Provider should be able to accept these on the query string or in the body of the POST with application/json encoding.
+The DNS Provider should be able to accept these on the query string or in the body of the POST with application/json encoding.
 
-Response codes Success, Authorization, and Errors are identical to
+Response codes Success, Authorization, and Errors are identical to
 above with the addition of the 501 code.
 
 
 
OAuth Flow: Revoking access
 
-Like all oAuth flows, the user may revoke the access at any time using
+Like all OAuth flows, the user may revoke the access at any time using
 UX at the DNS Provider site. As such the Service Provider needs to be
 aware that their access to the API may be denied.
 

@@ -1060,21 +1103,21 @@ aware that their access to the API may be denied.
 
 
Template Versioning
 
-If a breaking change is made to a template it is recommended that a new template be created. While on the surface versioning looks appealing, in reality this is rarely needed.
+If a breaking change is made to a template it is recommended that a new template be created. While on the surface versioning looks appealing, in reality this is rarely needed.
 
-Any changes to the template need to account for existing customers with settings in DNS, some applied through Domain Connect and some manual. So when changes are made, they are often backward compatible.
+Any changes to the template need to account for existing customers with settings in DNS, some applied through Domain Connect and some manual. So when changes are made, they are often backward compatible.
 
-Note that when a template changes, it does need to be on-boarded with the DNS Providers.
+Note that when a template changes, it does need to be on-boarded with the DNS Providers.
 
-The version field of the template definition serves the purpose of transparency between the DNS Provider and the Service Provider in case of such changes.
+The version field of the template definition serves the purpose of transparency between the DNS Provider and the Service Provider in case of such changes.
 

 
 
Template Definition
 
-A template is defined as a standard JSON data structure containing the following data. Fields are required unless otherwise indicated.
+A template is defined as a standard JSON data structure containing the following data. Fields are required unless otherwise indicated.
 
-properties of the template definition
Data ElementTypeKeyDescription
Service Provider IdStringproviderIdThe unique identifier of the Service Provider that created this template. This is used in the URLs to identify the Service Provider. To ensure non-coordinated uniqueness, this should be the domain name of the Service Provider (e.g. exampleservice.domainconnect.org).
Service Provider NameStringproviderNameThe name of the Service Provider suitable for display. This may be displayed to the user on the DNS Provider consent UX.
Service IdStringserviceIdThe name or identifier of the template.
-This is used in URLs to identify the template. It is also used in the scope parameter for oAuth. It must not contain space characters, and must be URL friendly.
Service NameStringserviceNameThe name of the service suitable for display to the user. This may be displayed to the user on the DNS Provider consent UX.
VersionIntegerversion(OPTIONAL)
+properties of the template definition
Data ElementTypeKeyDescription
Service Provider IdStringproviderId(REQUIRED) The unique identifier of the Service Provider that created this template. This is used in the URLs to identify the Service Provider. To ensure non-coordinated uniqueness, this should be the domain name of the Service Provider (e.g. exampleservice.example).
Service Provider NameStringproviderName(REQUIRED) The name of the Service Provider suitable for display. This may be displayed to the user on the DNS Provider consent UX.
Service IdStringserviceId(REQUIRED) The name or identifier of the template.
+This is used in URLs to identify the template. It is also used in the scope parameter for OAuth. It must not contain space characters, and must be URL friendly.
Service NameStringserviceName(REQUIRED) The name of the service suitable for display to the user. This may be displayed to the user on the DNS Provider consent UX.
VersionIntegerversion(OPTIONAL)
 If present this represents a version of the template and should be increased with each update of the template content. This value is mainly informational to improve communication and transparency between providers.
LogoStringlogoUrl(OPTIONAL) A graphical logo representing the Service Provider and/or Service for use in any web-based flow. If present this may be displayed to the user on the DNS Provider consent UX.
DescriptionTextdescription(OPTIONAL) A textual description of what this template attempts to do. This is meant to assist developers and must not be displayed to the user.
Variable DescriptionTextvariableDescription(OPTIONAL) A textual description of what the variables are. This is meant to assist developers and must not be displayed to the user.
Synchronous BlockBooleansyncBlock(OPTIONAL) Indicates that the synchronous protocol must be disabled for this template. The default for this is false.
SharedBooleanshared(OPTIONAL)
 This flag has been deprecated. It used to indicate that the template allowed a dynamic providerName on the query string. It is replaced with the sharedProviderName flag in v2.2 of the spec.
Shared Provider NameBooleansharedProviderName(OPTIONAL)
 This flag indicates that the template allows the caller to pass in additional information for the providerName. This information should augment the display of the providerName from the template. The default for this is false. For backward compatability with DNS Providers not at V2.2 of the spec it is recommended that the shared flag also be set.
Shared Service NameBooleansharedServiceName(OPTIONAL)
@@ -1087,104 +1130,96 @@ maintain template state in DNS.
Warn Phish
 When present, this tells the DNS Provider that the template may contain
 variables susceptible to phishing attacks and the provider is unable to digitally sign the requests. When set the DNS Provider should display warnings to the user.
 The default value for this is false.
Host RequiredBooleanhostRequired(OPTIONAL)
-Defaults to false. When present this indicates that the template has been authored to work only when both domain and host are provided. An example where this would be true would be a template where CNAME is set on the fully qualified domain name. This is largely informational, as most DNS Providers already enforce such rules.
Template RecordsArray of Template RecordsrecordsA list of records for the template.

+Defaults to false. When present this indicates that the template has been authored to work only when both domain and host are provided. An example where this would be true would be a template where CNAME is set on the fully qualified domain name. This is largely informational, as most DNS Providers already enforce such rules.
Template RecordsArray of Template Recordsrecords(REQUIRED) A list of records for the template.

 

 
 
Template Record
 
-Each template record is an entry that contains a type and several
+Each template record is an entry that contains a type and several
 other values depending on the type.
 
-Many of these values can contain variables. There are three built in variables.
+Many of these values can contain variables. There are three built in variables.
 
-
  • %host%: This is the host passed from the query string
    • 
+
    • %host%: This is the host passed from the query string
      • 
 
    • %domain%: This is the domain passed from the query string
      • 
 
    • %fqdn%: This is the fully qualified domain name e.g. [host.]domain
      • 
 
    
 
-The @ symbol has special meaning, and can be used in the host/name field or in
+The @ symbol has special meaning, and can be used in the host/name field or in
 the pointsTo/data field in isolation.
 
-For the host/name field it is a shortcut for the value "%fqdn%.". When applying the
+For the host/name field it is a shortcut for the value "%fqdn%.". When applying the
 template to a domain only, it represents "example.com.". When applying with a sub-domain
 (host) it represents "subdomain.example.com.".
 
-Note: The trailing dot here is similar to the bind protocol, which indicates the value
-is absolute. Without the trailing ".", the value in this field is relative to the [host.]domain.com
+Note: The trailing dot here is similar to the bind notation, which indicates the value
+is absolute. Without the trailing ".", the value in this field is relative to the [host.]example.com
 value.
 
-For the pointsTo/data field it is a shortcut for for the "%fqdn%". When appling
+For the pointsTo/data field it is a shortcut for for the "%fqdn%". When appling
 the template to a domain only, it represents "example.com". When applying with a sub-
 domain (host) it represents "subdomain.example.com".
 
-Note: The pointsTo and data files are always absolute for these fields.
+Note: The pointsTo and data files are always absolute for these fields.
 
-It is noted that as a best practice the variable portions should be constrained
+It is noted that as a best practice the variable portions should be constrained
 to as small as possible a portion of the resulting DNS record.
 
-For example, say a Service Provider requires a CNAME of one of three
+For example, say a Service Provider requires a CNAME of one of three
 values for their users: s01.example.com, s02.example.com, and
 s03.example.com.
 
-The value in the template could simply contain %servercluster%, and the
+The value in the template could simply contain %servercluster%, and the
 fully qualified string passed in. Alternatively, the value in the
 template could contain %var%.example.com and a value of 01, 02, or 03 passed in.
 By placing more fixed data into the template, the template is more secure.
 
-Each record will contain the following elements.
-
-properties of the template record definition
    Data ElementTypeKeyDescription
    TypeenumtypeDescribes the type of record in DNS, or the operation impacting DNS.
-
-Valid values include: A, AAAA, CNAME, MX, TXT, SRV, or SPFM
-
-For each type, additional fields would be required.
-
-A: host, pointsTo, TTL
-
-AAAA: host, pointsTo, TTL
-
-CNAME: host, pointsTo, TTL (host must not be null or @)
+Each record will contain the following elements.
 
-NS: host, pointsTo, TTL (host must not be null or @)
+properties of the template record definition
    Data ElementTypeKeyDescription
    Typeenumtype(REQUIRED) Describes the type of record in DNS, or the operation impacting DNS.
    
 
-TXT: host, data, TTL, txtConflictMatchingMode, txtConflictMatchingPrefix
+Valid values include: A, AAAA, CNAME, MX, TXT, SRV, or SPFM
    
 
-MX: host, pointsTo, TTL, priority
-
-SRV: name, target, TTL, priority, protocol, service, weight, port
-
-SPFM: host, spfRules
    Group IdStringgroupId(OPTIONAL)
+For each type, additional fields would be REQUIRED.
    
+* A: host, pointsTo, TTL
    
+* AAAA: host, pointsTo, TTL
    
+* CNAME: host, pointsTo, TTL (host must not be null or @ unless hostRequired is defined true for the template)
    
+* NS: host, pointsTo, TTL (host must not be null or @ unless hostRequired is defined true for the template)
    
+* TXT: host, data, TTL, txtConflict-MatchingMode, txtConflict-MatchingPrefix
    
+* MX: host, pointsTo, TTL, priority
    
+* SRV: name, target, TTL, priority, protocol, service, weight, port
    
+* SPFM: host, spfRules
    Group IdStringgroupId(OPTIONAL)
 This parameter identifies the group the record belongs to when applying changes. This must
 not contain variables.
    Essentialenumessential(OPTIONAL)
 This parameter indicates how the record is treated during conflict detection with
-existing templates.
+existing templates.
    
 
-If the DNS Provider is not implementing applied template state in DNS this is ignored.
+If the DNS Provider is not implementing applied template state in DNS this is ignored.
    
 
-Always (default) - record MUST be applied and kept with the template
+Always (default) - record MUST be applied and kept with the template
    
 
 OnApply - record MUST be applied but can be later removed without dropping the whole
-template
    HostStringhostThe host for A, AAAA, CNAME, NS, TXT, and MX values.
+template
    HostStringhost(REQUIRED) The host for A, AAAA, CNAME, NS, TXT, and MX values.
    
 
-This value is relative to the applied host and domain, unless trailed by a ".".
+This value is relative to the applied host and domain, unless trailed by a ".".
    
 
 A value of empty or @ indicates the root of the applied host and domain. In other words
-"[host.]domain.com.".
+"[host.]example.com.".
    
 
 This value should not contain variables unless absolutely necessary. This is discussed
-below.
    NameStringnameThe name for the SRV record.
+below.
    NameStringnameThe name for the SRV record.
    
 
 This value is relative to the applied host and domain. A value of empty or @ indicates
-the root of the applied host and domain.
+the root of the applied host and domain.
    
 
 This value should not contain variables unless absolutely necessary. This is discussed
-below.
    Points ToStringpointsToThe pointsTo location for A, AAAA, CNAME, NS and MX records.
+below.
    Points ToStringpointsToThe pointsTo location for A, AAAA, CNAME, NS and MX records.
    
 
-A value of empty or @ indicates the host and domain name being applied or [host.]domain.com
    TTLIntttlThe time-to-live for the record in DNS. Valid
+A value of empty or @ indicates the host and domain name being applied or [host.]example.com
    TTLIntttlThe time-to-live for the record in DNS. Valid
 for A, AAAA, CNAME, NS, TXT, MX, and SRV records. This must not contain variables.
    DataStringdataThe data for a TXT record in DNS.
 
-A value of empty or @ indicates the host and domain name being applied or [host.]domain.com
    TXT Conflict Matching ModeStringtxtConflictMatchingModeDescribes how conflicts on the TXT record are detected. Possible values are
-None, All, or Prefix. The default value is None. See below.
    TXT Conflict Matching PrefixStringtxtConflictMatchingPrefixThe prefix to detect conflicts when txtConflictMatchingMode is "Prefix". This
+A value of empty or @ indicates the host and domain name being applied or [host.]example.com
    TXT Conflict Matching ModeStringtxtConflictMatchingModeDescribes how conflicts on the TXT record are detected. Possible values are
+None, All, or Prefix. The default value is None. See below.
    TXT Conflict Matching PrefixStringtxtConflictMatchingPrefixThe prefix to detect conflicts when txtConflict-MatchingMode is "Prefix". This
 must not contain variables. See below.
    PriorityIntpriorityThe priority for an MX or SRV record. This must not contain variables.
    WeightIntweightThe weight for the SRV record. This must not contain variables.
    PortIntportThe port for the SRV record. This must not contain variables.
    ProtocolStringprotocolThe protocol for the SRV record.
    ServiceStringserviceThe symbolic name for the SRV record.
    TargetStringtargetThe target for the SRV record.
    SPF RulesStringspfRulesThese are desired rules for the SPF TXT record. These rules will be merged with other
 SPFM records into final SPF TXT record. See .
    
 
@@ -1193,59 +1228,59 @@ SPFM records into final SPF TXT record. See Template State in DNS
 
-DNS Providers may chose to maintain state inside records in DNS indicating the templates
+DNS Providers may chose to maintain state inside records in DNS indicating the templates
 writing the records. Other providers may chose to not maintain this state.
 
-A DNS Provider that maintains this state may be able to provide an improved experience for
+A DNS Provider that maintains this state may be able to provide an improved experience for
 customers, telling them the services enabled. They also may be able to have more
 advanced handling of conflicts.
 
-To make the implementation burden reasonable for DNS Providers, Domain Connect does not dictate the approach.
+To make the implementation burden reasonable for DNS Providers, Domain Connect does not dictate the approach.
 
 
 
    Disclosure of Changes and Conflicts
 
-It is left to the discretion of the DNS Provider to determine what is disclosed to the user
+It is left to the discretion of the DNS Provider to determine what is disclosed to the user
 when granting permission and/or applying changes to DNS.
 This includes disclosing the records being applied and the records
 that may be overwritten.
 
-For changes being made, one DNS Provider
+For changes being made, one DNS Provider
 may decide to simply tell the user the name of the service being enabled. Another
 may decide to display the records being set. And another
 may progressively display both.
 
-For conflict detection, one DNS Provider may simply overwrite
+For conflict detection, one DNS Provider may simply overwrite
 changed records without warning. Another may detect conflicts and warn the user of the
 records that will change. And another may implement logic to further detect, warn, and
 remove any of the existing templates that overlap with the new template once applied
 (this assumes they are a DNS Provider that maintains template state in DNS).
 
-As an example, consider applying a template that sets two records
+As an example, consider applying a template that sets two records
 (recordA and recordB) into a zone. Next consider applying a second template that
 overlaps with the first template (recordB and recordC). If the DNS maintains template state
 and removes conflicting templates, applying the second template would remove the first
 template. Application of the second template would conflict with recordB and the entire
 first template would be removed.
 
-Manual changes made by the user at the DNS Provider may also have
+Manual changes made by the user at the DNS Provider may also have
 appropriate warnings in place to prevent unwanted changes; with
 overrides being possible and removal of conflicting templates.
 
-For the synchronous flow, this happens while the user is present.
+For the synchronous flow, this happens while the user is present.
 
-For the asynchronous flow, the consent UX is similar. However, the changes are made later
+For the asynchronous flow, the consent UX is similar. However, the changes are made later
 using the API and OAuth. The DNS Provider may decide to detect conflicts and
 return these from the API without applying the change using the proper response code.
 If the force parameter is set, the changes must be applied regardless of conflicts.
 
-It is ultimately left to the DNS Provider to determine the amount of
+It is ultimately left to the DNS Provider to determine the amount of
 disclosure and/or conflict detection. The only requirement is that after
 a template is applied the new records must be applied in totality.
 
-A reasonable set of recommendations for the UX might consist of:
+A reasonable set of recommendations for the UX might consist of:
 
-
    • The consent UX should inform the customer of the service that will be
+
      • The consent UX should inform the customer of the service that will be
 enabled. If the customer want to know the specifics, the DNS
 Provider could provide a "show details" link to the user. This could
 display to them the specific records that are being set in DNS.
        • 
@@ -1258,25 +1293,25 @@ records that would be deleted or overwritten. This could be progressively disclo
 
 
        Record Types and Conflicts
 
-Conflict detection done by the DNS provider prior to template application has to take
+Conflict detection done by the DNS provider prior to template application has to take
 into consideration specifics of each DNS record type. The rules outlined below
 ensure predictable conflict resolution between DNS providers. Each rule applies to
 the records on the very same host, unless specifed otherwise.
 
-
        • CNAME record conflicts with TXT, MX, AAAA, A and existing CNAME records, and any other records of these
+
          • CNAME record conflicts with TXT, MX, AAAA, A and existing CNAME records, and any other records of these
 types conflict with an existing CNAME record. Note: CNAME records cannot be at the root of the zone.
            • 
 
          • NS records conflict with all other records. This includes of the same host, and for any record ending with the NS host. For example, an NS record of foo will conflict with any foo, www.foo, bar.foo, etc. Similarly all
 other record type conflict with NS records in the same manner.
            • 
 
          • MX, SRV records always conflict with records of the same type
            • 
 
          • A and AAAA records conflict with any other A and/or AAAA record, to avoid IPv4
 and IPv6 pointing to different services.
            • 
-
          • TXT records conflict detection is handled looking at txtConflictMatchingMode
+
          • TXT records conflict detection is handled looking at txtConflictMatchingMode
 parameter
-
            • None: This indicates that the TXT records do not conflict with any other TXT
+
              • None: This indicates that the TXT records do not conflict with any other TXT
 record. This is the default setting, if not specified.
                • 
 
              • All: This indicates that the TXT records conflict with any other TXT record
                • 
 
              • Prefix: This indicates that TXT record conflict with any other TXT containing value starting with
-txtConfictMatchingPrefix
                • 
+txtConflictMatchingPrefix
 
              
 
              • 
 
            
@@ -1284,43 +1319,43 @@ txtConfictMatchingPrefix
            • 
 
 
            Apply, Re-apply, and Multi-Instance
 
-There is an additional consideration for DNS Providers that maintain the state of an applied
+There is an additional consideration for DNS Providers that maintain the state of an applied
 template when re-applying a template.
 
-To avoid unnecessary conflict warnings to the user, under normal use when re-applying a
+To avoid unnecessary conflict warnings to the user, under normal use when re-applying a
 template such a DNS Provider should remove the previously applied template on the same host.
 
-This may not be desireable for all templates, as a limited set of templates are designed to
+This may not be desireable for all templates, as a limited set of templates are designed to
 be applied multiple times. To faciliate this the template can have the flag multiInstance
 set. This tells the DNS Provider that the template is expected to be written multiple times
 and that a re-apply must not remove previous instances.
 
-This setting only impacts DNS Providers that maintain applied template state. DNS Providers
+This setting only impacts DNS Providers that maintain applied template state. DNS Providers
 that do not maintain applied template state must rely on the normal conflict
 resolution rules, and this flag has no impact.
 
            
 
 
            Non-essential records
 
-Typically a template specifies a list of DNS records which are required for the service.
+Typically a template specifies a list of DNS records which are required for the service.
 There may be cases where some records are only required for a very short period of time,
 and removing or altering the record later (either by the end user or through application
 of another template) should not trigger conflict detection.
 
-This can be controlled by the essential property of a record in
+This can be controlled by the essential property of a record in
 the template.
 
-Again, this setting only impacts DNS Providers that maintain applied template state.
+Again, this setting only impacts DNS Providers that maintain applied template state.
 
            
 
 
            Template Scope
 
-For DNS Providers that maintain template state, an individual template is scoped to the set of records applied to a
+For DNS Providers that maintain template state, an individual template is scoped to the set of records applied to a
 fully qualified domain. This includes the root domain and the host (aka
 sub-domain) at apply time.
 
-As an example, if a template is applied on domain=example.com&host=sub1
-a later application of the template on domain=example.com&host=sub2 must be
+As an example, if a template is applied on domain=example.com=sub1
+a later application of the template on domain=example.com=sub2 must be
 treated as a distinct template. If a conflict is detected later
 with the records set into "sub2.example.com",
 only the records set with this template would be removed.
@@ -1328,35 +1363,35 @@ only the records set with this template would be removed.
 
 
            Host/Name in Template
 
-Template records contain the host name of the record to set into the zone (called name
+Template records contain the host name of the record to set into the zone (called name
 for SRV records). This value must be considered relative to the domain/host when
 the template is applied, unless followed by a trailing ".".
 
-Consider a template record of type A with a host value of "xyz". When the template is
-applied to a domain=foo.com and an empty host value, the resulting zone after the template
-is applied will contain an A record of "xyz" (or "xyz.foo.com." in bind format).
+Consider a template record of type A with a host value of "xyz". When the template is
+applied to a domain=example.com and an empty host value, the resulting zone after the template
+is applied will contain an A record of "xyz" (or "xyz.example.com." in bind format).
 
-If the same template is applied to a domain=foo.com and host=bar, the zone will contain an A
-record of "xyz.bar" (or "xyz.bar.foo.com." in bind format).
+If the same template is applied to a domain=example.com and host=bar, the zone will contain an A
+record of "xyz.bar" (or "xyz.bar.example.com." in bind format).
 
-A value of @ for host in the template is a placeholder for an empty value. In other words @
-would point to "bar.foo.com." when the same template is applied to domain=foo.com and host=bar.
+A value of @ for host in the template is a placeholder for an empty value. In other words @
+would point to "bar.example.com." when the same template is applied to domain=example.com and host=bar.
 
            
 
 
            PointsTo in Template
 
-Template records of certain types contain the pointsTo value to set in the zone. For
+Template records of certain types contain the pointsTo value to set in the zone. For
 record types such as CNAME where this can be a fully qualified domain name.
 
-A value of @ in pointsTo field in the template is a shortcut for the fully qualified domain
+A value of @ in pointsTo field in the template is a shortcut for the fully qualified domain
 name of the domain/host being applied.
 
-Consider a template record of type CNAME with a pointsTo value of "@". After a template of
-domain=foo.com and an empty host is applied, the pointsTo value (or corresponding field) in
-the resulting zone would be "foo.com". After a template of domain=foo.com
-with host=bar is applied, the points to value would be "bar.foo.com".
+Consider a template record of type CNAME with a pointsTo value of "@". After a template of
+domain=example.com and an empty host is applied, the pointsTo value (or corresponding field) in
+the resulting zone would be "example.com". After a template of domain=example.com
+with host=bar is applied, the points to value would be "bar.example.com".
 
-Any domain in a pointsTo field in a template must be considered fully qualified and not
+Any domain in a pointsTo field in a template must be considered fully qualified and not
 relative.
 
            
 
@@ -1364,81 +1399,81 @@ relative.            
 
 
            Variables and Host/Name in Template
 
-While templates do allow for variables in a host or name field values, these should be used
+While templates do allow for variables in a host or name field values, these should be used
 very sparingly.
 
-As an example, consider setting up hosting for a site. But instead of
+As an example, consider setting up hosting for a site. But instead of
 applying the template to a domain/host, the name of the host is
 placed as a variable in the template.
 
-Such a template might contain an A record of the form:
+Such a template might contain an A record of the form:
 
-
 
 
-This template could be applied on a domain like example.com with the var set
+This template could be applied on a domain like example.com with the var set
 to "sub", "sub1", "sub2", etc.
 
-Application of this template would be at the domain level for
+Application of this template would be at the domain level for
 "example.com". This causes problems for application/re-application
 of the template, conflict detection, and template removal.
 
-Since this template would be applied to the domain only, DNS providers that maintain
+Since this template would be applied to the domain only, DNS providers that maintain
 template state would remove previous instances of the template before re-application.
 This means applying this template with var=sub
 would result in the A record for sub.example.com to be set to
-the value 2.2.2.2. Later, applying the template on "example.com" with the
+the value 192.0.2.2. Later, applying the template on "example.com" with the
 var=sub2 should remove the old template before setting the new one. sub.example.com
 would be removed, and sub2.example.com would be set to the value
-2.2.2.2.
+192.0.2.2.
 
-Furthermore, determining conflicts would be impossible when the user is granting consent
+Furthermore, determining conflicts would be impossible when the user is granting consent
 for asynchronous operations (OAuth). This is because the host would be indeterminate.
 
-To solve this problem, templates are scoped to a domain and a host
+To solve this problem, templates are scoped to a domain and a host
 value. For synchronous operations, the host value is specified in the url.
 For asynchronous operations, permissions are granted for specific host values, whose value
 is later specified when applying the template.
 
-Note: There are some templates that utilize CNAME or TXT records with host values containing
+Note: There are some templates that utilize CNAME or TXT records with host values containing
 some form of user identification for validation of domain ownership, and these are often
 passed in variables.
 
-To support this use case, variables are allowed for the host name. But only in this
+To support this use case, variables are allowed for the host name. But only in this
 limited circumstance.
 
            
 
 
            Variable Values
 
-To allow for the use of the host name or domain name in templates, the
+To allow for the use of the host name or domain name in templates, the
 values of %host% and %domain% are available. A third value of %fqdn% is also available. This
 value is the result of combining the host and domain name with the necessary ".".
 
-For example, with the query string "domain=example.com&host=", %fqdn% in a template would be
+For example, with the query string "domain=example.com=", %fqdn% in a template would be
 "example.com", and with
-"domain=example.com&host=sub1", %fqdn% in a template would be "sub1.example.com".
+"domain=example.com=sub1", %fqdn% in a template would be "sub1.example.com".
 
            
 
 
            Variables and Security
 
-As discussed, with variables consideration is necessary to prevent certain styles of
+As discussed, with variables consideration is necessary to prevent certain styles of
 phishing attacks.
 
-The more static the value in the template record, the more secure the template. When static values are not possible, a carefully crafted link could hijack DNS settings.
+The more static the value in the template record, the more secure the template. When static values are not possible, a carefully crafted link could hijack DNS settings.
 
-Mitigations to this are discussed above.
+Mitigations to this are discussed above.
 
            
 
 
            Variable Examples
 
-Example template:
+Example template:
 
-
 {
     "type": "A",
     "host": "@",
-    "pointsTo": "1.1.1.1",
+    "pointsTo": "192.0.2.1",
     "ttl": 1800
 }]]]>
 
 
-Template applied with domain=foo.com and host parameter missing or empty:
+Template applied with domain=example.com and host parameter missing or empty:
 
-
+
 
 
-alternatively
+alternatively
 
-
+
 
 
-Template applied with domain=foo.com and host=bar:
+Template applied with domain=example.com and host=bar:
 
-
+
 
 
-alternatively
+alternatively
 
-
+
 
 
            
 
            
@@ -1482,137 +1517,142 @@ bar.foo.com.        1800 IN A 1.1.1.1]]>
 
 
            What is SPF?
 
-SPF stands for Sender Policy Framework specified in
-. It is a
+SPF stands for Sender Policy Framework specified in
+. It is a
 record that specifies a list of authorized host names and/or IP addresses from which mail
 can originate from for a given domain name.
 
-It manifests itself as a TXT record.  The format of which starts with v=spf1 followed by a list of "rules" of
+It manifests itself as a TXT record.  The format of which starts with v=spf1 followed by a list of "rules" of
 what to include/exclude.  If a rule passes, the mail is allowed. If it fails, it moves to the next rule.
 Typical record might appear as:
 
-
+
 
 
-This is an SPF record with two rules.  The first rule indicates that the rules for SPF record
-policy.exampleprovider.com be included in this record. The second rule is a catch all (_all). The default modifier for a rule is pass (+). Other modifiers are hard failure(-), soft failure (~) and neutral (?).
+This is an SPF record with two rules.  The first rule indicates that the rules for SPF record
+policy.exampleprovider.example be included in this record. The second rule is a catch all (_all). The default modifier for a rule is pass (+). Other modifiers are hard failure(-), soft failure (~) and neutral (?).
 
-Note: A failure in SPF doesn't mean delivery won't happen, however depending on the policies of the receiving
+Note: A failure in SPF doesn't mean delivery won't happen, however depending on the policies of the receiving
 system, messages classified with hard failure or soft failure may not be delivered or marked as spam.
 
-The use of "all" at the end  is pretty common, although some providers mark it as ~ (soft fail) or ? (neutral).
+The use of "all" at the end  is pretty common, although some providers mark it as ~ (soft fail) or ? (neutral).
 The reality is that a good SPF record is tuned based on what services are attached to a domain. Not just one
 individual service.
 
            
 
 
            Multiple Services
 
-If only one email sending service were active, the SPF record recommended by the provider is sufficient. But
+If only one email sending service were active, the SPF record recommended by the provider is sufficient. But
 mail from a domain can often come from several different services.
 
-A very typical use case might be end user mail and an email newsletter service.
+A very typical use case might be end user mail and an email newsletter service.
 Let's look at the SPF records recommended for individual services.
 
-Mailer1: v=spf1 include:spf.mailer1.com -all
-Newsletter1: v=spf1 include:_spf.newsletter.net ~all
+Mailer1: v=spf1 include:spf.mailer1.example -all
+Newsletter1: v=spf1 include:_spf.newsletter.example ~all
 
-All of these examples use the include syntax. This is fairly common. The use of all at the end is common,
+All of these examples use the include syntax. This is fairly common. The use of all at the end is common,
 although is often inconsistent with the modifier.
 
-If a customer installed Mailer1 and Newsletter1, their combined SPF record ought to be something like:
+If a customer installed Mailer1 and Newsletter1, their combined SPF record ought to be something like:
 
-
+
 
 
-We combined the two rules, and in this case picked the least restrictive all modifier.
+We combined the two rules, and in this case picked the least restrictive all modifier.
 
            
 
 
            SPF Record Merging
 
-The challenge with SPF records and Domain Connect is that an individual service might recommend an SPF record. If only one service were active, this would be accurate. But with several services together only the DNS Provider is able to determine the valid shape of a SPF TXT record.
+The challenge with SPF records and Domain Connect is that an individual service might recommend an SPF record. If only one service were active, this would be accurate. But with several services together only the DNS Provider is able to determine the valid shape of a SPF TXT record.
 
-One solution to this problem is to merge all related records. At the highest level, this means taking everything between the "v=spf1" and the "all" from each of the records and merging them together, terminating with hard-coded modifier on all at the end.  For an SPF record to fulfill it's purpose of protection against malicious email delivery, Domain Connect advises a fixed modifier "~" advising lower rating of the messages from other sources not specified in SPF. This setup offers a reasonable level of protection of mail delivery, on the other side does not reject the message in case forwarding facility is in place.
+One solution to this problem is to merge all related records. At the highest level, this means taking everything between the "v=spf1" and the "all" from each of the records and merging them together, terminating with hard-coded modifier on all at the end.  For an SPF record to fulfill it's purpose of protection against malicious email delivery, Domain Connect advises a fixed modifier "~" advising lower rating of the messages from other sources not specified in SPF. This setup offers a reasonable level of protection of mail delivery, on the other side does not reject the message in case forwarding facility is in place.
 
-
+
 
 
-The other would be to write intermediate records, and reference these locally.
+The other would be to write intermediate records, and reference these locally.
 
-
 
 
-There are advantages and disadvantages to both approaches.  SPF records have a limit of 10 DNS lookups and record length is limited to 255 characters.  So depending on the embedded records both approaches might have advantages.
+There are advantages and disadvantages to both approaches.  SPF records have a limit of 10 DNS lookups and record length is limited to 255 characters.  So depending on the embedded records both approaches might have advantages.
 
-The implementation would be left to the DNS Provider, but to facilitate this SPF records must NOT be included in templates.  Instead, we introduce a new pseudo-record type in the template called SPFM. This has the following attribute:
+The implementation would be left to the DNS Provider, but to facilitate this SPF records must NOT be included in templates.  Instead, we introduce a new pseudo-record type in the template called SPFM. This has the following attribute:
 
-
            spfRules
            Determines the desired rules, basically everything but leading "v=spf1" and trailing all rule -  see: SPF Rules
+
            spfRules
            Determines the desired rules, basically everything but leading "v=spf1" and trailing all rule -  see: SPF Rules
 
            
 
-When a template is added or removed with an SPFM record in the template, some code would need to take the aggregate value of all SPFM records in all templates applied as well as existing SPF TXT record on the host and recalculate the resulting SPF TXT record. In case several sources specify the same rule with a different policy DNS Provider SHOULD apply the least restrictive one as a result. soft failure SHOULD be preferred over hard failure, neutral SHOULD be preferred over soft failure.
+When a template is added or removed with an SPFM record in the template, some code would need to take the aggregate value of all SPFM records in all templates applied as well as existing SPF TXT record on the host and recalculate the resulting SPF TXT record. In case several sources specify the same rule with a different policy DNS Provider SHOULD apply the least restrictive one as a result. soft failure SHOULD be preferred over hard failure, neutral SHOULD be preferred over soft failure.
 
-DNS Provider SHOULD also allow the end user to modify the SPF record after merging.
+DNS Provider SHOULD also allow the end user to modify the SPF record after merging.
 
-Due to merging step in between, the resulting SPF TXT records are considered non-essential (see: ). That means the user may decide to override the final calculated value or remove the whole SPF record. This action must not lead to removal of any related templates in conflict detection and template integrity routines if implemented by the DNS provider.
+Due to merging step in between, the resulting SPF TXT records are considered non-essential (see: ). That means the user may decide to override the final calculated value or remove the whole SPF record. This action must not lead to removal of any related templates in conflict detection and template integrity routines if implemented by the DNS provider.
 
-If the existing TXT record makes the merging operation not possible, the DNS provider must handle this situation the same way as a conflict and either let the end-user resolve it in the UX (both in Synchronous and Asynchronous flow) or return the conflict as an error in the Asynchronous flow unless the force=true parameter is used, effectively removing the existing record.
+If the existing TXT record makes the merging operation not possible, the DNS provider must handle this situation the same way as a conflict and either let the end-user resolve it in the UX (both in Synchronous and Asynchronous flow) or return the conflict as an error in the Asynchronous flow unless the force=true parameter is used, effectively removing the existing record.
 
-Service providers should avoid exact match checking content of TXT SPF record, as it might be strongly influenced by the DNS Provider merging strategy and user actions.
+Service providers should avoid exact match checking content of TXT SPF record, as it might be strongly influenced by the DNS Provider merging strategy and user actions.
 
-See .
+See .
 
            
 
 
            Alternatives
 
-Some DNS Providers may decide not to support the SPFM record. The following alternative solution should allow general interoperability of the templates for those providers: onboard the templates with SPFM record in variable-compatible form using a regular TXT record with content "v=spf1 %spfRules% ~all", using property essential=OnApply set to avoid removal of the whole template by a conflict.
+Some DNS Providers may decide not to support the SPFM record. The following alternative solution should allow general interoperability of the templates for those providers: onboard the templates with SPFM record in variable-compatible form using a regular TXT record with content "v=spf1 %spfRules% ~all", using property essential=OnApply set to avoid removal of the whole template by a conflict.
 
            
 
        
 
 
        Public Template Repository
 
-The Public Template Repository is an open accessible location where Service Providers
+
        General information
+
+The Public Template Repository is an open accessible location where Service Providers
 MAY publish their Service Templates in the format specified in this specification.
 DNS Providers MAY support all of the published templates, just a subset or none of them according
 to own onboarding policies (see also: ).
 
-The template format is intended largely for documentation and communication between the DNS Providers and
+The template format is intended largely for documentation and communication between the DNS Providers and
 Service Providers, and there are no codified endpoints for creation or modification of these objects.
 Instead, Domain Connect references a template by ID.
 
-As such, DNS Providers may or may not use templates in this format in
+As such, DNS Providers may or may not use templates in this format in
 their internal implementations. By defining a standard template format,
 it is believed it will make it easier for Service Providers to share
 their configuration across DNS Providers.
+
        
 
 
        Repository Location
 
-The  repository of the templates is maintained under
+The  repository of the templates is maintained under
 .
 
        
 
 
        File naming requirements
 
-The file names in this repository MUST be all lower case, including the providerId
+The file names in this repository MUST be all lower case, including the providerId
 and serviceId. As a result, while the providerId and serviceId can be mixed case,
 all providerIds and serviceIds in this repository must be unique when lower case.
 
-Templates MUST be named according the following pattern: providerId.serviceId.json
+Templates MUST be named according the following pattern: providerId.serviceId.json
 
-
+Template file name: example.com.websitebuilder.json]]>
 
 
        
 
 
        Template Integrity
 
-Implementers are responsible for data integrity and should use the
+Implementers are responsible for data integrity and should use the
 record type field to validate that variable input meets the criteria for
 each different data type.
 
-Hard-coded host names are the responsibility of the DNS Provider to
+Hard-coded host names are the responsibility of the DNS Provider to
 protect. That is, DNS Providers are responsible for ensuring that host
 names do not interfere with known values (such as m. or www. or mail.)
 or internal names that provide critical functionality that is outside
@@ -1624,17 +1664,17 @@ the scope of this specification.
 
 
        Onboarding
 
-This specification is an open standard that describes the protocol, messages and formats
+This specification is an open standard that describes the protocol, messages and formats
 used to enable Domain Connect between a Service Provider and a DNS
 Provider.
 
-Any Service Provider is free to define and publish a template. However, the terms
+Any Service Provider is free to define and publish a template. However, the terms
 and conditions for a DNS Provider onboarding a Service Provider
 template is beyond the scope of this document. A DNS Provider can
 be selective in what templates they support, can require a contractual
 relationship, or even charge a fee for onboarding.
 
-One way a Service Provider can be selective in which DNS Providers they accept is to
+One way a Service Provider can be selective in which DNS Providers they accept is to
 implement a whitelist of providerIds. A Service Provider who chooses to whitelist must
 use providerId to distinguish between unique DNS Providers. The DNS providerId is typically
 a domain name.
@@ -1642,37 +1682,37 @@ a domain name.
 
 
        Case Sensitivity
 
-All values are case sensitive. This includes variable names, values, parameters and objects
+All values are case sensitive. This includes variable names, values, parameters and objects
 returned.
 
-One exception is the domain/host name. This is because a fully qualified domain name is case insensitive.
+One exception is the domain/host name. This is because a fully qualified domain name is case insensitive.
 
-The values for providerId/serviceId in the template and passed through URIs in the path or query string are case sensitive. Different rules apply to the file naming in the Public Template Repository.
+The values for providerId/serviceId in the template and passed through URIs in the path or query string are case sensitive. Different rules apply to the file naming in the Public Template Repository.
 
        
 
        
     
        Extensions/Exclusions
 
-Additional record types and/or extensions to records in the template can
-be implemented on a per DNS Provider basis. However, care should be
-taken when defining extensions so as to not conflict with other
+
        General information
+
+Additional record types and/or extensions to records in the template can be implemented on a per DNS Provider basis. However, care should be taken when defining extensions so as to not conflict with other
 protocols and standards. Certain record names are reserved for use in
-DNS for protocols like DNSSEC (DNSKEY, RRSIG) at the registry level.
+DNS for protocols like DNSSEC (DNSKEY, RRSIG)  at the registry level.
 
-Defining these OPTIONAL extensions in an open manner as part of this
-specification is done to provide consistency. The following are the initial
-OPTIONAL extensions a DNS Provider/Service Provider may support.
+Defining these OPTIONAL extensions in an open manner as part of this
+specification is done to provide consistency. The following are the initial OPTIONAL extensions a DNS Provider/Service Provider may support.
+
        
 
 
        APEXCNAME
 
-Some Service Providers desire the behavior of a CNAME record, but in the
+Some Service Providers desire the behavior of a CNAME record, but in the
 apex record. This would allow for an A Record at the root of the domain
 but dynamically determined at runtime.
 
-The recommended record type for DNS Providers that wish to support this
+The recommended record type for DNS Providers that wish to support this
 is an APEXCNAME record. Additional fields included with this record
 would include pointsTo and TTL.
 
-Defining a standard for such functionality in DNS is beyond the scope of
+Defining a standard for such functionality in DNS is beyond the scope of
 this specification. But for DNS Providers that support this
 functionality, using the same record type name across DNS Providers
 allows template reuse.
@@ -1680,76 +1720,70 @@ allows template reuse.
 
 
        Redirection
 
-Some Service Providers desire a redirection service associated with the
+Some Service Providers desire a redirection service associated with the
 A Record. A typical example is a service that requires a redirect of the
 domain (e.g. example.com) to the www variant (www.example.com). The www
 would often contain a CNAME.
 
-Since implementation of a redirection service is typically simple, it is
+Since implementation of a redirection service is typically simple, it is
 recommended that service providers implement redirection on their own.
 But for DNS Providers that have a redirection service, supporting simple
 templates with this functionality may be desired.
 
-While technically not a "record" in DNS, when supporting this OPTIONAL
+While technically not a "record" in DNS, when supporting this OPTIONAL
 functionality it is recommended that this should be implemented using two new
 record types.
 
-REDIR301 and REDIR302 would implement 301 and 302 redirects
+REDIR301 and REDIR302 would implement 301 and 302 redirects
 respectively. Associated with this record would be a single field called
 the "target", containing the target url of the redirect.
 
        
 
 
        Nameservers
 
-Several service providers have asked for functionality supporting an
+Several service providers have asked for functionality supporting an
 update to the nameserver records at the registry associated with the
 domain.
 
-When implementing this, two records should be provided. NS1 and NS2,
+When implementing this, two records should be provided. NS1 and NS2,
 each containing a pointsTo argument.
 
-It will be noted that a nameserver update would require that the DNS
+It will be noted that a nameserver update would require that the DNS
 Provider is the registrar. This is not always the case.
 
-This functionality is again deemed as OPTIONAL and up to the DNS
+This functionality is again deemed as OPTIONAL and up to the DNS
 Provider to determine if they will support this.
 
        
 
 
        DS (DNSSEC)
 
-Requests have been made to allow for updates to the DS record for
+Requests have been made to allow for updates to the DS record for
 DNSSEC. This record is required at the registry to enable DNSSEC, but
 can only be written by the registrar.
 
-For DNS Providers that support this record, the record type should be
+For DNS Providers that support this record, the record type should be
 DS. Values will be keyTag, algorithm, digestType, and digest.
 
-Again it should be noted that a DS update would require that the DNS
-Provider is the registrar, and is again deemed as OPTIONAL and up to the
+Again it should be noted that a DS update would require that the DNS
+Provider is the registrar, and is again deemed as optional and up to the
 DNS Provider to determine if they will support.
 
        
 
        
     
        IANA Considerations
 
-TODO
-
        
-    
        Acknowledgments
-
-The authors wish to thank the following persons for their feedback and suggestions:
-
-
        • Chris Ambler of GoDaddy Inc.
          • 
-
        • Jody Kolker of GoDaddy Inc.
          • 
-
        
+None.
 
        
     
        Change History
 
 
        Change from 03 to 04
 
+
        
 
        
 
 
        Change from 02 to 03
 
-
        
 
 
        Change from 01 to 02
 
-
        
 
        
 
 
        Change from 00 to 01
 
-
        
+
        
 
        
 
        
   
   
     
       Normative References
-      
-        
-          Key words for use in RFCs to Indicate Requirement Levels
-          
-          
-              In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
-  
-        
-        
-        
-        RFC 2119
-        
-        
-      
+      IETF  Key words for use in RFCs to Indicate Requirement Levels   StandardsTrackDocuments   In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.     
+      IETF  Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1   spoofingspfanti-forgeryauthentication   Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.  This document obsoletes RFC 4408.    
+      IETF  The OAuth 2.0 Authorization Framework   ClientResource OwnerAuthorization ServerResource ServerToken EndpointAuthorization EndpointAuthorization RequestAuthorization GrantProtected ResourceAccess TokenRefresh TokenAuthorization CodeImplicit GrantClient IdentifierAccess Token ScopeDelegation   The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]    
     
     
       Informative References
-      
-        
-          Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
-          
-          
-              RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
-  
-        
-        
-        
-        RFC 8174
-        
-        
-      
-      
-        
-          Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
-          
-          
-              Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.
-    This document obsoletes RFC 4408.
-  
-        
-        
-        
-        RFC 7208
-        
-        
-      
+      IETF  Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words     RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.     
+      IETF  DNS Security Extensions (DNSSEC)   DNSSECDNS Security ExtensionsDNS   This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.     
     
     
        Examples
 
 
        Example Template
 
-
@@ -1873,17 +1868,17 @@ clarification.]]>
 section of the template would have a single record of type "A" and could
 have a value of:
 
-
 
 
-This would have no variable substitution and the application of this
+This would have no variable substitution and the application of this
 template to a domain would simply set the host name "www" to the IP
-address "192.168.1.1"
+address "192.0.2.1"
 
        
 
 
        Example Records: Single variable host record for A
@@ -1892,10 +1887,10 @@ address "192.168.1.1"
 variable, the template would have a single record of type "A" and could
 have a value of:
 
-
 
@@ -1905,8 +1900,8 @@ have a value of:
 
 
 
-would cause the application of this template to a domain to set the host
-name for the apex A record to the IP address "192.168.1.2" with a TTL of
+would cause the application of this template to a domain to set the host
+name for the apex A record to the IP address "198.51.100.2" with a TTL of
 600
 
        
 
@@ -1914,58 +1909,59 @@ name for the apex A record to the IP address "192.168.1.2" with a TTL of
 
 Consider a DNS Zone before a template application:
 
-
+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 3600 IN TXT "v=spf1 a include:spf.example.org ~all"
+www 3600 IN CNAME other.host.example.]]>
 
 
 Now application of the following template:
 
-
 
 
 The following DNS Zone should be generated after the template is applied:
 
-
+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050920 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.
+@ 1800 IN A 203.0.113.2
+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 1800 IN TXT "v=spf1 a include:spf.example.org include:spf.hoster.ex
+ample ~all"
+www 1800 IN A 203.0.113.2]]>
 
 
        
 
@@ -1973,75 +1969,77 @@ www 1800 IN A 2.2.2.2]]>
 
 Consider a DNS Zone before a template application:
 
-
+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.]]>
 
 
 Now application of the following template of Mail service:
 
-
 
 
 Expected result in the DNS Zone
 
-
+@ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+1800 1209600 3600
+@ 3600 IN NS ns11.example.net.
+@ 3600 IN NS ns12.example.net.
+@ 3600 IN MX 10 mx1.example.net.
+@ 3600 IN MX 10 mx2.example.net.
+@ 3600 IN TXT "v=spf1 a include:spf.example.net ~all"]]>
 
 
 In the next step application of the following template of Newsletter
 service:
 
-
 
 
 Expected result in the DNS Zone
 
-
+
 
 
        
 
        
diff --git a/draft-domain-connect-04.txt b/draft-kowalik-regext-domainconnect-00.txt
similarity index 62%
rename from draft-domain-connect-04.txt
rename to draft-kowalik-regext-domainconnect-00.txt
index 0702676..0c08d75 100644
--- a/draft-domain-connect-04.txt
+++ b/draft-kowalik-regext-domainconnect-00.txt
@@ -2,23 +2,27 @@
 
 
 
-Registration Protocols Extensions                              R. Carney
-Internet-Draft                                              GoDaddy Inc.
-Intended status: Informational                                  A. Blinn
-Expires: 29 October 2022                                                
-                                                              P. Kowalik
-                                                                IONOS SE
-                                                           27 April 2022
+Registration Protocols Extensions                             P. Kowalik
+Internet-Draft                                                  DENIC eG
+Intended status: Standards Track                                A. Blinn
+Expires: 23 January 2025                                                
+                                                               J. Kolker
+                                                            GoDaddy Inc.
+                                                               S. Kerola
+                                                        Cloudflare, Inc.
+                                                            22 July 2024
 
 
- Domain Connect API - Communications between DNS Provider and Services
-                  draft-carney-regext-domainconnect-04
+  Domain Connect Protocol - DNS provisioning between Services and DNS
+                               Providers
+                 draft-kowalik-regext-domainconnect-00
 
 Abstract
 
-   This document provides information related to the Domain Connect API
-   that was built to support communications between DNS Providers and
-   Service Providers (hosting, social, email, hardware, etc.).
+   This document provides specification of the Domain Connect Protocol
+   that was built to support DNS configuration provisioning between
+   Service Providers (hosting, social, email, hardware, etc.) and DNS
+   Providers.
 
 Status of This Memo
 
@@ -35,115 +39,138 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 29 October 2022.
+   This Internet-Draft will expire on 23 January 2025.
 
 Copyright Notice
 
-   Copyright (c) 2022 IETF Trust and the persons identified as the
+   Copyright (c) 2024 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents (https://trustee.ietf.org/
    license-info) in effect on the date of publication of this document.
    Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
 
 
 
+Kowalik, et al.          Expires 23 January 2025                [Page 1]
+
+Internet-Draft               Domain Connect                    July 2024
+
 
+   and restrictions with respect to this document.  Code Components
+   extracted from this document must include Revised BSD License text as
+   described in Section 4.e of the Trust Legal Provisions and are
+   provided without warranty as described in the Revised BSD License.
 
+Table of Contents
 
-Carney, et al.           Expires 29 October 2022                [Page 1]
+   1.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Protocol design . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.1.  Templates . . . . . . . . . . . . . . . . . . . . . . . .   5
+   5.  End User Flows  . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.1.  General information . . . . . . . . . . . . . . . . . . .   6
+     5.2.  The Synchronous Flow  . . . . . . . . . . . . . . . . . .   6
+     5.3.  The Asynchronous Flow . . . . . . . . . . . . . . . . . .   9
+   6.  DNS Provider Discovery  . . . . . . . . . . . . . . . . . . .   9
+   7.  Applying Domain Connect . . . . . . . . . . . . . . . . . . .  13
+     7.1.  Endpoints . . . . . . . . . . . . . . . . . . . . . . . .  14
+     7.2.  Synchronous Flow  . . . . . . . . . . . . . . . . . . . .  14
+       7.2.1.  Query Supported Template  . . . . . . . . . . . . . .  14
+       7.2.2.  Apply Template  . . . . . . . . . . . . . . . . . . .  15
+       7.2.3.  Security Considerations . . . . . . . . . . . . . . .  19
+       7.2.4.  Shared Templates  . . . . . . . . . . . . . . . . . .  21
+       7.2.5.  Verification of Changes . . . . . . . . . . . . . . .  22
+     7.3.  Asynchronous Flow: OAuth  . . . . . . . . . . . . . . . .  22
+       7.3.1.  General information . . . . . . . . . . . . . . . . .  23
+       7.3.2.  OAuth Flow: Setup . . . . . . . . . . . . . . . . . .  23
+       7.3.3.  OAuth Flow: Getting an Authorization Code . . . . . .  23
+       7.3.4.  OAuth Flow: Requesting an Access Token  . . . . . . .  27
+       7.3.5.  OAuth Flow: Making Requests with Access Tokens  . . .  30
+       7.3.6.  OAuth Flow: Apply Template to Domain. . . . . . . . .  31
+       7.3.7.  OAuth Flow: Revert Template . . . . . . . . . . . . .  35
+       7.3.8.  OAuth Flow: Revoking access . . . . . . . . . . . . .  36
+   8.  Domain Connect Objects and Templates  . . . . . . . . . . . .  36
+     8.1.  Template Versioning . . . . . . . . . . . . . . . . . . .  37
+     8.2.  Template Definition . . . . . . . . . . . . . . . . . . .  37
+     8.3.  Template Record . . . . . . . . . . . . . . . . . . . . .  41
+   9.  Template Considerations . . . . . . . . . . . . . . . . . . .  46
+     9.1.  Template State in DNS . . . . . . . . . . . . . . . . . .  46
+     9.2.  Disclosure of Changes and Conflicts . . . . . . . . . . .  46
+     9.3.  Record Types and Conflicts  . . . . . . . . . . . . . . .  48
+     9.4.  Apply, Re-apply, and Multi-Instance . . . . . . . . . . .  48
+     9.5.  Non-essential records . . . . . . . . . . . . . . . . . .  49
+     9.6.  Template Scope  . . . . . . . . . . . . . . . . . . . . .  49
+     9.7.  Host/Name in Template . . . . . . . . . . . . . . . . . .  49
+     9.8.  PointsTo in Template  . . . . . . . . . . . . . . . . . .  50
+     9.9.  Variables . . . . . . . . . . . . . . . . . . . . . . . .  50
+       9.9.1.  Variables and Host/Name in Template . . . . . . . . .  50
+
+
+
+Kowalik, et al.          Expires 23 January 2025                [Page 2]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
+
+
+       9.9.2.  Variable Values . . . . . . . . . . . . . . . . . . .  51
+       9.9.3.  Variables and Security  . . . . . . . . . . . . . . .  52
+       9.9.4.  Variable Examples . . . . . . . . . . . . . . . . . .  52
+     9.10. SPF TXT Record  . . . . . . . . . . . . . . . . . . . . .  53
+       9.10.1.  What is SPF? . . . . . . . . . . . . . . . . . . . .  53
+       9.10.2.  Multiple Services  . . . . . . . . . . . . . . . . .  53
+       9.10.3.  SPF Record Merging . . . . . . . . . . . . . . . . .  54
+       9.10.4.  Alternatives . . . . . . . . . . . . . . . . . . . .  56
+     9.11. Public Template Repository  . . . . . . . . . . . . . . .  56
+       9.11.1.  General information  . . . . . . . . . . . . . . . .  56
+       9.11.2.  Repository Location  . . . . . . . . . . . . . . . .  56
+       9.11.3.  File naming requirements . . . . . . . . . . . . . .  56
+       9.11.4.  Template Integrity . . . . . . . . . . . . . . . . .  57
+   10. General considerations  . . . . . . . . . . . . . . . . . . .  57
+     10.1.  Onboarding . . . . . . . . . . . . . . . . . . . . . . .  57
+     10.2.  Case Sensitivity . . . . . . . . . . . . . . . . . . . .  57
+   11. Extensions/Exclusions . . . . . . . . . . . . . . . . . . . .  58
+     11.1.  General information  . . . . . . . . . . . . . . . . . .  58
+     11.2.  APEXCNAME  . . . . . . . . . . . . . . . . . . . . . . .  58
+     11.3.  Redirection  . . . . . . . . . . . . . . . . . . . . . .  58
+     11.4.  Nameservers  . . . . . . . . . . . . . . . . . . . . . .  59
+     11.5.  DS (DNSSEC)  . . . . . . . . . . . . . . . . . . . . . .  59
+   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  59
+   13. Change History  . . . . . . . . . . . . . . . . . . . . . . .  59
+     13.1.  Change from 03 to 04 . . . . . . . . . . . . . . . . . .  59
+     13.2.  Change from 02 to 03 . . . . . . . . . . . . . . . . . .  60
+     13.3.  Change from 01 to 02 . . . . . . . . . . . . . . . . . .  60
+     13.4.  Change from 00 to 01 . . . . . . . . . . . . . . . . . .  60
+   14. Normative References  . . . . . . . . . . . . . . . . . . . .  60
+   15. Informative References  . . . . . . . . . . . . . . . . . . .  60
+   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  61
+     A.1.  Example Template  . . . . . . . . . . . . . . . . . . . .  61
+     A.2.  Example Records: Single static host record  . . . . . . .  62
+     A.3.  Example Records: Single variable host record for A  . . .  62
+     A.4.  Example: DNS Zone merging . . . . . . . . . . . . . . . .  62
+     A.5.  Example: SPF Record Merging . . . . . . . . . . . . . . .  64
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  65
+
+1.  Acknowledgements
+
+   The authors wish to thank the following persons for their feedback
+   and suggestions as well as for the previous work on the standard:
 
+   *  Roger Carney of GoDaddy Inc.
+
+   *  Chris Ambler of GoDaddy Inc.
 
-Table of Contents
 
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.  Protocol design . . . . . . . . . . . . . . . . . . . . . . .   5
-     2.1.  Templates . . . . . . . . . . . . . . . . . . . . . . . .   5
-     2.2.  End User Flows  . . . . . . . . . . . . . . . . . . . . .   5
-       2.2.1.  The Synchronous Flow  . . . . . . . . . . . . . . . .   6
-       2.2.2.  The Asynchronous Flow . . . . . . . . . . . . . . . .   9
-   3.  DNS Provider Discovery  . . . . . . . . . . . . . . . . . . .   9
-   4.  Applying Domain Connect . . . . . . . . . . . . . . . . . . .  13
-     4.1.  Endpoints . . . . . . . . . . . . . . . . . . . . . . . .  13
-     4.2.  Synchronous Flow  . . . . . . . . . . . . . . . . . . . .  14
-       4.2.1.  Query Supported Template  . . . . . . . . . . . . . .  14
-       4.2.2.  Apply Template  . . . . . . . . . . . . . . . . . . .  15
-       4.2.3.  Security Considerations . . . . . . . . . . . . . . .  18
-       4.2.4.  Shared Templates  . . . . . . . . . . . . . . . . . .  21
-       4.2.5.  Verification of Changes . . . . . . . . . . . . . . .  21
-     4.3.  Asynchronous Flow: OAuth  . . . . . . . . . . . . . . . .  22
-       4.3.1.  OAuth Flow: Setup . . . . . . . . . . . . . . . . . .  22
-       4.3.2.  OAuth Flow: Getting an Authorization Code . . . . . .  22
-       4.3.3.  oAuth Flow: Requesting an Access Token  . . . . . . .  26
-       4.3.4.  OAuth Flow: Making Requests with Access Tokens  . . .  29
-       4.3.5.  OAuth Flow: Apply Template to Domain. . . . . . . . .  30
-       4.3.6.  OAuth Flow: Revert Template . . . . . . . . . . . . .  34
-       4.3.7.  OAuth Flow: Revoking access . . . . . . . . . . . . .  35
-   5.  Domain Connect Objects and Templates  . . . . . . . . . . . .  36
-     5.1.  Template Versioning . . . . . . . . . . . . . . . . . . .  36
-     5.2.  Template Definition . . . . . . . . . . . . . . . . . . .  36
-     5.3.  Template Record . . . . . . . . . . . . . . . . . . . . .  39
-   6.  Template Considerations . . . . . . . . . . . . . . . . . . .  43
-     6.1.  Template State in DNS . . . . . . . . . . . . . . . . . .  43
-     6.2.  Disclosure of Changes and Conflicts . . . . . . . . . . .  44
-     6.3.  Record Types and Conflicts  . . . . . . . . . . . . . . .  45
-     6.4.  Apply, Re-apply, and Multi-Instance . . . . . . . . . . .  46
-     6.5.  Non-essential records . . . . . . . . . . . . . . . . . .  46
-     6.6.  Template Scope  . . . . . . . . . . . . . . . . . . . . .  46
-     6.7.  Host/Name in Template . . . . . . . . . . . . . . . . . .  47
-     6.8.  PointsTo in Template  . . . . . . . . . . . . . . . . . .  47
-     6.9.  Variables . . . . . . . . . . . . . . . . . . . . . . . .  48
-       6.9.1.  Variables and Host/Name in Template . . . . . . . . .  48
-       6.9.2.  Variable Values . . . . . . . . . . . . . . . . . . .  49
-       6.9.3.  Variables and Security  . . . . . . . . . . . . . . .  49
-       6.9.4.  Variable Examples . . . . . . . . . . . . . . . . . .  49
-     6.10. SPF TXT Record  . . . . . . . . . . . . . . . . . . . . .  50
-       6.10.1.  What is SPF? . . . . . . . . . . . . . . . . . . . .  50
-       6.10.2.  Multiple Services  . . . . . . . . . . . . . . . . .  51
-       6.10.3.  SPF Record Merging . . . . . . . . . . . . . . . . .  51
-       6.10.4.  Alternatives . . . . . . . . . . . . . . . . . . . .  53
-
-
-
-Carney, et al.           Expires 29 October 2022                [Page 2]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-     6.11. Public Template Repository  . . . . . . . . . . . . . . .  53
-       6.11.1.  Repository Location  . . . . . . . . . . . . . . . .  53
-       6.11.2.  File naming requirements . . . . . . . . . . . . . .  53
-       6.11.3.  Template Integrity . . . . . . . . . . . . . . . . .  54
-   7.  General considerations  . . . . . . . . . . . . . . . . . . .  54
-     7.1.  Onboarding  . . . . . . . . . . . . . . . . . . . . . . .  54
-     7.2.  Case Sensitivity  . . . . . . . . . . . . . . . . . . . .  54
-   8.  Extensions/Exclusions . . . . . . . . . . . . . . . . . . . .  55
-     8.1.  APEXCNAME . . . . . . . . . . . . . . . . . . . . . . . .  55
-     8.2.  Redirection . . . . . . . . . . . . . . . . . . . . . . .  55
-     8.3.  Nameservers . . . . . . . . . . . . . . . . . . . . . . .  56
-     8.4.  DS (DNSSEC) . . . . . . . . . . . . . . . . . . . . . . .  56
-   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  56
-   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  56
-   11. Change History  . . . . . . . . . . . . . . . . . . . . . . .  57
-     11.1.  Change from 03 to 04 . . . . . . . . . . . . . . . . . .  57
-     11.2.  Change from 02 to 03 . . . . . . . . . . . . . . . . . .  57
-     11.3.  Change from 01 to 02 . . . . . . . . . . . . . . . . . .  57
-     11.4.  Change from 00 to 01 . . . . . . . . . . . . . . . . . .  57
-   12. Normative References  . . . . . . . . . . . . . . . . . . . .  57
-   13. Informative References  . . . . . . . . . . . . . . . . . . .  57
-   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  58
-     A.1.  Example Template  . . . . . . . . . . . . . . . . . . . .  58
-     A.2.  Example Records: Single static host record  . . . . . . .  59
-     A.3.  Example Records: Single variable host record for A  . . .  59
-     A.4.  Example: DNS Zone merging . . . . . . . . . . . . . . . .  59
-     A.5.  Example: SPF Record Merging . . . . . . . . . . . . . . .  61
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  62
-
-1.  Introduction
+
+
+
+Kowalik, et al.          Expires 23 January 2025                [Page 3]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+2.  Introduction
 
    Configuring a service at a Service Provider to work with a domain has
    historically been a complex task that is difficult for users.
@@ -160,16 +187,6 @@ Internet-Draft               Domain Connect                   April 2022
    might include help text, screen shots, or even links to the
    appropriate tools.
 
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022                [Page 3]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    Discovery of the DNS Provider in this manner is unreliable, and
    providing instructions to users would present a number of
    technologies (DNS record types, TTLs, Hostnames, etc.) and processes
@@ -187,12 +204,12 @@ Internet-Draft               Domain Connect                   April 2022
    of DNS settings will be done through the application of templates
    instead of direct manipulation of individual DNS records.
 
-1.1.  Terminology
+3.  Terminology
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY",
-   and "OPTIONAL" in this document are to be interpreted as described in
-   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
    capitals, as shown here.
 
    Service Providers  refers to entities that provide products and
@@ -202,9 +219,16 @@ Internet-Draft               Domain Connect                   April 2022
       manufacturers with DNS-enabled devices like home routers or
       automation controls (such as Linksys, Nest, and Philips).
 
+
+
+Kowalik, et al.          Expires 23 January 2025                [Page 4]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    DNS Providers  refers to entities that provide DNS services such as
       registrars (such as GoDaddy or 1and1) or standalone DNS services
-      (like CloudFlare).
+      (like Cloudflare).
 
    Registrar  refers to entities that register domain names with
       registries.  It is noted that the DNS Provider and Registrar can
@@ -217,14 +241,7 @@ Internet-Draft               Domain Connect                   April 2022
       service.
 
    Public Template Repository  refers to a public repository of
-      Templates in a standarised format (read more: Section 6.11).
-
-
-
-Carney, et al.           Expires 29 October 2022                [Page 4]
-
-Internet-Draft               Domain Connect                   April 2022
-
+      Templates in a standarised format (read more: Section 9.11).
 
    Root Domain  refers to a registered domain (e.g. example.com or
       example.co.uk), or to a delegated zone in DNS.
@@ -232,9 +249,9 @@ Internet-Draft               Domain Connect                   April 2022
    Sub Domain  refers to a sub-domain of a root domain (e.g.
       sub.example.com or sub.example.co.uk).
 
-2.  Protocol design
+4.  Protocol design
 
-2.1.  Templates
+4.1.  Templates
 
    Templates are core to Domain Connect, as they fully describe a
    service owned by a Service Provider and contain all of the
@@ -254,34 +271,30 @@ Internet-Draft               Domain Connect                   April 2022
 
    The template is defined by the Service Provider and manually
    onboarded with the DNS Provider, according to a template definition
-   published in the Public Repository (Section 6.11) or agreed out-of-
+   published in the Public Repository (Section 9.11) or agreed out-of-
    band between the Service Provider and the DNS Provider.
 
+
+
+
+Kowalik, et al.          Expires 23 January 2025                [Page 5]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    By basing the protocol on templates instead of DNS Records, several
    advantages are achieved.  The DNS Provider has very explicit
    knowledge and control of the settings being changed to enable a
    service.  And the system is more secure as templates are controlled
    and contained.
 
-2.2.  End User Flows
+5.  End User Flows
+
+5.1.  General information
 
    To attach a domain name to a service provided by a Service Provider,
    the customer would first enter their domain name.
 
-
-
-
-
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022                [Page 5]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    Instead of relying on examination of the nameservers and mapping
    these to DNS Providers, DNS Provider discovery is handled through
    simple records in DNS and an API.  The Service Provider queries for a
@@ -292,18 +305,18 @@ Internet-Draft               Domain Connect                   April 2022
 
    To apply the changes to DNS, there are two use cases.  The first is a
    synchronous web flow, and the second is an asynchronous flow using
-   oAuth and an API.
+   OAuth and an API.
 
    It is noted that a DNS Provider may choose to only implement one of
    the flows.  As a matter of practice many Service Providers are based
    on the synchronous flow, with only a handful of them based on the
-   asynchronous oAuth flow.  So many DNS providers may opt to only
+   asynchronous OAuth flow.  So many DNS providers may opt to only
    implement the synchronous flow.
 
    It is also be noted that individual services may work with the
    synchronous flow only, the asynchronous flow only, or with both.
 
-2.2.1.  The Synchronous Flow
+5.2.  The Synchronous Flow
 
    This flow is tailored for the Service Provider that requires a one
    time synchronous change to DNS.
@@ -311,8 +324,22 @@ Internet-Draft               Domain Connect                   April 2022
    The user first enters their domain name at the Service Provider
    website.
 
+
+
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025                [Page 6]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    +-----------------------------------------------+
-   | http://acmewebsiteserviceprovider.com         |
+   | https://acmewebsiteserviceprovider.example    |
    +-----------------------------------------------+
    | ACME Web Site Service Provider                |
    |                                               |
@@ -331,19 +358,12 @@ Internet-Draft               Domain Connect                   April 2022
 
                   Figure 1: Service Provider domain input
 
-
-
-Carney, et al.           Expires 29 October 2022                [Page 6]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    After the Service Provider determines the DNS Provider using
    discovery, the Service Provider should display a link to the user
    indicating that they can "Connect their Domain" to the service.
 
    +-----------------------------------------------+
-   | http://acmewebsiteserviceprovider.com         |
+   | https://acmewebsiteserviceprovider.example    |
    +-----------------------------------------------+
    | ACME Web Site Service Provider                |
    |                                               |
@@ -367,42 +387,25 @@ Internet-Draft               Domain Connect                   April 2022
    provider/template being enabled, and any additional parameters
    (variables) needed to apply the template and configure the service.
 
-   Once at the DNS Provider site, the user is asked to authenticate if
-   necessary.
-
-
-
-
-
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022                [Page 7]
+Kowalik, et al.          Expires 23 January 2025                [Page 7]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+   Once at the DNS Provider site, the user is asked to authenticate if
+   necessary.
+
    +-----------------------------------------------+
-   | http://virtucondomains.com                    |
+   | https://virtucondomains.example               |
    +-----------------------------------------------+
    | Virtucon Domains                              |
    |                                               |
    | Please sign in to Virtucon domains            |
    |                                               |
    |                 +-------------------------+   |
-   | Login           |user@xyz.com             |   |
+   | Login           |user@xyz.example         |   |
    |                 +-------------------------+   |
    |                                               |
    |                 +-------------------------+   |
@@ -425,7 +428,7 @@ Internet-Draft               Domain Connect                   April 2022
    disabled by applying this change to DNS.
 
    +-----------------------------------------------+
-   | http://virtucondomains.com                    |
+   | https://virtucondomains.example               |
    +-----------------------------------------------+
    | Virtucon Domains                              |
    |                                               |
@@ -440,16 +443,16 @@ Internet-Draft               Domain Connect                   April 2022
    |                                               |
    +-----------------------------------------------+
 
-     Figure 4: User authorization at the DNS provider of the DNS setup
-                                  for ACME
-
 
 
-Carney, et al.           Expires 29 October 2022                [Page 8]
+Kowalik, et al.          Expires 23 January 2025                [Page 8]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+     Figure 4: User authorization at the DNS provider of the DNS setup
+                                  for ACME
+
    Assuming the user grants this consent, the DNS changes are be
    applied.
 
@@ -458,9 +461,9 @@ Internet-Draft               Domain Connect                   April 2022
    must be navigated back to the Service Provider after the changes are
    applied.
 
-2.2.2.  The Asynchronous Flow
+5.3.  The Asynchronous Flow
 
-   The asynchronous oAuth flow is tailored for the Service Provider that
+   The asynchronous OAuth flow is tailored for the Service Provider that
    wishes to make changes to DNS asynchronously with respect to the user
    interaction, or wishes to make multiple or additional changes to DNS
    over time.
@@ -481,13 +484,13 @@ Internet-Draft               Domain Connect                   April 2022
    domain (and specific subdomains) DNS under control of a specific user
    at the DNS Provider.
 
-   The Service Provider would later call the an API to apply a template
-   using the access token.
+   The Service Provider would later call the API of the DNS provider to
+   apply a template using the access token.
 
    Additional parameters must be passed as name/value pairs when
    applying the template.
 
-3.  DNS Provider Discovery
+6.  DNS Provider Discovery
 
    To facilitate discovery of the DNS Provider from a domain name DNS is
    utilized.  This is done by returning a TXT record for
@@ -495,16 +498,15 @@ Internet-Draft               Domain Connect                   April 2022
 
    An example of the contents of this record:
 
-   domainconnect.virtucondomains.com
-
 
 
 
-
-Carney, et al.           Expires 29 October 2022                [Page 9]
+Kowalik, et al.          Expires 23 January 2025                [Page 9]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
+
 
+   domainconnect.virtucondomains.example
 
    As a practical matter of implementation, the DNS Provider may or may
    not contain a copy of this data in each and every zone.  Instead, the
@@ -535,33 +537,34 @@ Internet-Draft               Domain Connect                   April 2022
    +==============+=====================+========+=====================+
    | *Field*      | *Key*               | *Type* | *Description*       |
    +==============+=====================+========+=====================+
-   | *Provider    | providerId          | String | Unique identifier   |
-   | Id*          |                     |        | for the DNS         |
-   |              |                     |        | Provider.  To       |
+   | *Provider    | providerId          | String | (REQUIRED) Unique   |
+   | Id*          |                     |        | identifier for the  |
+   |              |                     |        | DNS Provider.  To   |
    |              |                     |        | ensure non-         |
    |              |                     |        | coordinated         |
    |              |                     |        | uniqueness, this    |
    |              |                     |        | should be the       |
    |              |                     |        | domain name of the  |
    |              |                     |        | DNS Provider (e.g.  |
-   |              |                     |        | virtucom.com).      |
+   |              |                     |        | virtucom.example).  |
    +--------------+---------------------+--------+---------------------+
-   | *Provider    | providerName        | String | The name of the     |
-   | Name*        |                     |        | DNS Provider.       |
+   | *Provider    | providerName        | String | (REQUIRED) The      |
+   | Name*        |                     |        | name of the DNS     |
+   |              |                     |        | Provider.           |
    +--------------+---------------------+--------+---------------------+
    | *Provider    | providerDisplayName | String | (OPTIONAL) The      |
    | Display      |                     |        | name of the DNS     |
-   | Name*        |                     |        | Provider that       |
-   |              |                     |        | should be           |
-   |              |                     |        | displayed by the    |
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 10]
+Kowalik, et al.          Expires 23 January 2025               [Page 10]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+   | Name*        |                     |        | Provider that       |
+   |              |                     |        | should be           |
+   |              |                     |        | displayed by the    |
    |              |                     |        | Service Provider.   |
    |              |                     |        | This may change     |
    |              |                     |        | per domain for      |
@@ -596,8 +599,9 @@ Internet-Draft               Domain Connect                   April 2022
    |              |                     |        | asynchronous flow   |
    |              |                     |        | on this domain.     |
    +--------------+---------------------+--------+---------------------+
-   | *API URL     | urlAPI              | String | The URL Prefix for  |
-   | Prefix*      |                     |        | the REST API        |
+   | *API URL     | urlAPI              | String | (REQUIRED) The URL  |
+   | Prefix*      |                     |        | Prefix for the      |
+   |              |                     |        | REST API            |
    +--------------+---------------------+--------+---------------------+
    | *Width of    | width               | Number | (OPTIONAL) This is  |
    | Window*      |                     |        | the desired width   |
@@ -606,18 +610,18 @@ Internet-Draft               Domain Connect                   April 2022
    |              |                     |        | when navigated in   |
    |              |                     |        | a popup.  Default   |
    |              |                     |        | value if not        |
-   |              |                     |        | returned should be  |
-   |              |                     |        | 750px.              |
-   +--------------+---------------------+--------+---------------------+
-   | *Height of   | height              | Number | (OPTIONAL) This is  |
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 11]
+Kowalik, et al.          Expires 23 January 2025               [Page 11]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+   |              |                     |        | returned should be  |
+   |              |                     |        | 750px.              |
+   +--------------+---------------------+--------+---------------------+
+   | *Height of   | height              | Number | (OPTIONAL) This is  |
    | Window*      |                     |        | the desired height  |
    |              |                     |        | of the window for   |
    |              |                     |        | granting consent    |
@@ -662,31 +666,31 @@ Internet-Draft               Domain Connect                   April 2022
    |              |                     |        | nameservers; for    |
    |              |                     |        | this the registry   |
    |              |                     |        | would be queried.   |
-   +--------------+---------------------+--------+---------------------+
 
-             Table 1: properties of the settings data structure
 
 
-
-
-Carney, et al.           Expires 29 October 2022               [Page 12]
+Kowalik, et al.          Expires 23 January 2025               [Page 12]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-   As an example, the JSON returned by this call might contain.
+   +--------------+---------------------+--------+---------------------+
+
+             Table 1: properties of the settings data structure
 
    {
-       "providerId": "virtucondomains.com",
+       "providerId": "virtucondomains.example",
        "providerName": "Virtucon Domains",
        "providerDisplayName": "Virtucon Domains",
-       "urlSyncUX": "https://domainconnect.virtucondomains.com",
-       "urlAsyncUX": "https://domainconnect.virtucondomains.com",
-       "urlAPI": "https://api.domainconnect.virtucondomains.com",
+       "urlSyncUX": "https://domainconnect.virtucondomains.example",
+       "urlAsyncUX": "https://domainconnect.virtucondomains.example",
+       "urlAPI": "https://api.domainconnect.virtucondomains.example",
        "width": 750,
        "height": 750,
-       "urlControlPanel": "https://domaincontrolpanel.virtucondomains.com/?domain=%domain%",
-       "nameServers": ["ns01.virtucondomainsdns.com", "ns02.virtucondomainsdns.com"]
+       "urlControlPanel": "https://domaincontrolpanel.virtucondomains.ex
+       ample/?domain=%domain%",
+       "nameServers": ["ns01.virtucondomainsdns.example", "ns02.virtucon
+       domainsdns.example"]
    }
 
    Discovery must work on the root domain (zone) only.  Bear in mind
@@ -714,49 +718,51 @@ Internet-Draft               Domain Connect                   April 2022
 
           Table 2: HTTP status codes for the settings end-point
 
-4.  Applying Domain Connect
+7.  Applying Domain Connect
 
-4.1.  Endpoints
-
-   The Domain Connect endpoints returned in the JSON during discovery
-   are in the form of URLs.
 
 
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 13]
+Kowalik, et al.          Expires 23 January 2025               [Page 13]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
+
 
+7.1.  Endpoints
+
+   The Domain Connect endpoints returned in the JSON during discovery
+   are in the form of URLs.
 
    The first set of endpoints are for the UX that the Service Provider
    links to.  These are for the synchronous flow where the user can
    click to grant consent and have changes applied, and for the
-   asynchronous oAuth flow where the user can grant consent for OAuth
+   asynchronous OAuth flow where the user can grant consent for OAuth
    access.
 
    The second set of endpoints are for the REST API.
 
    All endpoints begin with a root URL for the DNS Provider such as:
 
-   https://connect.dnsprovider.com
+   https://connect.dnsprovider.example
 
    They may also include any prefix at the discretion of the DNS
    Provider.  For example:
 
-   https://connect.dnsprovider.com/api
+   https://connect.dnsprovider.example/api
 
    The root URLs for the UX endpoints and the API endpoints are returned
    in the JSON payload during DNS Provider discovery.
 
-4.2.  Synchronous Flow
+7.2.  Synchronous Flow
 
-4.2.1.  Query Supported Template
+7.2.1.  Query Supported Template
 
    GET
 
-   {urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}
+   {urlAPI}/v2/domainTemplates/providers/{providerId}/services
+   /{serviceId}
 
    This URL is be used by the Service Provider to determine if the DNS
    Provider supports a specific template through the synchronous flow.
@@ -764,7 +770,7 @@ Internet-Draft               Domain Connect                   April 2022
    Returning a status of 200 without a body indicates the template is
    supported.  The DNS provider may decide to disclose the version of
    the template in a JSON object with field _version_ (see: version
-   field (Section 5.2)) or the full JSON object of deployed template.
+   field (Section 8.2) or the full JSON object of deployed template.
 
    Returning a status of 404 indicates the template is not supported.
 
@@ -775,15 +781,9 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 14]
+Kowalik, et al.          Expires 23 January 2025               [Page 14]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
       +===========+==========+======================================+
@@ -801,11 +801,14 @@ Internet-Draft               Domain Connect                   April 2022
             Table 3: https status codes for the Query Supported
                              Template end-point
 
-4.2.2.  Apply Template
+7.2.2.  Apply Template
+
+7.2.2.1.  Apply Template URL
 
    GET
 
-   {urlSyncUX}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties]
+   {urlSyncUX}/v2/domainTemplates/providers/{providerId}/services
+   /{serviceId}/apply?[properties]
 
    This is the URL where the user is sent to apply a template to a
    domain they own.  It is called from the Service Provider to start the
@@ -813,7 +816,7 @@ Internet-Draft               Domain Connect                   April 2022
 
    This URL can be called in one of two ways.
 
-4.2.2.1.  New Browser Window
+7.2.2.2.  New Browser Window
 
    The first is through a new browser tab or in a popup browser window.
    The DNS Provider signs the user in if necessary, verifies domain
@@ -821,7 +824,7 @@ Internet-Draft               Domain Connect                   April 2022
    template.  After application of the template, the DNS Provider should
    automatically close the browser tab or window.
 
-4.2.2.2.  Same Browser Window
+7.2.2.3.  Same Browser Window
 
    The second is in the current browser tab/window.  As above the DNS
    Provider signs the user in if necessary, verifies the user control of
@@ -832,16 +835,15 @@ Internet-Draft               Domain Connect                   April 2022
 
    Several parameters must be appended to the end of this redirect_uri.
 
-   *  State
-
-
 
 
-Carney, et al.           Expires 29 October 2022               [Page 15]
+Kowalik, et al.          Expires 23 January 2025               [Page 15]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+   *  State
+
       If a state parameter is passed in on the query string, this must
       be passed back as state= on the redirect_uri.
 
@@ -850,7 +852,7 @@ Internet-Draft               Domain Connect                   April 2022
       If authorization could not be obtained or an error has occurred,
       the parameter error= must be appended.  For consistency with the
       asynchronous OAuth flows the valid values for the error parameter
-      will be as specified in OAuth 2.0 RFC 6749 (4.1.2.1.  Error
+      will be as specified in OAuth 2.0 [RFC6749] (4.1.2.1.  Error
       Response - "error" parameter).  Valid values are: invalid_request,
       unauthorized_client, access_denied, unsupported_response_type,
       invalid_scope, server_error, and temporarily_unavailable.
@@ -881,24 +883,31 @@ Internet-Draft               Domain Connect                   April 2022
    the redirect_uri must be within the domains specified in the template
    in syncRedirectDomain.
 
-4.2.2.3.  Parameters/properties
 
-   +=============+==============+======================================+
-   | Property    | Request      | Description                          |
-   |             | Parameter    |                                      |
-   +=============+==============+======================================+
-   | *Domain*    | domain       | The domain name being configured.    |
-   |             |              | This is the root domain (the         |
-   |             |              | registered domain or delegated       |
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 16]
+
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 16]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
+
 
+7.2.2.4.  Parameters/properties
 
-   |             |              | zone).                               |
+   +=============+==============+======================================+
+   | Property    | Request      | Description                          |
+   |             | Parameter    |                                      |
+   +=============+==============+======================================+
+   | *Domain*    | domain       | (REQUIRED) The domain name being     |
+   |             |              | configured.  This is the root        |
+   |             |              | domain (the registered domain or     |
+   |             |              | delegated zone).                     |
    +-------------+--------------+--------------------------------------+
    | *Host*      | host         | (OPTIONAL) This is the host name of  |
    |             |              | the sub domain.  If left blank, the  |
@@ -924,19 +933,27 @@ Internet-Draft               Domain Connect                   April 2022
    |             |              | when redirecting to the              |
    |             |              | redirect_uri described above.        |
    +-------------+--------------+--------------------------------------+
-   | *Name/Value | *            | Any key that will be used as a       |
-   | Pairs*      |              | replacement for the "% surrounded"   |
-   |             |              | variables in the template.  The      |
-   |             |              | name portion of this API call        |
-   |             |              | corresponds to the variable(s)       |
-   |             |              | specified in the template and the    |
-   |             |              | value corresponds to the value that  |
-   |             |              | will be used when applying the       |
-   |             |              | template.                            |
+   | *Name/Value | *            | (REQUIRED) Any key that will be      |
+   | Pairs*      |              | used as a replacement for the "%     |
+   |             |              | surrounded" variables in the         |
+   |             |              | template.  The name portion of this  |
+   |             |              | API call corresponds to the          |
+   |             |              | variable(s) specified in the         |
+   |             |              | template and the value corresponds   |
+   |             |              | to the value that will be used when  |
+   |             |              | applying the template.               |
    +-------------+--------------+--------------------------------------+
    | *Provider   | providerName | (OPTIONAL) This parameter allows     |
    | Name*       |              | for the caller to provide            |
    |             |              | additional text for display with     |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 17]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    |             |              | the template providerName.  This     |
    |             |              | text should be used to augment the   |
    |             |              | providerName value from the          |
@@ -946,14 +963,6 @@ Internet-Draft               Domain Connect                   April 2022
    |             |              | set in the template.  Note: this     |
    |             |              | used to be controlled by the         |
    |             |              | "shared" attribute in the template,  |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 17]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    |             |              | which has been deprecated.           |
    +-------------+--------------+--------------------------------------+
    | *Service    | serviceName  | (OPTIONAL) This parameter allows     |
@@ -977,24 +986,46 @@ Internet-Draft               Domain Connect                   April 2022
    | *Signature* | sig          | (OPTIONAL) A signature of the query  |
    |             |              | string.  See Security                |
    |             |              | Considerations section below.        |
+   +-------------+--------------+--------------------------------------+
+   | *Key*       | key          | (OPTIONAL) A value containing the    |
+   |             |              | host in DNS where the public key     |
+   |             |              | for the signature can be obtained.   |
+   |             |              | The domain for this host is in the   |
+   |             |              | template in syncPubKeyDomain.  See   |
+   |             |              | Security Considerations section      |
+   |             |              | below.                               |
    +-------------+--------------+--------------------------------------+
 
         Table 4: query parameters of the apply call in the sync flow
 
    An example query string:
 
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 18]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    GET
 
-   https://web-connect.dnsprovider.com/v2/domainTemplates/providers/exampleservice.domainconnect.org/services/template1/apply?domain=example.com&IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello
+   https://web-connect.dnsprovider.example/v2/domainTemplates/providers/
+   exampleservice.example/services/template1/apply?domain=example.com
+   &IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello
 
    This call indicates that the Service Provider wishes to connect the
    domain example.com to the service using the template identified by
-   the composite key of the provider (exampleservice.domainconnect.org)
-   and the service template owned by them (template1).  In this example,
-   there are two variables in this template, "IP" and "RANDOMTEXT".
-   These variables are passed as name/value pairs.
+   the composite key of the provider (exampleservice.example) and the
+   service template owned by them (template1).  In this example, there
+   are two variables in this template, "IP" and "RANDOMTEXT".  These
+   variables are passed as name/value pairs.
+
+7.2.3.  Security Considerations
 
-4.2.3.  Security Considerations
+7.2.3.1.  Risk of phishing with open template parameters
 
    By applying a template with parameters there is a security
    consideration that must be taken into account.
@@ -1002,14 +1033,6 @@ Internet-Draft               Domain Connect                   April 2022
    Consider the template above where the IP address of the A record is
    passed in through a variable.  A bad actor could generate a URL with
    a malicious IP and phish users by sending out emails asking them to
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 18]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    "re-configure" their service.  If an end user is convinced to click
    on this link, they would land on the DNS Provider site to confirm the
    change.  To the user, this would appear to be a valid request to
@@ -1018,7 +1041,7 @@ Internet-Draft               Domain Connect                   April 2022
    Not all templates have this problem.  But when they do, there are
    several options.
 
-4.2.3.1.  Disable Synchronous
+7.2.3.2.  Disable Synchronous
 
    One option is to disable the synchronous flow and use asynchronous
    OAuth.  This can be controlled with the syncBlock value from the
@@ -1026,13 +1049,29 @@ Internet-Draft               Domain Connect                   April 2022
    implementation burden and requires onboarding between each Service
    and DNS Provider.
 
-4.2.3.2.  Digitally Sign Requests
+7.2.3.3.  Digitally Sign Requests
 
    Another option is to digitally sign the query string.  A signature is
    appended as an additional query string parameter, properly URL
    encoded and of the form:
 
-   sig=NLOQQm6ikGC2FlFvFZqIFNCZqlaC4B%2FQDwS6iCwIElMWhXMgRnRE17zhLtdLFieWkyqKa4I%2FOoFaAgd%2FAl%2ByzDd3sM2X1JVF5ELjTlj84jZ4KOEIdnbgkEeO%2FTkYRrPkwcmcHMwc4RuX%2Fqio8vKYxJaKLKeVGpUNSKo7zkq3XIRgyxoLSRKxmlSTHFAz4LvYXPWo6SHDoVcRvElWj18Um13sSXuX4KhtOLym2yImHpboEi4m2Ziigc%2BNHZE0VvHUR7wZgDaB01z8hFm5ATF%2B8swjandMRf2Lr4Syv4qTxMNT61r62EWFkt5t9nhxMgss6z4pfDVFZ3vYwSJDGuRpEQ%3D%3D
+
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 19]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   sig=V2te9zWMU7G3plxBTsmYSJTvn2vzMvNwAjWQ%2BwTe91DxuJhdVf4cVc4vZBYfEYV
+   7u5d7PzTO7se7OrkhyiB7TpoJJW1yB5qHR7HKM5SZldUsdtg5%2B1SzEtIX0Uq8b2mCmQ
+   F%2FuJGXpqCyFrEajvpTM7fFKPk1kuctmtkjV7%2BATcvNPLWY7KyE4%2Bqc8jpfN61cP
+   5l8iA4krAa3%2BfTro5cmWR8YUJ5yrnRs6KT4b5D71HFvOUk0sGEUddUUlsyRQKRHUFN6
+   HjEya50YDHfZJlYHkHlK0xX6Yqeii9QZ2I35U9eJbSvZGQko5beqviWFXdsVDbvd3DYcb
+   SHgJq9%2FXoMTTw%3D%3D
 
    The Service Provider generates this signature using a private key.
    As indicated, this signature is generated from the query string
@@ -1054,25 +1093,34 @@ Internet-Draft               Domain Connect                   April 2022
    multiple records may exist for the DNS TXT query.  For example, a
    public key of:
 
-   MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1dCqv7JEzUOfbhWKB9mTRsv3O9Vzy1Tz3UQlIDGpnVrTPBJDQTXUhxUMREEOBKo+rOjHZqfYnSmlkgu1dnBEO8bsELQL8GjS4zsjdA53gRk2SDxuzcB4fK+NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf50qP2/jMNs2G+KTlk3dBHx3wtqYLvdcop1Tk5xBD64BPJ9uwm8KlDNHe+8O+cC9j04Ji8B2K0/PzAj90xnb8XJy/EM124hpT9lMgpHKBUvdeurJYweC6oP41gsTf5LrpjnyIy9j5FHPCQIDAQAB
+   MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN4BHkkv0SBjAzIc
+   4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzLIZLNyMfI6qiXnM
+   +HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfyR/XSEWC5u16EBNvRn
+   NAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1dbdRy2opRPQ2FdZpovUgknybq/6FkeD
+   tW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX
+   2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8weDjXrJwIDAQAB
 
    may contain several TXT records.  The records would be of the form:
 
+   p=1,a=RS256,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA18SgvpmeasN
+   4BHkkv0SBjAzIc4grYLjiAXRtNiBUiGUDMeTzQrKTsWvy9NuxU1dIHCZy9o1CrKNg5EzL
+   IZLNyMfI6qiXnM+HMd4byp97zs/3D39Q8iR5poubQcRaGozWx8yQpG0OcVdmEVcTfy
 
+   p=2,a=RS256,d=R/XSEWC5u16EBNvRnNAOAvZYUdWqVyQvXsjnxQot8KcK0QP8iHpoL/1
+   dbdRy2opRPQ2FdZpovUgknybq/6FkeDtW7uCQ6Mvu4QxcUa3+WP9nYHKtgWip/eFxpeb+
+   qLvcLHf1h0JXtxLVdyy6OLk3f2JRYUX2ZZVDvG3biTpeJz6iRzjGg6MfGxXZHjI8
 
+   p=3,a=RS256,d=weDjXrJwIDAQAB
 
-Carney, et al.           Expires 29 October 2022               [Page 19]
-
-Internet-Draft               Domain Connect                   April 2022
 
 
-   p=1,a=RS256,t=x509,d=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1dCqv7JEzUOfbhWKB9mTRsv3O9Vzy1Tz3UQlIDGpnVrTPBJDQTXUhxUMREEOBKo+rOjHZqfYnSmlkgu1dn
 
-   p=2,a=RS256,t=x509,d=BEO8bsELQL8GjS4zsjdA53gRk2SDxuzcB4fK+NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf5
 
-   p=3,a=RS256,t=x509,d=NCDfnRHut5nG0S3U4cq4DuGrMDFVBwxH1duTsqDNgIOOfNTsFcWSVXoSSTqCCMGbj8Vt51umDhWQAj06lf50qP2/jMNs2G+KTlk3dBHx3wtqYLvdcop1Tk5xBD64BPJ9
 
-   p=4,a=RS256,t=x509,d=uwm8KlDNHe+8O+cC9j04Ji8B2K0/PzAj90xnb8XJy/EM124hpT9lMgpHKBUvdeurJYweC6oP41gsTf5LrpjnyIy9j5FHPCQIDAQAB
+Kowalik, et al.          Expires 23 January 2025               [Page 20]
+
+Internet-Draft               Domain Connect                    July 2024
+
 
    Here the public key is broken into four records in DNS, and the data
    also indicates that the signing algorithm is an RSA Signature with
@@ -1084,7 +1132,7 @@ Internet-Draft               Domain Connect                   April 2022
 
    The above data was generated for a query string:
 
-   a=1&b=2&ip=10.10.10.10&domain=foobar.com
+   a=1&b=2&ip=10.10.10.10&domain=example.net
 
    Signing the query string by the Service Provider is OPTIONAL.  Not
    all Services Provider templates require or are able to provide this
@@ -1100,7 +1148,7 @@ Internet-Draft               Domain Connect                   April 2022
    The values of each query string value key/value pair must be properly
    URL Encoded before the signature is generated.
 
-4.2.3.3.  Warnings
+7.2.3.4.  Warnings
 
    Some applications aren't able to use OAuth and/or sign requests.
 
@@ -1112,17 +1160,7 @@ Internet-Draft               Domain Connect                   April 2022
    extra warnings to the user to have them verify the link was/is from a
    reputable source before applying the template.
 
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 20]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-4.2.4.  Shared Templates
+7.2.4.  Shared Templates
 
    Some templates can be called by multiple companies, or be used for
    different purposes.
@@ -1133,6 +1171,13 @@ Internet-Draft               Domain Connect                   April 2022
    third parties.  It is often this third party reseller that configures
    DNS.
 
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 21]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    While each reseller could enable Domain Connect, this is inefficient
    for the DNS Providers.  Enabling a single template that is shared by
    multiple resellers would be more optimal.
@@ -1161,23 +1206,13 @@ Internet-Draft               Domain Connect                   April 2022
    Formatting.  But this would be required if the template required
    signatures.
 
-4.2.5.  Verification of Changes
+7.2.5.  Verification of Changes
 
    There are circumstances where the Service Provider may wish to verify
    that the template was successfully applied.  Without Domain Donnect,
    this typically involved the Service Provider querying DNS to see if
    the changes to DNS had been made.
 
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 21]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    This same technique works with Domain Connect, and if necessary can
    be triggered either manually on the Service Provider site or
    automatically upon page/window activation in the browser when the
@@ -1189,7 +1224,17 @@ Internet-Draft               Domain Connect                   April 2022
    return url in the browser.  As such it is recommend that enablement
    of a service be based on verification of changes to DNS.
 
-4.3.  Asynchronous Flow: OAuth
+7.3.  Asynchronous Flow: OAuth
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 22]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+7.3.1.  General information
 
    Using the OAuth flow is a more advanced use case needed by Service
    Providers that have more complex configurations that may require
@@ -1203,7 +1248,7 @@ Internet-Draft               Domain Connect                   April 2022
    is recommended that Service Providers relying on an OAuth
    implementation also implement a synchronous implementation.
 
-4.3.1.  OAuth Flow: Setup
+7.3.2.  OAuth Flow: Setup
 
    Service providers wishing to use the OAuth flow must register as an
    OAuth client with each DNS provider.  This is a manual process.
@@ -1221,21 +1266,29 @@ Internet-Draft               Domain Connect                   April 2022
    id and a secret which will be used when requesting tokens.  For
    simplicity the client id should be the same as the providerId.
 
-4.3.2.  OAuth Flow: Getting an Authorization Code
+7.3.3.  OAuth Flow: Getting an Authorization Code
 
    GET
 
    {urlAsyncUX}/v2/domainTemplates/providers/{providerId}
 
+   To initiate the OAuth flow the Service Provider first links to the
+   DNS Provider to gain consent.
 
 
-Carney, et al.           Expires 29 October 2022               [Page 22]
-
-Internet-Draft               Domain Connect                   April 2022
 
 
-   To initiate the OAuth flow the Service Provider first links to the
-   DNS Provider to gain consent.
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 23]
+
+Internet-Draft               Domain Connect                    July 2024
+
 
    This endpoint is similar to the synchronous flow described above.
    The DNS Provider must authenticate the user, verify the user has
@@ -1285,35 +1338,34 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 23]
-
-Internet-Draft               Domain Connect                   April 2022
 
 
-   +===============================================+==================+
-   | *Query String*                                | *Description*    |
-   +===============================================+==================+
-   | scope=t1+t2&domain=example.com                | Templates "t1"   |
-   |                                               | and "t2" can be  |
-   |                                               | applied to       |
-   |                                               | example.com      |
-   +-----------------------------------------------+------------------+
-   | scope=t1+t2&domain=example.com&host=sub1,sub2 | Templates "t1"   |
-   |                                               | and "t2" can be  |
-   |                                               | applied to       |
-   |                                               | sub1.example.com |
-   |                                               | or               |
-   |                                               | sub2.example.com |
-   +-----------------------------------------------+------------------+
-   | scope=t1+t2&domain=example.com&host=sub1,     | Templates "t1"   |
-   |                                               | and "t2" can be  |
-   |                                               | applied to       |
-   |                                               | example.com or   |
-   |                                               | sub1.example.com |
-   +-----------------------------------------------+------------------+
 
-       Table 5: examples of scope and host parameter values in the
-                                async flow
+Kowalik, et al.          Expires 23 January 2025               [Page 24]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+        +===================================+=====================+
+        | *Query String*                    | *Description*       |
+        +===================================+=====================+
+        | scope=t1+t2=example.com           | Templates "t1" and  |
+        |                                   | "t2" can be applied |
+        |                                   | to example.com      |
+        +-----------------------------------+---------------------+
+        | scope=t1+t2=example.com=sub1,sub2 | Templates "t1" and  |
+        |                                   | "t2" can be applied |
+        |                                   | to sub1.example.com |
+        |                                   | or sub2.example.com |
+        +-----------------------------------+---------------------+
+        | scope=t1+t2=example.com=sub1,     | Templates "t1" and  |
+        |                                   | "t2" can be applied |
+        |                                   | to example.com or   |
+        |                                   | sub1.example.com    |
+        +-----------------------------------+---------------------+
+
+          Table 5: examples of scope and host parameter values in
+                               the async flow
 
    Upon successful authorization/verification/consent from the user, the
    DNS Provider will direct the end user's browser to the redirect URI.
@@ -1322,7 +1374,7 @@ Internet-Draft               Domain Connect                   April 2022
 
    Similar to the synchronous flow, upon error the DNS provider may
    append an error code as query parameter "error".  These errors are
-   also from the oAuth 2.0 RFC 6749 (4.1.2.1.  Error Response - "error"
+   also from the OAuth 2.0 [RFC6749] (4.1.2.1.  Error Response - "error"
    parameter).  Valid values include: invalid_request,
    unauthorized_client, access_denied, unsupported_response_type,
    invalid_scope, server_error, and temporarilly_unavailable.  An
@@ -1341,86 +1393,98 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 24]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   +===========+===============+=======================================+
-   | Property  | Key           | Description                           |
-   +===========+===============+=======================================+
-   | *Domain*  | domain        | The domain name being                 |
-   |           |               | configured.  This is the root         |
-   |           |               | domain (the registered domain or      |
-   |           |               | delegated zone).                      |
-   +-----------+---------------+---------------------------------------+
-   | *Host*    | host          | (OPTIONAL) An list of comma           |
-   |           |               | separated host names upon which       |
-   |           |               | the template may be applied.  An      |
-   |           |               | empty string implies the root.        |
-   +-----------+---------------+---------------------------------------+
-   | *Client   | client_id     | The client id that was provided       |
-   | Id*       |               | by the DNS provider to the            |
-   |           |               | service provider during               |
-   |           |               | registration.  It is recommended      |
-   |           |               | that this should be the same as       |
-   |           |               | the providerId in the template.       |
-   +-----------+---------------+---------------------------------------+
-   | *Redirect | redirect_uri  | The location to direct the            |
-   | URI*      |               | client's browser upon successful      |
-   |           |               | authorization or upon error.          |
-   |           |               | Validation of the redirect_uri        |
-   |           |               | will be done by the DNS Provider      |
-   |           |               | to match the values provided          |
-   |           |               | during onboarding.                    |
-   +-----------+---------------+---------------------------------------+
-   | *Response | response_type | (OPTIONAL) If included it must        |
-   | type*     |               | be the string 'code' to indicate      |
-   |           |               | an authorization code is being        |
-   |           |               | requested.                            |
-   +-----------+---------------+---------------------------------------+
-   | *Scope*   | scope         | The OAuth scope corresponds to        |
-   |           |               | the requested templates.  This        |
-   |           |               | is list of space separated            |
-   |           |               | serviceIds.                           |
-   +-----------+---------------+---------------------------------------+
-   | *Provider | providerName  | (OPTIONAL) This parameter allows      |
-   | Name*     |               | for the caller to provide             |
-   |           |               | additional text for display with      |
-   |           |               | the template providerName.  This      |
-   |           |               | text should be used to augment        |
-   |           |               | the providerName value from the       |
-   |           |               | template, not replace it.             |
-   +-----------+---------------+---------------------------------------+
-   | *Service  | serviceName   | (OPTIONAL) This parameter allows      |
-   | Name*     |               | for the caller to provide             |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 25]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   |           |               | additional text for display with      |
-   |           |               | the template serviceName(s).  It      |
-   |           |               | should be used to augment the         |
-   |           |               | serviceName value(s) from the         |
-   |           |               | template, not replace.                |
-   +-----------+---------------+---------------------------------------+
-   | *State*   | state         | (OPTIONAL) This is a random,          |
-   |           |               | unique string passed along to         |
-   |           |               | prevent CSRF or to pass state         |
-   |           |               | value back to the caller.  It         |
-   |           |               | will be returned as a parameter       |
-   |           |               | appended to the redirect_url          |
-   |           |               | described above.                      |
-   +-----------+---------------+---------------------------------------+
-
-     Table 6: query parameters of the authorization end-point in async
-                                    flow
-
-4.3.3.  oAuth Flow: Requesting an Access Token
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 25]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+     +===========+===============+==================================+
+     | Property  | Key           | Description                      |
+     +===========+===============+==================================+
+     | *Domain*  | domain        | (REQUIRED) The domain name being |
+     |           |               | configured.  This is the root    |
+     |           |               | domain (the registered domain or |
+     |           |               | delegated zone).                 |
+     +-----------+---------------+----------------------------------+
+     | *Host*    | host          | (OPTIONAL) An list of comma      |
+     |           |               | separated host names upon which  |
+     |           |               | the template may be applied.  An |
+     |           |               | empty string implies the root.   |
+     +-----------+---------------+----------------------------------+
+     | *Client   | client_id     | (REQUIRED) The client id that    |
+     | Id*       |               | was provided by the DNS provider |
+     |           |               | to the service provider during   |
+     |           |               | registration.  It is recommended |
+     |           |               | that this should be the same as  |
+     |           |               | the providerId in the template.  |
+     +-----------+---------------+----------------------------------+
+     | *Redirect | redirect_uri  | (REQUIRED) The location to       |
+     | URI*      |               | direct the client's browser upon |
+     |           |               | successful authorization or upon |
+     |           |               | error.  Validation of the        |
+     |           |               | redirect_uri will be done by the |
+     |           |               | DNS Provider to match the values |
+     |           |               | provided during onboarding.      |
+     +-----------+---------------+----------------------------------+
+     | *Response | response_type | (OPTIONAL) If included it must   |
+     | type*     |               | be the string 'code' to indicate |
+     |           |               | an authorization code is being   |
+     |           |               | requested.                       |
+     +-----------+---------------+----------------------------------+
+     | *Scope*   | scope         | (REQUIRED) The OAuth scope       |
+     |           |               | corresponds to the requested     |
+     |           |               | templates.  This is list of      |
+     |           |               | space separated serviceIds.      |
+     +-----------+---------------+----------------------------------+
+     | *Provider | providerName  | (OPTIONAL) This parameter allows |
+     | Name*     |               | for the caller to provide        |
+     |           |               | additional text for display with |
+     |           |               | the template providerName.  This |
+     |           |               | text should be used to augment   |
+     |           |               | the providerName value from the  |
+     |           |               | template, not replace it.        |
+     +-----------+---------------+----------------------------------+
+     | *Service  | serviceName   | (OPTIONAL) This parameter allows |
+     | Name*     |               | for the caller to provide        |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 26]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+     |           |               | additional text for display with |
+     |           |               | the template serviceName(s).  It |
+     |           |               | should be used to augment the    |
+     |           |               | serviceName value(s) from the    |
+     |           |               | template, not replace.           |
+     +-----------+---------------+----------------------------------+
+     | *State*   | state         | (OPTIONAL) This is a random,     |
+     |           |               | unique string passed along to    |
+     |           |               | prevent CSRF or to pass state    |
+     |           |               | value back to the caller.  It    |
+     |           |               | will be returned as a parameter  |
+     |           |               | appended to the redirect_url     |
+     |           |               | described above.                 |
+     +-----------+---------------+----------------------------------+
+     | *Name/    | *             | (OPTIONAL) Any key that will be  |
+     | Value     |               | used as a replacement for the "% |
+     | Pairs*    |               | surrounded" value(s) in a        |
+     |           |               | template required for conflict   |
+     |           |               | detection.  This includes        |
+     |           |               | variables used in hosts and data |
+     |           |               | in certain TXT records.          |
+     +-----------+---------------+----------------------------------+
+
+       Table 6: query parameters of the authorization end-point in
+                                async flow
+
+7.3.4.  OAuth Flow: Requesting an Access Token
 
    POST
 
@@ -1428,7 +1492,7 @@ Internet-Draft               Domain Connect                   April 2022
 
    Once authorization has been granted, the Service Provider must use
    the Authorization Code provided to request an Access Token.  The
-   oAuth specification recommends that the Authorization Code be a short
+   OAuth specification recommends that the Authorization Code be a short
    lived token, and a reasonable recommended setting is ten minutes.  As
    such this exchange needs to be completed before that time has expired
    or the process will need to be repeated.
@@ -1442,23 +1506,21 @@ Internet-Draft               Domain Connect                   April 2022
    This is typically done when the OAuth client is a client application.
    When onboarding with the DNS Provider this would need to be enabled.
 
-   When the secret is provided (which is the normal case), care must be
-   taken.  A malicious user could create a domain that returns a false
-   __domainconnect_ TXT record, and subsequently a JSON call to their
-   own server for the API end point.  By doing so, they could then run
-   Domain Connect on their domain and retrieve the secret.
-
-
-
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 26]
+Kowalik, et al.          Expires 23 January 2025               [Page 27]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-   As such the urlAPI used for oAuth by the Service Provider should be
+   When the secret is provided (which is the normal case), care must be
+   taken.  A malicious user could create a domain that returns a false
+   __domainconnect_ TXT record, and subsequently a JSON call to their
+   own server for the API end point.  By doing so, they could then run
+   Domain Connect on their domain and retrieve the secret.
+
+   As such the urlAPI used for OAuth by the Service Provider should be
    maintained per DNS Provider and not the value retrieved during
    discovery.
 
@@ -1503,53 +1565,47 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 27]
+Kowalik, et al.          Expires 23 January 2025               [Page 28]
 
-Internet-Draft               Domain Connect                   April 2022
-
-
-    +================+===============+================================+
-    | Property       | Key           | Description                    |
-    +================+===============+================================+
-    | *Authorization | code/         | The authorization code that    |
-    | Code/Refresh   | refresh_token | was provided in the previous   |
-    | Code*          |               | step when the customer         |
-    |                |               | accepted the authorization     |
-    |                |               | request, or the refresh_token  |
-    |                |               | for a subsequent access token. |
-    +----------------+---------------+--------------------------------+
-    | *Redirect URI* | redirect_uri  | (OPTIONAL) This is required if |
-    |                |               | a redirect_uri was passed to   |
-    |                |               | request the authorization      |
-    |                |               | code.  When included, it needs |
-    |                |               | to be the same redirect_uri    |
-    |                |               | provided in this step.         |
-    +----------------+---------------+--------------------------------+
-    | *Grant type*   | grant_type    | The type of code in the        |
-    |                |               | request.  Usually the string   |
-    |                |               | 'authorization_code' or        |
-    |                |               | 'refresh_token'                |
-    +----------------+---------------+--------------------------------+
-    | *Client ID*    | client_id     | This is the client id that was |
-    |                |               | provided by the DNS provider   |
-    |                |               | to the Service Provider during |
-    |                |               | registration                   |
-    +----------------+---------------+--------------------------------+
-    | *Client        | client_secret | The secret provided to the     |
-    | Secret*        |               | Service Provider during        |
-    |                |               | registration.  Typically       |
-    |                |               | required unless the rare       |
-    |                |               | circumstance with secret-less  |
-    |                |               | oAuth.                         |
-    +----------------+---------------+--------------------------------+
-
-                 Table 7: parameters of the token end-point
+Internet-Draft               Domain Connect                    July 2024
+
+
+   +================+===============+=================================+
+   | Property       | Key           | Description                     |
+   +================+===============+=================================+
+   | *Authorization | code/         | (REQUIRED) The authorization    |
+   | Code/Refresh   | refresh_token | code that was provided in the   |
+   | Code*          |               | previous step when the customer |
+   |                |               | accepted the authorization      |
+   |                |               | request, or the refresh_token   |
+   |                |               | for a subsequent access token.  |
+   +----------------+---------------+---------------------------------+
+   | *Redirect URI* | redirect_uri  | (OPTIONAL) This is REQUIRED if  |
+   |                |               | a redirect_uri was passed to    |
+   |                |               | request the authorization code. |
+   |                |               | When included, it needs to be   |
+   |                |               | the same redirect_uri provided  |
+   |                |               | in this step.                   |
+   +----------------+---------------+---------------------------------+
+   | *Grant type*   | grant_type    | (REQUIRED) The type of code in  |
+   |                |               | the request.  Usually the       |
+   |                |               | string 'authorization_code' or  |
+   |                |               | 'refresh_token'                 |
+   +----------------+---------------+---------------------------------+
+   | *Client ID*    | client_id     | (REQUIRED) This is the client   |
+   |                |               | id that was provided by the DNS |
+   |                |               | provider to the Service         |
+   |                |               | Provider during registration    |
+   +----------------+---------------+---------------------------------+
+   | *Client        | client_secret | (REQUIRED) The secret provided  |
+   | Secret*        |               | to the Service Provider during  |
+   |                |               | registration.  Typically        |
+   |                |               | required unless the rare        |
+   |                |               | circumstance with secret-less   |
+   |                |               | OAuth.                          |
+   +----------------+---------------+---------------------------------+
+
+                Table 7: parameters of the token end-point
 
    Upon successful token exchange, the DNS Provider will return a
    response with 4 properties in the body of the response.
@@ -1565,9 +1621,9 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 28]
+Kowalik, et al.          Expires 23 January 2025               [Page 29]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
       +=================+===========================================+
@@ -1599,7 +1655,7 @@ Internet-Draft               Domain Connect                   April 2022
 
         Table 9: http status codes of the token end-point response
 
-4.3.4.  OAuth Flow: Making Requests with Access Tokens
+7.3.5.  OAuth Flow: Making Requests with Access Tokens
 
    Once the Service Provider has the access token, they can call the DNS
    Provider's API to make changes to DNS on the domain by applying and
@@ -1621,20 +1677,21 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 29]
+Kowalik, et al.          Expires 23 January 2025               [Page 30]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
    While the calls below do not have the same security consideration of
    passing the secret, it is recommend that the urlAPI be from a stored
    value vs. the value returned during discovery here as well.
 
-4.3.5.  OAuth Flow: Apply Template to Domain.
+7.3.6.  OAuth Flow: Apply Template to Domain.
 
    POST
 
-   {urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/apply?[properties]
+   {urlAPI}/v2/domainTemplates/providers/{providerId}/services
+   /{serviceId}/apply?[properties]
 
    The primary function of the API is to apply a template to a customer
    domain.
@@ -1670,18 +1727,18 @@ Internet-Draft               Domain Connect                   April 2022
     +==============+==============+===================================+
     | Property     | Key          | Description                       |
     +==============+==============+===================================+
-    | *Domain*     | domain       | The root domain name being        |
-    |              |              | configured.  It must match the    |
-    |              |              | domain that was authorized in the |
-    |              |              | token.                            |
+    | *Domain*     | domain       | (REQUIRED) The root domain name   |
+    |              |              | being configured.  It must match  |
+    |              |              | the domain that was authorized in |
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 30]
+Kowalik, et al.          Expires 23 January 2025               [Page 31]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+    |              |              | the token.                        |
     +--------------+--------------+-----------------------------------+
     | *Host*       | host         | (OPTIONAL) The host name of the   |
     |              |              | sub domain of the root domain     |
@@ -1690,14 +1747,15 @@ Internet-Draft               Domain Connect                   April 2022
     |              |              | template is being applied to the  |
     |              |              | root domain.                      |
     +--------------+--------------+-----------------------------------+
-    | *Name/Value  | *            | Any variable fields consumed by   |
-    | Pairs*       |              | this template.  The name portion  |
-    |              |              | of this API call corresponds to   |
-    |              |              | the variable(s) specified in the  |
-    |              |              | record and the value corresponds  |
-    |              |              | to the value that must be used    |
-    |              |              | when applying the template as per |
-    |              |              | the implementation notes.         |
+    | *Name/Value  | *            | (REQUIRED) Any variable fields    |
+    | Pairs*       |              | consumed by this template.  The   |
+    |              |              | name portion of this API call     |
+    |              |              | corresponds to the variable(s)    |
+    |              |              | specified in the record and the   |
+    |              |              | value corresponds to the value    |
+    |              |              | that must be used when applying   |
+    |              |              | the template as per the           |
+    |              |              | implementation notes.             |
     +--------------+--------------+-----------------------------------+
     | *Group ID*   | groupId      | (OPTIONAL) Specifies the group of |
     |              |              | changes in the template to apply. |
@@ -1728,16 +1786,16 @@ Internet-Draft               Domain Connect                   April 2022
     |              |              | additional context for the        |
     |              |              | serviceName that applied the      |
     |              |              | template.  It may be used by some |
-    |              |              | DNS Providers that display state  |
-    |              |              | regarding which templates have    |
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 31]
+Kowalik, et al.          Expires 23 January 2025               [Page 32]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
+    |              |              | DNS Providers that display state  |
+    |              |              | regarding which templates have    |
     |              |              | been applied.  It is only allowed |
     |              |              | when the "sharedProviderName"     |
     |              |              | attribute is set in the template  |
@@ -1746,7 +1804,7 @@ Internet-Draft               Domain Connect                   April 2022
     | *InstanceId* | instanceId   | (OPTIONAL) Only applicable to     |
     |              |              | templates supporting multiple     |
     |              |              | instances (see multiInstance      |
-    |              |              | (Section 5.2) template property). |
+    |              |              | (Section 8.2) template property). |
     |              |              | Allows for later removal of one   |
     |              |              | template instance by DNS          |
     |              |              | Providers storing this            |
@@ -1761,7 +1819,9 @@ Internet-Draft               Domain Connect                   April 2022
 
    POST
 
-   https://connect.dnsprovider.com/v2/domainTemplates/providers/exampleservice.domainconnect.org/services/template1/apply?IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello&force=1
+   https://connect.dnsprovider.example/v2/domainTemplates/providers/
+   exampleservice.example/services/template1/apply?IP=192.0.2.42
+   &RANDOMTEXT=shm%3A1542108821%3AHello&force=1
 
    The API must validate the access token, and that the domain belongs
    to the customer and is represented by the token being presented.  Any
@@ -1785,13 +1845,9 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 32]
+Kowalik, et al.          Expires 23 January 2025               [Page 33]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
      +================+==========+==================================+
@@ -1845,9 +1901,9 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 33]
+Kowalik, et al.          Expires 23 January 2025               [Page 34]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
    As an example:
@@ -1872,7 +1928,7 @@ Internet-Draft               Domain Connect                   April 2022
    In this example, the Service Provider tried to apply a new hosting
    template.  The domain had an existing service applied for hosting.
 
-4.3.6.  OAuth Flow: Revert Template
+7.3.7.  OAuth Flow: Revert Template
 
    This call reverts the application of a specific template from a
    domain.
@@ -1882,7 +1938,8 @@ Internet-Draft               Domain Connect                   April 2022
 
    POST
 
-   {urlAPI}/v2/domainTemplates/providers/{providerId}/services/{serviceId}/revert?domain={domain}&host={host}
+   {urlAPI}/v2/domainTemplates/providers/{providerId}/services
+   /{serviceId}/revert?domain={domain}&host={host}
 
    This API allows the removal of a template from a customer domain/host
    using an OAuth request.
@@ -1900,36 +1957,36 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-
-Carney, et al.           Expires 29 October 2022               [Page 34]
+Kowalik, et al.          Expires 23 January 2025               [Page 35]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
    POST
 
-   https://connect.dnsprovider.com/v2/domainTemplates/providers/exampleservice.domainconnect.org/services/template1/revert?domain=example.com
+   https://connect.dnsprovider.example/v2/domainTemplates/providers
+   /exampleservice.example/services/template1/revert?domain=example.com
 
    Allowed parameters:
 
    +==============+============+======================================+
    | Property     | Key        | Description                          |
    +==============+============+======================================+
-   | *Domain*     | domain     | The root domain name being           |
-   |              |            | configured.  It must match the       |
+   | *Domain*     | domain     | (REQUIRED) The root domain name      |
+   |              |            | being configured.  It must match the |
    |              |            | domain that was authorized in the    |
    |              |            | token.                               |
    +--------------+------------+--------------------------------------+
-   | *Host*       | host       | The host name of the sub domain of   |
-   |              |            | the root domain that was authorized  |
-   |              |            | in the token.  If omitted or left    |
-   |              |            | blank, the template is being applied |
-   |              |            | to the root domain.                  |
+   | *Host*       | host       | (OPTIONAL) The host name of the sub  |
+   |              |            | domain of the root domain that was   |
+   |              |            | authorized in the token.  If omitted |
+   |              |            | or left blank, the template is being |
+   |              |            | applied to the root domain.          |
    +--------------+------------+--------------------------------------+
    | *InstanceId* | instanceId | (OPTIONAL) Only applicable to        |
    |              |            | templates supporting multiple        |
    |              |            | instances (see multiInstance         |
-   |              |            | (Section 5.2) template property).    |
+   |              |            | (Section 8.2) template property).    |
    |              |            | For DNS Provider storing information |
    |              |            | about applied templates allows       |
    |              |            | removal of single instance of        |
@@ -1945,26 +2002,23 @@ Internet-Draft               Domain Connect                   April 2022
    Response codes Success, Authorization, and Errors are identical to
    above with the addition of the 501 code.
 
-4.3.7.  OAuth Flow: Revoking access
+7.3.8.  OAuth Flow: Revoking access
 
-   Like all oAuth flows, the user may revoke the access at any time
+   Like all OAuth flows, the user may revoke the access at any time
    using UX at the DNS Provider site.  As such the Service Provider
    needs to be aware that their access to the API may be denied.
 
+8.  Domain Connect Objects and Templates
 
 
 
 
-
-
-Carney, et al.           Expires 29 October 2022               [Page 35]
+Kowalik, et al.          Expires 23 January 2025               [Page 36]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-5.  Domain Connect Objects and Templates
-
-5.1.  Template Versioning
+8.1.  Template Versioning
 
    If a breaking change is made to a template it is recommended that a
    new template be created.  While on the surface versioning looks
@@ -1978,183 +2032,242 @@ Internet-Draft               Domain Connect                   April 2022
    Note that when a template changes, it does need to be on-boarded with
    the DNS Providers.
 
-   The version field (Section 5.2) of the template definition serves the
+   The version field (Section 8.2) of the template definition serves the
    purpose of transparency between the DNS Provider and the Service
    Provider in case of such changes.
 
-5.2.  Template Definition
+8.2.  Template Definition
 
    A template is defined as a standard JSON data structure containing
    the following data.  Fields are required unless otherwise indicated.
 
-   +=============+========+===================+==================================+
-   |Data Element |Type    |Key                |Description                       |
-   +=============+========+===================+==================================+
-   |*Service     |String  |providerId         |The unique identifier of the      |
-   |Provider Id* |        |                   |Service Provider that created this|
-   |             |        |                   |template.  This is used in the    |
-   |             |        |                   |URLs to identify the Service      |
-   |             |        |                   |Provider.  To ensure non-         |
-   |             |        |                   |coordinated uniqueness, this      |
-   |             |        |                   |should be the domain name of the  |
-   |             |        |                   |Service Provider (e.g.            |
-   |             |        |                   |exampleservice.domainconnect.org).|
-   +-------------+--------+-------------------+----------------------------------+
-   |*Service     |String  |providerName       |The name of the Service Provider  |
-   |Provider     |        |                   |suitable for display.  This may be|
-   |Name*        |        |                   |displayed to the user on the DNS  |
-   |             |        |                   |Provider consent UX.              |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Service Id* |String  |serviceId          |The name or identifier of the     |
-   |             |        |                   |template.  This is used in URLs to|
-   |             |        |                   |identify the template.  It is also|
-   |             |        |                   |used in the scope parameter for   |
-   |             |        |                   |oAuth.  It must not contain space |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 36]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   |             |        |                   |characters, and must be URL       |
-   |             |        |                   |friendly.                         |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Service     |String  |serviceName        |The name of the service suitable  |
-   |Name*        |        |                   |for display to the user.  This may|
-   |             |        |                   |be displayed to the user on the   |
-   |             |        |                   |DNS Provider consent UX.          |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Version*    |Integer |version            |(OPTIONAL) If present this        |
-   |             |        |                   |represents a version of the       |
-   |             |        |                   |template and should be increased  |
-   |             |        |                   |with each update of the template  |
-   |             |        |                   |content.  This value is mainly    |
-   |             |        |                   |informational to improve          |
-   |             |        |                   |communication and transparency    |
-   |             |        |                   |between providers.                |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Logo*       |String  |logoUrl            |(OPTIONAL) A graphical logo       |
-   |             |        |                   |representing the Service Provider |
-   |             |        |                   |and/or Service for use in any web-|
-   |             |        |                   |based flow.  If present this may  |
-   |             |        |                   |be displayed to the user on the   |
-   |             |        |                   |DNS Provider consent UX.          |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Description*|Text    |description        |(OPTIONAL) A textual description  |
-   |             |        |                   |of what this template attempts to |
-   |             |        |                   |do.  This is meant to assist      |
-   |             |        |                   |developers and must not be        |
-   |             |        |                   |displayed to the user.            |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Variable    |Text    |variableDescription|(OPTIONAL) A textual description  |
-   |Description* |        |                   |of what the variables are.  This  |
-   |             |        |                   |is meant to assist developers and |
-   |             |        |                   |must not be displayed to the user.|
-   +-------------+--------+-------------------+----------------------------------+
-   |*Synchronous |Boolean |syncBlock          |(OPTIONAL) Indicates that the     |
-   |Block*       |        |                   |synchronous protocol must be      |
-   |             |        |                   |disabled for this template.  The  |
-   |             |        |                   |default for this is false.        |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Shared*     |Boolean |shared             |(OPTIONAL) This flag has been     |
-   |             |        |                   |deprecated.  It used to indicate  |
-   |             |        |                   |that the template allowed a       |
-   |             |        |                   |dynamic providerName on the query |
-   |             |        |                   |string.  It is replaced with the  |
-   |             |        |                   |sharedProviderName flag in v2.2 of|
-   |             |        |                   |the spec.                         |
-   +-------------+--------+-------------------+----------------------------------+
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 37]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   |*Shared      |Boolean |sharedProviderName |(OPTIONAL) This flag indicates    |
-   |Provider     |        |                   |that the template allows the      |
-   |Name*        |        |                   |caller to pass in additional      |
-   |             |        |                   |information for the providerName. |
-   |             |        |                   |This information should augment   |
-   |             |        |                   |the display of the providerName   |
-   |             |        |                   |from the template.  The default   |
-   |             |        |                   |for this is false.  For backward  |
-   |             |        |                   |compatability with DNS Providers  |
-   |             |        |                   |not at V2.2 of the spec it is     |
-   |             |        |                   |recommended that the shared flag  |
-   |             |        |                   |also be set.                      |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Shared      |Boolean |sharedServiceName  |(OPTIONAL) This flag indicates    |
-   |Service Name*|        |                   |that the template allows the      |
-   |             |        |                   |caller to pass in additional      |
-   |             |        |                   |information for the serviceName.  |
-   |             |        |                   |This information should augment   |
-   |             |        |                   |the display of the serviceName    |
-   |             |        |                   |from the template.  The default   |
-   |             |        |                   |for this is false.                |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Synchronous |String  |syncPubKeyDomain   |(OPTIONAL) When present, indicates|
-   |Public Key   |        |                   |that calls to apply a template    |
-   |Domain*      |        |                   |synchronously must be digitally   |
-   |             |        |                   |signed.  The value indicates the  |
-   |             |        |                   |domain name for querying the TXT  |
-   |             |        |                   |record from DNS that contains the |
-   |             |        |                   |public key used for signing.      |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Synchronous |String  |syncRedirectDomain |(OPTIONAL) When present, this is a|
-   |Redirect     |        |                   |comma separated list of domain    |
-   |Domains*     |        |                   |names for which redirects must be |
-   |             |        |                   |sent to after applying a template |
-   |             |        |                   |for the synchronous flow.         |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Multiple    |Boolean |multiInstance      |(OPTIONAL) Defaults to False.     |
-   |Instance*    |        |                   |When set to True, it indicates    |
-   |             |        |                   |that the template may be applied  |
-   |             |        |                   |multiple times.  This only impacts|
-   |             |        |                   |DNS Providers that maintain       |
-   |             |        |                   |template state in DNS.            |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Warn        |Boolean |warnPhishing       |(OPTIONAL) When present, this     |
-   |Phishing*    |        |                   |tells the DNS Provider that the   |
-   |             |        |                   |template may contain variables    |
-   |             |        |                   |susceptible to phishing attacks   |
-   |             |        |                   |and the provider is unable to     |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 38]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   |             |        |                   |digitally sign the requests.  When|
-   |             |        |                   |set the DNS Provider should       |
-   |             |        |                   |display warnings to the user.  The|
-   |             |        |                   |default value for this is false.  |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Host        |Boolean |hostRequired       |(OPTIONAL) Defaults to false.     |
-   |Required*    |        |                   |When present this indicates that  |
-   |             |        |                   |the template has been authored to |
-   |             |        |                   |work only when both domain and    |
-   |             |        |                   |host are provided.  An example    |
-   |             |        |                   |where this would be true would be |
-   |             |        |                   |a template where CNAME is set on  |
-   |             |        |                   |the fully qualified domain name.  |
-   |             |        |                   |This is largely informational, as |
-   |             |        |                   |most DNS Providers already enforce|
-   |             |        |                   |such rules.                       |
-   +-------------+--------+-------------------+----------------------------------+
-   |*Template    |Array of|records            |A list of records for the         |
-   |Records*     |Template|                   |template.                         |
-   |             |Records |                   |                                  |
-   +-------------+--------+-------------------+----------------------------------+
+   +=============+========+===================+========================+
+   |Data Element |Type    |Key                |Description             |
+   +=============+========+===================+========================+
+   |*Service     |String  |providerId         |(REQUIRED) The unique   |
+   |Provider Id* |        |                   |identifier of the       |
+   |             |        |                   |Service Provider that   |
+   |             |        |                   |created this template.  |
+   |             |        |                   |This is used in the URLs|
+   |             |        |                   |to identify the Service |
+   |             |        |                   |Provider.  To ensure    |
+   |             |        |                   |non-coordinated         |
+   |             |        |                   |uniqueness, this should |
+   |             |        |                   |be the domain name of   |
+   |             |        |                   |the Service Provider    |
+   |             |        |                   |(e.g.                   |
+   |             |        |                   |exampleservice.example).|
+   +-------------+--------+-------------------+------------------------+
+   |*Service     |String  |providerName       |(REQUIRED) The name of  |
+   |Provider     |        |                   |the Service Provider    |
+   |Name*        |        |                   |suitable for display.   |
+   |             |        |                   |This may be displayed to|
+   |             |        |                   |the user on the DNS     |
+   |             |        |                   |Provider consent UX.    |
+   +-------------+--------+-------------------+------------------------+
+   |*Service Id* |String  |serviceId          |(REQUIRED) The name or  |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 37]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   |             |        |                   |identifier of the       |
+   |             |        |                   |template.  This is used |
+   |             |        |                   |in URLs to identify the |
+   |             |        |                   |template.  It is also   |
+   |             |        |                   |used in the scope       |
+   |             |        |                   |parameter for OAuth.  It|
+   |             |        |                   |must not contain space  |
+   |             |        |                   |characters, and must be |
+   |             |        |                   |URL friendly.           |
+   +-------------+--------+-------------------+------------------------+
+   |*Service     |String  |serviceName        |(REQUIRED) The name of  |
+   |Name*        |        |                   |the service suitable for|
+   |             |        |                   |display to the user.    |
+   |             |        |                   |This may be displayed to|
+   |             |        |                   |the user on the DNS     |
+   |             |        |                   |Provider consent UX.    |
+   +-------------+--------+-------------------+------------------------+
+   |*Version*    |Integer |version            |(OPTIONAL) If present   |
+   |             |        |                   |this represents a       |
+   |             |        |                   |version of the template |
+   |             |        |                   |and should be increased |
+   |             |        |                   |with each update of the |
+   |             |        |                   |template content.  This |
+   |             |        |                   |value is mainly         |
+   |             |        |                   |informational to improve|
+   |             |        |                   |communication and       |
+   |             |        |                   |transparency between    |
+   |             |        |                   |providers.              |
+   +-------------+--------+-------------------+------------------------+
+   |*Logo*       |String  |logoUrl            |(OPTIONAL) A graphical  |
+   |             |        |                   |logo representing the   |
+   |             |        |                   |Service Provider and/or |
+   |             |        |                   |Service for use in any  |
+   |             |        |                   |web-based flow.  If     |
+   |             |        |                   |present this may be     |
+   |             |        |                   |displayed to the user on|
+   |             |        |                   |the DNS Provider consent|
+   |             |        |                   |UX.                     |
+   +-------------+--------+-------------------+------------------------+
+   |*Description*|Text    |description        |(OPTIONAL) A textual    |
+   |             |        |                   |description of what this|
+   |             |        |                   |template attempts to do.|
+   |             |        |                   |This is meant to assist |
+   |             |        |                   |developers and must not |
+   |             |        |                   |be displayed to the     |
+   |             |        |                   |user.                   |
+   +-------------+--------+-------------------+------------------------+
+   |*Variable    |Text    |variableDescription|(OPTIONAL) A textual    |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 38]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   |Description* |        |                   |description of what the |
+   |             |        |                   |variables are.  This is |
+   |             |        |                   |meant to assist         |
+   |             |        |                   |developers and must not |
+   |             |        |                   |be displayed to the     |
+   |             |        |                   |user.                   |
+   +-------------+--------+-------------------+------------------------+
+   |*Synchronous |Boolean |syncBlock          |(OPTIONAL) Indicates    |
+   |Block*       |        |                   |that the synchronous    |
+   |             |        |                   |protocol must be        |
+   |             |        |                   |disabled for this       |
+   |             |        |                   |template.  The default  |
+   |             |        |                   |for this is false.      |
+   +-------------+--------+-------------------+------------------------+
+   |*Shared*     |Boolean |shared             |(OPTIONAL) This flag has|
+   |             |        |                   |been deprecated.  It    |
+   |             |        |                   |used to indicate that   |
+   |             |        |                   |the template allowed a  |
+   |             |        |                   |dynamic providerName on |
+   |             |        |                   |the query string.  It is|
+   |             |        |                   |replaced with the       |
+   |             |        |                   |sharedProviderName flag |
+   |             |        |                   |in v2.2 of the spec.    |
+   +-------------+--------+-------------------+------------------------+
+   |*Shared      |Boolean |sharedProviderName |(OPTIONAL) This flag    |
+   |Provider     |        |                   |indicates that the      |
+   |Name*        |        |                   |template allows the     |
+   |             |        |                   |caller to pass in       |
+   |             |        |                   |additional information  |
+   |             |        |                   |for the providerName.   |
+   |             |        |                   |This information should |
+   |             |        |                   |augment the display of  |
+   |             |        |                   |the providerName from   |
+   |             |        |                   |the template.  The      |
+   |             |        |                   |default for this is     |
+   |             |        |                   |false.  For backward    |
+   |             |        |                   |compatability with DNS  |
+   |             |        |                   |Providers not at V2.2 of|
+   |             |        |                   |the spec it is          |
+   |             |        |                   |recommended that the    |
+   |             |        |                   |shared flag also be set.|
+   +-------------+--------+-------------------+------------------------+
+   |*Shared      |Boolean |sharedServiceName  |(OPTIONAL) This flag    |
+   |Service Name*|        |                   |indicates that the      |
+   |             |        |                   |template allows the     |
+   |             |        |                   |caller to pass in       |
+   |             |        |                   |additional information  |
+   |             |        |                   |for the serviceName.    |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 39]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   |             |        |                   |This information should |
+   |             |        |                   |augment the display of  |
+   |             |        |                   |the serviceName from the|
+   |             |        |                   |template.  The default  |
+   |             |        |                   |for this is false.      |
+   +-------------+--------+-------------------+------------------------+
+   |*Synchronous |String  |syncPubKeyDomain   |(OPTIONAL) When present,|
+   |Public Key   |        |                   |indicates that calls to |
+   |Domain*      |        |                   |apply a template        |
+   |             |        |                   |synchronously must be   |
+   |             |        |                   |digitally signed.  The  |
+   |             |        |                   |value indicates the     |
+   |             |        |                   |domain name for querying|
+   |             |        |                   |the TXT record from DNS |
+   |             |        |                   |that contains the public|
+   |             |        |                   |key used for signing.   |
+   +-------------+--------+-------------------+------------------------+
+   |*Synchronous |String  |syncRedirectDomain |(OPTIONAL) When present,|
+   |Redirect     |        |                   |this is a comma         |
+   |Domains*     |        |                   |separated list of domain|
+   |             |        |                   |names for which         |
+   |             |        |                   |redirects must be sent  |
+   |             |        |                   |to after applying a     |
+   |             |        |                   |template for the        |
+   |             |        |                   |synchronous flow.       |
+   +-------------+--------+-------------------+------------------------+
+   |*Multiple    |Boolean |multiInstance      |(OPTIONAL) Defaults to  |
+   |Instance*    |        |                   |False.  When set to     |
+   |             |        |                   |True, it indicates that |
+   |             |        |                   |the template may be     |
+   |             |        |                   |applied multiple times. |
+   |             |        |                   |This only impacts DNS   |
+   |             |        |                   |Providers that maintain |
+   |             |        |                   |template state in DNS.  |
+   +-------------+--------+-------------------+------------------------+
+   |*Warn        |Boolean |warnPhishing       |(OPTIONAL) When present,|
+   |Phishing*    |        |                   |this tells the DNS      |
+   |             |        |                   |Provider that the       |
+   |             |        |                   |template may contain    |
+   |             |        |                   |variables susceptible to|
+   |             |        |                   |phishing attacks and the|
+   |             |        |                   |provider is unable to   |
+   |             |        |                   |digitally sign the      |
+   |             |        |                   |requests.  When set the |
+   |             |        |                   |DNS Provider should     |
+   |             |        |                   |display warnings to the |
+   |             |        |                   |user.  The default value|
+   |             |        |                   |for this is false.      |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 40]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   +-------------+--------+-------------------+------------------------+
+   |*Host        |Boolean |hostRequired       |(OPTIONAL) Defaults to  |
+   |Required*    |        |                   |false.  When present    |
+   |             |        |                   |this indicates that the |
+   |             |        |                   |template has been       |
+   |             |        |                   |authored to work only   |
+   |             |        |                   |when both domain and    |
+   |             |        |                   |host are provided.  An  |
+   |             |        |                   |example where this would|
+   |             |        |                   |be true would be a      |
+   |             |        |                   |template where CNAME is |
+   |             |        |                   |set on the fully        |
+   |             |        |                   |qualified domain name.  |
+   |             |        |                   |This is largely         |
+   |             |        |                   |informational, as most  |
+   |             |        |                   |DNS Providers already   |
+   |             |        |                   |enforce such rules.     |
+   +-------------+--------+-------------------+------------------------+
+   |*Template    |Array of|records            |(REQUIRED) A list of    |
+   |Records*     |Template|                   |records for the         |
+   |             |Records |                   |template.               |
+   +-------------+--------+-------------------+------------------------+
 
               Table 13: properties of the template definition
 
-5.3.  Template Record
+8.3.  Template Record
 
    Each template record is an entry that contains a type and several
    other values depending on the type.
@@ -2180,15 +2293,14 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-
-Carney, et al.           Expires 29 October 2022               [Page 39]
+Kowalik, et al.          Expires 23 January 2025               [Page 41]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-   Note: The trailing dot here is similar to the bind protocol, which
+   Note: The trailing dot here is similar to the bind notation, which
    indicates the value is absolute.  Without the trailing ".", the value
-   in this field is relative to the [host.]domain.com value.
+   in this field is relative to the [host.]example.com value.
 
    For the pointsTo/data field it is a shortcut for for the "%fqdn%".
    When appling the template to a domain only, it represents
@@ -2214,183 +2326,226 @@ Internet-Draft               Domain Connect                   April 2022
 
    Each record will contain the following elements.
 
-   +===========+======+=========================+=========================+
-   |Data       |Type  |Key                      |Description              |
-   |Element    |      |                         |                         |
-   +===========+======+=========================+=========================+
-   |*Type*     |enum  |type                     |Describes the type of    |
-   |           |      |                         |record in DNS, or the    |
-   |           |      |                         |operation impacting DNS. |
-   |           |      |                         |Valid values include: A, |
-   |           |      |                         |AAAA, CNAME, MX, TXT,    |
-   |           |      |                         |SRV, or SPFM For each    |
-   |           |      |                         |type, additional fields  |
-   |           |      |                         |would be required.  A:   |
-   |           |      |                         |host, pointsTo, TTL AAAA:|
-   |           |      |                         |host, pointsTo, TTL      |
-   |           |      |                         |CNAME: host, pointsTo,   |
-   |           |      |                         |TTL (host must not be    |
-   |           |      |                         |null or @) NS: host,     |
-   |           |      |                         |pointsTo, TTL (host must |
-   |           |      |                         |not be null or @) TXT:   |
-   |           |      |                         |host, data, TTL,         |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 40]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   |           |      |                         |txtConflictMatchingMode, |
-   |           |      |                         |txtConflictMatchingPrefix|
-   |           |      |                         |MX: host, pointsTo, TTL, |
-   |           |      |                         |priority SRV: name,      |
-   |           |      |                         |target, TTL, priority,   |
-   |           |      |                         |protocol, service,       |
-   |           |      |                         |weight, port SPFM: host, |
-   |           |      |                         |spfRules                 |
-   +-----------+------+-------------------------+-------------------------+
-   |*Group Id* |String|groupId                  |(OPTIONAL) This parameter|
-   |           |      |                         |identifies the group the |
-   |           |      |                         |record belongs to when   |
-   |           |      |                         |applying changes.  This  |
-   |           |      |                         |must not contain         |
-   |           |      |                         |variables.               |
-   +-----------+------+-------------------------+-------------------------+
-   |*Essential*|enum  |essential                |(OPTIONAL) This parameter|
-   |           |      |                         |indicates how the record |
-   |           |      |                         |is treated during        |
-   |           |      |                         |conflict detection with  |
-   |           |      |                         |existing templates.  If  |
-   |           |      |                         |the DNS Provider is not  |
-   |           |      |                         |implementing applied     |
-   |           |      |                         |template state in DNS    |
-   |           |      |                         |this is ignored.  Always |
-   |           |      |                         |(default) - record MUST  |
-   |           |      |                         |be applied and kept with |
-   |           |      |                         |the template OnApply -   |
-   |           |      |                         |record MUST be applied   |
-   |           |      |                         |but can be later removed |
-   |           |      |                         |without dropping the     |
-   |           |      |                         |whole template           |
-   +-----------+------+-------------------------+-------------------------+
-   |*Host*     |String|host                     |The host for A, AAAA,    |
-   |           |      |                         |CNAME, NS, TXT, and MX   |
-   |           |      |                         |values.  This value is   |
-   |           |      |                         |relative to the applied  |
-   |           |      |                         |host and domain, unless  |
-   |           |      |                         |trailed by a ".".  A     |
-   |           |      |                         |value of empty or @      |
-   |           |      |                         |indicates the root of the|
-   |           |      |                         |applied host and domain. |
-   |           |      |                         |In other words           |
-   |           |      |                         |"[host.]domain.com.".    |
-   |           |      |                         |This value should not    |
-   |           |      |                         |contain variables unless |
-   |           |      |                         |absolutely necessary.    |
-   |           |      |                         |This is discussed below. |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 41]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   +-----------+------+-------------------------+-------------------------+
-   |*Name*     |String|name                     |The name for the SRV     |
-   |           |      |                         |record.  This value is   |
-   |           |      |                         |relative to the applied  |
-   |           |      |                         |host and domain.  A value|
-   |           |      |                         |of empty or @ indicates  |
-   |           |      |                         |the root of the applied  |
-   |           |      |                         |host and domain.  This   |
-   |           |      |                         |value should not contain |
-   |           |      |                         |variables unless         |
-   |           |      |                         |absolutely necessary.    |
-   |           |      |                         |This is discussed below. |
-   +-----------+------+-------------------------+-------------------------+
-   |*Points To*|String|pointsTo                 |The pointsTo location for|
-   |           |      |                         |A, AAAA, CNAME, NS and MX|
-   |           |      |                         |records.  A value of     |
-   |           |      |                         |empty or @ indicates the |
-   |           |      |                         |host and domain name     |
-   |           |      |                         |being applied or         |
-   |           |      |                         |[host.]domain.com        |
-   +-----------+------+-------------------------+-------------------------+
-   |*TTL*      |Int   |ttl                      |The time-to-live for the |
-   |           |      |                         |record in DNS.  Valid for|
-   |           |      |                         |A, AAAA, CNAME, NS, TXT, |
-   |           |      |                         |MX, and SRV records.     |
-   |           |      |                         |This must not contain    |
-   |           |      |                         |variables.               |
-   +-----------+------+-------------------------+-------------------------+
-   |*Data*     |String|data                     |The data for a TXT record|
-   |           |      |                         |in DNS.  A value of empty|
-   |           |      |                         |or @ indicates the host  |
-   |           |      |                         |and domain name being    |
-   |           |      |                         |applied or               |
-   |           |      |                         |[host.]domain.com        |
-   +-----------+------+-------------------------+-------------------------+
-   |*TXT       |String|txtConflictMatchingMode  |Describes how conflicts  |
-   |Conflict   |      |                         |on the TXT record are    |
-   |Matching   |      |                         |detected.  Possible      |
-   |Mode*      |      |                         |values are None, All, or |
-   |           |      |                         |Prefix.  The default     |
-   |           |      |                         |value is None.  See below|
-   |           |      |                         |(Section 6.3).           |
-   +-----------+------+-------------------------+-------------------------+
-   |*TXT       |String|txtConflictMatchingPrefix|The prefix to detect     |
-   |Conflict   |      |                         |conflicts when           |
-   |Matching   |      |                         |txtConflictMatchingMode  |
-   |Prefix*    |      |                         |is "Prefix".  This must  |
-   |           |      |                         |not contain variables.   |
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 42]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   |           |      |                         |See below (Section 6.3). |
-   +-----------+------+-------------------------+-------------------------+
-   |*Priority* |Int   |priority                 |The priority for an MX or|
-   |           |      |                         |SRV record.  This must   |
-   |           |      |                         |not contain variables.   |
-   +-----------+------+-------------------------+-------------------------+
-   |*Weight*   |Int   |weight                   |The weight for the SRV   |
-   |           |      |                         |record.  This must not   |
-   |           |      |                         |contain variables.       |
-   +-----------+------+-------------------------+-------------------------+
-   |*Port*     |Int   |port                     |The port for the SRV     |
-   |           |      |                         |record.  This must not   |
-   |           |      |                         |contain variables.       |
-   +-----------+------+-------------------------+-------------------------+
-   |*Protocol* |String|protocol                 |The protocol for the SRV |
-   |           |      |                         |record.                  |
-   +-----------+------+-------------------------+-------------------------+
-   |*Service*  |String|service                  |The symbolic name for the|
-   |           |      |                         |SRV record.              |
-   +-----------+------+-------------------------+-------------------------+
-   |*Target*   |String|target                   |The target for the SRV   |
-   |           |      |                         |record.                  |
-   +-----------+------+-------------------------+-------------------------+
-   |*SPF Rules*|String|spfRules                 |These are desired rules  |
-   |           |      |                         |for the SPF TXT record.  |
-   |           |      |                         |These rules will be      |
-   |           |      |                         |merged with other SPFM   |
-   |           |      |                         |records into final SPF   |
-   |           |      |                         |TXT record.  See         |
-   |           |      |                         |Section 6.10.            |
-   +-----------+------+-------------------------+-------------------------+
+   +===========+======+=========================+======================+
+   |Data       |Type  |Key                      |Description           |
+   |Element    |      |                         |                      |
+   +===========+======+=========================+======================+
+   |*Type*     |enum  |type                     |(REQUIRED) Describes  |
+   |           |      |                         |the type of record in |
+   |           |      |                         |DNS, or the operation |
+   |           |      |                         |impacting DNS.        |
+   |           |      |                         |Valid values include: |
+   |           |      |                         |A, AAAA, CNAME, MX,   |
+   |           |      |                         |TXT, SRV, or SPFM     |
+   |           |      |                         |For each type,        |
+   |           |      |                         |additional fields     |
+   |           |      |                         |would be REQUIRED.    |
+   |           |      |                         |* A: host, pointsTo,  |
+   |           |      |                         |TTL                   |
+   |           |      |                         |* AAAA: host,         |
+   |           |      |                         |pointsTo, TTL         |
+   |           |      |                         |* CNAME: host,        |
+   |           |      |                         |pointsTo, TTL (host   |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 42]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   |           |      |                         |must not be null or @ |
+   |           |      |                         |unless hostRequired is|
+   |           |      |                         |defined true for the  |
+   |           |      |                         |template)             |
+   |           |      |                         |* NS: host, pointsTo, |
+   |           |      |                         |TTL (host must not be |
+   |           |      |                         |null or @ unless      |
+   |           |      |                         |hostRequired is       |
+   |           |      |                         |defined true for the  |
+   |           |      |                         |template)             |
+   |           |      |                         |* TXT: host, data,    |
+   |           |      |                         |TTL, txtConflict-     |
+   |           |      |                         |MatchingMode,         |
+   |           |      |                         |txtConflict-          |
+   |           |      |                         |MatchingPrefix        |
+   |           |      |                         |* MX: host, pointsTo, |
+   |           |      |                         |TTL, priority         |
+   |           |      |                         |* SRV: name, target,  |
+   |           |      |                         |TTL, priority,        |
+   |           |      |                         |protocol, service,    |
+   |           |      |                         |weight, port          |
+   |           |      |                         |* SPFM: host, spfRules|
+   +-----------+------+-------------------------+----------------------+
+   |*Group Id* |String|groupId                  |(OPTIONAL) This       |
+   |           |      |                         |parameter identifies  |
+   |           |      |                         |the group the record  |
+   |           |      |                         |belongs to when       |
+   |           |      |                         |applying changes.     |
+   |           |      |                         |This must not contain |
+   |           |      |                         |variables.            |
+   +-----------+------+-------------------------+----------------------+
+   |*Essential*|enum  |essential                |(OPTIONAL) This       |
+   |           |      |                         |parameter indicates   |
+   |           |      |                         |how the record is     |
+   |           |      |                         |treated during        |
+   |           |      |                         |conflict detection    |
+   |           |      |                         |with existing         |
+   |           |      |                         |templates.            |
+   |           |      |                         |If the DNS Provider is|
+   |           |      |                         |not implementing      |
+   |           |      |                         |applied template state|
+   |           |      |                         |in DNS this is        |
+   |           |      |                         |ignored.              |
+   |           |      |                         |Always (default) -    |
+   |           |      |                         |record MUST be applied|
+   |           |      |                         |and kept with the     |
+   |           |      |                         |template              |
+   |           |      |                         |OnApply - record MUST |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 43]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   |           |      |                         |be applied but can be |
+   |           |      |                         |later removed without |
+   |           |      |                         |dropping the whole    |
+   |           |      |                         |template              |
+   +-----------+------+-------------------------+----------------------+
+   |*Host*     |String|host                     |(REQUIRED) The host   |
+   |           |      |                         |for A, AAAA, CNAME,   |
+   |           |      |                         |NS, TXT, and MX       |
+   |           |      |                         |values.               |
+   |           |      |                         |This value is relative|
+   |           |      |                         |to the applied host   |
+   |           |      |                         |and domain, unless    |
+   |           |      |                         |trailed by a ".".     |
+   |           |      |                         |A value of empty or @ |
+   |           |      |                         |indicates the root of |
+   |           |      |                         |the applied host and  |
+   |           |      |                         |domain.  In other     |
+   |           |      |                         |words                 |
+   |           |      |                         |"[host.]example.com.".|
+   |           |      |                         |This value should not |
+   |           |      |                         |contain variables     |
+   |           |      |                         |unless absolutely     |
+   |           |      |                         |necessary.  This is   |
+   |           |      |                         |discussed below.      |
+   +-----------+------+-------------------------+----------------------+
+   |*Name*     |String|name                     |The name for the SRV  |
+   |           |      |                         |record.               |
+   |           |      |                         |This value is relative|
+   |           |      |                         |to the applied host   |
+   |           |      |                         |and domain.  A value  |
+   |           |      |                         |of empty or @         |
+   |           |      |                         |indicates the root of |
+   |           |      |                         |the applied host and  |
+   |           |      |                         |domain.               |
+   |           |      |                         |This value should not |
+   |           |      |                         |contain variables     |
+   |           |      |                         |unless absolutely     |
+   |           |      |                         |necessary.  This is   |
+   |           |      |                         |discussed below.      |
+   +-----------+------+-------------------------+----------------------+
+   |*Points To*|String|pointsTo                 |The pointsTo location |
+   |           |      |                         |for A, AAAA, CNAME, NS|
+   |           |      |                         |and MX records.       |
+   |           |      |                         |A value of empty or @ |
+   |           |      |                         |indicates the host and|
+   |           |      |                         |domain name being     |
+   |           |      |                         |applied or            |
+   |           |      |                         |[host.]example.com    |
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 44]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   +-----------+------+-------------------------+----------------------+
+   |*TTL*      |Int   |ttl                      |The time-to-live for  |
+   |           |      |                         |the record in DNS.    |
+   |           |      |                         |Valid for A, AAAA,    |
+   |           |      |                         |CNAME, NS, TXT, MX,   |
+   |           |      |                         |and SRV records.  This|
+   |           |      |                         |must not contain      |
+   |           |      |                         |variables.            |
+   +-----------+------+-------------------------+----------------------+
+   |*Data*     |String|data                     |The data for a TXT    |
+   |           |      |                         |record in DNS.  A     |
+   |           |      |                         |value of empty or @   |
+   |           |      |                         |indicates the host and|
+   |           |      |                         |domain name being     |
+   |           |      |                         |applied or            |
+   |           |      |                         |[host.]example.com    |
+   +-----------+------+-------------------------+----------------------+
+   |*TXT       |String|txtConflictMatchingMode  |Describes how         |
+   |Conflict   |      |                         |conflicts on the TXT  |
+   |Matching   |      |                         |record are detected.  |
+   |Mode*      |      |                         |Possible values are   |
+   |           |      |                         |None, All, or Prefix. |
+   |           |      |                         |The default value is  |
+   |           |      |                         |None.  See below      |
+   |           |      |                         |(Section 9.3).        |
+   +-----------+------+-------------------------+----------------------+
+   |*TXT       |String|txtConflictMatchingPrefix|The prefix to detect  |
+   |Conflict   |      |                         |conflicts when        |
+   |Matching   |      |                         |txtConflict-          |
+   |Prefix*    |      |                         |MatchingMode is       |
+   |           |      |                         |"Prefix".  This must  |
+   |           |      |                         |not contain variables.|
+   |           |      |                         |See below             |
+   |           |      |                         |(Section 9.3).        |
+   +-----------+------+-------------------------+----------------------+
+   |*Priority* |Int   |priority                 |The priority for an MX|
+   |           |      |                         |or SRV record.  This  |
+   |           |      |                         |must not contain      |
+   |           |      |                         |variables.            |
+   +-----------+------+-------------------------+----------------------+
+   |*Weight*   |Int   |weight                   |The weight for the SRV|
+   |           |      |                         |record.  This must not|
+   |           |      |                         |contain variables.    |
+   +-----------+------+-------------------------+----------------------+
+   |*Port*     |Int   |port                     |The port for the SRV  |
+   |           |      |                         |record.  This must not|
+   |           |      |                         |contain variables.    |
+   +-----------+------+-------------------------+----------------------+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 45]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   |*Protocol* |String|protocol                 |The protocol for the  |
+   |           |      |                         |SRV record.           |
+   +-----------+------+-------------------------+----------------------+
+   |*Service*  |String|service                  |The symbolic name for |
+   |           |      |                         |the SRV record.       |
+   +-----------+------+-------------------------+----------------------+
+   |*Target*   |String|target                   |The target for the SRV|
+   |           |      |                         |record.               |
+   +-----------+------+-------------------------+----------------------+
+   |*SPF Rules*|String|spfRules                 |These are desired     |
+   |           |      |                         |rules for the SPF TXT |
+   |           |      |                         |record.  These rules  |
+   |           |      |                         |will be merged with   |
+   |           |      |                         |other SPFM records    |
+   |           |      |                         |into final SPF TXT    |
+   |           |      |                         |record.  See          |
+   |           |      |                         |Section 9.10.         |
+   +-----------+------+-------------------------+----------------------+
 
            Table 14: properties of the template record definition
 
-6.  Template Considerations
+9.  Template Considerations
 
-6.1.  Template State in DNS
+9.1.  Template State in DNS
 
    DNS Providers may chose to maintain state inside records in DNS
    indicating the templates writing the records.  Other providers may
@@ -2403,14 +2558,7 @@ Internet-Draft               Domain Connect                   April 2022
    To make the implementation burden reasonable for DNS Providers,
    Domain Connect does not dictate the approach.
 
-
-
-Carney, et al.           Expires 29 October 2022               [Page 43]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-6.2.  Disclosure of Changes and Conflicts
+9.2.  Disclosure of Changes and Conflicts
 
    It is left to the discretion of the DNS Provider to determine what is
    disclosed to the user when granting permission and/or applying
@@ -2422,6 +2570,14 @@ Internet-Draft               Domain Connect                   April 2022
    to display the records being set.  And another may progressively
    display both.
 
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 46]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    For conflict detection, one DNS Provider may simply overwrite changed
    records without warning.  Another may detect conflicts and warn the
    user of the records that will change.  And another may implement
@@ -2458,14 +2614,6 @@ Internet-Draft               Domain Connect                   April 2022
 
    A reasonable set of recommendations for the UX might consist of:
 
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 44]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    *  The consent UX should inform the customer of the service that will
       be enabled.  If the customer want to know the specifics, the DNS
       Provider could provide a "show details" link to the user.  This
@@ -2478,7 +2626,15 @@ Internet-Draft               Domain Connect                   April 2022
       records, this would be records that would be deleted or
       overwritten.  This could be progressively disclosed.
 
-6.3.  Record Types and Conflicts
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 47]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+9.3.  Record Types and Conflicts
 
    Conflict detection done by the DNS provider prior to template
    application has to take into consideration specifics of each DNS
@@ -2513,16 +2669,9 @@ Internet-Draft               Domain Connect                   April 2022
          other TXT record
 
       -  Prefix: This indicates that TXT record conflict with any other
-         TXT containing value starting with txtConfictMatchingPrefix
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 45]
-
-Internet-Draft               Domain Connect                   April 2022
+         TXT containing value starting with txtConflictMatchingPrefix
 
-
-6.4.  Apply, Re-apply, and Multi-Instance
+9.4.  Apply, Re-apply, and Multi-Instance
 
    There is an additional consideration for DNS Providers that maintain
    the state of an applied template when re-applying a template.
@@ -2531,9 +2680,19 @@ Internet-Draft               Domain Connect                   April 2022
    when re-applying a template such a DNS Provider should remove the
    previously applied template on the same host.
 
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 48]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    This may not be desireable for all templates, as a limited set of
    templates are designed to be applied multiple times.  To faciliate
-   this the template can have the flag multiInstance (Section 5.2) set.
+   this the template can have the flag multiInstance (Section 8.2) set.
    This tells the DNS Provider that the template is expected to be
    written multiple times and that a re-apply must not remove previous
    instances.
@@ -2543,7 +2702,7 @@ Internet-Draft               Domain Connect                   April 2022
    state must rely on the normal conflict resolution rules, and this
    flag has no impact.
 
-6.5.  Non-essential records
+9.5.  Non-essential records
 
    Typically a template specifies a list of DNS records which are
    required for the service.  There may be cases where some records are
@@ -2552,60 +2711,55 @@ Internet-Draft               Domain Connect                   April 2022
    application of another template) should not trigger conflict
    detection.
 
-   This can be controlled by the essential (Section 5.3) property of a
+   This can be controlled by the essential (Section 8.3) property of a
    record in the template.
 
    Again, this setting only impacts DNS Providers that maintain applied
    template state.
 
-6.6.  Template Scope
+9.6.  Template Scope
 
    For DNS Providers that maintain template state, an individual
    template is scoped to the set of records applied to a fully qualified
    domain.  This includes the root domain and the host (aka sub-domain)
    at apply time.
 
+   As an example, if a template is applied on domain=example.com=sub1 a
+   later application of the template on domain=example.com=sub2 must be
+   treated as a distinct template.  If a conflict is detected later with
+   the records set into "sub2.example.com", only the records set with
+   this template would be removed.
 
+9.7.  Host/Name in Template
 
+   Template records contain the host name of the record to set into the
+   zone (called name for SRV records).  This value must be considered
+   relative to the domain/host when the template is applied, unless
+   followed by a trailing ".".
 
 
 
 
 
-
-Carney, et al.           Expires 29 October 2022               [Page 46]
+Kowalik, et al.          Expires 23 January 2025               [Page 49]
 
-Internet-Draft               Domain Connect                   April 2022
-
+Internet-Draft               Domain Connect                    July 2024
 
-   As an example, if a template is applied on
-   domain=example.com&host=sub1 a later application of the template on
-   domain=example.com&host=sub2 must be treated as a distinct template.
-   If a conflict is detected later with the records set into
-   "sub2.example.com", only the records set with this template would be
-   removed.
-
-6.7.  Host/Name in Template
-
-   Template records contain the host name of the record to set into the
-   zone (called name for SRV records).  This value must be considered
-   relative to the domain/host when the template is applied, unless
-   followed by a trailing ".".
 
    Consider a template record of type A with a host value of "xyz".
-   When the template is applied to a domain=foo.com and an empty host
-   value, the resulting zone after the template is applied will contain
-   an A record of "xyz" (or "xyz.foo.com." in bind format).
+   When the template is applied to a domain=example.com and an empty
+   host value, the resulting zone after the template is applied will
+   contain an A record of "xyz" (or "xyz.example.com." in bind format).
 
-   If the same template is applied to a domain=foo.com and host=bar, the
-   zone will contain an A record of "xyz.bar" (or "xyz.bar.foo.com." in
-   bind format).
+   If the same template is applied to a domain=example.com and host=bar,
+   the zone will contain an A record of "xyz.bar" (or
+   "xyz.bar.example.com." in bind format).
 
    A value of @ for host in the template is a placeholder for an empty
-   value.  In other words @ would point to "bar.foo.com." when the same
-   template is applied to domain=foo.com and host=bar.
+   value.  In other words @ would point to "bar.example.com." when the
+   same template is applied to domain=example.com and host=bar.
 
-6.8.  PointsTo in Template
+9.8.  PointsTo in Template
 
    Template records of certain types contain the pointsTo value to set
    in the zone.  For record types such as CNAME where this can be a
@@ -2615,42 +2769,43 @@ Internet-Draft               Domain Connect                   April 2022
    fully qualified domain name of the domain/host being applied.
 
    Consider a template record of type CNAME with a pointsTo value of
-   "@".  After a template of domain=foo.com and an empty host is
+   "@".  After a template of domain=example.com and an empty host is
    applied, the pointsTo value (or corresponding field) in the resulting
-   zone would be "foo.com".  After a template of domain=foo.com with
-   host=bar is applied, the points to value would be "bar.foo.com".
+   zone would be "example.com".  After a template of domain=example.com
+   with host=bar is applied, the points to value would be
+   "bar.example.com".
 
    Any domain in a pointsTo field in a template must be considered fully
    qualified and not relative.
 
+9.9.  Variables
 
+9.9.1.  Variables and Host/Name in Template
 
+   While templates do allow for variables in a host or name field
+   values, these should be used very sparingly.
 
+   As an example, consider setting up hosting for a site.  But instead
+   of applying the template to a domain/host, the name of the host is
+   placed as a variable in the template.
 
+   Such a template might contain an A record of the form:
 
 
-Carney, et al.           Expires 29 October 2022               [Page 47]
-
-Internet-Draft               Domain Connect                   April 2022
 
 
-6.9.  Variables
 
-6.9.1.  Variables and Host/Name in Template
 
-   While templates do allow for variables in a host or name field
-   values, these should be used very sparingly.
 
-   As an example, consider setting up hosting for a site.  But instead
-   of applying the template to a domain/host, the name of the host is
-   placed as a variable in the template.
+Kowalik, et al.          Expires 23 January 2025               [Page 50]
+
+Internet-Draft               Domain Connect                    July 2024
 
-   Such a template might contain an A record of the form:
 
    {
        "type": "A",
        "host": "%var%",
-       "pointsTo": "2.2.2.2",
+       "pointsTo": "192.0.2.2",
        "ttl": 1800
    }
 
@@ -2665,10 +2820,10 @@ Internet-Draft               Domain Connect                   April 2022
    providers that maintain template state would remove previous
    instances of the template before re-application.  This means applying
    this template with var=sub would result in the A record for
-   sub.example.com to be set to the value 2.2.2.2.  Later, applying the
-   template on "example.com" with the var=sub2 should remove the old
+   sub.example.com to be set to the value 192.0.2.2.  Later, applying
+   the template on "example.com" with the var=sub2 should remove the old
    template before setting the new one. sub.example.com would be
-   removed, and sub2.example.com would be set to the value 2.2.2.2.
+   removed, and sub2.example.com would be set to the value 192.0.2.2.
 
    Furthermore, determining conflicts would be impossible when the user
    is granting consent for asynchronous operations (OAuth).  This is
@@ -2680,16 +2835,6 @@ Internet-Draft               Domain Connect                   April 2022
    specific host values, whose value is later specified when applying
    the template.
 
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 48]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    Note: There are some templates that utilize CNAME or TXT records with
    host values containing some form of user identification for
    validation of domain ownership, and these are often passed in
@@ -2698,19 +2843,26 @@ Internet-Draft               Domain Connect                   April 2022
    To support this use case, variables are allowed for the host name.
    But only in this limited circumstance.
 
-6.9.2.  Variable Values
+9.9.2.  Variable Values
 
    To allow for the use of the host name or domain name in templates,
    the values of %host% and %domain% are available.  A third value of
    %fqdn% is also available.  This value is the result of combining the
    host and domain name with the necessary ".".
 
-   For example, with the query string "domain=example.com&host=", %fqdn%
-   in a template would be "example.com", and with
-   "domain=example.com&host=sub1", %fqdn% in a template would be
-   "sub1.example.com".
 
-6.9.3.  Variables and Security
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 51]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+   For example, with the query string "domain=example.com=", %fqdn% in a
+   template would be "example.com", and with "domain=example.com=sub1",
+   %fqdn% in a template would be "sub1.example.com".
+
+9.9.3.  Variables and Security
 
    As discussed, with variables consideration is necessary to prevent
    certain styles of phishing attacks.
@@ -2721,7 +2873,7 @@ Internet-Draft               Domain Connect                   April 2022
 
    Mitigations to this are discussed above.
 
-6.9.4.  Variable Examples
+9.9.4.  Variable Examples
 
    Example template:
 
@@ -2734,42 +2886,42 @@ Internet-Draft               Domain Connect                   April 2022
    {
        "type": "A",
        "host": "@",
-       "pointsTo": "1.1.1.1",
+       "pointsTo": "192.0.2.1",
        "ttl": 1800
    }]
 
+   Template applied with _domain_=example.com and _host_ parameter
+   missing or empty:
 
+   www 1800 IN CNAME example.com.
+   @   1800 IN A 192.0.2.1
 
+   _alternatively_
 
-Carney, et al.           Expires 29 October 2022               [Page 49]
-
-Internet-Draft               Domain Connect                   April 2022
+   www.example.com.    1800 IN CNAME example.com.
+   example.com.        1800 IN A 192.0.2.1
 
+   Template applied with _domain_=example.com and _host_=bar:
 
-   Template applied with _domain_=foo.com and _host_ parameter missing
-   or empty:
+   www.bar 1800 IN CNAME bar.example.com.
+   bar     1800 IN A 192.0.2.1
 
-   www 1800 IN CNAME foo.com.
-   @   1800 IN A 1.1.1.1
 
-   _alternatively_
 
-   www.foo.com.    1800 IN CNAME foo.com.
-   foo.com.        1800 IN A 1.1.1.1
 
-   Template applied with _domain_=foo.com and _host_=bar:
+Kowalik, et al.          Expires 23 January 2025               [Page 52]
+
+Internet-Draft               Domain Connect                    July 2024
 
-   www.bar 1800 IN CNAME bar.foo.com.
-   bar     1800 IN A 1.1.1.1
 
    _alternatively_
 
-   www.bar.foo.com.    1800 IN CNAME bar.foo.com.
-   bar.foo.com.        1800 IN A 1.1.1.1
+   www.bar.example.com.    1800 IN CNAME bar.example.com.
+   bar.example.com.        1800 IN A 192.0.2.1
 
-6.10.  SPF TXT Record
+9.10.  SPF TXT Record
 
-6.10.1.  What is SPF?
+9.10.1.  What is SPF?
 
    SPF stands for Sender Policy Framework specified in [RFC7208].  It is
    a record that specifies a list of authorized host names and/or IP
@@ -2780,11 +2932,11 @@ Internet-Draft               Domain Connect                   April 2022
    a rule passes, the mail is allowed.  If it fails, it moves to the
    next rule.  Typical record might appear as:
 
-   v=spf1 include:policy.exampleprovider.com -all
+   v=spf1 include:policy.exampleprovider.example -all
 
    This is an SPF record with two rules.  The first rule indicates that
-   the rules for SPF record _policy.exampleprovider.com be included in
-   this record.  The second rule is a catch all (_all_).  The default
+   the rules for SPF record _policy.exampleprovider.example be included
+   in this record.  The second rule is a catch all (_all_).  The default
    modifier for a rule is _pass_ (+).  Other modifiers are _hard
    failure_(-), _soft failure_ (~) and _neutral_ (?).
 
@@ -2793,21 +2945,12 @@ Internet-Draft               Domain Connect                   April 2022
    classified with _hard failure_ or _soft failure_ may not be delivered
    or marked as spam.
 
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 50]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    The use of "all" at the end is pretty common, although some providers
    mark it as ~ (soft fail) or ? (neutral).  The reality is that a good
    SPF record is tuned based on what services are attached to a domain.
    Not just one individual service.
 
-6.10.2.  Multiple Services
+9.10.2.  Multiple Services
 
    If only one email sending service were active, the SPF record
    recommended by the provider is sufficient.  But mail from a domain
@@ -2817,8 +2960,15 @@ Internet-Draft               Domain Connect                   April 2022
    newsletter service.  Let's look at the SPF records recommended for
    individual services.
 
-   Mailer1: v=spf1 include:spf.mailer1.com -all Newsletter1: v=spf1
-   include:_spf.newsletter.net ~all
+   Mailer1: v=spf1 include:spf.mailer1.example -all Newsletter1: v=spf1
+   include:_spf.newsletter.example ~all
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 53]
+
+Internet-Draft               Domain Connect                    July 2024
+
 
    All of these examples use the include syntax.  This is fairly common.
    The use of all at the end is common, although is often inconsistent
@@ -2827,12 +2977,13 @@ Internet-Draft               Domain Connect                   April 2022
    If a customer installed Mailer1 and Newsletter1, their combined SPF
    record ought to be something like:
 
-   v=spf1 include:spf.mailer1.com include:_spf.newsletter.net ~all
+   v=spf1 include:spf.mailer1.example include:_spf.newsletter.example
+    ~all
 
    We combined the two rules, and in this case picked the least
    restrictive all modifier.
 
-6.10.3.  SPF Record Merging
+9.10.3.  SPF Record Merging
 
    The challenge with SPF records and Domain Connect is that an
    individual service might recommend an SPF record.  If only one
@@ -2851,20 +3002,14 @@ Internet-Draft               Domain Connect                   April 2022
    on the other side does not reject the message in case forwarding
    facility is in place.
 
-
-
-Carney, et al.           Expires 29 October 2022               [Page 51]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
-   @ TXT v=spf1 include:spf.mailer1.com include:_spf.newsletter.net ~all
+   @ TXT v=spf1 include:spf.mailer1.example include:_spf.newsletter.exam
+   ple ~all
 
    The other would be to write intermediate records, and reference these
    locally.
 
-   r1.example.com. TXT v=spf1 include:spf.mailer1.com ~all
-   r2.example.com. TXT v=spf1 include:_spf.newsletter.net ~all
+   r1.example.com. TXT v=spf1 include:spf.mailer1.example ~all
+   r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
    @ TXT v=spf1 include:r1.example.com include:r2.example.com ~all
 
    There are advantages and disadvantages to both approaches.  SPF
@@ -2872,6 +3017,15 @@ Internet-Draft               Domain Connect                   April 2022
    to 255 characters.  So depending on the embedded records both
    approaches might have advantages.
 
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 54]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
    The implementation would be left to the DNS Provider, but to
    facilitate this SPF records must NOT be included in templates.
    Instead, we introduce a new pseudo-record type in the template called
@@ -2879,7 +3033,7 @@ Internet-Draft               Domain Connect                   April 2022
 
    spfRules  Determines the desired rules, basically everything but
       leading "v=spf1" and trailing _all_ rule - see: SPF Rules
-      (Section 5.3)
+      (Section 8.3)
 
    When a template is added or removed with an _SPFM_ record in the
    template, some code would need to take the aggregate value of all
@@ -2894,7 +3048,7 @@ Internet-Draft               Domain Connect                   April 2022
    after merging.
 
    Due to merging step in between, the resulting SPF TXT records are
-   considered non-essential (see: Section 6.5).  That means the user may
+   considered non-essential (see: Section 9.5).  That means the user may
    decide to override the final calculated value or remove the whole SPF
    record.  This action must not lead to removal of any related
    templates in conflict detection and template integrity routines if
@@ -2907,20 +3061,28 @@ Internet-Draft               Domain Connect                   April 2022
    in the Asynchronous flow unless the _force=true_ parameter is used,
    effectively removing the existing record.
 
-
-
-Carney, et al.           Expires 29 October 2022               [Page 52]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    Service providers should avoid exact match checking content of TXT
    SPF record, as it might be strongly influenced by the DNS Provider
    merging strategy and user actions.
 
    See Appendix A.5.
 
-6.10.4.  Alternatives
+
+
+
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 55]
+
+Internet-Draft               Domain Connect                    July 2024
+
+
+9.10.4.  Alternatives
 
    Some DNS Providers may decide not to support the SPFM record.  The
    following alternative solution should allow general interoperability
@@ -2930,13 +3092,15 @@ Internet-Draft               Domain Connect                   April 2022
    _essential=OnApply_ set to avoid removal of the whole template by a
    conflict.
 
-6.11.  Public Template Repository
+9.11.  Public Template Repository
+
+9.11.1.  General information
 
    The Public Template Repository is an open accessible location where
    Service Providers MAY publish their Service Templates in the format
    specified in this specification.  DNS Providers MAY support all of
    the published templates, just a subset or none of them according to
-   own onboarding policies (see also: Section 7.1).
+   own onboarding policies (see also: Section 10.1).
 
    The template format is intended largely for documentation and
    communication between the DNS Providers and Service Providers, and
@@ -2948,12 +3112,12 @@ Internet-Draft               Domain Connect                   April 2022
    format, it is believed it will make it easier for Service Providers
    to share their configuration across DNS Providers.
 
-6.11.1.  Repository Location
+9.11.2.  Repository Location
 
    The repository of the templates is maintained under
    https://github.com/Domain-Connect/templates.
 
-6.11.2.  File naming requirements
+9.11.3.  File naming requirements
 
    The file names in this repository MUST be all lower case, including
    the providerId and serviceId.  As a result, while the providerId and
@@ -2965,17 +3129,21 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 53]
+
+
+
+
+Kowalik, et al.          Expires 23 January 2025               [Page 56]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-   providerId: Acme.com
+   providerId: example.com
    serviceId: WebsiteBuilder
 
-   Template file name: acme.com.websitebuilder.json
+   Template file name: example.com.websitebuilder.json
 
-6.11.3.  Template Integrity
+9.11.4.  Template Integrity
 
    Implementers are responsible for data integrity and should use the
    record type field to validate that variable input meets the criteria
@@ -2987,9 +3155,9 @@ Internet-Draft               Domain Connect                   April 2022
    mail.) or internal names that provide critical functionality that is
    outside the scope of this specification.
 
-7.  General considerations
+10.  General considerations
 
-7.1.  Onboarding
+10.1.  Onboarding
 
    This specification is an open standard that describes the protocol,
    messages and formats used to enable Domain Connect between a Service
@@ -3008,7 +3176,7 @@ Internet-Draft               Domain Connect                   April 2022
    between unique DNS Providers.  The DNS providerId is typically a
    domain name.
 
-7.2.  Case Sensitivity
+10.2.  Case Sensitivity
 
    All values are case sensitive.  This includes variable names, values,
    parameters and objects returned.
@@ -3021,31 +3189,33 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 54]
+Kowalik, et al.          Expires 23 January 2025               [Page 57]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
    The values for providerId/serviceId in the template and passed
    through URIs in the path or query string are case sensitive.
    Different rules apply to the file naming in the Public Template
-   Repository (Section 6.11.2).
+   Repository (Section 9.11.3).
+
+11.  Extensions/Exclusions
 
-8.  Extensions/Exclusions
+11.1.  General information
 
    Additional record types and/or extensions to records in the template
    can be implemented on a per DNS Provider basis.  However, care should
    be taken when defining extensions so as to not conflict with other
    protocols and standards.  Certain record names are reserved for use
-   in DNS for protocols like DNSSEC (DNSKEY, RRSIG) at the registry
-   level.
+   in DNS for protocols like DNSSEC (DNSKEY, RRSIG) [RFC9364] at the
+   registry level.
 
    Defining these OPTIONAL extensions in an open manner as part of this
    specification is done to provide consistency.  The following are the
    initial OPTIONAL extensions a DNS Provider/Service Provider may
    support.
 
-8.1.  APEXCNAME
+11.2.  APEXCNAME
 
    Some Service Providers desire the behavior of a CNAME record, but in
    the apex record.  This would allow for an A Record at the root of the
@@ -3060,7 +3230,7 @@ Internet-Draft               Domain Connect                   April 2022
    functionality, using the same record type name across DNS Providers
    allows template reuse.
 
-8.2.  Redirection
+11.3.  Redirection
 
    Some Service Providers desire a redirection service associated with
    the A Record.  A typical example is a service that requires a
@@ -3075,11 +3245,9 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-
-
-Carney, et al.           Expires 29 October 2022               [Page 55]
+Kowalik, et al.          Expires 23 January 2025               [Page 58]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
    While technically not a "record" in DNS, when supporting this
@@ -3090,7 +3258,7 @@ Internet-Draft               Domain Connect                   April 2022
    respectively.  Associated with this record would be a single field
    called the "target", containing the target url of the redirect.
 
-8.3.  Nameservers
+11.4.  Nameservers
 
    Several service providers have asked for functionality supporting an
    update to the nameserver records at the registry associated with the
@@ -3105,7 +3273,7 @@ Internet-Draft               Domain Connect                   April 2022
    This functionality is again deemed as OPTIONAL and up to the DNS
    Provider to determine if they will support this.
 
-8.4.  DS (DNSSEC)
+11.5.  DS (DNSSEC)
 
    Requests have been made to allow for updates to the DS record for
    DNSSEC.  This record is required at the registry to enable DNSSEC,
@@ -3115,34 +3283,30 @@ Internet-Draft               Domain Connect                   April 2022
    DS.  Values will be keyTag, algorithm, digestType, and digest.
 
    Again it should be noted that a DS update would require that the DNS
-   Provider is the registrar, and is again deemed as OPTIONAL and up to
+   Provider is the registrar, and is again deemed as optional and up to
    the DNS Provider to determine if they will support.
 
-9.  IANA Considerations
+12.  IANA Considerations
 
-   TODO
+   None.
 
-10.  Acknowledgments
+13.  Change History
 
-   The authors wish to thank the following persons for their feedback
-   and suggestions:
+13.1.  Change from 03 to 04
 
-   *  Chris Ambler of GoDaddy Inc.
+   Version synchronized with 2.2 version rev. 66 of the public Domain
+   Connect specification.
 
-   *  Jody Kolker of GoDaddy Inc.
+                                  Figure 5
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 56]
+Kowalik, et al.          Expires 23 January 2025               [Page 59]
 
-Internet-Draft               Domain Connect                   April 2022
-
+Internet-Draft               Domain Connect                    July 2024
 
-11.  Change History
 
-11.1.  Change from 03 to 04
-
-11.2.  Change from 02 to 03
+13.2.  Change from 02 to 03
 
    Added width/height JSON values returned by DNS Provider Discovery.
    Corrected text of GET method for getting the authorization token.
@@ -3151,48 +3315,56 @@ Internet-Draft               Domain Connect                   April 2022
    that were found during implementation, especially in the
    Implementation Considerations section.
 
-                                  Figure 5
+                                  Figure 6
 
-11.3.  Change from 01 to 02
+13.3.  Change from 01 to 02
 
    Added new GET method for Service Providers to determine if the DNS
    Provider supports a specific template.  Some other minor edits for
    clarification.
 
-                                  Figure 6
+                                  Figure 7
 
-11.4.  Change from 00 to 01
+13.4.  Change from 00 to 01
 
    Minor edits and clarifications found during implementation.
 
-                                  Figure 7
+                                  Figure 8
 
-12.  Normative References
+14.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, RFC 2119,
-              DOI 10.17487/RFC2119, March 1997,
+              Requirement Levels", IETF, DOI 10.17487/RFC2119, BCP 14,
+              RFC 2119, March 1997,
               .
 
-13.  Informative References
-
-   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
-              2119 Key Words", RFC 8174, RFC 8174, DOI 10.17487/RFC8174,
-              May 2017, .
-
    [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
-              Authorizing Use of Domains in Email, Version 1", RFC 7208,
-              RFC 7208, DOI 10.17487/RFC7208, April 2014,
+              Authorizing Use of Domains in Email, Version 1", IETF,
+              DOI 10.17487/RFC7208, RFC 7208, April 2014,
               .
 
+   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", IETF,
+              DOI 10.17487/RFC6749, RFC 6749, October 2012,
+              .
 
+15.  Informative References
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", IETF, DOI 10.17487/RFC8174, BCP 14,
+              RFC 8174, May 2017,
+              .
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 57]
+
+Kowalik, et al.          Expires 23 January 2025               [Page 60]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
+
 
+   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", IETF,
+              DOI 10.17487/RFC9364, BCP 237, RFC 9364, February 2023,
+              .
 
 Appendix A.  Examples
 
@@ -3205,36 +3377,35 @@ A.1.  Example Template
        "serviceName": "Wordpress by example.com",
        "version": 1,
        "logoUrl": "https://www.example.com/images/billthecat.jpg",
-       "description": "This connects your domain to our super cool web hosting",
-       "launchURL" : "https://www.example.com/connectlaunch",
+       "description": "This connects your domain to our web hosting",
        "records": [
            {
-               "groupId" : "service",
                "type": "A",
+               "groupId": "service",
                "host": "www",
                "pointsTo": "%var1%",
-               "ttl": "%var2%"
+               "ttl": 600
            },
            {
-               "groupId" : "service",
                "type": "A",
+               "groupId": "service",
                "host": "m",
-               "pointsTo": "%var3%",
-               "ttl": "%var2%"
+               "pointsTo": "%var2%",
+               "ttl": 600
            },
            {
-               "groupId" : "service",
                "type": "CNAME",
+               "groupId": "service",
                "host": "webmail",
-               "pointsTo": "%var4%",
-               "ttl": "%var2%"
+               "pointsTo": "%var3%",
+               "ttl": 600
            },
            {
-               "groupId" : "verification",
                "type": "TXT",
+               "groupId": "verification",
                "host": "example",
-               "data": "%var5%",
-               "ttl": "%var2%"
+               "ttl": 600,
+               "data": "%var4%"
            }
        ]
    }
@@ -3242,12 +3413,9 @@ A.1.  Example Template
 
 
 
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 58]
+Kowalik, et al.          Expires 23 January 2025               [Page 61]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
 A.2.  Example Records: Single static host record
@@ -3259,13 +3427,13 @@ A.2.  Example Records: Single static host record
    [{
        "type": "A",
        "host": "www",
-       "pointsTo": "192.168.1.1",
+       "pointsTo": "192.0.2.1",
        "ttl": 600
    }]
 
    This would have no variable substitution and the application of this
    template to a domain would simply set the host name "www" to the IP
-   address "192.168.1.1"
+   address "192.0.2.1"
 
 A.3.  Example Records: Single variable host record for A
 
@@ -3276,7 +3444,7 @@ A.3.  Example Records: Single variable host record for A
    [{
        "type": "A",
        "host": "@",
-       "pointsTo": "192.168.1.%srv%",
+       "pointsTo": "198.51.100.%srv%",
        "ttl": 600
    }]
 
@@ -3285,7 +3453,7 @@ A.3.  Example Records: Single variable host record for A
    srv=2
 
    would cause the application of this template to a domain to set the
-   host name for the apex A record to the IP address "192.168.1.2" with
+   host name for the apex A record to the IP address "198.51.100.2" with
    a TTL of 600
 
 A.4.  Example: DNS Zone merging
@@ -3301,25 +3469,25 @@ A.4.  Example: DNS Zone merging
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 59]
+Kowalik, et al.          Expires 23 January 2025               [Page 62]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-   $ORIGIN test-domain.com.
+   $ORIGIN example.com.
 
-   @ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-   1209600 3600
-   @ 3600 IN NS ns11.acme.net.
-   @ 3600 IN NS ns12.acme.net.
-   @ 3600 IN A 1.1.1.1
-   @ 3600 IN A 1.1.1.2
+   @ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+   1800 1209600 3600
+   @ 3600 IN NS ns11.example.net.
+   @ 3600 IN NS ns12.example.net.
+   @ 3600 IN A 192.0.2.1
+   @ 3600 IN A 192.0.2.2
    @ 3600 IN AAAA 2001:db8:1234:0000:0000:0000:0000:0000
    @ 3600 IN AAAA 2001:db8:1234:0000:0000:0000:0000:0001
-   @ 3600 IN MX 10 mx1.acme.net.
-   @ 3600 IN MX 10 mx2.acme.net.
-   @ 3600 IN TXT "v=spf1 a include:spf.acme.com ~all"
-   www 3600 IN CNAME other.host.com.
+   @ 3600 IN MX 10 mx1.example.net.
+   @ 3600 IN MX 10 mx2.example.net.
+   @ 3600 IN TXT "v=spf1 a include:spf.example.org ~all"
+   www 3600 IN CNAME other.host.example.
 
    Now application of the following template:
 
@@ -3327,19 +3495,19 @@ Internet-Draft               Domain Connect                   April 2022
        {
            "type":"A",
            "host":"@",
-           "pointsTo":"2.2.2.2",
+           "pointsTo":"203.0.113.2",
            "ttl":"1800"
        },
        {
            "type":"A",
            "host":"www",
-           "pointsTo":"2.2.2.2",
+           "pointsTo":"203.0.113.2",
            "ttl":"1800"
        },
        {
            "type":"SPFM",
            "host":"@",
-           "spfRules":"a include:spf.hoster.com"
+           "spfRules":"a include:spf.hoster.example"
        }
    ]
 
@@ -3357,33 +3525,34 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 60]
+Kowalik, et al.          Expires 23 January 2025               [Page 63]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
 
 
-   $ORIGIN test-domain.com.
+   $ORIGIN example.com.
 
-   @ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050920 7200 1800
-   1209600 3600
-   @ 3600 IN NS ns11.acme.net.
-   @ 3600 IN NS ns12.acme.net.
-   @ 1800 IN A 2.2.2.2
-   @ 3600 IN MX 10 mx1.acme.net.
-   @ 3600 IN MX 10 mx2.acme.net.
-   @ 1800 IN TXT "v=spf1 a include:spf.acme.com include:spf.hoster.com ~all"
-   www 1800 IN A 2.2.2.2
+   @ 3600 IN SOA ns11.example.net. support.example.net. 2017050920 7200
+   1800 1209600 3600
+   @ 3600 IN NS ns11.example.net.
+   @ 3600 IN NS ns12.example.net.
+   @ 1800 IN A 203.0.113.2
+   @ 3600 IN MX 10 mx1.example.net.
+   @ 3600 IN MX 10 mx2.example.net.
+   @ 1800 IN TXT "v=spf1 a include:spf.example.org include:spf.hoster.ex
+   ample ~all"
+   www 1800 IN A 203.0.113.2
 
 A.5.  Example: SPF Record Merging
 
    Consider a DNS Zone before a template application:
 
-   $ORIGIN test-domain.com.
+   $ORIGIN example.com.
 
-   @ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-   1209600 3600
-   @ 3600 IN NS ns11.acme.net.
-   @ 3600 IN NS ns12.acme.net.
+   @ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+   1800 1209600 3600
+   @ 3600 IN NS ns11.example.net.
+   @ 3600 IN NS ns12.example.net.
 
    Now application of the following template of Mail service:
 
@@ -3392,41 +3561,42 @@ A.5.  Example: SPF Record Merging
            "type":"MX",
            "host":"@",
            "priority": "10",
-           "pointsTo":"mx1.acme.net",
+           "pointsTo":"mx1.example.net",
            "ttl":"1800"
        },
        {
            "type":"MX",
            "host":"www",
            "priority": "10",
-           "pointsTo":"mx2.acme.net",
+           "pointsTo":"mx2.example.net",
            "ttl":"1800"
        },
        {
            "type":"SPFM",
            "host":"@",
-           "spfRules":"a include:spf.acme.net"
+           "spfRules":"a include:spf.example.net"
        }
    ]
 
-   Expected result in the DNS Zone
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 61]
+Kowalik, et al.          Expires 23 January 2025               [Page 64]
 
-Internet-Draft               Domain Connect                   April 2022
+Internet-Draft               Domain Connect                    July 2024
+
 
+   Expected result in the DNS Zone
 
-   $ORIGIN test-domain.com.
+   $ORIGIN example.com.
 
-   @ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-   1209600 3600
-   @ 3600 IN NS ns11.acme.net.
-   @ 3600 IN NS ns12.acme.net.
-   @ 3600 IN MX 10 mx1.acme.net.
-   @ 3600 IN MX 10 mx2.acme.net.
-   @ 3600 IN TXT "v=spf1 a include:spf.acme.net ~all"
+   @ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+   1800 1209600 3600
+   @ 3600 IN NS ns11.example.net.
+   @ 3600 IN NS ns12.example.net.
+   @ 3600 IN MX 10 mx1.example.net.
+   @ 3600 IN MX 10 mx2.example.net.
+   @ 3600 IN TXT "v=spf1 a include:spf.example.net ~all"
 
    In the next step application of the following template of Newsletter
    service:
@@ -3435,65 +3605,63 @@ Internet-Draft               Domain Connect                   April 2022
        {
            "type":"SPFM",
            "host":"@",
-           "spfRules":"include:_spf.newsletter.com"
+           "spfRules":"include:_spf.newsletter.example"
        }
    ]
 
    Expected result in the DNS Zone
 
-   $ORIGIN test-domain.com.
+   $ORIGIN example.com.
 
-   @ 3600 IN SOA ns11.acme.net. support.acme.net. 2017050817 7200 1800
-   1209600 3600
-   @ 3600 IN NS ns11.acme.net.
-   @ 3600 IN NS ns12.acme.net.
-   @ 3600 IN MX 10 mx1.acme.net.
-   @ 3600 IN MX 10 mx2.acme.net.
-   @ 3600 IN TXT "v=spf1 a include:spf.acme.net include:_spf.newsletter.com ~all"
+   @ 3600 IN SOA ns11.example.net. support.example.net. 2017050817 7200
+   1800 1209600 3600
+   @ 3600 IN NS ns11.example.net.
+   @ 3600 IN NS ns12.example.net.
+   @ 3600 IN MX 10 mx1.example.net.
+   @ 3600 IN MX 10 mx2.example.net.
+   @ 3600 IN TXT "v=spf1 a include:spf.example.net include:_spf.newslett
+   er.
+   example ~all"
 
 Authors' Addresses
 
-   R Carney
-   GoDaddy Inc.
-   14455 N. Hayden Rd. #219
-   Scottsdale,
-   United States of America
-   Email: rcarney@godaddy.com
-   URI:   http://www.godaddy.com
-
-
-   A Blinn
-   Email: arnold@arnoldblinn.com
-
-
-
-
-
-Carney, et al.           Expires 29 October 2022               [Page 62]
-
-Internet-Draft               Domain Connect                   April 2022
-
-
    P Kowalik
-   IONOS SE
-   Elgendorfer Str. 57
-   Montabaur
+   DENIC eG
+   Theodor-Stern-Kai 1
+   Frankfurt am Main
    Germany
-   Email: pawel.kowalik@ionos.com
-   URI:   https://ionos.com
-
-
+   Email: pawel.kowalik@denic.de
+   URI:   https://denic.de
 
 
 
 
 
+Kowalik, et al.          Expires 23 January 2025               [Page 65]
+
+Internet-Draft               Domain Connect                    July 2024
 
 
+   A Blinn
+   Email: arnold@arnoldblinn.com
 
 
+   J Kolker
+   GoDaddy Inc.
+   14455 N. Hayden Rd. #219
+   Scottsdale,
+   United States of America
+   Email: jkolker@godaddy.com
+   URI:   https://www.godaddy.com
 
 
+   S Kerola
+   Cloudflare, Inc.
+   101 Townsend St
+   San Francisco,
+   United States of America
+   Email: kerolasa@cloudflare.com
+   URI:   https://cloudflare.com
 
 
 
@@ -3525,4 +3693,4 @@ Internet-Draft               Domain Connect                   April 2022
 
 
 
-Carney, et al.           Expires 29 October 2022               [Page 63]
+Kowalik, et al.          Expires 23 January 2025               [Page 66]