On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh <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.
i think this capability should be preserved, which this draft does by treating the delegation TTL as an upper bound on the apex TTL. if some registry wants to operate as quoted above, then periodic delegation revalidation in all RDNS servers will make it possible. if the registry prefers to let the registrar (or ultimately, the registrant) set the delegation TTL, then that will also be possible. therefore i repeat my earlier claim that any desire toward centricism, like child-centric or parent-centric, misses the point of delegation revalidation. DNS is a cooperative protocol, and local agency should determine data policy. On Monday, 27 April 2020 12:09:37 UTC Joe Abley wrote: > > ... > > 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. the protocol must not require this, but should facilitate it where desired. > 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. indeed, that's what the NS query is meant to do in this draft. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
