Annex 10. IAB recommendations and considerations
From IUCG - Internet Users Contributing Group
Taking into account the issues above, it would seem inappropriate for an application to convert a name to Punycode when it does not know whether DNS will be used by the name resolution library, or whether the name exists in a private name space that uses UTF-8, or in the global DNS that uses Punycode.
Instead, conversion to Punycode, UTF-8, or whatever other encoding, should be done only by an entity that knows which protocol will be used (e.g., the DNS resolver, or getaddrinfo upon deciding to pass the name to DNS), rather than by general applications that call protocol-independent name resolution APIs. Similarly, even when DNS is used, the conversion to Punycode should be done only by an entity that knows which name space will be used.
That is, a more intelligent DNS resolver would be more liberal inept from an application and be able to query for both a Punycode name (e.g., over the Internet) and a UTF-8 name (e.g., over a corporate network with a private name space) in case the server only recognized one. However, we might also take into account that the various resolution behaviors discussed earlier could also occur with record updates (e.g., with Dynamic Update [RFC2136]), resulting in some names being registered in a local network's private name space by applications doing Punycode conversion, and other names being registered using UTF-8. Hence a name might have to be queried with both encodings to be sure to succeed without changes to DNS servers.
Similarly, a more intelligent stub resolver would also be more liberal in what it would accept from a response as the value of a record (e.g., PTR) in that it would accept either UTF-8 or Punycode and convert them to whatever encoding is used by the application APIs to return strings to applications.
Indeed the choice of conversion within the resolver libraries is consistent with the quote from [RFC3490] section 6.2 stating that Punycode conversion "might be performed inside these new versions of the resolver libraries".
That said, some application-layer protocols may be defined to use Punycode rather than UTF-8 as recommended by [RFC2277]. In this case, an application may receive a Punycode name and want to pass it to name resolution APIs. Again the recommendation is that a resolver library be more liberal in what it would accept from an application would mean that such a name would be accepted and re-encoded as needed, rather than requiring the application to do so.
Finally, the question remains about what a DNS server should do to handle cases where some existing applications or hosts do Punycode queries within the local network using a private name space, and other existing applications or hosts send UTF-8 queries. It is undesirable to store different records for different encodings of the same name, since this introduces the possibility for inconsistency between them. Instead, a new DNS server could treat encoding- conversion in the same way as case-insensitive comparison which a DNS server is already required to do. Two encodings are, in this sense, two representations of the same name, just as two case-different strings are. However, whereas case comparison of non-ASCII characters is complicated by ambiguities (see [RFC4690]), encoding conversion between Punycode and UTF-8 is unambiguous.
Normalization/mapping issues
[EDITOR'S NOTE: There are also normalization/mapping issues which the next version of this document may explore. Currently we only explore encoding issues.]
Security Considerations
Having applications convert names to Punycode before calling name resolution can result in security vulnerabilities. If the name is resolved by protocols or in zones for which records are registered using other encoding schemes, an attacker can claim the Punycode version of the same name and hence trick the victim into accessing a different destination. This can be done for any non-ASCII name, even when there is no possible confusion due to case, language, or other issues. Other types of confusion beyond those resulting simply from the choice of encoding scheme are discussed in [RFC4690].
