diff --git a/docs/draft-ietf-dconn-domainconnect-04.clean.txt b/docs/draft-ietf-dconn-domainconnect-04.clean.txt index 2dbb0d0..798135d 100644 --- a/docs/draft-ietf-dconn-domainconnect-04.clean.txt +++ b/docs/draft-ietf-dconn-domainconnect-04.clean.txt @@ -299,6 +299,24 @@ Table of Contents dc-host-list = domain-name *( *SP "," *SP domain-name ) ; comma-separated list of domain names + dc-apply-param = dc-predefined-param / dc-dot-param / dc-vnd-param + ; any apply-parameter name + + dc-predefined-param = + "providerId" / "serviceId" / "domain" / "host" + / "redirect_uri" / "state" / "providerName" + / "serviceName" / "groupId" / "sig" / "key" + / "client_id" / "response_type" / "scope" + ; parameter names defined by this specification or + ; carried over from the client-request calls of the + ; asynchronous flow of [DC-SPEC] + + dc-dot-param = "dc." 1*ALPHA + ; "dc." tree, reserved for standards-track extensions + + dc-vnd-param = "vnd." 1*ALPHA *( "." 1*ALPHA ) + ; "vnd." tree, reserved for vendor/private use + ; ---- Other parameter rules ---- dc-sig = 1*( ALPHA / DIGIT / "+" / "/" / "=" ) @@ -2004,6 +2022,41 @@ Table of Contents HjEya50YDHfZJlYHkHlK0xX6Yqeii9QZ2I35U9eJbSvZGQko5beqviWFXdsVDbvd3DYcb SHgJq9%2FXoMTTw%3D%3D&key=_dcpubkeyv1 +8.3.2.2. Apply Parameter Extensibility + + The set of apply parameters MAY be extended. To avoid name + collisions between this specification, future extensions, and vendor- + specific parameters, apply parameter names are governed by the + following reservation rules: + + * Parameter names beginning with "dc." are reserved for parameters + defined by future standards-track extensions that normatively + require this document as their base. Implementations MUST NOT use + the "dc." prefix for private parameters. + + * Parameter names beginning with "vnd." are reserved for vendor- + specific and private-use parameters. A vendor SHOULD further + namespace such parameters with a vendor identifier (e.g. + "vnd.example.foo"). Parameters using this prefix MUST NOT be + assumed to be interoperable across DNS Providers. + + * Parameter names without any dot-prefix are reserved for this + specification and for specifications extending this document that + carry over functionality of [DC-SPEC] (see Section 3, Paragraph + 13), such as the client-request query parameters of the OAuth- + based asynchronous flow. Implementations MUST NOT define private + or vendor-specific parameters using unprefixed names. + + The name of every apply parameter MUST conform to the dc-apply-param + syntax (see Section 3), which partitions the parameter name space + into the three reservation classes above. Extension parameter names + using a reserved prefix accordingly conform to the dc-dot-param (for + "dc.") or dc-vnd-param (for "vnd.") rule. A DNS Provider MUST ignore + any apply parameter it does not recognise; an unrecognised extension + parameter MUST NOT cause the apply request to fail. Extension + parameters, when present, are included in the canonical input string + for signing exactly as any other parameter (see Section 8.3.2.1). + 8.3.3. Template Apply Request The Service Provider initiates the synchronous flow by directing the @@ -2190,6 +2243,12 @@ Table of Contents "NS" record types it would render a circular delegation therefore MUST NOT be used. + Aside from the built-in variables above and "@", a template variable- + name MUST NOT collide with any reserved apply parameter name - the + dc-predefined-param names or names beginning with a reserved + extension prefix ("dc.", "vnd.") (see Section 3). These names are + reserved for protocol use. + 9.2. Variable substitution 9.2.1. Input Values @@ -3163,6 +3222,19 @@ Change History This section is to be removed before publishing as an RFC. +Change from draft-ietf-dconn-domainconnect-03 to -04 + + * Added Apply Parameter Extensibility to Parameters/properties, + reserving the "dc." and "vnd." prefixes and the unprefixed + grandfathered parameter names. + + * Reserved built-in and grandfathered apply parameter names as + forbidden variable-name identifiers in Special and Built-In + Variables. + + * Added dc-apply-param, dc-predefined-param, dc-dot-param, and dc- + vnd-param to Terminology. + Change from draft-ietf-dconn-domainconnect-02 to -03 * Classified template record types as Fully Specified, Computed, or diff --git a/docs/draft-ietf-dconn-domainconnect-04.html b/docs/draft-ietf-dconn-domainconnect-04.html index b5d7041..eec3f49 100644 --- a/docs/draft-ietf-dconn-domainconnect-04.html +++ b/docs/draft-ietf-dconn-domainconnect-04.html @@ -1821,7 +1821,7 @@

The following additional ABNF rules are defined in this document and used normatively throughout.

-
+
; ---- Identifier rules ----
 
@@ -1837,6 +1837,24 @@ 

 dc-host-list   =  domain-name *( *SP "," *SP domain-name )
                 ; comma-separated list of domain names
 
+dc-apply-param =  dc-predefined-param / dc-dot-param / dc-vnd-param
+                ; any apply-parameter name
+
+dc-predefined-param =
+                   "providerId" / "serviceId" / "domain" / "host"
+                 / "redirect_uri" / "state" / "providerName"
+                 / "serviceName" / "groupId" / "sig" / "key"
+                 / "client_id" / "response_type" / "scope"
+                ; parameter names defined by this specification or
+                ; carried over from the client-request calls of the
+                ; asynchronous flow of [DC-SPEC]
+
+dc-dot-param   =  "dc." 1*ALPHA
+                ; "dc." tree, reserved for standards-track extensions
+
+dc-vnd-param   =  "vnd." 1*ALPHA *( "." 1*ALPHA )
+                ; "vnd." tree, reserved for vendor/private use
+
 ; ---- Other parameter rules ----
 
 dc-sig         =  1*( ALPHA / DIGIT / "+" / "/" / "=" )
@@ -4060,19 +4078,19 @@ 

             

 8.3.2.1. Signing Procedure
             

-

+

 
Signing the query string is OPTIONAL for templates that do not specify "syncPubKeyDomain". When "syncPubKeyDomain" is present in the template, the Service Provider MUST sign the request and the DNS Provider MUST reject any unsigned apply request (see Section 8.3.4).

 

-

+

 
The Service Provider MUST generate the digital signature as follows:

 

-

+

 
    
 
  1. 
-                
    
+                
    
 
    Construct the canonical input string:
    
 
    
-
    
+
    
 
      
 
    1. Take all apply parameters except "sig" and "key".
 
      2. 
@@ -4093,24 +4111,24 @@ 
      
 
             
    
 
    
-
    
+
    
 
    The signed query string MUST be used as-is as the query string of the request URL, without re-encoding, adding or re-ordering of query parameters.
    
 
    
-
    
+
    
 
    EXAMPLE: Example: signed query string parameters
    
 
    
-
    
+
    
 
    Example canonical input:
    
 
    
-
    
+
    
 
    
 
    a=1&b=2&domain=example.net&ip=10.10.10.10&text=a%2Bb
    
 
    
 
    
-
    
+
    
 
    Example signature:
    
 
    
-
    
+
    
 
    
 
    sig=V2te9zWMU7G3plxBTsmYSJTvn2vzMvNwAjWQ%2BwTe91DxuJhdVf4cVc4vZBYfEYV
 7u5d7PzTO7se7OrkhyiB7TpoJJW1yB5qHR7HKM5SZldUsdtg5%2B1SzEtIX0Uq8b2mCmQ
@@ -4122,6 +4140,27 @@ 
    
 
    
 
 
    
+
    
+
    
+            
    
+8.3.2.2. Apply Parameter Extensibility
+            
    
+
    
+
    The set of apply parameters MAY be extended. To avoid name collisions between this specification, future extensions, and vendor-specific parameters, apply parameter names are governed by the following reservation rules:
    
+
    
+
      
+
    • Parameter names beginning with "dc." are reserved for parameters defined by future standards-track extensions that normatively require this document as their base. Implementations MUST NOT use the "dc." prefix for private parameters.
+
      • 
+              
    • Parameter names beginning with "vnd." are reserved for vendor-specific and private-use parameters. A vendor SHOULD further namespace such parameters with a vendor identifier (e.g. "vnd.example.foo"). Parameters using this prefix MUST NOT be assumed to be interoperable across DNS Providers.
+
      • 
+              
    • Parameter names without any dot-prefix are reserved for this specification and for specifications extending this document that carry over functionality of [DC-SPEC] (see Section 3, Paragraph 13), such as the client-request query parameters of the OAuth-based asynchronous flow. Implementations MUST NOT define private or vendor-specific parameters using unprefixed names.
+
      • 
+            
    
+
    
+
    The name of every apply parameter MUST conform to the dc-apply-param syntax (see Section 3), which partitions the parameter name space into the three reservation classes above. Extension parameter names using a reserved prefix accordingly conform to the dc-dot-param (for "dc.") or dc-vnd-param (for "vnd.") rule. A DNS Provider MUST ignore any apply parameter it does not recognise; an unrecognised extension parameter MUST NOT cause the apply request to fail. Extension parameters, when present, are included in the canonical input string for signing exactly as any other parameter (see Section 8.3.2.1).
    
+
    
+
    
+
    
 
 
    
 
    
@@ -4311,6 +4350,9 @@ 
    
 
    
 
    The "@" variable has special meaning, and can be used in the "host"/"name" field or in the "pointsTo" field in isolation. For the "host"/"name" and "pointsTo" fields it is a shortcut for the value "%fqdn%.". The trailing dot here is equal to the DNS master file notation [RFC1035], which indicates the value is absolute. For some record types, like  "A" or "AAAA" usage of "@" in pointsTo would not render a valid IP address, therefore MUST NOT be used. Likewise in "NS" record types it would render a circular delegation therefore MUST NOT be used.
    
 
    
+
    
+
    Aside from the built-in variables above and "@", a template variable-name MUST NOT collide with any reserved apply parameter name - the dc-predefined-param names or names beginning with a reserved extension prefix ("dc.", "vnd.") (see Section 3). These names are reserved for protocol use.
    
+
    
 
 
    
 
@@ -5775,193 +5817,208 @@ 
    
       
 
 
    
-
    
+
    
 
    
       
    
 Change History
       
    
 
    This section is to be removed before publishing as an RFC.
    
-
    
+
    
 
    
         
    
-Change from draft-ietf-dconn-domainconnect-02 to -03
+Change from draft-ietf-dconn-domainconnect-03 to -04
         
    
 
+
    
+
    
+
    
+
    
+        
    
+Change from draft-ietf-dconn-domainconnect-02 to -03
+        
    
+
 
    
 
    
-
    
-
    
-        
    
-Change from draft-ietf-dconn-domainconnect-01 to -02
+
    
+
    
+        
    
+Change from draft-ietf-dconn-domainconnect-01 to -02
         
    
 
      
-
    • Removed the Asynchronous OAuth Flow from this document; the synchronous flow is now the sole protocol flow defined here. The asynchronous flow is reserved for a companion extension specification.
+
    • Removed the Asynchronous OAuth Flow from this document; the synchronous flow is now the sole protocol flow defined here. The asynchronous flow is reserved for a companion extension specification.
 
      • 
         
    
 
    
 
    
-
    
-
    
-        
    
-Change from draft-ietf-dconn-domainconnect-00 to -01
+
    
+
    
+        
    
+Change from draft-ietf-dconn-domainconnect-00 to -01
         
    
 
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 Change from draft-kowalik-domainconnect-02 to draft-ietf-dconn-domainconnect-00
         
    
 
      
-
    • DCONN WG adoption. No other changes.
+
    • DCONN WG adoption. No other changes.
 
      • 
         
    
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 Change from -01 to -02
         
    
 
      
-
    • Draft refresh from expire.  No content changes.
+
    • Draft refresh from expire.  No content changes.
 
      • 
         
    
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 Change from -00 to -01
         
    
 
      
-
    • Changed term Root Domain to Zone Apex to align with [RFC8499].
+
    • Changed term Root Domain to Zone Apex to align with [RFC8499].
 
      • 
-          
    • Removed example provider names from Service Providers and DNS Providers terminology
+          
    • Removed example provider names from Service Providers and DNS Providers terminology
 
      • 
-          
    • Added Use Cases
+          
    • Added Use Cases
 
      • 
-          
    • Added Trust Model
+          
    • Added Trust Model
 
      • 
-          
    • Added sequence diagrams for synchronous and asynchronous flows instead of UX mocks
+          
    • Added sequence diagrams for synchronous and asynchronous flows instead of UX mocks
 
      • 
-          
    • Reviewed use of normative language
+          
    • Reviewed use of normative language
 
      • 
-          
    • Cleaned up usage of terminology
+          
    • Cleaned up usage of terminology
 
      • 
-          
    • Variable substitution description updated
+          
    • Variable substitution description updated
 
      • 
-          
    • All URLs are now normatively defined with URI templates
+          
    • All URLs are now normatively defined with URI templates
 
      • 
         
    
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 Change from draft-kowalik-regext-domainconnect-00 to draft-kowalik-domainconnect-00
         
    
 
      
-
    • Added possibility to specify any DNS record type in a generic manner.
+
    • Added possibility to specify any DNS record type in a generic manner.
 
      • 
-          
    • Added possibility to define variables for numeric fields.
+          
    • Added possibility to define variables for numeric fields.
 
      • 
-          
    • Added IANA registration for _domainconnect record as per [RFC8552]
+          
    • Added IANA registration for _domainconnect record as per [RFC8552]
 
      • 
         
    
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 Change from draft-carney-regext-domainconnect-03 to draft-kowalik-regext-domainconnect-00
         
    
 
      
-
    • 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
         
    
 
      
-
    • Added width/height JSON values returned by DNS Provider Discovery.
+
    • Added width/height JSON values returned by DNS Provider Discovery.
 
      • 
-          
    • Corrected text of GET method for getting the authorization token.
+          
    • Corrected text of GET method for getting the authorization token.
 
      • 
-          
    • Added clarifying text to Group ID description parameter of the apply template POST method.  Quite a few minor edits and clarifications that were found during implementation, especially in the Implementation Considerations section.
+          
    • Added clarifying text to Group ID description parameter of the apply template POST method.  Quite a few minor edits and clarifications that were found during implementation, especially in the Implementation Considerations section.
 
      • 
         
    
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 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.
+
    • Added new GET method for Service Providers to determine if the DNS Provider supports a specific template.  Some other minor edits for clarification.
 
      • 
         
    
 
    
 
    
-
    
-
    
+
    
+
    
         
    
 Change from draft-carney-regext-domainconnect-00 to -01
         
    
 
      
-
    • Minor edits and clarifications found during implementation.
+
    • Minor edits and clarifications found during implementation.
 
      • 
         
    
 
    
diff --git a/docs/draft-ietf-dconn-domainconnect-04.pdf b/docs/draft-ietf-dconn-domainconnect-04.pdf
index 6e85776..e6104bf 100644
Binary files a/docs/draft-ietf-dconn-domainconnect-04.pdf and b/docs/draft-ietf-dconn-domainconnect-04.pdf differ
diff --git a/docs/draft-ietf-dconn-domainconnect-04.txt b/docs/draft-ietf-dconn-domainconnect-04.txt
index 98e49a6..d52e175 100644
--- a/docs/draft-ietf-dconn-domainconnect-04.txt
+++ b/docs/draft-ietf-dconn-domainconnect-04.txt
@@ -71,16 +71,16 @@ Table of Contents
      2.2.  Use Cases out of scope  . . . . . . . . . . . . . . . . .   5
    4.  Protocol design . . . . . . . . . . . . . . . . . . . . . . .  11
      4.1.  Templates . . . . . . . . . . . . . . . . . . . . . . . .  11
-     4.2.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  11
+     4.2.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  12
    5.  Protocol Flows Overview . . . . . . . . . . . . . . . . . . .  12
      5.1.  General information . . . . . . . . . . . . . . . . . . .  12
-     5.2.  The Synchronous Flow  . . . . . . . . . . . . . . . . . .  12
-   6.  Domain Connect Objects and Templates  . . . . . . . . . . . .  16
-     6.1.  Template Definition . . . . . . . . . . . . . . . . . . .  16
+     5.2.  The Synchronous Flow  . . . . . . . . . . . . . . . . . .  13
+   6.  Domain Connect Objects and Templates  . . . . . . . . . . . .  17
+     6.1.  Template Definition . . . . . . . . . . . . . . . . . . .  17
      6.2.  Template Record . . . . . . . . . . . . . . . . . . . . .  21
      6.3.  Template Considerations . . . . . . . . . . . . . . . . .  28
        6.3.1.  Template Scope  . . . . . . . . . . . . . . . . . . .  28
-       6.3.2.  Sub Domains . . . . . . . . . . . . . . . . . . . . .  28
+       6.3.2.  Sub Domains . . . . . . . . . . . . . . . . . . . . .  29
        6.3.3.  Variable Scope Minimisation . . . . . . . . . . . . .  29
      6.4.  Public Key Publication  . . . . . . . . . . . . . . . . .  29
    7.  DNS Provider Discovery  . . . . . . . . . . . . . . . . . . .  32
@@ -93,19 +93,19 @@ Table of Contents
      8.3.  Synchronous Flow  . . . . . . . . . . . . . . . . . . . .  40
        8.3.1.  Apply Template URL  . . . . . . . . . . . . . . . . .  40
        8.3.2.  Parameters/properties . . . . . . . . . . . . . . . .  40
-       8.3.3.  Template Apply Request  . . . . . . . . . . . . . . .  44
+       8.3.3.  Template Apply Request  . . . . . . . . . . . . . . .  45
        8.3.4.  Signature Verification  . . . . . . . . . . . . . . .  45
-       8.3.5.  Template Apply Response . . . . . . . . . . . . . . .  45
-       8.3.6.  Template Apply Error Response . . . . . . . . . . . .  46
-     8.4.  Verification of Changes . . . . . . . . . . . . . . . . .  47
-   9.  Resolving Template Variables  . . . . . . . . . . . . . . . .  47
-     9.1.  Variables . . . . . . . . . . . . . . . . . . . . . . . .  47
+       8.3.5.  Template Apply Response . . . . . . . . . . . . . . .  46
+       8.3.6.  Template Apply Error Response . . . . . . . . . . . .  47
+     8.4.  Verification of Changes . . . . . . . . . . . . . . . . .  48
+   9.  Resolving Template Variables  . . . . . . . . . . . . . . . .  48
+     9.1.  Variables . . . . . . . . . . . . . . . . . . . . . . . .  48
        9.1.1.  Variable Syntax . . . . . . . . . . . . . . . . . . .  48
-       9.1.2.  Special and Built-In Variables  . . . . . . . . . . .  48
-     9.2.  Variable substitution . . . . . . . . . . . . . . . . . .  48
-       9.2.1.  Input Values  . . . . . . . . . . . . . . . . . . . .  48
-       9.2.2.  Processing  . . . . . . . . . . . . . . . . . . . . .  49
-     9.3.  Host Name Rendering . . . . . . . . . . . . . . . . . . .  49
+       9.1.2.  Special and Built-In Variables  . . . . . . . . . . .  49
+     9.2.  Variable substitution . . . . . . . . . . . . . . . . . .  49
+       9.2.1.  Input Values  . . . . . . . . . . . . . . . . . . . .  49
+       9.2.2.  Processing  . . . . . . . . . . . . . . . . . . . . .  50
+     9.3.  Host Name Rendering . . . . . . . . . . . . . . . . . . .  50
 
 
 
@@ -114,48 +114,48 @@ Kowalik, et al.          Expires 4 January 2027                 [Page 2]
 Internet-Draft               Domain Connect                    July 2026
 
 
-       9.3.1.  Input Values  . . . . . . . . . . . . . . . . . . . .  49
-       9.3.2.  Processing  . . . . . . . . . . . . . . . . . . . . .  50
-       9.3.3.  Examples of host processing . . . . . . . . . . . . .  50
-     9.4.  SPF Record Merging  . . . . . . . . . . . . . . . . . . .  51
-   10. Template Application  . . . . . . . . . . . . . . . . . . . .  52
-     10.1.  Template State in DNS Providers system . . . . . . . . .  52
-     10.2.  Steps to Apply a Template  . . . . . . . . . . . . . . .  53
-     10.3.  Group Filtering  . . . . . . . . . . . . . . . . . . . .  54
-       10.3.1.  Group Filtering and Template State . . . . . . . . .  55
-     10.4.  Conflict Detection . . . . . . . . . . . . . . . . . . .  55
-       10.4.1.  Conflict Detection Special Handling  . . . . . . . .  56
-     10.5.  Calculating Conflict Resolution  . . . . . . . . . . . .  57
-     10.6.  User Authorization of Changes  . . . . . . . . . . . . .  58
+       9.3.1.  Input Values  . . . . . . . . . . . . . . . . . . . .  50
+       9.3.2.  Processing  . . . . . . . . . . . . . . . . . . . . .  51
+       9.3.3.  Examples of host processing . . . . . . . . . . . . .  51
+     9.4.  SPF Record Merging  . . . . . . . . . . . . . . . . . . .  52
+   10. Template Application  . . . . . . . . . . . . . . . . . . . .  53
+     10.1.  Template State in DNS Providers system . . . . . . . . .  53
+     10.2.  Steps to Apply a Template  . . . . . . . . . . . . . . .  54
+     10.3.  Group Filtering  . . . . . . . . . . . . . . . . . . . .  55
+       10.3.1.  Group Filtering and Template State . . . . . . . . .  56
+     10.4.  Conflict Detection . . . . . . . . . . . . . . . . . . .  56
+       10.4.1.  Conflict Detection Special Handling  . . . . . . . .  57
+     10.5.  Calculating Conflict Resolution  . . . . . . . . . . . .  58
+     10.6.  User Authorization of Changes  . . . . . . . . . . . . .  59
      10.7.  Template Application . . . . . . . . . . . . . . . . . .  59
-     10.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  59
-   11. Security Considerations . . . . . . . . . . . . . . . . . . .  59
-     11.1.  Template Variable Phishing . . . . . . . . . . . . . . .  59
+     10.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  60
+   11. Security Considerations . . . . . . . . . . . . . . . . . . .  60
+     11.1.  Template Variable Phishing . . . . . . . . . . . . . . .  60
      11.2.  Untrusted DNS Provider Discovery Records . . . . . . . .  60
      11.3.  Underscored Host Names . . . . . . . . . . . . . . . . .  61
-   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  61
-     12.1.  Registration Procedure for Domain Connect Registries . .  61
+   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  62
+     12.1.  Registration Procedure for Domain Connect Registries . .  62
      12.2.  Domain Connect Fully Specified Record Types Registry . .  62
      12.3.  Domain Connect Settings Properties Registry  . . . . . .  65
      12.4.  Guidance to the DNS Resource Record (RR) TYPEs
-            Registry . . . . . . . . . . . . . . . . . . . . . . . .  66
-     12.5.  Underscore "_domainconnect" DNS Node Name  . . . . . . .  67
+            Registry . . . . . . . . . . . . . . . . . . . . . . . .  67
+     12.5.  Underscore "_domainconnect" DNS Node Name  . . . . . . .  68
      12.6.  Media Type Registration for application/
-            domainconnect-template+json  . . . . . . . . . . . . . .  67
-   Implementation Status . . . . . . . . . . . . . . . . . . . . . .  68
-   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  69
-   Change History  . . . . . . . . . . . . . . . . . . . . . . . . .  69
-   Normative References  . . . . . . . . . . . . . . . . . . . . . .  73
-   Informative References  . . . . . . . . . . . . . . . . . . . . .  75
-   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  75
-     A.1.  Example Template  . . . . . . . . . . . . . . . . . . . .  75
-     A.2.  Example Records: Single static host record  . . . . . . .  76
-     A.3.  Example Records: Single variable host record for A  . . .  77
-     A.4.  Example Records: Generic Record Type CAA  . . . . . . . .  77
+            domainconnect-template+json  . . . . . . . . . . . . . .  68
+   Implementation Status . . . . . . . . . . . . . . . . . . . . . .  69
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  70
+   Change History  . . . . . . . . . . . . . . . . . . . . . . . . .  70
+   Normative References  . . . . . . . . . . . . . . . . . . . . . .  74
+   Informative References  . . . . . . . . . . . . . . . . . . . . .  76
+   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  77
+     A.1.  Example Template  . . . . . . . . . . . . . . . . . . . .  77
+     A.2.  Example Records: Single static host record  . . . . . . .  78
+     A.3.  Example Records: Single variable host record for A  . . .  78
+     A.4.  Example Records: Generic Record Type CAA  . . . . . . . .  78
      A.5.  Example: Template application to DNS Zone and Conflict
-           Resolution  . . . . . . . . . . . . . . . . . . . . . . .  78
-     A.6.  Example: SPF Record Merging . . . . . . . . . . . . . . .  80
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  81
+           Resolution  . . . . . . . . . . . . . . . . . . . . . . .  79
+     A.6.  Example: SPF Record Merging . . . . . . . . . . . . . . .  81
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  82
 
 
 
@@ -352,6 +352,24 @@ Internet-Draft               Domain Connect                    July 2026
    dc-host-list   =  domain-name *( *SP "," *SP domain-name )
                    ; comma-separated list of domain names
 
+   dc-apply-param =  dc-predefined-param / dc-dot-param / dc-vnd-param
+                   ; any apply-parameter name
+
+   dc-predefined-param =
+                      "providerId" / "serviceId" / "domain" / "host"
+                    / "redirect_uri" / "state" / "providerName"
+                    / "serviceName" / "groupId" / "sig" / "key"
+                    / "client_id" / "response_type" / "scope"
+                   ; parameter names defined by this specification or
+                   ; carried over from the client-request calls of the
+                   ; asynchronous flow of [DC-SPEC]
+
+   dc-dot-param   =  "dc." 1*ALPHA
+                   ; "dc." tree, reserved for standards-track extensions
+
+   dc-vnd-param   =  "vnd." 1*ALPHA *( "." 1*ALPHA )
+                   ; "vnd." tree, reserved for vendor/private use
+
    ; ---- Other parameter rules ----
 
    dc-sig         =  1*( ALPHA / DIGIT / "+" / "/" / "=" )
@@ -368,6 +386,14 @@ Internet-Draft               Domain Connect                    July 2026
    dc-pubkey-domain    =  *( dc-underscore-label "." ) domain-name
                        ; zero or more underscore labels prepended
                        ; to an IDNA domain name, per RFC 8552
+
+
+
+Kowalik, et al.          Expires 4 January 2027                 [Page 7]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
                        ; user for syncPubKeyDomain
 
    dc-display-name =  1*255unicode-assignable
@@ -386,14 +412,6 @@ Internet-Draft               Domain Connect                    July 2026
                    ; a strict subset of JSON number (RFC 8259
                    ; Section 6); used for template version
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                 [Page 7]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    ; ---- Variable expression rules ----
 
    variable-expression =  named-variable / template-apex-var
@@ -424,6 +442,14 @@ Internet-Draft               Domain Connect                    July 2026
                    ; uppercase letter and ends with a letter or
                    ; digit; "A" is grandfathered as a single-letter
                    ; mnemonic. MUST NOT be of the reserved forms
+
+
+
+Kowalik, et al.          Expires 4 January 2027                 [Page 8]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
                    ; "TYPE" or "CLASS" (<>, <>).
 
    dc-rfc3597-type =  "TYPE" 1*DIGIT
@@ -442,14 +468,6 @@ Internet-Draft               Domain Connect                    July 2026
                    ; non-empty printable ASCII (U+0021..U+007E);
                    ; no variable expressions permitted
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                 [Page 8]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    ; -- property value field --
 
    dc-prop-value  =  *( dc-prop-char / dc-rdata-escape )
@@ -481,6 +499,13 @@ Internet-Draft               Domain Connect                    July 2026
 
    ; -- integer fields with optional variable --
 
+
+
+Kowalik, et al.          Expires 4 January 2027                 [Page 9]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    dc-ttl-tmpl    =  1*DIGIT / named-variable
                    ; constant seconds, or a sole %-variable
 
@@ -499,13 +524,6 @@ Internet-Draft               Domain Connect                    July 2026
    dc-srv-protocol =  "_tcp" / "_udp" / "_sctp" / "_dccp"
                    ; underscore-prefixed transport per RFC 2782
 
-
-
-Kowalik, et al.          Expires 4 January 2027                 [Page 9]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    dc-srv-service  =  dc-underscore-label
                    ; underscore-prefixed service name per RFC 6335
 
@@ -532,6 +550,18 @@ Internet-Draft               Domain Connect                    July 2026
       work with a service provided by a Service Provider.
 
    Service Template/Template:  A structured data format that describes a
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 10]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
       set of configurations for DNS records required by a Service
       Provider to configure a certain service together with metadata
       related to the control flow of Domain Connect protocol.  A
@@ -553,15 +583,6 @@ Internet-Draft               Domain Connect                    July 2026
       Record Type's own name.
 
    Generic Record Type:  Any DNS resource record type, identified by its
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 10]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       IANA RR TYPE mnemonic or by the "TYPE" form of [RFC3597], whose
       RDATA is carried opaquely in the "data" field in DNS presentation
       format.
@@ -589,6 +610,14 @@ Internet-Draft               Domain Connect                    July 2026
    The individual records in a template MAY be assigned to a group
    identified by a "groupId".  This allows for the application of
    templates in different stages.  For example, an email provider might
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 11]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    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.
@@ -609,15 +638,6 @@ Internet-Draft               Domain Connect                    July 2026
    checks before enacting any DNS zone changes, and present proposed
    changes to the user in a human-readable form.
 
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 11]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    Service Providers are not assumed to be trusted by default.  A
    malicious actor may attempt to exploit user trust by impersonating a
    legitimate Service Provider.  Trust between DNS Providers and Service
@@ -646,6 +666,14 @@ Internet-Draft               Domain Connect                    July 2026
    compliant DNS Provider returns information about that domain and how
    to configure it using Domain Connect.
 
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 12]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    To apply the changes to DNS, this document defines a synchronous web
    flow.  The DNS Provider presents a consent UX to the user and applies
    the template within the same interaction session.
@@ -665,15 +693,6 @@ Internet-Draft               Domain Connect                    July 2026
    and explicitly consent to the changes within a single interaction
    session.
 
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 12]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    The term "synchronous" refers to this user-interaction model - not to
    immediate DNS propagation.  The DNS Provider commits to applying the
    template upon user consent, but the changes MAY be queued internally
@@ -703,6 +722,14 @@ Internet-Draft               Domain Connect                    July 2026
          |              5 Provides settings|                      |
          |              |<-----------------|                      |
          |              |                  |                      |
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 13]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
          |        6 Queries for supported template                |
          |              |----------------->|                      |
          |              |                  |                      |
@@ -722,14 +749,6 @@ Internet-Draft               Domain Connect                    July 2026
          !_____/        |                  |                      !
          !              10 Lookup URL      |                      !
          !              signature keys (DNS)                      !
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 13]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
          !              |<-----------------|                      !
          !              |                  |                      !
          !              |                  |----.                 !
@@ -759,6 +778,14 @@ Internet-Draft               Domain Connect                    July 2026
          |-------------------------------->|                      |
          |              |                  |                      |
          |              |                  17 Apply changes to DNS|
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 14]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
          |              |                  |--------------------->|
          |              |                  |                      |
          |           18 Redirect/ Close window                    |
@@ -777,15 +804,6 @@ Internet-Draft               Domain Connect                    July 2026
 
    Steps:
 
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 14]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    1.   *User Provides Domain Name*: The user initiates the process by
         providing their domain name to the Service Provider.
 
@@ -815,6 +833,15 @@ Internet-Draft               Domain Connect                    July 2026
         Provider presents a connection link to the user, which leads to
         the DNS Provider's Domain Connect service.
 
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 15]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    9.   *User Navigates to DNS Provider*: The user navigates the link
         and user agent is directed to the DNS Provider's website.
 
@@ -835,13 +862,6 @@ Internet-Draft               Domain Connect                    July 2026
         Provider verifies that the user is authorized to make change to
         the domain's DNS zone.
 
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 15]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    15.  *DNS Provider Requests Consent for DNS Changes*: The DNS
         Provider asks the user for consent to apply the changes to the
         DNS zone.
@@ -867,6 +887,17 @@ Internet-Draft               Domain Connect                    July 2026
         to the user that the domain has been successfully connected to
         the service.
 
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 16]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
 6.  Domain Connect Objects and Templates
 
 6.1.  Template Definition
@@ -890,14 +921,6 @@ Internet-Draft               Domain Connect                    July 2026
    |             |        |                   |to identify the Service |
    |             |        |                   |Provider.               |
    |             |        |                   |The value MUST conform  |
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 16]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    |             |        |                   |to the dc-id syntax (see|
    |             |        |                   |Section 3).             |
    |             |        |                   |To ensure non-          |
@@ -923,6 +946,14 @@ Internet-Draft               Domain Connect                    July 2026
    |             |        |                   |The value MUST conform  |
    |             |        |                   |to the dc-id syntax (see|
    |             |        |                   |Section 3).             |
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 17]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    +-------------+--------+-------------------+------------------------+
    |*Service     |String  |serviceName        |(REQUIRED) The name of  |
    |Name*        |        |                   |the service, suitable   |
@@ -946,14 +977,6 @@ Internet-Draft               Domain Connect                    July 2026
    |             |        |                   |to the dc-version syntax|
    |             |        |                   |(see Section 3).        |
    |             |        |                   |This is a strict subset |
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 17]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    |             |        |                   |of the "JSON number": a |
    |             |        |                   |positive integer with no|
    |             |        |                   |leading zeros, no       |
@@ -979,6 +1002,14 @@ Internet-Draft               Domain Connect                    July 2026
    |             |        |                   |template does, intended |
    |             |        |                   |for developer reference.|
    |             |        |                   |This value is not       |
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 18]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    |             |        |                   |intended for display to |
    |             |        |                   |the end user.           |
    |             |        |                   |The value MUST conform  |
@@ -1002,14 +1033,6 @@ Internet-Draft               Domain Connect                    July 2026
    |Block*       |        |                   |indicates that this     |
    |             |        |                   |template does not       |
    |             |        |                   |support the synchronous |
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 18]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    |             |        |                   |flow.  The DNS Provider |
    |             |        |                   |MUST refuse a           |
    |             |        |                   |synchronous apply       |
@@ -1035,6 +1058,14 @@ Internet-Draft               Domain Connect                    July 2026
    |Name*        |        |                   |caller MAY supply an    |
    |             |        |                   |additional              |
    |             |        |                   |"providerName" parameter|
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 19]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    |             |        |                   |at apply time.          |
    |             |        |                   |The default is "false". |
    |             |        |                   |For backward            |
@@ -1058,14 +1089,6 @@ Internet-Draft               Domain Connect                    July 2026
    |             |        |                   |record is published.    |
    |             |        |                   |When present, this field|
    |             |        |                   |signals that digital    |
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 19]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    |             |        |                   |signing is required for |
    |             |        |                   |synchronous apply       |
    |             |        |                   |requests.               |
@@ -1091,6 +1114,14 @@ Internet-Draft               Domain Connect                    July 2026
    |             |        |                   |times to the same domain|
    |             |        |                   |and host.               |
    |             |        |                   |The default is "false". |
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 20]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    +-------------+--------+-------------------+------------------------+
    |*Warn        |Boolean |warnPhishing       |(DEPRECATED) This flag  |
    |Phishing*    |        |                   |is deprecated and its   |
@@ -1114,14 +1145,6 @@ Internet-Draft               Domain Connect                    July 2026
    |*Host        |Boolean |hostRequired       |(OPTIONAL) When "true", |
    |Required*    |        |                   |indicates that the      |
    |             |        |                   |template is designed to |
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 20]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    |             |        |                   |work only when both     |
    |             |        |                   |"domain" and "host"     |
    |             |        |                   |apply parameters are    |
@@ -1144,6 +1167,17 @@ Internet-Draft               Domain Connect                    July 2026
    Each template record is an entry that contains a type and several
    other values depending on the type.
 
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 21]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    Many of these values can contain variables, which are expressed as
    strings surrounded with "%" or special variable "@" (See:
    Section 9.1).  Variables are replaced with values when the template
@@ -1169,23 +1203,14 @@ Internet-Draft               Domain Connect                    July 2026
       complete set is managed by the IANA "Domain Connect Fully
       Specified Record Types" registry (see Section 12.2).
 
+      Computed Record Types - which instruct the DNS Provider to derive
+      DNS records by a defined computation rather than write a verbatim
+      record.  "SPFM" is the Computed Record Type defined in this
+      document.
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 21]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
-      Computed Record Types - which instruct the DNS Provider to derive
-      DNS records by a defined computation rather than write a verbatim
-      record.  "SPFM" is the Computed Record Type defined in this
-      document.
-
-      Generic Record Types - any other IANA-registered RR TYPE mnemonic,
-      or the "TYPE" form of [RFC3597], whose RDATA is carried opaquely
-      in the "data" field.
+      Generic Record Types - any other IANA-registered RR TYPE mnemonic,
+      or the "TYPE" form of [RFC3597], whose RDATA is carried opaquely
+      in the "data" field.
 
       The DNS Provider MUST support the core Fully Specified Record
       Types A, AAAA, CNAME, MX, TXT, SRV.
@@ -1201,6 +1226,14 @@ Internet-Draft               Domain Connect                    July 2026
    "Group ID":
       JSON key:  "groupId"
 
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 22]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
       Type:  "String"
 
       (OPTIONAL) This parameter identifies the group the record belongs
@@ -1226,14 +1259,6 @@ Internet-Draft               Domain Connect                    July 2026
       OnApply - record MUST be applied but can be later removed without
       dropping the whole template
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 22]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       The value MUST conform to the dc-essential syntax (see Section 3).
 
       If omitted, the value MUST be assumed to be "Always".
@@ -1258,6 +1283,13 @@ Internet-Draft               Domain Connect                    July 2026
       After variable substitution, the resolved value MUST conform to
       the domain-name syntax (see Section 3).
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 23]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    "Name":
       JSON key:  "name"
 
@@ -1281,15 +1313,6 @@ Internet-Draft               Domain Connect                    July 2026
 
       The pointsTo location for A, AAAA, CNAME, NS and MX records.
 
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 23]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       When used in a template definition, the value MUST conform to the
       "dc-pointsto-tmpl" syntax for "CNAME"/"MX" and to the "dc-
       pointsto-nat-tmpl" syntax for A/AAAA/NS (see Section 3).
@@ -1315,6 +1338,14 @@ Internet-Draft               Domain Connect                    July 2026
       This value, no matter if variable or constant, is understood as
       "best effort" by DNS Provider and MAY be limited or adjusted by
       local policy at runtime or during template onboarding, like
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 24]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
       applying a certain minimum or maximum value of TTL or an
       enumeration of TTL values supported by the DNS Provider.  The DNS
       Provider SHOULD NOT reject template application because of invalid
@@ -1338,14 +1369,6 @@ Internet-Draft               Domain Connect                    July 2026
       Specified or Computed Record Type, which use type-specific data
       fields defined in this specification.
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 24]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       For a Generic Record Type, this field contains the canonical
       presentation format of the record, following [RFC3597] generic or
       type-specific encoding.
@@ -1371,6 +1394,14 @@ Internet-Draft               Domain Connect                    July 2026
       The prefix to detect conflicts when txtConflict-MatchingMode is
       "Prefix".  See below (Section 10.4).
 
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 25]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
       The value MUST conform to the dc-conflict-prefix syntax (see
       Section 3).
 
@@ -1394,14 +1425,6 @@ Internet-Draft               Domain Connect                    July 2026
 
       Type:  "Int" or string representation of "Int"
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 25]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       The weight for the SRV record.
 
       When used in a template definition, the value MUST conform to the
@@ -1428,6 +1451,13 @@ Internet-Draft               Domain Connect                    July 2026
       The resolved value is further constrained to the range 0-65535 as
       defined by [RFC6335].
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 26]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
       Support of variables in this field is OPTIONAL for DNS Provider.
 
    "Protocol":
@@ -1450,14 +1480,6 @@ Internet-Draft               Domain Connect                    July 2026
       The value MUST conform to the dc-srv-service syntax (see
       Section 3).
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 26]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    "Target":
       JSON key:  "target"
 
@@ -1485,28 +1507,6 @@ Internet-Draft               Domain Connect                    July 2026
       the version prefix ("v=spf1") and the terminating "all" qualifier.
       The DNS Provider MUST validate the syntax before merging.
 
-   The following table lists the fields that MAY be defined for each
-   record type.  Other fields MUST NOT be used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
 Kowalik, et al.          Expires 4 January 2027                [Page 27]
@@ -1514,6 +1514,9 @@ Kowalik, et al.          Expires 4 January 2027                [Page 27]
 Internet-Draft               Domain Connect                    July 2026
 
 
+   The following table lists the fields that MAY be defined for each
+   record type.  Other fields MUST NOT be used.
+
    +=========+========================================================+
    | Type    | Required fields                                        |
    +=========+========================================================+
@@ -1553,15 +1556,12 @@ Internet-Draft               Domain Connect                    July 2026
    The template's "host" or "name" field values are interpreted relative
    to this scope, as described in Section 9.3.
 
-6.3.2.  Sub Domains
 
-   The recommended way to configure records on a Sub Domain is to use
-   the "host" apply parameter rather than embedding sub-domain labels in
-   template "host" field values as variables.  This keeps the template
-   scope unambiguous and enables correct conflict detection and template
-   state tracking.  Template "host" field values containing variables
-   that resolve to sub-domain labels cause the template scope to be
-   indeterminate at consent time, which prevents accurate conflict
+
+
+
+
+
 
 
 
@@ -1570,6 +1570,15 @@ Kowalik, et al.          Expires 4 January 2027                [Page 28]
 Internet-Draft               Domain Connect                    July 2026
 
 
+6.3.2.  Sub Domains
+
+   The recommended way to configure records on a Sub Domain is to use
+   the "host" apply parameter rather than embedding sub-domain labels in
+   template "host" field values as variables.  This keeps the template
+   scope unambiguous and enables correct conflict detection and template
+   state tracking.  Template "host" field values containing variables
+   that resolve to sub-domain labels cause the template scope to be
+   indeterminate at consent time, which prevents accurate conflict
    detection.
 
    To add a record at the Zone Apex even when a Sub Domain is specified
@@ -1612,15 +1621,6 @@ Internet-Draft               Domain Connect                    July 2026
 
 
 
-
-
-
-
-
-
-
-
-
 Kowalik, et al.          Expires 4 January 2027                [Page 29]
 
 Internet-Draft               Domain Connect                    July 2026
@@ -2445,17 +2445,17 @@ Internet-Draft               Domain Connect                    July 2026
    HjEya50YDHfZJlYHkHlK0xX6Yqeii9QZ2I35U9eJbSvZGQko5beqviWFXdsVDbvd3DYcb
    SHgJq9%2FXoMTTw%3D%3D&key=_dcpubkeyv1
 
-8.3.3.  Template Apply Request
-
-   The Service Provider initiates the synchronous flow by directing the
-   user agent to the Apply Template URL (see Section 8.3.1), constructed
-   as specified in Section 8.3.2.
-
-   The DNS Provider validates the request to ensure that all required
-   parameters are present and valid.  This includes also verification of
-   request signature (see Section 8.3.4 below).
+8.3.2.2.  Apply Parameter Extensibility
 
+   The set of apply parameters MAY be extended.  To avoid name
+   collisions between this specification, future extensions, and vendor-
+   specific parameters, apply parameter names are governed by the
+   following reservation rules:
 
+   *  Parameter names beginning with "dc." are reserved for parameters
+      defined by future standards-track extensions that normatively
+      require this document as their base.  Implementations MUST NOT use
+      the "dc." prefix for private parameters.
 
 
 
@@ -2466,6 +2466,39 @@ Kowalik, et al.          Expires 4 January 2027                [Page 44]
 Internet-Draft               Domain Connect                    July 2026
 
 
+   *  Parameter names beginning with "vnd." are reserved for vendor-
+      specific and private-use parameters.  A vendor SHOULD further
+      namespace such parameters with a vendor identifier (e.g.
+      "vnd.example.foo").  Parameters using this prefix MUST NOT be
+      assumed to be interoperable across DNS Providers.
+
+   *  Parameter names without any dot-prefix are reserved for this
+      specification and for specifications extending this document that
+      carry over functionality of [DC-SPEC] (see Section 3, Paragraph
+      13), such as the client-request query parameters of the OAuth-
+      based asynchronous flow.  Implementations MUST NOT define private
+      or vendor-specific parameters using unprefixed names.
+
+   The name of every apply parameter MUST conform to the dc-apply-param
+   syntax (see Section 3), which partitions the parameter name space
+   into the three reservation classes above.  Extension parameter names
+   using a reserved prefix accordingly conform to the dc-dot-param (for
+   "dc.") or dc-vnd-param (for "vnd.") rule.  A DNS Provider MUST ignore
+   any apply parameter it does not recognise; an unrecognised extension
+   parameter MUST NOT cause the apply request to fail.  Extension
+   parameters, when present, are included in the canonical input string
+   for signing exactly as any other parameter (see Section 8.3.2.1).
+
+8.3.3.  Template Apply Request
+
+   The Service Provider initiates the synchronous flow by directing the
+   user agent to the Apply Template URL (see Section 8.3.1), constructed
+   as specified in Section 8.3.2.
+
+   The DNS Provider validates the request to ensure that all required
+   parameters are present and valid.  This includes also verification of
+   request signature (see Section 8.3.4 below).
+
    If the request is valid, the DNS Provider authenticates the user,
    validates user's authorization to modify the DNS zone, obtains
    authorization to apply the template to the DNS and finally applies
@@ -2480,6 +2513,15 @@ Internet-Draft               Domain Connect                    July 2026
    1.  *Check for required parameters* - The request MUST carry both
        "sig" and "key" parameters.
 
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 45]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    2.  *Retrieve the public key* - Query DNS for TXT records at the host
        formed by prepending the "key" parameter value as a label to
        "syncPubKeyDomain" (see Section 6.4).  If no such records are
@@ -2514,14 +2556,6 @@ Internet-Draft               Domain Connect                    July 2026
    Provider MUST terminate the user flow according to one of the
    following cases:
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 45]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    *  If "redirect_uri" was present in the request and the template's
       "syncRedirectDomain" field is set, the DNS Provider MUST redirect
       the user agent to the "redirect_uri".
@@ -2531,6 +2565,19 @@ Internet-Draft               Domain Connect                    July 2026
       -  "state" - If a "state" parameter was present in the request, it
          MUST be echoed back unchanged as "state=" on the redirect URI.
 
+
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 46]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    *  If "redirect_uri" was not provided, or if "syncRedirectDomain" is
       not set in the template, the DNS Provider MUST gracefully
       terminate the user flow by other means (for example, displaying a
@@ -2568,16 +2615,6 @@ Internet-Draft               Domain Connect                    July 2026
       descriptions vague where disclosure of internal account or domain
       state would be inappropriate.
 
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 46]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       As a RECOMMENDED convention, when the user explicitly cancels the
       operation and the DNS Provider uses "error=access_denied", the
       "error_description" value MAY carry the prefix "user_cancel" to
@@ -2587,6 +2624,16 @@ Internet-Draft               Domain Connect                    July 2026
    *  "state" - If a "state" parameter was present in the request, it
       MUST be echoed back unchanged as "state=" on the redirect URI.
 
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 47]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    If "redirect_uri" is not present or the open-redirect constraint is
    not satisfied, the DNS Provider MUST gracefully terminate the user
    flow and SHOULD present an appropriate error indication to the user.
@@ -2624,16 +2671,6 @@ Internet-Draft               Domain Connect                    July 2026
 
 9.1.  Variables
 
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 47]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
 9.1.1.  Variable Syntax
 
    Variable expressions are the parameterized parts of a Domain Connect
@@ -2644,6 +2681,15 @@ Internet-Draft               Domain Connect                    July 2026
    Variable expressions MUST conform to "variable-expression" syntax
    (see Section 3).
 
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 48]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
 9.1.2.  Special and Built-In Variables
 
    There are three Built-In variables:
@@ -2670,6 +2716,12 @@ Internet-Draft               Domain Connect                    July 2026
    "NS" record types it would render a circular delegation therefore
    MUST NOT be used.
 
+   Aside from the built-in variables above and "@", a template variable-
+   name MUST NOT collide with any reserved apply parameter name - the
+   dc-predefined-param names or names beginning with a reserved
+   extension prefix ("dc.", "vnd.") (see Section 3).  These names are
+   reserved for protocol use.
+
 9.2.  Variable substitution
 
 9.2.1.  Input Values
@@ -2682,18 +2734,18 @@ Internet-Draft               Domain Connect                    July 2026
       caller in the apply request (query string parameters or JSON
       body).  Values MUST be treated as strings regardless of how the
       underlying data source represents them; any transport encoding
+      (e.g., URL percent-encoding) MUST be decoded before substitution.
+      The resulting substituted value MUST reflect the exact original
+      input value string.
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 48]
+
+Kowalik, et al.          Expires 4 January 2027                [Page 49]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-      (e.g., URL percent-encoding) MUST be decoded before substitution.
-      The resulting substituted value MUST reflect the exact original
-      input value string.
-
    *  Built-in variable values - the values of "%domain%", "%host%", and
       "%fqdn%" derived from the "domain" and "host" apply parameters
       (see Section 9.1.2).
@@ -2738,16 +2790,18 @@ Internet-Draft               Domain Connect                    July 2026
 
 9.3.1.  Input Values
 
+   *  "domain" - the Zone Apex, as supplied in the apply request.
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 49]
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 50]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-   *  "domain" - the Zone Apex, as supplied in the apply request.
-
    *  "host" - the Sub Domain label(s), as supplied in the apply
       request.  An empty value or absence of this parameter indicates
       the Zone Apex.
@@ -2794,17 +2848,16 @@ Internet-Draft               Domain Connect                    July 2026
 
    _alternatively_
 
+   www.example.com.    1800 IN CNAME example.com.
+   example.com.        1800 IN A 192.0.2.1
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 50]
+Kowalik, et al.          Expires 4 January 2027                [Page 51]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-   www.example.com.    1800 IN CNAME example.com.
-   example.com.        1800 IN A 192.0.2.1
-
    DNS zone after the template applied with "domain=example.com" and
    "host=bar":
 
@@ -2849,20 +2902,18 @@ Internet-Draft               Domain Connect                    July 2026
    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 SHOULD NOT be included in templates.
+   Instead, a Computed Record Type (see Section 3) is introduced in the
+   template called "SPFM".  This has the following attribute:
 
 
 
-
-Kowalik, et al.          Expires 4 January 2027                [Page 51]
+Kowalik, et al.          Expires 4 January 2027                [Page 52]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-   The implementation would be left to the DNS Provider, but to
-   facilitate this SPF records SHOULD NOT be included in templates.
-   Instead, a Computed Record Type (see Section 3) is introduced 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 6.2)
@@ -2903,17 +2954,6 @@ Internet-Draft               Domain Connect                    July 2026
    DNS Providers MAY choose to maintain state inside records in DNS
    indicating the templates writing the records.
 
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 52]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    A DNS Provider that maintains this state may be able to provide an
    improved experience for users, telling them the services enabled.
    They also may be able to have more advanced handling of conflicts and
@@ -2922,6 +2962,14 @@ Internet-Draft               Domain Connect                    July 2026
    A template instance is identified by the pair "domain" and "host"
    where the template has been applied.  Therefore, the same template
    MUST be able to be applied more than once to the same DNS zone
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 53]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    identified by "domain", as long as the value of "host" parameter
    differs.  Application of the same template with same "host" MAY be
    handled as an update by DNS provider, or just trigger a regular
@@ -2962,14 +3010,6 @@ Internet-Draft               Domain Connect                    July 2026
        resolved RR set against the existing zone content according to
        the conflict detection rules (see Section 10.4).
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 53]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
        a.  Identify individual zone records that conflict with the
            resolved RR set.
 
@@ -2979,6 +3019,13 @@ Internet-Draft               Domain Connect                    July 2026
            conflicting records and would be removed in their entirety
            (see Section 10.4.1.2).
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 54]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
        c.  (only DNS Providers tracking template state): Mark instances
            of the same template applied on the same "host" for removal
            unless "multiInstance" is set for the template (see
@@ -3017,15 +3064,6 @@ Internet-Draft               Domain Connect                    July 2026
    1.  A record with no "groupId" field is always active, regardless of
        whether a "groupId" parameter was supplied in the apply request.
 
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 54]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    2.  A record with a "groupId" field is active if and only if its
        "groupId" value appears in the list supplied as the "groupId"
        apply parameter.  Matching is case-sensitive and exact.
@@ -3034,6 +3072,16 @@ Internet-Draft               Domain Connect                    July 2026
        records are active irrespective of whether they carry a
        "groupId".
 
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 55]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    Only active records MUST be subject to variable substitution,
    conflict detection, and zone write operations.  Inactive records MUST
    be excluded from all template processing steps and MUST NOT be
@@ -3071,26 +3119,25 @@ Internet-Draft               Domain Connect                    July 2026
    *  A CNAME record conflicts with any other record on the same host,
       and any existing records conflict with a CNAME.
 
+   *  An NS record conflicts with all other records on the same host,
+      and with any record whose host is subordinate to the NS host.  For
+      example, an NS record for "foo" conflicts with any record at
+      "foo", "www.foo", "bar.foo", etc.  Conversely, any other record
+      type conflicts with NS records in the same manner.
 
+   *  MX and SRV records conflict with any other record of the same type
+      on the same host.
 
 
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 55]
+
+Kowalik, et al.          Expires 4 January 2027                [Page 56]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-   *  An NS record conflicts with all other records on the same host,
-      and with any record whose host is subordinate to the NS host.  For
-      example, an NS record for "foo" conflicts with any record at
-      "foo", "www.foo", "bar.foo", etc.  Conversely, any other record
-      type conflicts with NS records in the same manner.
-
-   *  MX and SRV records conflict with any other record of the same type
-      on the same host.
-
    *  A and AAAA records conflict with any other A or AAAA record on the
       same host, to avoid IPv4 and IPv6 addresses pointing to different
       services.
@@ -3130,14 +3177,6 @@ Internet-Draft               Domain Connect                    July 2026
    A template flag multiInstance (Section 6.1) can be set in order to
    allow for that.  This tells the DNS Provider that the template is
    expected to be written multiple times and that a re-apply MUST NOT
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 56]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    remove previous instances with the same "host".  Regular conflict
    detection rules MUST still be processed between instances, therefore
    such a template MUST be designed so that it does not conflict with
@@ -3148,6 +3187,13 @@ Internet-Draft               Domain Connect                    July 2026
    This processing only REQUIRED for DNS Providers that maintain applied
    template state.
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 57]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    A template record is considered essential when it MUST be present and
    remain consistent with the applied template for the entire lifetime
    of the service.  The *essential* property of a template record
@@ -3187,13 +3233,6 @@ Internet-Draft               Domain Connect                    July 2026
    template whose records conflict with any existing record in the zone
    MUST remove all those conflicting records.
 
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 57]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    When a DNS Provider maintains applied template state, applying a
    template whose records conflict with records written by a previously
    applied template MUST cause the conflicting prior template to be
@@ -3203,6 +3242,14 @@ Internet-Draft               Domain Connect                    July 2026
    records B and C, record B conflicts, and T1 is removed together with
    all its records before T2 is applied.  Where such a provider shares a
    single record between more than one applied template instance (see
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 58]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    Section 10.4.1.3), it MUST retain that record until the last instance
    referencing it is removed, and MUST remove it only when no remaining
    instance still requires it.
@@ -3236,20 +3283,6 @@ Internet-Draft               Domain Connect                    July 2026
    the displayed name.  It is RECOMMENDED however to also display the
    original "providerName" and "serviceName" defined in the template.
 
-
-
-
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 58]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    Unless the apply request is digitally signed (see Section 8.3.2.1),
    the DNS Provider MUST treat the template as susceptible to phishing:
    it SHOULD display additional warnings prompting the user to verify
@@ -3263,6 +3296,16 @@ Internet-Draft               Domain Connect                    July 2026
    In the Synchronous Flow, after authorization is granted, the DNS
    Provider applies the template to the DNS zone.
 
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 59]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    In the Asynchronous Flow this happens in later point in time.  In
    this case conflict resolution MUST be calculated again for the actual
    state of the zone and parameters provided with the apply request.
@@ -3290,22 +3333,6 @@ Internet-Draft               Domain Connect                    July 2026
    Provider consent screen that appears valid, but would result in DNS
    being pointed at infrastructure under the attacker's control.
 
-
-
-
-
-
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 59]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    Not all templates are susceptible; the risk is proportional to how
    much of a record's content is controlled by variables.  Two
    mitigations are available to template authors and Service Providers:
@@ -3328,6 +3355,13 @@ Internet-Draft               Domain Connect                    July 2026
    Provider's HTTP client at an arbitrary endpoint.  Two classes of
    attack arise:
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 60]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    *  Denial of Service - The record may point at a resource that is
       malformed, never terminates, responds very slowly, or returns an
       oversized or unbounded body, with the goal of exhausting the
@@ -3352,16 +3386,6 @@ Internet-Draft               Domain Connect                    July 2026
       request timeouts, a maximum response size, and a limit on the
       number of redirects followed
 
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 60]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
 11.3.  Underscored Host Names
 
    The "host" apply parameter is supplied by the requesting party and
@@ -3383,6 +3407,17 @@ Internet-Draft               Domain Connect                    July 2026
    and verbose manner during User Authorization of Changes so that the
    special-meaning target is not obscured.
 
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 61]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
 12.  IANA Considerations
 
 12.1.  Registration Procedure for Domain Connect Registries
@@ -3406,18 +3441,6 @@ Internet-Draft               Domain Connect                    July 2026
    IANA's attention (using the  mailing list) for
    resolution.
 
-
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 61]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    The designated experts SHOULD determine whether a registration
    request contains enough information for the registry to be populated
    and whether the proposed new functionality already exists.  In the
@@ -3444,6 +3467,13 @@ Internet-Draft               Domain Connect                    July 2026
    Registration policy: Specification Required (see [RFC8126]),
    following the procedure in Section 12.1.
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 62]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    Each entry in the registry MUST include:
 
    *  *RR Type*: the record type name as it appears in a template record
@@ -3462,18 +3492,6 @@ Internet-Draft               Domain Connect                    July 2026
          obsolete in the IANA "Resource Record (RR) TYPEs" registry, the
          entry here SHOULD be set to "Deprecated".
 
-
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 62]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
       -  "Reserved": the type appears in earlier versions of the Domain
          Connect specification (see [DC-SPEC]) and is reserved for back-
          compatibility.  It MUST NOT be redefined in a manner
@@ -3502,41 +3520,71 @@ Internet-Draft               Domain Connect                    July 2026
       before completing the registration, to confirm that the chosen
       name does not collide with an existing or anticipated DNS RR TYPE.
 
-   *  *Kind*: the nature of the defining document.  The value MUST be
-      one of: "IETF Standard" for types defined in a standards-track
-      RFC, "Informational" for types defined in an Informational RFC, or
-      "Other" for any other specification.
 
-   *  *Reference*: the document that defines the type.
 
-   A registration request MUST provide the following:
 
-   RR Type:  The record type name (the "type" value), conforming to the
-      dc-type-name syntax (see Section 3).
 
-   Status:  One of "Active", "Deprecated", or "Reserved".
 
-   Class:  "Fully Specified" or "Computed"; omitted for a "Reserved"
-      entry.
+Kowalik, et al.          Expires 4 January 2027                [Page 63]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
+   *  *Kind*: the nature of the defining document.  The value MUST be
+      one of: "IETF Standard" for types defined in a standards-track
+      RFC, "Informational" for types defined in an Informational RFC, or
+      "Other" for any other specification.
+
+   *  *Reference*: the document that defines the type.
+
+   A registration request MUST provide the following:
+
+   RR Type:  The record type name (the "type" value), conforming to the
+      dc-type-name syntax (see Section 3).
+
+   Status:  One of "Active", "Deprecated", or "Reserved".
+
+   Class:  "Fully Specified" or "Computed"; omitted for a "Reserved"
+      entry.
+
+   DNS RR TYPE:  The name of the corresponding IANA DNS RR TYPE, or "N/
+      A".
+
+   Kind:  "IETF Standard", "Informational", or "Other".
+
+   Reference:  The document that defines the type, preferably including
+      a URI from which a copy can be retrieved.
+
+   The following types from this specification constitute the initial
+   contents of the registry:
+
+
+
+
+
+
 
-   DNS RR TYPE:  The name of the corresponding IANA DNS RR TYPE, or "N/
-      A".
 
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 63]
-
-Internet-Draft               Domain Connect                    July 2026
 
 
-   Kind:  "IETF Standard", "Informational", or "Other".
 
-   Reference:  The document that defines the type, preferably including
-      a URI from which a copy can be retrieved.
 
-   The following types from this specification constitute the initial
-   contents of the registry:
+
+
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 64]
+
+Internet-Draft               Domain Connect                    July 2026
+
 
     +=============+========+===========+=======+========+=============+
     | *RR Type*   |*Status*| *Class*   |*DNS RR|*Kind*  | *Reference* |
@@ -3575,17 +3623,6 @@ Internet-Draft               Domain Connect                    July 2026
 
         Table 9: Initial Domain Connect Fully Specified Record Types
 
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 64]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
 12.3.  Domain Connect Settings Properties Registry
 
    IANA is requested to create a new registry named "Domain Connect
@@ -3597,6 +3634,14 @@ Internet-Draft               Domain Connect                    July 2026
 
    Each entry in the registry MUST include:
 
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 65]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    *  *Property name*: the JSON key as it appears in the settings
       response.
 
@@ -3633,18 +3678,26 @@ Internet-Draft               Domain Connect                    July 2026
    Reference:  The document that defines the property, preferably
       including a URI from which a copy can be retrieved.
 
+   The following properties from this specification constitute the
+   initial contents of the registry:
 
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 65]
+
+
+
+
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 66]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-   The following properties from this specification constitute the
-   initial contents of the registry:
-
    +=======================+==========+===============+===============+
    | *Property Name*       | *Status* | *Kind*        | *Reference*   |
    +=======================+==========+===============+===============+
@@ -3688,21 +3741,19 @@ Internet-Draft               Domain Connect                    July 2026
    |  Fully Specified Record Types" registry before completing the
    |  assignment.
 
+   This coupling ensures that a Domain Connect record type name that
+   does not (yet) correspond to a DNS RR TYPE - such as a "Computed"
+   type - is not inadvertently assigned a conflicting meaning in the DNS
+   RR TYPEs registry.
 
 
 
 
-
-Kowalik, et al.          Expires 4 January 2027                [Page 66]
+Kowalik, et al.          Expires 4 January 2027                [Page 67]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
-   This coupling ensures that a Domain Connect record type name that
-   does not (yet) correspond to a DNS RR TYPE - such as a "Computed"
-   type - is not inadvertently assigned a conflicting meaning in the DNS
-   RR TYPEs registry.
-
    In addition, IANA is requested to update the "Reference" of the
    "Resource Record (RR) TYPEs" registry to cite this document alongside
    the existing references:
@@ -3746,19 +3797,19 @@ Internet-Draft               Domain Connect                    July 2026
 
    Security considerations:  See Section 11 of this document.
 
+   Interoperability considerations:  See this document.
 
+   Published specification:  This document (see Section 6.1).
 
+   Applications that use this media type:  Domain Connect Service
 
-Kowalik, et al.          Expires 4 January 2027                [Page 67]
-
-Internet-Draft               Domain Connect                    July 2026
 
 
-   Interoperability considerations:  See this document.
+Kowalik, et al.          Expires 4 January 2027                [Page 68]
+
+Internet-Draft               Domain Connect                    July 2026
 
-   Published specification:  This document (see Section 6.1).
 
-   Applications that use this media type:  Domain Connect Service
       Providers and DNS Providers.
 
    Fragment identifier considerations:  The "+json" structured syntax
@@ -3801,18 +3852,19 @@ Proprietary implementations
 
    *  35% of the .com zone (May'24)
 
+Service Providers
 
+Open Source
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 68]
-
-Internet-Draft               Domain Connect                    July 2026
 
 
-Service Providers
 
-Open Source
+Kowalik, et al.          Expires 4 January 2027                [Page 69]
+
+Internet-Draft               Domain Connect                    July 2026
+
 
    *  Example service:
       https://exampleservice.domainconnect.org/https://github.com/
@@ -3849,23 +3901,36 @@ Change History
 
    This section is to be removed before publishing as an RFC.
 
-Change from draft-ietf-dconn-domainconnect-02 to -03
+Change from draft-ietf-dconn-domainconnect-03 to -04
 
-   *  Classified template record types as Fully Specified, Computed, or
-      Generic.
+   *  Added Apply Parameter Extensibility to Parameters/properties,
+      reserving the "dc." and "vnd." prefixes and the unprefixed
+      grandfathered parameter names.
 
-   *  Added a shared Registration Procedure for Domain Connect
-      Registries section (designated-expert assignment and review
-      process) governing all Domain Connect registries.
+   *  Reserved built-in and grandfathered apply parameter names as
+      forbidden variable-name identifiers in Special and Built-In
+      Variables.
 
+   *  Added dc-apply-param, dc-predefined-param, dc-dot-param, and dc-
+      vnd-param to Terminology.
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 69]
+
+Kowalik, et al.          Expires 4 January 2027                [Page 70]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
+Change from draft-ietf-dconn-domainconnect-02 to -03
+
+   *  Classified template record types as Fully Specified, Computed, or
+      Generic.
+
+   *  Added a shared Registration Procedure for Domain Connect
+      Registries section (designated-expert assignment and review
+      process) governing all Domain Connect registries.
+
    *  Coupled the "Domain Connect Fully Specified Record Types" registry
       to the IANA DNS Resource Record (RR) TYPEs registry as a
       bidirectional maintenance contract (following the pattern set by
@@ -3905,6 +3970,14 @@ Internet-Draft               Domain Connect                    July 2026
       definition to [DC-SPEC]; removed reserved properties from the
       example settings response.
 
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 71]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
 Change from draft-ietf-dconn-domainconnect-01 to -02
 
    *  Removed the Asynchronous OAuth Flow from this document; the
@@ -3914,14 +3987,6 @@ Change from draft-ietf-dconn-domainconnect-01 to -02
 
 Change from draft-ietf-dconn-domainconnect-00 to -01
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 70]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    *  Added comprehensive ABNF grammar to the Terminology section
       covering all protocol identifiers, domain name forms (including
       IDN), template fields, OAuth parameters, and signing artifacts;
@@ -3960,6 +4025,15 @@ domainconnect-00
 
    *  DCONN WG adoption.  No other changes.
 
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 72]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
 Change from -01 to -02
 
    *  Draft refresh from expire.  No content changes.
@@ -3971,13 +4045,6 @@ Change from -00 to -01
    *  Removed example provider names from Service Providers and DNS
       Providers terminology
 
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 71]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    *  Added Use Cases
 
    *  Added Trust Model
@@ -4015,6 +4082,14 @@ Change from -02 to -03
 
    *  Corrected text of GET method for getting the authorization token.
 
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 73]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    *  Added clarifying text to Group ID description parameter of the
       apply template POST method.  Quite a few minor edits and
       clarifications that were found during implementation, especially
@@ -4026,14 +4101,6 @@ Change from -01 to -02
       Provider supports a specific template.  Some other minor edits for
       clarification.
 
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 72]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
 Change from draft-carney-regext-domainconnect-00 to -01
 
    *  Minor edits and clarifications found during implementation.
@@ -4069,6 +4136,16 @@ Normative References
               DOI 10.17487/RFC6749, RFC 6749, October 2012,
               .
 
+
+
+
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 74]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
               (RR) Types", IETF, DOI 10.17487/RFC3597, RFC 3597,
               September 2003, .
@@ -4083,13 +4160,6 @@ Normative References
               IETF, DOI 10.17487/RFC8552, BCP 222, RFC 8552, March 2019,
               .
 
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 73]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", IETF, STD 66,
               DOI 10.17487/RFC3986, BCP 66, RFC 3986, January 2005,
@@ -4125,6 +4195,13 @@ Internet-Draft               Domain Connect                    July 2026
               Encodings", IETF, DOI 10.17487/RFC4648, RFC 4648, October
               2006, .
 
+
+
+Kowalik, et al.          Expires 4 January 2027                [Page 75]
+
+Internet-Draft               Domain Connect                    July 2026
+
+
    [RFC5891]  Klensin, J., "Internationalized Domain Names in
               Applications (IDNA): Protocol", IETF,
               DOI 10.17487/RFC5891, RFC 5891, August 2010,
@@ -4139,13 +4216,6 @@ Internet-Draft               Domain Connect                    July 2026
               Subsets", IETF, DOI 10.17487/RFC9839, RFC 9839, August
               2025, .
 
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 74]
-
-Internet-Draft               Domain Connect                    July 2026
-
-
    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
               Writing an IANA Considerations Section in RFCs", IETF,
               DOI 10.17487/RFC8126, BCP 26, RFC 8126, June 2017,
@@ -4181,26 +4251,18 @@ Informative References
               .
 
-Appendix A.  Examples
-
-A.1.  Example Template
-
-   EXAMPLE: Full template example
-
-
-
-
-
-
 
 
+Kowalik, et al.          Expires 4 January 2027                [Page 76]
+
+Internet-Draft               Domain Connect                    July 2026
 
 
+Appendix A.  Examples
 
-Kowalik, et al.          Expires 4 January 2027                [Page 75]
-
-Internet-Draft               Domain Connect                    July 2026
+A.1.  Example Template
 
+   EXAMPLE: Full template example
 
    {
        "providerId": "example.com",
@@ -4242,22 +4304,24 @@ Internet-Draft               Domain Connect                    July 2026
        ]
    }
 
-A.2.  Example Records: Single static host record
-
-   Consider a template for setting a single host record.  The records
-   section of the template would have a single record of type "A" and
-   could have a value of:
 
-   EXAMPLE: Single static host record example
 
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 76]
+Kowalik, et al.          Expires 4 January 2027                [Page 77]
 
 Internet-Draft               Domain Connect                    July 2026
 
 
+A.2.  Example Records: Single static host record
+
+   Consider a template for setting a single host record.  The records
+   section of the template would have a single record of type "A" and
+   could have a value of:
+
+   EXAMPLE: Single static host record example
+
    [{
        "type": "A",
        "host": "www",
@@ -4301,15 +4365,7 @@ A.4.  Example Records: Generic Record Type CAA
 
 
 
-
-
-
-
-
-
-
-
-Kowalik, et al.          Expires 4 January 2027                [Page 77]
+Kowalik, et al.          Expires 4 January 2027                [Page 78]
 
 Internet-Draft               Domain Connect                    July 2026
 
@@ -4365,7 +4421,7 @@ A.5.  Example: Template application to DNS Zone and Conflict Resolution
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 78]
+Kowalik, et al.          Expires 4 January 2027                [Page 79]
 
 Internet-Draft               Domain Connect                    July 2026
 
@@ -4421,7 +4477,7 @@ Internet-Draft               Domain Connect                    July 2026
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 79]
+Kowalik, et al.          Expires 4 January 2027                [Page 80]
 
 Internet-Draft               Domain Connect                    July 2026
 
@@ -4477,7 +4533,7 @@ A.6.  Example: SPF Record Merging
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 80]
+Kowalik, et al.          Expires 4 January 2027                [Page 81]
 
 Internet-Draft               Domain Connect                    July 2026
 
@@ -4533,7 +4589,7 @@ Authors' Addresses
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 81]
+Kowalik, et al.          Expires 4 January 2027                [Page 82]
 
 Internet-Draft               Domain Connect                    July 2026
 
@@ -4589,4 +4645,4 @@ Internet-Draft               Domain Connect                    July 2026
 
 
 
-Kowalik, et al.          Expires 4 January 2027                [Page 82]
+Kowalik, et al.          Expires 4 January 2027                [Page 83]
diff --git a/docs/draft-ietf-dconn-domainconnect-04.xml b/docs/draft-ietf-dconn-domainconnect-04.xml
index 28cc6d5..ca3ec58 100644
--- a/docs/draft-ietf-dconn-domainconnect-04.xml
+++ b/docs/draft-ietf-dconn-domainconnect-04.xml
@@ -126,7 +126,7 @@
 
 The following additional ABNF rules are defined in this document and used normatively throughout.
 
-
 
 
    Signing Procedure
 
-Signing the query string is OPTIONAL for templates that do not specify "syncPubKeyDomain". When "syncPubKeyDomain" is present in the template, the Service Provider MUST sign the request and the DNS Provider MUST reject any unsigned apply request (see ).
+Signing the query string is OPTIONAL for templates that do not specify "syncPubKeyDomain". When "syncPubKeyDomain" is present in the template, the Service Provider MUST sign the request and the DNS Provider MUST reject any unsigned apply request (see ).
 
-The Service Provider MUST generate the digital signature as follows:
+The Service Provider MUST generate the digital signature as follows:
 
-
    1. Construct the canonical input string:
-
      1. Take all apply parameters except "sig" and "key".
        2. 
+
        1. Construct the canonical input string:
+
          1. Take all apply parameters except "sig" and "key".
            2. 
 
          2. URL-encode each parameter name and value per .
            3. 
 
          3. Sort the parameters in ascending lexicographic order of the URL-encoded parameter name.
            4. 
 
          4. Concatenate them as name=value pairs joined by "&".
            5. 
@@ -926,15 +944,27 @@ IP=192.168.42.42&RANDOMTEXT=shm%3A1542108821%3AHello]]>
 
          5. Append the URL-encoded "sig" value and the "key" identifier to the canonical input string to form a signed query string.
            6. 
 
          
 
-The signed query string MUST be used as-is as the query string of the request URL, without re-encoding, adding or re-ordering of query parameters.
+The signed query string MUST be used as-is as the query string of the request URL, without re-encoding, adding or re-ordering of query parameters.
 
-EXAMPLE: Example: signed query string parametersExample canonical input:Example signature:EXAMPLE: Example: signed query string parametersExample canonical input:Example signature:
 
    
+
+
    Apply Parameter Extensibility
+
+The set of apply parameters MAY be extended. To avoid name collisions between this specification, future extensions, and vendor-specific parameters, apply parameter names are governed by the following reservation rules:
+
+
    • Parameter names beginning with "dc." are reserved for parameters defined by future standards-track extensions that normatively require this document as their base. Implementations MUST NOT use the "dc." prefix for private parameters.
      • 
+
    • Parameter names beginning with "vnd." are reserved for vendor-specific and private-use parameters. A vendor SHOULD further namespace such parameters with a vendor identifier (e.g. "vnd.example.foo"). Parameters using this prefix MUST NOT be assumed to be interoperable across DNS Providers.
      • 
+
    • Parameter names without any dot-prefix are reserved for this specification and for specifications extending this document that carry over functionality of  (see ), such as the client-request query parameters of the OAuth-based asynchronous flow. Implementations MUST NOT define private or vendor-specific parameters using unprefixed names.
      • 
+
    
+
+The name of every apply parameter MUST conform to the dc-apply-param syntax (see ), which partitions the parameter name space into the three reservation classes above. Extension parameter names using a reserved prefix accordingly conform to the dc-dot-param (for "dc.") or dc-vnd-param (for "vnd.") rule. A DNS Provider MUST ignore any apply parameter it does not recognise; an unrecognised extension parameter MUST NOT cause the apply request to fail. Extension parameters, when present, are included in the canonical input string for signing exactly as any other parameter (see ).
+
    
 
    
 
 
    Template Apply Request
@@ -1029,6 +1059,8 @@ SHgJq9%2FXoMTTw%3D%3D&key=_dcpubkeyv1]]>
 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".
 
 The "@" variable has special meaning, and can be used in the "host"/"name" field or in the "pointsTo" field in isolation. For the "host"/"name" and "pointsTo" fields it is a shortcut for the value "%fqdn%.". The trailing dot here is equal to the DNS master file notation , which indicates the value is absolute. For some record types, like  "A" or "AAAA" usage of "@" in pointsTo would not render a valid IP address, therefore MUST NOT be used. Likewise in "NS" record types it would render a circular delegation therefore MUST NOT be used.
+
+Aside from the built-in variables above and "@", a template variable-name MUST NOT collide with any reserved apply parameter name - the dc-predefined-param names or names beginning with a reserved extension prefix ("dc.", "vnd.") (see ). These names are reserved for protocol use.
 
    
 
    
 
@@ -1526,11 +1558,19 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
 
  2. Arnt Gulbrandsen
    3. 
 
 
    
-    
    Change History
+    
    Change History
+
+
    Change from draft-ietf-dconn-domainconnect-03 to -04
+
+
    • Added  to , reserving the "dc." and "vnd." prefixes and the unprefixed grandfathered parameter names.
      • 
+
    • Reserved built-in and grandfathered apply parameter names as forbidden variable-name identifiers in .
      • 
+
    • Added dc-apply-param, dc-predefined-param, dc-dot-param, and dc-vnd-param to .
      • 
+
    
+
    
 
-
    Change from draft-ietf-dconn-domainconnect-02 to -03
+
    Change from draft-ietf-dconn-domainconnect-02 to -03
 
-
    • Classified template record types as Fully Specified, Computed, or Generic.
      • 
+
      • Classified template record types as Fully Specified, Computed, or Generic.
        • 
 
      • Added a shared  section (designated-expert assignment and review process) governing all Domain Connect registries.
        • 
 
      • Coupled the "Domain Connect Fully Specified Record Types" registry to the IANA DNS Resource Record (RR) TYPEs registry as a bidirectional maintenance contract (following the pattern set by RFC 9108 for that registry).
        • 
 
      • Added  to .
        • 
@@ -1547,15 +1587,15 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
 
      
 
    
 
-
    Change from draft-ietf-dconn-domainconnect-01 to -02
+
    Change from draft-ietf-dconn-domainconnect-01 to -02
 
-
    • Removed the Asynchronous OAuth Flow from this document; the synchronous flow is now the sole protocol flow defined here. The asynchronous flow is reserved for a companion extension specification.
      • 
+
      • Removed the Asynchronous OAuth Flow from this document; the synchronous flow is now the sole protocol flow defined here. The asynchronous flow is reserved for a companion extension specification.
        • 
 
      
 
    
 
-
    Change from draft-ietf-dconn-domainconnect-00 to -01
+
    Change from draft-ietf-dconn-domainconnect-00 to -01
 
-
    • Added comprehensive ABNF grammar to the Terminology section covering all protocol identifiers, domain name forms (including IDN), template fields, OAuth parameters, and signing artifacts; replaced informal prose constraints throughout parameter tables and field definitions with normative ABNF references.
      • 
+
      • Added comprehensive ABNF grammar to the Terminology section covering all protocol identifiers, domain name forms (including IDN), template fields, OAuth parameters, and signing artifacts; replaced informal prose constraints throughout parameter tables and field definitions with normative ABNF references.
        • 
 
      • Restructured : added , Essential Records, Steps to Apply a Template, and focused ,  subsections; moved UX and runtime-processing rules into their appropriate sections; moved  before  in the document structure.
        • 
 
      • Restructured request signing into , , and 
        • 
 
      • Replaced Sync Apply Interaction with a normative Request/Response/Error structure; rewrote  as normative text.
        • 
@@ -1566,21 +1606,21 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
 
      
 
    
 
-
    Change from draft-kowalik-domainconnect-02 to draft-ietf-dconn-domainconnect-00
+
    Change from draft-kowalik-domainconnect-02 to draft-ietf-dconn-domainconnect-00
 
-
    • DCONN WG adoption. No other changes.
      • 
+
      • DCONN WG adoption. No other changes.
        • 
 
      
 
    
 
-
    Change from -01 to -02
+
    Change from -01 to -02
 
-
    • Draft refresh from expire.  No content changes.
      • 
+
      • Draft refresh from expire.  No content changes.
        • 
 
      
 
    
 
-
    Change from -00 to -01
+
    Change from -00 to -01
 
-
    • Changed term Root Domain to Zone Apex to align with .
      • 
+
      • Changed term Root Domain to Zone Apex to align with .
        • 
 
      • Removed example provider names from Service Providers and DNS Providers terminology
        • 
 
      • Added Use Cases
        • 
 
      • Added Trust Model
        • 
@@ -1592,37 +1632,37 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
 
      
 
    
 
-
    Change from draft-kowalik-regext-domainconnect-00 to draft-kowalik-domainconnect-00
+
    Change from draft-kowalik-regext-domainconnect-00 to draft-kowalik-domainconnect-00
 
-
    • Added possibility to specify any DNS record type in a generic manner.
      • 
+
      • Added possibility to specify any DNS record type in a generic manner.
        • 
 
      • Added possibility to define variables for numeric fields.
        • 
 
      • Added IANA registration for _domainconnect record as per 
        • 
 
      
 
    
 
-
    Change from draft-carney-regext-domainconnect-03 to draft-kowalik-regext-domainconnect-00
+
    Change from draft-carney-regext-domainconnect-03 to draft-kowalik-regext-domainconnect-00
 
-
    • 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
+
    Change from -02 to -03
 
-
    • Added width/height JSON values returned by DNS Provider Discovery.
      • 
+
      • 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 template POST method.  Quite a few minor edits and clarifications that were found during implementation, especially in the Implementation Considerations section.
        • 
 
      
 
    
 
-
    Change from -01 to -02
+
    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.
      • 
+
      • Added new GET method for Service Providers to determine if the DNS Provider supports a specific template.  Some other minor edits for clarification.
        • 
 
      
 
    
 
-
    Change from draft-carney-regext-domainconnect-00 to -01
+
    Change from draft-carney-regext-domainconnect-00 to -01
 
-
    • Minor edits and clarifications found during implementation.
      • 
+
      • Minor edits and clarifications found during implementation.
        • 
 
      
 
    
 
    
diff --git a/draft-ietf-dconn-domainconnect-04.adoc b/draft-ietf-dconn-domainconnect-04.adoc
index a9f29aa..f569d57 100644
--- a/draft-ietf-dconn-domainconnect-04.adoc
+++ b/draft-ietf-dconn-domainconnect-04.adoc
@@ -140,6 +140,24 @@ dc-id-list     =  dc-id *( "," dc-id )
 dc-host-list   =  domain-name *( *SP "," *SP domain-name )
                 ; comma-separated list of domain names
 
+dc-apply-param =  dc-predefined-param / dc-dot-param / dc-vnd-param
+                ; any apply-parameter name
+
+dc-predefined-param =
+                   "providerId" / "serviceId" / "domain" / "host"
+                 / "redirect_uri" / "state" / "providerName"
+                 / "serviceName" / "groupId" / "sig" / "key"
+                 / "client_id" / "response_type" / "scope"
+                ; parameter names defined by this specification or
+                ; carried over from the client-request calls of the
+                ; asynchronous flow of [DC-SPEC]
+
+dc-dot-param   =  "dc." 1*ALPHA
+                ; "dc." tree, reserved for standards-track extensions
+
+dc-vnd-param   =  "vnd." 1*ALPHA *( "." 1*ALPHA )
+                ; "vnd." tree, reserved for vendor/private use
+
 ; ---- Other parameter rules ----
 
 dc-sig         =  1*( ALPHA / DIGIT / "+" / "/" / "=" )
@@ -1537,6 +1555,17 @@ SHgJq9%2FXoMTTw%3D%3D&key=_dcpubkeyv1
 ----
 ====
 
+[[apply-parameter-extensibility]]
+===== Apply Parameter Extensibility
+
+The set of apply parameters MAY be extended. To avoid name collisions between this specification, future extensions, and vendor-specific parameters, apply parameter names are governed by the following reservation rules:
+
+* Parameter names beginning with `"dc."` are reserved for parameters defined by future standards-track extensions that normatively require this document as their base. Implementations MUST NOT use the `"dc."` prefix for private parameters.
+* Parameter names beginning with `"vnd."` are reserved for vendor-specific and private-use parameters. A vendor SHOULD further namespace such parameters with a vendor identifier (e.g. `"vnd.example.foo"`). Parameters using this prefix MUST NOT be assumed to be interoperable across DNS Providers.
+* Parameter names without any dot-prefix are reserved for this specification and for specifications extending this document that carry over functionality of <> (see <>), such as the client-request query parameters of the OAuth-based asynchronous flow. Implementations MUST NOT define private or vendor-specific parameters using unprefixed names.
+
+The name of every apply parameter MUST conform to the `dc-apply-param` syntax (see <>), which partitions the parameter name space into the three reservation classes above. Extension parameter names using a reserved prefix accordingly conform to the `dc-dot-param` (for `"dc."`) or `dc-vnd-param` (for `"vnd."`) rule. A DNS Provider MUST ignore any apply parameter it does not recognise; an unrecognised extension parameter MUST NOT cause the apply request to fail. Extension parameters, when present, are included in the canonical input string for signing exactly as any other parameter (see <>).
+
 
 ==== Template Apply Request
 
@@ -1629,6 +1658,8 @@ For example, with the query string "domain=example.com&host=", `"%fqdn%"` in a t
 The `"@"` variable has special meaning, and can be used in the `"host"`/`"name"` field or in the `"pointsTo"` field in isolation. For the `"host"`/`"name"` and `"pointsTo"` fields it is a shortcut for the value `"%fqdn%."`. The trailing dot here is equal to the DNS master file notation <>, which indicates the value is absolute.
 For some record types, like `"A"` or `"AAAA"` usage of `"@"` in pointsTo would not render a valid IP address, therefore MUST NOT be used. Likewise in `"NS"` record types it would render a circular delegation therefore MUST NOT be used.
 
+Aside from the built-in variables above and `"@"`, a template `variable-name` MUST NOT collide with any reserved apply parameter name — the `dc-predefined-param` names or names beginning with a reserved extension prefix (`"dc."`, `"vnd."`) (see <>). These names are reserved for protocol use.
+
 [[variable-substitution]]
 === Variable substitution
 
@@ -2275,6 +2306,12 @@ The authors wish to thank the following persons for their feedback and suggestio
 [removeInRFC=true,toc=include,numbered=false]
 == Change History
 
+[toc=exclude,numbered=false]
+=== Change from draft-ietf-dconn-domainconnect-03 to -04
+- Added <> to <>, reserving the `"dc."` and `"vnd."` prefixes and the unprefixed grandfathered parameter names.
+- Reserved built-in and grandfathered apply parameter names as forbidden `variable-name` identifiers in <>.
+- Added `dc-apply-param`, `dc-predefined-param`, `dc-dot-param`, and `dc-vnd-param` to <>.
+
 [toc=exclude,numbered=false]
 === Change from draft-ietf-dconn-domainconnect-02 to -03
 - Classified template record types as Fully Specified, Computed, or Generic.