Ted stop being daft. People have been registering addresses of machines in the public DNS for decades. SLAAC. Is just one source of addresses. DHCP is another. Come up with a third method and they will do it with it.
Also DHCP servers from ISPs don’t have authority to update DNS servers for my machines. Only those machines have such authority so don’t discount DHCP derived addresses. -- Mark Andrews > On 25 Aug 2018, at 12:53, Ted Lemon <mel...@fugue.com> wrote: > > When would that happen? > >> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <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> wrote: >>> >>> >>> >>>> On Aug 24, 2018, at 2:59 PM, Ted Lemon <mel...@fugue.com> wrote: >>>> >>>>> On Aug 24, 2018, at 2:43 PM, Tom Pusateri <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 >>> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
