mir/dnsop-wg-materials
2
0
Fork 0
mirror of https://github.com/ietf-wg-dnsop/wg-materials synced 2025-08-21 17:57:18 +00:00
Code Issues Releases Wiki Activity

minutes

Browse Source
This commit is contained in:
Tim Wicinski 2022-05-30 08:05:22 -04:00
parent c472f11554
commit af23e4fa46
1 changed files with 32 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
interim-2022-dnsop-01/dnsop-interim-2022-01-minutes.md
View File

@ -25,7 +25,7 @@
* Jabber: [dnsop@jabber.ietf.org](dnsop@jabber.ietf.org)
* Minutes: [https://notes.ietf.org/notes-ietf-interim-2022-dnsop-01-dnsop](https://notes.ietf.org/notes-ietf-interim-2022-dnsop-01-dnsop)
* Minutes: [https://github.com/ietf-wg-dnsop/wg-materials/blob/main/interim-2022-dnsop-01/dnsop-interim-2022-01-minutes.md](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/interim-2022-dnsop-01/dnsop-interim-2022-01-minutes.md)
## Agenda
@ -44,7 +44,8 @@ ksk/zsk working but need more explicit handling of CSK
basic working of algorithms. but work through implementation pieces
Currently has an implementation that works with dynamic updates and an interface with deSEC is in development
Currently has an implementation that works with dynamic updates and an interface with deSEC is in development.
* Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator,
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
@ -57,41 +58,52 @@ several implementations done or in progress
three issues
- operator be required to serve bootstrapping issues for all domains?
* Issue 1: operator be required to serve bootstrapping issues for all domains?
Ben Schwartz: Should not be required and wrong technically
Ben Schwartz(BS): Should not be required and wrong technically
Peter Thomassen(PT): maybe a political requirement
Wes Hardaker: Should not unless we have a good reason
- do we need an IANA action?
BS: Do all nameserver operators of a zone must participate?
- Delegations within a bootstrapping zone
PT: Only needed for the first time. If domain is insecure and multi provider,
draft currently says all name servers serve bootstrapping records.
- Tuple with (name, RRType)
* Issue 2: do we need an IANA action?
- Solution Options
Benno: Many +1 in chat to IANA action.
- different record type
- hashed naming scheme (ruled out)
- bootstrap under _dsauth
- disallow CDS/CDNSKEY usage for subzone rollover
- disallow zone cuts underneath _dsauth
- underscore prefix for actual signal
* Issue 3: Delegations within a bootstrapping zone
Peter van Dijk: How would you know if something is the leaf domain or not?
Solution Options
Ben: Can't rollover these domains unless bootstrapping
1. different record type
2. hashed naming scheme (ruled out)
3. bootstrap under \_dsauth
4. disallow CDS/CDNSKEY usage for subzone rollover
5. disallow zone cuts underneath \_dsauth
6. underscore prefix for actual signal
Peter van Dijk: for No 3 - How would you know if something is the leaf domain or not?
BS: can we say records carry both semantics? Can we demand they are the same?
PT: They will have different cds records
John Levine: Corner Case but leans toward #5
Peter: people think of #6 ?
PT: people think of #6 ?
Nils: Ben's comment from chat - #6 needs it's own #5
PT: Easy to add new record types
Nils: Ben's comment from chat - #6 needs it's own #5, strong argument.
Warren Kumari: Burning code points using #1.
Roger Murray: Personally like #1, but maybe sending more queries.
Roger Murray: Will differences between 1 and 6 affect the scanning.
Personally like #1, but maybe sending more queries.
```