Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
Wes On Mon, Jan 29, 2024 at 6:45 PM Wes Hardaker wrote: > IESG Secretary writes: > > > The Domain Name System Operations (dnsop) WG will hold a virtual > > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > > (17:00 to 18:00 UTC). > > I'm sadly very day-job conflicted with this slot, but greatly look > forward to watching the replay afterward (I may try to sneak an earpiece > into my head but it's unlikely I can pull that off). > > I'll note that if we're going to go down the road of such a major > change to parent/child/resolver interactions, it is highly important we > get opinions and viewpoints from all segments of the DNS industries to > ensure this is widely deployable. Having said that, if I can't keep my > own zones in sync properly with my registry's advertised data: it's time > to do something about the problem. [yes I recognize this is not an > adequate summary of the problem space, but it's a part]. Whether this > is the right solution or not will depend on feedback from many voices. > > I think not only opinions and viewpoints, but also a way to properly express the motivation. I added a question at the end of the chairs slides "Explain to Windows Admins and R53 Admins how this helps them" which is probably out of line, but this is more working to help summarize the motivation to a larger audience. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
On Mon, Jan 29, 2024 at 3:45 PM Wes Hardaker wrote: > IESG Secretary writes: > > > The Domain Name System Operations (dnsop) WG will hold a virtual > > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > > (17:00 to 18:00 UTC). > > I'm sadly very day-job conflicted with this slot, but greatly look > forward to watching the replay afterward (I may try to sneak an earpiece > into my head but it's unlikely I can pull that off). > > I'll note that if we're going to go down the road of such a major > change to parent/child/resolver interactions, it is highly important we > get opinions and viewpoints from all segments of the DNS industries to > ensure this is widely deployable. Having said that, if I can't keep my > own zones in sync properly with my registry's advertised data: it's time > to do something about the problem. [yes I recognize this is not an > adequate summary of the problem space, but it's a part]. Whether this > is the right solution or not will depend on feedback from many voices. > > Ditto, sort of. (Busy with day-job search etc.) My $0.02 is to paraphrase https://xkcd.com/1069/ (where the pick up line about putting "U" and "I" next to each other in the English language, gets trashed by a reference to orthography): If we're going to add something like DELEG, I'd very much like to see a corresponding apex record/flag on the child. It's the one opportunity to "fix" the RRR non-role that DNS operators have and the unilateral nature of parent-side NS records. (If someone can come up with a "backronym" for ATE, then the pair would be DELEG-ATE. :-) ) But seriously, having a signed parental record that can, among other things, get paired up with a signed child apex record which would confirm (or deny) the validity of a delegation to a specific nameserver, would be a very nice thing. (Permanently lame child servers would need to stand up a zone just for the denial assertion, but having resolvers obtain, use, and cache that would improve the situation for all parties.) I.e. this would facilitate revalidation (as previously proposed), except that it would handle permanently lame delegations, including the "all nameservers are lame" situation. Now that I think about this a bit more, there are problems with being able to sign a child zone that denies the legitimacy of the delegation. It might need to exist underneath the namespace of the nameserver name, e.g. with an underscore prefix. Modulo the signing and location, it would probably be sufficient for such a record to be "yes"/"no", as to whether the child thinks the delegation is legitimate. (This would basically be an anti-bootstrap record, if that description makes sense.) Of course, it would also be nice if the Registries were to take on and fix the delegation issue (including the conflicting registrar ownership and usage of host objects), but if the DNS protocol can facilitate a signed (secure) work-around, that gets DNS to the goal state sooner (a lot sooner?). The other things I'd like to see (which may already be in the draft): - Require DNSSEC if/when DELEG (and ATE) are in use - If child (ATE) is included, I'd really like the delegation confirmation to be a MUST. If you are a resolver, the scalability/stability/security of DNS depends on you respecting (validated) signals from authoritative servers, IMNSHO. - Resolver-auth signaling of understanding DELEG (probably more important for any semantic things if/when those arise), presumably via EDNS. - Client-resolver signaling too? Are there new capabilities or better security etc available if/when clients are upgraded appropriately? Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
IESG Secretary writes: > The Domain Name System Operations (dnsop) WG will hold a virtual > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > (17:00 to 18:00 UTC). I'm sadly very day-job conflicted with this slot, but greatly look forward to watching the replay afterward (I may try to sneak an earpiece into my head but it's unlikely I can pull that off). I'll note that if we're going to go down the road of such a major change to parent/child/resolver interactions, it is highly important we get opinions and viewpoints from all segments of the DNS industries to ensure this is widely deployable. Having said that, if I can't keep my own zones in sync properly with my registry's advertised data: it's time to do something about the problem. [yes I recognize this is not an adequate summary of the problem space, but it's a part]. Whether this is the right solution or not will depend on feedback from many voices. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
Dear WG, We have published an updated agenda for the interim, see https://datatracker.ietf.org/doc/agenda-interim-2024-dnsop-01-dnsop-01/. ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft - https://datatracker.ietf.org/doc/draft-dnsop-deleg/ - 15 minutes * Legacy resolver compliance testing results - 5 minutes * Open discussion points in the draft - 10 minutes * Initial reflections on DELEG - Paul Wouters - 15 minutes * Open discussion: discussion and reflection on interim - 10 minutes * IETF Process Time - BoF? New WG? Another hour needed at next IETF On 19/01/2024 18:13, IESG Secretary wrote: The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2024-dnsop-01 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop) ## Session interim-2024-dnsop-01 * Date: 30 January 2024 * Time: 17:00-18:00 UTC * [MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f) * [Jabber](dn...@jabber.ietf.org) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft. - 15 minutes * Legacy resolver compliance testing results. - 5 minutes * Open discussion points in the draft: - 10 minutes * Open Discussiontime for discussions - 20 minutes * IETF Process Time * BoF? New WG ? Another Hour Needed at next IETF Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2024-dnsop-01 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop) ## Session interim-2024-dnsop-01 * Date: 30 January 2024 * Time: 17:00-18:00 UTC * [MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f) * [Jabber](dn...@jabber.ietf.org) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft. - 15 minutes * Legacy resolver compliance testing results. - 5 minutes * Open discussion points in the draft: - 10 minutes * Open Discussiontime for discussions - 20 minutes * IETF Process Time * BoF? New WG ? Another Hour Needed at next IETF Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
