diff --git a/docs/draft-ietf-dconn-domainconnect-02.pdf b/docs/draft-ietf-dconn-domainconnect-02.pdf deleted file mode 100644 index 1bc74b7..0000000 Binary files a/docs/draft-ietf-dconn-domainconnect-02.pdf and /dev/null differ diff --git a/docs/draft-ietf-dconn-domainconnect-02.clean.txt b/docs/draft-ietf-dconn-domainconnect-03.clean.txt similarity index 74% rename from docs/draft-ietf-dconn-domainconnect-02.clean.txt rename to docs/draft-ietf-dconn-domainconnect-03.clean.txt index f7ba409..84cd99d 100644 --- a/docs/draft-ietf-dconn-domainconnect-02.clean.txt +++ b/docs/draft-ietf-dconn-domainconnect-03.clean.txt @@ -5,17 +5,17 @@ Network Working Group P. Kowalik Internet-Draft DENIC eG Intended status: Standards Track A. Blinn -Expires: 7 December 2026 +Expires: 4 January 2027 J. Kolker GoDaddy Inc. S. Kerola Cloudflare, Inc. - 5 June 2026 + 3 July 2026 Domain Connect Protocol - DNS provisioning between Services and DNS Providers - draft-ietf-dconn-domainconnect-02 + draft-ietf-dconn-domainconnect-03 Abstract @@ -39,7 +39,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 7 December 2026. + This Internet-Draft will expire on 4 January 2027. Copyright Notice @@ -76,6 +76,9 @@ Table of Contents 6.3.3. Variable Scope Minimisation 6.4. Public Key Publication 7. DNS Provider Discovery + 7.1. "_domainconnect" Resource Record + 7.1.1. Deployment considerations + 7.2. Settings End-Point 8. Applying Domain Connect 8.1. Endpoints 8.2. Query Supported Template @@ -112,9 +115,16 @@ Table of Contents 10.8. Examples 11. Security Considerations 11.1. Template Variable Phishing + 11.2. Untrusted DNS Provider Discovery Records + 11.3. Underscored Host Names 12. IANA Considerations - 12.1. Underscore "_domainconnect" DNS Node Name - 12.2. Domain Connect Settings Properties Registry + 12.1. Registration Procedure for Domain Connect Registries + 12.2. Domain Connect Fully Specified Record Types Registry + 12.3. Domain Connect Settings Properties Registry + 12.4. Guidance to the DNS Resource Record (RR) TYPEs Registry + 12.5. Underscore "_domainconnect" DNS Node Name + 12.6. Media Type Registration for application/ + domainconnect-template+json Implementation Status Acknowledgements Change History @@ -124,7 +134,7 @@ Table of Contents A.1. Example Template A.2. Example Records: Single static host record A.3. Example Records: Single variable host record for A - A.4. Example Records: Unspecified record type CAA + A.4. Example Records: Generic Record Type CAA A.5. Example: Template application to DNS Zone and Conflict Resolution A.6. Example: SPF Record Merging @@ -340,13 +350,26 @@ Table of Contents ; ---- Template record field rules ---- - dc-record-type = ( "A" / "AAAA" / "CNAME" / "MX" / "TXT" - / "SRV" / "SPFM" / "NS" ) - ; named core and pseudo record types - / "TYPE" 1*DIGIT + dc-record-type = dc-type-name / dc-rfc3597-type + ; a registered RR TYPE mnemonic (covering + ; Fully Specified, Computed, and Generic types + ; alike), or the RFC 3597 unknown-type form. + + dc-type-name = "A" + / ( UALPHA *( UALPHA / DIGIT / "-" ) + ( UALPHA / DIGIT ) ) + ; RR TYPE mnemonic per RFC 6895: + ; [A-Z][A-Z0-9-]*[A-Z0-9], i.e. starts with an + ; uppercase letter and ends with a letter or + ; digit; "A" is grandfathered as a single-letter + ; mnemonic. MUST NOT be of the reserved forms + ; "TYPE" or "CLASS" (<>, <>). + + dc-rfc3597-type = "TYPE" 1*DIGIT ; unknown type per RFC 3597 - / 1*(ALPHA / DIGIT / "-") - ; any other IANA-registered RR type name + + UALPHA = %x41-5A + ; A-Z (uppercase letter) dc-essential = "Always" / "OnApply" ; default is "Always" @@ -439,8 +462,27 @@ Table of Contents template is used as a means of communication between Service Provider and DNS Provider. + Fully Specified Record Type: A DNS resource record type for which + this document, or a specification registered in the IANA "Domain + Connect Fully Specified Record Types" registry (see Section 12.2), + defines a breakdown of the record's RDATA into individual, + normatively-typed template fields rather than carrying the RDATA + opaquely. + + Computed Record Type: A template record type that does not + correspond to a single DNS resource record placed verbatim into + the zone. Instead, it instructs the DNS Provider to derive one or + more DNS resource records by a computation defined for that type. + The resulting record types and RDATA need not match the Computed + Record Type's own name. + + Generic Record Type: Any DNS resource record type, identified by its + IANA RR TYPE mnemonic or by the "TYPE" form of [RFC3597], whose + RDATA is carried opaquely in the "data" field in DNS presentation + format. + Certain labels, parameters, endpoints, and registry entries are - present in this specification with _Reserved_ status. These items + present in this specification with "Reserved" status. These items appear in the original Domain Connect community specification [DC-SPEC] and are reserved here to ensure back-compatibility with that specification. Reserved items MUST NOT be redefined in any @@ -706,6 +748,10 @@ Table of Contents the following data. Field values MUST be defined unless otherwise indicated. + The template JSON structure defined in this section is identified by + the media type "application/domainconnect-template+json" (see + Section 12.6). + +=============+========+===================+========================+ |Data Element |Type |Key |Description | +=============+========+===================+========================+ @@ -887,14 +933,24 @@ Table of Contents | | | |and host. | | | | |The default is "false". | +-------------+--------+-------------------+------------------------+ - |*Warn |Boolean |warnPhishing |(OPTIONAL) When "true", | - |Phishing* | | |signals that the | - | | | |template contains | - | | | |variables that cannot be| - | | | |constrained by digital | - | | | |signing and may be | + |*Warn |Boolean |warnPhishing |(DEPRECATED) This flag | + |Phishing* | | |is deprecated and its | + | | | |code point is reserved | + | | | |(see Section 3, | + | | | |Paragraph 13). Phishing| + | | | |warnings are now the | + | | | |default behavior in the | + | | | |absence of other | + | | | |security mechanisms (see| + | | | |Section 11.1). 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.| - | | | |The default is "false". | +-------------+--------+-------------------+------------------------+ |*Host |Boolean |hostRequired |(OPTIONAL) When "true", | |Required* | | |indicates that the | @@ -929,379 +985,288 @@ Table of Contents Each record MUST contain the following elements unless otherwise specified. - +===========+======+=========================+======================+ - |Data |Type |Key |Description | - |Element | | | | - +===========+======+=========================+======================+ - |*Type* |enum |type |(REQUIRED) Describes | - | | | |the type of record in | - | | | |DNS, or the operation | - | | | |impacting DNS. | - | | | |Valid values include: | - | | | |A, AAAA, CNAME, MX, | - | | | |TXT, SRV, or SPFM. | - | | | |The DNS Provider MUST | - | | | |support the core set | - | | | |of records A, AAAA, | - | | | |CNAME, MX, TXT, SRV. | - | | | |The DNS Provider | - | | | |SHOULD support SPFM | - | | | |record for high | - | | | |interoperability with | - | | | |existing templates | - | | | | | - | | | |All other record types| - | | | |MAY be specified by | - | | | |type name as listed in| - | | | |IANA registry for DNS | - | | | |Resource Record (RR) | - | | | |TYPEs. Unknown record| - | | | |types MAY be specified| - | | | |as per [RFC3597] by | - | | | |the word "TYPE" | - | | | |immediately followed | - | | | |by the decimal RR type| - | | | |number, with no | - | | | |intervening | - | | | |whitespace. Support | - | | | |for other record types| - | | | |is OPTIONAL. | - | | | |The value MUST conform| - | | | |to the dc-record-type | - | | | |syntax (see | - | | | |Section 3). | - +-----------+------+-------------------------+----------------------+ - |*Group ID* |String|groupId |(OPTIONAL) This | - | | | |parameter identifies | - | | | |the group the record | - | | | |belongs to when | - | | | |applying changes. The| - | | | |value MUST conform to | - | | | |the dc-id syntax (see | - | | | |Section 3) and MUST | - | | | |NOT contain variable | - | | | |expressions. | - +-----------+------+-------------------------+----------------------+ - |*Essential*|enum |essential |(OPTIONAL) This | - | | | |parameter indicates | - | | | |how the record is | - | | | |treated during | - | | | |conflict detection | - | | | |with existing | - | | | |templates. | - | | | |If the DNS Provider is| - | | | |not implementing | - | | | |applied template state| - | | | |in DNS this is | - | | | |ignored. | - | | | |Always (default) - | - | | | |record MUST be applied| - | | | |and kept with the | - | | | |template | - | | | |OnApply - record MUST | - | | | |be applied but can be | - | | | |later removed without | - | | | |dropping the whole | - | | | |template | - | | | |The value MUST conform| - | | | |to the dc-essential | - | | | |syntax (see | - | | | |Section 3). | - | | | |If omitted, the value | - | | | |MUST be assumed to be | - | | | |"Always". | - +-----------+------+-------------------------+----------------------+ - |*Host* |String|host |(REQUIRED) The host | - | | | |for A, AAAA, CNAME, | - | | | |NS, TXT, MX and other | - | | | |unspecified record | - | | | |type values. | - | | | |This value is relative| - | | | |to the applied host | - | | | |and domain, unless | - | | | |trailed by a ".". | - | | | |A value of empty or | - | | | |"@" indicates the root| - | | | |of the applied host | - | | | |and domain. In other | - | | | |words | - | | | |"[host.]example.com.".| - | | | |When used in a | - | | | |template definition, | - | | | |the value MUST conform| - | | | |to the dc-host-tmpl | - | | | |syntax (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the domain-| - | | | |name syntax (see | - | | | |Section 3). | - +-----------+------+-------------------------+----------------------+ - |*Name* |String|name |The name for the SRV | - | | | |record. | - | | | |This value is relative| - | | | |to the applied host | - | | | |and domain. A value | - | | | |of empty or "@" | - | | | |indicates the root of | - | | | |the applied host and | - | | | |domain. | - | | | |When used in a | - | | | |template definition, | - | | | |the value MUST conform| - | | | |to the dc-host-tmpl | - | | | |syntax (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the domain-| - | | | |name syntax (see | - | | | |Section 3). | - +-----------+------+-------------------------+----------------------+ - |*Points To*|String|pointsTo |The pointsTo location | - | | | |for A, AAAA, CNAME, NS| - | | | |and MX records. | - | | | |When used in a | - | | | |template definition, | - | | | |the value MUST conform| - | | | |to the "dc-pointsto- | - | | | |tmpl" syntax for | - | | | |"CNAME"/"MX" and to | - | | | |the "dc-pointsto-nat- | - | | | |tmpl" syntax for | - | | | |A/AAAA/NS (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the | - | | | |presentation format of| - | | | |the corresponding | - | | | |resource record type. | - +-----------+------+-------------------------+----------------------+ - |*TTL* |Int or|ttl |The time-to-live for | - | |string| |the record in DNS. | - | |repr. | |Valid for A, AAAA, | - | |of Int| |CNAME, NS, TXT, MX, | - | | | |and SRV records. This| - | | | |SHOULD NOT contain | - | | | |variables unless | - | | | |absolutely necessary. | - | | | |When used in a | - | | | |template definition, | - | | | |the value MUST conform| - | | | |to the dc-ttl-tmpl | - | | | |syntax (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the dc-ttl-| - | | | |value syntax. 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. | - +-----------+------+-------------------------+----------------------+ - |*Data* |String|data |For TXT record "data" | - | | | |contains TXT-DATA | - | | | |[RFC1035] in | - | | | |presentation format. | - | | | |For a single | - | | | |"" | - | | | |the heading and | - | | | |trailing " character | - | | | |MAY be omitted even if| - | | | |space character is | - | | | |present in the value. | - | | | |"data" MUST NOT be | - | | | |present in a template | - | | | |record for any other | - | | | |record type that has | - | | | |type-specific data | - | | | |fields defined in this| - | | | |specification. For | - | | | |any unspecified record| - | | | |type, this field | - | | | |contains the canonical| - | | | |presentation format of| - | | | |the record, following | - | | | |[RFC3597] generic or | - | | | |type-specific | - | | | |encoding. | - +-----------+------+-------------------------+----------------------+ - |*TXT |String|txtConflictMatchingMode |Describes how | - |Conflict | | |conflicts on the TXT | - |Matching | | |record are detected. | - |Mode* | | |Possible values are | - | | | |None, All, or Prefix. | - | | | |See below | - | | | |(Section 10.4). | - | | | |The value MUST conform| - | | | |to the dc-txt- | - | | | |conflict-mode syntax | - | | | |(see Section 3). | - | | | |If omitted, the value | - | | | |MUST be assumed to be | - | | | |"None". | - +-----------+------+-------------------------+----------------------+ - |*TXT |String|txtConflictMatchingPrefix|The prefix to detect | - |Conflict | | |conflicts when | - |Matching | | |txtConflict- | - |Prefix* | | |MatchingMode is | - | | | |"Prefix". See below | - | | | |(Section 10.4). | - | | | |The value MUST conform| - | | | |to the dc-conflict- | - | | | |prefix syntax (see | - | | | |Section 3). | - +-----------+------+-------------------------+----------------------+ - |*Priority* |Int or|priority |The priority for an MX| - | |string| |or SRV record. | - | |repr. | |When used in a | - | |of Int| |template definition, | - | | | |the value MUST conform| - | | | |to the dc-uint16-tmpl | - | | | |syntax (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the dc- | - | | | |uint16-value syntax. | - | | | |Support of variables | - | | | |in this field is | - | | | |OPTIONAL for DNS | - | | | |Provider. | - +-----------+------+-------------------------+----------------------+ - |*Weight* |Int or|weight |The weight for the SRV| - | |string| |record. | - | |repr. | |When used in a | - | |of Int| |template definition, | - | | | |the value MUST conform| - | | | |to the dc-uint16-tmpl | - | | | |syntax (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the dc- | - | | | |uint16-value syntax. | - | | | |Support of variables | - | | | |in this field is | - | | | |OPTIONAL for DNS | - | | | |Provider. | - +-----------+------+-------------------------+----------------------+ - |*Port* |Int or|port |The port for the SRV | - | |string| |record. | - | |repr. | |When used in a | - | |of Int| |template definition, | - | | | |the value MUST conform| - | | | |to the dc-uint16-tmpl | - | | | |syntax (see | - | | | |Section 3). | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the dc- | - | | | |uint16-value syntax. | - | | | |The resolved value is | - | | | |further constrained to| - | | | |the range 0-65535 as | - | | | |defined by [RFC6335]. | - | | | |Support of variables | - | | | |in this field is | - | | | |OPTIONAL for DNS | - | | | |Provider. | - +-----------+------+-------------------------+----------------------+ - |*Protocol* |String|protocol |The protocol for the | - | | | |SRV record. | - | | | |The value MUST conform| - | | | |to the dc-srv-protocol| - | | | |syntax (see | - | | | |Section 3). | - +-----------+------+-------------------------+----------------------+ - |*Service* |String|service |The symbolic service | - | | | |name for the SRV | - | | | |record. | - | | | |The value MUST conform| - | | | |to the dc-srv-service | - | | | |syntax (see | - | | | |Section 3). | - +-----------+------+-------------------------+----------------------+ - |*Target* |String|target |The target hostname | - | | | |for the SRV record as | - | | | |defined in Section 3.1| - | | | |of [RFC2782]. | - | | | |When used in a | - | | | |template definition, | - | | | |the value MUST conform| - | | | |to the dc-pointsto- | - | | | |tmpl syntax (see | - | | | |Section 3), or be the | - | | | |single label "." to | - | | | |indicate that the | - | | | |service is not | - | | | |available. | - | | | |After variable | - | | | |substitution, the | - | | | |resolved value MUST | - | | | |conform to the domain-| - | | | |name syntax (see | - | | | |Section 3), or be ".".| - +-----------+------+-------------------------+----------------------+ - |*SPF Rules*|String|spfRules |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. | - +-----------+------+-------------------------+----------------------+ - - Table 2: properties of the template record definition + Properties of the template record definition: + + "Type": + JSON key: "type" + + Type: "enum" + + (REQUIRED) Describes the type of record in DNS, or the operation + impacting DNS. + + Record types fall into three classes (see Section 3): + + Fully Specified Record Types - A, AAAA, CNAME, MX, TXT, SRV, NS - + whose RDATA is broken into dedicated template fields. The + complete set is managed by the IANA "Domain Connect Fully + Specified Record Types" registry (see Section 12.2). + + Computed Record Types - which instruct the DNS Provider to derive + DNS records by a defined computation rather than write a verbatim + record. "SPFM" is the Computed Record Type defined in this + document. + + Generic Record Types - any other IANA-registered RR TYPE mnemonic, + or the "TYPE" form of [RFC3597], whose RDATA is carried opaquely + in the "data" field. + + The DNS Provider MUST support the core Fully Specified Record + Types A, AAAA, CNAME, MX, TXT, SRV. + The DNS Provider SHOULD support the "SPFM" Computed Record Type + for high interoperability with existing templates. + Support for NS, for Generic Record Types, and for any Fully + Specified Record Type registered by another specification is + OPTIONAL. + + The value MUST conform to the dc-record-type syntax (see + Section 3). + + "Group ID": + JSON key: "groupId" + + Type: "String" + + (OPTIONAL) This parameter identifies the group the record belongs + to when applying changes. + + The value MUST conform to the dc-id syntax (see Section 3) and + MUST NOT contain variable expressions. + + "Essential": + JSON key: "essential" + + Type: "enum" + + (OPTIONAL) This parameter indicates how the record is treated + during conflict detection with existing templates. + + If the DNS Provider is not implementing applied template state in + DNS this is ignored. + + Always (default) - record MUST be applied and kept with the + template + + OnApply - record MUST be applied but can be later removed without + dropping the whole template + + The value MUST conform to the dc-essential syntax (see Section 3). + + If omitted, the value MUST be assumed to be "Always". + + "Host": + JSON key: "host" + + Type: "String" + + (REQUIRED) The host for A, AAAA, CNAME, NS, TXT, MX and Generic + Record Type values. + + This value is relative to the applied host and domain, unless + trailed by a ".". + + A value of empty or "@" indicates the root of the applied host and + domain. In other words "[host.]example.com.". + + When used in a template definition, the value MUST conform to the + dc-host-tmpl syntax (see Section 3). + + After variable substitution, the resolved value MUST conform to + the domain-name syntax (see Section 3). + + "Name": + JSON key: "name" + + Type: "String" + + The name for the SRV record. + + This value is relative to the applied host and domain. A value of + empty or "@" indicates the root of the applied host and domain. + + When used in a template definition, the value MUST conform to the + dc-host-tmpl syntax (see Section 3). + + After variable substitution, the resolved value MUST conform to + the domain-name syntax (see Section 3). + + "Points To": + JSON key: "pointsTo" + + Type: "String" + + The pointsTo location for A, AAAA, CNAME, NS and MX records. + + When used in a template definition, the value MUST conform to the + "dc-pointsto-tmpl" syntax for "CNAME"/"MX" and to the "dc- + pointsto-nat-tmpl" syntax for A/AAAA/NS (see Section 3). + + After variable substitution, the resolved value MUST conform to + the presentation format of the corresponding resource record type. + + "TTL": + JSON key: "ttl" + + Type: "Int" or string representation of "Int" + + The time-to-live for the record in DNS. Valid for A, AAAA, CNAME, + NS, TXT, MX, and SRV records. This SHOULD NOT contain variables + unless absolutely necessary. + + When used in a template definition, the value MUST conform to the + dc-ttl-tmpl syntax (see Section 3). + + After variable substitution, the resolved value MUST conform to + the dc-ttl-value syntax. + + 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. + + "Data": + JSON key: "data" + + Type: "String" + + For TXT record "data" contains TXT-DATA [RFC1035] in presentation + format. For a single "" the heading and + trailing " character MAY be omitted even if space character is + present in the value. + + "data" MUST NOT be present in a template record for any Fully + Specified or Computed Record Type, which use type-specific data + fields defined in this specification. + + For a Generic Record Type, this field contains the canonical + presentation format of the record, following [RFC3597] generic or + type-specific encoding. + + "TXT Conflict Matching Mode": + JSON key: "txtConflictMatchingMode" + + Type: "String" + + Describes how conflicts on the TXT record are detected. Possible + values are None, All, or Prefix. See below (Section 10.4). + + The value MUST conform to the dc-txt-conflict-mode syntax (see + Section 3). + + If omitted, the value MUST be assumed to be "None". + + "TXT Conflict Matching Prefix": + JSON key: "txtConflictMatchingPrefix" + + Type: "String" + + The prefix to detect conflicts when txtConflict-MatchingMode is + "Prefix". See below (Section 10.4). + + The value MUST conform to the dc-conflict-prefix syntax (see + Section 3). + + "Priority": + JSON key: "priority" + + Type: "Int" or string representation of "Int" + + The priority for an MX or SRV record. + + When used in a template definition, the value MUST conform to the + dc-uint16-tmpl syntax (see Section 3). + + After variable substitution, the resolved value MUST conform to + the dc-uint16-value syntax. + + Support of variables in this field is OPTIONAL for DNS Provider. + + "Weight": + JSON key: "weight" + + Type: "Int" or string representation of "Int" + + The weight for the SRV record. + + When used in a template definition, the value MUST conform to the + dc-uint16-tmpl syntax (see Section 3). + + After variable substitution, the resolved value MUST conform to + the dc-uint16-value syntax. + + Support of variables in this field is OPTIONAL for DNS Provider. + + "Port": + JSON key: "port" + + Type: "Int" or string representation of "Int" + + The port for the SRV record. + + When used in a template definition, the value MUST conform to the + dc-uint16-tmpl syntax (see Section 3). + + After variable substitution, the resolved value MUST conform to + the dc-uint16-value syntax. + + The resolved value is further constrained to the range 0-65535 as + defined by [RFC6335]. + + Support of variables in this field is OPTIONAL for DNS Provider. + + "Protocol": + JSON key: "protocol" + + Type: "String" + + The protocol for the SRV record. + + The value MUST conform to the dc-srv-protocol syntax (see + Section 3). + + "Service": + JSON key: "service" + + Type: "String" + + The symbolic service name for the SRV record. + + The value MUST conform to the dc-srv-service syntax (see + Section 3). + + "Target": + JSON key: "target" + + Type: "String" + + The target hostname for the SRV record as defined in Section 3.1 + of [RFC2782]. + + When used in a template definition, the value MUST conform to the + dc-pointsto-tmpl syntax (see Section 3), or be the single label + "." to indicate that the service is not available. + + After variable substitution, the resolved value MUST conform to + the domain-name syntax (see Section 3), or be ".". + + "SPF Rules": + JSON key: "spfRules" + + Type: "String" + + 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. @@ -1328,11 +1293,11 @@ Table of Contents +---------+--------------------------------------------------------+ | "SPFM" | "host", "spfRules" | +---------+--------------------------------------------------------+ - | other | "host", "data", "ttl" | + | Generic | "host", "data", "ttl" | | types | | +---------+--------------------------------------------------------+ - Table 3: Fields per record type + Table 2: Fields per record type 6.3. Template Considerations @@ -1447,19 +1412,21 @@ Table of Contents | | | If omitted, MUST be assumed to be "x509". | +------------+-----+------------------------------------------------+ - Table 4: Properties of the public key TXT record + Table 3: Properties of the public key TXT record - To allow for key rotation or use of multiple keys, the Service - Provider MAY publish key records at multiple hosts within + A Service Provider MUST publish exactly one public key on any given + host name. To use multiple keys, e.g. for key rotation, the Service + Provider MUST publish each key on a different host name within "syncPubKeyDomain". The "key" apply parameter identifies which host to query for each request and MUST be included in the signed apply request. To account for DNS record size limits, a public key MAY be split across multiple TXT records at the same host. All fragments MUST be - reassembled in ascending numeric order of "p" before use. The values - "a" and '"d"' MUST be equal for all such TXT records on the same - host. + reassembled in ascending numeric order of "p" before use. All such + TXT records at the same host therefore belong to the same key: the + values "a" and "t" MUST be equal across them, and their "d" fragments + MUST have distinct "p" indices. Given the public key (line breaks for brevity): @@ -1487,6 +1454,8 @@ Table of Contents 7. DNS Provider Discovery +7.1. "_domainconnect" Resource Record + To facilitate discovery of the DNS Provider from a domain name DNS is utilized. This is done by returning a TXT record for "_domainconnect" in the zone. @@ -1498,12 +1467,27 @@ Table of Contents domainconnect.virtucondomains.example + EXAMPLE 2: An example of the contents of this record including a path + segment: + + domainconnect.virtucondomains.example/dc + "_domainconnect" TXT record content, when prepended with https:// schema and appended with /v2 path segment, MUST form a valid URL [RFC3986]. "_domainconnect" TXT record MUST contain the authority part of the URL and MAY contain a path part. "_domainconnect" MUST not contain schema, query or fragment part of an URL. + The DNS query for the "_domainconnect" TXT record MAY return more + than one TXT record. The Service Provider MUST reject any returned + record whose content does not satisfy the validity rules above. If, + after this filtering, at least one valid record remains, the Service + Provider MUST process at least one of them. The Service Provider MAY + iterate over the remaining valid records, attempting discovery with + each in turn, until a valid Settings End-Point response is obtained. + +7.1.1. Deployment considerations + As a practical matter of implementation, the DNS Provider may or may not contain a copy of this data in each and every zone. Instead, the DNS Provider MUST simply respond to the DNS query for the @@ -1517,10 +1501,12 @@ Table of Contents may simply respond with the appropriate records at the DNS layer without having the data in each zone. - The URL prefix returned MUST be subsequently used by the Service - Provider to determine the additional settings for using Domain - Connect on this domain at the DNS Provider. This is done by calling - a REST API. +7.2. Settings End-Point + + The URL prefix returned in "_domainconnect" Resource Record MUST be + subsequently used by the Service Provider to determine the additional + settings for using Domain Connect on this domain at the DNS Provider. + This is done by calling a REST API. Normative URI template of the Settings End-Point per [RFC6570]: @@ -1536,167 +1522,120 @@ Table of Contents Provider. This JSON structure MUST contain the following fields unless otherwise specified. - +==============+=====================+========+=====================+ - | *Field* | *Key* | *Type* | *Description* | - +==============+=====================+========+=====================+ - | *Provider | providerId | String | (REQUIRED) Unique | - | Id* | | | identifier for the | - | | | | DNS Provider. | - | | | | The value MUST | - | | | | conform to the dc- | - | | | | id syntax (see | - | | | | Section 3). | - | | | | To allow for non- | - | | | | coordinated | - | | | | uniqueness, this | - | | | | SHOULD be the | - | | | | domain name of the | - | | | | DNS Provider (e.g. | - | | | | virtucom.example). | - +--------------+---------------------+--------+---------------------+ - | *Provider | providerName | String | (REQUIRED) The | - | Name* | | | name of the DNS | - | | | | Provider. | - | | | | The value MUST | - | | | | conform to the dc- | - | | | | display-name | - | | | | syntax (see | - | | | | Section 3). | - +--------------+---------------------+--------+---------------------+ - | *Provider | providerDisplayName | String | (OPTIONAL) The | - | Display | | | name of the DNS | - | Name* | | | Provider that | - | | | | SHOULD be | - | | | | displayed by the | - | | | | Service Provider. | - | | | | This MAY change | - | | | | per domain for | - | | | | some DNS Providers | - | | | | that power | - | | | | multiple brands. | - | | | | When present, the | - | | | | value MUST conform | - | | | | to the dc-display- | - | | | | name syntax (see | - | | | | Section 3). | - +--------------+---------------------+--------+---------------------+ - | *UX URL | urlSyncUX | String | (OPTIONAL) The URL | - | Prefix for | | | Prefix for linking | - | Synchronous | | | to the UX of | - | Flows* | | | Domain Connect for | - | | | | the synchronous | - | | | | flow at the DNS | - | | | | Provider. If not | - | | | | returned, the DNS | - | | | | Provider is not | - | | | | supporting the | - | | | | synchronous flow | - | | | | on this domain. | - | | | | This MUST be a | - | | | | valid URI | - | | | | [RFC3986] with | - | | | | scheme "https", | - | | | | MUST include an | - | | | | authority | - | | | | component, and | - | | | | MUST NOT contain a | - | | | | query component or | - | | | | fragment | - | | | | component. | - | | | | The URI MAY | - | | | | include a path | - | | | | component. | - +--------------+---------------------+--------+---------------------+ - | *UX URL | urlAsyncUX | String | (Reserved. See | - | Prefix for | | | Section 3, | - | Asynchronous | | | Paragraph 13.) | - | Flows* | | | | - +--------------+---------------------+--------+---------------------+ - | *API URL | urlAPI | String | (REQUIRED) The URL | - | Prefix* | | | Prefix for the | - | | | | REST API. | - | | | | This MUST be a | - | | | | valid URI | - | | | | [RFC3986] with | - | | | | scheme "https", | - | | | | MUST include an | - | | | | authority | - | | | | component, and | - | | | | MUST NOT contain a | - | | | | query component or | - | | | | fragment | - | | | | component. | - | | | | The URI MAY | - | | | | include a path | - | | | | component. | - +--------------+---------------------+--------+---------------------+ - | *Width of | width | Number | (OPTIONAL) The | - | Window* | | | desired width in | - | | | | pixels of the pop- | - | | | | up window used for | - | | | | granting consent. | - | | | | If not present, | - | | | | the default MUST | - | | | | be assumed to be | - | | | | 750. | - +--------------+---------------------+--------+---------------------+ - | *Height of | height | Number | (OPTIONAL) The | - | Window* | | | desired height in | - | | | | pixels of the pop- | - | | | | up window used for | - | | | | granting consent. | - | | | | If not present, | - | | | | the default MUST | - | | | | be assumed to be | - | | | | 750. | - +--------------+---------------------+--------+---------------------+ - | *UX URL | urlControlPanel | String | (OPTIONAL) A URL | - | Control | | | to the DNS | - | Panel* | | | Provider's control | - | | | | panel for manual | - | | | | DNS editing. This | - | | | | field allows a | - | | | | Service Provider | - | | | | whose template is | - | | | | not supported at | - | | | | the DNS Provider | - | | | | to provide a | - | | | | direct link to | - | | | | perform manual | - | | | | edits. | - | | | | The value MAY | - | | | | contain the | - | | | | literal token | - | | | | "%domain%" as a | - | | | | placeholder for | - | | | | the domain name, | - | | | | to allow deep- | - | | | | linking to a | - | | | | specific domain. | - | | | | The value, after | - | | | | any substitution | - | | | | of the "%domain%" | - | | | | token, MUST be a | - | | | | valid URI per | - | | | | [RFC3986] with | - | | | | scheme "https". | - +--------------+---------------------+--------+---------------------+ - | *Name | nameServers | List | (OPTIONAL) The | - | Servers* | | of | list of nameserver | - | | | String | hostnames for the | - | | | | zone held by this | - | | | | DNS Provider | - | | | | (typically derived | - | | | | from the zone's NS | - | | | | records). | - | | | | Each entry MUST | - | | | | conform to the | - | | | | "domain-name" | - | | | | syntax (see | - | | | | Section 3). | - +--------------+---------------------+--------+---------------------+ - - Table 5: properties of the settings data structure + +=============+=====================+========+======================+ + | *Field* | *Key* | *Type* | *Description* | + +=============+=====================+========+======================+ + | *Provider | providerId | String | (REQUIRED) Unique | + | Id* | | | identifier for the | + | | | | DNS Provider. | + | | | | The value MUST | + | | | | conform to the dc- | + | | | | id syntax (see | + | | | | Section 3). | + | | | | To allow for non- | + | | | | coordinated | + | | | | uniqueness, this | + | | | | SHOULD be the | + | | | | domain name of the | + | | | | DNS Provider (e.g. | + | | | | virtucom.example). | + +-------------+---------------------+--------+----------------------+ + | *Provider | providerName | String | (REQUIRED) The name | + | Name* | | | of the DNS | + | | | | Provider. | + | | | | The value MUST | + | | | | conform to the dc- | + | | | | display-name syntax | + | | | | (see Section 3). | + +-------------+---------------------+--------+----------------------+ + | *Provider | providerDisplayName | String | (OPTIONAL) The name | + | Display | | | of the DNS Provider | + | Name* | | | that SHOULD be | + | | | | displayed by the | + | | | | Service Provider. | + | | | | This MAY change per | + | | | | domain for some DNS | + | | | | Providers that | + | | | | power multiple | + | | | | brands. | + | | | | When present, the | + | | | | value MUST conform | + | | | | to the dc-display- | + | | | | name syntax (see | + | | | | Section 3). | + +-------------+---------------------+--------+----------------------+ + | *UX URL | urlSyncUX | String | (OPTIONAL) The URL | + | Prefix for | | | Prefix for linking | + | Synchronous | | | to the UX of Domain | + | Flows* | | | Connect for the | + | | | | synchronous flow at | + | | | | the DNS Provider. | + | | | | If not returned, | + | | | | the DNS Provider is | + | | | | not supporting the | + | | | | synchronous flow on | + | | | | this domain. | + | | | | This MUST be a | + | | | | valid URI [RFC3986] | + | | | | with scheme | + | | | | "https", MUST | + | | | | include an | + | | | | authority | + | | | | component, and MUST | + | | | | NOT contain a query | + | | | | component or | + | | | | fragment component. | + | | | | The URI MAY include | + | | | | a path component. | + +-------------+---------------------+--------+----------------------+ + | *API URL | urlAPI | String | (REQUIRED) The URL | + | Prefix* | | | Prefix for the REST | + | | | | API. | + | | | | This MUST be a | + | | | | valid URI [RFC3986] | + | | | | with scheme | + | | | | "https", MUST | + | | | | include an | + | | | | authority | + | | | | component, and MUST | + | | | | NOT contain a query | + | | | | component or | + | | | | fragment component. | + | | | | The URI MAY include | + | | | | a path component. | + +-------------+---------------------+--------+----------------------+ + | *Name | nameServers | List | (OPTIONAL) The list | + | Servers* | | of | of nameserver | + | | | String | hostnames for the | + | | | | zone held by this | + | | | | DNS Provider | + | | | | (typically derived | + | | | | from the zone's NS | + | | | | records). | + | | | | Each entry MUST | + | | | | conform to the | + | | | | "domain-name" | + | | | | syntax (see | + | | | | Section 3). | + +-------------+---------------------+--------+----------------------+ + | *Reserved* | urlAsyncUX | | (Reserved. See | + | | | | Section 3, | + | | | | Paragraph 13.) | + +-------------+---------------------+--------+----------------------+ + | *Reserved* | width | | (Reserved. See | + | | | | Section 3, | + | | | | Paragraph 13.) | + +-------------+---------------------+--------+----------------------+ + | *Reserved* | height | | (Reserved. See | + | | | | Section 3, | + | | | | Paragraph 13.) | + +-------------+---------------------+--------+----------------------+ + | *Reserved* | urlControlPanel | | (Reserved. See | + | | | | Section 3, | + | | | | Paragraph 13.) | + +-------------+---------------------+--------+----------------------+ + + Table 4: properties of the settings data structure Clients MUST ignore any JSON properties in the settings response that are not defined in this specification or not recognized from an @@ -1704,19 +1643,16 @@ Table of Contents properties in the settings response beyond those defined in this specification, however it is RECOMMENDED that those properties are registered in the "Domain Connect Settings Properties" registry - defined in Section 12.2 in order to avoid name conflicts. + defined in Section 12.3 in order to avoid name conflicts. - EXAMPLE 2: Example Settings End-Point response + EXAMPLE: Example Settings End-Point response { "providerId": "virtucondomains.example", "providerName": "Virtucon Domains", "providerDisplayName": "Virtucon Domains", - "urlSyncUX": "https://domainconnect.virtucondomains.example", - "urlAsyncUX": "https://domainconnect.virtucondomains.example", + "urlSyncUX": "https://domainconnect.virtucondomains.example/sync", "urlAPI": "https://api.domainconnect.virtucondomains.example", - "width": 750, - "height": 750, "urlControlPanel": "https://domaincontrolpanel.virtucondomains.ex ample/?domain=%domain%", "nameServers": ["ns01.virtucondomainsdns.example", "ns02.virtucon @@ -1759,7 +1695,7 @@ Table of Contents | Found* | | DNS Provider does not have the zone. | +-----------+----------+-------------------------------------------+ - Table 6: HTTP status codes for the settings end-point + Table 5: HTTP status codes for the settings end-point 8. Applying Domain Connect @@ -1822,7 +1758,7 @@ Table of Contents | | | id syntax (see Section 3). | +----------+------------+------------------------------------+ - Table 7: URI template parameters for the query supported + Table 6: URI template parameters for the query supported template end-point Returning a status of 200 without a body indicates the template is @@ -1830,6 +1766,15 @@ Table of Contents in a JSON object with field "version" (see: version field (Section 6.1) or the full JSON object of deployed template. + The Service Provider MAY use HTTP content negotiation (see [RFC9110]) + to request the full template object, for example by sending an + "Accept" request header of "application/domainconnect-template+json". + When the DNS Provider returns the full template object in the + response body, it MUST set the "Content-Type" response header to + "application/domainconnect-template+json" (see Section 12.6). A DNS + Provider that does not return the full template object responds as + described above. + Returning a status of 404 indicates the template is not supported. +===========+==========+======================================+ @@ -1844,7 +1789,7 @@ Table of Contents | Found* | | the template is not supported | +-----------+----------+--------------------------------------+ - Table 8: https status codes for the Query Supported + Table 7: https status codes for the Query Supported Template end-point 8.3. Synchronous Flow @@ -1988,7 +1933,7 @@ Table of Contents | | | See the Section 8.3.2.1 below. | +-------------+--------------+-----------------------------------+ - Table 9: URI template parameters of the apply call in the sync + Table 8: URI template parameters of the apply call in the sync flow An example query string: @@ -2402,8 +2347,8 @@ Table of Contents The implementation would be left to the DNS Provider, but to facilitate this SPF records SHOULD NOT be included in templates. - Instead, a new pseudo-record type is introduced in the template - called "SPFM". This has the following attribute: + Instead, a Computed Record Type (see Section 3) is introduced in the + template called "SPFM". This has the following attribute: "spfRules": Determines the desired rules, basically everything but leading "v=spf1" and trailing "all" rule - see: SPF Rules @@ -2659,6 +2604,23 @@ Table of Contents user or through the application of another template - without triggering conflict or removal of the owning template. +10.4.1.3. Identical Records + + A resolved template record that is byte-identical to a resource + record already present in the target zone - same owner name, type, + class and RDATA - MUST NOT be treated as a conflict, regardless of + the conflict-detection rules above. Instead of removing the existing + record or the whole template, the DNS Provider applies the new + template on top of it, so that the record is now shared between the + existing configuration and the newly applied template. + + Whether a second, byte-identical copy of the record is stored in DNS + Provider's system, or the duplicate is skipped so that a single + record remains, is left to the DNS Provider and the capabilities of + its underlying DNS software. Both behaviours are conformant - the + observable DNS response MUST be equivalent in either case and contain + only single resource record. + 10.5. Calculating Conflict Resolution A DNS Provider not maintaining applied template state, applying a @@ -2672,7 +2634,11 @@ Table of Contents 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. + 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. 10.6. User Authorization of Changes @@ -2703,10 +2669,13 @@ Table of Contents the displayed name. It is RECOMMENDED however to also display the original "providerName" and "serviceName" defined in the template. - When the template's "warnPhishing" field is "true", the DNS Provider - SHOULD display additional warnings prompting the user to verify the - source of the request before proceeding, and SHOULD provide a more - verbose description of the changes about to be applied. + Unless the apply request is digitally signed (see Section 8.3.2.1), + the DNS Provider MUST treat the template as susceptible to phishing: + it SHOULD display additional warnings prompting the user to verify + the source of the request before proceeding, and SHOULD provide a + more verbose description of the changes about to be applied. Failure + to do so may expose the end user to the risk of malicious changes + being applied to the DNS zone. 10.7. Template Application @@ -2741,37 +2710,240 @@ Table of Contents being pointed at infrastructure under the attacker's control. Not all templates are susceptible; the risk is proportional to how - much of a record's content is controlled by variables. Three + much of a record's content is controlled by variables. Two mitigations are available to template authors and Service Providers: digitally signing apply requests (see the - Section <
>), using an alternative flow - not prone to this risk and disabling the synchronous flow via - "syncBlock", and setting the "warnPhishing" flag to prompt the DNS - Provider to display additional warnings to the user. + Section <
>), and using an alternative + flow not prone to this risk by disabling the synchronous flow via + "syncBlock". In the absence of such a mitigation a template is + treated as susceptible to phishing by default, and DNS Providers + display the additional warnings described in Section 10.6. + +11.2. Untrusted DNS Provider Discovery Records + + DNS Provider Discovery (see Section 7) requires the Service Provider + to read the "_domainconnect" TXT record from the target zone and to + fetch the Settings End-Point at the URL derived from it. The content + of this record is controlled by whoever controls the zone, which is + not necessarily a party the Service Provider trusts. + + A malicious or compromised zone can therefore direct the Service + Provider's HTTP client at an arbitrary endpoint. Two classes of + attack arise: + + * 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 + Service Provider's connections, memory, or processing capacity. + + * Server-Side Request Forgery (SSRF) - The derived authority may + resolve to an address inside the Service Provider's own + infrastructure (for example a loopback, link-local, or private-use + address, or an internal-only hostname), causing the Service + Provider to issue requests against internal services on the + attacker's behalf. + + Service Providers MUST treat the "_domainconnect" TXT record content, + and the Settings End-Point response derived from it, as untrusted + input. In particular, Service Providers: + + * SHOULD reject derived authorities that resolve to loopback, link- + local, private-use, or otherwise internal addresses, unless the + Service Provider has a specific reason to permit them + + * MUST bound the discovery request, including connection and total- + request timeouts, a maximum response size, and a limit on the + number of redirects followed + +11.3. Underscored Host Names + + The "host" apply parameter is supplied by the requesting party and + prepended to the template record owner names during Host Name + Rendering. When its value is an underscore-prefixed label per + [RFC8552], the applied records land under a name with special + protocol meaning - for example "_acme-challenge", "_domainkey", or + "_dmarc". A template that places a "CNAME" on the apex ("@") host + could then be applied with such a "host" value to redirect one of + 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 + publication, or DMARC policy. + + Legitimate uses of an underscored "host" value exist but are rare. + DNS Providers SHOULD therefore apply additional measures when the + "host" apply parameter contains an underscore-prefixed label, such as + presenting the affected owner names to the user in a more explicit + and verbose manner during User Authorization of Changes so that the + special-meaning target is not obscured. 12. IANA Considerations -12.1. Underscore "_domainconnect" DNS Node Name +12.1. Registration Procedure for Domain Connect Registries + + IANA is requested to create a new registry group named "Domain + Connect Protocol". The registration procedure described in this + section applies to all registries established by this document under + that registry group. + + Values are registered after a three-week review period on the + mailing list or its successor, on the advice + of one or more designated experts. To allow for the allocation of + values prior to publication, the designated experts MAY approve + registration once they are satisfied that the corresponding + specification will be published. + + Registration requests sent to the review mailing list SHOULD use an + appropriate subject line (e.g., "Request to register Domain Connect + record type: example"). Registration requests that remain + undetermined for a period longer than 21 days MAY be brought to + IANA's attention (using the mailing list) for + resolution. + + The designated experts SHOULD determine whether a registration + request contains enough information for the registry to be populated + and whether the proposed new functionality already exists. In the + case of an incomplete registration, or an attempt to register already + existing functionality, the designated experts SHOULD ask for + corrections or reject the registration. + + IANA is requested to appoint one or more designated experts for the + registries in the "Domain Connect Protocol" registry group. It is + RECOMMENDED that multiple designated experts be appointed who are + able to represent the perspectives of different Service Providers and + DNS Providers, in order to enable broadly informed review of + registration decisions. In cases where a registration decision could + be perceived as creating a conflict of interest for a particular + expert, that expert SHOULD defer to the judgment of the other + experts. + +12.2. Domain Connect Fully Specified Record Types Registry - Per [RFC8552], please add the following entry to the "Underscored and - Globally Scoped DNS Node Names" registry: + IANA is requested to create a new registry named "Domain Connect + Fully Specified Record Types" under the "Domain Connect Protocol" + registry group. - +=========+================+================+ - | RR Type | _NODE NAME | Reference | - +=========+================+================+ - | TXT | _domainconnect | This document. | - +---------+----------------+----------------+ + Registration policy: Specification Required (see [RFC8126]), + following the procedure in Section 12.1. - Table 10: IANA Registration for - _domainconnect + Each entry in the registry MUST include: -12.2. Domain Connect Settings Properties Registry + * *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 Section 3). + + * *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 [DC-SPEC]) and is reserved for back- + compatibility. It MUST NOT be redefined in a manner + incompatible with [DC-SPEC], and MAY only be defined by a + specification that extends this document. See Section 3, + Paragraph 13. + + * *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. + + * *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. + + A registration request MUST provide the following: + + RR Type: The record type name (the "type" value), conforming to the + dc-type-name syntax (see Section 3). + + Status: One of "Active", "Deprecated", or "Reserved". + + Class: "Fully Specified" or "Computed"; omitted for a "Reserved" + entry. + + DNS RR TYPE: The name of the corresponding IANA DNS RR TYPE, or "N/ + A". + + Kind: "IETF Standard", "Informational", or "Other". + + Reference: The document that defines the type, preferably including + a URI from which a copy can be retrieved. + + The following types from this specification constitute the initial + contents of the registry: + + +=============+========+===========+=======+========+=============+ + | *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 + +12.3. Domain Connect Settings Properties Registry IANA is requested to create a new registry named "Domain Connect - Settings Properties" under a new registry group "Domain Connect - Protocol". + Settings Properties" under the "Domain Connect Protocol" registry + group. - Registration policy: Specification Needed (see [RFC8126]). + Registration policy: Specification Required (see [RFC8126]), + following the procedure in Section 12.1. Each entry in the registry MUST include: @@ -2800,6 +2972,17 @@ Table of Contents * *Reference*: the document that defines the property. + A registration request MUST provide the following: + + Property name: The JSON key as it appears in the settings response. + + Status: One of "Active", "Deprecated", or "Reserved". + + Kind: "IETF Standard", "Informational", or "Other". + + Reference: The document that defines the property, preferably + including a URI from which a copy can be retrieved. + The following properties from this specification constitute the initial contents of the registry: @@ -2814,20 +2997,114 @@ Table of Contents +-----------------------+----------+---------------+---------------+ | "urlSyncUX" | Active | IETF Standard | This document | +-----------------------+----------+---------------+---------------+ - | "urlAsyncUX" | Reserved | IETF Standard | This document | + | "urlAsyncUX" | Reserved | Other | [DC-SPEC] | +-----------------------+----------+---------------+---------------+ | "urlAPI" | Active | IETF Standard | This document | +-----------------------+----------+---------------+---------------+ - | "width" | Active | IETF Standard | This document | + | "width" | Reserved | Other | [DC-SPEC] | +-----------------------+----------+---------------+---------------+ - | "height" | Active | IETF Standard | This document | + | "height" | Reserved | Other | [DC-SPEC] | +-----------------------+----------+---------------+---------------+ - | "urlControlPanel" | Active | IETF Standard | This document | + | "urlControlPanel" | Reserved | Other | [DC-SPEC] | +-----------------------+----------+---------------+---------------+ | "nameServers" | Active | IETF Standard | This document | +-----------------------+----------+---------------+---------------+ - Table 11: Initial Domain Connect Settings Properties + Table 10: Initial Domain Connect Settings Properties + +12.4. Guidance to the DNS Resource Record (RR) TYPEs Registry + + To avoid collisions between newly assigned DNS RR TYPE mnemonics and + the record type names used by Domain Connect, IANA is requested to + add the following note to the registration procedure of the "Resource + Record (RR) TYPEs" registry within the "Domain Name System (DNS) + Parameters" registry group (see [RFC6895]): + + | When evaluating a request to assign a new RR TYPE mnemonic, the + | designated experts SHOULD consult the "Domain Connect Fully + | Specified Record Types" registry. If the requested mnemonic + | matches the name of an entry in that registry whose *DNS RR TYPE* + | field is "N/A", the designated experts SHOULD flag the potential + | conflict and consult the designated experts of the "Domain Connect + | Fully Specified Record Types" registry before completing the + | assignment. + + This coupling ensures that a Domain Connect record type name that + does not (yet) correspond to a DNS RR TYPE - such as a "Computed" + type - is not inadvertently assigned a conflicting meaning in the DNS + RR TYPEs registry. + + In addition, IANA is requested to update the "Reference" of the + "Resource Record (RR) TYPEs" registry to cite this document alongside + the existing references: + + | OLD: [RFC6895][RFC1035] + | NEW: [RFC6895][RFC1035][This document] + + This records, on the DNS side, the obligation to consult the "Domain + Connect Fully Specified Record Types" registry described above. + +12.5. Underscore "_domainconnect" DNS Node Name + + Per [RFC8552], please add the following entry to the "Underscored and + Globally Scoped DNS Node Names" registry: + + +=========+================+================+ + | RR Type | _NODE NAME | Reference | + +=========+================+================+ + | TXT | _domainconnect | This document. | + +---------+----------------+----------------+ + + Table 11: IANA Registration for + _domainconnect + +12.6. Media Type Registration for application/domainconnect- + template+json + + IANA is requested to register the following media type in the "Media + Types" registry, per [RFC6838]. + + Type name: application + + Subtype name: domainconnect-template+json + + Required parameters: N/A + + Optional parameters: N/A + + Encoding considerations: binary; the content is a JSON [RFC8259] + document encoded in UTF-8. + + Security considerations: See Section 11 of this document. + + Interoperability considerations: See this document. + + Published specification: This document (see Section 6.1). + + Applications that use this media type: Domain Connect Service + Providers and DNS Providers. + + Fragment identifier considerations: The "+json" structured syntax + suffix is defined in [RFC6839]; see also [RFC8259]. + + Additional information: Deprecated alias names for this type: N/A + + Magic number(s): N/A + + File extension(s): N/A + + Macintosh file type code(s): N/A + + Person email address to contact for further information: IETF DCONN + Working Group + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: IETF DCONN Working Group + + Change controller: IETF Implementation Status @@ -2886,6 +3163,54 @@ Change History This section is to be removed before publishing as an RFC. +Change from draft-ietf-dconn-domainconnect-02 to -03 + + * Classified template record types as Fully Specified, Computed, or + Generic. + + * Added a shared Registration Procedure for Domain Connect + Registries section (designated-expert assignment and review + process) governing all Domain Connect registries. + + * Coupled the "Domain Connect Fully Specified Record Types" registry + to the IANA DNS Resource Record (RR) TYPEs registry as a + bidirectional maintenance contract (following the pattern set by + RFC 9108 for that registry). + + * Added Untrusted DNS Provider Discovery Records to Security + Considerations. + + * Clarified handling of multiple "_domainconnect" TXT records in DNS + Provider Discovery. + + * Deprecated and reserved the "warnPhishing" template flag in + Template Definition; phishing warnings are now default behavior, + see Template Variable Phishing. + + * Clarified one-host-one-key rule in Public Key Publication. + + * Added Media Type Registration for application/ + domainconnect-template+json in IANA Considerations. + + * Added media type identification to Template Definition. + + * Added HTTP content negotiation guidance to the Query Supported + Template end-point. + + * Added Identical Records to Conflict Detection and shared-record + retention to Calculating Conflict Resolution. + + * Added examples illustrating an optional path segment in the + "_domainconnect" TXT record content and in the settings-response + URL prefixes in DNS Provider Discovery. + + * Added Underscored Host Names to Security Considerations. + + * Marked the "width", "height" and "urlControlPanel" DNS Provider + Discovery settings properties as Reserved, deferring their + definition to [DC-SPEC]; removed reserved properties from the + example settings response. + Change from draft-ietf-dconn-domainconnect-01 to -02 * Removed the Asynchronous OAuth Flow from this document; the @@ -3057,6 +3382,11 @@ Normative References DOI 10.17487/RFC6335, BCP 165, RFC 6335, August 2011, . + [RFC6895] 3rd, D. E., "Domain Name System (DNS) IANA + Considerations", IETF, DOI 10.17487/RFC6895, BCP 42, + RFC 6895, April 2013, + . + [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", IETF, DOI 10.17487/RFC6570, RFC 6570, March 2012, @@ -3094,16 +3424,27 @@ Normative References DOI 10.17487/RFC9499, BCP 219, RFC 9499, March 2024, . -Informative References + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", IETF, + DOI 10.17487/RFC6838, BCP 13, RFC 6838, January 2013, + . - [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", IETF, - DOI 10.17487/RFC9364, BCP 237, RFC 9364, February 2023, - . + [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 [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, January 2013, + . + [DC-SPEC] Blinn, A., Kerola, S., and P. Kowalik, "Domain Connect Specification, Version 2.3 Rev. 67", 2 March 2025, - + - +