On Mon, Jan 29, 2024 at 3:45 PM Wes Hardaker <wjh...@hardakers.net> wrote:
> IESG Secretary <iesg-secret...@ietf.org> 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