Approaches to Support Setting Primary Names for All Contracts

[nischal.eth]

@nick.eth

An attacker cannot* use control of a reverse record to point it at a name that then resolves to something else. But they can use it to name the contract whatever they want, potentially contrary to the wishes of the actual owner (if any).

Yes, that’s a valid point and one we’ve considered in our approach. While an attacker could technically change the primary name and spend mainnet gas doing so, the key question is: what’s the incentive to do that if the name cannot be used for any exploit or misleading purpose?

@nick.eth

*Not easily, anyway - a clever resolver implementation could be configured to return different results depending on how and when it is called, potentially giving a correct result at the time reverse resolution is performed, but later resolving to a different address.

I see, however, I believe with careful consideration and enough rigor, we could design a ContractResolver that prevents this kind of behavior, by ensuring that once a name is set as the reverse resolution for a contract, its forward resolution cannot be arbitrarily changed. This constraint would safeguard against misleading resolution scenarios like later resolving to a different address.