Front-end rejects non-IDNA2008 domains

[WKobes]

Although problems with non-IDNA2008 domains were already reported and partially fixed in #484, the front-end still rejects non-IDNA2008 domains (both in their rendered as punycode representation). You can use the example in #484, or see this example below:

Direct test works: https://internet.nl/site/xn--i-7iq.ws/

Entering xn--i-7iq.ws or i❤️.ws on https://internet.nl/test-site/ fails:

The given domain is invalid!
Explanation: An A and/or AAAA record is necessary for the website test, and a SOA record for the email test.

This seems to affect only IDN domains that do not conform IDNA2008. Valid punycode domains are accepted by the front-end.

[WKobes]

I expect that the DNS lookup check done in the frontend fails for non-IDNA2008 IDNs. If bug #582 is addressed, this will probably cause the direct URLs to tests on non-IDNA2008 to fail as well.

[baknu]

Thanks for reporting. This seems to be some sort of regression, because it was fixed (or should have been fixed) in the 1.3 release (issue #507).

[gthess]

That issue (#507) introduced the idna Python module that supports IDNA2008 instead of Python's own codecs that supported IDNA2003. The other issue (#484) fixed (read: ignored) the error when converting from punnycode back to unicode in the results page.

The current idna Python module only does IDNA2008, so non-IDNA2008 domains will not work.

[bwbroersma]

BTW we should fix this in the python code, but it's pretty easy to convert a unicode domain to punycode in the browser with URL:

(new URL('https://i❤️.ws')).host

which will result in the correct "xn--i-7iq.ws" (for if we ever migrate to a JS frontend ;)