IDN's (Internationalized Domain Names)

Een geïnternationaliseerde domeinnaam (IDN) is een domeinnaam die tekens bevat uit niet-Latijnse schriften of talen — zoals Arabisch, Chinees, Cyrillisch, Devanagari, Hebreeuws, Japans of Koreaans — evenals geaccentueerde Latijnse tekens die worden gebruikt in talen als Nederlands, Frans, Duits of Spaans.

Voordat IDN's bestonden, ondersteunde het domeinnaamsysteem (DNS) uitsluitend ASCII-tekens: de 26 letters van het Latijnse alfabet, de cijfers 0–9 en koppeltekens. Hierdoor was de grote meerderheid van de schrijfsystemen ter wereld uitgesloten van een native representatie in een domeinnaam.

ICANN introduceerde geïnternationaliseerde domeinnamen om het internet toegankelijker te maken voor niet-Engelssprekende gemeenschappen. Vandaag bestaan er IDN-TLD's (topleveldomeinen) voor tientallen talen, zodat gebruikers volledig in hun moedertaal door het web kunnen navigeren — van de domeinextensie tot het websiteadres.

Er zijn twee verschillende manieren waarop niet-ASCII-tekens in een domeinnaam kunnen voorkomen, en het is belangrijk dit onderscheid te begrijpen:

IDN-TLD's (geïnternationaliseerde domeinextensies) — Dit zijn de TLD's die op deze pagina worden vermeld. De extensie zelf is geschreven in een niet-ASCII-schrift. Voorbeelden zijn .中国 (China), .рф (Rusland), .مصر (Egypte) en .한국 (Zuid-Korea). Een volledig geïnternationaliseerd domein zoals 政府.中国 gebruikt native tekens op beide niveaus — de tweede-niveau domeinnaam én de TLD-extensie.

IDN-domeinnamen onder standaard-TLD's — Sommige registers die bekende TLD's beheren, zoals .com, .net of landcode-TLD's zoals .nl of .be, staan registratie toe van tweede-niveau domeinnamen met niet-ASCII-tekens, ook al blijft de extensie zelf in ASCII. Zo gebruiken münchen.de of académie.fr geaccentueerde of niet-ASCII-tekens in de domeinnaam, maar is de TLD een gewone ASCII-extensie.

Of een standaard-TLD niet-ASCII-registraties accepteert, hangt volledig af van het beleid van het betreffende register. Sommige registers staan een breed scala aan Unicode-tekens toe; andere beperken registraties tot tweede-niveau domeinen met uitsluitend ASCII-tekens. Er bestaat geen universele regel — het IDN-beleid van het specifieke register voor de gewenste TLD dient te worden geraadpleegd.

Waarom dit onderscheid relevant is voor beveiliging: IDN-homograafaanvallen maken bijna altijd misbruik van het tweede scenario — het registreren van een domeinnaam met visueel gelijkende Unicode-tekens (zoals een Cyrillische а in plaats van een Latijnse a) onder een gangbare ASCII-TLD zoals .com. Dit creëert een domein dat in de adresbalk visueel identiek lijkt aan een vertrouwd merk. IDN-TLD-extensies zijn doorgaans onderworpen aan striktere éénschrift-beleidsregels van registers, wat dit type misbruik op extensieniveau beperkt — maar niet volledig uitsluit.

Hoewel IDN-domeinen aan gebruikers worden weergegeven in hun native schriften, werkt de DNS-infrastructuur nog steeds op basis van ASCII. De brug tussen beide is Punycode — een coderingsstandaard gedefinieerd in RFC 3492 die Unicode-tekens omzet in een geldige ASCII-compatibele tekenreeks.

Elk IDN-domein wordt in de DNS opgeslagen en omgezet als zijn Punycode-equivalent, dat altijd begint met het prefix xn--. Bijvoorbeeld:

• Het Arabische domein مثال.إختبار wordt xn--mgbh0fb.xn--kgbechtv
• Het Duitse domein münchen.de wordt xn--mnchen-3ya.de
• Het Japanse domein 日本語.jp wordt xn--wgv71a309e.jp

Moderne browsers en e-mailclients verwerken de Punycode-conversie automatisch, zodat gebruikers de leesbare Unicode-versie in de adresbalk zien. Op de achtergrond lost de DNS de xn--Punycode-tekenreeks op zoals elke andere domeinnaam.

Een Punycode-converter kan worden gebruikt om elk IDN-domein te vertalen naar zijn ASCII-compatibele codering (ACE) — handig bij het configureren van DNS-records, SSL-certificaten of serverinstellingen waarvoor de onbewerkte ASCII-representatie vereist is.

Ja — IDN-domeinregistratie is mogelijk via door ICANN geaccrediteerde registrars die Unicode-domeinnamen ondersteunen. Niet elke registrar biedt IDN-registratie aan, dus er moet een registrar worden gevonden die specifiek het gewenste schrift en de gewenste TLD ondersteunt.

Waar op te letten bij een IDN-registrar:

• Ondersteuning voor de specifieke tekenset of het schrift (Arabisch, Cyrillisch, CJK, Devanagari, etc.)
• Beschikbaarheid van de gewenste IDN-TLD — zowel generieke TLD's (gTLD's) als ccTLD's kunnen IDN-varianten hebben
• Correcte Punycode-conversie tijdens het registratieproces
• Ondersteuning voor IDN-compatibele SSL/TLS-certificaten en e-mailconfiguratie

Registratieproces: Zodra een registrar is gevonden en de beschikbaarheid is bevestigd, verloopt het proces identiek aan een standaard domeinregistratie. De registrar converteert de gekozen Unicode-domeinnaam automatisch naar het Punycode-equivalent en stuurt dit naar het register. Het domein wordt beheerd via de Unicode-versie in het controlepaneel van de registrar.

De prijs van IDN-domeinen varieert per TLD en registrar en volgt hetzelfde verlengingsmodel als elke andere domeinnaam.

Een ccTLD (landcode-topleveldomain) is een twee-letter domeinextensie die door ICANN wordt toegewezen om een specifiek land of gebied te vertegenwoordigen — zoals .nl (Nederland), .be (België), .de (Duitsland) of .jp (Japan). Alle traditionele ccTLD's gebruiken ASCII-tekens, wat betekent dat de extensie altijd in het Latijnse alfabet is geschreven, ongeacht het native schrift van het land.

Een IDN (geïnternationaliseerde domeinnaam) daarentegen is een domein dat niet-ASCII-tekens gebruikt — hetzij in de tweede-niveau domeinnaam, in de TLD-extensie zelf, of in beide. IDN's bestaan specifiek om het domeinnaamsysteem in staat te stellen de talen en schriften van de wereld buiten het Latijnse alfabet te vertegenwoordigen.

Deze twee categorieën overlappen op een belangrijke manier: de IDN-ccTLD's. ICANN begon in 2010 met het delegeren van IDN-ccTLD's, zodat landen hun eigen extensie in hun native schrift kunnen weergeven. Bijvoorbeeld:

• .рф is de IDN-ccTLD voor Rusland — het Cyrillische equivalent van .ru
• .中国 en .中國 zijn IDN-ccTLD's voor China in vereenvoudigd en traditioneel Chinees
• .مصر is de IDN-ccTLD voor Egypte in het Arabisch
• .भारत is een van de meerdere IDN-ccTLD's voor India in Devanagari-schrift

Hoewel elke IDN-ccTLD dus een IDN is, is niet elke ccTLD een IDN: de meeste landcode-extensies blijven uitsluitend ASCII. En hoewel elke IDN-ccTLD een land vertegenwoordigt, is niet elke IDN een ccTLD: IDN-gTLD's zoals .游戏 (games) of .شبكة (web/netwerk) zijn geïnternationaliseerd maar niet landspecifiek.

Voor een volledige lijst van landcode-domeinextensies — zowel ASCII als IDN — bezoek onze landendomeingids.

Een IDN-TLD (geïnternationaliseerd topleveldomain) is een topleveldomain-extensie geschreven in een niet-ASCII-schrift. Vóór het IDN-programma van ICANN waren alle TLD's — inclusief ccTLD's zoals .uk of .de — beperkt tot ASCII-tekens, zelfs voor landen die het Latijnse alfabet niet gebruiken.

ICANN begon in 2010 met het delegeren van IDN-ccTLD's, waardoor landen hun TLD in hun eigen native schrift kunnen weergeven. Bijvoorbeeld:

• .中国 — China (vereenvoudigd Chinees)
• .مصر — Egypte (Arabisch)
• .भारत — India (Devanagari)
• .рф — Rusland (Cyrillisch)
• .한국 — Zuid-Korea (Hangul)

Naast ccTLD's zijn ook IDN-gTLD's (geïnternationaliseerde generieke topleveldomeinen) beschikbaar — met domeinextensies in schriften als Arabisch, Chinees, Cyrillisch, Hebreeuws, Japans, Koreaans, Tamil, Thai en nog veel meer.

Het totale aantal gedelegeerde IDN-TLD's blijft groeien naarmate ICANN nieuwe aanvragen verwerkt. Op deze pagina staan alle momenteel beschikbare IDN-TLD's met hun ondersteunde schriften, registratiestatus en prijzen.

Een IDN-homograafaanval (ook homoglyfaanval genoemd) is een vorm van phishing waarbij een kwaadwillende actor een domeinnaam registreert die visueel identiek — of vrijwel identiek — oogt aan een legitieme domeinnaam, maar Unicode-tekens uit een ander schrift gebruikt die lijken op de originele Latijnse letters.

Zo ziet de Cyrillische letter а (U+0430) er in de meeste lettertypen identiek uit als de Latijnse letter a (U+0061). Een aanvaller zou een domein als pаypal.com kunnen registreren met de Cyrillische 'а', dat in veel browsers identiek zou worden weergegeven als paypal.com.

Dit type aanval richt zich doorgaans op standaard ASCII-TLD's zoals .com — niet op IDN-TLD-extensies —, omdat de aanval gebaseerd is op het mengen van schriften binnen de tweede-niveau domeinnaam terwijl een vertrouwd ogende extensie behouden blijft. Zie de vorige vraag voor een uitgebreidere uitleg van dit onderscheid.

Hoe browsers en registers hierop reageren:

• Moderne browsers tonen de Punycode-versie (xn--) in de adresbalk wanneer een domein schriften mengt, waardoor het bedrog zichtbaar wordt
• Veel registers hanteren éénschrift-beleid, waardoor een domein geen tekens uit verschillende Unicode-schriften kan combineren
• ICANN geeft registers richtlijnen voor het implementeren van maatregelen om het risico op homograafaanvallen te verminderen

Hoe u zichzelf beschermt: Controleer altijd zorgvuldig de adresbalk bij het klikken op links. Als een vertrouwd domein een xn--prefix toont of onverwachte tekens bevat, behandel het dan met argwaan en navigeer rechtstreeks naar de website in plaats van op de link te klikken.

IDN-domeinen kunnen effectief zijn voor SEO wanneer doelgroepen worden bereikt die zoeken in niet-Latijnse schriften — met name in markten waar gebruikers zoekopdrachten en merknamen eerder in hun moedertaal intypen.

Vanuit technisch SEO-perspectief ondersteunen zoekmachines zoals Google IDN-domeinen volledig en indexeren ze die zoals elk ander domein. De Punycode- en Unicode-versies van een IDN leiden naar dezelfde bestemming, dus er zijn geen problemen met dubbele inhoud.

Factoren om rekening mee te houden:

• Lokale relevantie: Een IDN-domein in het native schrift van uw doelmarkt kan lokaal vertrouwen en merkbekendheid versterken
• Afstemming op zoekwoorden: Als gebruikers in uw markt zoeken met native schrift-termen, kan een overeenkomstig IDN-domein de thematische relevantiasignalen versterken
• Linkbuilding: Sommige platforms en oudere systemen kunnen moeite hebben met het correct weergeven of linken naar IDN-domeinen — controleer de compatibiliteit met uw ecosysteem
• E-mailbezorging: Niet alle e-mailclients ondersteunen IDN-e-mailadressen volledig — houd hiermee rekening als e-mail deel uitmaakt van uw domeinsstrategie

Voor de meeste internationale SEO-strategieën blijft een ccTLD of gTLD met hreflang-implementatie de primaire aanbeveling — maar een IDN-TLD kan een zinvolle aanvulling zijn wanneer merkidentiteit in een native schrift een prioriteit is.