I think it will be very hard to stop the creation of code that harms people, whether a DNS, an app, or a website, so I don’t think we can make the underlying network only support a safe [cough] resolution service.
Hence I don’t see network side blacklists, reserving tlds etc as any more effective than @urrtag’s suggestion that the initial NRS be limiting client side, eg with an modifiable blacklist.
We could make the blacklist configurable, updateable, and optional to reduce the incentive to create or move to something less SAFE. I think that might be both more effective and a better UX.
My suggestion is to focus on helping users make the most appropriate choices about what NRS they use, which apps, which filters to enable etc, and do this all client side rather than attempt to bullet proof the network so only safe things can be built on it.
For example reserving the names / tlds and ‘destroying’ the keys (which can never be proven) will be bypassed by the first alternative DNS. So we still need to think of how to help people choose the most appropriate DNS for them, or they’ll easily be persuaded onto the now less safe alternative.