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
INWX: Punycode not supported? #2450
Comments
I've never been using such domains and I actually try to avoid them :D @TomOnTime Can you confirm that this is expected behavior? I can see dnscontrol/pkg/zonerecs/zonerecords.go Line 33 in 9741d3c
dnscontrol/commands/previewPush.go Line 168 in 9741d3c
So it should work with all providers the same way? |
In theory all providers should handle this the same way. Sadly they are inconsistent. I think the problem is that we haven't clearly decided how we should handle these domains. Thus it is difficult to decide what the right thing to do should be. Here's one option:
|
I'm not an expert when it comes to encoding, like punycode/unicode or what amplifications it might have. My high-level thought: As dnscontrol is designed to be managed by users (manually), showing the Depending on the provider and its API, we might then decide (a new capability flag for it?) if a special processing is needed - like converting to/from punycode before interacting with the API. |
I'd display what'd actually would be sent to the API. If the provider doesn't support UTF-8, then show the IDN format. I'm a low level techie and would really want for the diff not to lie to me or give me alternative data, to what actually ends up on the nameservers. Masking this in user representation might lead to harder to debug situations. |
An issue I've ran into is when the registrar uses punycode, but the DSP uses the UTF-8. So having dnscontrol be opinionated and change as needed for the API could actually be preferable. |
Seems like IDN is completely broken at INWX now? 😟 I know it worked at v4.1.1 with unicode format. Now at v4.6.0 it's broken for both formats:
But it exists at my INWX account: /cc @patschi |
(Last reply deleted.) Seems like it's a pure cosmetic issue at
But it's still an issue to mix providers with different IDN formats. Now my local BIND zone file gets always updated, because it supports only the punycode format. ^^ @patschi It's possible to add a test IDN to your INWX account without buying it! Just go to Nameserver and click at the Add domain button in the top right corner. Now enter something like |
DNSControl is an opinionated system. Is there an "opinion" about how IDN domains should be handled that would help? (I don't own any such domains and have nearly zero experience here) |
I would say this RFC covers the "opinions" about how IDN should be handled in applications. More about IDN can be found by this author: https://datatracker.ietf.org/person/paf@paftech.se |
This discussion is happening on many providers. The global issue is tracked here: #2097 |
It seems IDN domains are only supported without punycode format at v4.1.1.
D("xn--exmple-cua.at", …
throws an error atdnscontrol push
:Only
D("exämple.at", …
works. I think this is not the intended behavior?/cc @patschi
The text was updated successfully, but these errors were encountered: