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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [UTS46] The Unicode Consortium, "Unicode IDNA Compatibility Processing", Unicode Technical Standard #46, Revision 35, September 2025, . 11.2. Informative References [DENIC2010] DENIC eG, "German Alphabet In The Internet Now Complete With Eszett", Press release, 16 November 2010, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . 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, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . [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, . [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, . [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, . [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-Local Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, . [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, . [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, . [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, DOI 10.17487/RFC6055, February 2011, . 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, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [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, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [UTS39] The Unicode Consortium, "Unicode Security Mechanisms", Unicode Technical Standard #39, . [WHATWG-URL] WHATWG, "URL Living Standard", . 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]