diff --git a/docs/draft-ietf-dconn-domainconnect-04.clean.txt b/docs/draft-ietf-dconn-domainconnect-04.clean.txt index 879ed22..384b794 100644 --- a/docs/draft-ietf-dconn-domainconnect-04.clean.txt +++ b/docs/draft-ietf-dconn-domainconnect-04.clean.txt @@ -237,7 +237,7 @@ Table of Contents capitals, as shown here. The Terms like "*Registrar*", "*Authoritative server*", "*Zone*", - "*Zone Apex*" or "*Sub Domain*" are used as defined in [RFC8499]. + "*Zone Apex*" or "*Sub Domain*" are used as defined in [RFC9499]. This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. The following ABNF rules are imported from @@ -1007,11 +1007,7 @@ Table of Contents | | | |work only when both | | | | |"domain" and "host" | | | | |apply parameters are | - | | | |provided, for example | - | | | |when the template | - | | | |contains a CNAME record | - | | | |targeted at the fully | - | | | |qualified domain name. | + | | | |provided. | | | | |The default is "false". | +-------------+--------+-------------------+------------------------+ |*Critical |Array of|crit |(OPTIONAL) A list of the| @@ -1240,6 +1236,11 @@ Table of Contents order to avoid necessity of per provider adjustment to the application flow. + Records forming the same RRset (i.e., sharing "host"/"name" and + record type) SHOULD be given the same "ttl" value in the template + definition, since [RFC2181] Section 5.2 requires all resource + records in an RRset to share a single TTL. + Support of variables in this field is OPTIONAL for DNS Provider. "Data": @@ -1455,7 +1456,7 @@ Table of Contents The value in the template could simply contain "%servercluster%", and the fully qualified string passed in. Alternatively, the value in - the template could contain "%var%.example.com" and a value of "01", + the template could contain "s%var%.example.com" and a value of "01", "02", or "03" passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the @@ -2580,18 +2581,18 @@ Table of Contents 4. *Resolve variables* - All variable expressions in active template records are substituted with the values provided by the caller, - producing a concrete set of DNS resource records (RRs) to be - applied (see Section 9.2). + producing the Rendered Record Set: a concrete set of DNS resource + records (RRs) to be applied (see Section 9.2). a. abort if rendered RRs are not possible to be applied to the target zone 5. *Perform conflict detection* - The DNS Provider checks the - resolved RR set against the existing zone content according to - the conflict detection rules (see Section 10.4). + Rendered Record Set against the existing zone content according + to the conflict detection rules (see Section 10.4). a. Identify individual zone records that conflict with the - resolved RR set. + Rendered Record Set. b. (only DNS Providers tracking template state): Check each resolved RR against essential records of previously applied @@ -2620,7 +2621,13 @@ Table of Contents a. Remove all records pre-calculated for removal from the zone. - b. Write the resolved RR set to the zone in totality. + b. Write the Rendered Record Set to the zone in totality. + + i. Note: if the Rendered Record Set yields differing "ttl" + values across new and existing RRs that form the same + RRset, the DNS Provider MUST reconcile them to a single + TTL (e.g., by taking the lowest value), per [RFC2181] + Section 5.2 c. (only DNS Providers tracking template state): Record the new template instance for the "domain" and "host" pair and remove @@ -2680,7 +2687,8 @@ Table of Contents host, unless otherwise specified. * A CNAME record conflicts with any other record on the same host, - and any existing records conflict with a CNAME. + including another CNAME, 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 @@ -2708,10 +2716,11 @@ Table of Contents the same host whose value starts with "txtConflictMatchingPrefix". - Note: DNS Provider MUST also check applicability of all generated - records to the target DNS zone in its own system. For example it is - very common for DNS provider not to allow CNAME records to be at the - zone apex. + Note: A DNS Provider MUST also check the applicability of all + generated records to the target DNS zone against constraints imposed + by the DNS protocol itself, such as the coexistence rules of + [RFC2181], as well as any other local capabilities, limits or + policies. 10.4.1. Conflict Detection Special Handling @@ -3002,7 +3011,7 @@ Table of Contents specification that extends this document. See Section 3, Paragraph 13. - * *Class*: the handling class of the type. The value MUST be one of + * *Handling*: the handling of the type. The value MUST be one of "Fully Specified" (RDATA broken into dedicated template fields) or "Computed" (records derived by a defined computation). A "Reserved" entry MAY leave this field unassigned. @@ -3037,7 +3046,7 @@ Table of Contents Status: One of "Active", "Deprecated", or "Reserved". - Class: "Fully Specified" or "Computed"; omitted for a "Reserved" + Handling: "Fully Specified" or "Computed"; omitted for a "Reserved" entry. DNS RR TYPE: The name of the corresponding IANA DNS RR TYPE, or "N/ @@ -3051,42 +3060,42 @@ Table of Contents The following types from this specification constitute the initial contents of the registry: - +=============+========+===========+=======+========+=============+ - | *RR Type* |*Status*| *Class* |*DNS RR|*Kind* | *Reference* | - | | | |TYPE* | | | - +=============+========+===========+=======+========+=============+ - | "A" |Active | Fully |"A" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "AAAA" |Active | Fully |"AAAA" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "CNAME" |Active | Fully |"CNAME"|IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "MX" |Active | Fully |"MX" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "TXT" |Active | Fully |"TXT" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "SRV" |Active | Fully |"SRV" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "NS" |Active | Fully |"NS" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "SPFM" |Active | Computed |"N/A" |IETF | This | - | | | | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "APEXCNAME" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | - +-------------+--------+-----------+-------+--------+-------------+ - | "REDIR301" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | - +-------------+--------+-----------+-------+--------+-------------+ - | "REDIR302" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | - +-------------+--------+-----------+-------+--------+-------------+ - - Table 9: Initial Domain Connect Fully Specified Record Types + +=============+========+============+=======+========+=============+ + | *RR Type* |*Status*| *Handling* |*DNS RR|*Kind* | *Reference* | + | | | |TYPE* | | | + +=============+========+============+=======+========+=============+ + | "A" |Active | Fully |"A" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "AAAA" |Active | Fully |"AAAA" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "CNAME" |Active | Fully |"CNAME"|IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "MX" |Active | Fully |"MX" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "TXT" |Active | Fully |"TXT" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "SRV" |Active | Fully |"SRV" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "NS" |Active | Fully |"NS" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "SPFM" |Active | Computed |"N/A" |IETF | This | + | | | | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "APEXCNAME" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | + +-------------+--------+------------+-------+--------+-------------+ + | "REDIR301" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | + +-------------+--------+------------+-------+--------+-------------+ + | "REDIR302" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | + +-------------+--------+------------+-------+--------+-------------+ + + Table 9: Initial Domain Connect Fully Specified Record Types 12.3. Domain Connect Settings Properties Registry @@ -3449,6 +3458,16 @@ Change from draft-ietf-dconn-domainconnect-03 to -04 * Added dc-template-property, dc-unprefixed-property, and dc-vnd- property to Terminology. + * Corrected nits from early Dnsdir review. + + * Clarified RR placement constraints arising from the DNS protocol. + + * Noted RRset TTL consistency requirements in Template Record and + Steps to Apply a Template. + + * Introduced Rendered Record Set terminology in Steps to Apply a + Template to disambiguate from RRset. + Change from draft-ietf-dconn-domainconnect-02 to -03 * Classified template record types as Fully Specified, Computed, or @@ -3720,11 +3739,11 @@ Normative References RFC 9110, June 2022, . -Informative References + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", IETF, DOI 10.17487/RFC2181, RFC 2181, July + 1997, . - [RFC8499] "Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS - Terminology", IETF, DOI 10.17487/RFC8499, RFC 8499, - January 2019, >.". +Informative References [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", IETF, DOI 10.17487/RFC6839, diff --git a/docs/draft-ietf-dconn-domainconnect-04.html b/docs/draft-ietf-dconn-domainconnect-04.html index abf17f1..958f8f8 100644 --- a/docs/draft-ietf-dconn-domainconnect-04.html +++ b/docs/draft-ietf-dconn-domainconnect-04.html @@ -1681,7 +1681,7 @@

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

-

The Terms like "Registrar", "Authoritative server", "Zone", "Zone Apex" or "Sub Domain" are used as defined in [RFC8499].

+

The Terms like "Registrar", "Authoritative server", "Zone", "Zone Apex" or "Sub Domain" are used as defined in [RFC9499].

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. The following ABNF rules are imported from the normative references [RFC5234].

@@ -2343,7 +2343,7 @@

The template JSON structure defined in this section is identified by the media type "application/domainconnect-template+json" (see Section 12.7).

-
+
- +
Table 1: @@ -2500,7 +2500,7 @@

Boolean hostRequired(OPTIONAL) When "true", indicates that the template is designed to work only when both "domain" and "host" apply parameters are provided, for example when the template contains a CNAME record targeted at the fully qualified domain name.
The default is "false".		(OPTIONAL) When "true", indicates that the template is designed to work only when both "domain" and "host" apply parameters are provided.
The default is "false".
@@ -2846,12 +2846,14 @@

-
+
-"TTL":
-
-
+
+"TTL":
+ +
+
JSON key:
@@ -2886,8 +2888,11 @@

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 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 value, rather pick the nearest supported value or a default, in order to avoid necessity of per provider adjustment to the application flow.

-
-

Support of variables in this field is OPTIONAL for DNS Provider.

+
+

Records forming the same RRset (i.e., sharing "host"/"name" and record type) SHOULD be given the same "ttl" value in the template definition, since [RFC2181] Section 5.2 requires all resource records in an RRset to share a single TTL.

+
+
+

Support of variables in this field is OPTIONAL for DNS Provider.

@@ -3403,7 +3408,7 @@

-
+

6.3. Template Considerations @@ -3437,7 +3442,7 @@

-
+

6.3.3. Variable Scope Minimisation @@ -3448,8 +3453,8 @@

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

-
-

The value in the template could simply contain "%servercluster%", and the fully qualified string passed in. Alternatively, the value in the template could contain "%var%.example.com" and a value of "01", "02", or "03" passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the template.

+
+

The value in the template could simply contain "%servercluster%", and the fully qualified string passed in. Alternatively, the value in the template could contain "s%var%.example.com" and a value of "01", "02", or "03" passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the template.

@@ -4674,7 +4679,7 @@

The following steps give an overview of the template application process. Each step is described in detail in the sections below.

-
+
  1. Verify template applicability - For synchronous flow requests, the DNS Provider MUST verify that the template's "syncBlock" field is not "true". If it is, the DNS Provider MUST NOT process the request and MUST return an error. @@ -4686,8 +4691,8 @@

    Filter records to apply - select records applicable for further processing based on "groupId" property of the template and "groupId" apply parameter (see Section 10.3).

  2. -
    -

    Resolve variables - All variable expressions in active template records are substituted with the values provided by the caller, producing a concrete set of DNS resource records (RRs) to be applied (see Section 9.2).

    +
    +

    Resolve variables - All variable expressions in active template records are substituted with the values provided by the caller, producing the Rendered Record Set: a concrete set of DNS resource records (RRs) to be applied (see Section 9.2).

      @@ -4697,12 +4702,12 @@

  3. -
    -

    Perform conflict detection - The DNS Provider checks the resolved RR set against the existing zone content according to the conflict detection rules (see Section 10.4).

    +
    +

    Perform conflict detection - The DNS Provider checks the Rendered Record Set against the existing zone content according to the conflict detection rules (see Section 10.4).

    -
    +
      -
    1. Identify individual zone records that conflict with the resolved RR set. +
    2. Identify individual zone records that conflict with the Rendered Record Set.
    3. (only DNS Providers tracking template state): Check each resolved RR against essential records of previously applied templates. Identify which previously applied templates own conflicting records and would be removed in their entirety (see Section 10.4.1.2).
      4. @@ -4729,11 +4734,20 @@

      Apply changes - After authorization is granted, or at later point in Asynchronous flow:

      -
      +
      1. Remove all records pre-calculated for removal from the zone.
        2. -
      2. Write the resolved RR set to the zone in totality. +
      3. +
        +

        Write the Rendered Record Set to the zone in totality.

        +
        +
        +
          +
        1. Note: if the Rendered Record Set yields differing "ttl" values across new and existing RRs that form the same RRset, the DNS Provider MUST reconcile them to a single TTL (e.g., by taking the lowest value), per [RFC2181] Section 5.2 +
          2. +
        +
      4. (only DNS Providers tracking template state): Record the new template instance for the "domain" and "host" pair and remove the state of any template instances that were resolved for removal.
        5. @@ -4792,7 +4806,7 @@

        Conflict detection is performed by the DNS Provider prior to template application. The rules below ensure predictable conflict resolution between DNS Providers. Each rule applies to records on the same host, unless otherwise specified.

        -
      • A CNAME record conflicts with any other record on the same host, and any existing records conflict with a CNAME. +
      • A CNAME record conflicts with any other record on the same host, including another CNAME, 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.
        • @@ -4817,8 +4831,8 @@

      -
      -

      Note: DNS Provider MUST also check applicability of all generated records to the target DNS zone in its own system. For example it is very common for DNS provider not to allow CNAME records to be at the zone apex.

      +
      +

      Note: A DNS Provider MUST also check the applicability of all generated records to the target DNS zone against constraints imposed by the DNS protocol itself, such as the coexistence rules of [RFC2181], as well as any other local capabilities, limits or policies.

      @@ -5069,7 +5083,7 @@

    4. - Class: the handling class of the type. The value MUST be one of "Fully Specified" (RDATA broken into dedicated template fields) or "Computed" (records derived by a defined computation). A "Reserved" entry MAY leave this field unassigned. + Handling: the handling of the type. The value MUST be one of "Fully Specified" (RDATA broken into dedicated template fields) or "Computed" (records derived by a defined computation). A "Reserved" entry MAY leave this field unassigned.
    5. DNS RR TYPE: the name of the corresponding entry in the IANA "Resource Record (RR) TYPEs" registry within the "Domain Name System (DNS) Parameters" registry group. A "Fully Specified" type SHOULD correspond to a registered DNS RR TYPE of the same name; before registering such a type, the designated experts MUST verify that the named DNS RR TYPE exists in that registry. For a "Computed" type, a "Reserved" type, or any other type for which no corresponding DNS RR TYPE exists or would be meaningful, the value MUST be "N/A". Where a "Fully Specified" type would use a name that is not yet a registered DNS RR TYPE, or where an entry is registered with a "DNS RR TYPE" of "N/A" (such as a "Computed" type), the designated experts SHOULD coordinate with the designated experts of the "Resource Record (RR) TYPEs" registry before completing the registration, to confirm that the chosen name does not collide with an existing or anticipated DNS RR TYPE. @@ -5084,7 +5098,7 @@

      A registration request MUST provide the following:

      -
      +
      RR Type:
      @@ -5104,7 +5118,7 @@

      -
      Class:
      +
      Handling:
      @@ -5145,7 +5159,7 @@

      The following types from this specification constitute the initial contents of the registry:

      -
      +
      Table 9: @@ -5160,7 +5174,7 @@

      Status

      - Class + Handling DNS RR TYPE @@ -6116,13 +6130,13 @@

      -
      +

      Change History

      This section is to be removed before publishing as an RFC.

      -
      +

      Change from draft-ietf-dconn-domainconnect-03 to -04 @@ -6141,6 +6155,14 @@

    6. Added the IANA "Domain Connect Template Properties" registry in Domain Connect Template Properties Registry.
    7. Added dc-template-property, dc-unprefixed-property, and dc-vnd-property to Terminology. +
      8. +
    8. Corrected nits from early Dnsdir review. +
      9. +
    9. Clarified RR placement constraints arising from the DNS protocol. +
      10. +
    10. Noted RRset TTL consistency requirements in Template Record and Steps to Apply a Template. +
      11. +
    11. Introduced Rendered Record Set terminology in Steps to Apply a Template to disambiguate from RRset.

      12. @@ -6240,13 +6262,13 @@

      -
      +

      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
        • @@ -6332,7 +6354,7 @@

      -
      +

      Normative References @@ -6427,22 +6449,22 @@

      Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", IETF, DOI 10.17487/RFC6838, BCP 13, RFC 6838, , <https://www.rfc-editor.org/info/rfc6838>.
      [RFC9110]
      -
      +
      Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", IETF, STD 97, DOI 10.17487/RFC9110, BCP 97, RFC 9110, , <https://www.rfc-editor.org/info/rfc9110>.
      +
      [RFC2181]
      +
      +Elz, R. and R. Bush, "Clarifications to the DNS Specification", IETF, DOI 10.17487/RFC2181, RFC 2181, , <https://www.rfc-editor.org/info/rfc2181>.
      +

      -
      +

      Informative References

      -
      [RFC8499]
      -
      -"Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", IETF, DOI 10.17487/RFC8499, RFC 8499, January 2019, >.".
      -
      [RFC6839]
      Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", IETF, DOI 10.17487/RFC6839, RFC 6839, , <https://www.rfc-editor.org/info/rfc6839>.
      diff --git a/docs/draft-ietf-dconn-domainconnect-04.pdf b/docs/draft-ietf-dconn-domainconnect-04.pdf index b4d6f24..a7e4e8a 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 76e3837..cf4755d 100644 --- a/docs/draft-ietf-dconn-domainconnect-04.txt +++ b/docs/draft-ietf-dconn-domainconnect-04.txt @@ -81,7 +81,7 @@ Table of Contents 6.2. Template Record . . . . . . . . . . . . . . . . . . . . . 23 6.3. Template Considerations . . . . . . . . . . . . . . . . . 30 6.3.1. Template Scope . . . . . . . . . . . . . . . . . . . 30 - 6.3.2. Sub Domains . . . . . . . . . . . . . . . . . . . . . 31 + 6.3.2. Sub Domains . . . . . . . . . . . . . . . . . . . . . 30 6.3.3. Variable Scope Minimisation . . . . . . . . . . . . . 31 6.4. Public Key Publication . . . . . . . . . . . . . . . . . 31 7. DNS Provider Discovery . . . . . . . . . . . . . . . . . . . 34 @@ -128,15 +128,15 @@ Internet-Draft Domain Connect July 2026 10.4.1. Conflict Detection Special Handling . . . . . . . . 59 10.5. Calculating Conflict Resolution . . . . . . . . . . . . 60 10.6. User Authorization of Changes . . . . . . . . . . . . . 61 - 10.7. Template Application . . . . . . . . . . . . . . . . . . 61 + 10.7. Template Application . . . . . . . . . . . . . . . . . . 62 10.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 11.1. Template Variable Phishing . . . . . . . . . . . . . . . 62 - 11.2. Untrusted DNS Provider Discovery Records . . . . . . . . 62 + 11.2. Untrusted DNS Provider Discovery Records . . . . . . . . 63 11.3. Underscored Host Names . . . . . . . . . . . . . . . . . 63 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 12.1. Registration Procedure for Domain Connect Registries . . 64 - 12.2. Domain Connect Fully Specified Record Types Registry . . 64 + 12.2. Domain Connect Fully Specified Record Types Registry . . 65 12.3. Domain Connect Settings Properties Registry . . . . . . 67 12.4. Domain Connect Template Properties Registry . . . . . . 69 12.5. Guidance to the DNS Resource Record (RR) TYPEs @@ -147,7 +147,7 @@ Internet-Draft Domain Connect July 2026 Implementation Status . . . . . . . . . . . . . . . . . . . . . . 73 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 74 Change History . . . . . . . . . . . . . . . . . . . . . . . . . 74 - Normative References . . . . . . . . . . . . . . . . . . . . . . 78 + Normative References . . . . . . . . . . . . . . . . . . . . . . 79 Informative References . . . . . . . . . . . . . . . . . . . . . 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 81 A.1. Example Template . . . . . . . . . . . . . . . . . . . . 81 @@ -273,7 +273,7 @@ Internet-Draft Domain Connect July 2026 capitals, as shown here. The Terms like "*Registrar*", "*Authoritative server*", "*Zone*", - "*Zone Apex*" or "*Sub Domain*" are used as defined in [RFC8499]. + "*Zone Apex*" or "*Sub Domain*" are used as defined in [RFC9499]. @@ -1184,11 +1184,7 @@ Internet-Draft Domain Connect July 2026 | | | |work only when both | | | | |"domain" and "host" | | | | |apply parameters are | - | | | |provided, for example | - | | | |when the template | - | | | |contains a CNAME record | - | | | |targeted at the fully | - | | | |qualified domain name. | + | | | |provided. | | | | |The default is "false". | +-------------+--------+-------------------+------------------------+ |*Critical |Array of|crit |(OPTIONAL) A list of the| @@ -1222,8 +1218,12 @@ Internet-Draft Domain Connect July 2026 track extensions, and vendor-specific additions, the property name space is partitioned as follows: - - + * Property names without any prefix are reserved for this + specification and for future standards-track extensions that + normatively require this document as their base. Such names are + managed through the IANA "Domain Connect Template Properties" + registry (see Section 12.4). Implementations MUST NOT introduce + private or vendor-specific properties using unprefixed names. @@ -1234,13 +1234,6 @@ Kowalik, et al. Expires 4 January 2027 [Page 22] Internet-Draft Domain Connect July 2026 - * Property names without any prefix are reserved for this - specification and for future standards-track extensions that - normatively require this document as their base. Such names are - managed through the IANA "Domain Connect Template Properties" - registry (see Section 12.4). Implementations MUST NOT introduce - private or vendor-specific properties using unprefixed names. - * Property names beginning with "vnd." are reserved for vendor- specific and private use. A vendor SHOULD further namespace such properties with a vendor identifier (e.g. "vnd.example.fooBar"), @@ -1282,14 +1275,6 @@ Internet-Draft Domain Connect July 2026 Section 9.1). Variables are replaced with values when the template is applied. - - - -Kowalik, et al. Expires 4 January 2027 [Page 23] - -Internet-Draft Domain Connect July 2026 - - Each record MUST contain the following elements unless otherwise specified. @@ -1298,6 +1283,13 @@ Internet-Draft Domain Connect July 2026 "Type": JSON key: "type" + + +Kowalik, et al. Expires 4 January 2027 [Page 23] + +Internet-Draft Domain Connect July 2026 + + Type: "enum" (REQUIRED) Describes the type of record in DNS, or the operation @@ -1338,14 +1330,6 @@ Internet-Draft Domain Connect July 2026 (OPTIONAL) This parameter identifies the group the record belongs to when applying changes. - - - -Kowalik, et al. Expires 4 January 2027 [Page 24] - -Internet-Draft Domain Connect July 2026 - - The value MUST conform to the dc-id syntax (see Section 3) and MUST NOT contain variable expressions. @@ -1354,6 +1338,14 @@ Internet-Draft Domain Connect July 2026 Type: "enum" + + + +Kowalik, et al. Expires 4 January 2027 [Page 24] + +Internet-Draft Domain Connect July 2026 + + (OPTIONAL) This parameter indicates how the record is treated during conflict detection with existing templates. @@ -1395,13 +1387,6 @@ Internet-Draft Domain Connect July 2026 Type: "String" - - -Kowalik, et al. Expires 4 January 2027 [Page 25] - -Internet-Draft Domain Connect July 2026 - - The name for the SRV record. This value is relative to the applied host and domain. A value of @@ -1410,6 +1395,13 @@ Internet-Draft Domain Connect July 2026 When used in a template definition, the value MUST conform to the dc-host-tmpl syntax (see Section 3). + + +Kowalik, et al. Expires 4 January 2027 [Page 25] + +Internet-Draft Domain Connect July 2026 + + After variable substitution, the resolved value MUST conform to the domain-name syntax (see Section 3). @@ -1442,22 +1434,6 @@ Internet-Draft Domain Connect July 2026 After variable substitution, the resolved value MUST conform to the dc-ttl-value syntax. - - - - - - - - - - - -Kowalik, et al. Expires 4 January 2027 [Page 26] - -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 @@ -1468,8 +1444,20 @@ Internet-Draft Domain Connect July 2026 order to avoid necessity of per provider adjustment to the application flow. + Records forming the same RRset (i.e., sharing "host"/"name" and + record type) SHOULD be given the same "ttl" value in the template + definition, since [RFC2181] Section 5.2 requires all resource + records in an RRset to share a single TTL. + Support of variables in this field is OPTIONAL for DNS Provider. + + +Kowalik, et al. Expires 4 January 2027 [Page 26] + +Internet-Draft Domain Connect July 2026 + + "Data": JSON key: "data" @@ -1506,14 +1494,6 @@ Internet-Draft Domain Connect July 2026 Type: "String" - - - -Kowalik, et al. Expires 4 January 2027 [Page 27] - -Internet-Draft Domain Connect July 2026 - - The prefix to detect conflicts when txtConflict-MatchingMode is "Prefix". See below (Section 10.4). @@ -1527,6 +1507,13 @@ Internet-Draft Domain Connect July 2026 The priority for an MX or SRV record. + + +Kowalik, et al. Expires 4 January 2027 [Page 27] + +Internet-Draft Domain Connect July 2026 + + When used in a template definition, the value MUST conform to the dc-uint16-tmpl syntax (see Section 3). @@ -1563,13 +1550,6 @@ Internet-Draft Domain Connect July 2026 After variable substitution, the resolved value MUST conform to the dc-uint16-value syntax. - - -Kowalik, et al. Expires 4 January 2027 [Page 28] - -Internet-Draft Domain Connect July 2026 - - The resolved value is further constrained to the range 0-65535 as defined by [RFC6335]. @@ -1582,6 +1562,14 @@ Internet-Draft Domain Connect July 2026 The protocol for the SRV record. + + + +Kowalik, et al. Expires 4 January 2027 [Page 28] + +Internet-Draft Domain Connect July 2026 + + The value MUST conform to the dc-srv-protocol syntax (see Section 3). @@ -1618,6 +1606,18 @@ Internet-Draft Domain Connect July 2026 These are desired rules for the SPF TXT record. These rules SHOULD be merged with other SPFM records into final SPF TXT record. See Section 9.4. The value MUST contain only mechanism + and modifier terms as defined in [RFC7208] Section 5, excluding + 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. + + + + + + @@ -1626,13 +1626,6 @@ Kowalik, et al. Expires 4 January 2027 [Page 29] Internet-Draft Domain Connect July 2026 - and modifier terms as defined in [RFC7208] Section 5, excluding - 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. - +=========+========================================================+ | Type | Required fields | +=========+========================================================+ @@ -1672,16 +1665,6 @@ 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. - - - - - -Kowalik, et al. Expires 4 January 2027 [Page 30] - -Internet-Draft Domain Connect July 2026 - - 6.3.2. Sub Domains The recommended way to configure records on a Sub Domain is to use @@ -1691,6 +1674,14 @@ Internet-Draft Domain Connect July 2026 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 + + + +Kowalik, et al. Expires 4 January 2027 [Page 30] + +Internet-Draft Domain Connect July 2026 + + detection. To add a record at the Zone Apex even when a Sub Domain is specified @@ -1716,7 +1707,7 @@ Internet-Draft Domain Connect July 2026 The value in the template could simply contain "%servercluster%", and the fully qualified string passed in. Alternatively, the value in - the template could contain "%var%.example.com" and a value of "01", + the template could contain "s%var%.example.com" and a value of "01", "02", or "03" passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the @@ -1733,6 +1724,15 @@ Internet-Draft Domain Connect July 2026 + + + + + + + + + Kowalik, et al. Expires 4 January 2027 [Page 31] Internet-Draft Domain Connect July 2026 @@ -3112,18 +3112,18 @@ Internet-Draft Domain Connect July 2026 4. *Resolve variables* - All variable expressions in active template records are substituted with the values provided by the caller, - producing a concrete set of DNS resource records (RRs) to be - applied (see Section 9.2). + producing the Rendered Record Set: a concrete set of DNS resource + records (RRs) to be applied (see Section 9.2). a. abort if rendered RRs are not possible to be applied to the target zone 5. *Perform conflict detection* - The DNS Provider checks the - resolved RR set against the existing zone content according to - the conflict detection rules (see Section 10.4). + Rendered Record Set against the existing zone content according + to the conflict detection rules (see Section 10.4). a. Identify individual zone records that conflict with the - resolved RR set. + Rendered Record Set. b. (only DNS Providers tracking template state): Check each resolved RR against essential records of previously applied @@ -3159,7 +3159,13 @@ Internet-Draft Domain Connect July 2026 a. Remove all records pre-calculated for removal from the zone. - b. Write the resolved RR set to the zone in totality. + b. Write the Rendered Record Set to the zone in totality. + + i. Note: if the Rendered Record Set yields differing "ttl" + values across new and existing RRs that form the same + RRset, the DNS Provider MUST reconcile them to a single + TTL (e.g., by taking the lowest value), per [RFC2181] + Section 5.2 c. (only DNS Providers tracking template state): Record the new template instance for the "domain" and "host" pair and remove @@ -3180,12 +3186,6 @@ Internet-Draft Domain Connect July 2026 "groupId" value appears in the list supplied as the "groupId" apply parameter. Matching is case-sensitive and exact. - 3. If no "groupId" parameter is supplied in the apply request, all - records are active irrespective of whether they carry a - "groupId". - - - @@ -3194,6 +3194,10 @@ Kowalik, et al. Expires 4 January 2027 [Page 57] Internet-Draft Domain Connect July 2026 + 3. If no "groupId" parameter is supplied in the apply request, all + records are active irrespective of whether they carry a + "groupId". + 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 @@ -3229,7 +3233,8 @@ Internet-Draft Domain Connect July 2026 host, unless otherwise specified. * A CNAME record conflicts with any other record on the same host, - and any existing records conflict with a CNAME. + including another CNAME, 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 @@ -3237,11 +3242,6 @@ Internet-Draft Domain Connect July 2026 "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. - - - @@ -3250,6 +3250,9 @@ Kowalik, et al. Expires 4 January 2027 [Page 58] Internet-Draft Domain Connect July 2026 + * 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. @@ -3267,10 +3270,11 @@ Internet-Draft Domain Connect July 2026 the same host whose value starts with "txtConflictMatchingPrefix". - Note: DNS Provider MUST also check applicability of all generated - records to the target DNS zone in its own system. For example it is - very common for DNS provider not to allow CNAME records to be at the - zone apex. + Note: A DNS Provider MUST also check the applicability of all + generated records to the target DNS zone against constraints imposed + by the DNS protocol itself, such as the coexistence rules of + [RFC2181], as well as any other local capabilities, limits or + policies. 10.4.1. Conflict Detection Special Handling @@ -3294,10 +3298,6 @@ Internet-Draft Domain Connect July 2026 such a template MUST be designed so that it does not conflict with itself. -10.4.1.2. Essential Records - - This processing only REQUIRED for DNS Providers that maintain applied - template state. @@ -3306,6 +3306,11 @@ Kowalik, et al. Expires 4 January 2027 [Page 59] Internet-Draft Domain Connect July 2026 +10.4.1.2. Essential Records + + This processing only REQUIRED for DNS Providers that maintain applied + template state. + 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 @@ -3349,11 +3354,6 @@ Internet-Draft Domain Connect July 2026 template whose records conflict with records written by a previously applied template MUST cause the conflicting prior template to be removed in its entirety, unless a conflicting record is explicitly - marked as non essential and eligible for removal. As an example: if - template T1 wrote records A and B, and template T2 is applied with - 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 @@ -3362,6 +3362,11 @@ Kowalik, et al. Expires 4 January 2027 [Page 60] Internet-Draft Domain Connect July 2026 + marked as non essential and eligible for removal. As an example: if + template T1 wrote records A and B, and template T2 is applied with + 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 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. @@ -3403,11 +3408,6 @@ Internet-Draft Domain Connect July 2026 to do so may expose the end user to the risk of malicious changes being applied to the DNS zone. -10.7. Template Application - - In the Synchronous Flow, after authorization is granted, the DNS - Provider applies the template to the DNS zone. - @@ -3418,6 +3418,11 @@ Kowalik, et al. Expires 4 January 2027 [Page 61] Internet-Draft Domain Connect July 2026 +10.7. Template Application + + In the Synchronous Flow, after authorization is granted, the DNS + Provider applies the template to the DNS zone. + 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. @@ -3455,6 +3460,20 @@ Internet-Draft Domain Connect July 2026 treated as susceptible to phishing by default, and DNS Providers display the additional warnings described in Section 10.6. + + + + + + + + + +Kowalik, et al. Expires 4 January 2027 [Page 62] + +Internet-Draft Domain Connect July 2026 + + 11.2. Untrusted DNS Provider Discovery Records DNS Provider Discovery (see Section 7) requires the Service Provider @@ -3467,13 +3486,6 @@ 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 62] - -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 @@ -3510,6 +3522,14 @@ Internet-Draft Domain Connect July 2026 these underscored names to infrastructure under an attacker's control, causing the user to authorize what appears to be an ordinary change while in fact delegating certificate issuance, DKIM key + + + +Kowalik, et al. Expires 4 January 2027 [Page 63] + +Internet-Draft Domain Connect July 2026 + + publication, or DMARC policy. Legitimate uses of an underscored "host" value exist but are rare. @@ -3519,17 +3539,6 @@ 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 63] - -Internet-Draft Domain Connect July 2026 - - 12. IANA Considerations 12.1. Registration Procedure for Domain Connect Registries @@ -3570,6 +3579,13 @@ Internet-Draft Domain Connect July 2026 expert, that expert SHOULD defer to the judgment of the other experts. + + +Kowalik, et al. Expires 4 January 2027 [Page 64] + +Internet-Draft Domain Connect July 2026 + + 12.2. Domain Connect Fully Specified Record Types Registry IANA is requested to create a new registry named "Domain Connect @@ -3579,13 +3595,6 @@ 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 64] - -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 @@ -3611,7 +3620,7 @@ Internet-Draft Domain Connect July 2026 specification that extends this document. See Section 3, Paragraph 13. - * *Class*: the handling class of the type. The value MUST be one of + * *Handling*: the handling of the type. The value MUST be one of "Fully Specified" (RDATA broken into dedicated template fields) or "Computed" (records derived by a defined computation). A "Reserved" entry MAY leave this field unassigned. @@ -3625,15 +3634,6 @@ Internet-Draft Domain Connect July 2026 "Computed" type, a "Reserved" type, or any other type for which no corresponding DNS RR TYPE exists or would be meaningful, the value MUST be "N/A". Where a "Fully Specified" type would use a name - that is not yet a registered DNS RR TYPE, or where an entry is - registered with a "DNS RR TYPE" of "N/A" (such as a "Computed" - type), the designated experts SHOULD coordinate with the - designated experts of the "Resource Record (RR) TYPEs" registry - before completing the registration, to confirm that the chosen - name does not collide with an existing or anticipated DNS RR TYPE. - - - @@ -3642,6 +3642,13 @@ Kowalik, et al. Expires 4 January 2027 [Page 65] Internet-Draft Domain Connect July 2026 + that is not yet a registered DNS RR TYPE, or where an entry is + registered with a "DNS RR TYPE" of "N/A" (such as a "Computed" + type), the designated experts SHOULD coordinate with the + designated experts of the "Resource Record (RR) TYPEs" registry + 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 @@ -3656,7 +3663,7 @@ Internet-Draft Domain Connect July 2026 Status: One of "Active", "Deprecated", or "Reserved". - Class: "Fully Specified" or "Computed"; omitted for a "Reserved" + Handling: "Fully Specified" or "Computed"; omitted for a "Reserved" entry. DNS RR TYPE: The name of the corresponding IANA DNS RR TYPE, or "N/ @@ -3682,13 +3689,6 @@ Internet-Draft Domain Connect July 2026 - - - - - - - @@ -3698,42 +3698,42 @@ Kowalik, et al. Expires 4 January 2027 [Page 66] Internet-Draft Domain Connect July 2026 - +=============+========+===========+=======+========+=============+ - | *RR Type* |*Status*| *Class* |*DNS RR|*Kind* | *Reference* | - | | | |TYPE* | | | - +=============+========+===========+=======+========+=============+ - | "A" |Active | Fully |"A" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "AAAA" |Active | Fully |"AAAA" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "CNAME" |Active | Fully |"CNAME"|IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "MX" |Active | Fully |"MX" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "TXT" |Active | Fully |"TXT" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "SRV" |Active | Fully |"SRV" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "NS" |Active | Fully |"NS" |IETF | This | - | | | Specified | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "SPFM" |Active | Computed |"N/A" |IETF | This | - | | | | |Standard| document | - +-------------+--------+-----------+-------+--------+-------------+ - | "APEXCNAME" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | - +-------------+--------+-----------+-------+--------+-------------+ - | "REDIR301" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | - +-------------+--------+-----------+-------+--------+-------------+ - | "REDIR302" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | - +-------------+--------+-----------+-------+--------+-------------+ - - Table 9: Initial Domain Connect Fully Specified Record Types + +=============+========+============+=======+========+=============+ + | *RR Type* |*Status*| *Handling* |*DNS RR|*Kind* | *Reference* | + | | | |TYPE* | | | + +=============+========+============+=======+========+=============+ + | "A" |Active | Fully |"A" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "AAAA" |Active | Fully |"AAAA" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "CNAME" |Active | Fully |"CNAME"|IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "MX" |Active | Fully |"MX" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "TXT" |Active | Fully |"TXT" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "SRV" |Active | Fully |"SRV" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "NS" |Active | Fully |"NS" |IETF | This | + | | | Specified | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "SPFM" |Active | Computed |"N/A" |IETF | This | + | | | | |Standard| document | + +-------------+--------+------------+-------+--------+-------------+ + | "APEXCNAME" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | + +-------------+--------+------------+-------+--------+-------------+ + | "REDIR301" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | + +-------------+--------+------------+-------+--------+-------------+ + | "REDIR302" |Reserved| Computed |"N/A" |Other | [DC-SPEC] | + +-------------+--------+------------+-------+--------+-------------+ + + Table 9: Initial Domain Connect Fully Specified Record Types 12.3. Domain Connect Settings Properties Registry @@ -4168,6 +4168,16 @@ Internet-Draft Domain Connect July 2026 * Added dc-template-property, dc-unprefixed-property, and dc-vnd- property to Terminology. + * Corrected nits from early Dnsdir review. + + * Clarified RR placement constraints arising from the DNS protocol. + + * Noted RRset TTL consistency requirements in Template Record and + Steps to Apply a Template. + + * Introduced Rendered Record Set terminology in Steps to Apply a + Template to disambiguate from RRset. + Change from draft-ietf-dconn-domainconnect-02 to -03 * Classified template record types as Fully Specified, Computed, or @@ -4185,6 +4195,13 @@ Change from draft-ietf-dconn-domainconnect-02 to -03 * Added Untrusted DNS Provider Discovery Records to Security Considerations. + + +Kowalik, et al. Expires 4 January 2027 [Page 75] + +Internet-Draft Domain Connect July 2026 + + * Clarified handling of multiple "_domainconnect" TXT records in DNS Provider Discovery. @@ -4194,14 +4211,6 @@ Change from draft-ietf-dconn-domainconnect-02 to -03 * Clarified one-host-one-key rule in Public Key Publication. - - - -Kowalik, et al. Expires 4 January 2027 [Page 75] - -Internet-Draft Domain Connect July 2026 - - * Added Media Type Registration for application/ domainconnect-template+json in IANA Considerations. @@ -4239,15 +4248,6 @@ Change from draft-ietf-dconn-domainconnect-00 to -01 replaced informal prose constraints throughout parameter tables and field definitions with normative ABNF references. - * Restructured Template Application: added Group Filtering, - Essential Records, Steps to Apply a Template, and focused Conflict - Detection, User Authorization of Changes subsections; moved UX and - runtime-processing rules into their appropriate sections; moved - Domain Connect Objects and Templates before Applying Domain - Connect in the document structure. - - * Restructured request signing into Signing Procedure, Signature - Verification, and Public Key Publication @@ -4258,6 +4258,16 @@ Kowalik, et al. Expires 4 January 2027 [Page 76] Internet-Draft Domain Connect July 2026 + * Restructured Template Application: added Group Filtering, + Essential Records, Steps to Apply a Template, and focused Conflict + Detection, User Authorization of Changes subsections; moved UX and + runtime-processing rules into their appropriate sections; moved + Domain Connect Objects and Templates before Applying Domain + Connect in the document structure. + + * Restructured request signing into Signing Procedure, Signature + Verification, and Public Key Publication + * Replaced Sync Apply Interaction with a normative Request/Response/ Error structure; rewrote Verification of Changes as normative text. @@ -4295,6 +4305,15 @@ Change from -00 to -01 * Added Trust Model + + + + +Kowalik, et al. Expires 4 January 2027 [Page 77] + +Internet-Draft Domain Connect July 2026 + + * Added sequence diagrams for synchronous and asynchronous flows instead of UX mocks @@ -4306,14 +4325,6 @@ Change from -00 to -01 * All URLs are now normatively defined with URI templates - - - -Kowalik, et al. Expires 4 January 2027 [Page 77] - -Internet-Draft Domain Connect July 2026 - - Change from draft-kowalik-regext-domainconnect-00 to draft-kowalik- domainconnect-00 @@ -4351,6 +4362,14 @@ Change from draft-carney-regext-domainconnect-00 to -01 * Minor edits and clarifications found during implementation. + + + +Kowalik, et al. Expires 4 January 2027 [Page 78] + +Internet-Draft Domain Connect July 2026 + + Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and @@ -4363,13 +4382,6 @@ Normative References DOI 10.17487/RFC2782, RFC 2782, February 2000, . - - -Kowalik, et al. Expires 4 January 2027 [Page 78] - -Internet-Draft Domain Connect July 2026 - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", IETF, DOI 10.17487/RFC2119, BCP 14, RFC 2119, March 1997, @@ -4403,6 +4415,17 @@ Internet-Draft Domain Connect July 2026 IETF, DOI 10.17487/RFC8552, BCP 222, RFC 8552, March 2019, . + + + + + + +Kowalik, et al. Expires 4 January 2027 [Page 79] + +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, @@ -4419,13 +4442,6 @@ Internet-Draft Domain Connect July 2026 DOI 10.17487/RFC6335, BCP 165, RFC 6335, August 2011, . - - -Kowalik, et al. Expires 4 January 2027 [Page 79] - -Internet-Draft Domain Connect July 2026 - - [RFC6895] 3rd, D. E., "Domain Name System (DNS) IANA Considerations", IETF, DOI 10.17487/RFC6895, BCP 42, RFC 6895, April 2013, @@ -4459,6 +4475,13 @@ Internet-Draft Domain Connect July 2026 Subsets", IETF, DOI 10.17487/RFC9839, RFC 9839, August 2025, . + + +Kowalik, et al. Expires 4 January 2027 [Page 80] + +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, @@ -4473,25 +4496,16 @@ Internet-Draft Domain Connect July 2026 DOI 10.17487/RFC6838, BCP 13, RFC 6838, January 2013, . - - - - -Kowalik, et al. Expires 4 January 2027 [Page 80] - -Internet-Draft Domain Connect July 2026 - - [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", IETF, STD 97, DOI 10.17487/RFC9110, BCP 97, RFC 9110, June 2022, . -Informative References + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", IETF, DOI 10.17487/RFC2181, RFC 2181, July + 1997, . - [RFC8499] "Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS - Terminology", IETF, DOI 10.17487/RFC8499, RFC 8499, - January 2019, >.". +Informative References [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", IETF, DOI 10.17487/RFC6839, @@ -4514,20 +4528,6 @@ A.1. Example Template - - - - - - - - - - - - - - diff --git a/docs/draft-ietf-dconn-domainconnect-04.xml b/docs/draft-ietf-dconn-domainconnect-04.xml index 3288d2d..7858721 100644 --- a/docs/draft-ietf-dconn-domainconnect-04.xml +++ b/docs/draft-ietf-dconn-domainconnect-04.xml @@ -96,7 +96,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. -The Terms like "Registrar", "Authoritative server", "Zone", "Zone Apex" or "Sub Domain" are used as defined in . +The Terms like "Registrar", "Authoritative server", "Zone", "Zone Apex" or "Sub Domain" are used as defined in . This specification uses the Augmented Backus-Naur Form (ABNF) notation of . The following ABNF rules are imported from the normative references . @@ -479,7 +479,7 @@ dc-srv-service = dc-underscore-label The template JSON structure defined in this section is identified by the media type "application/domainconnect-template+json" (see ). -properties of the template definition
      Data ElementTypeKeyDescription
      Service Provider IdStringproviderId(REQUIRED) The unique identifier of the Service Provider that created this template. This is used in the URLs to identify the Service Provider.
      The value MUST conform to the dc-id syntax (see ).
      To ensure non-coordinated uniqueness, this SHOULD be the domain name of the Service Provider (e.g. exampleservice.example).
      Service Provider NameStringproviderName(REQUIRED) The name of the Service Provider, suitable for display to the user.
      The value MUST conform to the dc-display-name syntax (see ).
      Service IdStringserviceId(REQUIRED) The name or identifier of the template. This is used in URLs to identify the template.
      The value MUST conform to the dc-id syntax (see ).
      Service NameStringserviceName(REQUIRED) The name of the service, suitable for display to the user.
      The value MUST conform to the dc-display-name syntax (see ).
      VersionIntegerversion(OPTIONAL) If present this represents a version of the template and SHOULD be changed with each update of the template content. This opaque value is mainly informational to improve communication and transparency between providers.
      The value MUST conform to the dc-version syntax (see ).
      This is a strict subset of the "JSON number": a positive integer with no leading zeros, no fractional part, and no exponent part.
      Template Specification VersionIntegertemplateSpecVersion(OPTIONAL) The version of the Domain Connect template specification that the template conforms to. This identifies the template format and processing rules defined by this document and its successors.
      The value MUST conform to the dc-version syntax (see ). For templates conforming to this document, the value is "1".
      LogoStringlogoUrl(OPTIONAL) A graphical logo representing the Service Provider and/or Service for use in any web-based flow. If present this MAY be displayed to the user on the DNS Provider consent UX.
      When present, the value MUST be a valid URI with scheme "https".
      DescriptionStringdescription(OPTIONAL) A textual description of what this template does, intended for developer reference. This value is not intended for display to the end user.
      The value MUST conform to the dc-description-text syntax (see ).
      Variable DescriptionStringvariableDescription(OPTIONAL) A textual description of the template variables, intended for developer reference. This value is not intended for display to the end user.
      The value MUST conform to the dc-description-text syntax (see ).
      Synchronous BlockBooleansyncBlock(OPTIONAL) When "true", indicates that this template does not support the synchronous flow. The DNS Provider MUST refuse a synchronous apply request for this template and MUST return an appropriate error to the user.
      The default is "false".
      SharedBooleanshared(OPTIONAL) This flag has been deprecated. It used to indicate that the template allowed a dynamic "providerName" on the query string. It is replaced with the "sharedProviderName" flag in v2.2 of the spec.
      Shared Provider NameBooleansharedProviderName(OPTIONAL) When "true", indicates that the caller MAY supply an additional "providerName" parameter at apply time.
      The default is "false".
      For backward compatibility with DNS Providers prior to v2.2, it is RECOMMENDED that the deprecated "shared" flag also be set.
      Shared Service NameBooleansharedServiceName(OPTIONAL) When "true", indicates that the caller MAY supply an additional "serviceName" parameter at apply time.
      The default is "false".
      Synchronous Public Key DomainStringsyncPubKeyDomain(OPTIONAL) The domain name under which the Service Provider's public signing key TXT record is published. When present, this field signals that digital signing is required for synchronous apply requests.
      The value MUST conform to the dc-pubkey-domain syntax (see ).
      Synchronous Redirect DomainsStringsyncRedirectDomain(OPTIONAL) A comma-separated list of domain names to which the DNS Provider is permitted to send the post-apply redirect in the synchronous flow.
      The value MUST conform to the "dc-host-list" syntax (see ).
      Multiple InstanceBooleanmultiInstance(OPTIONAL) When "true", indicates that the template is designed to be applied multiple times to the same domain and host.
      The default is "false".
      Warn PhishingBooleanwarnPhishing(DEPRECATED) This flag is deprecated and its code point is reserved (see ). Phishing warnings are now the default behavior in the absence of other security mechanisms (see ). This flag MUST NOT be relied upon and MUST NOT be set in new templates. A DNS Provider MUST NOT treat the absence of this flag as a signal that a template is not susceptible to phishing.
      Host RequiredBooleanhostRequired(OPTIONAL) When "true", indicates that the template is designed to work only when both "domain" and "host" apply parameters are provided, for example when the template contains a CNAME record targeted at the fully qualified domain name.
      The default is "false".
      Critical PropertiesArray of Stringcrit(OPTIONAL) A list of the names of template properties that an implementation is required to understand and process for the template to be applied correctly.
      Each entry MUST conform to the dc-template-property syntax (see ).
      When present, the "crit" property MUST NOT be empty.
      Template RecordsArray of Template Recordsrecords(REQUIRED) A list of records for the template.
      +properties of the template definition
      Data ElementTypeKeyDescription
      Service Provider IdStringproviderId(REQUIRED) The unique identifier of the Service Provider that created this template. This is used in the URLs to identify the Service Provider.
      The value MUST conform to the dc-id syntax (see ).
      To ensure non-coordinated uniqueness, this SHOULD be the domain name of the Service Provider (e.g. exampleservice.example).
      Service Provider NameStringproviderName(REQUIRED) The name of the Service Provider, suitable for display to the user.
      The value MUST conform to the dc-display-name syntax (see ).
      Service IdStringserviceId(REQUIRED) The name or identifier of the template. This is used in URLs to identify the template.
      The value MUST conform to the dc-id syntax (see ).
      Service NameStringserviceName(REQUIRED) The name of the service, suitable for display to the user.
      The value MUST conform to the dc-display-name syntax (see ).
      VersionIntegerversion(OPTIONAL) If present this represents a version of the template and SHOULD be changed with each update of the template content. This opaque value is mainly informational to improve communication and transparency between providers.
      The value MUST conform to the dc-version syntax (see ).
      This is a strict subset of the "JSON number": a positive integer with no leading zeros, no fractional part, and no exponent part.
      Template Specification VersionIntegertemplateSpecVersion(OPTIONAL) The version of the Domain Connect template specification that the template conforms to. This identifies the template format and processing rules defined by this document and its successors.
      The value MUST conform to the dc-version syntax (see ). For templates conforming to this document, the value is "1".
      LogoStringlogoUrl(OPTIONAL) A graphical logo representing the Service Provider and/or Service for use in any web-based flow. If present this MAY be displayed to the user on the DNS Provider consent UX.
      When present, the value MUST be a valid URI with scheme "https".
      DescriptionStringdescription(OPTIONAL) A textual description of what this template does, intended for developer reference. This value is not intended for display to the end user.
      The value MUST conform to the dc-description-text syntax (see ).
      Variable DescriptionStringvariableDescription(OPTIONAL) A textual description of the template variables, intended for developer reference. This value is not intended for display to the end user.
      The value MUST conform to the dc-description-text syntax (see ).
      Synchronous BlockBooleansyncBlock(OPTIONAL) When "true", indicates that this template does not support the synchronous flow. The DNS Provider MUST refuse a synchronous apply request for this template and MUST return an appropriate error to the user.
      The default is "false".
      SharedBooleanshared(OPTIONAL) This flag has been deprecated. It used to indicate that the template allowed a dynamic "providerName" on the query string. It is replaced with the "sharedProviderName" flag in v2.2 of the spec.
      Shared Provider NameBooleansharedProviderName(OPTIONAL) When "true", indicates that the caller MAY supply an additional "providerName" parameter at apply time.
      The default is "false".
      For backward compatibility with DNS Providers prior to v2.2, it is RECOMMENDED that the deprecated "shared" flag also be set.
      Shared Service NameBooleansharedServiceName(OPTIONAL) When "true", indicates that the caller MAY supply an additional "serviceName" parameter at apply time.
      The default is "false".
      Synchronous Public Key DomainStringsyncPubKeyDomain(OPTIONAL) The domain name under which the Service Provider's public signing key TXT record is published. When present, this field signals that digital signing is required for synchronous apply requests.
      The value MUST conform to the dc-pubkey-domain syntax (see ).
      Synchronous Redirect DomainsStringsyncRedirectDomain(OPTIONAL) A comma-separated list of domain names to which the DNS Provider is permitted to send the post-apply redirect in the synchronous flow.
      The value MUST conform to the "dc-host-list" syntax (see ).
      Multiple InstanceBooleanmultiInstance(OPTIONAL) When "true", indicates that the template is designed to be applied multiple times to the same domain and host.
      The default is "false".
      Warn PhishingBooleanwarnPhishing(DEPRECATED) This flag is deprecated and its code point is reserved (see ). Phishing warnings are now the default behavior in the absence of other security mechanisms (see ). This flag MUST NOT be relied upon and MUST NOT be set in new templates. A DNS Provider MUST NOT treat the absence of this flag as a signal that a template is not susceptible to phishing.
      Host RequiredBooleanhostRequired(OPTIONAL) When "true", indicates that the template is designed to work only when both "domain" and "host" apply parameters are provided.
      The default is "false".
      Critical PropertiesArray of Stringcrit(OPTIONAL) A list of the names of template properties that an implementation is required to understand and process for the template to be applied correctly.
      Each entry MUST conform to the dc-template-property syntax (see ).
      When present, the "crit" property MUST NOT be empty.
      Template RecordsArray of Template Recordsrecords(REQUIRED) A list of records for the template.
      Template Property Extensibility @@ -591,7 +591,7 @@ dc-srv-service = dc-underscore-label After variable substitution, the resolved value MUST conform to the presentation format of the corresponding resource record type.
      -
      "TTL":
      JSON key:
      "ttl" +
      "TTL":
      JSON key:
      "ttl"
      Type:
      "Int" or string representation of "Int"
      @@ -603,7 +603,9 @@ dc-srv-service = dc-underscore-label 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 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 value, rather pick the nearest supported value or a default, in order to avoid necessity of per provider adjustment to the application flow. -Support of variables in this field is OPTIONAL for DNS Provider. +Records forming the same RRset (i.e., sharing "host"/"name" and record type) SHOULD be given the same "ttl" value in the template definition, since Section 5.2 requires all resource records in an RRset to share a single TTL. + +Support of variables in this field is OPTIONAL for DNS Provider.
      "Data":
      JSON key:
      "data" @@ -719,7 +721,7 @@ dc-srv-service = dc-underscore-label Fields per record type
      TypeRequired fields
      "A""host", "pointsTo", "ttl"
      "AAAA""host", "pointsTo", "ttl"
      "CNAME""host", "pointsTo", "ttl" ("host" MUST NOT be "@" or empty unless "hostRequired" is "true" in the template)
      "NS""host", "pointsTo", "ttl"
      "TXT""host", "data", "ttl", "txtConflictMatchingMode", "txtConflictMatchingPrefix"
      "MX""host", "pointsTo", "ttl", "priority"
      "SRV""name", "target", "ttl", "priority", "protocol", "service", "weight", "port"
      "SPFM""host", "spfRules"
      Generic types"host", "data", "ttl"
      -
      Template Considerations +
      Template Considerations
      Template Scope @@ -737,13 +739,13 @@ dc-srv-service = dc-underscore-label When a template is not applicable at the Zone Apex - for example because it contains a CNAME record or any other record type that is incompatible with Apex placement - the "hostRequired" flag SHOULD be set to "true" in the template definition (see hostRequired).
      -
      Variable Scope Minimisation +
      Variable Scope Minimisation It is noted that as a best practice the variable portions SHOULD be constrained to as small as possible a portion of the resulting DNS record. For example, say a Service Provider requires a CNAME of one of three values for their users: "s01.example.com", "s02.example.com", and "s03.example.com". -The value in the template could simply contain "%servercluster%", and the fully qualified string passed in. Alternatively, the value in the template could contain "%var%.example.com" and a value of "01", "02", or "03" passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the template. +The value in the template could simply contain "%servercluster%", and the fully qualified string passed in. Alternatively, the value in the template could contain "s%var%.example.com" and a value of "01", "02", or "03" passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the template.
      @@ -1235,15 +1237,15 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all The following steps give an overview of the template application process. Each step is described in detail in the sections below. -
      1. Verify template applicability - For synchronous flow requests, the DNS Provider MUST verify that the template's "syncBlock" field is not "true". If it is, the DNS Provider MUST NOT process the request and MUST return an error.
        2. +
        1. Verify template applicability - For synchronous flow requests, the DNS Provider MUST verify that the template's "syncBlock" field is not "true". If it is, the DNS Provider MUST NOT process the request and MUST return an error.
        2. Verify zone ownership - The DNS Provider MUST verify that the target zone identified by "domain" is present in the user's account and that the user is authorized to make changes to it.
        3. Filter records to apply - select records applicable for further processing based on "groupId" property of the template and "groupId" apply parameter (see ).
          4. -
        4. Resolve variables - All variable expressions in active template records are substituted with the values provided by the caller, producing a concrete set of DNS resource records (RRs) to be applied (see ). +
        5. Resolve variables - All variable expressions in active template records are substituted with the values provided by the caller, producing the Rendered Record Set: a concrete set of DNS resource records (RRs) to be applied (see ).
          1. abort if rendered RRs are not possible to be applied to the target zone
          6. -
        6. Perform conflict detection - The DNS Provider checks the resolved RR set against the existing zone content according to the conflict detection rules (see ). -
          1. Identify individual zone records that conflict with the resolved RR set.
            2. +
          2. Perform conflict detection - The DNS Provider checks the Rendered Record Set against the existing zone content according to the conflict detection rules (see ). +
            1. Identify individual zone records that conflict with the Rendered Record Set.
            2. (only DNS Providers tracking template state): Check each resolved RR against essential records of previously applied templates. Identify which previously applied templates own conflicting records and would be removed in their entirety (see ).
            3. (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 ).
            @@ -1254,8 +1256,11 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
        7. Apply changes - After authorization is granted, or at later point in Asynchronous flow: -
          1. Remove all records pre-calculated for removal from the zone.
            2. -
          2. Write the resolved RR set to the zone in totality.
            3. +
            1. Remove all records pre-calculated for removal from the zone.
              2. +
            2. Write the Rendered Record Set to the zone in totality. +
              1. Note: if the Rendered Record Set yields differing "ttl" values across new and existing RRs that form the same RRset, the DNS Provider MUST reconcile them to a single TTL (e.g., by taking the lowest value), per Section 5.2
                2. +
              +
            3. (only DNS Providers tracking template state): Record the new template instance for the "domain" and "host" pair and remove the state of any template instances that were resolved for removal.
            @@ -1287,7 +1292,7 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all Conflict detection is performed by the DNS Provider prior to template application. The rules below ensure predictable conflict resolution between DNS Providers. Each rule applies to records on the same host, unless otherwise specified. -
            • A CNAME record conflicts with any other record on the same host, and any existing records conflict with a CNAME.
              • +
              • A CNAME record conflicts with any other record on the same host, including another CNAME, 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.
              • 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.
                • @@ -1299,7 +1304,7 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
              -Note: DNS Provider MUST also check applicability of all generated records to the target DNS zone in its own system. For example it is very common for DNS provider not to allow CNAME records to be at the zone apex. +Note: A DNS Provider MUST also check the applicability of all generated records to the target DNS zone against constraints imposed by the DNS protocol itself, such as the coexistence rules of , as well as any other local capabilities, limits or policies.
              Conflict Detection Special Handling @@ -1426,14 +1431,14 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all Each entry in the registry MUST include: -
              • RR Type: the record type name as it appears in a template record "type" field. The value MUST conform to the dc-type-name syntax (see ).
                • +
                • RR Type: the record type name as it appears in a template record "type" field. The value MUST conform to the dc-type-name syntax (see ).
                • Status: the lifecycle state of the registration. The following values are defined; IANA MAY define additional values as needed:
                  • "Active": the type is currently in use and its definition is normative.
                  • "Deprecated": the type SHOULD NOT be used in new templates; it MAY appear in existing deployments for backwards compatibility. If the corresponding DNS RR TYPE is marked deprecated or obsolete in the IANA "Resource Record (RR) TYPEs" registry, the entry here SHOULD be set to "Deprecated".
                  • "Reserved": the type appears in earlier versions of the Domain Connect specification (see ) and is reserved for back-compatibility. It MUST NOT be redefined in a manner incompatible with , and MAY only be defined by a specification that extends this document. See .
                  • -
                • Class: the handling class of the type. The value MUST be one of "Fully Specified" (RDATA broken into dedicated template fields) or "Computed" (records derived by a defined computation). A "Reserved" entry MAY leave this field unassigned.
                  • +
                • Handling: the handling of the type. The value MUST be one of "Fully Specified" (RDATA broken into dedicated template fields) or "Computed" (records derived by a defined computation). A "Reserved" entry MAY leave this field unassigned.
                • DNS RR TYPE: the name of the corresponding entry in the IANA "Resource Record (RR) TYPEs" registry within the "Domain Name System (DNS) Parameters" registry group. A "Fully Specified" type SHOULD correspond to a registered DNS RR TYPE of the same name; before registering such a type, the designated experts MUST verify that the named DNS RR TYPE exists in that registry. For a "Computed" type, a "Reserved" type, or any other type for which no corresponding DNS RR TYPE exists or would be meaningful, the value MUST be "N/A". Where a "Fully Specified" type would use a name that is not yet a registered DNS RR TYPE, or where an entry is registered with a "DNS RR TYPE" of "N/A" (such as a "Computed" type), the designated experts SHOULD coordinate with the designated experts of the "Resource Record (RR) TYPEs" registry 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.
                  • @@ -1441,9 +1446,9 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all A registration request MUST provide the following: -
                  RR Type:
                  The record type name (the "type" value), conforming to the dc-type-name syntax (see ). +
                  RR Type:
                  The record type name (the "type" value), conforming to the dc-type-name syntax (see ).
                  Status:
                  One of "Active", "Deprecated", or "Reserved". -
                  Class:
                  "Fully Specified" or "Computed"; omitted for a "Reserved" entry. +
                  Handling:
                  "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. @@ -1451,7 +1456,7 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all The following types from this specification constitute the initial contents of the registry: -Initial Domain Connect Fully Specified Record Types
                  RR TypeStatusClassDNS RR TYPEKindReference
                  "A"ActiveFully Specified"A"IETF StandardThis document
                  "AAAA"ActiveFully Specified"AAAA"IETF StandardThis document
                  "CNAME"ActiveFully Specified"CNAME"IETF StandardThis document
                  "MX"ActiveFully Specified"MX"IETF StandardThis document
                  "TXT"ActiveFully Specified"TXT"IETF StandardThis document
                  "SRV"ActiveFully Specified"SRV"IETF StandardThis document
                  "NS"ActiveFully Specified"NS"IETF StandardThis document
                  "SPFM"ActiveComputed"N/A"IETF StandardThis document
                  "APEXCNAME"ReservedComputed"N/A"Other
                  "REDIR301"ReservedComputed"N/A"Other
                  "REDIR302"ReservedComputed"N/A"Other
                  +Initial Domain Connect Fully Specified Record Types
                  RR TypeStatusHandlingDNS RR TYPEKindReference
                  "A"ActiveFully Specified"A"IETF StandardThis document
                  "AAAA"ActiveFully Specified"AAAA"IETF StandardThis document
                  "CNAME"ActiveFully Specified"CNAME"IETF StandardThis document
                  "MX"ActiveFully Specified"MX"IETF StandardThis document
                  "TXT"ActiveFully Specified"TXT"IETF StandardThis document
                  "SRV"ActiveFully Specified"SRV"IETF StandardThis document
                  "NS"ActiveFully Specified"NS"IETF StandardThis document
                  "SPFM"ActiveComputed"N/A"IETF StandardThis document
                  "APEXCNAME"ReservedComputed"N/A"Other
                  "REDIR301"ReservedComputed"N/A"Other
                  "REDIR302"ReservedComputed"N/A"Other
              Domain Connect Settings Properties Registry @@ -1613,17 +1618,21 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
            • Arnt Gulbrandsen
      -
      Change History +
      Change History -
      Change from draft-ietf-dconn-domainconnect-03 to -04 +
      Change from draft-ietf-dconn-domainconnect-03 to -04 -
      • Added to , reserving the "dc." and "vnd." prefixes and the unprefixed grandfathered parameter names.
        • +
        • 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 .
        • Added and the "crit" property to .
        • Added the "templateSpecVersion" property to .
        • Added the IANA "Domain Connect Template Properties" registry in .
        • Added dc-template-property, dc-unprefixed-property, and dc-vnd-property to .
          • +
        • Corrected nits from early Dnsdir review.
          • +
        • Clarified RR placement constraints arising from the DNS protocol.
          • +
        • Noted RRset TTL consistency requirements in and .
          • +
        • Introduced Rendered Record Set terminology in to disambiguate from RRset.
      @@ -1677,9 +1686,9 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
      -
      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 [RFC8499].
        • Removed example provider names from Service Providers and DNS Providers terminology
        • Added Use Cases
        • Added Trust Model
          • @@ -1727,7 +1736,7 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all
      - + Normative References Domain names - implementation and specification DOMAINDNS This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. IETF A DNS RR for specifying the location of services (DNS SRV) DNS-SRVdomain name systemserviceRRresource record This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] @@ -1752,15 +1761,11 @@ r2.example.com. TXT v=spf1 include:_spf.newsletter.example ~all IETF DNS Terminology vocabularydomain name system The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. IETF Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. IETF HTTP Semantics Hypertext Transfer ProtocolHTTPHTTP semanticsHTTP contentHTTP methodHTTP status code The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. + IETF Clarifications to the DNS Specification DNS-CLARDomainNameSystem This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] - + Informative References - - - Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", IETF, DOI 10.17487/RFC8499, RFC 8499, January 2019, >. - - - IETF Additional Media Type Structured Syntax Suffixes structured syntax suffixmedia type A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. + IETF Additional Media Type Structured Syntax Suffixes structured syntax suffixmedia type A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. Domain Connect Specification, Version 2.3 Rev. 67 diff --git a/draft-ietf-dconn-domainconnect-04.adoc b/draft-ietf-dconn-domainconnect-04.adoc index b8688e1..c4aed50 100644 --- a/draft-ietf-dconn-domainconnect-04.adoc +++ b/draft-ietf-dconn-domainconnect-04.adoc @@ -94,7 +94,7 @@ While Domain Connect offers significant advantages in automating DNS configurati The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. -The Terms like "*Registrar*", "*Authoritative server*", "*Zone*", "*Zone Apex*" or "*Sub Domain*" are used as defined in <>. +The Terms like "*Registrar*", "*Authoritative server*", "*Zone*", "*Zone Apex*" or "*Sub Domain*" are used as defined in <>. This specification uses the Augmented Backus-Naur Form (ABNF) notation of <>. The following ABNF rules are imported from the normative references <>. @@ -627,7 +627,7 @@ The default is `"false"`. |*Host Required* |Boolean |hostRequired -|(OPTIONAL) When `"true"`, indicates that the template is designed to work only when both `"domain"` and `"host"` apply parameters are provided, for example when the template contains a CNAME record targeted at the fully qualified domain name. + +|(OPTIONAL) When `"true"`, indicates that the template is designed to work only when both `"domain"` and `"host"` apply parameters are provided. + The default is `"false"`. @@ -788,7 +788,7 @@ After variable substitution, the resolved value MUST conform to the presentation -- [newline=true] -`"TTL"`:: +[[ttl-record]]`"TTL"`:: + -- [horizontal] @@ -805,6 +805,8 @@ After variable substitution, the resolved value MUST conform to the `dc-ttl-valu 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 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 value, rather pick the nearest supported value or a default, in order to avoid necessity of per provider adjustment to the application flow. +Records forming the same RRset (i.e., sharing `"host"`/`"name"` and record type) SHOULD be given the same `"ttl"` value in the template definition, since <> Section 5.2 requires all resource records in an RRset to share a single TTL. + Support of variables in this field is OPTIONAL for DNS Provider. -- @@ -1009,7 +1011,7 @@ It is noted that as a best practice the variable portions SHOULD be constrained For example, say a Service Provider requires a CNAME of one of three values for their users: `"s01.example.com"`, `"s02.example.com"`, and `"s03.example.com"`. -The value in the template could simply contain `"%servercluster%"`, and the fully qualified string passed in. Alternatively, the value in the template could contain `"%var%.example.com"` and a value of `"01"`, `"02"`, or `"03"` passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the template. +The value in the template could simply contain `"%servercluster%"`, and the fully qualified string passed in. Alternatively, the value in the template could contain `"s%var%.example.com"` and a value of `"01"`, `"02"`, or `"03"` passed in. By placing more fixed data into the template, the template is less prone to error or misuse and allows better review of intent by the DNS Provider when onboarding the template. [[pubkey-publication]] === Public Key Publication @@ -1859,10 +1861,10 @@ Each step is described in detail in the sections below. . *Verify template applicability* — For synchronous flow requests, the DNS Provider MUST verify that the template's `"syncBlock"` field is not `"true"`. If it is, the DNS Provider MUST NOT process the request and MUST return an error. . *Verify zone ownership* — The DNS Provider MUST verify that the target zone identified by `"domain"` is present in the user's account and that the user is authorized to make changes to it. . *Filter records to apply* - select records applicable for further processing based on `"groupId"` property of the template and `"groupId"` apply parameter (see <>). -. *Resolve variables* — All variable expressions in active template records are substituted with the values provided by the caller, producing a concrete set of DNS resource records (RRs) to be applied (see <>). +. *Resolve variables* — All variable expressions in active template records are substituted with the values provided by the caller, producing the Rendered Record Set: a concrete set of DNS resource records (RRs) to be applied (see <>). .. abort if rendered RRs are not possible to be applied to the target zone -. *Perform conflict detection* — The DNS Provider checks the resolved RR set against the existing zone content according to the conflict detection rules (see <>). - .. Identify individual zone records that conflict with the resolved RR set. +. *Perform conflict detection* — The DNS Provider checks the Rendered Record Set against the existing zone content according to the conflict detection rules (see <>). + .. Identify individual zone records that conflict with the Rendered Record Set. .. (only DNS Providers tracking template state): Check each resolved RR against essential records of previously applied templates. Identify which previously applied templates own conflicting records and would be removed in their entirety (see <>). .. (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 <>). . *Pre-calculate conflict resolution* — Determine the full set of records and, @@ -1873,7 +1875,8 @@ Each step is described in detail in the sections below. .. abort if authorization not granted . *Apply changes* — After authorization is granted, or at later point in Asynchronous flow: .. Remove all records pre-calculated for removal from the zone. - .. Write the resolved RR set to the zone in totality. + .. Write the Rendered Record Set to the zone in totality. + ... Note: if the Rendered Record Set yields differing `"ttl"` values across new and existing RRs that form the same RRset, the DNS Provider MUST reconcile them to a single TTL (e.g., by taking the lowest value), per <> Section 5.2 .. (only DNS Providers tracking template state): Record the new template instance for the `"domain"` and `"host"` pair and remove the state of any template instances that were resolved for removal. @@ -1902,7 +1905,7 @@ Consequently, for DNS Providers that maintain applied template state, an existin Conflict detection is performed by the DNS Provider prior to template application. The rules below ensure predictable conflict resolution between DNS Providers. Each rule applies to records on the same host, unless otherwise specified. -* A CNAME record conflicts with any other record on the same host, and any existing records conflict with a CNAME. +* A CNAME record conflicts with any other record on the same host, including another CNAME, 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. * 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. @@ -1911,7 +1914,7 @@ Conflict detection is performed by the DNS Provider prior to template applicatio ** `"All"` — the record conflicts with any other TXT record on the same host. ** `"Prefix"` — the record conflicts with any other TXT record on the same host whose value starts with `"txtConflictMatchingPrefix"`. -Note: DNS Provider MUST also check applicability of all generated records to the target DNS zone in its own system. For example it is very common for DNS provider not to allow CNAME records to be at the zone apex. +Note: A DNS Provider MUST also check the applicability of all generated records to the target DNS zone against constraints imposed by the DNS protocol itself, such as the coexistence rules of <>, as well as any other local capabilities, limits or policies. ==== Conflict Detection Special Handling @@ -2044,7 +2047,7 @@ Each entry in the registry MUST include: ** `"Active"`: the type is currently in use and its definition is normative. ** `"Deprecated"`: the type SHOULD NOT be used in new templates; it MAY appear in existing deployments for backwards compatibility. If the corresponding DNS RR TYPE is marked deprecated or obsolete in the IANA "Resource Record (RR) TYPEs" registry, the entry here SHOULD be set to `"Deprecated"`. ** `"Reserved"`: the type appears in earlier versions of the Domain Connect specification (see <>) and is reserved for back-compatibility. It MUST NOT be redefined in a manner incompatible with <>, and MAY only be defined by a specification that extends this document. See <>. -* *Class*: the handling class of the type. The value MUST be one of `"Fully Specified"` (RDATA broken into dedicated template fields) or `"Computed"` (records derived by a defined computation). A `"Reserved"` entry MAY leave this field unassigned. +* *Handling*: the handling of the type. The value MUST be one of `"Fully Specified"` (RDATA broken into dedicated template fields) or `"Computed"` (records derived by a defined computation). A `"Reserved"` entry MAY leave this field unassigned. * *DNS RR TYPE*: the name of the corresponding entry in the IANA "Resource Record (RR) TYPEs" registry within the "Domain Name System (DNS) Parameters" registry group. A `"Fully Specified"` type SHOULD correspond to a registered DNS RR TYPE of the same name; before registering such a type, the designated experts MUST verify that the named DNS RR TYPE exists in that registry. For a `"Computed"` type, a `"Reserved"` type, or any other type for which no corresponding DNS RR TYPE exists or would be meaningful, the value MUST be `"N/A"`. Where a `"Fully Specified"` type would use a name that is not yet a registered DNS RR TYPE, or where an entry is registered with a `"DNS RR TYPE"` of `"N/A"` (such as a `"Computed"` type), the designated experts SHOULD coordinate with the designated experts of the "Resource Record (RR) TYPEs" registry 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. @@ -2053,7 +2056,7 @@ A registration request MUST provide the following: RR Type:: The record type name (the `"type"` value), conforming to the `dc-type-name` syntax (see <>). Status:: One of `"Active"`, `"Deprecated"`, or `"Reserved"`. -Class:: `"Fully Specified"` or `"Computed"`; omitted for a `"Reserved"` entry. +Handling:: `"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. @@ -2064,7 +2067,7 @@ The following types from this specification constitute the initial contents of t |======================================================================= |*RR Type* |*Status* -|*Class* +|*Handling* |*DNS RR TYPE* |*Kind* |*Reference* @@ -2487,6 +2490,10 @@ The authors wish to thank the following persons for their feedback and suggestio - Added the `"templateSpecVersion"` property to <>. - Added the IANA "Domain Connect Template Properties" registry in <>. - Added `dc-template-property`, `dc-unprefixed-property`, and `dc-vnd-property` to <>. +- Corrected nits from early Dnsdir review. +- Clarified RR placement constraints arising from the DNS protocol. +- Noted RRset TTL consistency requirements in <> and <>. +- Introduced Rendered Record Set terminology in <> to disambiguate from RRset. [toc=exclude,numbered=false] === Change from draft-ietf-dconn-domainconnect-02 to -03 @@ -2530,7 +2537,7 @@ The authors wish to thank the following persons for their feedback and suggestio [toc=exclude,numbered=false] === 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 [RFC8499]. - Removed example provider names from Service Providers and DNS Providers terminology - Added Use Cases - Added Trust Model @@ -2592,11 +2599,11 @@ The authors wish to thank the following persons for their feedback and suggestio * [[[RFC8126,RFC 8126]]] 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, . * [[[RFC9499,RFC 9499]]] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", IETF, DOI 10.17487/RFC9499, RFC 9499, March 2024, . * [[[RFC6838,RFC 6838]]] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", IETF, DOI 10.17487/RFC6838, BCP 13, RFC 6838, January 2013, . -* [[[RFC9110,RFC 9110]]] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", IETF, STD 97, DOI 10.17487/RFC9110, BCP 97, RFC 9110, June 2022, . +* [[[RFC9110,RFC 9110]]] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", IETF, STD 97, DOI 10.17487/RFC9110, BCP 97, RFC 9110, June 2022, . +* [[[RFC2181,RFC 2181]]] Elz, R. and R. Bush, "Clarifications to the DNS Specification", IETF, DOI 10.17487/RFC2181, RFC 2181, July 1997, . [bibliography,normative=false] == Informative References -* [[[RFC8499,RFC 8499]]] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", IETF, DOI 10.17487/RFC8499, RFC 8499, January 2019, . * [[[RFC6839,RFC 6839]]] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", IETF, DOI 10.17487/RFC6839, RFC 6839, January 2013, . // Documentation of asciibib: https://www.relaton.org/asciibib/