Why are resolvers configurable?

💬 General Discussion
1

As I understand, lookup of an address from an ENS name is a two step process, first to find the resolver, and then to resolve (using it) to the address:

Screen Shot 2022-04-19 at 2.01.33 PM
Screen Shot 2022-04-19 at 2.01.33 PM1890×872 122 KB

I registered an ENS name and found that the resolver defaulted to 0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41.

This default one seems to implement lots of good things, like an arbitrary key-value store for text records.

However, I noticed on the dashboard it is possible to change the resolver contract.

Why is this?

What kinds of reasons or new usecases might require users to switch out their resolvers or design new ones? Are there already examples of this? Or is this mostly a “someday people may want to do things ENS developers haven’t thought of” type of thing?

Thanks!

1 Like
2

The public resolver has been updated a number of times to add new features and functionality. And while its data model and permissions model suits most people, there are good reasons to want to use something else. Making the resolver configurable for each name allows for customisation and dynamic upgradeability without requiring a change to the whole system.

For example, the recently introduced wildcard support (ENSIP 10) and offchain lookup support (EIP 3668) both require changes to resolvers to implement.

2 Likes
3

Wow, this is fascinating.

So essentially the storage of all records associated with ENS names need not be in contracts controlled by ENS? In effect, seems like I can, at any time, code my own resolver which could serve whichever arbitrary rules or records I like, and changing them doesn’t require ENS to add anything to their frontend application. (hopefully I got this right?)

However: to maintain interoperability, are there interfaces that resolvers have to abide by (like a small required set of records to support) or is it completely free for all? Would love to find where this is mandated in code if so!

4

No, but close. The resolver only parses the data. The metadata is in fact stored in the registry, which is locked in place, unlocked only by the owner. Resolver is more like CSS. It makes things “look nice”. Of course you can morph the data through your custom resolver but that will only affect your view since it is only your custom resolver. Check this: https://ipfs.io/ipfs/QmTU7GXZN6iT5dajsPq8FaeGv2iQziDt6pqWUTcY5XEovE or https://ipfs.io/ipfs/Qmb3VVRcfqFbZAYq2RmfnQf7kQEVpzt6FpXnd1JQ5giuXP?filename=ENS.png

5

wow that’s a fantastic diagram! thank you muchly.

@inplco I’m having trouble seeing how the text records data structure is owned by the registrar contract and not a resolver. From the deployed resolver contract here on etherscan it reads from the text() function which looks suspiciously like the function from the resolver contract code here.

To me it looks like the resolver owns this data structure, but maybe there’s a better way to see which contracts are deployed and which code is used where? Sorry I am very n00b.

6

You got this right. The text() function queries the node along with the key, which returns the necessary metadata from the registry. The two links you sent are in fact the same code. Only the owner of the node can make changes to the registry such as setting content hashes or text records. This is pretty nicely detailed in the docs here: PublicResolver - ENS Documentation

You don’t sound like a nøøb. Stop playing us. Who dis?
(Sorry I bungled up my use of registry and registrar)

1 Like
7

That’s correct.

Yes, this is specified in ENSIPs.

That’s not correct. The registry stores only the owner and resolver address; all other data is stored by the resolver itself, and it can choose what to store and how to respond to queries. It can also set its own permission model - for example, the ‘owned resolver’ is a special purpose resolver that lets the contract owner set any record, regardless of whether it owns the name or not; this is used to implement the resolver for .eth, since .eth is owned by the registrar contract.

2 Likes
8

got it. to summarize:

  1. Resolvers are responsible for storing metadata
  2. Registry is just the system of record for ownership, TTL, and resolver choice.

hopefully got that right now.

for example, the ‘owned resolver’ is a special purpose resolver that lets the contract owner set any record, regardless of whether it owns the name or not; this is used to implement the resolver for .eth

could you say more about this? are you referring to “ENS Public Resolver 2” (0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41)?

since .eth is owned by the registrar contract

sorry, when you say “owned” here, what do you mean? I see here in the ethregistrar contract a mention that it “owns” the .eth TLD (in contracts/ethregistrar/BaseRegistrarImplementation.sol#L14). do you mean in the sense that the contract linked gates all changes to ENS registry’s .eth names?

thanks for all your patience here in answering all these questions!

9

Yup!

No, the Owned Resolver is separate to the public resolver; each user can deploy their own owned resolver, and it answers only to them. Here’s the one for .eth. It’s owned by the DAO wallet, so the DAO wallet can set records for .eth even though that name is not owned directly by the DAO.

By “owned” I mean an account is the owner of the name in the ENS registry.

1 Like