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