Transparent Handling of Internationalized Domain Names in Name Resolution APIs
draft-rodenhaeuser-idna-transparent-resolution-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Luca Rodenhäuser | ||
| Last updated | 2026-07-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rodenhaeuser-idna-transparent-resolution-00
Network Working Group L. Rodenhäuser
Internet-Draft 18 July 2026
Intended status: Best Current Practice
Expires: 19 January 2027
Transparent Handling of Internationalized Domain Names in Name
Resolution APIs
draft-rodenhaeuser-idna-transparent-resolution-00
Abstract
Applications are expected to convert internationalized domain names
to their ASCII-Compatible Encoding (A-label) form before invoking
name resolution APIs. In practice this conversion is performed
inconsistently: different applications follow different IDNA
standards, use different libraries, and ship different versions of
the Unicode mapping tables, so that the same input string can resolve
to different registrable domain names depending on which software
component performs the conversion.
This document specifies that name resolution services accept Unicode
host names by default and perform the conversion to A-labels
internally, exactly once, at the point where a name is handed to a
specific resolution protocol. The DNS wire format is unchanged: only
A-labels appear in queries to the public DNS. The conversion
procedure is Unicode IDNA Compatibility Processing (UTS #46),
nontransitional, with a mapping-table floor of Unicode 15.1. This
codifies the architectural recommendation of RFC 6055 and the
deployed practice of several major platforms.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document is encouraged on the IETF DISPATCH
working group mailing list (dispatch@ietf.org); DNS-specific aspects
may also be raised on the DNSOP working group list (dnsop@ietf.org).
Comments may also be sent directly to the author.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Rodenhaeuser Expires 19 January 2027 [Page 1]
Internet-Draft Transparent IDN Resolution July 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Behavioral Requirements, Not API Signatures . . . . . . . 6
4.2. The Wire Format Remains A-Labels . . . . . . . . . . . . 6
4.3. A Single Conversion Procedure . . . . . . . . . . . . . . 6
4.3.1. Table Version . . . . . . . . . . . . . . . . . . . . 7
4.4. Late Conversion . . . . . . . . . . . . . . . . . . . . . 8
5. Processing Requirements . . . . . . . . . . . . . . . . . . . 8
5.1. ASCII Fast Path . . . . . . . . . . . . . . . . . . . . . 8
5.2. Byte-Oriented Interfaces . . . . . . . . . . . . . . . . 9
5.3. Unicode-Native Interfaces . . . . . . . . . . . . . . . . 9
5.4. Conversion . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Length Limits and Root-Label Semantics . . . . . . . . . 9
5.6. Search Lists . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Failure Handling . . . . . . . . . . . . . . . . . . . . 10
5.8. Default Activation and Opt-Out . . . . . . . . . . . . . 10
5.9. Access to the Converted Form . . . . . . . . . . . . . . 10
Rodenhaeuser Expires 19 January 2027 [Page 2]
Internet-Draft Transparent IDN Resolution July 2026
6. Non-DNS Name Services and Private Namespaces . . . . . . . . 11
6.1. Multicast DNS and LLMNR . . . . . . . . . . . . . . . . . 11
6.2. Hosts File . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Private DNS Namespaces Using UTF-8 . . . . . . . . . . . 11
7. Error Reporting . . . . . . . . . . . . . . . . . . . . . . . 12
8. Migration and Backward Compatibility . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Table-Version Skew . . . . . . . . . . . . . . . . . . . 13
9.2. Divergence between Components . . . . . . . . . . . . . . 13
9.3. Residual Asymmetries . . . . . . . . . . . . . . . . . . 13
9.4. Changed Attack Surface of Default Activation . . . . . . 14
9.5. No New Wire Exposure . . . . . . . . . . . . . . . . . . 14
9.6. Pass-Through of Non-UTF-8 Input . . . . . . . . . . . . . 14
9.7. Application-Side Pre-Conversion . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Survey of Existing Implementations . . . . . . . . . 17
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The Domain Name System carries internationalized labels in an ASCII-
Compatible Encoding: U-labels are converted to A-labels [RFC5890]
before they appear in DNS queries. IDNA deliberately placed this
conversion inside applications so that existing APIs and servers
could remain unchanged [RFC3490]. Fifteen years of deployment
experience show the cost of that choice: every application converts
for itself, and no two convert alike.
Rodenhaeuser Expires 19 January 2027 [Page 3]
Internet-Draft Transparent IDN Resolution July 2026
The resulting divergence is observable on three levels. On the
standards level, widely used runtime facilities still implement
IDNA2003 (for example the java.net.IDN class and Python's built-in
"idna" codec) while other components implement IDNA2008 with UTS #46
mapping [UTS46]. On the library level, a single portable program may
use a different conversion backend on every platform it supports. On
the table-version level, even components that agree on UTS #46
nontransitional processing disagree when their copies of the Unicode
mapping table differ in age: at the time of writing, the input
"STRAẞE.de" is converted to "strasse.de" by implementations shipping
tables older than Unicode 15.1 and to "xn--strae-oqa.de" by
implementations with current tables -- two independently registrable
domain names from one input string, on one host, depending on which
library is asked. The divergence even crosses layers within a single
runtime and a single vendor; Appendix A records the observed state of
common implementations.
The consequences are not merely cosmetic. When a security filter
canonicalizes a name differently from the resolver that later looks
it up, the filter examines one domain and the network connects to
another. When two applications on the same system convert
differently, the same user input reaches different destinations.
This document specifies the remedy that the IAB recommended in 2011:
[RFC6055] concludes that it is inappropriate for applications calling
general-purpose name resolution APIs to convert names to A-labels
themselves, and that the conversion should instead be performed by
the entity that knows which resolution protocol will be used -- the
resolver, at the moment it decides to hand the name to the DNS. The
candidate mappings at the time included the local mapping of
[RFC5895] and both modes of UTS #46, and no single choice could yet
be recommended. The original IDNA specification anticipated the same
evolution, expecting that future resolver libraries would accept
domain names in non-ASCII form and perform the ToASCII operation
internally [RFC3490]. What RFC 6055 could not settle at the time --
which of the competing mappings the resolver should apply -- has
since been settled elsewhere: Unicode deprecated transitional
processing, declared the industry transition to IDNA2008 behavior
complete, and in Unicode 15.1 aligned the mapping of capital sharp s
with nontransitional expectations [UTS46].
Accordingly, this document requires that name resolution services
accept Unicode input by default, without any opt-in flag or
attribute; that they convert it with a single, versioned procedure
(Section 4.3); that the conversion happens exactly once, at the
protocol boundary (Section 4.4); and that nothing changes on the wire
(Section 4.2).
Rodenhaeuser Expires 19 January 2027 [Page 4]
Internet-Draft Transparent IDN Resolution July 2026
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Name resolution service
Any interface that accepts a host name as a character or byte
string and resolves it using one or more name resolution
protocols, of which the DNS is typically one. This includes C
library stub resolver entry points such as getaddrinfo()
[RFC3493], operating system name resolution services, resolvers
embedded in language runtimes, and high-level lookup functions of
DNS libraries. It does not include interfaces that accept names
already in DNS wire format (Section 3).
Conversion point
The place within a name resolution service at which a name is
transformed into the encoding required by one specific resolution
protocol.
Table version
The version of the Unicode IdnaMappingTable (and associated
derived data) from which an implementation's UTS #46 processing is
generated.
U-label, A-label
As defined in [RFC5890]; A-labels carry a Punycode-encoded
[RFC3492] form of the label.
3. Scope and Non-Goals
This document applies to name resolution services as defined above:
entry points that accept host names as text. Interfaces that operate
on names already in DNS wire format (for example res_mkquery()-level
APIs) are out of scope; callers of such interfaces have already
chosen an encoding.
This document does not change the DNS wire format, and it
deliberately does not define any negotiation mechanism for carrying
Unicode names on the wire; the obstacles to such a mechanism, DNSSEC
canonicalization first among them (Section 4.2), are outside its
scope. It does not constrain registry or registration policy (for
which see [RFC5891]), does not specify the display direction
Rodenhaeuser Expires 19 January 2027 [Page 5]
Internet-Draft Transparent IDN Resolution July 2026
(conversion of A-labels to U-labels for presentation), does not
modify URL or IRI processing (see [WHATWG-URL]), and does not address
internationalized email.
The requirement keywords of this document define conformance to the
practice it specifies. They impose no obligation on implementations
that do not claim conformance, and they render no existing
implementation invalid with respect to any other specification; in
particular, conformance to this document is orthogonal to conformance
to interface standards such as POSIX.
4. Architecture
4.1. Behavioral Requirements, Not API Signatures
This document states requirements on the observable behavior of name
resolution services. It does not define function signatures, flag
constants, or other language- or platform-specific interface details,
which belong to the respective interface specifications (for POSIX,
the Austin Group). Appendix A maps the requirements onto existing
interfaces informatively.
4.2. The Wire Format Remains A-Labels
Queries sent to the public DNS carry A-labels, exactly as today.
Several properties of the deployed DNS depend on names being ASCII at
the protocol layer: the DNSSEC canonical form is defined in terms of
ASCII case folding only [RFC4034]; caches, case-randomizing
resolvers, and middleboxes compare and copy names under the same
assumption; and the entire registration ecosystem provisions
A-labels. While the DNS protocol itself places no restriction on the
octets in a label [RFC2181], and UTF-8 labels do occur in private
namespaces (Section 6.3), changing the encoding used in the public
tree is a separate and much larger problem than the one this document
solves.
4.3. A Single Conversion Procedure
Implementations MUST convert names using Unicode IDNA Compatibility
Processing [UTS46], conforming to conformance clause C2
(nontransitional processing), with the ToASCII operation
parameterized as follows:
Rodenhaeuser Expires 19 January 2027 [Page 6]
Internet-Draft Transparent IDN Resolution July 2026
+=========================+=========================+
| Parameter | Value |
+=========================+=========================+
| UseSTD3ASCIIRules | false |
+-------------------------+-------------------------+
| CheckHyphens | false |
+-------------------------+-------------------------+
| CheckBidi | true |
+-------------------------+-------------------------+
| CheckJoiners | true |
+-------------------------+-------------------------+
| Transitional_Processing | false |
+-------------------------+-------------------------+
| VerifyDnsLength | false (see Section 5.5) |
+-------------------------+-------------------------+
| IgnoreInvalidPunycode | false |
+-------------------------+-------------------------+
Table 1: UTS #46 ToASCII Profile
Transitional processing (conformance clause C1) is deprecated by
Unicode and MUST NOT be used, in any mode, including as a fallback
for input that fails nontransitional processing.
UseSTD3ASCIIRules is false because names containing underscores, such
as service and policy labels of the form "_sip._tcp", must remain
resolvable. CheckHyphens is false because labels such as those
beginning with "r3---" occur in deployed DNS content and must remain
resolvable. CheckBidi preserves conformance with the Bidi rule
[RFC5893], and CheckJoiners preserves the contextual rules for joiner
characters. This parameter set is identical to the one used by the
WHATWG URL Standard's domain-to-ASCII operation [WHATWG-URL]; a
resolver conforming to this document therefore derives the same
A-labels as the browsers running above it.
Callers are not required to normalize their input: UTS #46 processing
itself maps and normalizes to NFC, so input in NFD or mixed
normalization forms is acceptable.
4.3.1. Table Version
Implementations MUST use mapping and validity data derived from
Unicode version 15.1 or later, and SHOULD track the current Unicode
version, following the review process established for IDNA in
[RFC8753].
Rodenhaeuser Expires 19 January 2027 [Page 7]
Internet-Draft Transparent IDN Resolution July 2026
The floor of 15.1 is not arbitrary. Unicode 15.1 is the version in
which, as an explicit exception to the otherwise-guaranteed backward
compatibility of the mapping table, the mapping of U+1E9E (LATIN
CAPITAL LETTER SHARP S, "ẞ") was changed from "ss" to U+00DF (LATIN
SMALL LETTER SHARP S, "ß"), which nontransitional processing treats
as valid [UTS46]. Under older tables, the uppercase and lowercase
spellings of the same word convert to two different registrable
domain names (Section 9.1). A floor below 15.1 would perpetuate
exactly the divergence this document exists to remove.
4.4. Late Conversion
Conversion happens at the conversion point of each resolution
protocol, not at the API boundary. Name resolution services are
protocol-independent: the same call may be satisfied by the DNS, by
Multicast DNS [RFC6762], by LLMNR [RFC4795], by a hosts file, or by
other mechanisms, and these protocols do not share an encoding.
Multicast DNS, for example, uses UTF-8 on the wire. A name converted
to A-labels at the API boundary would therefore be wrong for some
backends; a name converted at each protocol boundary is right for all
of them. This is the architecture recommended by [RFC6055] and
implemented, for example, by systemd-resolved, which prepares both an
IDNA form and a UTF-8 form of each question and lets the backend
select the appropriate one.
5. Processing Requirements
5.1. ASCII Fast Path
If the input consists entirely of ASCII characters -- including input
that already contains A-labels -- the service MUST NOT apply any IDNA
processing to it. Behavior for such input remains octet-for-octet
identical to the behavior of a service not implementing this
document.
This rule makes the conversion idempotent and protects the two
largest classes of existing callers: applications that only ever
resolve ASCII names, and applications that perform their own
conversion and pass A-labels. Neither can observe any change. It
also preserves the ability to resolve ASCII labels that merely
resemble A-labels: names beginning with "xn--" are passed through
without validation or re-mapping, as they are today.
Rodenhaeuser Expires 19 January 2027 [Page 8]
Internet-Draft Transparent IDN Resolution July 2026
5.2. Byte-Oriented Interfaces
For interfaces that accept names as byte strings: if the input
contains at least one non-ASCII octet and is valid UTF-8, the service
MUST process it as described in Section 5.4. UTF-8 validity is as
defined in [RFC3629], which excludes surrogates and overlong forms.
If the input contains non-ASCII octets but is not valid UTF-8, the
service SHOULD pass it to the resolution protocol unchanged,
preserving the historical eight-bit transparency of the DNS
[RFC2181]; it MAY instead provide a configuration under which such
input is rejected with an error (Section 7).
5.3. Unicode-Native Interfaces
For interfaces that accept names as Unicode strings (for example
UTF-16 string types), any input containing non-ASCII characters MUST
be processed as described in Section 5.4. No byte-level heuristic is
needed or permitted.
5.4. Conversion
Input selected by Section 5.2 or Section 5.3 MUST be converted by
applying the ToASCII operation with the profile of Section 4.3 to the
whole domain name. The mapping step of UTS #46 itself handles the
ideographic and fullwidth label separators (U+3002, U+FF0E, U+FF61),
so no separate pre-processing of dots is required. The conversion is
performed exactly once, at the conversion point of the protocol that
will carry the query (Section 4.4).
5.5. Length Limits and Root-Label Semantics
After conversion, the service MUST verify the DNS length limits on
the converted form: at most 63 octets per label and at most 255
octets for the name in wire format [RFC1035]. A single trailing dot
denotes the root label and MUST retain its conventional meaning of
marking the name fully qualified and suppressing search-list
processing. This is why the profile in Section 4.3 sets
VerifyDnsLength to false: with that flag enabled, UTS #46 would
reject the empty root label, whereas with it disabled the empty root
label passes through and the service applies its own checks with the
correct semantics. Interior empty labels are invalid and MUST be
rejected; only the single trailing empty label denoting the root is
permitted. Where search-list expansion applies (Section 5.6), the
limits are verified for each candidate name actually queried.
Rodenhaeuser Expires 19 January 2027 [Page 9]
Internet-Draft Transparent IDN Resolution July 2026
5.6. Search Lists
The service MUST convert the caller-supplied name before performing
search-list expansion. Configured search domains may themselves
contain non-ASCII characters; they MUST be converted with the same
procedure when the configuration is loaded, so that expansion
concatenates A-label forms -- except where a search domain belongs to
a private namespace configured as described in Section 6.3, in which
case the form appropriate to that namespace is used. Note that
[RFC6055] documents deployments in which suffix search lists contain
UTF-8.
5.7. Failure Handling
If mapping or validation of input on the IDNA path fails, the service
MUST report an error that is distinguishable from a resolution
failure such as "name not found" (Section 7). Input that was
recognized as Unicode MUST NOT be sent to the public DNS in
unconverted form, and partial conversions MUST NOT be used: a name is
converted completely or the call fails. The pass-through behavior of
Section 5.2 applies exclusively to input that is not valid UTF-8.
5.8. Default Activation and Opt-Out
Acceptance and conversion of Unicode input MUST be the default
behavior of the service and MUST NOT require any per-call flag,
option, attribute, or prior configuration.
Implementations MUST provide a mechanism to disable the conversion --
per call, per process, or per system -- for compatibility and
diagnostic purposes. An existing example of such a mechanism is the
AI_DISABLE_IDN_ENCODING flag of the Windows getaddrinfo() family.
5.9. Access to the Converted Form
The service SHOULD make the converted (A-label) form of the queried
name available to the caller, for example through the mechanism used
to return canonical names or through another interface-specific
channel where that mechanism already carries DNS-derived names.
Protocol elements above the resolver -- TLS Server Name Indication
[RFC6066], HTTP Host headers, and certificate identity verification
[RFC9525] -- operate on A-labels; a caller that only holds the
U-label form is forced to repeat the conversion itself, reintroducing
the very divergence this document removes.
Rodenhaeuser Expires 19 January 2027 [Page 10]
Internet-Draft Transparent IDN Resolution July 2026
Names returned by the DNS (for example CNAME chains and PTR targets)
remain in A-label form. Conversion of results to U-labels for
display MUST be available only on explicit request of the caller;
presentation of internationalized names, and its associated spoofing
concerns, are outside the scope of this document.
6. Non-DNS Name Services and Private Namespaces
6.1. Multicast DNS and LLMNR
Names sent over Multicast DNS MUST be carried in the UTF-8 form
specified by [RFC6762], not as A-labels. The same applies to LLMNR
[RFC4795]. The conversion point for these protocols therefore
performs no ToASCII operation; the late-conversion architecture of
Section 4.4 is what makes this correct.
6.2. Hosts File
Entries in a hosts file may be written as U-labels or as A-labels.
When matching a looked-up name against hosts file entries, the
service SHOULD apply the conversion procedure of Section 4.3 to both
sides and compare the results, so that either spelling of an entry
matches either spelling of a query. If conversion of an entry or of
the queried name fails, that side is matched by direct comparison of
its UTF-8 form.
6.3. Private DNS Namespaces Using UTF-8
[RFC6055] documents a long-established practice of provisioning UTF-8
names in private DNS namespaces, particularly in enterprise
environments, and recommends that resolvers be liberal enough to
reach names in such namespaces. This document accommodates that
practice without weakening the public case: queries sent to the
public DNS MUST carry A-labels; for zones or network scopes that are
explicitly configured as private UTF-8 namespaces, an implementation
MAY send the UTF-8 form of a name in addition to, or instead of, the
A-label form. Such behavior MUST be bound to the configured scope
and MUST NOT be a global default. Note that DNS servers do not case-
fold non-ASCII octets [RFC4343]; names in such namespaces match bit-
for-bit, and provisioning conventions need to account for this.
Rodenhaeuser Expires 19 January 2027 [Page 11]
Internet-Draft Transparent IDN Resolution July 2026
7. Error Reporting
Services distinguish at least the following failure classes on the
IDNA path: mapping failures (input containing disallowed code
points), validation failures (violations of the Bidi rule, the joiner
context rules, or Punycode validity inside a mixed name), length
failures (Section 5.5), and -- where the strict mode of Section 5.2
is enabled -- invalid UTF-8.
Errors of these classes MUST be reported through a code or condition
distinct from resolution failures, so that callers can tell "this
name cannot be encoded" apart from "this name does not exist". An
existing example is the EAI_IDN_ENCODE error of the GNU C library.
Diagnostics SHOULD identify the offending label and, where possible,
the offending code point position.
8. Migration and Backward Compatibility
Existing callers fall into three classes. Applications that only
resolve ASCII names are untouched by construction (Section 5.1).
Applications that perform their own IDNA conversion hand ASCII to the
service and are equally untouched; no double conversion can occur,
since Punycode input is never re-mapped. Applications that
deliberately pass raw non-ASCII octets -- a small class, chiefly in
private-namespace environments -- are served by the UTF-8 pass-
through of Section 5.2, by Section 6.3, and by the opt-out of
Section 5.8.
Applications need not change to benefit, and need not wait to be
safe: an application that continues to convert names itself remains
correct indefinitely, because its A-label output takes the ASCII fast
path unchanged (Section 5.1). Until an application can rely on the
services it uses conforming to this document, continuing to pre-
convert is the prudent choice; the aim of this document is to make
that burden unnecessary, not to forbid carrying it.
Default-on conversion is not an experiment. The Windows resolver has
converted by default since Windows 8 with an opt-out flag, across
more than a decade of deployment, without ecosystem breakage -- even
though, as Appendix A records, the procedure behind that default is
today the part most in need of the present specification. The musl C
library, which currently performs no IDN conversion, states as
project policy that support, when added, will always be enabled
rather than requiring application flags; this document supplies the
specification such an implementation needs.
Rodenhaeuser Expires 19 January 2027 [Page 12]
Internet-Draft Transparent IDN Resolution July 2026
For implementations, the migration is incremental: a libc that today
offers opt-in conversion makes that behavior the default, turns the
opt-in flag into a no-op, adds an opt-out, and updates its mapping
tables to meet the floor of Section 4.3.1; a runtime whose HTTP layer
already converts extends the same procedure to its socket-level
lookups. Interface-level details for POSIX getaddrinfo() are a
matter for the Austin Group and are sketched informatively in
Appendix A.
9. Security Considerations
9.1. Table-Version Skew
Until the floor of Section 4.3.1 is universally met, implementations
with pre-15.1 tables convert "STRAẞE.de" to "strasse.de" while
implementations with current tables convert it to "xn--strae-oqa.de".
These are independently registrable domains: the operator of the .de
registry admitted the letter "ß" on 16 November 2010 after a one-time
sunrise phase for holders of the corresponding "ss" domains, and
applies its ordinary first-come-first-served rules since -- there is
no bundling requirement, and the registry itself noted at
introduction time that software following the older standard would
lead users entering "ß" to the "ss" domain, which need not belong to
the same holder [DENIC2010]. An attacker who controls the name
produced by the older tables receives the traffic of every client on
the wrong side of the skew. The table-version floor exists to shrink
this window; until it closes, operators of names containing
deviation-adjacent characters should consider holding both spellings.
9.2. Divergence between Components
Security decisions that compare domain names -- allowlists,
blocklists, SSRF protections, pinning, access control -- are only
sound if the comparing component and the resolving component
canonicalize identically. Such comparisons SHOULD be performed on
the A-label form produced by the procedure of Section 4.3;
Section 5.9 exists to make that form available. Logs SHOULD record
both the input form and the converted form of resolved names.
9.3. Residual Asymmetries
The conversion is deliberately context-free, and some case
asymmetries therefore remain: the Greek capital sigma always maps to
U+03C3, while a final lowercase sigma (U+03C2) is valid as written,
so the uppercase and lowercase spellings of a Greek word ending in
sigma still convert to different labels. This document does not and
cannot repair that; it only guarantees that every component disagrees
in the same way. Visual confusability between distinct code points
Rodenhaeuser Expires 19 January 2027 [Page 13]
Internet-Draft Transparent IDN Resolution July 2026
(homoglyphs) is likewise out of scope; see UTS #39 [UTS39] and the
registry-side recommendations of [RFC5891].
9.4. Changed Attack Surface of Default Activation
Applications that implicitly relied on non-ASCII input never
resolving -- using the resolver's previous behavior as an accidental
input filter -- lose that property under this document. Such
applications should validate input explicitly and may use the opt-out
of Section 5.8 during transition.
9.5. No New Wire Exposure
Because the wire format is unchanged (Section 4.2), this document
introduces no new interactions with DNSSEC validation, caching, or
on-path devices.
9.6. Pass-Through of Non-UTF-8 Input
The pass-through behavior of Section 5.2 preserves compatibility with
eight-bit legacy deployments, but it is itself a canonicalization
boundary: a component that leniently decodes malformed input as
Unicode will canonicalize a byte sequence that the resolver forwards
untouched, recreating the divergence of Section 9.2 at the encoding
layer. Deployments in security-sensitive contexts SHOULD enable the
strict rejection mode of Section 5.2, and comparing components SHOULD
NOT apply lenient decoding to input that the resolver treats as
opaque bytes.
9.7. Application-Side Pre-Conversion
The status quo is itself a documented vulnerability: [RFC6055]
observes that applications converting to A-labels before calling
protocol-independent resolution APIs can be directed to attacker-
controlled destinations wherever a namespace uses a different
encoding, because the attacker can register the A-label spelling of a
name whose canonical form in that namespace is UTF-8. By moving
conversion to the protocol-aware conversion point, this document
removes the incentive and the need for application-side pre-
conversion, and with it this class of attack.
10. IANA Considerations
This document has no IANA actions. In particular, it deliberately
does not define an EDNS(0) option or any other protocol element for
negotiating name encodings on the wire.
11. References
Rodenhaeuser Expires 19 January 2027 [Page 14]
Internet-Draft Transparent IDN Resolution July 2026
11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[UTS46] The Unicode Consortium, "Unicode IDNA Compatibility
Processing", Unicode Technical Standard #46, Revision 35,
September 2025, <https://www.unicode.org/reports/tr46/>.
11.2. Informative References
[DENIC2010]
DENIC eG, "German Alphabet In The Internet Now Complete
With Eszett", Press release, 16 November 2010,
<https://www.denic.de/en/whats-new/press-releases/article/
german-alphabet-in-the-internet-now-complete-with-eszett-
effective-16-november-the-letter-eszett-w/>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
Rodenhaeuser Expires 19 January 2027 [Page 15]
Internet-Draft Transparent IDN Resolution July 2026
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, DOI 10.17487/RFC3490, March 2003,
<https://www.rfc-editor.org/info/rfc3490>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/info/rfc4343>.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-Local
Multicast Name Resolution (LLMNR)", RFC 4795,
DOI 10.17487/RFC4795, January 2007,
<https://www.rfc-editor.org/info/rfc4795>.
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
Internationalized Domain Names for Applications (IDNA)",
RFC 5893, DOI 10.17487/RFC5893, August 2010,
<https://www.rfc-editor.org/info/rfc5893>.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
<https://www.rfc-editor.org/info/rfc5895>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011,
<https://www.rfc-editor.org/info/rfc6055>.
Rodenhaeuser Expires 19 January 2027 [Page 16]
Internet-Draft Transparent IDN Resolution July 2026
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC8753] Klensin, J. and P. Faltstrom, "Internationalized Domain
Names for Applications (IDNA) Review for New Unicode
Versions", RFC 8753, DOI 10.17487/RFC8753, April 2020,
<https://www.rfc-editor.org/info/rfc8753>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[UTS39] The Unicode Consortium, "Unicode Security Mechanisms",
Unicode Technical Standard #39,
<https://www.unicode.org/reports/tr39/>.
[WHATWG-URL]
WHATWG, "URL Living Standard",
<https://url.spec.whatwg.org/>.
Appendix A. Survey of Existing Implementations
This appendix is informative and records the state observed in July
2026; it will age. Source references are to the respective public
repositories and vendor documentation at that time.
+==================+===============================================+
| Implementation | Observed behavior |
+==================+===============================================+
| Windows (Winsock | Conversion on by default since Windows 8; |
| / NLS) | opt-out via AI_DISABLE_IDN_ENCODING. The |
| | native NLS path (IdnToAscii) maps "ß" to |
| | "ss"; its documentation still cites RFC 3490. |
| | Toward enterprise DNS in domain networks, |
| | UTF-8 queries are used, per the practice |
| | described in RFC 6055. |
+------------------+-----------------------------------------------+
| .NET 5 and later | Nontransitional |
| (ICU) | (UIDNA_NONTRANSITIONAL_TO_ASCII with joiner- |
| | context checking); diverges from the platform |
| | NLS path above. |
+------------------+-----------------------------------------------+
Rodenhaeuser Expires 19 January 2027 [Page 17]
Internet-Draft Transparent IDN Resolution July 2026
| glibc | Opt-in via AI_IDN; nontransitional via |
| | libidn2 (loaded at run time). Effective |
| | table version equals that of the installed |
| | libidn2; the floor of this document requires |
| | libidn2 2.3.8 (March 2025) or later. |
+------------------+-----------------------------------------------+
| musl | No IDN conversion. Project documentation |
| | states that support, when added, will always |
| | be enabled rather than requiring application |
| | options. |
+------------------+-----------------------------------------------+
| Apple libc | No IDN conversion of any kind (source |
| (Libinfo) | inspection); non-ASCII input is passed |
| | through as UTF-8 octets. |
+------------------+-----------------------------------------------+
| WebKit | UTS #46 via ICU with CheckBidi, joiner- |
| | context checking, and nontransitional |
| | processing, without STD3 rules -- equivalent |
| | to the profile of this document. |
+------------------+-----------------------------------------------+
| systemd-resolved | Nontransitional via libidn2, but with a |
| | transitional fallback when input is |
| | disallowed, and a round-trip guard that |
| | discards conversions which do not round-trip. |
| | Prepares per-protocol question forms (UTF-8 |
| | and IDNA), matching the architecture of this |
| | document; the transitional fallback does not. |
+------------------+-----------------------------------------------+
| Go | net/http converts via x/net/idna |
| | (nontransitional); the net package itself |
| | does not convert. Tables are Unicode 15.0, |
| | moving to 17.0 with the Go 1.27 toolchain. |
+------------------+-----------------------------------------------+
Table 2: Observed Behavior of Name Resolution Stacks (July 2026)
For POSIX, the natural mapping of this document is: getaddrinfo()
behaves by default as it does today with the GNU AI_IDN extension;
AI_IDN becomes a no-op; a standardized counterpart to
AI_DISABLE_IDN_ENCODING provides the opt-out of Section 5.8; and the
error condition of Section 7 is surfaced as a distinct EAI_ value.
Standardization of these interface details is a matter for the Austin
Group.
Rodenhaeuser Expires 19 January 2027 [Page 18]
Internet-Draft Transparent IDN Resolution July 2026
Appendix B. Test Vectors
The following vectors illustrate the profile of Section 4.3 with a
table version meeting the floor of Section 4.3.1. They were verified
against an implementation generated from Unicode 17.0.0 data. The
authoritative conformance data is the IdnaTestV2.txt file published
with [UTS46].
+=====================+=====================+=======================+
|Input |Output |Remark |
+=====================+=====================+=======================+
|straße.de |xn--strae-oqa.de |Nontransitional: ß is |
| | |preserved. |
+---------------------+---------------------+-----------------------+
|STRAẞE.de |xn--strae-oqa.de |Requires table version |
| | |15.1 or later; older |
| | |tables yield strasse.de|
| | |(see Section 9.1). |
+---------------------+---------------------+-----------------------+
|faß.de |xn--fa-hia.de |Transitional processing|
| | |would yield fass.de and|
| | |is forbidden. |
+---------------------+---------------------+-----------------------+
|bloß.de |xn--blo-7ka.de | |
+---------------------+---------------------+-----------------------+
|müller-straße.de |xn--mller-strae- |Processing normalizes; |
|(input in NFD) |46a18a.de |callers need not supply|
| | |NFC. |
+---------------------+---------------------+-----------------------+
|σοφός.gr |xn--0xagbn4a.gr |Residual case asymmetry|
| | |of final sigma |
| | |(Section 9.3). |
+---------------------+---------------------+ |
|ΣΟΦΌΣ.gr |xn--0xahbl4a.gr | |
+---------------------+---------------------+-----------------------+
|日本語。ＪＰ |xn--wgv71a119e.jp |Ideographic and |
| | |fullwidth separators |
| | |and characters are |
| | |mapped by the |
| | |processing itself. |
+---------------------+---------------------+-----------------------+
|_dmarc.straße.de |_dmarc.xn--strae- |UseSTD3ASCIIRules=false|
| |oqa.de |admits the underscore |
| | |label. |
+---------------------+---------------------+-----------------------+
|_sip._tcp.example.com|_sip._tcp.example.com|ASCII fast path |
| | |(Section 5.1): no |
| | |processing at all. |
Rodenhaeuser Expires 19 January 2027 [Page 19]
Internet-Draft Transparent IDN Resolution July 2026
+---------------------+---------------------+-----------------------+
|xn--strae-oqa.de |xn--strae-oqa.de |ASCII fast path: |
| | |existing A-labels are |
| | |never re-mapped. |
+---------------------+---------------------+-----------------------+
|⒈example.com |error |U+2488 is disallowed; |
| | |fails closed per |
| | |Section 5.7. |
+---------------------+---------------------+-----------------------+
Table 3: ToASCII Test Vectors
Acknowledgements
The analysis in this document benefited from the public source code
and issue trackers of the projects surveyed in Appendix A. Reviewers
and contributors will be acknowledged here as the document
progresses.
Author's Address
Luca Rodenhäuser
Lindenstraße 11
64380 Gundernhausen
Germany
Email: otzelot2021@outlook.de
Rodenhaeuser Expires 19 January 2027 [Page 20]