]> The Swedish Internet Foundation

Sweden johan.stenstam@internetstiftelsen.se

The Swedish Internet Foundation

Sweden erik.bergstrom@internetstiftelsen.se

The Swedish Internet Foundation

Sweden leon.fernandez@internetstiftelsen.se

Internet DNSOP Working Group Internet-Draft Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastrophic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism based on DNS Dynamic Updates (DDNS) secured with SIG(0) signatures, sent from the child to the parent across the zone cut. The target of the update is discovered via the DSYNC record defined in . TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via-ddns. The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests.

Introduction For DNSSEC signed child zones with TLD registries as parents there is an emerging trend towards running so-called "CDS scanners" and "CSYNC scanners" by the parent. These scanners detect publication of CDS records (the child signalling a desire for an update to the DS RRset in the parent) and/or a CSYNC record (the child signalling a desire for an update to the NS RRset or, possibly, in-bailiwick glue in the parent). The scanners have a number of drawbacks, including being inefficient and slow. They are only applicable to DNSSEC-signed child zones and they add significant complexity to the parent operations. But given that, they do work. proposes a method to alleviate the inefficiency and slowness of scanners. But the DNSSEC requirement and the complexity remain. This document proposes an alternative mechanism to automate the updating of delegation information in the parent zone for a child zone based on DNS Dynamic Updates secured with SIG(0) signatures. This alternative mechanism shares the property of being efficient and provides rapid convergence (similar to generalized notifications in conjunction with scanners). Furthermore, it has the advantages of not requiring any scanners in the parent at all and also not being dependent on the child (and parent) being DNSSEC-signed. Knowledge of DNS NOTIFY and DNS Dynamic Updates and is assumed. DNS SIG(0) transaction signatures are documented in . In addition this Internet-Draft borrows heavily from the thoughts and problem statement from .

Requirements Notation 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.

Terminology

SIG(0)

The DNS transaction authentication mechanism of , which uses asymmetric (public-key) cryptography so that the recipient needs only the sender's public key to verify a signature created with the sender's private key.

UPDATE Receiver

The logical role that receives and processes DNS UPDATE messages on behalf of, or under the authority of, the parent zone operator. This role MAY be co-located with the parent's primary name server, run as a separate dedicated service operated by the parent, or operated by a third party (such as a registrar) on the parent's behalf. This document uses the single term "UPDATE Receiver" for this role throughout.

Bootstrap

The process of establishing initial trust in a SIG(0) public key. A key that has been received but not yet validated is "known"; once validated it is promoted to "trusted".

Applicability Because of the drawbacks of CDS and CSYNC scanners they are unlikely to be able to fully automate the maintenance of delegation information in all parent zones. The primary reasons are the hard requirement on DNSSEC in the child zones and the complexity cost of operating the scanner infrastructure. In practice, scanners are likely mostly realistic for parent zones that are operated by well-resourced registries. All the parts of the DNS name space where the parent is smaller and more resource constrained would be able to automate the delegation management via this mechanism without the requirement of operating scanners. Also all parts of the name space where there are child zones that are not DNSSEC-signed would be able to use this. Obviously, also well-resourced parent zones with DNSSEC-signed child zones would be able to use this DNS UPDATE-based mechanism, but in those cases scanners plus generalized notifications would also work.

DNS NOTIFY versus DNS UPDATE DNS NOTIFY and DNS UPDATE messages share several properties and are used to address similar issues.

Similarities between NOTIFY and UPDATE Both NOTIFY and UPDATE are "push" rather than "pull" messages and therefore very efficient. Both NOTIFY and UPDATE are messages, in DNS packet format. They are used by one party (the sender) to inform another party (the recipient) that some piece of DNS information has changed and that as a consequence of this change the recipient of the message may want to also make a change to its DNS data. A NOTIFY (as per ) is only a hint and the recipient may ignore it. But if the recipient does listen to the NOTIFY it should make its own lookups to verify what has changed and whether that should trigger any changes in the DNS data provided by the recipient.

Differences between NOTIFY and UPDATE The difference between the UPDATE and the NOTIFY is that the UPDATE contains the exact change that should (in the opinion of the sender) be applied to the recipient's DNS data. Furthermore, for secure Dynamic Updates, the message also contains proof why the update should be trusted (in the form of a digital signature by a key that the recipient trusts). In this document the term "Dynamic Update" or "DNS UPDATE" implies secure dynamic update. Furthermore this document implies that the signature algorithms are always based on asymmetric crypto keys, using the same algorithms as are being used for DNSSEC. With an appropriate choice of algorithm the SIG(0) signature is therefore as cryptographically strong as a DNSSEC signature. Note that this is a statement about the signature primitive only: the overall trust model still differs from DNSSEC, since a SIG(0) key is trusted individually (via the bootstrap of ) rather than through a chain of signatures back to a trust anchor. DNS UPDATEs can be used to update any information in a zone (subject to the policy of the recipient). In the special case addressed by this document, the data being updated is the delegation information for a child zone and the UPDATE is sent across a zone cut (i.e. the child sends it to the parent). In this case the UPDATE serves the same signalling purpose as a generalized NOTIFY, but additionally carries the exact change and the proof of its authenticity. The DNS UPDATE in this case is essentially a message that says:

Updating Delegation Information via DNS UPDATEs Updating delegation information in the parent via DNS UPDATE is not a new idea; there is prior art, including the expired . This document does not define a new update mechanism. The child's update to the delegation information is an ordinary DNS UPDATE , secured as a SIG(0)-signed transaction ; the NS, glue and DS changes it carries, and the way the UPDATE Receiver processes them, are exactly as specified there. What this document adds is a way for the parent to announce, via the DSYNC mechanism , whether it accepts such updates for a given child and where they are to be sent, together with the SIG(0) key management needed to authenticate them across the zone cut. The functionality to update delegation information in the parent zone via DNS UPDATE has been available for years in at least one DNS implementation (BIND9). However, while DNS UPDATE is used extensively inside organisations it has not seen much use across organisational boundaries. And zone cuts, almost by definition, usually cut across such boundaries. When sending a DNS UPDATE it is necessary to know where to send it. Inside an organisation this information is usually readily available. But outside the organisation it is not. And even if the sender would know where to send the update, it is not at all clear that the destination is reachable to the sender (the parent primary is likely to be protected by firewalls and other measures). This constitutes a problem for using DNS UPDATES across zone cuts. Another concern is that traditionally DNS UPDATEs are sent to a primary nameserver, and if the update signature verifies the update is automatically applied to the DNS zone. This is often not an acceptable mechanism. The recipient may, for good reason, require additional policy checks and likely an audit trail. Finally, the change should in many cases not be applied to the running zone but rather to some sort of provisioning system or a database. This creates another problem for using DNS UPDATEs for managing delegation information. Both problems are addressed by the target location mechanism defined in , described in the next section.

Locating the Target for a generalized NOTIFY and/or DNS UPDATE Section 3 of defines a new RR type, DSYNC, that has the following format:

where {target} is the domain name of the recipient of the NOTIFY message. {RRtype} is typically CDS or CSYNC in the case where delegation information should be updated (there are also other uses of generalized notifications). Finally, {scheme} is an 8 bit unsigned integer to indicate the type of notification mechanism to use. Scheme=1 is defined as "NOTIFY" (and the presentation format is also "NOTIFY"), as in "send a generalized NOTIFY to {target} on port {port}". This document proposes the definition of a new {scheme} for the same record that is used for generalized NOTIFY. Scheme=TBD is here defined as "UPDATE", as in "send a DNS UPDATE to {target} on port {port}". When parsing or presenting DNS zone data the 8 bit unsigned integer TBD should be replaced by the string "UPDATE", as in the examples below. Apart from defining a new scheme to specify the mechanism "UPDATE" (rather than the mechanism "NOTIFY") this document does not say anything about what Qname to look up or what RR type. The UPDATE mechanism should use exactly the same method of locating the target of the UPDATE as is used for generalized NOTIFY. This lookup addresses the first issue with using DNS UPDATE across organizational boundaries. Example 1: a parent zone announces support for DNS UPDATE as a mechanism for delegation synchronization for all child zones:

Example 2: a parent zone announces support for different DNS UPDATE targets on a per-child basis:

The DSYNC RRset is looked up, typically by the child primary name server or by a separate agent for the child, at the time that the delegation information for the child zone changes in some way that would prompt an update in the parent zone. When the {scheme} is "UPDATE" (the scheme value assigned by IANA in ) the interpretation is: Send a DNS UPDATE to the IP address for the name {target} on port {port}, where {target} and {port} are taken from the right-hand side of the DSYNC record that matches the qname in the DNS query.

Limitation of Scope for the Proposed Mechanism DNS UPDATE is in wide use all over the world, for all sorts of purposes. It is not in wide use across organizational boundaries. This document only addresses the specific case of a child zone that makes a change in its DNS delegation information that will require an update of the corresponding information in the parent zone. This includes: changes to the NS RRset changes to glue (if any) changes to the DS RRset (if any) changes to the KEY RRset (only used for validation of UPDATE messages) Only for those specific cases is the described mechanism proposed.

The UPDATE Receiver While the simplest design is to send the DNS UPDATEs to the primary name server of the parent it will in most cases be more interesting to send them to a separate UPDATE Receiver. To separate the primary name server from the UPDATE Receiver, use a {target} with addresses separate from the addresses of the primary name server.

Processing the UPDATE in the UPDATE Receiver The receiver of the DNS UPDATE messages should implement a suitably strict policy for what updates are accepted. Two distinct classes of update are in scope. The first is updates to the delegation information itself, where the policy typically allows only changes to the NS RRset, glue and DS RRset. The second is updates to the child's KEY RRset used to authenticate these UPDATEs; KEY changes are accepted only as part of the bootstrap and re-bootstrap procedures described in , and are subject to the additional validation rules stated there (in particular, a previously trusted key MUST NOT be removed until the replacement key has been validated). A single UPDATE used for delegation maintenance is not expected to also carry KEY changes. Furthermore, the receiver MUST only allow updates to the delegation information of a child zone when the UPDATE is signed by a trusted SIG(0) key whose name is the exact same name as the child zone, unless the receiver implements an alternative authorization scheme (for example a registrar-operated key authorized to manage many children). That is, in the absence of such a scheme, an UPDATE request for the delegation information for the zone child.parent. is only processed if it is signed by a trusted SIG(0) key with the name child.parent. and the signature verifies correctly. This name-scoping rule is the primary parent-side authorization control and is discussed further in . Once the DNS UPDATE message has been verified to be correctly signed by a known and trusted key with the correct name and also adhere to the update policy it should be subjected to the same set of correctness tests as a CDS/CSYNC scanner would have performed. For DS changes these are the acceptance checks defined for CDS/CDNSKEY processing in and ; for NS and glue changes they are the checks defined for CSYNC processing in . The parent applies the same policy regardless of whether the change arrives by scanning or by DNS UPDATE. If these requirements are also fulfilled the change may be applied to the parent zone in whatever manner the parent zone is maintained (as a text file, data in a database, via an API, etc).

Interpretation of the response to the DNS UPDATE All DNS transactions are designed as a pair of messages and this is true also for DNS UPDATE. The interpretation of the different responses to DNS UPDATE are fully documented in , section 2.2.

RCODE NOERROR A response with rcode=0 (NOERROR) should be interpreted as a confirmation that the DNS UPDATE has been received and accepted, i.e., the change to the parent DNS data should be expected to be published in the parent zone at some future time.

RCODE REFUSED A response with rcode=5 (REFUSED) should be interpreted as the receiver declining to process the UPDATE. Because the child only sends an UPDATE after the parent has announced support for it via publication of an appropriate target location record, a persistent REFUSED most likely indicates a parent-side misconfiguration. REFUSED may, however, also be a transient condition (for example a policy or rate-limit rejection, see ); a child SHOULD NOT treat a single REFUSED as a permanent signal to stop, but MAY do so after repeated REFUSED responses over time.

RCODE BADKEY A response with rcode=17 (BADKEY) should be interpreted as a definitive statement that the UPDATE Receiver does not have access to the public SIG(0) key needed for signature verification, i.e. that the key is unknown to the receiver. In this case the child should fall back to bootstrap of the SIG(0) public key into the DNS UPDATE Receiver, see below. BADKEY does not distinguish the intermediate states in which the receiver has the key but has not yet trusted it (for example, a bootstrap that is in progress, where the child should wait, or one whose validation has failed, where re-bootstrapping will not help). Those states are conveyed via the Extended DNS Error codes of ; a child that receives BADKEY without such an error treats the key as unknown and (re-)initiates bootstrap.

No response to a DNS UPDATE The case of no response is more complex, as it is not possible to know whether the DNS UPDATE actually reached the receiver (or was lost in transit) or the response was not sent (or lost in transit). Whether and how to retry depends on the sender's situation. For example, if the sender of the DNS UPDATE message (perhaps the primary name server of the child zone) only serves a single child, then resending the DNS UPDATE once or twice may be worthwhile (to ensure that the lack of response is not due to packets being lost in transit). On the other hand, if the sender serves a large number of child zones below the same parent zone, then it may already know that the receiver for the DNS UPDATEs is not responding for any of the child zones, and resending the update immediately is likely pointless. A sender that retries SHOULD wait at least 5 seconds before treating the absence of a response as a timeout, SHOULD apply exponential backoff between successive retries (e.g. doubling the interval each time), and SHOULD give up after no more than 5 retries for a given UPDATE. A sender MAY deviate from these defaults based on local knowledge, such as the per-receiver observations described above.

Management of SIG(0) Public Keys Only the child should have access to the SIG(0) private key. The corresponding SIG(0) public key should preferably be published in DNS, but it doesn't have to be. The SIG(0) public key only needs to be available to the parent UPDATE Receiver. Keeping all the public SIG(0) keys for different child zones in some sort of database is perfectly fine.

Choice of SIG(0) Signature Algorithm The child's SIG(0) public key is, in the common case, discoverable in DNS: either at the child apex, or at the _sig0key.{child}._signal.{nameserver}. name in the nameserver's zone, or via multi-query convergence against the child KEY RRset. In each case the public key is recoverable by any party that can issue DNS queries. An adversary capable of breaking the signature algorithm of the SIG(0) key from the public key alone can therefore forge DNS UPDATEs to the parent UPDATE Receiver and substitute arbitrary delegation information. The integrity of the entire mechanism rests on the SIG(0) key remaining unforgeable for the operational lifetime of the delegation. The DNS UPDATEs described in this document are infrequent and SHOULD be carried over TCP (or a connection-oriented secure transport such as DoT); this avoids the spoofing and fragmentation exposure of UDP for a message that mutates parent-side state, and accommodates the larger SIG(0) signatures discussed below. Unlike DNSSEC validation traffic, which is size-sensitive because of the per-query UDP path, this path imposes no significant wire-size constraint on the SIG(0) signature. The larger public keys and signatures of post-quantum algorithms will therefore not be a deployment obstacle for SIG(0) on the DDNS UPDATE path even though they would be a serious obstacle on most ordinary DNSSEC paths. As post-quantum signature algorithms such as ML-DSA and SLH-DSA become standardized for DNSSEC use and are supported by parent UPDATE Receivers, child operators are encouraged to adopt them for the SIG(0) key on this path: there is no operational reason to prefer a classical algorithm here. The experimental algorithm code-point range proposed in provides one path by which a PQ-safe algorithm can be used on this path before full IETF standardization completes.

Communication Between Child and Parent UPDATE Receiver There are two cases where communication between child and parent UPDATE Receiver would benefit greatly from some additional information. The bootstrap states named in the subsections below are defined in .

Communication in Case of Errors An error response from the parent UPDATE Receiver is improved by more detail provided via Extended DNS Errors . When the child's key is known to the receiver but the UPDATE cannot yet be applied because the key is not (or no longer) trusted, the receiver returns RCODE REFUSED carrying one of the Extended DNS Error codes below; this is distinct from BADKEY, which indicates that the key is unknown (). To that end this document defines three new Extended DNS Error codes (see ), expressing the following bootstrap "states": "SIG(0) key is known, but not yet trusted": indicating that bootstrap of the key is not yet complete. Waiting may resolve the issue. "SIG(0) key is known, but validation failed": indicating that bootstrap has failed and waiting will not resolve the issue. "Automatic bootstrap of SIG(0) keys not supported; manual bootstrap required": indicating that while the parent does support delegation synchronization via DNS UPDATE, it only supports manual bootstrap. Note that the child should normally discover this via the SVCB bootstrap SvcParamKey before attempting automatic bootstrap; this error serves as a fallback for cases where that discovery was not performed or the SVCB record was not available. These Extended DNS Error codes are the always-available baseline channel for conveying key-state detail in error responses. A richer, optional channel - able to carry inquiries and key identifiers for automated processing - is provided by the KeyState OPT of , described in .

Communication To Inquire State Extended DNS Errors provides an excellent mechanism for adding more detail to error responses. However it is, intentionally, limited to: returning extra information from the receiver to the original sender. It is not possible to "send" information, only "return" information. no information except the actual error code is meant for automatic processing. It is therefore not possible to communicate things like, e.g. a KeyId via Extended DNS Errors. The communication between child and parent would benefit from the addition of the ability to also send inquiries to the parent. For example, the child should be able to inquire about key state: "I operate under the assumption that the key {key} is known and trusted by you (the parent). Is this correct?" is proposed as a mechanism to improve the communication between child and parent, both in the error case and in the inquiry case. If that draft is supported then the above example would travel as "KeyState codes" in a KeyState OPT as specified in .

Mutual Authentication For the KeyState communication described above to be trustworthy, the child must be able to verify that responses from the UPDATE Receiver are authentic. Otherwise an adversary could potentially cause disruption by sending forged responses, e.g. falsely claiming that the child's key is unknown and triggering an unnecessary re-bootstrap. For this reason the UPDATE Receiver SHOULD also maintain a SIG(0) key pair and use its private key to sign responses to the child. This enables mutual authentication: the child authenticates to the parent via its SIG(0) signature on the UPDATE, and the parent authenticates to the child via its SIG(0) signature on the response. When the child makes key-state inquiries (for example via the KeyState mechanism of ), the UPDATE Receiver MUST sign its responses, since an unsigned response to such an inquiry is exactly the forged-response vector described above. Mutual authentication depends on the child being able to validate the UPDATE Receiver's key (see ). In the common case the parent zone is DNSSEC-signed and this validation is automatic. When the parent zone is unsigned, the child can only obtain the Receiver's key via manual bootstrap; absent that, mutual authentication is unavailable, and responses cannot be authenticated - leaving the forged-response disruption above as a residual risk that the operator accepts. The bootstrap problem therefore arises in both directions: the parent needs to acquire and trust the child's SIG(0) public key, and the child needs to acquire and trust the UPDATE Receiver's SIG(0) public key. covers both halves.

Bootstrapping SIG(0) Public Keys This section has two parts. The first describes how the parent UPDATE Receiver acquires and trusts the child's SIG(0) public key. The second describes how the child acquires and trusts the UPDATE Receiver's SIG(0) public key. Both halves use the same underlying DNS-based discovery and DNSSEC-validation pattern, applied to the two parties in turn.

Bootstrapping the Child's Key Into the UPDATE Receiver Bootstrap of the child public SIG(0) key to be trusted by the UPDATE Receiver may be done either manually or automatically. Manually may in various cases be the preferred method, especially in the case of non-registry parents with a small number of child delegations. If the UPDATE Receiver only supports manual bootstrap, then that is what will happen (apart from informing the child about this policy). The set of bootstrap methods a parent supports is not negotiated by the child; it is advertised by the parent through the bootstrap SvcParamKey (). A child that requires manual bootstrap therefore selects a parent (or an UPDATE Receiver) that advertises manual, or arranges it out of band. In those cases there is by definition some mechanism in place to communicate information from the child to the parent, be it email, a web form, pieces of paper or something else. The same mechanism can be extended to also be used to communicate the initial SIG(0) public key from the child to the parent. Regardless of whether manual bootstrap or automatic bootstrap is to be used (subject to the UPDATE Receiver policy), the bootstrap must be initiated. This is done by the child issuing a self-signed DNS UPDATE to the parent containing:

The first record is an instruction to delete any previous keys for this child (CLASS=ANY in a DNS UPDATE is a request to delete an entire RRset). The second is an instruction to add the new key. When receiving such a message (where the self-signature validates) the parent UPDATE Receiver SHOULD mark that key as "known" (but not yet trusted) and then either put that key into a queue for later look up and validation of the corresponding KEY record (if supporting automatic bootstrap) or put that key into a queue for subsequent manual validation and verification. A self-signature is made by the very key being added, so its validation proves only that the sender possesses the corresponding private key; it does not, by itself, prove that the sender is authorized to manage the child's delegation. That authorization is established only by the subsequent validation step (DNSSEC validation of the published KEY, or manual verification) before the key is promoted to "trusted". For this reason the receiver MUST NOT act on the DEL ... ANY KEY instruction in a bootstrap UPDATE to remove an already-trusted key until the newly added key has been validated (see ). Automated bootstrapping is also possible, subject to the policy of the UPDATE Receiver. The basic idea is to publish the public SIG(0) key as a KEY record either at the child apex or at a special name below the name of an authoritative nameserver for the zone located in a DNSSEC- signed zone. This publication must occur prior to the initial key upload. Then the UPDATE Receiver (or an agent) may look that KEY up for subsequent validation. The following three subsections describe the three automatic bootstrap methods this document defines, one per case of child-zone signing status.

When Child Zone Is DNSSEC-signed If the child zone is DNSSEC-signed (including a signed delegation via a DS record), then the KEY record containing the SIG(0) public key located at the zone apex can be looked up and validated by the DNS UPDATE Receiver.

In case of validation success the key SHOULD be promoted to "trusted" by the UPDATE Receiver. At this point any superseded keys SHOULD be deleted (note that this is the validation-success path; on the re-bootstrap path a previously trusted key MUST NOT be deleted until the replacement key has been validated, see ). In case of validation failure (or absence of a DNSSEC signature) the SIG(0) SHOULD NOT be promoted to the set of keys that the UPDATE Receiver trusts and any old keys MUST be kept.

When Child Nameserver Is In A DNSSEC-signed Zone If the child zone is unsigned but at least one of the authoritative nameservers for the zone is located in a DNSSEC-signed zone (including a signed delegation via a DS record), then the KEY record containing the SIG(0) public key can be looked up and validated by the DNS UPDATE Receiver. Example: assume that the unsigned child zone child.parent. has two nameservers:

ns.child.parent. is located in the unsigned zone child.parent. and a KEY record located under that name can not be DNSSEC-validated. ns.provider.example. on the other hand is located in a DNSSEC signed zone. In this case the KEY record containing the public SIG(0) key for child.parent. may be located at the special label _sig0key.{child}._signal.{nameserver}:

The underscored globally scoped label _signal in this name pattern is the one registered by for DNSSEC bootstrap (see ). The leading _sig0key label is introduced by this document to distinguish the SIG(0) bootstrap use case from the CDS/CDNSKEY use case defined in . In case of validation success the key SHOULD be promoted to "trusted" by the UPDATE Receiver. At this point any superseded keys SHOULD be deleted (note that this is the validation-success path; on the re-bootstrap path a previously trusted key MUST NOT be deleted until the replacement key has been validated, see ). In case of validation failure (or absence of a DNSSEC signature) the SIG(0) SHOULD NOT be promoted to the set of keys that the UPDATE Receiver trusts and any old keys MUST be kept. This bootstrap mechanism is identical to the method used for DNSSEC bootstrap as described in . As the proof of the SIG(0) key being authentic is based on a clear DNSSEC signature chain this method is as secure as if the child zone had been signed. Operator coordination via HSYNCPARAM. The KEY record at _sig0key.{child}._signal.{nameserver}. must be published by the operator of the nameserver's zone, not by the operator of the child zone. The child operator therefore needs a mechanism to instruct each of the child's nameserver operators that they should publish the KEY record under the appropriate _sig0key.{child}._signal.{their-ns-name}. name within their own zone. This document recommends, but does not require, that this instruction be conveyed via the pubkey key of the HSYNCPARAM record defined in . HSYNCPARAM is published in the child zone, and the providers of the child zone are authoritative for that zone and can therefore observe HSYNCPARAM directly. The pubkey signal expresses the child operator's intent that each provider SHOULD publish the child's SIG(0) KEY at _sig0key.{child}._signal.{their-ns-name}. in their own zone. The mechanics of how each provider acts on this signal (operational coordination, provisioning APIs, internal handoffs, etc.) are out of scope for this document.

When Child Zone Is Unsigned Hence, to bootstrap the public SIG(0) key for a child zone it is possible for the parent to use a "bootstrap policy" a la: Look up the KEY RRset in the child zone. Compare to the child KEY received in the self-signed DNS UPDATE. To mitigate a possible on-path attacker, do the look up of the child KEY RRset, using TCP transport, from multiple vantage points, at multiple times. The child KEY RRset must be consistent over time and space. Make on-path attacks even more difficult by adding a requirement to, in addition to TCP, also use a more secure transport, like DoT, DoH or DoQ once those become more generally available for DNS queries to authoritative servers. The child KEY RRset must be consistent over all tested transports. If the received KEY RRset is consistent from multiple vantage points and multiple times then it is considered authentic and promoted by the parent's UPDATE Receiver from "known" to "trusted" SIG(0) key for the child. At this point any superseded SIG(0) public keys for the child SHOULD be deleted (on the validation-success path; see the MUST NOT-delete-until-validated rule for re-bootstrap in ). Should a "registry" parent want to support this mechanism (as a service to its unsigned children) then a likely model is that the target of the DNS UPDATE is operated by the registrar (or possibly that the DNS UPDATE is forwarded to the registrar). The registrar performs its normal verifications of a change and then transforms the update into an EPP transaction to communicate it to the registry. This bootstrap mechanism for the case of an unsigned child reuses the "acceptance" method standardized in for automatic DNSSEC bootstrapping via CDS, which multiple TLD registries provide today. Its security properties and limitations are therefore those of , not new ones introduced here: it does not provide the provable authenticity of the two DNSSEC-validated methods above, and its strength against on-path attackers increases with the number and diversity of vantage points and transports used, but it cannot exceed the authenticity of the child's own authoritative servers. In particular, this method authenticates the current operator of the child's delegation, not the registrant: an attacker who controls (or is on-path to all of) the child's authoritative name servers can present a chosen KEY. That exposure, however, is not introduced by this mechanism - such an attacker can already manipulate the child zone regardless. The remedies (using reputable providers, and signing the child zone, which enables the stronger at-apex and at-ns methods) are out of scope for this document. For these reasons this is the weakest of the defined bootstrap methods; a parent advertises whether it supports it via the unsigned token of the bootstrap SvcParamKey ().

Bootstrapping the UPDATE Receiver's Key Into the Child

Publishing the UPDATE Receiver's Key The UPDATE Receiver SHOULD publish its public SIG(0) key as a KEY record at the domain name that is the {target} of the DSYNC record. Example:

Acquiring and Validating the UPDATE Receiver's Key The child needs to acquire and validate the UPDATE Receiver's public SIG(0) key before it can verify signed responses. Two methods are defined: If the KEY record for the UPDATE Receiver is located in a DNSSEC-signed zone (which is expected in the common case where the parent zone is DNSSEC-signed), the child looks up the KEY record and performs standard DNSSEC validation. On validation success the key is trusted. If the KEY record is not in a DNSSEC-signed zone, manual bootstrap is required. The same out-of-band mechanisms available for bootstrapping the child key (email, web form, etc.) may be used in reverse.

Publishing Supported Bootstrap Methods As there are multiple possible methods to bootstrap the initial SIG(0) public key to become trusted by the parent it becomes important for child zone operators to be able to find out which method to use. For this purpose, a parent that operates an UPDATE Receiver MAY publish an SVCB record at the {target} of the DSYNC record, announcing the capabilities of that UPDATE Receiver. This re-uses the SVCB-at-DSYNC-target convention introduced by (where it announces CDS and CSYNC scanner capabilities). The relevant capability for the UPDATE Receiver is the set of supported bootstrap methods, carried in the bootstrap SvcParamKey defined below; this document describes that use in full, so it does not depend on for interoperability.

SvcParamKey bootstrap The bootstrap SvcParamKey in the SVCB record is used to signal what mechanisms are supported for bootstrapping the trust of the child's public SIG(0) key to the UPDATE Receiver. Four mechanisms are currently identified: at-apex: This is an indication that the UPDATE Receiver supports automatic bootstrap of the SIG(0) public key for signed child zones by the child publishing the DNSSEC-signed KEY record at the child zone apex.

See . at-ns: This is an indication that the UPDATE Receiver supports automatic bootstrap of the SIG(0) public key by publishing the KEY record both at the child zone apex AND at the special name _sig0key.{child}._signal.{nameserver}. below the name of an authoritative nameserver located in a signed zone. The apex KEY is published so that the nameserver operators can re-publish it under the special name, where it is DNSSEC-signed and can be validated. This mechanism is similar to what is described in for CDS bootstrap:

See . unsigned: This method is similar to what describes for CDS bootstrapping.

See . manual: This is an indication that the UPDATE Receiver supports some other mechanism for bootstrap of the SIG(0) public key. The value of the bootstrap key is a string with one or more of the supported mechanisms, separated by ,. The mechanisms may occur in arbitrary order. New mechanisms are likely to be defined in the future.

Complete Example Example for a parent that operates an UPDATE Receiver that only supports the secure automatic bootstrap methods at-apex and at-ns. Otherwise manual bootstrap is needed.

That is, this UPDATE Receiver does not support the unsigned method based on .

Rolling the SIG(0) Key Once the parent (or registrar) UPDATE Receiver has the key, the child can update it via a DNS UPDATE just like updating the NS RRset, the DS RRset or the glue in the parent zone (assuming a suitable DNS UPDATE policy in the parent), i.e., only the initial bootstrapping of the key is an issue. Note, however, that the alternative of re-bootstrapping (by whatever bootstrapping mechanism was used) in case of a key compromise may be a better alternative to the parent supporting key rollover for child SIG(0) keys. The decision of whether to allow SIG(0) key rollover via DNS UPDATE is left as parent-side policy.

Re-bootstrapping In Case of Errors Sometimes things get out of sync in spite of all efforts. It could be an operator error in the parent end losing the child public key or it could be an error in the child end losing the private key. Another possibility could be a key rollover that for some reason didn't sync correctly. If is supported then the child can inquire with the UPDATE Receiver about the KeyState of the SIG(0) key it would use in an UPDATE request. In all such cases, as soon as the child becomes aware of the problem it should simply re-bootstrap by the same mechanism as used initially. The self-signed DNS UPDATE that starts the bootstrapping process contains the instruction

which directs the parent UPDATE Receiver to delete any SIG(0) public keys for this child (and after that to start the process of validating the new key). Note that when receiving such a self-signed DNS UPDATE the parent MUST NOT delete any old keys until the new key has been validated and therefore promoted to "trusted". This is needed and important to avoid the potential attack vector of an adversary causing a parent to invalidate the child key by just sending a self-signed bootstrap UPDATE (which will not validate, but if the old key is deleted then the harm would already be done).

Scalability Considerations The primary existing mechanism for automatic synchronization of DNS delegation information is based on parent-side "scanning" of the child zones for CDS and/or CSYNC RRsets, performing DNSSEC validation on the result and then, in the CSYNC case, based on the result, issue and validate a potentially large number of additional DNS queries, all of which must be DNSSEC validated. This makes a CDS/CSYNC scanner for a parent with a significant number of delegations a complex and resource consuming service. Among the issues are rate-limiting by large DNS operators and inherent difficulties in issuing millions of recursive DNS queries where all received data must be validated. By comparison, the DNS UPDATE based mechanism for automatic synchronization shifts most of the effort to the child side. It is the child that is responsible for detecting the need to update the delegation information in the parent zone (which makes sense as it is the child that has made a change and therefore, in many cases, already "knows"). It is the child rather than the parent that computes what records should be added or removed. All of this is good for scalability. Furthermore, the information collection and validation effort for the UPDATE Receiver is restricted to validation of a single DNS message, using a SIG(0) key that the UPDATE Receiver already has. Hence, as the data collection and validation is much simplified the task of the UPDATE Receiver is mostly focused on the policy issues of whether to approve the UPDATE or not (i.e. the same process that a CDS and/or CSYNC scanner follows). Note that this is a shift of complexity, not an elimination of it. The receiver-side policy checks, audit trail, and integration with the parent's provisioning system are still required, just as they would be for a scanner-based mechanism. The principal scalability gain is the avoidance of the scanning round-trip latency: the parent no longer needs to poll every child zone on a fixed cadence in order to detect a change, because the child updates the parent at the moment the change happens.

Security Considerations Any fully automatic mechanism to update the contents of a DNS zone opens up a potential vulnerability should the mechanism not be implemented correctly. In this case the definition of "correct" is a question for the receiver of the DNS UPDATE. The receiver should verify the authenticity of the DNS UPDATE and then do the same checks and verifications as a CDS or CSYNC scanner does. The difference from the scanner is only in the validation: single SIG(0) signature by a key that the UPDATE Receiver trusts vs DNSSEC signatures that chain back to a DNSSEC trust anchor that the validator trusts. Another issue of concern is whether a parent-side service that provides support for changes to child delegation information via DNS UPDATE is open for potential denial-of-service attacks. The answer is likely no, as it is possible to have a very strict rate-limiting policy based on the observation that no child zone should have a legitimate need to change its delegation information frequently. Furthermore, as the location of the UPDATE Receiver can be separated from any parent name server even in the worst case the only service that can be subject to an attack is the UPDATE Receiver itself, which is a service that previously did not exist.

Authorization Scoping The most important parent-side authorization control is the name- scoping rule of , which requires an UPDATE to the delegation information of child.parent. to be signed by a trusted SIG(0) key named child.parent.. This binds the authority to change a child's delegation to possession of a key bootstrapped specifically for that child, and prevents one child (or one compromised key) from altering the delegation of another. The rule permits an alternative authorization scheme (for example a registrar-operated key authorized to manage many children); a receiver that uses one takes on the corresponding responsibility for authorizing each change by other means.

SIG(0) Key Bootstrap The trust the UPDATE Receiver places in a child's SIG(0) key is only as strong as the bootstrap method used to acquire it. The at-apex and at-ns methods derive trust from a DNSSEC signature chain and are as strong as DNSSEC. The unsigned method (see ) reuses the acceptance method and authenticates only the current operator of the child's authoritative servers, not the registrant; it is the weakest method and cannot defend against an attacker who controls those servers (an exposure that exists independently of this mechanism). A receiver discovers which bootstrap methods a child can use, and a child discovers which methods a parent supports, via the bootstrap SvcParamKey (). Because that SVCB record is published in the parent's zone, an attacker able to forge it could attempt a downgrade - steering a child toward the weaker unsigned method. A parent that supports DNSSEC SHOULD sign the SVCB record so that children can detect such tampering; a child SHOULD prefer the strongest method the parent advertises that it can satisfy. During (re-)bootstrap the receiver MUST NOT delete a previously trusted key until a newly presented key has been validated (see ). This prevents an attacker from using a forged or self-signed bootstrap UPDATE to evict a good key and substitute its own.

Authenticating Responses Responses from the UPDATE Receiver are authenticated only when the receiver signs them with its own SIG(0) key and the child has validated that key (see ). When the parent zone is unsigned and no manual receiver-key bootstrap has been performed, responses cannot be authenticated, and an attacker able to inject responses could, for example, falsely report a key as unknown and trigger unnecessary re-bootstrap. This is a denial/disruption risk rather than an integrity risk: it cannot cause an unauthorized delegation change. Whether to act on unauthenticated responses when receiver-key trust cannot be established is subject to local policy.

Replay A DNS UPDATE in this mechanism is protected by its SIG(0) signature, whose validity is bounded by the inception and expiration times of the signature . Receivers MUST reject UPDATEs whose signature time is outside an acceptable window, and the window SHOULD be kept small, to limit the value of a captured UPDATE to an attacker.

IANA Considerations IANA is requested to assign a new scheme value to the registry for "DSYNC Location of Synchronization Endpoints" as follows:

Reference

(this document)

RRtype Scheme Purpose Reference ANY TBD Delegation management (this document)

Underscored Node Name IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry , alongside the entries added by : RR Type _NODE NAME Reference KEY _signal (this document) registered the _signal global underscored label for the CDS and CDNSKEY RR types; this document adds an entry for the KEY RR type at the same global label, for SIG(0) key bootstrap. See for the name pattern in which this label is used. The subordinate label _sig0key introduced by this document (in _sig0key.{child}._signal.{nameserver}.) is not separately registered: per , only the global underscored node name (_signal) is registered, and labels subordinate to it are the responsibility of the specification that uses the global label.

SVCB SvcParamKey bootstrap IANA is requested to register a new SvcParamKey in the "Service Binding (SVCB) Parameter Registry" (per Section 14.3.2 of ): Number Name Meaning Reference TBD bootstrap SIG(0) key bootstrap methods supported (this document) The format and use of this SvcParamKey are defined in . Its value is a comma-separated list of tokens from the "DSYNC SIG(0) Bootstrap Mechanisms" registry below.

DSYNC SIG(0) Bootstrap Mechanisms Registry IANA is requested to create a new registry, "DSYNC SIG(0) Bootstrap Mechanisms", to hold the tokens that may appear in the value of the bootstrap SvcParamKey. The registration policy is Specification Required (). Each entry has a token (a short case-sensitive string), a brief description, and a reference. The initial contents are: Token Description Reference at-apex KEY published, DNSSEC-signed, at the child zone apex (this document) at-ns KEY published under _sig0key.{child}._signal.{nameserver} in a signed nameserver zone (this document) unsigned RFC 8078-style multiple-vantage-point acceptance (this document) manual Out-of-band / manual bootstrap (this document)

Extended DNS Error Codes IANA is requested to register three new Extended DNS Error codes in the "Extended DNS Error Codes" registry : INFO-CODE Mnemonic Purpose Reference TBD KEY-KNOWN-NOT-TRUSTED SIG(0) key known but not yet trusted (this document) TBD KEY-VALIDATION-FAILED SIG(0) key known but validation failed (this document) TBD MANUAL-BOOTSTRAP-REQUIRED Automatic SIG(0) bootstrap not supported; manual bootstrap required (this document) The meaning and intended use of these codes are described in .

Acknowledgements Peter Thomassen and I together came up with the location mechanism for the generalized notifications, which this draft relies upon. Mark Andrews provided the initial inspiration for writing some code to experiment with the combination of the location mechanism from the generalised notifications with DNS UPDATEs across zone cuts. Stefan Ubbink helped me realize the need to also cater for the case of re-bootstrapping if or when things got out of sync for some reason.

This document generalizes and extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints to allow other types of actions that were previously lacking a trigger mechanism to be triggered via the DNS. Notifications merely nudge the receiver to initiate a predefined action promptly (instead of on a schedule); they do not alter the action itself (including any security checks it might employ). To enable this functionality, a method for discovering the receiver endpoint for such notification messages is introduced, via the new DSYNC record type. Notification types are recorded in a new registry, with initial support for parental NS and DS record updates including DNSSEC bootstrapping. This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK] Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK] This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK] This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. This document introduces an in-band method for DNS operators to publish arbitrary information about the zones for which they are authoritative, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document establishes the DS enrollment method described in Section 4 of this document as the preferred method over those from Section 3 of RFC 8078. It also updates RFC 7344. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) ISC DNS UPDATE was developed to allow DNS zones to be updated. There is a perception that UPDATE cannot be used in conjuction with the Registry, Registar, Registrant (RRR) model to update a zone. This document explains how UPDATE can be used in the RRR model. This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. The Swedish Internet Foundation The DNSSEC Algorithm Numbers registry contains two code points, 253 (PRIVATEDNS) and 254 (PRIVATEOID), intended for private and experimental algorithms. These code points identify the algorithm by prepending a domain name or an object identifier to the "Public Key" field of the DNSKEY RDATA, overloading the semantics of that field and forcing every implementation to special-case algorithm dispatch. Because all such algorithms share a single code point, they cannot be distinguished on the wire by the algorithm number alone. This document reserves two small ranges of DNSSEC algorithm numbers: one for Private Use, requiring no IANA registration, and one for experimental algorithms, registered on a First Come First Served basis. Code points drawn from these ranges behave identically to ordinary algorithm numbers and require no overloading of the DNSKEY RDATA. This enables clean experimentation with the growing set of post-quantum and other candidate signature algorithms. This document updates RFC 6014 and RFC 9157. The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation This document introduces the KeyState EDNS(0) option code, to enable the exchange of SIG(0) key state information between DNS entities via the DNS protocol. The KeyState option allows DNS clients and servers to include key state data in both queries and responses, facilitating mutual awareness of SIG(0) key status between child and parent zones. This mechanism addresses the challenges of maintaining synchronization of SIG(0) keys used for securing DNS UPDATE messages, thereby enhancing the efficiency and reliability of DNS operations that require coordinated key management. This document proposes such a mechanism. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-opt-transaction-state (https://github.com/johanix/draft-berra-dnsop-transaction-state-00). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation Edgemoor Research Institute This document introduces a standardized mechanism for zone owners to signal their intent regarding DNS provider responsibilities through DNS itself. It defines two new DNS RRtypes -- HSYNC (Horizontal Synchronization, per-provider enrollment) and HSYNCPARAM (zone-wide multi-provider policy) -- that together enable zone owners to designate which Providers are authorized to serve and/or sign their zones, control whether Providers or the zone owner manages the NS RRset, and specify zone transfer chain configurations. The HSYNC and HSYNCPARAM records allow DNS Providers to discover each other and establish secure communication, either using the JOSE framework over DNS or via a RESTful API secured by TLS. This provider-to-provider communication enables automated coordination for tasks such as NS RRset management and DNSSEC-related operations. The document describes how the Providers discover one another, establish secure communication, and maintain it with periodic keep-alives; this specification covers those discovery and communication-establishment aspects, while the on-the-wire framing of the messages the Providers exchange is defined in a companion document. While a distributed DNSSEC multi-signer architecture (similar to "model 2" in [RFC8901]) is an important application of this framework, the HSYNC-based signaling supports broader provider synchronization needs. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-signaling-zone-owner- intent (https://github.com/johanix/draft-leon-dnsop-signaling-zone- owner-intent). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation In DNS operations, automated scanners are commonly employed by the operator of a parent zone to detect the presence of specific records, such as CDS or CSYNC, in child zones, indicating a desire for delegation updates. However, the presence and periodicity of these scanners are typically implicit and undocumented, leading to inefficiencies and uncertainties. This document proposes an extension to the semantics of the DSYNC resource record, as defined in [RFC9859], allowing parent zones to explicitly signal the presence and scanning interval of such automated scanners. This enhancement aims to improve transparency and coordination between child and parent zones. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-announce-scanner (https://github.com/johanix/draft-berra-dnsop-announce-scanner). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests.

Change History (to be removed before publication) draft-ietf-dnsop-delegation-mgmt-via-ddns-02

• Restructured Section Management of SIG(0) Public Keys to expose the two-direction bootstrap symmetry: Section Mutual Authentication now motivates a single Section Bootstrapping SIG(0) Public Keys section with subsections for the child's key and the UPDATE Receiver's key.

• Added Section Choice of SIG(0) Signature Algorithm covering the case for adopting a PQ-safe algorithm on this path once available.

• Added Section Operator coordination via HSYNCPARAM (a pubkey key in the HSYNCPARAM record from draft-leon-dnsop-signaling-zone-owner-intent) for the at-ns bootstrap method, and an IANA request for a (KEY, _signal) entry in the RFC 8552 registry.

• Added baseline retry policy for missing UPDATE responses, plus minor structural and editorial polish.

draft-ietf-dnsop-delegation-mgmt-via-ddns-01

• Large number of editorial nits addressed (thanks to Yorgos Thessalonikefs)

• Replaced the hand-waving "Mutual Authentication" section with a concrete specification for where the UPDATE Receiver publishes its SIG(0) public key and how the child validates it (DNSSEC validation or manual bootstrap). Moved "Communication Between Child and Parent UPDATE Receiver" and "Mutual Authentication" to directly after the child key bootstrap sections, so that the motivation (KeyState communication) directly precedes the solution (mutual authentication via the parent's SIG(0) key). Removed the policy inquiry references that were made obsolete by the SVCB "bootstrap" SvcParamKey mechanism. Moved Terminology to the Introduction and added definitions for UPDATE Receiver and Bootstrap. Expanded the abstract to describe the proposed mechanism.

draft-ietf-dnsop-delegation-mgmt-via-ddns-00

• Re-submitted as a WG document after adoption.

draft-johani-dnsop-delegation-mgmt-via-ddns-06

• Added the more secure bootstrap of the SIG(0) public key based on RFC9615 in addition to the original mechanism based on RFC8078.

• Replaced references to the draft on generalized notifications with a reference to RFC9859.

draft-johani-dnsop-delegation-mgmt-via-ddns-05

• Fixed typos in the KeyState OPT section.

• Added a section on mutual authentication.

• Fixed spelling errors.

draft-johani-dnsop-delegation-mgmt-via-ddns-04

• Reworked the section on automatic bootstrapping a la RFC8078.

• Added a section on re-bootstrapping the SIG(0) key with the parent after problems.

• Added text on the importance of augmenting error responses using EDE (RFC8914).

• Added text on the insufficiency of RFC8914 for child-to-parent communication and a reference to the (upcoming) draft on a new OPT code to alleviate this.

draft-johani-dnsop-delegation-mgmt-via-ddns-03

• Update the draft based on the excellent dnsdir review of draft-ietf-dnsop-generalized-notify-01 by Patrick Mevsek.

• Expand the section on alternatives for initial bootstrap to suggest a mechanism similar to what is used for automatic bootstrap of DNSSEC signed delegations via multiple queries for child the CDS RRset.

• Added a section on scalability considerations.

• Expanded the Security Considerations section with a paragraph on the potential for DDOS attacks aimed at the UPDATE Receiver.

draft-johani-dnsop-delegation-mgmt-via-ddns-02

• Update the references to the (updated) I-D for generalized notifications.

• Remove duplicated descriptions between the two drafts. It is sufficient that the generalized notification draft describes the mechanics.

draft-johani-dnsop-delegation-mgmt-via-ddns-01

• Change the RRtype from the original "NOTIFY" to the proposed "DSYNC"

• Expand the description of how to interpret different RCODE responses to the UPDATE. Expand the description of bootstrapping alternatives. Change the mnemonic of the RR type used from "NOTIFY" to "DSYNC" in the examples.

draft-johani-dnsop-delegation-mgmt-via-ddns-00

• Initial public draft.