I wish there was a kind of "dead man switch" app that would wipe a device if it is not unlocked for x days or met some other kind of personalized criteria.
No such thing exists
> If you don't do a lookup every X days, it'll expire from the cache
Requerying a cached DNS record doesn’t extend its TTL. TTL is based on when it was first added to the cache.
Think about that from a technical perspective and you’ll realize the flaw. :)
You can’t cycle to a new set unless the authoritative server is still responding with the key. If the authoritative server still has it, what difference does the fact a caching name server has it? Furthermore, there’s zero guarantees a caching resolver will cache for the length of the specified TTL, so you literally have a land mine that’ll explode randomly and cause you to lose your data.
> As the GP hints
Read it again. GP’s Github link doesn’t allude to what you imply it does. Storing arbitrary data in DNS is of course possible and others will cache it for you, but implying anything like what you described as feasible just doesn’t hold merit.
> but calling it "factually not correct" is unfair.
This entire theory you posted originally doesn’t hold up to even basic technical review. It’s nothing against you personally, the idea simply doesn’t provide any actual benefit and very fairly is factually incorrect.
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.
A better idea would be to put an RTC + watchdog timer[1] into the security chip that holds the keys and power it continuously with a small amount of external power. The power must be available and the watchdog timer must have time remaining to disconnect a circuit that pulls the memory holding the keys to ground.
More advanced types of tamper resistance and self-destructing chips are possible, but they tend to have significant downsides.
Presumably, this would automatically delete your G Suite email, contact, calendar, and other data from your device.
EDIT Using Apple Configurator, you can change the number of times unsuccessful attempts can occur before erasing an iPhone to anything between 2-10.
That option has been built in to the iPhone pretty much since the beginning.
After all, when was the last time you spent three days without fondling your phone?