> You can’t cycle to a new set unless the authoritative server is still responding with the key. Yes - during a refresh you'd (re-)add the key to an authoritat

> You can’t cycle to a new set unless the authoritative server is still responding with the key. Yes - during a refresh you'd (re-)add the key to an authoritative server that you control, query it from X open resolvers that you do not control, then delete the records from the authoritative server that you control, such that the only remaining copies are held by the open resolvers. Care would be taken to make the key forensically unrecoverable on the authoritative resolver whenever it's not participating in this refresh process. > there’s zero guarantees a caching resolver will cache for the ... [full] TTL To deal with that you can test them first using useless/random data, and use many (10+) to deal with the risk that policy changes after your test. The hope being that it's unlikely for all 10+ to go offline, time out, etc, before your next refresh. But it is true that some availability risk is the price you must pay for the "unrecoverability after X seconds, using HW you don't own" benefit of the scheme.