Lindenstraße 11 Gundernhausen 64380 Germany otzelot2021@outlook.de

art IDNA IDN Unicode Punycode UTS 46 getaddrinfo resolver 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 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.

Introduction The Domain Name System carries internationalized labels in an ASCII-Compatible Encoding: U-labels are converted to A-labels before they appear in DNS queries. IDNA deliberately placed this conversion inside applications so that existing APIs and servers could remain unchanged . Fifteen years of deployment experience show the cost of that choice: every application converts for itself, and no two convert alike. 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 . 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; 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: 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 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 . 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 . 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 (); that the conversion happens exactly once, at the protocol boundary (); and that nothing changes on the wire ().

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 when, and only when, they appear in all capitals, as shown here.

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() , 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 ().

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 ; A-labels carry a Punycode-encoded form of the label.

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 (), are outside its scope. It does not constrain registry or registration policy (for which see ), does not specify the display direction (conversion of A-labels to U-labels for presentation), does not modify URL or IRI processing (see ), 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.

Architecture

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). maps the requirements onto existing interfaces informatively.

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 ; 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 , and UTF-8 labels do occur in private namespaces (), changing the encoding used in the public tree is a separate and much larger problem than the one this document solves.

A Single Conversion Procedure Implementations MUST convert names using Unicode IDNA Compatibility Processing , conforming to conformance clause C2 (nontransitional processing), with the ToASCII operation parameterized as follows: UTS #46 ToASCII Profile

Parameter	Value
UseSTD3ASCIIRules	false
CheckHyphens	false
CheckBidi	true
CheckJoiners	true
Transitional_Processing	false
VerifyDnsLength	false (see )
IgnoreInvalidPunycode	false

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 , 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 ; 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.

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 . 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 . Under older tables, the uppercase and lowercase spellings of the same word convert to two different registrable domain names (). A floor below 15.1 would perpetuate exactly the divergence this document exists to remove.

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 , by LLMNR , 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 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.

Processing Requirements

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.

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 . UTF-8 validity is as defined in , 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 ; it MAY instead provide a configuration under which such input is rejected with an error ().

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 . No byte-level heuristic is needed or permitted.

Conversion Input selected by or MUST be converted by applying the ToASCII operation with the profile of 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 ().

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 . 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 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 (), the limits are verified for each candidate name actually queried.

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 , in which case the form appropriate to that namespace is used. Note that documents deployments in which suffix search lists contain UTF-8.

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" (). 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 applies exclusively to input that is not valid UTF-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.

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 , HTTP Host headers, and certificate identity verification -- 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. 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.

Non-DNS Name Services and Private Namespaces

Multicast DNS and LLMNR Names sent over Multicast DNS MUST be carried in the UTF-8 form specified by , not as A-labels. The same applies to LLMNR . The conversion point for these protocols therefore performs no ToASCII operation; the late-conversion architecture of is what makes this correct.

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 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.

Private DNS Namespaces Using UTF-8 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 ; names in such namespaces match bit-for-bit, and provisioning conventions need to account for this.

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 (), and -- where the strict mode of 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.

Migration and Backward Compatibility Existing callers fall into three classes. Applications that only resolve ASCII names are untouched by construction (). 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 , by , and by the opt-out of . 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 (). 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 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. 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 ; 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 .

Security Considerations

Table-Version Skew Until the floor of 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 . 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.

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 ; exists to make that form available. Logs SHOULD record both the input form and the converted form of resolved names.

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 (homoglyphs) is likewise out of scope; see UTS #39 and the registry-side recommendations of .

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 during transition.

No New Wire Exposure Because the wire format is unchanged (), this document introduces no new interactions with DNSSEC validation, caching, or on-path devices.

Pass-Through of Non-UTF-8 Input The pass-through behavior of 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 at the encoding layer. Deployments in security-sensitive contexts SHOULD enable the strict rejection mode of , and comparing components SHOULD NOT apply lenient decoding to input that the resolver treats as opaque bytes.

Application-Side Pre-Conversion The status quo is itself a documented vulnerability: 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.

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.

References Normative References The Unicode Consortium Unicode Technical Standard #46, Revision 35 Informative References The Unicode Consortium Unicode Technical Standard #39 WHATWG DENIC eG Press release

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. Observed Behavior of Name Resolution Stacks (July 2026)

Implementation	Observed behavior
Windows (Winsock / NLS)	Conversion on by default since Windows 8; 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 (ICU)	Nontransitional (UIDNA_NONTRANSITIONAL_TO_ASCII with joiner-context checking); diverges from the platform NLS path above.
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 (Libinfo)	No IDN conversion of any kind (source 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.

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 ; and the error condition of is surfaced as a distinct EAI_ value. Standardization of these interface details is a matter for the Austin Group.

Test Vectors The following vectors illustrate the profile of with a table version meeting the floor of . They were verified against an implementation generated from Unicode 17.0.0 data. The authoritative conformance data is the IdnaTestV2.txt file published with . ToASCII Test Vectors

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 ).
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 (input in NFD)	xn--mller-strae-46a18a.de	Processing normalizes; callers need not supply NFC.
σοφός.gr	xn--0xagbn4a.gr	Residual case asymmetry of final sigma ().
ΣΟΦΌΣ.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-oqa.de	UseSTD3ASCIIRules=false admits the underscore label.
_sip._tcp.example.com	_sip._tcp.example.com	ASCII fast path (): no processing at all.
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 .

Acknowledgements The analysis in this document benefited from the public source code and issue trackers of the projects surveyed in . Reviewers and contributors will be acknowledged here as the document progresses.