mir/dnsop-wg-materials
2
0
Fork 0
mirror of https://github.com/ietf-wg-dnsop/wg-materials synced 2025-08-22 02:09:16 +00:00
Code Issues Releases Wiki Activity

updated

Browse Source
This commit is contained in:
Tim Wicinski 2025-03-16 22:56:31 -04:00
parent 26da27570a
commit 71642ef7b1
1 changed files with 23 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
interim-2025-dnsop-01/dnsop-interim-2025-01-minutes.md
View File

@ -1,66 +1,38 @@
## **interim-2025-dnsop-01 minutes**
## **dnsop-interim-2025-01-minutes**
The interim meeting focused on the concept of a Distributed Multi-Signer architecture for a DNSSEC zone signing pipeline. The discussion centered around a set of new drafts presented to the DNSOP Working Group. These drafts aim to address currently missing components needed to fully implement such an architecture.
[Chat Log](https://datatracker.ietf.org/meeting/interim-2025-dnsop-01/materials/chatlog-interim-2025-dnsop-01-202502171600-00)
### Drafts
* draft-ietf-dnsop-generalized-notify (IETF LastCall)
* draft-berra-dnsop-keystate
* draft-johani-dnsop-delegation-mgmt-via-ddns
* draft-leon-distributed-multi-signer
Presenters:
Johan Stenstam, Erik Bergstrom, and Leon Fernandez introduced the following drafts:
* draft-ietf-dnsop-generalized-notify (in IETF LastCall)
* draft-berra-dnsop-keystate
* draft-johani-dnsop-delegation-mgmt-via-ddns
* draft-leon-distributed-multi-signer
* draft-johani-tld-zone-pipeline
[Slides](https://datatracker.ietf.org/doc/slides-interim-2025-dnsop-01-sessa-towards-distributed-multi-signer/)
The slides from the presentations are available on Datatracker:
https://datatracker.ietf.org/doc/slides-interim-2025-dnsop-01-sessa-towards-distributed-multi-signer/
*Chairs suggest walking through the presentation*
Following the presentations, the session was opened for questions and discussions.
Presentation Summary:
Ed raised a point about terminology, suggesting that "Sign/No Sign" would be a more intuitive and mnemonic way to represent the concept rather than "Yes/No." There was general agreement that this terminology would work well. It was also noted that in the protocol, this is simply a uint8 (an octet), meaning that different tokens could be used to represent various values as needed.
### **Coordination & Automation Challenges**
Stephane brought up a point regarding RFC 8483 and the idea of coordinating through human means. Johan acknowledged that such coordination does happen within organisations and is a well-known practice. An example was given of New Zealand, which has been running a multi-tier configuration manually and in-house for many years. While it is possible to manage coordination manually across organisational boundaries, the concern was raised that doing so is complex and challenging.
* New Zealand runs an in-house multi-tier DNS that has been manually managed.
* Automating secure communication between MSAs is a priority before defining synchronization protocols.
The discussion covered multi-signer configurations, highlighting different use cases, including simultaneous multi-signer setups and transitioning from one signer to another. The hsync RR set was designed to support both multi-signer and single-signer contexts, allowing gradual changes to reduce operational risk.
### **Protocols & Synchronization Issues**
A key point was that while MSAs (Message Signing Authorities) can securely communicate, the details of how they synchronise DNS key information are still being developed. Future work may explore a model where a single provider distributes zones to others, ensuring consistency. However, zone transfer specifics are intentionally left out due to security concerns.
* **HSYNC RR Set**: Designed to facilitate smooth transitions in signing states.
* Addressed concerns about ensuring identical configurations across multiple providers.
* Debate over whether the SOA record needs full synchronization or just selective fields (e.g., technical contact email).
The need for SOA record synchronisation was debated, with agreement that while serial numbers may not need alignment, fields like the technical contact email should remain consistent. The discussion concluded with an acknowledgment that more work is needed to define which apex data elements require synchronization in multi-signer setups.
### **Security Considerations**
Steve raised the SOA question, noting that it arises due to multiple sources of change or truth in multi-signer setups. He suggested that the SOA primarily reflects the contents of the zone, while other elements—such as the number of providers, the set of name servers, and the set of keys—can change independently. While acknowledging that some might want an SOA equivalent for these components, he questioned whether it was necessary.
* Discussed secure zone transfers, emphasizing the need for **TLS, VPNs, or other secure methods** to prevent attacks.
* Agreed that **exposing zone transfer details is a security risk**, so they should remain confidential.
Suzanne then summarised and closed the session, emphasising that the meeting was held to discuss the integrated architecture that spans multiple drafts. While the generalized-notify draft is progressing through the pipeline, other related drafts together define the broader architecture. The discussion provided valuable insights, though no concrete conclusions were drawn yet. Participants were encouraged to continue discussions on the mailing list.
### **Future Work & Next Steps**
Zulip chat log: https://datatracker.ietf.org/meeting/interim-2025-dnsop-01/materials/chatlog-interim-2025-dnsop-01-202502171600-00
* Further discussions needed on **how MSAs synchronize data** and establish **secure communication**.
* Encouragement to review drafts and contribute to ongoing discussions.
Ed Lewis: "SIGN/NOSIGN" would be more mnemonic than "YES/NO" in the RDATA field
Johan: agreed
Kazunori Fujiwara: The model seems to be similar to the multi-singer controller.
Stephane: 8483 described an intermediary case: signers in different organizations but coordinating closely by human means.
Johan: yes, but it can be more difficult
Stephane Bortzmeyer: Do you require that the SOA is in sync across all vendors?
Johan: The Serial Number, not so munich, the other parts (contacts, etc) yes.
Johan: They will different SOA but must have keys in sync
Bob Harold: TSIG ?
Johan: TSIG can be used to for zone transfer, or something else that is secure
Suzanne Woolf: Integrated architecture but several drafts that tie them together.
Still hard to take something concrete out of this, other than more discussions.