Enforce ENS Normalization check on ENS Reverse Lookups #3832
lightwalker-eth
started this conversation in
General
Replies: 1 comment 5 replies
-
The namehash of Can you provide an example configured (e.g. even on goerli) that doesn’t work as expected? |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This suggestion relates to the lookupAddress function here: https://github.com/ethers-io/ethers.js/blob/main/src.ts/providers/abstract-provider.ts
The existing logic in this function might cause someone to perform a transaction with the wrong account.
Let's consider a scenario where address 0x123 has set a reverse lookup name "ExampleReverse.eth".
If the primary ENS name of 0x123 has been set to "ExampleReverse.eth" and the ETH deposit address of "ExampleReverse.eth" has been set to 0x123 then the lookupAddress function on address 0x123 will return "ExampleReverse.eth" as both reverse and forward resolution agree.
However, these checks aren't currently taking into consideration ENS Normalization. https://github.com/adraffy/ens-normalize.js
Continuing our scenario from above, let's say we're now some different Ethereum account 0x5678 and interacting with any dapp that's making use of the ethers.js library for reverse name resolution. This dapp might tell me that some account I'd like to interact with is "ExampleReverse.eth". However, here's the key issue: If I copy-paste this name into a properly implemented ENS client then I wouldn't be interacting with "ExampleReverse.eth". I would be interacting with "examplereverse.eth" which is a distinct ENS name with a distinct namehash from "ExampleReverse.eth". For example: If I perform a high value transaction with "ExampleReverse.eth" the properly implemented ENS client would actually make that transaction with "examplereverse.eth". Instead of performing that transaction with 0x123 it might perform it with Ethereum account 0x456 or whatever is configured as the deposit address of "examplereverse.eth".
Suggested resolution here is to add another check before returning a reverse lookup name: Any reverse lookup name not only need to pass a forward resolution check (already done), but it also needs to pass ENS normalization. If it doesn't then the reverse lookup should fail.
Beta Was this translation helpful? Give feedback.
All reactions