Event 1032 - Internationalized Domain Names (IDN) Support
- Logged Message
- What Is It?
- When Is This Event Logged?
- Example
- Remediation
- IDN Compatibility Impact for Network Administrators
- IDN Compatibility Impact for Website Developers
- Windows Internet Explorer and Allowable IDN Addresses
- IDN Compatibility Impact for Application Developers
- IDN Support Advantages
- Related topics
Logged Message
Windows Internet Explorer 8 and Windows Internet Explorer 7 permit navigation to Internationalized Domain Name (IDN). IDN relies upon a standardized mechanism known as "punycode" for encoding Unicode domain names, using only the ASCII characters permitted by global Domain Name System (DNS). Windows Internet Explorer helps mitigate possible spoofing attacks posed by Unicode look-alike characters by rendering some existing IDN names in the encoded format. This change has implications for URL compatibility in previous versions, since earlier versions of Internet Explorer encoded domain names in different formats (such as ANSI and 8-bit Unicode Transformation Format (UTF-8)).
What Is It?
A domain name is considered an IDN when it contains Unicode characters whose code is higher than 0x007E ('~'). IDNs use a mechanism for encoding Unicode domain names using only ASCII characters permitted by the global DNS system. The idea is to encode international domain names that might look similar to their valid ASCII counterparts but are actually used by a malicious attacker to spoof valid domain names. The encoded form of the domain name is relatively easy to spot by a user, cueing them that they are not visiting the domain they intended.
For further details on IDNs please refer to RFC 3490.
When Is This Event Logged?
This event is logged when Internet Explorer encounters an IDN.
Example
Perform the following steps to see this event logged in the compatibility tool:
- Open Internet Explorer and enter the URL: http://www.café.com?
The URL is rendered in punycode format and the IDN event is logged.
Remediation
End users of Internet Explorer might experience the compatibility impact of IDN support.
Symptom: When browsing the Internet, a punycode-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.
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.
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 URLreplaces the letter L with the number 1. With IDN, the character set expands from a few dozen characters to many thousands of characters from all 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. Mixing character sets within a host name (for instance, "contos?.com") where the second "o" is "?" (Cyrillic Unicode 0x043E), are generally not allowed regardless of language settings. See the section Internet Explorer and Allowable IDN Addresses below.
Note 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 following registry key to 1:
HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\DisableIDNPrompt DWORD
Symptom: When navigating to an intranet website 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:
- On the Tools menu, click Internet Options, and then click the Advanced tab.
- Scroll down to the International section, and then clear the check box for Send IDN server names
-OR-
Open the Registry Editor and change:
HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\EnablePunycode DWORD
To one of the following Values
| Value | Effect |
| 0 | Punycode is never used. |
| 1 | Punycode is used when talking directly to origin servers. |
| 2 | Punycode is used when talking to a proxy server. |
| 3 (default) | Punycode is used when talking to both origin and proxy servers. |
This feature can also be controlled by the following Group Policy settings:
| GPO Policy Path | GPO Policy Setting Name | GPO Settings |
|---|---|---|
| Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel | Send internationalized domain names | If you enable this policy setting, you must specify when IDN server names should be sent: 0) Unicode domain names will never be converted to IDN format; 1) Unicode domain names will be converted to IDN format only for addresses that are not in the Intranet Zone; 2) Unicode domain names will be converted to IDN format only for addresses in the Intranet Zone; and 3) Unicode domain names always be converted to IDN format If you disable or do not configure this policy setting, the user can control this setting by using the Advanced Options in Internet Control Panel. By default, domain names will be converted to IDN format only for addresses that are not in the Intranet Zone. |
IDN Compatibility Impact for Website Developers
Website 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.
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 all of the world's languages, thereby increasing the risk of spoofing attack.
Windows Internet Explorer and Allowable IDN Addresses
Internet Explorer includes a number of restrictions on allowable IDN addresses in order to protect the user from spoofing attacks including:
A domain name is 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.
- o 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: Ensure 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.
Note A label is a segment of a domain name, delimited by periods (.). For example, www.microsoft.com contains three labels, "www", "microsoft", and "com".
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 website owners choose to use IDN domain names as redirects to ASCII-based domain names. ASCIIURLs are reachable in all browser versions, and such domain names do not show an Information Bar in any locale.
Symptom: If you use scripting to retrieve the URL properties for Dynamic HTML (DHTML) objects, the URL can be unexpectedly returned as Unicode.
Cause: URL properties might be converted into 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 script code.
Workaround: Ensure that you write robust URL handling routines to handle the differences in domain name encoding. In particular, ensure that you use Unicode rather than Punycode when comparing Microsoft 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 Microsoft Win32 Internet (WinInet) to connect to a website 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: To work around this issue, you must configure IDN 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 talking directly to origin servers. 2: Punycode is used when talking to a proxy server. 3 (default): Punycode is used when talking to 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, ensure 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 ensure 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 end user, the network administrator, the website developer, and the application developer can take advantage of IDN support.
End User:
End users can take advantage of IDN support in Internet Explorer because it now permits navigation to IDN sites written with Unicode characters from all of the world's languages.
Network Administrator:
If your 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-
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 appear in encoded form.
Website Developer:
Formatting your IDN names in Punycode ensures that users of Internet Explorer prior to Internet Explorer 7 can navigate to your sites. In 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 support forIDN, you can take advantage of other IDN resources available on MSDN.