Applications normally use functions in the operating system when they resolve DNS queries. Those functions in the operating system are often called "the resolver library", and the applications communicate with the resolver libraries through a programming interface (API).

It is inappropriate for an application that calls a general-purpose

name resolution library to convert a name to an A-label unless the

application is absolutely certain that, in all environments where the

application might be used, only the global DNS that uses IDNA

A-labels actually will be used to resolve the name.

Instead, conversion to A-label form, or any other special encoding

required by a particular name-lookup protocol, 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. (Of course, applications that store strings

internally in a different format than that required by those APIs,

need to convert strings from their own internal format to the format

required by the API.) Similarly, even if an application can know

that DNS is to be used, the conversion to A-labels should be done

only by an entity that knows which part of the DNS namespace will be

used.

That is, a more intelligent DNS resolver would be more liberal in

what it would accept from an application and be able to query for

both a name in A-label form (e.g., over the Internet) and a UTF-8

name (e.g., over a corporate network with a private namespace) in

case the server only recognizes 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 namespace by applications doing conversion to

A-labels, 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 (U-labels in

the case of IDNA) or A-labels and convert them to whatever encoding

is used by the application APIs to return strings to applications.

3. Name Resolution APIs and Libraries: Resolvers MUST either respond

to requests for .onion names by resolving them according to

[tor-rendezvous] or by responding with NXDOMAIN [RFC1035].

When the realm portion of the NAI is used as the basis for name

resolution, it may be necessary to convert internationalized realm

names to Punycode [RFC3492] encoding form as described in [RFC5891].

As noted in Section 2 of [RFC6055], resolver Application Programming

Interfaces (APIs) are not necessarily DNS specific, so conversion to

Punycode needs to be done carefully:

Applications that convert an IDN to A-label form before calling (for

example) getaddrinfo() will result in name resolution failures if the

Punycode name is directly used in such protocols. Having libraries

or protocols to convert from A-labels to the encoding scheme defined

by the protocol (e.g., UTF-8) would require changes to APIs and/or

servers, which Internationalized Domain Names for Applications (IDNA)

was intended to avoid.

As a result, applications SHOULD NOT assume that non-ASCII names are

resolvable using the public DNS and blindly convert them to A-labels

without knowledge of what protocol will be selected by the name

resolution library.

We're planning to integrate a DNS resolver into Gecko. Our primary motivation is performance, but we're also interested in a number of new security features such as DNSSEC.

When the IDN setting is set to “None”, no conversions are performed by Uri.Host or Uri.DnsSafeHost. When the IDN setting is set to “All”, uri.Host remains Unicode and uri.DnsSafeHost is converted to Punycode. When the IDN setting is set to “AllExceptIntranet”, uri.DnsSafeHost is converted to Punycode for internet addresses, and remains Unicode for intranet addresses. This setting is important for correct DNS name resolution.