IDNA proposal

[tlimoncelli]

No description provided.

[tlimoncelli]

Mentioning a number of people that I suspect have IDNA domains or knowledge about how IDNA works (based on skimmy bugs and PRs)

@adamus1red
@dkim1970
@flz
@juliusrickert
@killerbees19
@Kusado
@louis-lau
@masterzen
@mderriey
@pmoroney
@tresni
@Yannik

I'd love to receive feedback about this proposal!

[Yannik]

@tlimoncelli

I think your example for the asci==unicode exampe might be wrong:

#7: + CREATE foo.example.com MX 10 xn--p1ai.com (рф.com) (ttl=14400)

Was this what you intended?

[Yannik]

I noticed you created both CREATE and MODIFY examples for ascii (unicode) and unicode (ascii), but only MODIFY examples for ascii and unicode. How is that to be understood?

[tlimoncelli]

@tlimoncelli

I think your example for the asci==unicode exampe might be wrong:

#7: + CREATE foo.example.com MX 10 xn--p1ai.com (рф.com) (ttl=14400)

Was this what you intended?

Ah, good point!

The first one is where the label is ascii==unicode but the target is ascii!=unicode. I'll update the comment.

Thanks for finding that!

Tom

[tlimoncelli]

I noticed you created both CREATE and MODIFY examples for ascii (unicode) and unicode (ascii), but only MODIFY examples for ascii and unicode. How is that to be understood?

I've added more examples. I don't think I've covered every combination, but my goal is to show typical examples not every possible example.

I've also added examples where we use {} and ⟬⟭ and ❮❯. I think using unicode chars to highlight unicode domains would be cool (maybe too clever?).

[adamus1red]

While I'm not against having the ASCII and UTF on the output lines, I do worry it might make the output too busy.
Wouldn't simply using the .Name value be a better since it should then pretty much match what is in the dnscontrol configuration?

[pmoroney]

LGTM

[tlimoncelli]

@adamus1red wrote:

While I'm not against having the ASCII and UTF on the output lines, I do worry it might make the output too busy.
Wouldn't simply using the .Name value be a better since it should then match what is in the dnscontrol configuration?

That's an interesting point! I guess my thought is that showing both versions helps with debugging.

[adamus1red]

That's an interesting point! I guess my thought is that showing both versions helps with debugging.

@tlimoncelli maybe a compromise would be if the output was the same as what the DNS provider or Registrar used.

I know I've had issues where the DNS is using UTF but the registrar is using ASCII. I.e. namecheap uses ascii, so for registrar stuff using namecheap use ascii punycode and the DNS is cloudflare which uses UTF, so the output uses UTF.

[louis-lau]

The only IDNA domain I have is for fun, so I don't have a strong preference. I'll give my input nonetheless :). If you want to show both, I think I like B better, as it feels more consistent to me. Anything not in brackets will always be ASCII that way.

I'd probably go with showing what the original user input was, with a flag to only show ASCII if needed. It's less information to parse, and the user should be familiar with it as that's the way it's listed in their config. I could see points being made for showing both, but I've always liked things more distraction free and less dense.

I think the Unicode brackets are a little too clever, perhaps even a little confusing ;)

[Yannik]

First of all, improving IDNA handling would be a great improvement to dnscontrol.

Regarding output, the one thing I definitely do not like is having the ascii output come first, because it is the one least likely to be understood/mentally associated with the relevant domain.

I think simply using the original user input has merit, pairing that with a toggle to additionally show ascii seems fine to me.
However, I also wouldn't mind the unicode (ascii) output.

[dkim1970]

First of all, improving IDNA handling would be a great improvement to dnscontrol.

Regarding output, the one thing I definitely do not like is having the ascii output come first, because it is the one least likely to be understood/mentally associated with the relevant domain.

I think simply using the original user input has merit, pairing that with a toggle to additionally show ascii seems fine to me. However, I also wouldn't mind the unicode (ascii) output.

I'm seconding this suggestion, by displaying the "human readable" format I think the barrier for using IDN's with dnscontrol is getting lowered.

Because the IDNA format is not human readable, especially when it comes to non-latinized languages.

[tlimoncelli]

This is excellent feedback! It's getting me excited!

Question: In what situations would people want to see something besides the .Name (the user input) version?

[adamus1red]

Question: In what situations would people want to see something besides the .Name (the user input) version?

What about if the registrar or dns provider use something different than the .Name value, then include the version they are using in brackets?

[louis-lau]

Personally, I think whatever the dns provider does isn't relevant to the cli output. Behind the scenes at every provider, it's all punycode anyway.

[Yannik]

Personally, I think whatever the dns provider does isn't relevant to the cli output. Behind the scenes at every provider, it's all punycode anyway.

Agreed, having the display format handled outside of the provider is to be preferred IMO.

[masterzen]

I don't have experience with IDNA at all.
My $0.02: I do agree that showing the ascii version is useful only for debugging, what users want to see is if their unicode domain (or however it was entered in dnsconfig.js) is being processed and how.

[tlimoncelli]

Hi folks!

2 ideas:

Support multiple formats?

There's been a lot of discussion about ascii (unicode) vs unicode (ascii). It might be possible to add a command line flag that selected the format. No promises, but it might be possible. In that case, I'd recommend the default be userinput and add a flag for debugging that shows unicode (ascii) or userinput (ascii).

I'll know more if this is possible when I start coding.

An idea that would break less existing code

Existing code expects .Name to be ASCII (the current code runs dc.Punycode() for all providers, which rewrites .Name to be ASCII). Rather than require every use of .Name to change to .NameASCII, maybe the names should be: .Name (ASCII, to be compatible with old code), .NameORIG (how the user input the string), .NameUNICODE, and .NameDisplay.