IDN
Also known as: Internationalized Domain Name, internationalised domain name, IDNA, UTS #46
An IDN (Internationalized Domain Name) is a domain name containing characters outside ASCII, which is carried through DNS as an ASCII xn-- form produced by the IDNA processing defined in UTS #46.
Overview
DNS has always been restricted to letters, digits and hyphen, so an IDN is not stored as Unicode anywhere in the system. It is converted to an ASCII form before it reaches a resolver, and converted back for display. The conversion is defined by UTS #46 and has four steps: map every character, normalise the result to NFC, split it into labels, then validate and Punycode-encode each label that needs it. Punycode is only the last step, and mistaking it for the whole process is why so many converters disagree with the address bar.
The mapping step is where the real behaviour lives. Uppercase folds to lowercase; compatibility characters collapse to plain ones, so fullwidth ｅｘａｍｐｌｅ maps to example and the fi ligature becomes fi; a handful of characters like the soft hyphen are discarded entirely; and some are disallowed outright. Then NFC normalisation matters more than it looks: 'café' can be four code points or five depending on whether the accent is precomposed, the two are visually identical, and macOS hands you the decomposed form because its filenames are decomposed. Without the normalisation pass they encode to two different domains.
IDNA changed once, and the change still shows. IDNA2003 folded ß to 'ss' and final sigma ς to σ, so straße.de and strasse.de were one domain. IDNA2008 keeps both characters, making them separate registrations, and browsers moved to the new rules around 2010 — which is why some German site owners ended up buying their domain twice. These are called deviation characters, and any tool that converts a name containing one is quietly choosing which era to answer for.
Two validity rules are commonly skipped and both cause real rejections. CheckBidi (RFC 5893) requires a label containing right-to-left text to be consistently ordered, so an Arabic or Hebrew label with a stray Latin letter is invalid even though each character is allowed on its own. CheckJoiners (RFC 5892) permits a zero-width joiner only directly after a virama or between two Arabic joining letters, because anywhere else it is invisible and serves only to make two distinct names look identical.