Support for resolving TLDs with punycodes #24
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementation is not able to resolve root domains with puny codes.
ENS supports unicode characters and therefore TLDs with special characters can be directly registered as they are without mapping to punycodes or other encodings.
As an example, if we take
☢㣎
, punycodexn--j4h059d
, we can create an ENS registry with☢㣎
whose hash is0x9944186df8dbb5bd89fd1d89d38b3889b75f7aa9fd3a0b66921a49372935804c
.When typing
subdomain.☢㣎
in a browser, it will be mapped tosubdomain.xn--j4h059d
which will trigger fingertip to query the handshake record forxn--j4h059d
resulting in a contract address which then needs to be queries using☢㣎
rather than its punycode equivalent.In short the flow currently is:
subdomain.☢㣎
in browerdomain.xn--j4h059d
.xn--j4h059d
and gets ENS registry contract addressdomain.xn--j4h059d
But step 4 should be:
4. Fingertip queries contract for
domain.☢㣎
This PR normalises the name to resolve before we call the ENS contract.