Thanks. That's the tricky part and I'd love to hear suggestions on it.
The trust to dns-specialized relays (+clients + nameservers), capable of verifying NIP-05 *before* the takedown, appears to be inevitable.
Briefly, something blockchain-based/like could be a solution, which could be implemented entirely on Nostr: these relays receive the domain owner's event kind 0, verify nip05 and broadcast a note with verification proof, which refers to the event kind 0. Other dns-specialized relays receive the proof but don't make it available for requesting until they themselves reverify it. They sign another proof, which refers to the newest existing proof for the same event kind 0 and broadcast that.
The relays would need to reject incoming too new/old events, so in this case, a new relay/nameserver won't be able to resolve domains that were taken down before the relay was deployed (or, alternatively, the relay could temporarily trust other manually selected dns-specialized relays and load old events from them after deployment).
When there's no takedown—resolve using normal recursive nameserver.
In case of takedown (detected while resolving using the recursive nameserver):
- if it's a new unknown takedown—relay signs the fact of the takedown and broadcasts to others for the similar confirmation process; may temporarily fail to resolve
- otherwise resolves records from an event signed by domain owner's npub, who has a corresponding newest nip05 proof with the `created_at < takedown_at` and the newest existing corresponding proof of the takedown; both proofs are with at least N confirmations.
I think that should work normally in case of voluntarily selling the domain as well (if the new owner broadcasts their event kind 0 for verification after acquisition).
The first takedown of the last corresponding proven nip05-verified npub is a real takedown; other takedowns and nip05 verifications after the takedown are ignored.
I wonder whether I'm missing some important case or something could be simplified.
