On Saturday, 4 April 2020 22:55:55 UTC Viktor Dukhovni wrote: > On Sat, Apr 04, 2020 at 09:56:06PM +0000, Paul Vixie wrote: > > ... > > I'm therefore sympathetic to Google's parent-centric approach (one > source of truth), without denying the desirability of letting the child > zone adjust TTLs.
i am not. sympathetic, that is, to any approach which discards useful information. this is apparently an area of the protocol which would benefit from more specification. for example, only NS RRs which appear both above and below the cut should be used, and if there is no overlap, the zone should be treated as lame. perhaps this topic will come up over on [email protected] where the ns-revalidation specification is supposed to be discussed instead of here. > Of course, we should probably not overly optimize the design for the > minority of cases that are broken. The majority of cases where the > parent glue and child zone apex don't agree are benign. i don't think anybody has called for overly optimizing anything, even allowing for wide subjectivity on the meaning of the word "overly". rather, we should seek a balanced design that incentivizes correctness at reasonable complexity costs. we don't have that balance today: costs and benefits are ~unrelated. a system which is only resilient because of widespread error-tolerance must always become a diagnostic hellscape. -- Paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
