Request for an "ENAME" record type on the public resolver

I want the ability to specify something analogous to a CNAME record from DNS. For example, if I own both virgilgr.eth and virgil.eth, on virgilgr.eth I can put a ENAME to virgil.eth so queries to virgilgr.eth are automatically forwarded to virgil.eth

There may be some trickiness in enabling ENAMEs on second-level-domains, but this is something we can figure out.

Could this not just be a text record with the key being “ENAME”? That way it is already supported for the majority of domains with resolvers without requiring upgrades.

I’m referring to the ENS resolver, not DNS resolvers. As far as I know, in ENS, only the public resolver is used. And moreover the public ENS resolver doesn’t support TXT records.

Actually it does support DNS records (there is a full DNS profile in the public resolver) but there is also a TEXT type field that is a simple key/value store. The code for the TEXT profile is at

For example:

$ ethereal --network=goerli --domain=idnstest.eth ens text set --key="ENAME" --text="anotherdomain.eth" --wait
$ ethereal --network=goerli --domain=idnstest.eth ens text get --key="ENAME"

The tricky bit is deciding where to carry out the recursion if an ENAME is present. It could be added to the public resolver to fetch data for the ENAMEd domain, but that would massively increase the complexity of the resolver (not least because it would have to generate namehashes from strings, which is hard/gas-heavy due to the various rules involved). Alternatively, it could be added to the various client libraries but there are quite a few of them out there, so we could end up with inconsistent resolution if the codebases are not all in sync.

I suspect that the latter option is the only realistic one. Not sure what the best approach would be to push something like this that touches a lot of third-party code.

1 Like

Thank you for the correction @ricmoo. I’m not attached to the name ENAME. ALIAS or whatever would be fine by me. But this functionality is something we need a record type for.

1 Like

I lean towards the client-side approach. If gas becomes less of an issue we can explore increasing the resolver complexity

First, to clear up a misconception: the current resolver has support for text records, independent of its support for DNS records. There’s no need to involve the DNS support for this.

Second, the default resolver isn’t the only usable resolver - anyone can write one.

This can be accomplished entirely inside the resolver, by adding a lookup table from namehash to namehash. The resolver can check this mapping before resolving a name. An even simpler approach might be to have a “CNAME resolver” contract whose sole job is to look up its internal table and then forward the call to the name it finds there.

This is much simpler than requiring clients to support this, because that would require updating every existing client to support this new record type and resolve names correctly. In the meantime, some names would resolve to nothing on some clients and to the correct record on others.

1 Like