Markdown Version | Recording 1 | Recording 2
Session Date/Time: 18 Mar 2024 05:30
dnsop
Summary
The DNSOP working group session at IETF 119 covered updates on various drafts, including 8109 bis (priming root queries), trust anchor publication for the root zone, compact denial of existence, NSP validation, and a new draft on DNS greasing. Hackathon results were presented, and discussions were held regarding adoption of new drafts and addressing open issues.
Key Discussion Points
- 8109 bis (Priming Root Queries): Discussion arose concerning the current status of root zone operations and whether the document adequately addresses the special nature of the root zone operators.
- Trust Anchor Publication: Concerns were raised regarding the reliance on transport security (TLS) instead of data origin authenticity when publishing the root zone trust anchor. The removal of certificates and certificate signing mechanisms was also discussed.
- Compact Denial of Existence: The group discussed the treatment of explicit queries for Nx name, updates to RFCs 64034 and 4035, and the allocation of a meta type for Nx name.
- NSP Validation: Discussion covered the trustworthiness of infrastructure RRs and revalidation's role in reducing cache poisoning and query redirection risks.
- DNS Greasing: A new draft on DNS greasing was presented, discussing the use of unallocated protocol code points to prevent ossification. Points covered the protocol elements to grease, selection strategies, frequency, failure detection, and data collection.
- Generalized Notify Updates: Updates on the draft related to DNS notifications and automation of delegation management. A key aspect discussed was the mechanism for discovering the notification target.
- Hackathon Results: Presentations covered compact denial of existence implementation, discussions around Dileg, and automatic child-to-parent synchronization of delegation information.
Decisions and Action Items
- 8109 bis (Priming Root Queries): Mark Andrews to send proposed wording changes to the mailing list. The working group will review and provide feedback.
- Trust Anchor Publication: The authors will consider adding an IANA consideration section detailing required actions and make explicit that gossip is currently the fallback. The authors will also consider pre-announcing future trust anchors in the DNS.
- DNS Greasing: This draft has been queued up for more discussions.
- Generalized Notify Updates: The draft will be updated based on feedback received, including addressing concerns regarding DNSSEC and unsigned records.
- DNIS greased: People asked for more information for the DNIS greased document, and will provide the info on the mailing list.
- All drafts: Tim and Suzanne to update email list for the drafts.
Next Steps
- The chairs will initiate a thread on the mailing list to gather reviews on the DINS greased document.
- Authors of various drafts will address open issues and feedback received during the session.
- The working group will continue discussions on the mailing list to move drafts closer to working group last call.
Session Date/Time: 22 Mar 2024 05:00
# dnsop
## Summary
This DNSOP session covered several topics, including a report on the DNS delegation BAF, updates on crypto-algorithm registry management for DNSSEC, ranking DNS data sources, automated delegation synchronization, and measurement of CDS/CDNSKEY inconsistencies. The primary focus was on discussing and gathering feedback on proposed drafts for adoption.
## Key Discussion Points
* **DNS Delegation (DD) BAF Report:** The BAF explored updating the DNS delegation mechanism. A new mailing list, [email protected], is dedicated to this topic. The aim is to develop a charter for a working group, focusing on problem identification before evaluating solutions. The IAB will decide on forming a working group.
* **Crypto-Algorithm Registry Management:** Three drafts were presented regarding crypto-algorithm management for DNSSEC:
* A draft to move recommendations into the IANA table.
* A draft stating "Must Not Use SHA1"
* A draft stating "Must Not GOS" - more specifically the ECE GOS.
* The approach is to use smaller RFC updates for incremental changes.
* Discussion revolved around requiring standard action for all changes except adding an algorithm with a "May" recommendation.
* The potential addition of a column for deployment level was suggested.
* **Ranking DNS Data Sources:** Discussion on re-evaluating and potentially overhauling RFC 2181, section 5.4.1, concerning the ranking of DNS data. Emphasis was placed on the need to acknowledge diverse operational contexts and policies, instead of aiming for a rigid linear ranking.
* **Automated Delegation Synchronization:** A discussion on automating delegation synchronization between child and parent zones, even in non-DNSSEC environments, by bootstrapping trust of the child key using various mechanisms like multi-vantage point validation or requiring operator confirmation. A potential downside is the possibility of a persistent hijack mechanism.
* **CDS/CDNSKEY Inconsistencies:** A study on the frequency of inconsistencies in CDS and CDNSKEY records across authoritative name servers. Results show that roughly 0.1% of zones with these records have inconsistencies. The study highlighted specific cases, including issues with .ch and .com, and multi-provider setups (e.g., Google Domains and Wix DNS).
## Decisions and Action Items
* **Adoption of Crypto-Algorithm Registry Drafts:**
* Decision: Working group to consider adoption of the draft updating the tables, along with consideration of merging Peter and Schumann's comments regarding the addition of a deployment level column.
* Action: Address concerns raised regarding the lack of a security explanation in the "Must Not Use SHA1" draft. Provide the reasoning for deprecation.
* Action: Call for working group adoption will occur for the first draft, as well as the "Must Not GOS" draft.
* **Ranking DNS Data Sources Draft:**
* Decision: The working group will plan on calling for adoption of the draft.
* Action: The document should be taken to the mailing list to collect further comments and discussion.
* **Automated Delegation Synchronization Draft:**
* Action: Yohan to continue discussion on the mailing list to refine bootstrapping mechanisms and address security concerns.
## Next Steps
* Charter for the DD working group will continue to be discussed on the dedicated mailing list. The mailing list will remain open for discussion.
* Address open issues and comments raised during the DNSOP session on the mailing lists, particularly regarding the ranking of DNS data and automated delegation synchronization.
* Prepare for working group adoption calls for the crypto-algorithm registry drafts (after addressing the concerns about the "Must Not Use SHA1" draft) and the ranking of DNS data draft.
* The discussion of automated delegation synchronization should continue to be thrashed out on the mailing list.