Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS import does not work with non latin-character TLDs #1535

Open
linuxens opened this issue Jul 2, 2022 · 6 comments
Open

DNS import does not work with non latin-character TLDs #1535

linuxens opened this issue Jul 2, 2022 · 6 comments

Comments

@linuxens
Copy link

linuxens commented Jul 2, 2022

The ENS registration platform does not recognize DNS domains when the TLD is not latin characters. This was experimented on DNS domains where the TLDs had chinese characters, hebrew characters, and urdo characters. DNSSEC is supported on all of the TLDs and it was enabled for each domain. The DNS settings were updated with the _ens and wallet address etc etc.

The response given is: "DNS server responded with NXDOMAIN"

I have successfully imported several DNS domains with latin characters so I am experienced with making this process work. It only occurs with non-latin character TLDs. I have also tried to register them using punycode and it produces the same result of NXDOMAIN.

@linuxens
Copy link
Author

linuxens commented Jul 2, 2022

I have determined the likely culprit of why non-latin character TLDs fail the DNS server response test.

When the ENS manager currently uses the cloudflare DNS query, it sends a base64 encoded request with the non-latin characters. This will return a failed response every time. What the cloudflare DNS query should do is send a request with the punycode of the TLD instead. So it should be: domainname.xn--9dbq2a in the request instead of domainname.קום, for example. This should be an easy fix for the ENS team.

@aoxborrow
Copy link

The DNSSEC oracle contract cannot handle IDN names because it needs the punycode of the domain to verify with DNS. I'm not sure on-chain punycoding would be an exact science, since there are collisions where multiple unicode names produce the same punycode, per @adraffy:
https://discuss.ens.domains/t/dns-collisions-of-ens-names-in-browser-input/12539

See also:
ensdomains/dnsregistrar#10
ensdomains/dnssec-oracle#54

@adraffy
Copy link

adraffy commented Aug 17, 2022

The collisions only occur because some flavor of IDNA 2003 is typically coupled with Punycode processing (eg. browser address bar). Punycode itself can encode Unicode without issue.

To better understand Punycode, I recently wrote yet-another Punycode library https://github.com/adraffy/punycode.js by directly following RFC3492. IMO, it looks straight forward to translate that to Solidity.

@aoxborrow
Copy link

A Solidity Punycode implementation would be super helpful for the Handshake -> EVM bridge we're building! Are you planning to write one by chance? 😄

@adraffy
Copy link

adraffy commented Sep 10, 2022

I have a working implementation. What exactly do you need?

This code:
https://github.com/ensdomains/dnsregistrar/blob/4a0f94cb123d1a8ce22fa9ba07742fc5a73276c6/contracts/DNSRegistrar.sol#L72
Should look something like this?

uint labelLen = name.readUint8(0);
bytes memory decoded = decodeLabel(name.substring(1, labelLen)); // <----
bytes32 labelHash = decoded.keccak(1, decoded.length);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants