Event 1032 - Internationalized Domain Names (IDN) Support

Applies To: Windows 7, Windows Vista

Internationalized Domain Names (IDN) provides browser support for navigating to URLs written in a users' native language. IDN is composed of Unicode characters from most of the world's languages, relying on a standardized mechanism known as Punycode. Punycode encodes the Unicode domain names with only the ASCII characters permitted by the global DNS system.

When Is This Event Logged?

This event is logged when Windows® Internet Explorer encounters an Internationalized Domain Name (IDN).

Remediation

Internet Explorer users might experience the following issue, related to IDN support:

• Symptom. Internet Explorer shows an encoded Web address that starts with xn-- and an Information Bar that states "This Web address contains letters or symbols that cannot be displayed with the current language settings" appears.

• Cause. Internet Explorer shows an encoded Web address to avoid possible spoofing, if the domain name contains characters that are not used by the user's list of preferred content languages. Internet Explorer also performs the encoding to avoid look-alike attacks, where a user is redirected to a malicious site, for example, www.litwareinc.com versus www.1itwareinc.com, where the second URL replaces the letter L with the number 1. With IDN, the character set expands from a few dozen characters to many thousands of characters from most of the world's languages, thereby increasing the risk of spoofing attack.

• Workaround. The user can add languages to the configured language set, by clicking the Information Bar or by clicking Tools, clicking Internet Options, and then clicking the Languages button on the General tab.

  The order of configured languages is important, so the user must ensure that the preferred content language appears first on the list.

IDN Compatibility Impact for Network Administrators

Network administrators can disable the Information Bar by setting the HKLM or HKCU \Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\DisableIDNPrompt``DWORD registry key to 1.

Network Administrators might experience the compatibility impact of IDN support in the following ways:

• Symptom. When navigating to an intranet Web site where the domain name contains Unicode characters, the browser might fail to find the site and instead show an HTTP/404 error page.

• Cause. Previous versions of Internet Explorer used a different URL format when representing intranet domain names that contained non-ASCII characters. Some environments might not yet support the new IDN Punycode standard, so some sites might not be reachable using the IDN Punycode address format.

• Workaround. The network administrator can revert to the way Microsoft® Internet Explorer 6 handled the Unicode domain names, by using the Internet Control Panel.

  To change the Unicode domain name handling

  1. On the Tools menu, click Internet Options, and then click the Advanced tab.

  2. Scroll down to the International section, and then clear the check box for Send IDN server names or Send IDN server names through proxy connections, depending on whether you reach the destination domain by using a proxy server.

     -or-

     Open the Registry Editor and change the HKLM or HKCU \Software\Microsoft\Windows\CurrentVersion\Internet Settings\EnablePunycode``DWORD value, based on the following:

     • 0. Punycode is never used.

     • 1. Punycode is used when communicating directly with origin servers.

     • 2. Punycode is used when communicating with a proxy server.

     • 3 (default). Punycode is used when communicating with both origin and proxy servers.

IDN Compatibility Impact for Web Site Developers

Web site developers might experience the compatibility impact of IDN support in the following ways.

• Symptom. Internet Explorer shows an encoded Web address that starts with xn-- and an Information Bar that states "This Web address contains letters or symbols that cannot be displayed with the current language settings" appears.

• Cause. Internet Explorer shows an encoded Web address to avoid possible spoofing, if the domain name contains characters not used by the user's list of preferred content languages. A domain name will be displayed in encoded form if any of the following are true:

  • The domain name contains characters outside of the user's chosen languages, except for ASCII-only labels, which are always permitted for compatibility with existing sites.

  • The domain name contains characters that are not part of any language.

  • Any one of the labels contains a mix of scripts that do not appear together within a single language. For instance, Greek characters cannot mix with Cyrillic in a single label.

• Workaround. Verify that your domain name does not contain characters from multiple languages within a single label. If you need to use multiple languages, use one label per language. In addition, you must ensure that you write the domain name, by using characters from the language that your destination audience is most likely to have configured in their browser. Many Web site owners choose to use IDN domain names as redirects to ASCII-based domain names. ASCII URLs are accessible in all browser versions, and such domain names do not show an Information Bar in any locale.

• Symptom. When you use scripting methods to retrieve the URL properties for your DHTML objects, the URL unexpectedly returns as Unicode.

• Cause. URL properties might be converted into Unicode form when assigned to object model properties. This is relevant if your code attempts to perform comparisons between URL strings and strings elsewhere in the script code.

• Workaround. Ensure that you write robust URL handling routines to handle the differences in domain-name encoding. In particular, verify that you use Unicode rather than Punycode when comparing JScript strings to URLs. Make sure that you test your scripts with all of the expected combinations of browser languages to ensure that you did not write your URL-handling code based on incorrect assumptions.

IDN Compatibility Impact for Application Developers

Application developers might experience the compatibility impact of IDN support in the following ways:

• Symptom. If you develop an application that uses WININET to connect to a Web site where the domain name contains Unicode characters, the networking component might fail to connect to the site.

• Cause. Previous versions of WININET represented intranet domain names with non-ASCII characters in a different URL format. Some environments might not yet support the new IDN Punycode standard, so some sites might not be reachable, by using the IDN Punycode address format.

• Workaround. You must configure IDN by using the InternetSetOption function before making an HTTP request. Additionally, you must set the dwIDNSettings registry key based on the following:

  • 0: Punycode is never used.

  • 1: Punycode is used when communicating directly with origin servers.

  • 2: Punycode is used when communicating with a proxy server.

  • 3 (default): Punycode is used when communicating with both origin and proxy servers.

• Symptom. If you use code to retrieve the URL properties for DHTML objects, the URL can be unexpectedly returned in Punycode or Unicode, depending on the user's settings.

• Cause. URL properties might be converted into Punycode or Unicode form when assigned to object model properties. This is particularly relevant if your code attempts to perform comparisons between URL strings and strings elsewhere in the code.

• Workaround. Ensure that you write robust URL-handling routines to handle the differences in domain-name encoding. In particular, verify that you use Unicode rather than Punycode when comparing strings to URLs. Make sure that you test your code with all of the expected combinations of browser languages to validate that you did not write your URL-handling code based on incorrect assumptions. When writing native-code applications, use the IURI API to parse the URL components.

IDN Support Advantages

The following sections discuss how the user, the network administrator, the Web site developer, and the application developer can take advantage of IDN support.

User

Users can now navigate to any IDN site that is written with Unicode characters from most of the world's languages.

Network Administrator

If users do not need to navigate to IDN sites, you can force all IDN Web addresses to appear in encoded form by setting the HKLM or HKCU \Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ShowPunycode DWORD registry key to 1, or you can manually set the Always show encoded addresses option located in the Advanced tab of the Internet Control Panel on each user's computer. When you select this option, all IDN Web addresses will automatically appear in encoded form.

Web Site Developer

Formatting your IDN names in Punycode ensures that users of Internet Explorer, prior to Windows Internet Explorer 7, can navigate to your sites. In Internet Explorer 7 and Internet Explorer 8, your links will appear in Unicode if your user's configured display language permits the characters

Application Developer

In addition to Internet Explorer's support for IDN, you can take advantage of other IDN resources available on MSDN®.

See Also

Concepts

Known Internet Explorer Security Feature Issues