Hi,
Is there a documented way to block unicode domain names ( all of them, not some ) ?
Why ? Because http://xn–80ak6aa92e.com/ reads like apple.com in anything outside of Internet Explore. Firefox has a puny flag which can be set so the domain does no longer get displayed as apple.com but Chrome is pending an update to fix this issue.
Best Regards,
JL
As maintainer in Fedora and one of th DNS team members for RHEL, I would
compile-time disable any such option as it would break all non-english
or latin domains. It is not an acceptable workaround ever.
The real fix here is that .com needs to come up with proper policies
regarding mixing scripts and domain bundling, something that the
newGLTDs did properly.
Paul
FYI yesterday's Chrome released fixed this. Firefox 53 still requires
the about:config toggle.
Joris L. via Unbound-users skrev den 2017-04-21 18:48:
Is there a documented way to block unicode domain names ( all of them,
not some ) ?
ask the nic registra for this idn domain, if idn decode only come back with 7bit its not need to be encoded in idn
all other ways to solve it it will break idn and unicode
Why ? Because http://аррӏе.com/ reads like apple.com in
anything outside of Internet Explore. Firefox has a puny flag which
can be set so the domain does no longer get displayed as apple.com but
Chrome is pending an update to fix this issue.
latest browsers is not always better
if it have anything to do with unbound, it could be solve if idn domain decode turns up with 7bit only results, then lie to the query with domain not found
but its a nic registra issue, not a dns issue in any dns server
Thanks Paul, i understand, mostly. I must admit i’m somewhat dumbfounded with
"The real fix here is that .com needs to come up with proper policies
regarding mixing scripts and domain bundling, something that the
newGLTDs did properly. "
What do you mean with “mixing scripts and domain bundling” ?
Br,
Joris
Thanks Paul, i understand, mostly. I must admit i'm somewhat dumbfounded with
"The real fix here is that .com needs to come up with proper policies
regarding mixing scripts and domain bundling, something that the
newGLTDs did properly. "
See https://archive.icann.org/en/meetings/saopaulo/presentation-IDN-tutorial-03dec06.pdf
What do you mean with "mixing scripts and domain bundling" ?
Mixing a Cyrillic "c" in a latin alphabet will very hard for humans to
distinguish from a Latin "c", so this must be disallowed, or at the
very least end up at the same Registrant.
For domain bundling, see https://cira.ca/assets/Documents/Legal/IDN/faq.pdf
It means that since I have registered "nohat.ca", no one but me can
register "nohâts.ca". These names come in a "bundle" to the same
Registrant only.
Paul
Thanks Paul,
Evidently, indeed. If one registers a name it must be protected in any code, ascii, ansi, utf …
Remains the problem of a man-in-the-middel and self generated certificates with legitimate server names, given the rise of free ssl certificates this may be a legitimate concern. It also suggests the creation and validation of certificates on the client side must be extended to registrars of domain names etc. to warrant safe usage. I’ve not really put much thought in it since i’m not in a position to make a difference anyway.
Br,
JL
Hi Joris,
I think it is all about domain registrars. You cannot prevent anyone
generating self-signed certificate. That is no problem, they are not
trusted by anyone. If you are talking about domain verified certificates
provided (for example) by LetsEncrypt, that will be solved by good
registrar policy as well. These certificates are generated only for
already available domains. You will not be able to verify your domain
unless registrar adds it into the TLD. If he refuses to add it for a
reason, you will not get trusted certificate for it as well.
If registrars do their job well, I think there is no more work required
for certificate providers. Do you agree?
Cheers,
Petr
Dne 22.4.2017 v 21:36 Joris L. via Unbound-users napsal(a):