Right, prefix delegation over DHCPv6 is a similar case that gets a prefix lifetime. I still use the WIDE dhcp6c client for PD and it has no means to update DNS. I haven’t found specific documentation from ISC DHCPv6 or KEA that describes creating DNS entries (PTR records) from delegated prefixes.
Tom > On Aug 24, 2018, at 10:53 PM, Ted Lemon <mel...@fugue.com> wrote: > > When would that happen? > > On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <ma...@isc.org > <mailto:ma...@isc.org>> wrote: > Registering slaac derived addresses in the DNS. These are tied to prefix > lifetimes. > > > -- > Mark Andrews > > On 25 Aug 2018, at 05:02, Tom Pusateri <pusat...@bangj.com > <mailto:pusat...@bangj.com>> wrote: > >> >> >>> On Aug 24, 2018, at 2:59 PM, Ted Lemon <mel...@fugue.com >>> <mailto:mel...@fugue.com>> wrote: >>> >>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri <pusat...@bangj.com >>> <mailto:pusat...@bangj.com>> wrote: >>>> It seems odd to take the position that the authoritative server shouldn’t >>>> need to clean up stale entries because it assumes the client will do it >>>> for you. I can’t imagine you taking this position under any other scenario. >>> >>> The issue here is that this is a pretty major change to the DNS. If we >>> really want something this heavy, we should have a good reason for wanting >>> it. That's all. >>> >>> The idea that some unnamed DHCP server somewhere doesn't do the right thing >>> with cleaning up stale entries doesn't seem like a good enough reason, >>> particularly given that the DHCID record tags the thing as having been >>> added by the DHCP server, and considering that there are several open >>> source implementations that do automatically delete records when the lease >>> expires. >>> >>> I think it might make sense to just wait on this. I agree that it's an >>> interesting idea for completeness, but we don't have enough operational >>> experience yet to know whether we have a problem worth solving. With >>> respect to the DHCP use case, I'm certain we don't. >>> >>> The good news is that if we do need this, you've done a design, and we also >>> have Paul's design to look at. So if operational experience a few years >>> down the road shows us that we have a gap here, we can move on it pretty >>> easily. I just don't see any reason to rush into it. >> >> Ok, great. Hopefully others have some use cases they can share. In the mean >> time, back to learning Rust… >> >> Thanks, >> Tom >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >> https://www.ietf.org/mailman/listinfo/dnsop >> <https://www.ietf.org/mailman/listinfo/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
