A Networkshop konferencián 2002-ben, Egerben elhangzott előadás
A DNS szolgáltatás szabályait az RFC1034 és az RFC1035 írja le. Ezek még abból az időből származnak, amikor az internet gyakorlatilag csak Amerikában volt elérhető. Nem gondoltak arra, hogy pl. magyar, japán vagy arab nevek bevezetésére is szükség lehet.
A DNS kliens-szerver modellen alapuló szolgáltatás. Az interneten szétszórt DNS szerverek - névszerverek - szolgáltatják az osztott adatbázist, a kliensek pedig a minden internetbe kötött gépen működő ú.n. rezolverek.
A DNS osztott, hierarchikus adatbázis: a nevek hierarchikusan épülnek fel, és a név-fa egyes ágai felett külön-külön névszerverek rendelkeznek. Bármely ponton lehetőség van egy-egy újabb rész-fa létrehozására, és az adminisztráció és felelősség továbbdelegálására. Egy másik lényeges tulajdonsága a DNS-nek, hogy általában minden rész-fáért több névszerver felelős: ezek a rezolverek szempontjából egyenrangúak. Emiatt a DNS igen hibatűrő szolgáltatás: egy-egy névszerver kiesése nem befolyásolja lényegesen a névfeloldást. A hierarchia csúcsán tartják nyilván például az egyes országokhoz tartozó névszerverek adatait. Ilyen ú.n. gyökér névszerverből több mint egy tucat van szétszórva az internet különböző pontjain. A Magyarországhoz tartozó .hu domain-t kiszolgáló névszerverből, és az ez alatt levő, a Pázmány Péter Katolikus Egyetemhez tartozó ppke.hu névszerverből is több van. A www.itk.ppke.hu név feloldásához sorra szükség van mindezek a eléréséhez a hierarchia legfelső fokáról indulva.
A domain nevek tagokból (label, name part) állnak. Az egyes tagok maximális hossza 63 bájt lehet. A gyakorlatban ennek töredékét használják.
Használható karakterek
A domain nevekben csak 7 bites ASCII karakterek használhatók. Ennél is szigorúbb megkötések vannak, ha a domain név egy számítógépet jelöl: ilyenkor az alfanumerikus karaktereken kívül csak a mínusz jel (dash) használható.
Fontos tulajdonsága még a domain neveknek, hogy nincs különbség kis és nagybetű között. Tehát pl. valami.hu és VALAMI.hu vagy VaLaMi.hu ugyanazt jelentik.
Többről van azonban szó. Hasonló probléma jelentkezik nem csak minden más ékezeteket használó nyelvnél, hanem a nem latin karaktereket használó nyelveknél: pl. az arab, görög, kínai vagy orosz internet felhasználóknál. Nem csak arra van szükség tehát, hogy domain nevekben ékezetes karaktereket lehessen használni, hanem arra, hogy tetszőleges karaktereket. Erre utal a probléma elnevezése is: International Domain Names, IDN. Az internet legfőbb műszaki szervezete, az IETF (Internet Engineering Task Force) erre szakosodott munkacsoportjának a neve: IDN munkacsoport.
Túl kell tehát lépnünk azon az állapoton, hogy domain nevekben csakis ékezetek nélküli latin betűket lehessen használni. Erre már a 80-as évek óta történnek erőfeszítések, a nagy áttörés azonban még nem történt meg: az osztott, hierarchikus DNS adatbázisban még mindig nem használhatók csak ASCII karakterek.
Mielőtt a megoldás módjaira térnénk, beszélnünk kell az interneten használt karakterkészletekről.
Egy karakterkészlet kódolása egy olyan hozzárendelés, amikor az egyes karakterekhez bizonyos bitsorozatokat rendelünk, azzal a céllal, hogy ilyen bitsorozattal ábrázoljuk a karaktert számítógépeken. Egy ilyen bitsorozat nem feltétlenül egyezik azzal a kóddal, ami a karakter sorszáma a karakterkészlet definíciójában, hanem egy hozzárendelés, ami minden CCS-ben szereplő kódhoz egy bitsorozatot rendel. Az RFC2278 szerint ez egy CES (Character Encoding Scheme). Előfordul, hogy egy kódolást valamilyen okból - például átvitel vagy tárolás céljára - újra kódolunk, olyasféleképpen, mint amikor egy dolgot többszörösen becsomagolunk.
Egy fontkészlet egy karakterkészletnek egy bizonyos rajzolatja.
Vannak kódolások, amiket csak egyfajta karakterkészlettel értelmes használni. Ilyen az UTF-8, ami csak UCS (unicode) karakterkészlettel értelmes.
Az ISO-10646 szabvány 31 bit pozíción definiál karaktereket. A lehetséges kódhelyeknek egyelőre csak kicsiny töredékét osztották ki, elsősorban a 16 bittel leírható helyeket, az ú.n. BMP-t (Basic Multilingual Plane).
Amikor egy UCS karaktert a 2, illetve 4 bájton ábrázolt sorszám kódjával kódolunk, akkor UCS-2 illetve UCS-4 kódolásról beszélünk.
0x0100 és 0x0200 közti kódok a latin1-en kívül eső európai latin karaktereket tartalmaznak, többek közt itt van a mi hosszú ő és ű betűnk. Figyelemre méltó különbség a latin1 kódoláshoz képest, hogy az egymásnak megfelelő kis és nagybetűk kódjainak különbsége nem 0x0020, mint az ASCII vagy ISO-8859 kódolásnál, hanem 0x0001.
Base64 kódoló táblázat
Mit? Mivé? Mit? Mivé? Mit? Mivé? Mit? Mivé?
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Amint láttuk, a domain nevekben sok esetben nem használható minden 7 bites ASCII karakter sem, és a kis- és nagybetűk közti különbség sem számít. Ezért értelme van annak, hogy tetszőleges bináris információt ASCII betűkkel és számokkal kódoljunk. Ilyen kódolás a Base32 kódolás. Itt a bináris információt 5 bites darabokra osztjuk, és ezeket az 5 bites darabokat kódoljuk egy táblázatnak megfelelően, vagyis 32-es számrendszerben olvassuk le az értéket. Ha az inputban a kódolandó bitek száma nem lenne 5-tel osztható, akkor 0 bitekkel egészítjük ki (padding).
Base32 kódoló táblázat
Mit? Mivé? hex Mit? Mivé? hex
00000 a 0x61 10000 q 0x71
00001 b 0x62 10001 r 0x72
00010 c 0x63 10010 s 0x73
00011 d 0x64 10011 t 0x74
00100 e 0x65 10100 u 0x75
00101 f 0x66 10101 v 0x76
00110 g 0x67 10110 w 0x77
00111 h 0x68 10111 x 0x78
01000 i 0x69 11000 y 0x79
01001 j 0x6a 11001 z 0x7a
01010 k 0x6b 11010 2 0x32
01011 l 0x6c 11011 3 0x33
01100 m 0x6d 11100 4 0x34
01101 n 0x6e 11101 5 0x35
01110 o 0x6f 11110 6 0x36
01111 p 0x70 11111 7 0x37
Érdemes megfigyelni a Base32 kódoló táblázatnál, hogy hiányzik a 0 és 1 számjegy, valamint az o és l betű, hogy a tévedés veszélyét csökkentsük, hiszen ezek egymással összekeverhetők.
Mivel az internet egyik alappilléréről van szó, nagyon körültekintően kell elvégezni az IDN bevezetését. A bevezetés követelményeiről 30 pontból álló követelményrendszert állított össze az IETF IDN munkacsoportja. A követelmények között szerepel, hogy ne kelljen egyszerre upgrade-elni az összes névszervert, rezolvert és alkalmazást: arra kell számítani, hogy az IDN-t nem ismerő programok még sokáig jelen lesznek a hálózaton. Az IDN bevezetését úgy kell megoldani, hogy ezek működésében ne álljon be zavar.
A tapasztalat azt mutatja, hogy sok létező alkalmazás megjósolhatatlanul viselkedik, elszáll, rosszul működik, ha nem 7 bites ASCII karakterek szerepelnek a domain nevekben. Ezért is esik a választás olyan megoldásra, ahol a névszerverek és rezolverek továbbra is 7 bites karaktereket kezelnek, az alkalmazások szintjén viszont tetszőleges karakterkészletet használhatunk. Ez az
Ez azzal jár, hogy a DNS szerverekben különös, első pillantásra értelmetlennek tűnő DNS neveket kell bevezetni. Ha a névszerver konfiguráció fájljai valamilyen szövegszerkesztővel készülnek, akkor például valamilyen editor makró segítségével elérhető, hogy a hostmaster saját nyelvén írja be az IDN nevet, de a konfigurációs fájlba már a 7 bites ASCII forma kerüljön.
Az Unicode karaktereket tartalmazó IDN domain név 7 bites ASCII-vá való konvertálására egyszerű megoldás, ha a például UTF-8-ban kódolt név bájtjait egyszerűen hexa karakterek sorozataként írjuk le. Az UTF-8 kódolás eleve azzal jár, hogy sok karakter nem 1, hanem több, esetenként akár 6 bájt hosszú. A hexa konverzió az UTF-8 hosszat még kétszerezi, pedig a hossz növekedés nem kívánatos, mivel egy név rész hossza legfeljebb 63 karakter lehet. Ezért ezt az egyszerű kódolást valamilyen ötletesebb formával érdemes felváltani. Egy sor javaslat született ilyen ASCII kompatibilis kódolásra (ACE, ASCII Compatible Encoding).
Ha az alkalmazás konvertálja ASCII karakterekké az IDN domain nevet, akkor a felhasználó nyugodtan használhatja a nemzeti karaktereket a domain nevekben, - például egy elektronikus levélcímben, vagy weblap címben. Ahhoz, hogy a dolog működjön, az alkalmazáson kívül csak a használt karakterhez tartozó ACE név DNS adminisztrátorára van szükség.
A RACE (Row-based ASCII Compatible Encoding for IDN), (ami lehet, hogy megnyeri az ACE-ek versenyét :-) az UCS szerint kódolt nevet tömöríti, base32 szerint kódolja és egy jellegzetes előtaggal ellátva (bq--) tárolja. Egy csupa 7 bites karaktereket tartalmazó domain név RACE kódolásnál változatlan marad. A RACE kódolás előnye, hogy igen tömör, különösen akkor, ha csak egy nyelv karaktereit (pl. csak héber vagy örmény karaktereket) tartalmazó névről van szó: a legtöbb nyelven több mint 30 karakteres lehet egy kódolt név.
Például a rádió.hu domain név RACE szerint kódolva: bq--abzoczdj6m.hu
Nyilvánvaló, hogy ha nem csak a latin karaktereket tekintjük, akkor még sokkal több probléma merül fel. A legnagyobb veszély az, hogy az internet felhasználó valamilyen más helyre lyukad ki, mint amit gondol: imposztorok eltéríthetik a web kéréseit, vagy az elektronikus leveleit.
Jelenleg több kereskedelmi vállalkozás is regisztrál IDN domain neveket, az IETF fejcsóválása ellenére. A szabványosítás lassan halad, bonyolult, egyre újabb és újabb problémák kerülnek felszínre. Ráadásul jogi nehézségek is felléptek. Mindazonáltal a haladás egyértelmű. 2001 decemberében az IETF elkötelezte magát az IDNA elképzelés mellett, ami egyszerűsíti az átállás, az átmenet folyamatát.