On Fri, Apr 3, 2020 at 11:59 AM Ralf Weber <[email protected]> wrote: > Well it was you think and others (including me) disagree for valid reasons. > There is absolutely no reason to issue queries for some validation, when > you already got good results. > > I see this is a workaround for people to lazy to update the delegations, > and put more complexity and work on resolvers. >
Dear Ralf, It is possible that there exist some people who want this because they are "too lazy" to update delegations. But I strongly suspect there are other reasons. Let me explain why I am personally interested in having this behavior implemented widely. We can take care to make sure the contents of parent/child NS sets are always in sync (and we do). What we cannot control is the TTL value of the NS RRset in the parent. Many TLDs are quite inflexible in this regard and only support long (~2 day) TTLs. (I know some people will immediately say let's fix this. But we have to live in the real world of TLDs. Folks have been asking for this forever, and there has been no movement. And if there is movement, that will happen on the timescale of many years or longer). Normally, this is not an issue for us, as we prefer long TTLs on zone infrastructure records for stability and performance reasons. The issue arises when we are making changes to the infrastructure, such as migrating to another DNS provider, or deploying DNSSEC etc. We want to make sure we can very quickly backout changes if we encounter unanticipated problems, by temporarily deploying a short TTL. To give you a real case, some time last year, we signed and migrated some of our important zones to a set of new providers, after extensive testing (verifying the zones were correctly deployed and signed, detailed pre-delegation testing, distributed monitoring of the provider footprints etc). A couple of days after pulling the trigger, we discovered breakage in a particular region of the world where one of the provider's servers were misconfigured. We weren't able to catch this pre-deployment, since our distributed monitoring did not include nodes in the anycast catchment area(s) of these broken servers. So, we had to backout the change, and then deal with the lingering up-to-2-day effect of the parent NS TTL (for parent centric resolvers). To fend off these kinds of issues, there are some well known infrastructure operators that configure their resolvers to enforce a maximum cache TTL of only 60 seconds. Should we be advocating things like that? :) (There is a larger philosophical question that I will avoid for now, about why resolvers should prefer non-authoritative glue, which cannot be signed, over signed authoritative data, and whether or not we should redesign the DNS delegation mechanism to fix that. The security of DNSSEC does not currently rely on signed nameserver records, but why not try to catch spoofed delegation data as early as possible, at its source?). Shumon Huque
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
