On Saturday, August 25, 2018 6:11:48 PM UTC Tom Pusateri wrote: > ... > > In most cases, having the primary remember the lease lifetime should be > enough. But if the outage is longer than the lease lifetime, it would > better if the secondary would also have that information.
you seem to be proposing that the "secondary" servers, by which i mean those not the primary master, alter the zone contents in a way that's visible to query initiators, independently. if so, i oppose this, in the form proposed. to have more than one source of DNS truth requires "multi-master", so that zone identity can be partitioned and healed, following partitions and healings of the connectivity of each responder and its cloud of reachable clients. one of the hard problems here is split horizon. another is incompatible deltas at heal time. the database world has grappled with this topic, having varying degrees of success, for as long as there have been computer networks. i would like to see DNS add "multi-master". several proprietary vendor extensions do various parts of this -- though none of them that i know of can handle split horizon or incompatible deltas. and tellingly, none has been opened to the community in the form of a standardization effort. if on the other hand you only intend to carry the timeout information as zone data transferred in AXFR/IXFR in case a sysop decides that the primary master will be offline indefinitely and wants to manually promote one of the "secondary" servers to the role of primary master, then i have no objection. that's why the TUU and TUD RR's of my 1996 "defupd" proposal are in-zone data rather than stored in some ancillary location reachable only by the primary master. can you verify that you do not intend secondary servers to automatically expire records, independent of hearing IXFR/AXFR updates from the primary master, after the primary master applies its own copy of your TIMEOUT RR's? -- Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
