On 25 Apr 2020, at 00:30, Shumon Huque <shu...@gmail.com> wrote: > On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh <gmccull...@gmail.com > <mailto:gmccull...@gmail.com>> wrote: > > PS How truly intractible is the registry argument? It seems something like > "When an NS change is made, TTL=3600 for the first N hours, then 2 days > thereafter." would be a major step forward without drastically increasing > complexity. > > Based on history to date, it seems to be rather intractable, but I would love > to be proven wrong. The interfaces that registrars use to update delegation > records in the registries don't even offer any TTL configuration option that > I've seen (even if the registries were willing to support it). Does the EPP > DNS mapping even support setting TTL? > > That's one way to approach it. What I was thinking was, if the registries > want to dictate the TTL, that seems understandable. But in so doing, they > could have a process where they dictate a lowered TTL (of their choice) for a > period after each change, then raise it back up to normal in order to reduce > the impact of mistakes/problems. A "bake period" essentially. The timers > would be argued about of course, like all magic numbers, but something > conservative like an hour would seem like a major improvement on today. > Hypothetically, would you consider that would improve your use case? > > Based on my experience, I doubt that registries would do this. I could be > wrong though, and perhaps we should ask and get them to respond to your > suggestion. But to answer your last question, the draft that has been > proposed is not about improving my own personal use case(s).
As a contracted registry operator, we will do whatever the contract tells us to do. However, it might be that centralising the requirements for this kind of new mechanism in the form of legal contracts with ICANN, back-end registry providers, etc might not be the most efficient way of deploying anything. There are also many TLDs that are not contracted parties and who (properly, sensibly) make their own decisions. If part of the goal is simplicity through consistency, this seems like a poor approach. More generally, putting the TTL for the NS set effectively in the hands of the child zone operator provides maximum flexibility for appropriate values to be chosen. Concentrating a TTL policy in the parent for all child zones, regardless of downstream operational circumstances or personal preference, seems a lot less flexible. With a child-centric approach, the NS RRSet TTL in the parent zone relates to the parent infrastructure and is useful until the child can be reached, at which point it can be replaced a value that makes sense for the child infrastructure. This seems intuitive, simple and sensible. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
