On Mon, Mar 4, 2019 at 9:26 PM Paul Vixie <[email protected]> wrote: > On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote: > > can I ask, what happens when a domain is intentionally down though? For > > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the > > master/shadow NS go down, hard. All public auth servers eventually (in a > > day or so) went dark too. > > i already raised that question, very far up-thread. got no answer. > > apologies for repeat-asking :( whoops! It'd still be good to hear an answer. I can think of simple product and not 'life safety' reasons that I might darken a zone as well, so if you don't want to answer for an abundance of caution for your fellow folken... think of the product marketing folk who mistakenly launch a day early, or who would like to retire a service in a clearly delineated manner.
:) > If someone is 'ordered' to make a zone dark, there may be reasons for that > > action, and real penalties if the request is not honored. > > Is this draft suggesting that the DNS operations folk go against the > wishes > > of the domain owner by keeping a domain alive after the auth servers have > > become unreachable? How would a recursive resolver know that the auth is > > down: "By mistake" vs: "By design" ? > > this the essence of the argument against utility for this entire proposal. > no > data should be served beyond its TTL unless some new leasing protocol is > first > defined, to obtain permission and to provide a cache invalidation method. > this is what I was thinking as well. thanks for more clarity.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
