rfc9859v4.txt | rfc9859.txt | |||
---|---|---|---|---|
skipping to change at line 130 ¶ | skipping to change at line 130 ¶ | |||
delegation maintenance (such as DS or NS update hints), a service to | delegation maintenance (such as DS or NS update hints), a service to | |||
accept these notifications will need to be made available. Depending | accept these notifications will need to be made available. Depending | |||
on the context, this service may be run by the parent operator or by | on the context, this service may be run by the parent operator or by | |||
a designated entity who is in charge of handling the domain's | a designated entity who is in charge of handling the domain's | |||
delegation data (such as a domain registrar). | delegation data (such as a domain registrar). | |||
It seems desirable to minimize the number of steps that the | It seems desirable to minimize the number of steps that the | |||
notification sender needs to perform in order to figure out where to | notification sender needs to perform in order to figure out where to | |||
send the NOTIFY. This suggests that the lookup process be ignorant | send the NOTIFY. This suggests that the lookup process be ignorant | |||
of the details of the parent-side relationships (e.g., whether or not | of the details of the parent-side relationships (e.g., whether or not | |||
there is a registrar.) This is addressed by parameterizing the | there is a registrar). This is addressed by parameterizing the | |||
lookup with the name of the child. The parent operator may then | lookup with the name of the child. The parent operator may then | |||
(optionally) announce the notification endpoint in a delegation- | announce the notification endpoint in a delegation-specific way by | |||
specific way by publishing it at a child-specific name. (A catch-all | publishing it at a child-specific name. (A catch-all endpoint may be | |||
endpoint may be indicated by wildcarding.) | indicated by wildcarding.) | |||
The solution proposed here is thus for the parent operator to publish | The solution specified here is thus for the parent operator to | |||
the address where someone listens for notifications, in a child- | publish the address where someone listens for notifications, in a | |||
specific way (see Section 3). Potential senders can easily determine | child-specific way (see Section 3). Potential senders can easily | |||
the name of the parent and then look up that information (see | determine the name of the parent and then look up that information | |||
Section 4.1). | (see Section 4.1). | |||
1.2. Requirements Notation | 1.2. Requirements Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. DSYNC RR Type | 2. DSYNC RR Type | |||
skipping to change at line 167 ¶ | skipping to change at line 167 ¶ | |||
The DSYNC RDATA wire format is encoded as follows: | The DSYNC RDATA wire format is encoded as follows: | |||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| RRtype | Scheme | Port | | RRtype | Scheme | Port | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Target ... / | | Target ... / | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ | |||
Figure 1: DSYNC RDATA Wire Format | ||||
RRtype: The type of generalized NOTIFY that this DSYNC RR defines | RRtype: The type of generalized NOTIFY that this DSYNC RR defines | |||
the desired target address for (see the "Resource Record (RR) | the desired target address for (see the "Resource Record (RR) | |||
TYPEs" registry). For now, only CDS and CSYNC are supported | TYPEs" registry at <https://www.iana.org/assignments/dns- | |||
values, with the former indicating an updated CDS or CDNSKEY | parameters/>). For now, only CDS and CSYNC are supported values, | |||
record set. | with the former indicating an updated CDS or CDNSKEY record set. | |||
Scheme: The mode used for contacting the desired notification | Scheme: The mode used for contacting the desired notification | |||
address. This is an 8-bit unsigned integer. Records with value 0 | address. This is an 8-bit unsigned integer. Records with value 0 | |||
(null scheme) are ignored by consumers. Value 1 is described in | (null scheme) are ignored by consumers. Value 1 is described in | |||
this document, and values 128-255 are Reserved for Private Use. | this document, and values 128-255 are Reserved for Private Use. | |||
All other values are currently unassigned. | Other values are currently unassigned. Future assignments are | |||
maintained in the registry created in Section 6.2. | ||||
Port: The port on the target host of the notification service. This | Port: The transport port number on the target host of the | |||
is a 16-bit unsigned integer in network byte order. Records with | notification service. This is a 16-bit unsigned integer in | |||
value 0 are ignored by consumers. | network byte order. Records with value 0 are ignored by | |||
consumers. | ||||
Target: The fully-qualified, uncompressed domain name of the target | Target: The fully-qualified, uncompressed domain name of the target | |||
host providing the service of listening for generalized | host providing the service of listening for generalized | |||
notifications of the specified type. This name MUST resolve to | notifications of the specified type. This name MUST resolve to | |||
one or more address records. | one or more address records. | |||
2.2. Presentation Format | 2.2. Presentation Format | |||
The presentation format of the RDATA portion is as follows: | The presentation format of the RDATA portion is as follows: | |||
skipping to change at line 210 ¶ | skipping to change at line 214 ¶ | |||
* The Target field is represented as a <domain-name> (Section 5.1 of | * The Target field is represented as a <domain-name> (Section 5.1 of | |||
[RFC1035]). | [RFC1035]). | |||
2.3. Semantics | 2.3. Semantics | |||
For now, the only scheme defined is 1 (mnemonic: NOTIFY). By | For now, the only scheme defined is 1 (mnemonic: NOTIFY). By | |||
publishing a DSYNC record with this scheme, a parent indicates that | publishing a DSYNC record with this scheme, a parent indicates that | |||
they would like child operators to send them a NOTIFY message (see | they would like child operators to send them a NOTIFY message (see | |||
Section 4) upon publication of a new CDS/CDNSKEY/CSYNC RRset to the | Section 4) upon publication of a new CDS/CDNSKEY/CSYNC RRset to the | |||
address and port listed in that DSYNC record and using conventional | address and port number that correspond to that DSYNC record, using | |||
DNS transport [RFC1035]. | conventional DNS transport [RFC1035]. | |||
Example (for the owner names of these records, see Section 3): | Example (for the owner names of these records, see Section 3): | |||
IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net. | IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net. | |||
IN DSYNC CSYNC NOTIFY 5360 csync-scanner.example.net. | IN DSYNC CSYNC NOTIFY 5360 csync-scanner.example.net. | |||
Should a need for other mechanisms arise, other schemes may be | Should a need for other mechanisms arise, other schemes may be | |||
defined to deal with such requirements using alternative logic. | defined to deal with such requirements using alternative logic. | |||
Schemes are independent of the RRtype. They merely specify a method | Schemes are independent of the RRtype. They merely specify a method | |||
skipping to change at line 367 ¶ | skipping to change at line 371 ¶ | |||
_dsync label, remove them to construct a new lookup name (such | _dsync label, remove them to construct a new lookup name (such | |||
as _dsync.example). Then go to step 2. (This is to enable | as _dsync.example). Then go to step 2. (This is to enable | |||
zone structures without wildcards.) | zone structures without wildcards.) | |||
* Otherwise, return null (no notification target available). | * Otherwise, return null (no notification target available). | |||
4.2. Sending Notifications | 4.2. Sending Notifications | |||
When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child | When creating or changing a CDS/CDNSKEY/CSYNC RRset in the child | |||
zone, the DNS operator SHOULD send a suitable notification to one of | zone, the DNS operator SHOULD send a suitable notification to one of | |||
the endpoints discovered as described in the previous section. | the endpoints discovered as described in Section 4.1. | |||
A NOTIFY message can only carry information about changes concerning | A NOTIFY message can only carry information about changes concerning | |||
one child zone. When there are changes to several child zones, the | one child zone. When there are changes to several child zones, the | |||
sender MUST send a separate notification for each one. | sender MUST send a separate notification for each one. | |||
When a primary name server publishes a new RRset in the child, there | When a primary name server publishes a new RRset in the child, there | |||
typically is a time delay until all publicly visible copies of the | typically is a time delay until all publicly visible copies of the | |||
zone are updated. If the primary sends a notification at the exact | zone are updated. If the primary sends a notification at the exact | |||
time of publication, there is a potential for CDS/CDNSKEY/CSYNC | time of publication, there is a potential for CDS/CDNSKEY/CSYNC | |||
processing to be attempted before the corresponding records are | processing to be attempted before the corresponding records are | |||
skipping to change at line 466 ¶ | skipping to change at line 470 ¶ | |||
1. Acknowledge receipt by sending a NOTIFY response as described in | 1. Acknowledge receipt by sending a NOTIFY response as described in | |||
[RFC1996], Section 4.7, and schedule an immediate check of the | [RFC1996], Section 4.7, and schedule an immediate check of the | |||
CDS/CDNSKEY/CSYNC RRsets published by that particular child zone | CDS/CDNSKEY/CSYNC RRsets published by that particular child zone | |||
(as appropriate for the type of NOTIFY received). | (as appropriate for the type of NOTIFY received). | |||
If the NOTIFY message contains an EDNS0 Report-Channel option | If the NOTIFY message contains an EDNS0 Report-Channel option | |||
[RFC9567] with an agent domain subordinate or equal to one of the | [RFC9567] with an agent domain subordinate or equal to one of the | |||
NS hostnames listed in the delegation, the processing party | NS hostnames listed in the delegation, the processing party | |||
SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC | SHOULD report any errors occurring during CDS/CDNSKEY/CSYNC | |||
processing by sending a report query with an appropriate extended | processing by sending a report query with an appropriate EDE code | |||
DNS error (EDE) code as described in [RFC8914]. Reporting may be | as described in [RFC8914]. Reporting may be done asynchronously | |||
done asynchronously (outside of the NOTIFY transaction). | (outside of the NOTIFY transaction). | |||
When using periodic scanning, notifications preempt the scanning | When using periodic scanning, notifications preempt the scanning | |||
timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/ | timer. If the NOTIFY-induced check finds that the CDS/CDNSKEY/ | |||
CSYNC RRset is indeed new or has changed, the corresponding | CSYNC RRset is indeed new or has changed, the corresponding | |||
child's timer may be reset and the scanning frequency reduced | child's timer may be reset and the scanning frequency reduced | |||
(e.g., to once a week). If a CDS/CDNSKEY/CSYNC change is later | (e.g., to once a week). If a CDS/CDNSKEY/CSYNC change is later | |||
detected through scanning (without having received a | detected through scanning (without having received a | |||
notification), the NOTIFY-related state SHOULD be cleared, | notification), the NOTIFY-related state SHOULD be cleared, | |||
reverting to the default scanning schedule for this child. | reverting to the default scanning schedule for this child. | |||
skipping to change at line 627 ¶ | skipping to change at line 631 ¶ | |||
that the usage is not going to duplicate one that is already | that the usage is not going to duplicate one that is already | |||
registered and that the point is likely to be used in deployments. | registered and that the point is likely to be used in deployments. | |||
The code points tagged as "Private Use" are intended for testing | The code points tagged as "Private Use" are intended for testing | |||
purposes and closed environments. Code points in other ranges | purposes and closed environments. Code points in other ranges | |||
should not be assigned for testing. | should not be assigned for testing. | |||
* A specification of a scheme is desirable, but early assignment | * A specification of a scheme is desirable, but early assignment | |||
before a specification is available is also possible. When | before a specification is available is also possible. When | |||
specifications are not provided, the description provided needs to | specifications are not provided, the description provided needs to | |||
have sufficient information to identify what the point is being | have sufficient information to identify what the point is being | |||
used for. A scheme number may optionally have exactly one | used for. A scheme number may have exactly one mnemonic. | |||
mnemonic. | ||||
* Experts should take into account that field values are fit for | * Experts should take into account that field values are fit for | |||
purpose. For example, the mnemonic should be indicative and have | purpose. For example, the mnemonic should be indicative and have | |||
a plausible connection to the scheme's notification mechanism. | a plausible connection to the scheme's notification mechanism. | |||
6.3. _dsync Underscore Name | 6.3. _dsync Underscore Name | |||
Per [RFC8552], IANA has registered the following entries to the | Per [RFC8552], IANA has registered the following entries to the | |||
"Underscored and Globally Scoped DNS Node Names" registry within the | "Underscored and Globally Scoped DNS Node Names" registry within the | |||
"Domain Name System (DNS) Parameters" registry group: | "Domain Name System (DNS) Parameters" registry group: | |||
End of changes. 11 change blocks. | ||||
24 lines changed or deleted | 27 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |