DNSOP Working Group Meeting

Summary

The DNSOP Working Group meeting addressed the status of several key drafts, including new RFC publications and documents in various stages of the IETF publication process. Significant discussions revolved around mandating IPv6 for DNS operations, improving Domain Control Validation mechanisms, formalizing the lifecycle of DNS cryptographic algorithms, and exploring hyper-local DNS deployments. The session concluded with a general call for working group members to review drafts and continue technical discussions on the mailing list, with specific follow-ups on forming small focus groups for certain drafts.

Key Discussion Points

Working Group Updates and Document Status

RFCs Published: Two RFCs, "Compact Denial of Assistance" and "Generalized DNS Notifications," were published in September.
RFC Editor Queue: Several documents are in the RFC Editor queue.
IESG Review: The "CDS Consistency" document has been submitted to the IESG after a Working Group Last Call (WGLC).
Active Working Group Last Calls (WGLC):
- "DANE for S/MIME" (draft-ietf-dane-smime): Second WGLC initiated for two weeks following substantial feedback and a revision.
- "Domain Verification Techniques" (draft-ietf-dnsop-dcv): Expected to be ready for WGLC after its presentation.
- "DNSSEC Automation" (draft-ietf-dnsop-dnssec-automation): Planned for WGLC but requires some edits.
- "Genus of Greece" (draft-ietf-dnsop-genus-of-greece): On the agenda for discussion.
Documents Awaiting Updates: Several drafts are pending new revisions or presentations to progress.
Obstructed DNS Error (draft-ietf-dnsop-obstructed-dns-error): Chairs plan to coordinate an interim meeting in December/January to find a way forward, noting ongoing implementation efforts.

Hackathon Update

Projects included Deleg implementation, DNS transport signaling, libUV/QUIC support in OpenSSL for ICBind DNS server, DNS resolver cache sharing (poison-licious) for Bind, post-quantum cryptography for DNSSEC, MTL mode for ML signature algorithm, Dry Run DNSSEC, and DNS over Co-AP.

Liaison/Dispatch Section (Friday)

Three drafts from the ISE track will be presented on Friday to determine if they fall within DNSOP's scope.

Draft: "to R3901 abyss" (Mandating IPv6 for DNS Operations)

Problem: RFC 3901 (2004) allows IPv4-only for recursive resolvers and implicitly makes IPv6 optional for authoritative name servers. This leads to DNS fragmentation (up to 40% of zones are IPv4-only), preventing IPv6-only resolvers from reaching them. This contradicts RFC 6540 (2012), which states IPv6 support is no longer optional for IP nodes.
Proposal: Update RFC 3901 to mandate IPv6 for DNS, reflecting current widespread IPv6 deployment and improving DNS policy. Research suggests IPv6 DNS is ready, with most problems stemming from misconfigurations.
Updates: Incorporated fragmentation avoidance advice (RFC 9715), updated wording on IPv4/IPv6 translation, added more RFC references.
Discussion:
- Strong support for mandating IPv6, citing dropping IPv4 quality and the need for an RFC to encourage IPv6 adoption for authoritative DNS.
- Editorial Feedback: Suggested clarifying terms like "mapped addresses" (vs. synthesized) and adding references for Pref6 prefix selection.
- Security Considerations: Need to expand on security, especially regarding synthesized addresses and layer 2 security to prevent rogue arrays.
- Stub Resolver Prioritization: Debate on changing "should" to "may" for IPv6 prioritization (stub-to-recursive), with arguments that IPv4 is becoming "worse" and preferring IPv6 is desirable for persistent sessions and to avoid expensive keep-alives.
Decision: Chairs will initiate a Working Group Last Call (WGLC) after authors incorporate feedback, particularly on security and editorial points.

Draft: "Domain Control Validation (DCV)"

Updates (v-10): Merged concepts of "unique tokens" (random tokens being an example), improved DNSSEC validation language, added a privacy consideration section, and began language cleanup.
Open Issues:
- Threat Model: Need a clearer threat model. Proposal to remove the 128-bit requirement for random tokens and encourage applications to select sizes based on their threat model.
  - Discussion: Strong consensus that a formal threat model is essential. Speakers argued that the typical threat model is simple (seeing a token), requiring only enough bits to prevent accidental collision, while certificate signing may require higher security. Documenting trade-offs between token sizes was suggested over prescriptive musts. A formal threat model is seen as crucial for utility and avoiding "looking silly."
- Multi-Account Section: Reintroducing a trimmed version to support multiple intermediaries/accounts (e.g., two ACME validations in parallel).
  - Discussion: Supported, as it's actively used in the field by ACME and other cloud-provider applications.
Decision: Chairs requested authors to include a comprehensive threat model and address minor comments for the next version. Once updated, it will be considered for WGLC.

Draft: "DNS Integration in Application Environments"

Goals: Minimize conflicts between global DNS and applications, provide consistent user experience (unique identifiers), and extend DNS security/stability/resiliency.
Updates (00 to 01): Refined goals in abstract/introduction, narrowed intended audience to "applications providing DNS integrations," consolidated the "motivation" section, and made minor updates to existing considerations.
Current Considerations: Eight considerations (e.g., domain name lifecycle, stability, security, privacy) are outlined, with high-level challenges for applications not accounting for them.
Next Steps: Authors seek feedback on existing/new considerations and input on whether to adopt more normative/opinionated language (changing it from informational to potentially standards-track).
Discussion: Strong support for the document's necessity, with a call for the working group to thoroughly read and review it, given its adoption.
Decision: Working group members are urged to review the document and provide feedback on the mailing list.

Draft: "Operational Accommodations for DS Automation"

Updates:
- Human notifications: Removed email suggestion; now states notifications should occur "according to established preferences" with the contract party.
- CDS/CDNSKEY checking: Removed recommendation for parents to check both records.
- DS configuration inspection: Domain owners "should" be able to inspect current DS configuration via a portal; update history is now "MAY" (due to registry concerns).
- DS automation disablement: Clarified that this should only happen if the DS record set was manually removed.
Open Questions:
- Registry DS Automation without Registrar Interface: Should registries perform DS automation if the registrar doesn't offer a DS removal interface?
  - Discussion: Mixed opinions. Some argue registries should enable it (registrants can contact registry), others emphasize the complexity of registrar/registry communication and prefer an opt-in approach where registrars explicitly signal to registries.
- Rescheduling DS Validation Checks: Should the processing party (parent) reschedule acceptance checks later (e.g., after a week/month)?
  - Discussion: General sentiment leans against this being the parent's responsibility if issues arise at the child's side later.
- Appendix C: Authors propose removing an appendix containing old ideas not reaching consensus unless there is feedback to keep it.
Decision: Discussion to continue on the mailing list.

Draft: "Updating BCP 237 (DNSSEC Definition)"

Purpose: BCP 237 (RFC 8624) defines DNSSEC by listing core and related RFCs. This draft aims to update it, reflecting new RFCs, obsoleted documents, and especially the soon-to-be-published cryptographic algorithm recommendations (which are seen as highly actionable for implementers).
Discussion:
- Desire for Updates: General agreement that updating the list of relevant RFCs is useful, particularly for external readers.
- Cadence: Question about how often to update. Suggestions ranged from a fixed cadence (e.g., every two years) to updating around major milestones (e.g., DELIC deployment).
- Mechanism: Debate whether an RFC is the best mechanism (vs. a web page, IANA registry). RFCs provide findability and a historical snapshot, but frequent updates could be a burden. Other IETF protocols (IPSEC, SIP) rarely updated similar guides.
- Working Group Time: Concerns were raised about consuming WG time for repeated revisions, though the current draft is seen as relatively light review-wise.
Decision: Working group adoption is being considered. Further discussion on adoption and update cadence will happen on the mailing list.

Draft: "Lifecycle of DNS Cryptographic Algorithms"

Motivation: Red Hat's removal of an older algorithm caused problems due to lack of clear, community-wide advice on sequencing the phasing in and phasing out of cryptographic algorithms.
Proposal: Defines a 7-phase lifecycle for DNS signing algorithms (Introduce, Mainstream, Phase Out, Deprecate, Remove) with criteria and transitions. Suggests an IETF-managed registry with expert consensus. Timeframes are measured in years/decades.
Discussion:
- Scope: Questioned if this should be specific to DNSSEC or a broader security area/CFRG concern.
- DNS Specificity: Arguments for DNS being special: no negotiation with resolvers, data is "at rest" (signed once, validated elsewhere), and expertise required is more about ecosystem knowledge than pure crypto research.
- Announcement Mechanism: Clarification sought on whether IETF "official announcements" occur via RFCs, IANA registry, or other means.
Decision: Discussion to continue on the mailing list. Chairs will follow up on potential call for adoption, considering the scope and suitable venue.

Draft: "Hyper-local DNS"

Motivation: Update/replace informational RFC 8806 to encourage wider adoption of hyper-local root zone copies (local resolvers holding a copy of the root zone). Benefits include faster resolution, improved robustness, enhanced privacy, and reduced load on root servers.
Proposal: Seek Working Group adoption to elevate the document to a BCP (Best Common Practice) or Standards Track RFC to provide stronger incentive for implementation.
Gaps: Requires infrastructure for zone transfer (e.g., HTTP), content verification (ZoneMD), potential IANA/PTI oversight, and significant education/outreach.
Discussion:
- Architectural Change: Strong opposition to making it a BCP/Standards Track document, arguing it represents a fundamental architectural change to the DNS, which falls under IAB's purview, not DNSOP.
- Root Server Load: A root server operator clarified that current root server load isn't an issue; capacity exists for DDoS protection. The argument for DDoS defense-in-depth via hyper-local copies was noted but seen as orthogonal to routine load.
- Evolution of Root Zone: Concerns that widespread deployment could hinder future root zone evolution (e.g., adding new record types), as illustrated by issues with ZoneMD deployment in 2023.
- Implementer Advice: Need for more advice on monitoring and precautions against stale data.
- Venue: Suggestion to consider DNS-OARC or other operational groups, as this WG is "DNS operations" in name but doesn't focus on such operational guidance.
Decision: Discussion to continue on the mailing list, given the differing opinions.

Drafts by Johan Stenstam: Dsync for Scanner/Notify Schemes & Dynamic Updates

Draft 1: "DNSSEC Automation Signal for Scanners"
- Purpose: Announce the existence and details of CDS/CDNSKEY scanners using the D-Sync record (_dns-scanner scheme) with additional info in an SVCB record (e.g., frequency, supported bootstrap mechanisms). Aims to set expectations for child operators.
- Updates: Moved scanner details into an SVCB record (was overloading D-Sync semantics). Added a mechanism for announcing support for multiple bootstrap methods.
Draft 2: "Delegation Synchronization via Dynamic Updates"
- Purpose: Revive and standardize the use of dynamic updates for automatic delegation synchronization from child to parent, leveraging the D-Sync record to specify the update target.
- Bootstrapping: Describes scalable mechanisms for automatically bootstrapping the child's sig0 key in the parent, using either an 8078-like multiple vantage point approach or a 9615-like DNSSEC validation method.
- Updates: Aligned signaling of supported bootstrap mechanisms with the scanner/notify drafts, using SVCB records. Simplified EDNS-0 option communication by moving information to DNS records.
Discussion:
- Interest: A small number of attendees indicated interest in these drafts. The author highlighted that over 90% of children zones are unsigned, implying a large potential demand for such automation mechanisms.
- Sig0 Bootstrapping: Questioned the authentication mechanism for sig0 keys (is it similar to DANE?). Author clarified it leverages DNSSEC validation for the public key.
- Scalability: Concern raised about the scalability of a mechanism where all resolvers get zone updates if it becomes default.
Decision: Chairs will consider organizing a small focus group to continue work on these drafts, alongside ongoing mailing list discussion.

Draft: "DNS Transport Signaling (Opportunistic)"

Motivation: Provide explicit signals for alternative DNS transports (DoT, DoQ) beyond blind probing (RFC 9539), to allow for better distinction between test and production deployments, and signed validation.
Proposal:
- Opportunistic Mode: Use SVCB records in additional section of authoritative responses, providing an unvalidated signal.
- Validated Mode: Evolve towards an explicit query for an SVCB record, DNSSEC-signed, enabling expression of more complex (and potentially "dangerous") signals.
- Example Signals: -DO53 to signal turning off UDP/TCP transport (useful for traffic separation, maintenance windows for unicast servers).
Discussion:
- Support: Seen as a good, short-term option that doesn't conflict with DELIC. Cloudflare expressed interest in implementation.
- Opposition/Concerns:
  - Inefficiency: Increased packet size if SVCB records are always in the additional section.
  - Integration: Difficult to integrate into the core delegation and resolution process compared to authenticated signals like DELIC.
  - Additional Section Abuse: Historical concerns about "additional section" abuse in DNS. Preference for following the "regular, authenticated path."
  - Motivation for Implementation: One implementer found it hard to justify implementing this alongside ongoing DELIC work, given the complexity on the resolver side.
Decision: Discussion to continue on the mailing list.

Decisions and Action Items

to R3901 abyss (IPv6 Mandate for DNS): Chairs to initiate a Working Group Last Call (WGLC) after authors incorporate feedback.
Domain Control Validation (DCV): Authors to include a comprehensive threat model and address minor comments for the next version, then aim for WGLC.
DNS Integration in Application Environments: Working group members are explicitly requested to review the document and provide feedback on the mailing list.
Operational Accommodations for DS Automation: Continue discussion on the mailing list, particularly on the question of registry DS automation without registrar interfaces.
Updating BCP 237 (DNSSEC Definition): Working group adoption request is pending. Follow up on the mailing list regarding adoption and update cadence.
Lifecycle of DNS Cryptographic Algorithms: Continue discussion on the mailing list. Chairs will follow up on the potential for a call for adoption and appropriate venue.
Hyper-local DNS: Discussion to continue on the mailing list, addressing the strong concerns raised about architectural changes.
Dsync for Scanner/Notify Schemes & Dynamic Updates: Chairs will consider organizing a small focus group for these drafts, alongside continued mailing list discussion.
DNS Transport Signaling (Opportunistic): Continue discussion on the mailing list.

Next Steps

Ops Area Session: Attendees are encouraged to participate in the "DNS at IETF" session in the Ops area on Thursday (third session of the day) for broader DNS discussions.
Mailing List Engagement: All participants are requested to actively review drafts and provide technical feedback on the DNSOP mailing list to ensure progress and build consensus.

Session Date/Time: 07 Nov 2025 16:30

DNSOP

Summary

The DNSOP session covered a range of topics, including proposed mechanisms for indicating zone cuts, extensions for delegation record types, updates to DNSSEC algorithm rules, improvements for private DNSSEC, strategies for DNSSEC disaster recovery, and the publication of domain "for sale" indicators. Discussions highlighted the technical merits and potential operational impacts of each proposal, often leading to recommendations for further mailing list engagement or re-evaluation of scope within the IETF or other streams. A significant meta-discussion also took place regarding the future home and organization of Post-Quantum DNSSEC work within the IETF. The chairs indicated upcoming changes to how presentations and drafts are accepted, with details to be announced on the mailing list.

Key Discussion Points

Delegation to the Empty Label (draft-andrews-dnsop-delegation-to-empty-label)
- Problem: How to indicate a zone cut (e.g., for dot internal) without specifying a server, avoiding ambiguity when a name exists internally but not globally.
- Proposal: Use an NSR set with the empty label (.) as the target in an NS record. This signals a zone cut exists but no server is globally available.
- DNSSEC Integration: Allows publishing DS records for internal zones, enabling DNSSEC validation without distributing trust anchors.
- Precedent: Similar use of . in SRV, MX, SVCB, MNAME, and RNAME records.
- Impact: No protocol changes required, but DNS parser/syntax checkers might need updates.
- Testing: Preliminary experiments show no immediate damage; further testing planned to observe resolver behavior.
- Clarification: This mechanism is intended for any zone to publish an entry point for an internal zone, not specifically for a global dot internal in the root.
- Concerns (Mark Andrews): Recursive servers, especially in chains, could repeatedly attempt resolution, leading to SERVFAIL. This was argued to be "bad protocol design" and that existing insecure delegation methods are superior.
- Action: Discussion to continue on the mailing list, specifically requesting testing with multi-layer forwarders.
DNS Protocol Modifications for Delegation Extensions (draft-arenz-dnsop-delegation-extensions)
- Motivation: To allow a range of RR types to exist at a delegation point, not just the single type currently being developed for DELIC. The IESG INT area director recommended bringing this to DNSOP.
- Proposal: Allocate a range of types for future extensions at delegation points, using the same mechanism as DELIC.
- Support: Strong support from several individuals, including Ray Bellis and Shumon, for reserving ranges and considering updates to RFC6895 (IANA Considerations for DNS).
- Non-Impediment: The author emphasized that this is not an alternative to the DELIC draft and intends to avoid delaying DELIC's progress.
- Clarification (Paul Hoffman): Noted that while DELIC might get a range, DELIG (Delegation Insecure) would still need a separate, distinct record.
- Action: Chairs indicated strong support for early adoption and fast-tracking this work, encouraging continued discussion on the mailing list regarding its relationship with RFC6895.
Multiple Algorithm Rules in DNSSEC (draft-wessels-dnsop-multi-algo-dnssec)
- Problem: Current DNSSEC requirements for signers (use all algorithms) and validators (use any valid path) create operational complexities during algorithm transitions or with multi-signer setups.
- Key Proposal: If a zone advertises only universal algorithms, signing with one is sufficient. If it uses formerly universal or no universal algorithms, it must sign with all. This is intended to ease transitions while preserving downgrade attack protection.
- Validator Behavior: Proposed that if a mainstream algorithm is locally disabled (e.g., by OS policy), validators should treat validation paths using that algorithm as insecure, not bogus.
- Related Work: Discussion about synchronizing with Steve Crocker's DNSSEC Algorithm Lifecycle draft.
- Arguments for (Shumon, Victor, Peter Thomassen): The use cases for multi-signers and graceful handling of algorithm deprecation (e.g., Red Hat issue) are valid. This draft addresses catastrophic failure modes when lifecycle transitions fail, which the lifecycle draft does not cover. It does not add protocol complexity, rather it clarifies operational best practices and implementation behavior.
- Arguments Against (Mark Andrews): Attributed issues (like Red Hat's) to operator error, not protocol design flaws. Warned against managing DNS algorithms in this way, predicting long-term operational problems.
- Action: Discussion to continue on the mailing list, with a specific request for Mark Andrews to document previous concerns regarding forwarder situations.
Private DNSSEC and Private OID (draft-andrews-dnsop-private-alg-ds)
- Problem: DS records for private DNSSEC algorithms (Private DNS, Private OID) are ambiguous because the algorithm number alone doesn't uniquely identify the algorithm, unlike standard algorithm types. This creates issues, especially with pre-publishing DS records or determining if a supported algorithm is actually in use.
- Proposal: Introduce new DS hash algorithm types that include the specific private algorithm identifier at the beginning of the hash, similar to DNSKEY and RRSIG.
- Support (Chair): Views this as fixing a bug in the original implementation, potentially useful, but needs thorough testing (BQC).
- Alternative (Philip): Suggested that resolvers could fetch the DNSKEY RRset to match public keys and determine the exact algorithm, then treat unmatched DS records as not present.
- Response (Mark Andrews): Acknowledged that fetching DNSKEY works in some cases but not for pre-publishing and can impact downgrade resistance.
- Action: Discussion to continue on the mailing list to resolve these technical details.
Disaster Recovery for DNSSEC (draft-courage-dnsop-disaster-recovery-dnssec)
- Problem: The necessity of keeping private keys confidential (e.g., with HSMs) often prevents backups, which is problematic for disaster recovery. Secret sharing schemes are operationally complex and can fail.
- Proposal: Outlines a key rollover process for disaster recovery when a private key is inoperable, leveraging RFC7543. A critical step is that the signer must not remove old RRSIGs during the transition.
- Status: Internal disaster recovery exercises are planned, and early feedback from implementers is positive.
- Support (Stephen Ebbing, Peter Thomassen): The draft provides a useful, protocol-compliant "how-to" guide for a specific operational challenge without adding protocol complexity, requiring only minor software changes.
- Concerns (Johan, Jim Reid): Questioned the necessity, suggesting HSMs should support backups. Expressed confusion about the RFC7543 reference, finding the approach overly complex for a niche policy regime. Suggested it might be better suited as a BCP or for IESG ARC review rather than a formal RFC.
- Action: Discussion to continue on the mailing list.
Putting a "For Sale" Sign on a Domain Name (draft-davids-for-sale-sign-for-domains)
- Problem: No standardized way to indicate that a registered domain name is available for sale or lease.
- Proposal: Use a TXT record under a special underscore label (_for-sale.<domain_name>) containing structured data (e.g., asking price, contact email, landing page URL).
- Use Case: SIDN (.nl registry) has implemented this in production since 2022 to connect buyers and sellers, without commercial involvement from the registry.
- Technical Status: Draft is mature, with a working demo. DNS Director review found it technically sound, requiring no DNS protocol or software changes.
- IETF Stream Discussion:
  - Chair: Recommended keeping it in the Independent Submission stream, as it's more about registrar/ICANN community consensus than IETF protocol consensus. DNSOP has too much work.
  - Support for RFC (John, Tobias): Agreed it was technically fine for ISE. An RFC (even an ISE one) would provide significant credibility for broader adoption by registrars and domain parkers.
  - Eliot Lear (Independent Submissions Editor): Confirmed that ISE would seek expert review, welcoming input from DNS experts. Emphasized that the IETF as a whole decides where rough consensus helps.
- Action: The consensus was for the draft to remain in the Independent Submission stream but to be published as an RFC for credibility among its target community.
Method to Identify Administrative Boundary of IDN Names (draft-kangyang-dnsop-idns-administrative-boundary)
- Problem: Applications struggle to recognize variant IDN names (e.g., simplified and traditional Chinese characters for the same entity) as belonging to the same administrative boundary, despite human recognition.
- History: Previous efforts in the IDN working group and a 2023 BoF failed to gain traction or form a working group.
- Proposal: Use DS records to link variant domain names to a common "anchor" or "intermediary" name, thus signaling a shared administrative boundary to applications.
- IETF Stream Discussion:
  - Chair: Noted that new R-types are not inherently "expensive" but require expert review. Raised concerns that the idea had been previously rejected by IETF and questioned whether it was truly a DNS problem or an application problem. Emphasized the need for application-side support and security implications if domains change ownership.
  - Concerns (Tobias, Victor, John): Agreed that DNS's tree-shaped nature is intended to cover such cases. Viewed the problem as social rather than technical. Noted that solutions for TLD variants already exist (e.g., via DS records). Cited a decade of lack of application interest in auto-configuring for variant names, suggesting it's not a problem the community considers worth solving.
- Action: No support for this work in DNSOP. The presenter was encouraged to seek support from the application community.
Post-Quantum DNSSEC Strategy (draft-sury-dnsop-pq-dnssec-strategy)
- Problem: Post-Quantum (PQ) cryptography poses significant risks to DNSSEC. New PQ algorithms often have characteristics (e.g., larger key/signature sizes) that are not a perfect fit for existing DNSSEC mechanisms, requiring new strategies and protocol changes.
- Collaboration: Highlighted extensive community collaboration (PQDNSSEC mailing list, hackathons, NIST, academic, operator communities) to research, implement, and evaluate PQ algorithms for DNSSEC.
- Strategy Draft: The first version focuses on crypto agility and security, proposing two classes of algorithms (resilient fallback, routine performance) and techniques like MTL mode to mitigate impact.
- Meta-Discussion: The core question was where this extensive PQDNSSEC work should be standardized within the IETF (e.g., DNSOP, a new group like DNSEXT, or a combination). Noted CFRG's disinterest in Merkel tree constructs and the need for cryptographic expertise.
- Recommendations (Paul Hoffman, Florian, Andre): Praised the draft for defining the scope of work. Suggested that the work is significant enough to warrant a dedicated working group or focus group, possibly involving cryptographers and DNS experts, as it might be too broad or specialized for DNSOP alone. Paul Hoffman advised clarifying that "migration" in the draft refers to standards evolution, not deployment guidance.
- Action: This was a high-level discussion to inform the broader IETF on how to organize the significant upcoming PQDNSSEC work (likely via the DNS@IETF initiative). No specific DNSOP adoption decision was made.

Decisions and Action Items

Delegation to the Empty Label: Discussion to continue on the mailing list, focusing on Mark Andrews' concerns about recursive server behavior and testing with multi-layer forwarders.
DNS Protocol Modifications for Delegation Extensions: Chairs indicated strong support for early adoption and fast-tracking the document. Authors encouraged to continue discussions on the mailing list regarding potential updates to RFC6895.
Multiple Algorithm Rules in DNSSEC: Discussion to continue on the mailing list. Mark Andrews was asked to document his previous concerns regarding forwarder situations.
Private DNSSEC and Private OID: Discussion to continue on the mailing list to hash out technical details and address concerns about downgrade resistance and pre-publishing.
Disaster Recovery for DNSSEC: Discussion to continue on the mailing list to address the utility and scope of the document, including whether it's best suited as a BCP or RFC.
Putting a "For Sale" Sign on a Domain Name: Consensus was to proceed via the Independent Submission stream, aiming for publication as an RFC to lend credibility for broader adoption by registrars and the domain industry. DNSOP will not take on this work.
Method to Identify Administrative Boundary of IDN Names: No support for this work within DNSOP. The author was encouraged to seek support from the application community.
Post-Quantum DNSSEC Strategy: This was a discussion to gather input for the broader IETF community (likely DNS@IETF) on how to organize and progress the significant PQDNSSEC work. No immediate DNSOP adoption decision.

Next Steps

Chairs plan to announce changes to how presentations and drafts are accepted, with an open discussion on the mailing list before the next in-person IETF meeting.
Mailing list discussions are expected to continue for several drafts as indicated in the "Decisions and Action Items" section.