On Saturday, 4 April 2020 17:45:49 UTC Doug Barton wrote: > On 4/3/20 9:28 PM, Paul Vixie wrote: > > the economy requires faster, easier takedown of domains. when a delegation > > is revoked due to bad behaviour by a registrant, it has to die > > _everywhere_ almost immediately. not sporadically depending on which > > (above vs. below) NS RRset was cached, or on what TTL it had. > > > > the overwhelming majority of newly created domains are used maliciously, > > and die quickly after short, brutal lives. we have to make them as easy > > to kill as to birth. > > I agree with you, Paul, on most domains being bad; and that takedowns > are often effective. However this is actually one reason not to prefer > the child TTL, since the bad actors will simply crank up the TTL on > their NS set to the max. > > That said, I still want to prefer the child TTL. The parent delegation > is not authoritative, it's just a referral. ...
somehow we're off track entirely, and using terms like parent-centric and child-centric. anyone using those terms hasn't read <https://www.ietf.org/ archive/id/draft-vixie-dnsext-resimprove-00.txt> so let me quote it for you: > INTERNET-DRAFT 2010-06-22 DNS-RESIMPROVE > > 2. Delegation Revalidation Upon NS RRSet Expiry > > 2.1. Because the delegating NS RRset at the bottom of the parent zone > and the apex NS RRset in the child zone are unsynchronized, the TTL > of the parent's delegating NS RRset is meaningless. A child zone's > apex NS RRset is authoritative and thus has a higher cache > credibility than the parent's delegating NS RRset, so, the NS RRset > "below the cut" immediately replaces the parent's delegating NS RRset > in cache when an iterative caching DNS resolver crosses a zone cut. > > 2.2. The lowest TTL found in a parent zone's delegating NS RRset > should be stored in the cache and used to trigger delegation > revalidation as follows. Whenever a cached RRset is being considered > for use in a response, the cache should be walked upward toward the > root, looking for expired delegations. At the first expired > delegation encountered while walking upward toward the root, > revalidation should be triggered, putting the processing of dependent > queries on hold until validation is complete. > > 2.3. To revalidate a delegation, the iterative caching DNS resolver > will forward the query that triggered revalidation to the nameservers > at the closest enclosing zone cut above the revalidation point. While > searching for these nameservers, additional revalidations may occur, > perhaps placing an entire chain of dependent queries on hold, > unwinding in downward order as revalidations closer to the root must > be complete before revalidations further from the root can begin. > > 2.4. If a delegation can be revalidated at the same node, then the > old apex NS RRset should be deleted from cache and then the new > delegating NS RRset should be stored in cache. The minimum TTL from > the new delegating NS RRset should also be stored in cache to > facilitate future revalidations. This order of operations ensures > that the RRset credibility rules do not prevent the new delegating NS > RRset from entering the cache. It is expected that the child's apex > NS RRset will rapidly replace the parent's delegating NS RRset as > soon as iteration restarts after the revalidation event. > > 2.5. If the new delegating NS RRset cannot be found (RCODE=NXDOMAIN) > or if there is a new zone cut at some different level of the > hierarchy (insertion or deletion of a delegation point above the > revalidation point) or if the new RRset shares no nameserver names in > common with the old one (indicating some kind of redelegation, which > is rare) then the cache should be purged of all names and RRsets at > or below the revalidation point. This facilitates redelegation or > revocation of a zone by a parent zone administrator, and also > conserves cache storage by deleting unreachable data. > > 2.6. To make the timing of a revalidation event unpredictable from > the point of view of a potential cache-spoof attacker, the parent's > delegating NS RRset TTL should be reduced by a random fraction of its > value before being stored for use in revalidation activities. > > Expires 2010-12-22 [Page 2] normally i would ask, please tell me how that could be made more clear. however, that ship has sailed, and the result is a new draft: https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 as a named co-author of both drafts, i think it's itinerant upon you to avoid making any statement that presumes a "child-centric" or "parent-centric" view on my part. i see a role for both delegating and apex NS RRsets, and i think any recursion logic that ignores one in favour of the other is incomplete at best, but probably also wrong. > The child should have the right to determine its own fate. This is > especially true when it comes to preparing for a redelegation, but there > are other reasons of course. that right is preserved in both this year's revalidation draft and the original from 2010. so i don't know who you are arguing with but it is not me and in such case i'd thank you not to make such a statement while replying to text i wrote, as in the case of your message here. > Regarding resolver operators who don't want to obey TTLs that they think > are too short, they already have options to set minimums that work for > them. That combined with the resolver otherwise obeying the child TTL > makes everyone happy (and follows the protocol). if you're going to argue against an internet-draft, please read it first. -- Paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
