Az ENUM hazai megvalósításának előkészítése

Az ENUM hazai megvalósításának előkészítése - tanulmány -

készült a Nemzeti Hírközlési Hatóság megbízásából

Készítette: Verzió: Dátum:

Budapesti Műszaki és Gazdaságtudományi Egyetem, Informatikai Központ 1.0 2004.02.15.

Tartalomjegyzék

TARTALOMJEGYZÉK VEZETŐI ÖSSZEFOGLALÓ................................................................................................ 4 1

BEVEZETŐ...................................................................................................................... 7

2

AZ ENUM ÁLTALÁNOS ISMERTETÉSE.................................................................. 8 2.1 KAPOCS AZ INTERNET ÉS A TÁVKÖZLŐ HÁLÓZAT KÖZÖTT .......................................... 8 2.2 FUNKCIONÁLIS MODELL .............................................................................................. 9 2.3 A MEGVALÓSÍTÁS ALAPELVEI ................................................................................... 10 2.3.1 Általános alapelvek .......................................................................................... 10 2.3.2 Önkéntesség elve .............................................................................................. 10 2.3.3 Elvek a hívók és a szolgáltatók részére ............................................................ 11

3

NEMZETKÖZI SZERVEZETEK, SZABVÁNYOSÍTÁS......................................... 12 3.1 AZ INTERNET NEMZETKÖZI SZERVEZETEI .................................................................. 12 3.1.1 Internet Engineering Task Force (IETF) ......................................................... 12 3.1.2 Internet Engineering Steering Group (IESG) .................................................. 13 3.1.3 Internet Architecture Board (IAB) ................................................................... 13 3.1.4 Internet Society (ISOC) .................................................................................... 14 3.1.5 Internet Assigned Numbers Authority (IANA).................................................. 14 3.1.6 Internet Corporation for Assigned Names and Numbers (ICANN) ................. 14 3.1.7 RIPE ................................................................................................................. 16 3.2 TÁVKÖZLÉSI NEMZETKÖZI SZERVEZETEK .................................................................. 17 3.2.1 ITU-T................................................................................................................ 17 3.2.2 CEPT/ECC ....................................................................................................... 19 3.2.3 ETSI.................................................................................................................. 20 3.3 A TÁVKÖZLÉSI ÉS AZ INTERNET SZABÁLYOZÁS ÖSSZEHASONLÍTÁSA ........................ 21

4

A SZÁMOZÁSI TERV ÉS A DOMAIN NÉV RENDSZER (DNS) ÁTTEKINTÉSE ......................................................................................................................................... 22 4.1 A DOMAIN NÉV RENDSZER (DNS) ............................................................................. 22 4.1.1 A domain név rendszer (DNS) jelentősége....................................................... 22 4.1.2 A domain nevek hierarchiája ........................................................................... 22 4.1.3 Domain nevek írásmódja.................................................................................. 23 4.1.4 Domain nevek formai követelményei................................................................ 23 4.1.5 Domain nevek egyedisége ................................................................................ 24 4.1.6 Név-cím hozzárendelés, név feloldás................................................................ 24 4.1.7 Domain név szerverek ...................................................................................... 24 4.1.8 Delegálás, kezelők............................................................................................ 26 4.1.9 Cím-név hozzárendelés..................................................................................... 26 4.1.10 DNS gyökér név szerverek................................................................................ 27 4.1.11 Erőforrás rekordok........................................................................................... 27 4.2 A KÖZCÉLÚ TÁVBESZÉLŐ HÁLÓZAT SZÁMOZÁSI TERVE ÉS A SZÁMOKKAL VALÓ GAZDÁLKODÁS RENDJE ......................................................................................................... 32 4.2.1 A számozási terv ............................................................................................... 33 4.2.2 A számozási erőforrások lefoglalása, kijelölése, visszavonása........................ 34 4.3 AZ ITU-T E.164 AJÁNLÁS SZERINTI SZÁMOZÁSI TERV ÉS A DOMAIN NÉV RENDSZER ÖSSZEVETÉSE ........................................................................................................................ 35

Az ENUM hazai megvalósításának előkészítése

-1-

Tartalomjegyzék 5

AZ ENUM TECHNOLÓGIA ....................................................................................... 36 5.1 KERESÉS A TELEFONSZÁM ALAPJÁN .......................................................................... 36 5.1.1 Az ENUM eljárás ............................................................................................. 36 5.1.2 A DNS gyökér meghatározása.......................................................................... 36 5.1.3 Az E.164 szerinti számok átalakítása domain névvé ........................................ 37 5.1.4 A DNS lekérdezésre adott válasz...................................................................... 38 5.2 A KIKERESETT INFORMÁCIÓ ÉRTELMEZÉSE ............................................................... 39 5.2.1 Az ENUM adatmodell....................................................................................... 39 5.2.2 Az ENUM alkalmazások működésének általános sémája ................................ 40 5.2.3 Együttműködési követelmények ........................................................................ 42 5.3 ENUMSZOLGÁLTATÁSOK ÉS A HOZZÁJUK TARTOZÓ URI SÉMÁK ............................. 46 5.3.1 ENUMszolgáltatások minimális alaphalmaza ................................................. 46 5.3.2 További ENUMszolgáltatások.......................................................................... 49 5.3.3 ENUM kliensek által lekérdezett információ feldolgozása .............................. 49

6

ENUM ADATOK ADMINISZTRÁLÁSA................................................................... 53 6.1 ADMINISZTRÁCIÓS SZINTEK A DNS RENDSZERBEN ................................................... 53 6.1.1 Az ENUM gyökér kezelése................................................................................ 53 6.1.2 Az országhoz tartozó domain kezelése ............................................................. 53 6.1.3 A regisztrált aldomainek kezelése .................................................................... 53 6.2 AZ ADMINISZTRÁCIÓ SZEREPLŐI................................................................................ 54 6.2.1 Felügyelő testület ............................................................................................. 54 6.2.2 Nyilvántartó...................................................................................................... 54 6.2.3 Regisztrátorok .................................................................................................. 57 6.2.4 Hitelesítő .......................................................................................................... 57 6.2.5 NS szolgáltató................................................................................................... 58 6.2.6 Regisztráltak..................................................................................................... 58 6.3 INTERFÉSZEK A SZEREPLŐK KÖZÖTT ......................................................................... 58 6.3.1 Regisztrált és regisztrátor ................................................................................ 58 6.3.2 Regisztrált és NS szolgáltató ............................................................................ 59 6.3.3 Regisztrátor és nyilvántartó ............................................................................. 59 6.4 ADMINISZTRATÍV FOLYAMATOK ............................................................................... 61 6.5 NYILVÁNOS INFORMÁCIÓK ........................................................................................ 62 6.6 VITARENDEZÉS.......................................................................................................... 64

7

ENUM RENDSZER A VÉGFELHASZNÁLÓ SZEMÉVEL.................................... 65 7.1 ENUM FELHASZNÁLÓK KÖRE ................................................................................... 65 7.1.1 ENUM felhasználók.......................................................................................... 65 7.1.2 Végfelhasználók................................................................................................ 65 7.2 ENUM SZOLGÁLTATÁSOK, ALKALMAZÁSOK............................................................ 66 7.2.1 ENUM-ra épülő szolgáltatások........................................................................ 66 7.2.2 Kiindulási és végződtetési pontok .................................................................... 66 7.2.3 Végfelhasználói alkalmazások.......................................................................... 69 7.2.4 Fenntartási, karbantartási szolgáltatások........................................................ 72 7.3 ÜZLETI MODELLEK .................................................................................................... 73

8

ENUM BIZTONSÁGI KERETRENDSZER............................................................... 74 8.1 BEVEZETŐ ................................................................................................................. 74 8.2 ALAPVETŐ INFORMATIKAI BIZTONSÁGI DEFINÍCIÓK .................................................. 74 8.2.1 Azonosítás – Authentication ............................................................................. 74


-2-

Tartalomjegyzék 8.2.2 Jogosultság – Authorization............................................................................. 74 8.2.3 Adat letagadhatatlanság - Data Non-Repudiation........................................... 74 8.2.4 Adatbiztonság - Data Privacy .......................................................................... 75 8.2.5 Adat integritás (sértetlenség) - Data Integrity ................................................. 75 8.2.6 Naplózás - Auditing.......................................................................................... 76 8.2.7 Biztonsági szabályzat és adminisztráció - Policy Management and Administration.................................................................................................................. 76 8.3 AZ ENUM RENDSZER BIZTONSÁGI FENYEGETETTSÉG .............................................. 76 8.3.1 Az ENUM regisztrációs rendszer biztonsági fenyegetettsége .......................... 76 8.3.2 Az ENUM lekérdező (DNS) szolgáltatás biztonsági fenyegetettsége ............... 77 8.4 ENUM BIZTONSÁGI KERETRENDSZER ....................................................................... 79 8.5 DNSSEC................................................................................................................... 81 8.5.1 ENUM lekérdezés (DNS Cache használata nélkül) ......................................... 81 8.5.2 A DNSSEC protokoll ........................................................................................ 82 8.5.3 A DNSSEC célja ............................................................................................... 82 8.5.4 A DNSEC működése ......................................................................................... 82 8.5.5 Szülő általi hitelesítés....................................................................................... 83 8.5.6 Kulcsok váltása ................................................................................................ 84 8.5.7 Előnyök és hátrányok ....................................................................................... 84 8.5.8 A DNSSEC és a PKI viszonya .......................................................................... 84 8.5.9 TSIG ................................................................................................................. 85 8.5.10 Egyéb lehetőségek ............................................................................................ 86 8.6 A DNSEC ÉS TSIG FELHASZNÁLÁSA AZ ENUM RENDSZER BIZTONSÁGI MEGOLDÁSAIBAN .................................................................................................................. 86 8.6.1 Feltételek a DNSSEC használatához................................................................ 86 9

NEMZETKÖZI KITEKINTÉS .................................................................................... 88

10

HAZAI SZABÁLYOZÁSI, FELÜGYELETI KÉRDÉSEK ÉS MEGVALÓSÍTÁSI JAVASLATOK.............................................................................................................. 90

10.1 10.2

A SZABÁLYOZÁS ÉS SZERVEZETI KERETEI ................................................................. 90 ENUM KÍSÉRLETI ÜZEM ........................................................................................... 91

FELHASZNÁLT ELEKTRONIKUS IRODALOM........................................................... 92 FÜGGELÉK ........................................................................................................................... 94 KAPCSOLÓDÓ SZABVÁNYOK ......................................................................................... 94 1.1 ITU szabványok .................................................................................................... 94 1.2 ETSI szabványok .................................................................................................. 95 1.3 IETF ajánlások:.................................................................................................... 95 2 FOGALOM MEGHATÁROZÁSOK ...................................................................................... 97 3 RÖVIDÍTÉSEK ................................................................................................................ 98 1


-3-

Vezetői összefoglaló

Vezetői összefoglaló A távközlés szabályozásának speciális ága az azonosítók szabályozása. Ennek fontosságát hangsúlyozza, hogy a távközlésben az azonosítók legfontosabb körét képező telefonszámok révén lehet igénybe venni a távközlési szolgáltatásokat. Elmondható, hogy a számokkal kapcsolatos szabályozás milyensége nagymértékben befolyásolja a távközlési infrastruktúra használhatóságát, az előfizetők megelégedettségétől kezdve, a szolgáltatások minőségén keresztül a szolgáltatók gazdasági érdekeit. E tények ismeretében a Hírközlési Főfelügyelet hosszú távú szabályozási koncepció kidolgozását határozta el. Ennek érdekében első lépésben egy elemező és rendszerező tanulmány készítését határozata el. A tanulmány1 kidolgozásában a témában jártas, a távközlés különböző szegmenseiben tevékenykedő szakértők vettek részt. A tanulmány igen széles körben áttekintette a számozási szabályozás kérdését. E koncepció keretében a megalapozó tanulmány megállapításaira támaszkodva, figyelembe véve a nemzetközi szabályozás legfrissebb eredményeit további tanulmányok készültek. Első volt a sorban a sok-szolgáltatós környezethez illeszkedő az Európai Unió számozási követelményeit kielégítő, a nemzetközi közcélú távbeszélő2 számozási tervre épülő hazai számozási terv tanulmány3. A következő téma a tranzit és a helyi hálózatokban a verseny kialakulását lehetővé tevő, a nemzetközi szabványosítás4 elveit követő szolgáltató-választás5 és számhordozhatóság volt. E sorozatba illik, annak szerves folytatása az ITU-T számozási tervről szóló ajánlás-család legújabb tagján6 alapuló jelen tanulmány is, amely a távközlés és az Internet konvergenciájának egy részszegmensét, a távközlés területén használt előfizetői azonosítóknak (telefonszámok) Internetes azonosítókká (domain nevek) való átalakításának eljárását (ENUM), az eljárásban résztvevő szereplőket, és a szükséges és lehetséges szabályozási folyamatokat vizsgálja. Áttekinti az ENUM hazai és nemzetközi helyzetét, a megvalósításához kapcsolódó szabványokat és ajánlásokat, valamint azokat a szabványosítási folyamatokat, melyek jelenleg meghatározzák az ENUM technológia fejlődését. Az ENUM rendszer működésének ismertetése mellett röviden bemutatja az ENUM rendszerhez kapcsolódó Internetes technológiákat is. Külön foglalkozik a szabályozási és felügyeleti kérdésekkel, javaslatot tesz azok átgondolására, valamint egy hazai kísérleti projekt elindítására. Az ENUM (Telephone Number Mapping) egy olyan internetes műszaki megoldás, amely lehetővé teszi, hogy az Internetes domain név rendszert (DNS), mint egy világméretű elosztott adatbázist felhasználva, valamely E.164 szabvány szerinti számhoz (telefonszámhoz) különféle Internetes, és hagyományos távközlési szolgáltatásokat rendeljünk, és azt a telefonszám alapján elérjük.

1 2 3 4

A számozás szabályozás hazai elveinek megalapozása. HTE munkacsoportja, 1999. The international public telecommunication numbering plan. ITU-T Recommendation E.164 A magyar számozási rendszer középtávú fejlesztési terve. HTE munkacsoport, 2000. december. Alternatives for carrier selection and network identification. ITU-T Recommendation E.164 – Supplement 1 Number Portability ITU-T Recommendation E.164 – Supplement 2 5 A szolgáltató választás megvalósításának műszaki elemzése. HTE munkacsoport, 2001. augusztus A számhordozhatóság megvalósításának műszaki elemzése, HTE munkacsoport, 2001. december A mobil számhordozhatóság megvalósításának műszaki elemzése, HTE munkacsoport, 2002. november 6 Operational and administrative issues associated with national implementations of the ENUM functions ITU-T Recommendation E.164 – Supplement 3


-4-

Vezetői összefoglaló A szolgáltatások elérése úgy történik, hogy először az E.164 szerinti számhoz egy speciális domain név képzési eljárás alkalmazásával, továbbá egy regisztrált mutató segítségével kikeressük az Interneten azt az adatbázist, amely az adott E.164 szerinti számhoz tartozó különböző szolgáltatások igénybevételéhez szükséges adatokat tartalmazza. A keresés eszköze az Interneten alapszolgáltatásként hagyományosan működő DNS rendszer, amely egy alfanumerikus karaktersorozathoz egyértelműen hozzárendel egy információs rekordot. A keresés eredményeként különféle szolgáltatásokhoz kapcsolódó információhoz juthatunk, így pl. az adott E.164 szerinti számhoz tartozó email cím(ek)hez, további telefonszám(ok)hoz, fax szám(ok)hoz, Web címhez, egyéb adatokhoz. Ezeket az adatokat jellemzően valamilyen alkalmazás (program) használja fel például arra, hogy a telefonszám (az E.164 szerinti szám) ismeretében elektronikus levelet, esetleg abban hangüzenetet küldjön a telefonszám gazdájának, vagy a nyilvános kapcsolt telefonhálózat helyett internetes telefonon kezdeményezze a hívást. Az adatok között egy szolgáltatáshoz több protokoll és cím is fel lehet sorolva, sőt közöttük rangsort lehet megadni. Például megadhatjuk, hogy telefonhívást inkább az Interneten x címen szeretnénk kapni, de ha ez nem működik, akkor a nyilvános telefonhálózat y számán várjuk a hívást. Az ENUM az Internet és hagyományos távközlő hálózatok között a telefonhívások felépítéséhez a címzési eljárások átjárhatóságát teremti meg. Az ENUM egyúttal kapcsolatot teremt az Internet egyéb, nem beszéd alkalmazásaival is, mivel egyetlen azonosítóval, a telefonszámmal a hívott elérhetőségéről többféle információt tesz elérhetővé. Így például: − IP telefonszám, − videotelefon száma, − fax szám, − SMS, EMS, MMS elérhetősége, − mail cím, Web cím, ftp cím, − helymeghatározó szolgáltatás. Az ENUM adatokat az Interneten jelenleg is meglevő DNS adatbázis tárolja, így annak technikai hátterét nem kell létrehozni, de a rendszerben megjelenő új adatokat regisztrálni, frissíteni, kezelni kell. Az adatok adminisztrációja hierarchikusan, felülről lefelé, a telefonszámok kiosztását szabályozó nemzetközi előírások figyelembe vételével történik. Az adatok adminisztrációjával, kezelésével kapcsolatban a tanulmány részletesen elemzi a következő szereplők feladat- és hatáskörét: felügyelő testület, nyilvántartó, regisztrátor, hitelesítő, NS szolgáltató, regisztrált. Megállapítja, hogy a szereplők közül több szervezet – elsősorban az Internetes infrastruktúra szervezetei – már a célnak megfelelően jelenleg is működnek (nyilvántartó, regisztrátorok, NS szolgáltatók). Néhány szervezetet azonban újonnan létre kell hozni, ilyen a felügyelő testület, esetleg a hitelesítők. A felügyelő testület feladata a nemzeti hatáskörbe tartozó ügyekkel kapcsolatos döntésekre, a szabályok meghozatalára, a szereplők közötti esetleges viták rendezésére terjed ki. Ezért a felügyelő testületbe célszerű bevonni az ENUM infrastruktúra működésében érdekelt szereplőket, illetve azok képviselőit. Egy ilyen felügyelő testület tagjai lehetnek a szabályozó és felügyelő intézmények képviselői (minisztérium, hatóság, Internetes önszabályozó szervezetek), a szolgáltatók (internet szolgáltatók, vezetékes és mobil szolgáltatók, nyilvántartó és regisztrátorok) és a felhasználók képviselői, továbbá független műszaki és jogi szakértők is. Világosan látható, hogy a jelenlegi szabályozás és annak szervezeti háttere megfelel a világszerte kialakult helyzetnek. A távközlés szabályozása közelmúltban életbe lépett, az elektronikus hírközlésről szóló 2003. évi C. törvény alapján történik. A Kormány felhatalmazást kapott, hogy az Azonosítók Nemzeti Felosztási Tervét (ANFT-t) és az azonosítókkal való gazdál-


-5-

Vezetői összefoglaló kodás rendjére vonatkozó részletes szabályokat kormányrendeletekben határozza meg. Ez azt jelenti, hogy a nemzetközi gyakorlatnak megfelelően az azonosítók, jelen esetben a telefonszámok használatát továbbra is a hagyományos távközlési szabályok és elvek határozzák meg, és az azonosítókkal való gazdálkodás továbbra is a nemzeti szabályozó hatóság, az NHH feladata. Az Internet azonosítók használatával, kijelölésével kapcsolatos tevékenységeket továbbra is a megfelelő felhatalmazással bíró hazai szervezetek végzik, ill. koordinálják. Ez azt jelenti, hogy a telefonszámokból képzett domain nevek kezelését az egyéb domain nevek kezelésére kijelölt szervezetek (Internet Szolgáltatók Tanácsa, mint nyilvántartó és a vele kapcsolatban álló regisztrátor szervezetek) végzik. A szabályozási feladatokat áttekintve fogalmazódik meg a tanulmány 1. és 2. javaslata: 1. Javaslat: Célszerűnek látszik az ENUM-mal kapcsolatos tevékenységeket meglévő szervezetekre és infrastruktúrára alapozni, azzal a kiegészítéssel, hogy fel kell mérni az új feladatokat, és javaslatot kell tenni azok ellátására. 2. Javaslat: Ki kell dolgozni az ENUM-ra vonatkozó eljárási szabályokat, az egyes résztvevők feladatát, és felelősségét és az együttműködés rendjét. A tanulmány harmadik javaslata a kísérleti üzem beindításával kapcsolatos. Az ENUM kísérleti üzem feladata, hogy a piac összes résztvevője kormányzati felügyelet mellett együttesen, a kereskedelmi fázist megelőzően meggyőződhessen az ENUM IETF RFC 2619 szerinti működéséről, a szükséges műszaki, működési feltételek meglétéről. A javasolt résztvevői kör: szabályozó, felügyelő szervezetek (pl. IHM, NHH, Internet Szolgáltatók Tanácsa), szolgáltatói kör (pl. Internet szolgáltatók, vezetékes és mobil szolgáltatók, nyilvántartó, regisztrátorok), kutatóhelyek, egyetemek (pl. BME). A nemzetközi kísérleti projektek tapasztalatai és eredményei alapján fontosnak tartjuk, hogy Magyarország is bekapcsolódjon az ENUM alkalmazás-fejlesztés feladataiba, valamint az ENUM rendszerek együttműködési vizsgálatába. Ez lehetőséget teremt arra, hogy a későbbiekben zökkenőmentesen be tudjunk kapcsolódni a nemzetközi ENUM struktúrába. Így a hazai piac szereplői is képet kaphatnak arról, hogy milyen lehetőségek nyílnak meg számukra ezen új technológia használatával. A tanulmány elkészítése során folytatott konzultációk alapján megállapítható, hogy több szereplő is kifejezte készségét egy kísérleti üzemben való részvételre, melynek során hasznosíthatja megszerzett tudását, korábbi tapasztalatait, így pl. BME-IK, Internet Szolgáltatók Tanácsa, NHH. Az Internet Szolgáltatók Tanácsa elsősorban a nyilvántartói feladatok ellátásával, regisztrátori rendszer működtetésével kapcsolatos teendőket és eljárásokat dolgozná ki és koordinálná a kísérleti üzem kapcsán. A BME-IK alkalmazásfejlesztési és tesztelési ill. projektmenedzsment feladatokat vállalna. Az NHH a nemzetközi koordinációban a felügyeleti és szabályozási tevékenység előkészítésében, a telefonszámok hitelesítésében lát feladatokat. 3. Javaslat: Meg kell szervezni, és be kell indítani az ENUM kísérleti üzemet, amely bekapcsolódhat a nemzetközi kísérletekbe. Ehhez kormányzati támogatás szükséges. Az ENUM hazai megvalósításának előkészítése

-6-

Bevezető

1 Bevezető Mi is az ENUM? Az ENUM egy eljárás, mely a telefonszámokat Internet domain névvé alakítja. Az ENUM egy megoldás a távközlésben jelenleg végbemenő, a távközlés jövőjét nagymértékben meghatározó, jelentős folyamat egyik részfeladatára. Ez a folyamat a konvergencia. A konvergencia szó azt jelenti: közeledni egymáshoz, jelen esetben a távközlési és az Internetes világ közeledéséről van szó. A távközlésben végbement változások, egyrészt a digitalizáció, másrészt a liberalizáció és a verseny kialakulása, valamint az Internet robbanásszerű világméretű elterjedése lehetőséget ad a két világ összekapcsolására, együttműködésére. A két világ eltérő fejlődése azonban számtalan problémát vet fel, amit az együttműködés érdekében meg kell oldani. Ilyen lényeges eltérés, hogy a két világ más-más eljárást használ az előfizetők, szolgáltatások azonosítására. Problémát jelent az is, hogy nagymértékben megnövekedett egy felhasználó által használt azonosítók száma. Ez vonatkozik a távközlési és tartalomszolgáltatásokra egyaránt. A problémára választott megoldás olyan legyen, hogy − A felhasználók által használt és tárolt azonosítók fajtája csökkenjen; − Egyszerűsítse az autentikációt, és egyben növelje annak hatékonyságát; − Könnyen meghatározható legyen, hogy lehet egy másik felhasználóval kommunikálni, és milyen azonosítót kell használni; − Ne lehessen könnyen hamisítani, csalás ellen védett legyen. Jelenleg több módszer van fejlesztés, kidolgozás alatt, ezek közül néhány fontosabb: − Az ENUM, mely az E.164 szerinti telefonszámokat az .e164.arpa domain név tartományba konvertálja át. Az ENUM egyirányú átalakítás, csak a telefonszámokat alakítja át domain névvé. − Univerzális Távközlési Azonosító UCI. Ez az ETSI által javasolt, az EU által támogatott új azonosítási rendszer. Az UCI három részből áll: Egyedi szám azonosító + természetes név + kiegészítő információ. Az egyedi szám azonosító szolgál a hívó és a hívott fél azonosítására, ez az E.164 kibővítése. Az egyedi név az előfizetőt azonosítja. − Microsoft Passport. A Microsoft szervereken fut, a meglévő email címeken alapul. − Liberty Alliance. Számos szolgáltató által támogatott nyílt kezdeményezés, elosztott architektúrájú rendszer, melyben a felhasználók nem rendelkeznek „master” azonosítóval. E tanulmány a továbbiakban nem foglalkozik a konvergenciával, a számátalakítási módszerek közül is csak az ENUM eljárás elemzésére vállalkozik. A tanulmány alapot adhat egy kísérleti üzem megvalósításának.


-7-

Az ENUM általános ismertetése

2 Az ENUM általános ismertetése 2.1 Kapocs az Internet és a távközlő hálózat között A hagyományos távközlés és az Internet jelenleg két külön világ a piac szempontjából. Míg a telefonos piac mind államigazgatásilag, mind ITU oldalról jól szabályozott, az Internet spontán és gyorsan növekvő terület, ami kevésbé szabályozott.

ENUM

PSTN, GSM…

Internet 350 millió Internet használó világszerte

1.2 milliárd telefonszám világszerte

1. ábra Az ENUM a távközlő hálózatok és az Internet címzési eljárásainak összekapcsolása

A műszaki fejlődés eredményeként az Interneten a hálózatra jellemző alkalmazásokon túl a távközlő hálózatok jól bevált szolgáltatásai is megjelennek, amelyek hálózatok közötti együttműködéséhez új megoldásokat kell kidolgozni. Az ENUM az Internet és hagyományos távközlő hálózatok között a telefonhívások felépítéséhez a címzési eljárások átjárhatóságát teremti meg. Az ENUM egyúttal kapcsolatot teremt az Internet egyéb, nem beszéd alkalmazásaival is, mivel egyetlen azonosítóval, a telefonszámmal a hívott elérhetőségéről többféle információt tesz elérhetővé. Így például: − IP telefonszám, − videotelefon száma, − fax szám, − SMS, EMS, MMS elérhetősége, − mail cím, Web cím, ftp cím, − helymeghatározó szolgáltatás.


-8-

Az ENUM általános ismertetése

2.2 Funkcionális modell Az ENUM működésének alapja az Interneten alkalmazott világméretű elosztott adatbázis, a domain név rendszer (DNS). Ezt az adatbázis használják fel arra, hogy a telefonszámokhoz a felhasználó elérésére adatokat tároljanak és keressenek ki az Interneten alkalmazott különböző szolgáltatásokhoz. Ehhez a telefonszámokat olyan DNS azonosítóvá kell konvertálni, amihez információs rekordokat lehet kötni. A telefonszámok ITU-T E.164 Ajánlás szerinti hierarchikus felépítése miatt a konverzió egyértelműen elvégezhető. Egy számhoz több adatbázis rekord (NAPTR) tartozhat. A rekordokban elvben minden jelenleg meglevő és később kialakuló fontos információ elhelyezhető egy URI formájában. Az URI-k értelmezése elsősorban az ENUM kliens programra van bízva, így egy URI kiválasztásával elindítható a kommunikáció a megfelelő alkalmazással a megadott azonosítóra, például hívás indítható az IP telefonra, fax küldhető a megadott számra, e-mail küldhető a megadott címre, stb.

ITU

0. szint nyilvántartó

Nemzeti keretszabályozás

Delegálás

0. szint nyilvántartó

Validálás

ENUM regisztrátor

Delegálás

0. szint nyililvántartó

Hatóság, Távközlési szolgáltató

ENUM előfizető (regisztrált)

E.164 számkijelölés

Együttműködés Alkalmazások

Szabályozás, adminisztráció

2. ábra Az ENUM funkcionális modellje


-9-

Az ENUM általános ismertetése Az ENUM adatokat a DNS tárolja. Az ENUM adatok tárolása és a rendszer működtetése a domain nevek tárolásához és működtetéséhez hasonló. Az adatok adminisztrációja hierarchikusan, felülről lefelé, három szinten történik. Mivel a telefonszámok kiosztását szigorú nemzetközi előírások szabályozzák, az ENUM adminisztráció szintjeit ezekhez illesztik. Az ENUM megvalósítás a 2. ábrán látható háromszintű architektúrára épül. A DNS mindhárom szintjén vannak adminisztratív és működtetési feladatok, ezen kívül kapcsolatot kell tartani az E.164-es telefonszámok előfizetőivel, a távközlési szolgáltatókkal és a számgazdálkodást végző szervezetekkel is. Ez utóbbira annak ellenőrzésére van szükség, hogy az ENUM adatokat a telefonszámok „birtokosa” viszi a DNS-be.

2.3 A megvalósítás alapelvei

2.3.1 Általános alapelvek − Az ENUM felhasználónak az E.164-es számozási terv integritása érdekében rendelkeznie kell E.164-es telefonszámmal. − Az ENUM adatok integritását nem szabad veszélyeztetni. − Az adminisztrációs követelményeknek tekintettel kell lenni a különböző típusú E.164es számokra és azok menedzselési módjára. − A vonatkozó ITU-T ajánlások és IETF műszaki specifikációk előírásait be kell tartani. − Európában a versenykörnyezetet és a versenytörvény minden vonatkozását elő kell segíteni. − Stabil és biztonságos környezetet kell biztosítani, amely nem veszélyezteti az Internet és a távközlő hálózatok (PSTN, ISDN, PLMN) stabilitását és funkcionalitását. A nagyobb biztonság érdekében a DNSSEC használata megfontolandó. − Az ENUM minden adatát teljes mértékben a regionális és nemzeti adat- és titokvédelmi törvényeknek megfelelően kell kezelni. − Az ENUM-ban a telefonszámok kezelését a vonatkozó nemzeti szabályozás követelményeivel összhangban kell végezni. − A meglévő, gyakran ország-specifikus megvalósítású hálózati funkciókat, mint a számhordozhatóság, nem szabad veszélyeztetni. − A felhasználók ENUM-ban való részvételére az önkéntesség elvét kell alkalmazni. − Az ENUM-ot nem szabad megtiltani/késleltetni, ha az erre kijelölt szervezetek nem kívánnak részt venni benne.

2.3.2 Önkéntesség elve Az ENUM-ban való részvételhez a telefonszám birtokosának a kifejezett kérése szükséges ahhoz, hogy az E.164-es telefonszámát az ENUM domain-ben regisztrálják és a számhoz bármilyen NAPTR rekordot közzétegyenek. Ez azért fontos, mert az ENUM rekord a DNS lekérdezéssel nyilvánosan elérhető.


- 10 -

Az ENUM általános ismertetése Az önkéntes eljárást a következőképpen kell megtervezni: − A felhasználók irányíthatják az információik védelmét és integritását. − Az alapfeltételezés az, hogy nincs NAPTR rekord információ. − Minden bejegyzési kérést hitelesíteni kell, hogy az az E.164-es telefonszám birtokosától származik. − A NAPTR rekord információ bejegyzésnek visszafordíthatónak kell lennie, lehetővé téve a felhasználónak az adatok eltávolítását a DNS rendszerből jól időzíthető módon. − A felhasználónak megfelelő és egyértelmű módon tudomására kell hozni, hogy az ő NAPTR rekordokban szereplő távközlési azonosítói nem védhetők meg sehol a világon.

2.3.3 Elvek a hívók és a szolgáltatók részére Amikor a hívó fél egy E.164-es telefonszámot tárcsáz, alapértelmezésben a meglévő (ITU-T E.105 ajánlás szerinti) telefonszolgáltatást kell nyújtani az ENUM bevonása nélkül. Ebből az alábbiak következnek: − Sem a hívó felhasználó, sem a szolgáltató nem kötelezhető arra, hogy egy E.164-es telefonszámra irányuló hívás felépítéséhez ENUM lekérdezést végezzen. − Az ENUM lekérdezést végző hívó felhasználó vagy szolgáltató nem kötelezhető a válaszul kapott NAPTR rekordokban szereplő szolgáltatások alkalmazására. − A megadott számra irányuló, távközlő hálózatban (PSTN, ISDN, PLMN) kezdeményezett hívásokat megfelelően kell végződtetni, amely végződtetés egy bemondás is lehet.


- 11 -

Nemzetközi szervezetek, szabványosítás

3 Nemzetközi szervezetek, szabványosítás Ebben a fejezetben röviden áttekintjük azokat a nemzetközi szervezeteket, melyek meghatározó szerepet játszanak az ENUM technológia elterjedésében, alkalmazásában és a szabványosítási folyamatában. Először az Internet nemzetközi szervezeteinek feladatait és felépítését, majd a távközlési nemzetközi szervezetek szerepét ismertetjük. A szervezetek felépítésének bemutatásához felhasznált ábrákat a szervezetek dokumentumaiból vettük át, melyben a feliratok, rövidítések angolul szerepelnek.

3.1 Az Internet nemzetközi szervezetei

3.1.1 Internet Engineering Task Force (IETF) Az IETF (Internet Engineering Task Force - Internet-mérnöki Munkacsoport) az Internet protokoll-konstrukciós és -fejlesztési részlege. Az IETF a hálózattervezők, üzemeltetők és kutatók nagy, nyitott nemzetközi közössége, amely az Internet architektúrájának fejlődésével és zökkenőmentes üzemeltetésével foglalkozik. A szervezet nyitva áll minden érdeklődő magánszemély előtt. Az IETF által végzett tényleges technikai tevékenység munkacsoportokban folyik, amelyek tématerületek szerint különülnek el. A munka jó részét elektronikus levelezési listákon keresztül végzik. Az IETF évente háromszor ülésezik. Az IETF munkacsoportjai tématerületek szerint vannak csoportosítva, és mindegyiket egy Terület-Igazgató (Area Director: AD) vezeti. Az AD-k tagjai az Internet Engineering Steering Group (IESG) testületnek, az Internet-konstrukciós Irányító Csoportnak. Architekturális felügyeletet az Internet Architecture Board (IAB) biztosít számára. Az Általános TerületIgazgató (General Area Director) egyúttal az IESG és az IETF elnöke, ezenkívül hivatalból tagja az IAB-nek. Az IETF dolgozza ki a szabványokat, az ún. RFC-ket. Ellentétben az ITU szabványokkal az RFC-k szövege szabadon hozzáférhető és díjfizetés nélkül letölthető, másolható. Az Interneten több helyen is megtalálhatjuk a szabványok szövegét, de autentikus forrásnak az IETF szerverét tekinthetjük. Egy pl. xxxx számú RFC szövegét megtaláljuk a http://www.ietf.org/rfc/rfcxxxx.txt címen. Az IETF és az ITU 2000 októberében megállapodtak azokban a kérdésekben, amelyek tisztázzák az E.164 számokból képzett domain nevek beillesztését a globális domain név rendszerbe. Így megállapodtak abban, hogy az ENUM domain nevek gyökere az e164.arpa lesz. Meghatározták, hogy milyen eljárással kell egy E.164 számból az ENUM domain nevet képezni, és megállapodtak számos további adminisztrációs kérdésben. A megállapodást egy RFC-ben rögzítették (RFC 326: Liaison to IETF/ISOC on ENUM).


- 12 -


3.1.2 Internet Engineering Steering Group (IESG) Az IESG (Internet Engineering Steering Group - Internet-mérnöki Irányító Csoport) feladata az IETF tevékenységi körének és az Internet szabványosítási folyamatának technikai vezetése. Az ISOC részeként az IESG adminisztrálja a folyamatot azoknak a szabályoknak és eljárásoknak az alapján, amelyeket az ISOC megbízottak (Trustees) ratifikáltak. Az IESG közvetlen felelősséget visel az Internet szabványosításával, annak előrehaladásával összefüggő akciókért, beleértve a specifikációk Internet-szabványokként való végleges elfogadását.

3.1.3 Internet Architecture Board (IAB) Az IAB (Internet Architecture Board - Internet-architektúra Testület) feladata az Internet általános architektúrájának definiálása, iránymutatás nyújtása és az általános irányvonal meghatározása az IETF részére. Az IAB ezen túlmenően technológiai kérdésekben tanácsadó csoportként működik az Internet Society (Internet Társaság) mellett, és számos kritikus jelentőségű tevékenység felett gyakorol felügyeletet az Internet támogatására. Feladatai kiterjednek a következőkre: − IESG-választás: Az IAB nevezi ki az új IETF-elnököt és minden más IESG-jelöltet az IETF-jelölőbizottság által összeállított listáról. − Architekturális felügyelet: Az IAB gyakorol felügyeletet az Interneten használt protokollok és eljárások architektúrája felett. − Felügyeleti és fellebbezési jogkör gyakorlása a szabványosítási folyamat felett: Az IAB gyakorol felügyeletet az Internet-szabványok létrehozása és használati folyamata felett. Az IAB szolgál fellebbviteli testületként a szabványosítási folyamat nem megfelelő végrehajtása ügyében benyújtott panaszok tekintetében. − RFC-sorozat és IANA: Az IAB feladata a Request for Comments (RFC) dokumentumsorozat szerkesztői és kiadói teendőinek ellátása, továbbá a különböző Internetkijelölésű számok adminisztrációja. − Külső kapcsolattartás: Az IAB az Internet Society érdekképviseleteként működik a globális Internet szabványosítási, valamint technikai és szervezeti kérdéseivel foglalkozó egyéb szervezetek felé. − Tanácsadás az ISOC részére: Az IAB tanácsadás és iránymutatás forrásaként szolgál az Internet Society Megbízottainak és Tisztségviselőinek Testülete (Board of Trustees and Officers) számára technikai, architekturális, eljárási és (ahol ez helyénvaló) szabályozási ügyekben az Internet és a vele összefüggő technológiák vonatkozásában.


- 13 -


3.1.4 Internet Society (ISOC) Az ISOC (Internet Society - Internet-társaság) professzionális tagsággal rendelkező szervezet, amely véleményezi a követett politikát és gyakorlatot, továbbá felügyeletet gyakorol több más, hálózatpolitikai (network policy) ügyekkel foglalkozó testület és akciócsoport felett. Az Internet közösség egészét jelenleg talán legjobban megtestesítő szervezet. Az ISOC nonprofit, nem kormányszintű, nemzetközi, professzionális tagsággal rendelkező szervezet, amely szabványosítási, oktatási és politikai kérdésekre összpontosít. Több mint 150 tagszervezete és hozzávetőleg 8 600 egyéni tagja a világ 170 országából az Internet-közösség valóságos „who’s who” lexikona. Az ISOC-nak helyi nemzeti tagszervezetei vannak, magyar tagszervezete a Magyar Internet Társaság egyesületi formában a magyar Internet szakemberek, felhasználók fórumaként működik.

3.1.5 Internet Assigned Numbers Authority (IANA) Az IANA (Internet Assigned Numbers Authority - Internet Számkijelölő Hatóság) hatáskörébe tartoznak az Internet valamennyi központilag koordinálandó paramétereivel (IP címek, AS számok, felső szintű domainek, TCP port számok stb.) kapcsolatos adminisztratív, "hatósági" teendők. Az IANA alkalmazottai végzik ezen azonosítók kiadását, nyilvántartását, őrködnek az egyediségen és az ésszerű használaton. Az IANA az Internet Society (ISOC) felhatalmazásával végzi a különböző Internet-protokoll paraméterek használatának kijelölését és koordinálását. Az IANA korábban szabályozó funkcióval is rendelkezett, az ICANN megalakulásával a szabályalkotás mindinkább az ICANN-hez kerül, az IANA pedig a központi koordináció gyakorlati működéséről gondoskodik.

3.1.6 Internet Corporation for Assigned Names and Numbers (ICANN) Az 1998 novemberében megalakult Internet Corporation for Assigned Names and Numbers (ICANN), a Név- és Számkijelölő Internet Vállalat egy Kaliforniában bejegyzett nonprofit társaság, amely az Internettel összefüggő bizonyos technikai igazgatási funkciók koordinálásával hivatott foglalkozni, amit korábban az Egyesült Államok kormánya, illetve annak szerződéses és önkéntes megbízottai végeznek. Az Internet növekvő nemzetközi jelentősége azonban szükségessé tette egy olyan műszaki, igazgatási és politikaformáló testületnek a létrehozását, amelynek egyidejűleg erősebben formalizált a struktúrája és teljesebben tükrözi az Internet-közösség sokféleségét/diverzitását. A szervezeti felépítést a 3. ábra mutatja be vázlatosan. Az ICANN azzal a céllal jött létre, hogy globális konszenzusteremtő testületként szolgáljon, amelyre az amerikai kormány átruházza az Internet négy kulcsfontosságú funkciójának koordinálásával összefüggő feladatokat és felelősséget. Ezek: − a domain név rendszer kezelése, − az IP címek kiosztása, − a protokollparaméterek kijelölése, és


- 14 -

Nemzetközi szervezetek, szabványosítás − a gyökér névszerver rendszer kezelése. Az ICANN működését az Alapokmány (Bylaws) határozza meg, amely minden szervezeti és eljárási kérdést szabályoz. A szervezetet egy Igazgatótanács (Board of Directors) irányítja, amelynek tagjait az ICANN érdekképviseleti struktúráiban szereplő szereplők választanak hierarchikus és tematizált kontingensek szerint. Az ICANN struktúrája egyrészt a széles bázisú internetes általános tagságot képviselőkből, másrészt a világ különböző részeiről választott több műszaki és politikai tanácsadó szervezetből tevődik össze.

3. ábra Az ICANN szervezeti felépítése


- 15 -


3.1.7 RIPE A három regionális címkiosztó közül Európában a RIPE (Réseaux IP Européens) működik. Az egyesület tagjai a helyi címkiosztó szervezetek (LIR: Local Internet Registry). A technikai munkát a RIPE NCC (Network Control Centre) végzi, amely a RIPE egyesület vállalkozása. Az Internet nemzetközi irányító szervezetei és az ITU közötti megállapodás alapján az e164.arpa domain kezelésével a RIPE NCC-t bízták meg. Ez egyrészt a megfelelő műszaki feltételek biztosítását, a vonatkozó névszerverek üzemeltetését jelenti, másrészt az egyes országkód domainek kezelésére vonatkozó beérkező igények teljesítéséhez szükséges adminisztratív teendők elvégzését. A kölcsönös egyetértésben megszületett szabályok szerint a RIPE NCC-hez beérkező igényeket elektronikus levelezési listán és web lapon nyilvánosságra hozzák, továbbá értesítik az ITU TSB-t (Telecommunication Standardization Bureau). Ezt követően a RIPE NCC 60 napig várja, hogy az igénnyel kapcsolatban érkezik-e hozzászólás, esetleg kifogás. Az ITU ezalatt konzultál az érdekelt ország ITU képviseletével és állást foglal abban a kérdésben, hogy támogatja, vagy ellenzi az igény teljesítését. Ha az ITU az igény támogatásáról értesíti a RIPE NCC-t és a RIPE NCC által elvégzett műszaki vizsgálatok eredménye is pozitív, akkor a RIPE NCC bejegyzi a megfelelő adatokat a DNS adatbázisba és ezzel az eljárás lezárul.


- 16 -


3.2 Távközlési nemzetközi szervezetek

3.2.1 ITU-T Az ITU-T az ENSZ szakmai szervezetének, a Nemzetközi Távközlési Uniónak három szektora közül a Távközlés szabványosításával foglalkozó szektora. 1993 márciusában alapították az 1865 óta működő CCITT jogutódaként.

4. ábra Az ITU szervezeti felépítése


- 17 -


Feladata a távközlés – kivéve a rádiós rész kivételével – egész világra kiterjedő szabályozása hatékony, magas minőségű, kellő időben rendelkezésre álló szabványok által. Tagjai a világ összes országa ill. ezen országok adminisztrációja, szolgáltatói, fejlesztő intézetei. Legfőbb szerve a 4 évenként ülésező közgyűlés (World Telecommunication Standardization Assembly - WTSA), ahol kialakítják a szektor általános politikáját, létrehozzák a Tanulmányi Bizottságokat, kinevezik ezek vezetőit, meghatározzák a 4 éves periódus munkaprogramját. A szektor munkáját a Távközlési Szabványosítási Iroda (Telecommunication Standardization Bureau – TSB) szervezi és koordinálja. A lényegi szabványosítás a Tanulmányi Bizottságokban folyik, a számozással kapcsolatos kérdések a 2. Tanulmányi Bizottságban. 3.2.1.1 Az ENUM TLD vita

Az ITU-T 2. Tanulmányi Bizottsága Ajánlás tervezetet dolgozott ki az országkódoknak megfelelő domain nevek ENUM domainba való delegálására, azonban néhány ITU-T tagország ellenzi az IANA felügyelete alatt álló „e164.arpa” domain használatát, ezért az Ajánlás nem került elfogadásra. Ezek az országok az ENUM számára az ITU-T vagy más nemzetközi szervezet felügyelete alatt álló domain-t szeretnének, amely nagyobb befolyást biztosít az ITU-T számára az ENUM domain menedzselésében. A 2. Tanulmányi Bizottságban az ENUM számára létrehozandó új domain megvalósíthatóságát, előnyeit és hátrányait vizsgáló szakértői csoport alakult. Ha a vizsgálat eredményeként új TLD („top level domain”) kerül kijelölésre, az ENUM kereskedelemi alkalmazásához az előírásokat az új domainre kell kidolgozni. 3.2.1.2 Ideiglenes eljárás

Az ENUM funkciók tesztelésének lehetővé tétele céljából az ITU-T 2. Tanulmányi Bizottsága a domain nevek „e164.arpa” zónába való delegálására ideiglenes eljárást (interim procedure) dolgozott ki, amely szabályozza a RIPE-NCC és az ITU TSB közötti az adminisztratív eljárást. Az ideiglenes eljárás addig marad életben, amíg döntés nem születik az ENUM domain kérdésében és a kidolgozás alatt álló Ajánlásokat el nem fogadják. Addig a 2. Tanulmányi Bizottság az eljárást meghatározott időközönként felülvizsgálja. 3.2.1.3 ENUM Ajánlás és Kiegészítés tervezetek

Az országkódok delegálására jelenleg két Ajánlás megszövegezése folyik, külön a földrajzi országkódokra és a nem-földrajzi országkódok közül a Hálózatok és az országcsoportok országkódjainak delegálására: − draft ITU-T Recommmendation E.A-ENUM: Principles and procedures for the administration of the E.164 geographic Country Codes for registration into the Domain Name System − draft ITU-T Recommmendation E.A-N/GoC: Principles and procedures for the registration of the E.164 Country Codes and their associated Identification Codes


- 18 -

Nemzetközi szervezetek, szabványosítás (ICs) for Networks and Group Identifications Codes (GICs) for groups of countries into the Domain Name System Az ENUM megvalósítása a delegált domainekben az egyes országok belső ügye, azonban a megvalósítás adminisztratív és műszaki kérdéseihez az ITU-T útmutatást, háttér-információt dolgozott ki. A 2002-ben elfogadott Kiegészítés a földrajzi országkódokra mutatja be az ENUM architektúrát és a funkciók lehetséges megosztásainak módját a résztvevők között. Elkezdődött a nem-földrajzi országkódokra vonatkozó Kiegészítés kidolgozása is, amely a globális szolgáltatásokra terjed ki. Az elfogadott és a készülő Kiegészítés címe: − ITU-T Supplement: “Operational and administrative issues associated with national implementations of the ENUM functions” (2002-05) − Draft ITU-T Supplement: “Operational and administrative issues associated with the implementation of ENUM for Non-Geographic Country Codes” Az ITU-T gondot fordít arra, hogy a tagországok szakértőivel megismertesse az ENUM-ot. 2001-ben és 2002-ben ENUM Workshopot rendezett, valamint 2001. szeptemberben, majd 2002. februárban ENUM ismertetőt adott ki: − Global implementation of ENUM: Backgroud / Tutorial Information Version 1.0 - 7 September 2001 − Global Implementation of ENUM: A Tutorial Paper Information Document 10 (TSB) – February 2002 2003. augusztusában APT-ITU közös ENUM Workshopot rendeztek Thaiföldön, ahol elsősorban az ázsiai országok ENUM projektjeit tekintették át. Az eseményen számos ázsiai ország, többek között Nepál, Korea, Kína, Pakisztán, Vietnám vett részt, ami mutatja az ENUM technológia iránti fokozott érdeklődést világszerte.

3.2.2 CEPT/ECC Az European Conference of Postal and Telecommunications Administrations (CEPT) a távközlés európai szabályozásával foglalkozik, jelenleg 43 európai ország, köztünk Magyarország a tagja. Legfőbb szerve a közgyűlés. A CEPT az Electronic Communications Committee (ECC) szervezetén belül az európai távközlési hatóságok részvételével működik, jórészt szabályozási kérdésekkel foglalkoznak. A munka az időnként ülésező munkacsoportokban illetve az Európai Távközlési Iroda és az Európai Rádiókomunikációs Iroda egyesüléséből létrejött állandó ERO irodában folyik. AZ ECC a szabályozást általában az ERO-ban és a munkacsoportokban kidolgozott és a plenáris ülésén jóváhagyott Határozatokkal és Irányelvekkel irányítja, nagyfontosságú kérdésekben pedig javasolja EU Határozatok és Irányelvek kiadását.


- 19 -


5. ábra Az ECC szervezeti felépítése

Az azonosítók szabályozásával – így az ENUM-mal is - a „számozási” munkacsoport (Working Group Naming, Numbering Addressing – WG NNA) foglalkozik. Az NNA munkacsoport figyelemmel kíséri az ITU-T és az ETSI tevékenységét, valamint az ENUM kísérleteket, és javaslatokat dolgoz ki a nemzeti szabályozás kialakítására.

3.2.3 ETSI Az Európai Távközlési Szabványügyi Intézet (European Telecommunications Standardization Institute - ETSI) független, non-profit szervezet, melynek feladata távközlési szabványok készítése. Jelenleg 55 országból közelítőleg 700 tagja van, gyártók, szolgáltatók, hálózat üzemeltetők, adminisztrációk, fejlesztő intézetek. Az ETSI szabványok konszenzus alapján jönnek létre. Az ETSI legmagasabb szerve a közgyűlés, melyben minden ország képviselteti magát, a közgyűlések közötti legfőbb irányító testület a Board. A szabványok készítése a műszaki bizottságokban folyik. Jelenleg közel 3500 szakértő, több mint 200 csoportban végzi ezt a tevékenységet. Az ETSI vizsgálja az ENUM európai bevezetését. 2002. júliusában megjelent jelentésében felvázolja az ENUM európai bevezetésének általános keretszabályait és a bevezetésre több modellt is javasol. A jelentés nagy súlyt fektet a DNS és az E.164-es számok használatának integritására és hangsúlyozza ezek validálásának szükségességét.


- 20 -

Nemzetközi szervezetek, szabványosítás Eddig két műszaki specifikációt fogadtak el, egyik az ENUM európai adminisztrációját szabályozza, a másik az ENUM kísérleti üzemét támogatja.

3.3 A távközlési és az Internet szabályozás összehasonlítása A hagyományos távközlés és az Internet világa nagymértékben különbözik egymástól, de a közelmúltig, míg mindkettő más-más piaci szegmensben dolgozott, ez nem okozott egyik félnek sem gondot. A távközlésre jellemző, hogy nemzeti szinten a kormányok által, globális szinten az ITU-T által tradicionálisan szigorúan szabályozott, és relatív stabil, előre jelezhető piaci körülmények között működött. Az Internet ezzel szemben abszolút versenypiaci környezetben gyorsan és spontán módon fejlődött, és a kormányok semmilyen szerepet nem játszottak a fejlesztésben és a szabályozásban. Míg az ITU-T tradicionálisan meghatározó szereppel bír a számozási erőforrások egész világra kiterjedő menedzselésében, addig az ICANN a generic TLD menedzselését az ipar önszabályozó mechanizmusa alapján végzi. Ez a kettősség természetesen rányomja bélyegét a két rendszer konvergenciája következtében kialakuló helyzetben, mikor a két rendszer azonos funkciójú erőforrásai között kívánunk kapcsolatot létrehozni, vagyis konkrét esetben a távközlésben használt telefonszámokat az Internetben használatos domain nevekké kívánjuk átalakítani. Természetesen mindkét fél meg kívánja őrizni a kialakult szabályozási mechanizmusait, intézményrendszerét, kompetenciáját stb., mely természetesen számos konfliktus forrása lehet.


- 21 -

A számozási terv és a domain név rendszer (DNS) áttekintése

4 A számozási terv és a domain név rendszer (DNS) áttekintése Mint már a bevezetőben láttuk, az ENUM egy olyan eljárás mely alkalmazásával az E.164 ajánlás szerinti telefonszámokat domain névvé lehet leképezni. Az eljárás részletes ismertetése előtt célszerű megismerkedni a távközlő hálózatok számozási tervével és a Domain Név Rendszerrel, valamint ezen belül az előfizetők azonosításának módjával a távbeszélő és az Internet hálózatban.

4.1 A domain név rendszer (DNS)

4.1.1 A domain név rendszer (DNS) jelentősége A domain név rendszer kialakításának eredeti célja az volt, hogy az Interneten elérhető számítógépeknek neveket (pl. www.hif.hu) lehessen adni, ami kettős előnnyel jár. Az egyik, hogy az Internet használata közben a nehezen megjegyezhető Internet címek (pl. 193.225.23.45) helyett a könnyebben megjegyezhető neveket használhatjuk. A másik, hogy ha a számítógépet a hálózat más pontjára kell helyezni, akkor a címe megváltozik ugyan, de a megszokott nevet mindenki (ember és program) használhatja tovább. A domain név rendszer egy olyan elosztott adatbázist tartalmazó számítógépes rendszer, amely az Internet szolgáltatók összehangolt együttműködésével, hierarchikus felépítésben egy globálisan egyedi szöveges azonosítóhoz (domain névhez) egy IP címet rendel hozzá. A domain név rendszer azonban általánosabban is alkalmas arra, hogy az Interneten elérhető erőforrások számára névtárként működjön, azaz egy teljes domain névhez egyértelműen hozzárendeljük egy erőforrás Interneten elfoglalt helyét. Ezt a tulajdonságát használjuk az ENUM eljárások során.

4.1.2 A domain nevek hierarchiája Az Internet nevek fordított fa szerint szerveződő hierarchiát alkotnak. A fa fordított, a hierarchia legmagasabb fokát DNS gyökérnek (DNS root) nevezzük, de ezt a szintet a domain nevek leírásakor nem jelöljük. A név-fa egy-egy pontját "domain"-nek, domain névnek vagy egyszerűen névnek nevezzük. A közvetlen gyökér alatti neveket felső szintű domaineknek (TLD: top level domain) nevezik. Ezután jönnek a második szintű domainek (SLD: second level domain) stb. A hierarchia szintek száma korlátlan, de 5-6 szintnél mélyebb hierarchiát nem szokás használni. Amikor az Internet még csak USA hálózat volt, a következő TLD-k voltak használatosak az amerikai felhasználók számára: edu com mil gov

egyetemek, oktatási intézmények vállalatok katonai szervezetek kormányzat


- 22 -

A számozási terv és a domain név rendszer (DNS) áttekintése net hálózati szervezetek, szolgáltatók org mindenféle más szervezet arpa az Internet ősében, az Arpanetben levő gépek neveire szolgált kezdetben. Jelenleg általában a címeknek és útválasztó paramétereknek van fenntartva (Address and Routing Parameter Area). Ez alatt találjuk az in-addr domaint, amelynek az inverz feloldásnál (IP címből domain név) van fontos szerepe, és ez alatt hozták létre az e164 domaint is, amelyet az ENUM használ. Az USA-n kívüli felhasználók számára az ISO 3166 szabványban meghatározott kétkarakteres országkóddal (pl. fr, de, hu) jelölt TLD-ket kezdték használni. Ezen TLD-k együttesének elterjedt jelölése: ccTLD (country code TLD). Például a hu ccTLD a magyarországi felhasználók számára szolgált. Mára egyre több ccTLD működik nyitottan, azaz bármely országban élő személy vagy működő szervezet igényelhet domaint az adott országkód alatt. A 90-es évek második felében a com, net és org TLD-t megnyitották az Amerikán kívüli felhasználók számára is, sőt azok időközben továbbiakkal bővültek (pl. info, biz). Ezen TLD-k alatt ma a világ bármely tájáról bárki (magánszemély vagy szervezet) regisztráltathat domaint, illetve domain neveket. Elterjedt jelölésük: gTLD (globális vagy generikus TLD-k).

4.1.3 Domain nevek írásmódja Az internet domain nevek írásmódja olyan, hogy balról jobbra haladunk az egyre magasabb hierarchia szintek felé, miközben a szintek nevei közé pontot teszünk (pl. gep.osztaly.intezet.hu). Ez nagyon hasonlít az operációs rendszerek fájl struktúra hierarchiájához (pl. C:\anyagok\majus\jelentes1.txt), csak itt éppen fordítva: a névben a hierarchia jobbról balra csökken. A TLD-től balra helyezkedik el a második szintű domain, tőle balra a harmadik szintű domain (ha van ilyen), és így tovább. Egy ún. teljes domain név az alkalmazott hierarchia szintek számának megfelelően több, egymástól ponttal elválasztott név-részből, ún. szegmensből áll. Egy hierarchia szintről nézve az az alatti domaineket aldomaineknek nevezzük. Így egy un. teljes domain név az aldomain nevek felsorolásából áll. A teljes domain névben a hierarchia alján (a bal oldalon) lévő név jellemzően már nem egy további elemeket tartalmazó domain neve, hanem egy bizonyos konkrét számítógép, szolgáltatás megnevezése (az adott környezetben).

4.1.4 Domain nevek formai követelményei Domain nevekben megengedett karakterek a latin ABC betűi [a-z], a számjegyek [0-9] és a kötőjel (-). Kis és nagybetű egyformán használható, és nem jelent különbséget. Az ASCII karakterkészleten kívüli betűk (pl. ékezetes betűk) sokáig nem szerepelhettek domain névben, ezen a nemrég elfogadott új szabvány (IDN: Internationalized Domain Names) változtatott. Az új szabványt napjainkban vezetik be, és ahogy a nyilvántartók megkezdik az új szabvány szerinti névválasztás elfogadását, valamint ahogy az alkalmazások új verzióiban is megjelenik az új szabvány implementálása, úgy válnak használhatóvá olyan korábban elképzelhetetlen domain nevek, mint pl. fúrógép.hu. A szám vagy betű karakterektől eltérő karaktereket (kivéve a kötőjelet) továbbra sem támogatja a szabvány, ezért pl. a kiss&nagy.hu továbbra sem lesz használható. Kötőjel sem a név szegmens elején, sem a végén nem állhat.


- 23 -


4.1.5 Domain nevek egyedisége Egy teljes domain névnek egyedinek kell lennie a teljes globális Interneten. Ehhez a domain nevek kiosztását össze kell hangolni, amiben segít a hierarchikus szervezés. Lehet, hogy az Internet több pontján is elneveznek egy gépet pl. jupiter-nek, de nevük egyértelmű, ha a teljes domain nevüket tekintjük (pl. jupiter.osztaly.intezet.hu vagy jupiter.arizona.edu). Ugyanahhoz az IP címhez több domain név is tartozhat.

4.1.6 Név-cím hozzárendelés, név feloldás Hogyan is zajlik a név feloldás? A nevek feloldása hálózati kommunikáció által történik. A nevek feloldása a gyökértől kezdődik, és fokról fokra halad előre. Tételezzük fel, hogy a www.arizona.edu nevet kell feloldani, mert ott egy Web lapot akarunk megnézni. Ezért az általunk használt Web böngészőnek megadjuk a www.arizona.edu domain nevet. Programunknak ekkor meg kell állapítani, hogy milyen IP cím is tartozik ehhez a domain névhez. Ezt a funkciót ellátó egységet nevezzük rezolvernek, feloldónak. Gépünkön a TCP/IP szoftver telepítésekor, konfigurálásakor meg kellett adni egy vagy több domain név szervert. Ezekhez fordul a rezolver. Rezolverre gyakorlatilag minden TCP/IP-t használó, Internetbe kapcsolt számítógépen szükség van. A rezolver tehát nem végez közvetlenül név feloldást, hanem bizonyos általa ismert névszervereket kér meg arra, hogy a feloldást elvégezzék. A rezolver konfigurációban a domain név szerverek megadásánál értelemszerűen IP címeket kell használnunk. Amikor a rezolver a konfigurációjában megadott névszerverhez (példánkban legyen ez az ns.intezet.hu) fordul, hogy a www.arizona.edu névhez tartozó IP címet megtudja, akkor a névszerver munkához lát. Az ns.intezet.hu névszerver ismeri a DNS gyökér névszervereinek IP címét és ezek valamelyikét kérdezi meg, hogy ki az edu zóna felelőse. A root névszerver elküldi az .edu zónáért felelős névszerver(ek) listáját. Az ns.intezet.hu névszerver ekkor egy újabb kérdést intéz ezúttal az .edu névszerveréhez, amely megválaszolja, hogy hova lehet fordulni az arizona.edu nevek feloldásáért. Ilyen módon az ns.intezet.hu rekurzív módon oldja fel a nevet, melynek végén a kérdező kliens gép rezolverének megadja a választ. A domain név szerverek általában nem végeznek bármely kliens számára ilyen rekurzív feloldást, hanem csak a konfigurációjukban meghatározottakra.

4.1.7 Domain név szerverek A domain név - erőforrás hely összerendeléseket az Interneten számos helyen működő domain név szerverek tartalmazzák. A szerverek között hálózati kommunikáció zajlik, ez teszi lehetővé, hogy az általunk megadott domain név alapján a domain név szerverek kikeressék számunkra az adott névhez tartozó adatokat. A keresés a fa gyökerétől halad lefele a hierarchián. Valamely domain név szerver a neki megküldött név alapján kikeresi és megadja a következő, eggyel alacsonyabb hierarchia szinthez tartozó névszerver IP címét, vagy (ha már ő az utolsó a sorban) a kérdezett teljes névhez tartozó IP címet vagy egyéb erőforrás rekordot. Ha egy név dolgában egy szerver az Internet számára elsődleges információforrás, azaz illetékes, azt úgy szokás kifejezni, hogy az ő adata autoritatív.


- 24 -

A számozási terv és a domain név rendszer (DNS) áttekintése 4.1.7.1 Zónafájl

A név-fa zónákra oszlik: egy-egy zóna a fa egy egységként kezelt része. Sokszor - de nem feltétlenül -, egy zóna egybeesik egy aldomainnel (pl. egy zóna lehet az osztaly.intezet.hu és minden név, ami a hierarchiában ez alatt van). Egy zóna adatai a közvetlenül érte felelős (elsődleges) domain név szerveren rendszerint egy fájlban, az ún. zónafájlban találhatók. A zónafájlban ún. erőforrás rekordok (RR: resource record) találhatók, ezekkel később részletesen foglalkozunk. 4.1.7.2 Redundáns szerverek

Egy-egy zónát több szerver is láttathat az Internet felé. Ezek közül az egyik az elsődleges (primary) vagy mester (master), a többi (ha van) másodlagos (secondary) vagy szolga (slave). Az egyszerű felhasználók rendszerint csak egy másodlagos névszerverrel rendelkeznek, a szolgáltatók azonban többnyire növelik a redundanciát és 3-5 másodlagos névszervert is használnak. A DNS gyökér zóna például tíznél is több névszerveren érhető el. Az elsődleges névszerveren a domainhez tartozó adatokat a zóna kezelője közvetlenül (egy fájl átírásával) adja meg, változtatja. A másodlagos szerver(ek) a zóna adatait meghatározott rend szerint az elsődleges szervertől a hálózaton keresztül automatikusan veszi(k) át, tükrözi(k). A tükrözés rendjét az elsődleges szerveren a kezelő a zóna konfigurációs paramétereinek beállításával határozza meg. A másodlagos névszerver(eke)t rendszerint senki sem a saját hálózatán helyezi el, hanem annak működtetését kölcsönösségi alapon (vagy egyéb megállapodással) másra bízza. (Itt nem kell feltétlenül egy önálló gép máshol történő elhelyezésére gondolnunk, hiszen egy számítógép sok zóna számára adhat másodlagos névszerver szolgáltatást.) Ennek az az értelme, hogy ha az elsődleges névszerver egy hálózati hiba miatt elérhetetlenné válik, akkor az attól független, másutt lévő hálózaton lévő másodlagos névszerver az Internet felé továbbra is szolgáltatni tudja a másolatban nála lévő zónafájlból az adatokat. Így az elsődleges névszerver esetleges meghibásodása vagy hálózati okokból történő elérhetetlenné válása miatt nem szűnik meg az adott zónára vonatkozó információ szolgáltatás. A domain név rendszer automatikusan megkeresi azt a névszervert, amely tudja szolgáltatni az adatokat a zónafájlból. Ez a redundancia a névszerver rendszer egyik nagy erőssége. 4.1.7.3 Cache, TTL

A névszerverek az általuk megtudott információt tárolják azzal a céllal, hogy ha újra megkérdezik tőlük, akkor ebből a cache-ből (átmeneti tárból) azonnal tudjanak válaszolni. Ennek többszörös haszna van: csökkenti a hálózati forgalmat, és gyorsítja a névfeloldást. A cacheben minden információt, csak egy bizonyos ideig tárolnak. Ha ez az idő lejárt, akkor egy újabb kéréskor (hiába lenne a cache-ben az információ) a névszerver újra kérdezi azt. Ilyen módon, ha a névhez tartozó információ esetleg változik, arról tudomást szerezhet. Azt az időt, ameddig a cache-ben van egy-egy információ, nem a tárolóban, hanem a láttató, az autoritatív szerverben döntik el: minden rekordhoz tartozik egy - sokszor implicit módon megadott - élettartam (TTL: Time To Live) érték. Ennyi másodpercig tárolják a szerverek a cache-ükben az információt.


- 25 -


4.1.8 Delegálás, kezelők Minden TLD alatt nevek hierarchiája hozható létre. Valamely domain kezelője a hierarchiában alatta lévő aldomainek kezelését tovább delegálhatja más kezelő(k)nek, más autoritásoknak. Például az intezet.hu domain kezelője az osztaly.intezet.hu aldomain kezelését másra bízhatja. A gyökér zóna, és a TLD névszerverek jellemzően ilyen továbbdelegálási bejegyzéseket tartalmaznak, amelyek más névszerverekre mutatnak. Így jön létre a hierarchikus, elosztott adatbázis. Több szintű rendszert, több szintű domain neveket azonban természetesen továbbdelegálás nélkül is ki lehet alakítani. Például lehetséges, hogy az intezet.hu kezelője az osztaly.intezet.hu-t nem delegálta tovább, mégis létezhet a gep.osztaly.intezet.hu domain, mert a kezelő bevezette saját magánál a gep.osztaly.intezet.hu nevet. A név-fa különböző elágazási pontjaiért és ágaiért különböző kezelők felelősek. Egy-egy kezelő lehet több ágért is felelős. Egy aldomain delegálásakor a delegáló kezelőnek a következő tennivalói vannak: − Nevet kell adnia az aldomainnek − Az aldomain nevét, az aldomain elsődleges névszerverének és másodlagos névszerverének IP címét be kell jegyeznie az általa kezelt domain elsődleges névszerverébe Egy aldomain delegálásakor a delegált domain kezelőjének a következő tennivalói vannak: − A fent bejegyzett IP címen - helyes konfigurációval - elsődleges névszervert kell működtetnie az adott aldomainre. − A fent bejegyzett IP címen - helyes konfigurációval - másodlagos névszervert kell működtetnie az adott aldomainre, az elsődleges névszervertől független elérésű hálózaton.

4.1.9 Cím-név hozzárendelés Az Interneten nem csak arra van szükség, hogy nevekből IP címeket nyerjünk, hanem arra is, hogy IP címekből domain neveket kapjunk vissza. Ez a szolgáltatás - amit inverz, vagy reverz feloldásnak neveznek -, a hálózati biztonság szempontjainak erősödése miatt egyre nagyobb jelentőségű. Például sok levelező szerver nem fogad el kéréseket csak olyan IP címekről, amiknek címéből a hozzájuk tartozó domain nevet ki lehet deríteni. Vannak szolgáltatások, amik csak bizonyos domainekból érhetők el. A cím-név feloldás érdekében bevezették az in-addr.arpa domaint. IP címeket úgynevezett pontozott decimális (dotted decimal) alakban szokás megadni ilyesformán: 150.151.152.153. Az ehhez a címhez tartozó nevet úgy kapjuk meg, hogy a domain rendszertől megkérdezzük a 153.152.151.150.in-addr.arpa névhez tartozó rekordot. Az in-addr.arpa domainban éppen úgy delegálják az egyes aldomain-eket mint minden más zónában.


- 26 -


4.1.10

DNS gyökér névszerverek

A domain név hierarchiában meghatározó jelentősége van annak, hogy a gyökér névszerver(ek) milyen szerverekre mutatnak, amikor a TLD-k névszerverei után érdeklődünk. Hiába állítanánk ugyanis fel egy névszervert pl. a .com zónára, ha a gyökér névszerver nem ezt a szervert nevezi meg, akkor senki sem fog rátalálni. A gyökér névszerverek között is kitüntetett szerepe van az elsődleges ("A") gyökér névszervernek, mivel a többi gyökér névszerver ennek az adatait veszi át (tükrözi). Az IANA/ICANN tartja kezében azt az adatállományt, amely a TLD névszervereket tartalmazza, és a gyökér névszerverekbe rendszeresen letöltődik. Ez az a praktikus hatalom, amivel az IANA/ICANN meghatározhatja, hogy kinek delegálja a TLD-k kezelését. A gyökér névszervereket az Internet központi, jól elérhető helyeire telepítik, mivel mindenki őket kérdezgeti. Jelenleg 14 gyökér névszerver működik, ebből csak kettő van Európában, egy Japánban, a többi az Egyesült Államokban található (6. ábra). k.root-servers.net RIPE NCC (LINX) London, UK d.root-servers.net University of Maryland College Park, MD, USA

i.root-servers.net NORDUNET/KTH Stockholm, Sweden

c.root-servers.net PSINet Ashburn, VA, USA

m.root-servers.net WIDE Tokyo, Japan

e.root-servers.net NASA (Ames) Mt. View, CA, USA j.root-servers.net Verisign GRS Herndon, VA, USA

f.root-servers.net ISC Palo Alto, CA, USA b.root-servers.net USC-ISI Los Angeles, CA, USA l.root-servers.net ICANN Los Angeles, CA, USA

g.root-servers.net US Dept. of Defense (DISA) Vienna, VA, USA a.root-servers.net Verisign GRS Herndon, VA, USA

h.root-servers.net US Dept.t of Defense (ARL) Aberdeen, MD, USA

6. ábra A gyökér névszerverek elhelyezkedése

4.1.11

Erőforrás rekordok

A zónafájlban több, különböző típusú erőforrás rekord helyezhető el. A rekordok formáját az RFC 1035 határozza meg. A rekordok egy részét itt mutatjuk be, a közvetlenül az ENUM-hoz kapcsolódó rekordokat az ENUM részleteiről szóló részben tárgyaljuk.


- 27 -

A számozási terv és a domain név rendszer (DNS) áttekintése Az erőforrás rekordok általános formátuma a következő: cimke ttl osztály típus adatok A 'cimke' a domain rekord neve. Lehet üres, ilyenkor az előtte levő rekord cimkéje érvényes. A 'ttl' a rekordhoz tartozó time to live időt adja meg másodpercben. Nem kötelező paraméter. Ha elhagyjuk, akkor a zónára vonatkozó alapértelmezés lesz a rekordhoz tartozó érték. A következő paraméter értéke gyakorlatilag mindig IN, azaz internet osztály. Ez is elhagyható. A 'típus' mondja meg, hogy milyen fajta információról is van szó. Pl. IP cím (A rekord), name szerver információ (NS rekord) stb. Az 'adatok' mező a rekord típusától függő információt tartalmaz. 4.1.11.1 SOA - Start of Authority rekord, zóna kezdő rekord

A SOA rekord adja meg egy zónára vonatkozó közös információkat. A rekord formáját egy példán mutatjuk be: valami.hu.

SOA gep.valami.hu. mester.valami.hu. ( 1999093001 ;Serial nr. 86400 ;Refresh 1800 ;Retry 604800 ;Expire 43200) ;TTL

A címke (valami.hu.) a zóna neve. A SOA kulcsszó utáni első paraméter a zónához tartozó elsődleges szerver domain neve. A második paraméter egy e-mail cím, melyet úgy kapunk, ha az első olyan . karaktert, amit nem előz meg backslash (\) , at jelre, @-ra cseréljük. A serial nr. a zóna sorszáma. Arra szolgál, hogy a slave (másodlagos) szerverek ellenőrizhessék, hogy a náluk levő zóna tartalom nem avult-e el. Akkor töltik le az master (elsődleges) szerverről a zóna tartalmát, ha a náluk levő zóna sorszám kisebb. Arra kell tehát vigyázni az elsődleges szerver adminisztrátorának, hogy ez a szám mindig növekedjen, ha valamit változtat, ha új változat keletkezik a zónából. Szokás ezt a sorszámot ÉÉÉÉHHNNVV alakban megadni, ahol ÉÉÉÉ az év négy jegyen, HH a hónap két jegyen, NN a nap két jegyen, VV a napon belüli változat két jegyen ábrázolva. Az ez után következő négy paraméter mind másodpercben megadott érték. Az első a refresh, a frissítés idő azt mondja meg, hogy mennyi időnként kell a slave szervereknek a master-től megkérdezni, hogy a zóna sorszáma mennyi, vagyis, hogy szükséges-e a zónát frissíteni náluk. A retry idő azt mutatja, hogy ha a frissítés nem sikerült, akkor mennyi időt várjanak, mielőtt újra próbálkoznának. Az expire azt mondja meg, hogy ha nem sikerül a master-rel kommunikálniuk, ennyi ideig szolgáltatják a zónát a világ számára. A TTL érték lesz a zóna rekordjaira érvényes alapértelmezés. Figyelni kell rá, hogy észszerűen állítsuk be a zóna SOA rekordjában az idő értékeket. A legtöbb esetben az 1 napos (86400) refresh, 1 órás (3600) retry, 1 hetes (604800) expire és 1 napos (86400) TTL megfelelő. Ha gyors változás várható, akkor érdemes a TTL értéket kicsire venni. A dolog természetéből adódóan súlyos zavarokat okoz, ha az expire idő nem nagyobb, mint a refresh: a másodlagos zóna nem fogja szolgáltatni az adatokat az idő egy részében.7

7 Az újabb Bind-nál a másodpercben értendő dimenzió nélkül megadott számok helyett használhatunk emberek számára könnyebben kezelhető mértékegységekben megadott számokat, ilyenformán: 1W2D3H. A W (week) heteket, D (day) napokat, H (hour) órákat jelent.


- 28 -

A számozási terv és a domain név rendszer (DNS) áttekintése 4.1.11.2 A - Address, cím rekord

Ez a leggyakrabban használt rekord, amely arra szolgál, hogy egy domain névhez IP címet rendeljünk. Például: masina A 190.111.222.3 Sokszor használt tulajdonságát látjuk itt a zónafájlnak: nem írjuk ki egy domain (jelen esetben a masina) teljes domain nevét, csak annak első részét. A végére oda kell érteni azt a vonatkoztatási rendszert, ahol éppen vagyunk. Ezt először is maga az a zóna adja meg, amire ez a fájl vonatkozik. Például ha a valami.hu zónáról van szó, akkor a 'masina' a végére biggyesztett pont nélkül úgy értendő, mint masina.valami.hu. Ez a tulajdonság legtöbbször igen kellemes, mert például egy 200 A rekordot tartalmazó zóna esetében nem kell 200szor megismételnünk a zónában, hogy 'egyik.valami.hu., masik.valami.hu.' hanem elég annyit írnunk 'egyik, masik'. Vigyáznunk kell azonban, mert könnyen elfelejtkezhetünk arról, hogy pontot kell tennünk a domain név végére, ha azt teljes egészében kiírjuk valahol. Figyeljük meg ebből a szempontból a SOA rekordra felhozott példát fentebb. 4.1.11.3 NS - Name Server, névszerver rekord

Ez a rekord szolgál arra, hogy egy domain névszervereit megadjuk. Ilyen módon a domain egy delegálási pont. Példa: osztaly NS gep.osztaly.valami.hu. Ezzel a rekorddal deklaráljuk, hogy az 'osztaly' aldomain névszervere a gep.osztaly.valami.hu. Ajánlatos - bár technikai értelemben nem kötelező - legalább két névszervert megadni. Ilyen módon a zóna adatai akkor is elérhetők a világból, ha az egyik gép, vagy a hozzá vezető vonal valami miatt kiesne. A felsőbb szinten - példánkban a valami.hu zóna alatt -, nem látszik, hogy a szerverek közül melyik a master és melyik a slave. Szigorúan véve az NS rekordoknak csak a felsőbb szinten, az 'apuka' zónában van szerepe, indokolt azonban a zónában is felsorolni. Az NS rekord paramétere egy gép domain neve. Szükséges, hogy ehhez a névhez közvetlenül A rekord tartozzon. Hibás CNAME rekorddal definiált domain nevet megadni. 4.1.11.4 Glue rekord

Gyakori, hogy a delegált zóna egyik névszervere éppen a zónában van, mint a fenti példában. A gep.osztaly.valami.hu rekordnak az osztaly zónában van a helye, de mégis szükség van arra, hogy egy szinttel feljebb, a valami.hu zónában is felsoroljuk, különben csapdába kerülünk. Ezért fel kell vennünk egy nem oda való A rekordot: gep.osztaly A 190.1.2.3 Az ilyen, idegen A rekordot nevezik glue (ragadvány) rekordnak. Előfordul, hogy adminisztrátorok akkor is felsorolnak nem a zónába való A rekordot, amikor az nem egy onnan delegált aldomainban van, ez hiba. Semmi haszna és zavart okoz. Tehát például ha az osztaly.valami.hu zónának egy másik névszervere a mas.nevszerver.intezet.hu, akkor ehhez nem kell glue rekordot csatolni a vala-


- 29 -

A számozási terv és a domain név rendszer (DNS) áttekintése mi.hu zónában, hiszen ennek a névszervernek az A rekordját ettől a delegálástól teljesen függetlenül lehet megtudni. Ha valahova delegálunk egy zónát, akkor az ottani adminisztrátorral meg kell beszélnünk, hogy azt folyamatosan szolgáltassa is. Ha ez nem történik meg, akkor beszélünk 'lame' delegálásról. Sokszor előfordul például amiatt, mert a delegált zóna slave szervere nevet változtat, vagy meg is szűnik, és erről elfelejtik értesíteni a felettes zóna gazdáit. 4.1.11.5 CNAME - Canonical Name, kanonikus név rekord

Ez a rekord arra való, hogy egy hostnak becenevet adjunk. Például: www CNAME gep Ha ez a rekord van mondjuk a valahol.hu zónában, az azt mutatja, hogy a www.valahol.hu egy másik neve a gep.valahol.hu-nak. Nagyon hasznos az ilyen név például a következő esetben: tegyük fel, hogy egy idő után a gep.valahol.hu meg is szűnik, és a szolgáltatást az ujdivat.valahol.hu veszi át. Ilyenkor elég csak a CNAME rekordot módosítani, így: www CNAME ujdivat A világ számára a valahol.hu web lapjai továbbra is a www.valahol.hu gépen lesznek elérhetők. Az is gyakori, hogy egy gép több funkciót is ellát, és a funkciók mindegyikéhez tartozik egy-egy CNAME rekord, ami ugyanarra a gépre mutat. Például news.valahol.hu, ftp.valahol.hu mind mutathatnak ugyanoda. Mint látjuk, a CNAME rekord paramétere egy domain név. Általában ez a név már A rekorddá oldható fel. Megengedett, de nem ajánlatos a CNAME-ra mutató CNAME rekord. 4.1.11.6 MX - Mail eXchanger, levelező szerver rekord

Ez a rekord szolgál arra, hogy egy domainba érkező levelek levelező szerverét kijelölje. A rekord formátuma egy példán: valahol.hu.

MX MX

10 20

masina.valahol.hu. mas.mashol.hu.

Ezek a sorok azt jelentik, hogy a [email protected] alakú címre érkező leveleket a masina.valahol.hu, vagy a mas.mashol.hu. gépekre kell küldeni. Az MX rekordok első paramétere egy szám, ami a rekord preferenciát jelenti. Kötelező paraméter, de csak akkor van jelentősége, ha több MX rekord tartozik ugyanahhoz a névhez: kisebb szám nagyobb preferenciát jelent. Példánkban tehát csak akkor fogják a levelező szerverek a mas.mashol.hu-ra küldeni a valahol.hu domainba szóló leveleket, ha a preferáltabb masina.valahol.hu nem elérhető. Lehetséges több MX rekordot egyenlő preferenciával megadni. Ilyenkor véletlenszerű, hogy melyikre érkezik be egy-egy levél. Az MX rekord második paramétere egy domain név. Fontos, hogy ehhez a névhez már A rekord tartozzon. Nem megengedett olyan domain nevet magadni, ami csak egy CNAME-ra, vagy másik MX-re mutat. Az MX rekord gyakori alkalmazása, amikor egy intézményben egységes, egyszerűsített, és könnyen megjegyezhető levélcímeket vezetnek be a segítségével. Például a Firma cégnél Az ENUM hazai megvalósításának előkészítése

- 30 -

A számozási terv és a domain név rendszer (DNS) áttekintése [email protected] alakú levelezési címe lehet mindenkinek, ha a firma.hu MX rekord egy - akár időben változó - levelező szerverre mutat, ahol aztán feloldják a levél cím első részében a név aliast, esetleg tovább küldik a levelet egy másik szerverre. 4.1.11.7 TXT - Text, szöveges rekord

Ez a rekord tetszőleges szöveges információt tartalmazhat. Példa: modern

TXT

"Ez a gep mar megszunt"

A TXT rekord paramétere egyetlen, idézőjelek közé zárt ASCII karaktersorozat. 4.1.11.8 HINFO - Hardware information, hardver információ rekord

Akárcsak a TXT rekord ez a rekord is emberi olvasásra szánt, egy számítógépről nyújt felvilágosítást. Példa: masina

HINFO

VAX

VMS-4.7

Mint látható, két paramétere van. Az első a hardver típust, a második az operációs rendszert szokta jelölni. 4.1.11.9 PTR - Pointer rekord

Ahogy arról már szó volt, nem csak név-cím, hanem cím-név hozzárendelésre is szükség van. Ezt a szolgáltatást elsősorban nem emberek, nem is kliens programok, hanem szerver programok használják, annak kiderítésére, hogy egy hozzájuk érkezett IP csomag milyen domainhoz is tartozik. DNS rendszerben az in-addr.arpa domain alá tartozó ág szolgálja a cím-név felosztást. Itt a zónák delegálása az IP címtartomány egyes darabjainak megfelelően történik. Példa: 140.in-addr.arpa.

NS

...

Ez a zóna a 140.x.y.z alakú IP címek inverz domain név szolgáltatásánál játszik szerepet. Ha egy intézmény egy C osztályú címet kap, vagyis gazdálkodhat pl. a 192.84.124.x alakú címekkel, akkor célszerű, ha nála van a 124.84.192.in-addr.arpa zóna elsődleges névszervere is. Ebben a zónában vannak azután a PTR rekordok. Például: 22

PTR

gep.valahol.hu.

A PTR rekord egyetlen paramétere az a domain név, ami az illető IP címhez tartozik. A paraméterként megadott domain név A rekorddá kell forduljon az 'egyenes' feloldáskor.


- 31 -


4.2 A közcélú távbeszélő hálózat számozási terve és a számokkal való gazdálkodás rendje A közcélú távbeszélő hálózatok számozási tervével és a számozási erőforrásokkal való gazdálkodással globális szinten az ITU-T 2. Tanulmányi bizottsága, nemzeti szinten az adott ország adminisztrációja foglalkozik. A számozással kapcsolatos nemzetközi ajánlások hierarchiáját és összefüggéseit az alábbi táblázat mutatja: ITU-T International numbering resource administration

E.195

Principles and responsibilities for the management, assignment and reclamation of E-series international numbering resources

E.190

Criteria and procedures for the reservation, assignment and reclamation of E.164 country codes and associated Identification Codes (IC)

E.164.1

E.164

The international public telecommunication numbering plan

E.213

Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN) Assignment procedures for universal personal telecommunications (UPT) numbers in the provisioning of the UPT service

E.168.1 E.168 E.169

Application of E.164 numbering plan for UPT Application of Recommendation E.164 numbering plan for universal international numbers for international telecommunications services using country codes for global services

E.169.1 Application of Recommendation E.164 numbering plan for universal international freephone numbers for international freephone service E.169.2 Application of Recommendation E.164 numbering plan for universal international premium rate numbers for international premium rate service E.169.3 Application of Recommendation E.164 numbering plan for universal international shared cost numbers for international shared cost service

A számozással kapcsolatos tevékenységek két fő részből állnak: − a számozási politika kialakítása, mely magába foglalja a számozási tervek készítését, folyamatos karbantartását, erőforrások biztosítását az új szolgáltatások számára, a számozással kapcsolatos szabályozás kialakítását, a verseny-semleges, átlátható, felhasználóbarát, gazdálkodás feltételeinek kialakítását, a nemzetközi koordináció végzését, a nemzetközi kötelezettségek betartásának ellenőrzését, szorgalmazását. − a számozási politika végrehajtása, mely magába foglalja a számozási erőforrások lekötését, kijelölését a szolgáltatók ill. előfizetők számára, az erőforrások használatának


- 32 -

A számozási terv és a domain név rendszer (DNS) áttekintése ellenőrzését, szükség esetén az erőforrások visszavonását, az erőforrások használatáért járó díjak beszedését, a nyilvántartások vezetését, közzétételét.

4.2.1 A számozási terv A számozással kapcsolatos összes tevékenység alapja a számozási terv, mely meghatározza a rendelkezésre álló számok körét, mennyiségét, felépítését és a használat szabályait. 4.2.1.1 Nemzetközi számozási terv

A Resolution 20 előírása szerint az ITU-T 2. Tanulmányi Bizottságainak feladata a nemzetközi távközlés igényeinek megfelelő - a segélyhívásokat is magába foglaló - számozási tervek kidolgozása és a TSB igazgatójának támogatása a nemzetközi számozási és címzési erőforrások kijelölésével, visszavonásával kapcsolatos feladatainak végzésével kapcsolatban. Az ITU-T E.164 ajánlás a nemzetközi közcélú távközlés számozási terve ("The International Public Telecommunication Numbering Plan”). Ez az Ajánlás a világ összes országa, összes szolgáltatója, hálózat-üzemeltetője számára kötelező. Az ajánlás 4 típusú nemzetközi számot határoz meg. Minden nemzetközi szám alapvetően két részből áll: az ITU-T által meghatározott országkódból és az esetleges kiegészítő azonosítóból, valamint az egyes országok adminisztrációjának hatáskörébe tartozó belföldi számból, mely tartalmazza az előfizetői számot. A nemzetközi számok maximális hossza 15 számjegy lehet, a megfelelő forgalomirányítás érdekében 7 számjegy mélységű számanalízist alkalmazva. Országkód + azonosító

Földrajzi terület

CC

NDC

SN

Globális szolgáltatás

CC

GSN

Hálózatok

CC

IC

SN

Országcsoport

CC

GIC

SN

ITU-T szabályozás

Ahol:

Belföldi szám (előfizetői szám)

Nemzeti szabályozás

CC

Country Code

országkód

IC

Identification Code

azonosító kód

GIC

Group Identification Code

csoportazonosító kód

NDC National Destination Code


belföldi rendeltetési szám

- 33 -

A számozási terv és a domain név rendszer (DNS) áttekintése SN

Subscriber Number

előfizetői szám

GSN

Global Subscriber Number

globális előfizetői szám

4.2.1.2 Nemzeti számozási terv

A nemzeti számozási terv kidolgozása a nemzetközi számozási terv alapján az adott ország feladata. A Magyarországon jelenleg érvényben lévő számozási terv a közcélú távközlő-hálózatok azonosítóinak felosztási tervéről szóló 10/2001. (III.27.) MeHVM rendelet. E rendelet még az 1992. évi távközlésről szóló LXXII. törvény felhatalmazás alapján, a monopol távközlési viszonyokra készült. A múlt évben megjelent, az elektronikus hírközlésről szóló törvény felhatalmazást adott az Azonosítók Nemzeti Felosztási Tervéről szóló Korm. rendelet elkészítésére. A nemzetközi szabályozásban az utóbbi években végbement radikális változások és ennek bevezetését előíró európai keretszabályozás ismeretében várható a jelenlegi számozási terv alapvető módosítása. Ilyen várható módosítás a sávos számozási struktúra bevezetése, a számhosszak egységesítése, a számozási körzetek számának lényeges csökkentése. A hazai szabályozás a belföldi számra vonatkozik. A belföldi szám a nemzetközi szám országkódot nem tartalmazó része, és két részből áll: a belföldi rendeltetési számból és az előfizetői számból. A belföldi rendeltetési szám (BRS) egy számozási körzetet határoz meg, mely lehet egy földrajzi számozási körzet, vagy nem-földrajzi hálózat, vagy szolgáltatás. A belföldi szám hossza jelenleg 8 vagy 9 számjegy lehet. A reform egyik iránya a földrajz és nem-földrajzi számok élesebb elkülönítése. 1-3 számozási sáv a földrajzi számok részére van kijelölve. Ez elégségesnek látszik a jelenlegi és jövőbeli igények kielégítésére, és a migrációra is lehetőséget ad. A reform része kell legyen a jelenlegi 54 számozási körzetek számának radiális csökkentése. Magyarország méretű, lényegesen nagyobb telefonsűrűséggel rendelkező országok sokszor nem is különítenek el számozási körzeteket. Hasonlóan jelentős változás várható a nem-földrajzi számok területén. A szolgáltatások számára a nemzetközi gyakorlatnak megfelelően 3 csoport lesz kialakítva, nevezetesen a személyhez kötött távközlés, az osztott díjas és díjmentes hívások és az emeltdíjas hívások számára. (A 7-es, 8-as és a 9-es sávok). Külön sávba kerül az összes rádiós szolgáltatás (GSM, UMTS…) és külön sávba a (virtuális) magánhálózatok.

4.2.2 A számozási erőforrások lefoglalása, kijelölése, visszavonása A WTSA Resolution 20 szerint: „A nemzetközi számozási és címzési erőforrások kijelöléséért a TSB igazgatója és a megfelelő nemzeti Adminisztráció a felelős.” 4.2.2.1 Nemzetközi számok kijelölése

Néhány jellegzetes példa a TSB által kijelölt országkódokra:


- 34 -

A számozási terv és a domain név rendszer (DNS) áttekintése Földrajzi

Magyarország

36

Globális szolgáltatás

Universal International Freephone Service (UIFN) Universal International Premium Rate Service (UIPRN) Universal International Shared Cost Service (UISCN) Universal Personal Telecommunication (UPT)

800 979 808 878

European Telecommunications Numbering Space (ETNS)

388 3

Hálózat Országcsoport

4.2.2.2 Az azonosítókkal való gazdálkodás

Az azonosítókkal való gazdálkodás állami feladatait a Hírközlési felügyelet látja el.8 A számokkal való gazdálkodást Magyarországon a távközlési szám- és címgazdálkodásról, valamint annak eljárási szabályairól szóló 75/2000. (V.31.) Korm. rendelet szabályozza. A távközlő hálózatok működéséhez, illetőleg a távközlési szolgáltatások nyújtásához szükséges számok, címek, nevek és ezek tartományai olyan korlátozott erőforrások, amelyet az igénybe vevők ill. a számhasználók lekötés, majd kijelölés alapján vehetnek igénybe.

4.3 Az ITU-T E.164 ajánlás szerinti számozási terv és a domain név rendszer összevetése Az ITU-T E.164 szerinti számozási terv és a DNS számtalan eltérés mellett bír egy közös tulajdonsággal is, nevezetesen mindkettő hierarchikus rendszer. Mint minden hierarchikus rendszernek mindkettőnek van „gyökere”, azonban e gyökér kezelési módja már jelentősen eltér egymástól a két rendszerben. Az ITU-T E.164 ajánlás szerinti számozási tervnek az ITU szabványosítási testülete által kidolgozott minden módosítása az ITU hivatalos lapjában (ITU Operational Bulletin) közzétételre kerül. Ennek következtében a világ összes szolgáltatója „hivatalosan” tudomást szerez a változásokról és az aktuális technikai változtatásokat végre tudja hajtani. Más szóval a szoftverek, azaz a kapcsolóközpontok szükséges változtatását disztributív – elosztott – módon hajtják végre, vagyis nincs központi adatbázis vagy számítógépes rendszer, mely az országkódokban bekövetkezett változásokat az alrendszerek számára továbbadná, mint ahogy az a DNS esetében történik. Tehát ez egy adminisztratív koordinált gyökér, szemben a DNS technikailag is koordinált gyökerével. Ezen adminisztratív koordinált gyökér nagy hátránya, hogy a különböző nemzeti rendszerek közötti koordinálás meglehetősen bonyolult, és egyre nehezebbé válik a távközlési rendszerek liberalizációjával és a szolgáltatók számának gyors növekedésével. Ezt felismerve, az ITU-T 2. Tanulmányi Bizottsága felvette programjába az E.164 szerinti erőforrás változás elérési módjának újragondolását. Az E.164 adminisztratív koordinált gyökér menedzselési rendszerének van bizonyos előnye is. A módszer alkalmazásával kikerülhető a műszaki infrastruktúrában egy kritikus vezérlő alkalmazása, valamint elkerülhető a nemzeti szuverenitás hatása kritikus infrastruktúra elemekre és lehetőséget ad speciális, nemzeti jellegű szolgáltatások bevezetésére. 8 2004. január 1. után a HIF jogutódja a Nemzeti Hírközlési Hatóság.


- 35 -

Az ENUM technológia

5 Az ENUM technológia Ebben a fejezetben ismertetjük a technológia legfontosabb elemeit és azok kapcsolatát. A részletes, mindenre kiterjedő specifikációk természetesen az ide vonatkozó szabványok, ill. ajánlások alapján ismerhetők meg, amelyeket a függelékben felsoroltunk.

5.1 Keresés a telefonszám alapján

5.1.1 Az ENUM eljárás Az ENUM (Telephone Number Mapping) egy olyan internetes műszaki megoldás, amely lehetővé teszi, hogy az internetes domain név rendszert (DNS) felhasználva valamely E.164 szabvány szerinti számhoz (telefonszámhoz) különféle szolgáltatásokat rendeljünk. A művelet egyik fele, hogy az E.164 szerinti számhoz egy domain név képzési eljárás alkalmazásával, továbbá egy regisztrált (domain név regisztráció) mutató segítségével kikeressük az Interneten azt a zónafájlt, amely az adott E.164 szerinti számhoz tartozó különböző szolgáltatások igénybevételéhez szükséges adatokat tartalmazza. A keresés eszköze az Interneten alapszolgáltatásként hagyományosan működő DNS rendszer, amely egy alfanumerikus karaktersorozathoz egyértelműen hozzárendel egy adatállományt (zónafájlt), amely az adatállomány gazdája által regisztráltatott helyen található az Interneten. A művelet másik fele, hogy a zónafájlban található adatok alapján különféle szolgáltatásokhoz kapcsolódó információhoz juthatunk. Így pl. az adott E.164 szerinti számhoz tartozó email cím(ek)hez, további telefonszám(ok)hoz, fax számhoz, Web címhez, stb. Ezeket az adatokat jellemzően valamilyen alkalmazás használja fel például arra, hogy a telefonszám (az E.164 szerinti szám) ismeretében emailt (például emailben hangüzenetet) küldjön a telefonszám gazdájának, vagy a nyilvános kapcsolt telefonhálózat helyett internetes telefonon kezdeményezze a hívást. Az adatok között egy szolgáltatáshoz több protokoll és cím is fel lehet sorolva, sőt közöttük rangsort lehet megadni. Például megadhatjuk, hogy telefonhívást inkább az Interneten x címen szeretnénk kapni, de ha ez nem működik, akkor a nyilvános telefonhálózat y számán várjuk a hívást. A zónafájlban az információ ún. erőforrás rekordok (RR - resource record) formájában található. Az ENUM definiál olyan erőforrás rekord formátumokat, amelyek az ilyen szolgáltatások megvalósításához szükségesek. A szabvány nyitott olyan értelemben, hogy újabb és újabb szolgáltatás típusok definiálására ad módot. Az ENUM lényegét az RFC 2916 (E.164 numbers and DNS) számú internetes szabvány írta le, amit 2000 szeptemberében fogadtak el. Mára ezt tovább bővítették, az újabb változat az RFC 2916bis (The E.164 to URI DDDS Application) jelzést viseli, de ez még nem lezárt, hivatalosan még nem elfogadott szabvány.

5.1.2 A DNS gyökér meghatározása A DNS-ben egy teljes domain név egyediségét az garantálja, hogy a névadás hierarchikus, fordított fa struktúrában történik. Ahhoz, hogy az E.164 szerinti számok szerint a DNS-ben kereshessünk, előbb el kell helyezni az E.164 szerinti számokból képzett nevet a DNS hierarAz ENUM hazai megvalósításának előkészítése

- 36 -

Az ENUM technológia chiában olyan helyen, ahol az így előálló név már egyedi lesz az egész globális DNS rendszerben. A szabvány erre a célra az .e164.arpa alatti névteret jelöli ki. A .arpa legfelső szintű domain a címeknek és útválasztó paramétereknek van fenntartva (Address and Routing Parameter Area). Ez alatt hozták létre az e164 jelölésű domaint, amely az ENUM céljaira használható.

5.1.3 Az E.164 szerinti számok átalakítása domain névvé Annak érdekében, hogy egy E.164 szerinti szám alapján a világon bárki egyértelműen meghatározhassa, hogy abból milyen domain nevet kell képezni, pontosan meg kell határozni a szám átalakításának módját domain névvé. Ez a következőképpen történik: 1. A kiinduló formátum az E.164 szerinti szám a teljes alakjában, tartalmazva az országkódot is (pl. +36 1 234 5678). 2. Az átalakítás első lépcsőjében csak a szám karaktereket hagyjuk meg és közéjük pontot helyezünk el (pl. 3.6.1.2.3.4.5.6.7.8). 3. Az átalakítás második lépcsőjében az előző lépésben nyert karaktersorozatot elhelyezzük a DNS fordított hierarchikus rendszerében az ENUM gyökér alá. Ez úgy történik, hogy az első lépésben nyert karaktersorozatot fordított sorrendben írjuk le és a végére illesztjük a .e164.arpa karaktersorozatot (pl. 8.7.6.5.4.3.2.1.6.3.e164.arpa). Ezzel megkaptuk a DNS használatához szükséges ún. teljesen meghatározott domain nevet.

Gyökér

.arp

.hu

.e164.arp

.6.3.e164.arpa

2. szintű domain

.bme

.in-addr

...

.com

2. szintű domain

3. szintű domain

.ik

... 8.7.6.5.4.3.2.1.6.3.e164.arpa

7. ábra Az ENUM helye a DNS hierarchiában


- 37 -

Az ENUM technológia A DNS rendszer számára bemenetül szolgáló domain név láthatólag "emberi fogyasztásra" nem a legalkalmasabb. De a rendszer nem is arra számít, hogy a felhasználók közvetlen DNS parancsokat adnak ki, majd a választ értékelve megállapítják pl. a nevezett email címét. A tervezők arra számítanak, hogy ezeket a feladatokat ENUM kliens program végzi. Az ENUM kliens programok pedig vagy más alkalmazásoktól (kliens vagy szerver programoktól) kapják a bemenő adatokat vagy barátságos felhasználói felületeket szolgáltatnak, ahol a telefonszámok a szokásos írásmóddal adhatók meg. Tehát pl. a számítógép képernyőjén megjelenő "Melyik telefonszámhoz tartozó email címet keresi?" kérdésre nyugodtan beírhatjuk a "+3612345678" karaktersorozatot, mert a program ezt értelmezi és elvégzi az átalakítási lépéseket, majd a DNS-nek elküldi a 8.7.6.5.4.3.2.1.6.3.e164.arpa domain névre vonatkozó kérdést. A választ hasonlóképpen vagy programok kapják vagy ember, ez utóbbi esetben nyilvánvalóan valamilyen érthető formátumban és kommentárral. A továbbiakban azt tárgyaljuk, hogy a kérdésre milyen válaszok érkezhetnek.

5.1.4 A DNS lekérdezésre adott válasz Az előző pont szerint előállított domain névre elküldött szabályos DNS lekérdezés bármely más domain névre vonatkozó lekérdezéshez hasonlóan végigjárja a DNS-ről szóló részben tárgyalt utakat. A lényeg, hogy a rendszer előbb-utóbb megtalálja azt az autoritatív választ tudó szervert, illetve azt a zónafájlt, amely az adott domain névhez tartozó erőforrás rekordokat tartalmazza. Természetesen most nem a domain névhez tartozó IP címre van szükségünk (az A erőforrás rekordra), hanem különböző szolgáltatásokra vonatkozó információkra. Szerencsére a DNS rendszer lehetővé teszi, hogy a zónafájlban többféle erőforrás rekord legyen és ezeket a rendszer el is küldi a lekérdezésre adott válaszban. Ezután a lekérdező feladata a kapott rekordok közül a neki szükségeseket kiválasztani és azokat értelmezni. Az ENUM lekérdezés a zónafájlban elhelyezett NAPTR (Naming Authority Pointer) erőforrás rekordokra kíváncsi, mert ezek tartalmazzák a számára fontos információkat. A NAPTR rekordokban olyan bejegyzéseket találhatunk, amelyek további erőforrások elérésének módját, helyét mondják meg az ún. URI (Uniform Resource Identifier) szintaxis szerint. A különböző szolgáltatásokhoz különböző URI-kat találunk, illetve egy szolgáltatáshoz találhatunk több URI-t, amelyekhez különböző preferencia szint van megadva. Az ENUM alkalmazás tehát a DNS lekérdezésre válaszul egy URI listát kap, amelyből kiválasztja az adott szolgáltatáshoz, az adott helyzetben megfelelőt (pl. email üzenet küldéséhez szükségeset). A következő lépés függ az adott szolgáltatástól, de rendszerint az következik, hogy az URI domain név részét véve az alkalmazás egy újabb DNS lekérdezést hajt végre, ímmár az URIból nyert domain névre vonatkozóan és így jut hozzá ahhoz az IP címhez, amely címen már a tulajdonképpen elérni kívánt szolgáltatással, számítógéppel közvetlenül kapcsolatba léphet. A folyamatot leegyszerűsítve úgy vázolhatjuk, hogy a hagyományos domain név -> IP cím feloldás elé egy megelőző lekérdezés kerül, amely során a telefonszámból képzett domain névből egy szolgáltatás specifikus domain névhez és protokoll megválasztáshoz jutunk.


- 38 -


5.2 A kikeresett információ értelmezése

5.2.1 Az ENUM adatmodell A zónafájlban található ENUM specifikus adatok formátumát, értelmezését az RFC 3401 3405 (Dynamic Delegation Discovery System) dokumentumokban találhatjuk. Ahhoz, hogy a zónafájlba helyezett információkról teljes képünk legyen, mind az öt dokumentumot el kell olvasni. A DDDS dinamikusan konfigurálható delegációs rendszereket támogat azzal, hogy segítségével egy egyedi karaktersorozathoz (pl. domain névhez) különböző adatokat lehet hozzárendelni. A DDDS valójában egyfajta adatbázis, amely egy domain névhez tartozik. Az adatbázisban NAPTR rekordokat találunk. A NAPTR rekordok transzformációs szabályokat is tartalmaznak, amelyeket esetenként több lépésben kell alkalmazni a karaktersorozatra, amíg a végső állapothoz és adatokhoz eljutunk. Az RFC 3403 szabvány meghatározza, hogy a domain név rendszert hogyan kell a transzformációs szabályokat is tartalmazó adatbázisként használni ahhoz, hogy egy DDDS alkalmazás azt hasznosítani tudja. Az RFC 3403 szabvány érvényteleníti az RFC 2915 (The Naming Authority Pointer (NAPTR) DNS Resource Record) szabványt. Az ENUM-ot egy lehetséges DDDS alkalmazásnak kell tekintenünk, amelyet az RFC 2916bis ír le. Annak érdekében, hogy több DDDS alkalmazás is ugyanazt az adatbázist használhassa, valamiképpen meg kell különböztetni az egyes NAPTR rekordokat, hogy melyik alkalmazásra vonatkoznak. Az ENUM alkalmazásra azon NAPTR rekordok vonatkoznak, amelyek a Szolgáltatás mezőben az E2U azonosítót tartalmazzák. A zónafájlban található NAPTR rekord felépítése megfelel az erőforrás rekordokra vonatkozó általános szabályoknak. A címke azonos a domain névvel, a ttl elhagyható, az osztály: IN, a típus: NAPTR. Az "adatok" mező, a NAPTR rekord specifikus része, a következő almezőket tartalmazza: Sorrend (Order), Preferencia (Preference), Jelző (Flag), Szolgáltatás (Service), Regexp, Helyettesítés (Replacement). A Sorrend mezőben egy pozitív egész szám van. Ez a szám határozza meg azt a sorrendet, ahogy az egyes NAPTR rekordokat fel kell dolgozni ahhoz, hogy az általuk leírt szabályokat a megfelelő sorrendben alkalmazzuk. Az alacsonyabb sorrendszámú rekordok feldolgozása megelőzi a magasabb sorszámúakét. Ha a feldolgozás során olyan NAPTR rekordhoz érünk, amely passzol a keresetthez (találat), a magasabb sorrendszámú rekordokat már nem szabad figyelembe venni. A Preferencia mezőben egy pozitív egész szám van. Ez a szám azt a sorrendet határozza meg, ahogy az azonos sorrendszámmal rendelkező NAPTR rekordok feldolgozása javasolt. Az alacsonyabb preferenciaszámot tartalmazó rekordoknak van nagyobb preferenciájuk. A Az ENUM hazai megvalósításának előkészítése

- 39 -

Az ENUM technológia mező azt a célt szolgálja, hogy a domain gazdája például nagyobb teljesítményű szerver gépek felé irányítsa vagy az általa előnyben részesített protokoll használatára késztesse a kliens alkalmazást. A lekérdező kliens alkalmazásnak módjában áll eldönteni, hogy figyelembe veszi-e ezt az ajánlást vagy nem (például esetleg nem veszi figyelembe, mert az előnyben részesített protokollt nem beszéli és ezért a kevésbé preferált, de működő protokollt választja). A Sorrend és Preferencia mezők között az a lényeges különbség, hogy a kliensnek találat estén nagyobb Sorrend számú rekordot már nem szabad figyelembe vennie, ám azonos sorrendszámú, de különböző preferenciaszámú rekordok közül még válogathat. A Jelző mezőben egy karakter van (A-Z, 0-9). A karakter különböző szabályrendszereket azonosít, amelyek szerint a további teendők és a rekord mezői értelmezendők. Napjainkig négy Jelzőt definiáltak: "S", "A", "U", "P". Ezek közül most az ENUM-mal kapcsolatos "U" Jelző érdemel részletesebb kifejtést. Az "U" azt jelzi, hogy a következő lépés nem egy DNS lekérdezés, hanem a Regexp mezőben egy URI található, amely megfelel az RFC 2234 és RFC 2396 ajánlásnak. Az "U" egyben azt is jelzi, hogy az itteni név átírási szabályt nem követi újabb. A Szolgáltatás mezőben szolgáltatást és protokollt azonosító karaktersorozat található. Az ENUM-mal kapcsolatos Szolgáltatás mező mindenek előtt tartalmazza az ENUM-ra utaló E2U (E.164 to URI resolution) karaktersorozatot. Ezt követi egy ún. ENUMszolgáltatás azonosító (+ jel és szöveg), amit egy protokoll azonosító követ (: jel és szöveg). Pl. "E2U+message:mailto". Az ENUMszolgáltatás és protokoll azonosító párosból több is állhat egymás után. Pl. "E2U+talk:sip+message:sip". Néhány ENUMszolgáltatás és protokoll azonosítót már definiáltak, de a szabvány nyitott, megfelelő műszaki javaslatok esetén az IANA újabbakat vesz nyilvántartásba. A Regexp mezőben a szolgáltatás elérhetőségét meghatározó adatok megállapítására vonatkozó kifejezéseket, utasításokat találunk. Ez egy transzformációs szabály, amely alapján az eredeti domain névből megkapjuk a keresett szolgáltatáshoz tartozó adatokat. A transzformáció szintaxisát az RFC 3402-3404 ajánlás tárgyalja. A Helyettesítés mezőt akkor használjuk, ha nincs szükség speciális transzformációs szabály alkalmazására, hanem az eredeti domain nevet egyszerűen, teljes egészében egy új domain névvel kell helyettesíteni. Az ENUM ezt a mezőt nem használja.

5.2.2 Az ENUM alkalmazások működésének általános sémája Ezek után vizsgáljuk meg az ENUM alkalmazások működési modelljét. Egy tipikus ENUM alkalmazás működése a következő (8. ábra): 1. Az alkalmazás (azaz az ENUM kliens) előállítja az E.164 formátumú számból a domain nevet. Pl.: +36 1 234 5678 Æ 3.6.1.2.3.4.5.6.7.8. e164.arpa (ld. 5.1.3 pontban) 2. Az ENUM kliens szoftver egy DNS lekérdezést indít az előállított domain névre. 3. A lekérdezésre válaszul az ENUM NS-től (ENUM nyilvántartók névszerveitől) megkapja az adott zónafájlban tárolt, kért domain névhez tartozó erőforrás (NAPTR) rekordokat. 4. Az alkalmazás az NAPTR rekordok közül kikeresi az adott típusú szolgáltatásra vonatkozó bejegyzéseket.


- 40 -

Az ENUM technológia 5. A bejegyzések tartalma alapján – amennyiben az adott szolgáltatás megvalósításához szükség van rá – további hagyományos, domain név Æ IP cím feloldó lekérdezéseket kezdeményez. ENUM 1.szint Nyilvántartó NS

ENUM frissítések

ENUM 2.szint Nyilvántartó NS

ENUM Regisztrátor

NAPTR rekordok

NAPTR rekord lekérdezések

ENUM Előfizető

ENUM rendszer ENUM rendszerre épülő alkalmazás

ENUM alkalmazás kliens

Alkalmazás szerver

Alkalmazás kliens szoftver

Az alkalmazások által megteremtett kommunikációs kapcsolat

ENUM felhasználó

8. ábra ENUM alkalmazás általános működési sémája

Az egyes szolgáltatások megvalósításához különböző típusú információt kell az NAPTR rekordokban tárolni. Az, hogy egy adott NAPTR rekord melyik szolgáltatásra vonatkozó információt tartalmazza az NAPTR rekord Szolgáltatás mezője fogja azonosítani az 5.2.3.1 fejezetben leírt formátumban. Az NAPTR rekordok általános szintaktikája jól definiált az RFC 2916bis-ben. Ugyan az RFC 2916bis még nem hivatalos szabvány, azonban a vele kapcsolatos egyeztetés igen előrehaladott állapotában van. Fontos kiemelni, hogy az ENUM a szolgáltatások a szempontjából teljesen nyílt, mindenki olyan szolgáltatást, ill. hozzá tartozó NAPTR rekordot definiálhat, amit szeretne. Az egyes szolgáltatásokhoz tárolandó információ, ill. a tárolás formátuma jelenleg szabvány által nem szabályozott. Világszerte folynak kísérletek (trial-ek) az ENUM szolgáltatásokkal kapcsolatban. Vannak olyan ENUMszolgáltatások, amelyek NAPTR leírásának szintaxisára már véglegesnek tűnő


- 41 -

Az ENUM technológia javaslatok vannak, mások még képlékeny állapotban vannak. Azonban egyik esetben sem beszélhetünk hivatalosan elfogadott szabványokról. Ilyen körülmények között fennáll a veszélye annak, hogy a különböző országokban folyó kísérletekben ENUM szolgáltatásokat megvalósító rendszerek nem tudnak együttműködni egymással. Ennek az inkompatibilitásnak a veszélye nagy, hiszen az egyes ENUMszolgáltatások bevezetését célzó kísérletek különböző országokban folynak, így az ENUM-os domain névhez tartozó bejegyzéseket (NAPTR rekordokat) különböző Regisztrátor rögzíti.

ENUM Regisztrátor

ENUM kísérlet 1

ENUM kísérlet 2

ENUM 1. szint Nyilvántartó NS


ENUM frissítések



ENUM Regisztrátor

NAPTR rekordok

NAPTR rekordok

ENUM Előfizető

ENUM frissítések

ENUM Előfizető



ENUM alkalmazás kliens

Alkalmazás szerver Az alkalmazások által megteremtett kommunikációs kapcsolat

Alkalmazás kliens szoftver

Az alkalmazások által megteremtett kommunikációs kapcsolat

ENUM felhasználó

9. ábra Különböző ENUM kísérleti alkalmazások együttműködése

A 9. ábrán olyan rendszer működését láthatjuk, melyben több ENUM kísérleti rendszerek működik. A domain nevek lekérdezésekor az ENUM kliens számára transzparens, hogy melyik Regisztrátor által rögzített telefonszámhoz tartozó domain nevet kérdezi le. Az ábrán jól látható, hogy a kliens a domain névtől függően bármelyik NS-től kaphat választ, vagyis nem biztos, hogy a saját kísérletében résztvevő Regisztrátor által rögzített NAPTR rekordot fogja megkapni. Ha különböző kísérletekben használt NAPTR rekordokban tárolt információ nem kompatibilis egymással, az ENUM kliens nem fog tudni az alkalmazás számára értelmezhető NAPTR rekordokat lekérdezni, ill. tovább adni.

5.2.3 Együttműködési követelmények Annak veszélye, hogy az egyes kísérletekben kidolgozott, ENUMszolgáltatásokat megvalósító rendszerek nem tudnak együttműködni a következő elvek betartásával jelentősen csökkenthető:


- 42 -

Az ENUM technológia − Az ENUM kliensnek azt kell feltételezni, hogy az ENUM-hoz tartozó DNS bejegyzések az e164.arpa domain alatt vannak bejegyezve. − Az E.164 formátumú telefonszámok alapján képzett domain nevek bármelyik kliens által lekérdezhetők az RFC 2916bis-ben és az RFC 1035-ben rögzített szabványos mechanizmussal. − Az ENUM kísérletekben résztvevő ENUM Előfizetőknek meg kell adni legalább egy Application Service Provider által üzemeltett URI-t (pl. e-mail, Web, stb.). − Az ENUM kliensnek képesnek kell lenni domain neveket lekérdezni és NAPTR rekordokat tartalmazó bejegyzéseket kiértékelni. − Az NAPTR rekordok formátumának meg kell felelni az RFC 3403-nak, az RFC 2916bis-nek, valamint az NAPTR rekordban szereplő Szolgáltatás (ENUMszolgáltatás) mezőt az 5.3 fejezetben leírt formátumban kell használni. − Az ENUM kliensek képesnek kell lennie konvertálni az E.164-nek megfelelően +NNN formátumban megadott telefonszámot az RFC 2916bis 2 pontjában rögzített szabályok szerint e164.arpa-ra végződő domain névvé. − Az ENUM kliensek által használt DNS Resolver-nek minden CNAME és DNAME erőforrás rekordot transzparensen kell kezelnie. − Az NAPTR erőforrás rekordoknak (Resource Record) az ENUM kliens számára értelmezhetőnek és feldolgozhatónak kell, melynek különböző aspektusai vannak: •

•

•

•

Az erőforrás rekordokban tárolt információt a rekordot nyilvánosságra hozó és az azt lekérdező azonosan értelmezze. Ennek érdekében az ENUM kísérletek egy közös (alap)halmazát definiálták az ENUMszolgáltatásoknak melyek azonosítói az ENUM-hoz tartozó NAPTR rekordok Szolgáltatás mezőjében szerepelhetnek. A definiált ENUMszolgáltatások definiálják az ENUM-ban használt URI Sémák egy közös (alap) halmazát is. Mint említettük, a használható ENUMszolgáltatások és URI Sémák az 5.3. fejezetben kerülnek felsorolásra. Ez nem jelenti azt, hogy egy ENUM kliensnek minden, a listában szereplő ENUMszolgáltatást támogatnia kell. Fel kell ismernie a listában szereplő ENUMszolgáltatások jelentését és a nem támogatott ENUMszolgáltatások és URI Sémák esetén előre definiált módon kell viselkednie.

Fontos megjegyezni, hogy a fenti felsorolás a kísérletek együttműködésének követelménye. Teljesen elfogadott azonban, hogy az egyes kísérleteken belül a fenti elsorolásban nem szereplő alkalmazásokat (szolgáltatásokat) teszteljenek, és ennek megfelelően ezeknek az alkalmazásokhoz tartozó erőforrás rekordokat tároljanak. Mivel az ENUM domainek fizikailag bárhonnan elérhetőek az ENUM kliensek a lekérdezések eredményeként kaphatnak olyan erőforrás rekordokat, melyeket azok egyáltalán nem támogatnak, ill. értelmeznek, pl. komplex reguláris kifejezéseket tartalmazó (RegExp) mezőt, vagy akár nem teljes NAPTR rekordot. Ezért az ENUM klienseket fel kell készíteni erre az esetre is. Ez azt jelenti, hogy előre definiált módon kell reagálniuk: • •

nem értelmezett erőforrás rekordok esetén, nem támogatott szolgáltatások esetén, ill.


- 43 -

Az ENUM technológia •

akkor, ha nem teljes NAPTR rekord érkezik, vagy más probléma lép fel.

Ezen követelmények megvalósításához fontos, hogy a ENUM kliensek felismerjék a komplex reguláris kifejezéseket (RegExp mezőt) tartalmazó rekordokat, és ha nem támogatják a reguláris kifejezések feldolgozását, akkor ne próbálják meg tévesen felhasználni a félig feldolgozott rekordot. 5.2.3.1 NAPTR rekordok formátuma és feldolgozása

− Az NAPTR rekordok formátumának meg kell felelni az RFC 3403-ban rögzítetteknek. Az NAPTR rekordok a következő mezőket tartalmazhatják: Sorrend (Order), • Preferencia (Preference), • Jelző (Flag), • Szolgáltatás (Service), • Reguláris kifejezés (RegExp), • Helyettesítés (Replacement). − Az ENUM kísérletek együttműködésének biztosítása érdekében az NAPTR rekordokra vonatkozó általános előírásokhoz képest a következő egyszerűsítések javasoltak: •

•

•

•

• •

•

Az ENUM kliensek figyelmen kívül hagyhatnak minden olyan NAPTR rekordot, mely nem ”U” Jelzőt tartalmaz. A Jelző értéke mindig ”U”, és sosem lehet üres, tehát a megkapott NAPTR rekordot nem követi újabb lekérdezés. Ebből következik, hogy a Helyettesítés mező mindig üres. Egy ENUM domainben minden NAPTR rekordban a Sorrend mező értékét azonos értékre kell beállítani (pl. 10). A Preferencia mezőt használhatják az ENUM Előfizetők, méghozzá arra, hogy megadják, hogy milyen sorrendben kapják meg a különböző kapcsolati pontjaikat (pl. alternatív telefonszámaikat) az ENUM felhasználók. Az ENUM kliens rendezheti az NAPTR rekordokat a Preferencia mező alapján, de ez nem kötelező előírás. A reguláris kifejezés mezőben az elválasztó karakter a ”!”. Minimális követelményként az ENUM kliensnek nem kötelező olyan reguláris kifejezés mezőt feldolgozni, mely nem kizárólag az URI megnevezését szöveges formában tartalmazó karakterlánc, hanem olyan, amelyikben van illeszkedő mintától (matching part) függő következő rész (consequent part), pl. olyan ahol a karakterláncban ”\1” szerepel. Azonban ebben az esetben is, amikor a kliens nem képes bonyolult reguláris kifejezéseket feldolgozni, képesnek kell lennie felismerni a nem kizárólag egyszerű szöveget tartalmazó reguláris kifejezés mezőt és nem szabad az ilyen kifejezést tartalmazó NAPTR rekordot elfogadnia, és főleg semmiképpen sem szabad az ilyen karakterlánc direkt felhasználását megkísérelnie. A reguláris kifejezés (RegExp) mező két részből áll: illeszkedő részből (matching part) és az azt követő következő (consequent part) részből. Mindaddig, amíg lehetséges az illeszkedő rész csak teljesen illeszkedő mintát tartalmazzon, úgy, hogy a következő rész a teljes helyettesítését tartalmazza, az illeszkedő rész újra használata nélkül. Ez a szabály a következő feldolgozó parancsként értelmezhető ”dobd el a bemeneti karakter sorozatot és helyettesítsd


- 44 -


•

a következő részben talált karakterlánccal”! Ez a reguláris kifejezés formátuma szerint a következőképpen néz ki: „!^.*$!teljes-URI”, ahol a teljes-URI a teljes, URI-t azonosító karakterláncot tartalmazza. Az ENUM kliensek nem feltétlenül kötelező támogatni ENDS (extended length) opciót tartalmazó lekérdezéseket. Megjegyzés: Az ENDS (extended length) flag bekapcsolásával és a hossz paraméter megadásával beállíthatjuk, hogy a lekérdezés eredményeként kapott válaszok maximális hossza a paraméterben megadott legyen. Ha nem használjuk ezt az opciót, a válaszok maximális hossza az alapértelmezett 500 byte lesz. Ha a szerver a lekérdezésre adott válaszában több adatot akar küldeni, mint az így kiszámolt maximum, a válaszban beállítja a turncated flag-et. Ha a kliens ilyen félbevágott, nem teljes választ kap, még egyszer elküldheti a lekérdezést TCP-n keresztül. Amennyiben az ENUM DNS szervere támogatja a TCP-n keresztül történő lekérdezéseket, a kliens megkapja a teljes választ. Hozzá kell tennünk, hogy ha DNSSEC-et használunk, az kizárja olyan kliens használatát, mely nem támogatja az (extended length) opciót, mivel a DNSSEC secure válaszok általában hosszabbak az alapértelmezett 500 byte-os limitnél.

•

•

•

•

Annak érdekében, hogy lehetővé tegyük ENDS opció használatát nem támogató ENUM kliensek és TCP kapcsolatot nem támogató DNS szerverek együttes használatát a lekérdezések eredményének hosszát kb. 500 bájtban kell korlátozni. Ennek megfelelően az egy lekérdezhető domainben tárolt, adott névhez tartozó NAPTR rekordok számát úgy kell korlátozni, hogy beleférjen ebbe a méret korlátba. Ez kb. 5 NAPTR rekordot jelent domainenként, amely korlátot természetesen csak akkor kell figyelembe venni, ha nem használunk DNSSEC-et. A fentiek alapján látható, hogy minden ENUM kliensnek fel kell készülni arra, hogy félbevágott, nem teljes NAPTR rekordokat kap, és ezt megfelelően le kell kezelnie. Továbbá arra is fel kell készülnie a kliensnek, hogy az ENUM-hoz tartozó bejegyzéseket tároló DNS szerver nem támogat TCP kapcsolatot. Az ENUM klienseknek ellenőrizni kell, hogy az NAPTR rekord Szolgáltatás mezőjében egynél több ”+” jel szerepel-e, és ezt helyesen úgy kell értelmeznie, hogy az adott NAPTR rekord egynél több ENUMszolgáltatáshoz tartozik. Az a javasolt eljárás, hogy az ilyen több szolgáltatáshoz tartozó NAPTR rekordokat a kliens úgy kezelje, jelenítse meg, mintha több NAPTR rekordot kapott volna, melyek mindegyike csak egy ENUMszolgáltatáshoz tarozna. A kliens tehát konvertálja a kombinált NAPTR rekordokat több egy szolgáltatást tartalmazó NAPTR rekorddá. Megjegyzendő, hogy ha a kliens által megkapott NAPTR rekord több olyan szolgáltatáshoz tartozik melyek URI sémája különböző, vagy az adott, Szolgáltatás mező alapján azonosított szolgáltatás URI sémája nem egyezik meg a Reguláris kifejezés (RegExp mező) által tárolt azonosítóval, akkor az NAPTR rekord hibás, és az ENUM kliensnek vissza kell azt utasítania. A kombinált, több szolgáltatáshoz tartozó NAPTR rekordokra vonatkozó szabályok alól egy kivétel van. Ha az NAPTR rekord „sip” vagy „h323” ENUMszolgáltatáshoz tartozik, akkor ezek nem szerepelhetnek kombináltan, pl. E2U+sip+h323. Ez azért van így, mert ezek a szolgáltatások dedikáltan kö-


- 45 -

Az ENUM technológia tődnek egy-egy URI-hoz, vagyis ezen szolgáltatásokhoz tartozó kombinált NAPTR rekord több URI-t kellene, hogy tartalmazzon.

5.3 ENUMszolgáltatások és a hozzájuk tartozó URI sémák

5.3.1 ENUMszolgáltatások minimális alaphalmaza Minden ENUMszolgáltatás definíciónak a következő formátumúnak kell lennie: típus:altípus az RFC 2916bis szerint, kivéve a sip és a h323 szolgáltatásokat, amelyekben csak típus megnevezés szerepel. A következő definíciókban az altípus helyén szereplő azonosító az NAPTR rekordban tárolt URI sémával megegyezik. 5.3.1.1 ENUMszolgáltatások média stream átvitelre

Ez az ENUMszolgáltatás mező olyan erőforrás azonosítására szolgál, amely interaktív (media stream exchange) hívások lebonyolítására alkalmas.

5.3.1.1.1 Hang átviteli szolgáltatások − voice:sip − voice:h323 − voice:tel Ezek az ENUMszolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben az URI által azonosított erőforrások olyan kommunikációs kapcsolatot képesek létesíteni mely kapcsolat hang átvitelére alkalmas.

5.3.1.1.2 Videó átviteli szolgáltatások − video:sip − video:h323 − video:tel Ezek az ENUMszolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben az URI által azonosított erőforrások olyan kommunikációs kapcsolatot képesek létesíteni mely kapcsolat kép (videó jel) átvitelére alkalmas. 5.3.1.2 ENUMszolgáltatások egyedi üzenet küldésre

Ez a csoportja az ENUMszolgáltatás mezőknek olyan erőforrások azonosítására szolgál mely alkalmas különálló (egyedi) (non-session related) üzenetek vagy dokumentumok fogadására. Ezt a csoportját az ENUMszolgáltatás mezőknek akkor kérdezi le a kliens alkalmazás, ha üzeneteket (pl. faxot) akar a címzettnek küldeni. − email:mailto


- 46 -

Az ENUM technológia Ez az ENUMszolgáltatás mező olyan NAPTR rekordokat jelöl, melyekben azonosított távoli erőforrás képes e-mail-eket fogadni. − fax:tel Ez az ENUMszolgáltatás mező olyan NAPTR rekordokat jelöl, melyekben azonosított erőforrás képes fax üzeneteket fogadni. − sms:tel Ez az ENUMszolgáltatás mező olyan NAPTR rekordokat jelöl, melyekben azonosított erőforrás képes Short Message Service (SMS) üzeneteket fogadni. − ems:tel Ez az ENUMszolgáltatás mező olyan NAPTR rekordokat jelöl, melyekben azonosított erőforrás képes Extended Message Service (EMS) üzeneteket fogadni. − mms:tel Ez az ENUMszolgáltatás mező olyan NAPTR rekordokat jelöl, melyekben azonosított erőforrás képes Multimedia Message Service (MMS) üzeneteket fogadni. 5.3.1.3 ENUMszolgáltatások információforrásokra

Ezek az ENUMszolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított erőforrások információforrások lehetnek. Ezek a szolgáltatások az üzenet küldő szolgáltatások ellentétei, hiszen ezek az információ adói, míg az előzőekben ismertetett üzenetküldők az információ „nyelői”. − web:http − web:https Ezek az ENUMszolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított erőforrásokhoz kapcsolódhatunk web protokollon keresztül, vagyis Web szervereket azonosít a megadott URI. − ftp:ftp Ezek az ENUMszolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított erőforrásokhoz kapcsolódhatunk ftp protokollon keresztül, fájlokat másolhatunk fel és tölthetünk le. 5.3.1.4 ENUMszolgáltatások szolgáltatást feloldó (engedélyező) szolgáltatásokhoz

Ezt a csoportját az ENUMszolgáltatásoknak akkor használjuk, ha az ENUM Előfizető az ENUM mellett az ENUM-tól független "Service Resolution Service" szolgáltatást akarja használni. Erre akkor van szükség, ha az ENUM szolgáltatások köre olyan tényezőktől függ, amelyeket az ENUM rendszer nem kezel. Ilyen lehet például a ”hirdetés” szolgáltatás, amikor is a hirdetést küldő (jelen esetben a lekérdezést indító) személyének azonosítása után küldhető csak vissza a kért információ. − sip − h323


- 47 -

Az ENUM technológia Ez az egyetlen olyan szolgáltatás, ahol a protokoll rész nem használt. Erről az ENUMszolgáltatásról az [1] és [2] dokumentumok tartalmaznak bővebb információt. 5.3.1.5 ENUMszolgáltatások session-oriented üzenet küldésre

Ezek az ENUMszolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított távoli erőforrás alkalmas chat-elésre (chat sessions – session-oriented message exchanges). Ez különbözik a korábban említett e-mail szolgáltatástól, ahol különálló leveleket lehetet küldeni. − tp:tel Ez az ENUMszolgáltatás mező olyan NAPTR rekordokat jelöl, melyekben az URI által azonosított távoli erőforrás alkalmas szöveges telefonon (textphone) történő kommunikációra. Az ilyen rendszerek PSTN-en keresztül továbbítanak szöveges információt távoli terminálokra. Halláskárosultak által általánosan használt szolgáltatás. − im:sip Ezzel az ENUMszolgáltatás mezővel jelzett NAPTR rekordokban olyan távoli erőforrás van azonosítva, melyek alkalmas session-orientált azonnali üzenet vételére. 5.3.1.6 ENUMszolgáltatások hirdetmények megjelenítésére

Az ENUMszolgáltatások ezen csoportja olyan szolgáltatásokat jelöl, ahol az ENUM Előfizető az ENUM kliensen keresztül közvetlen üzeneteket tud küldeni a az ENUM felhasználónak. − ann:sip − ann:h323 − ann:tel Ezek az ENUMszolgáltatások előre eltárolt üzeneteket továbbítanak. − ann:http − ann:ftp Ezekhez az ENUMszolgáltatásokhoz tartozó rekordok olyan Web oldalakat azonosítanak, amelyek párhuzamosan szöveges és hang üzeneteket is tárolnak. Az ilyen üzenetek különösen fontosak a látás és halláskárosult emberek számára. Az a javasolt eljárás, hogy az azonosított erőforrások mindkét típusú információt tárolják pl. beágyazott linkek segítségével. Megjegyzendő, hogy ez a szolgáltatás a tárolt információ automatikus közlését jelenti. Ez az ENUM kliensek esetén nem feltétlenül megvalósítható, a szolgáltatás megvalósításának részletei a kísérleti alkalmazások során tisztázandó. 5.3.1.7 ENUMszolgáltatások átirányítása

Ez az ENUMszolgáltatás különleges abból a szempontból, hogy magában foglalja az összes többi ENUMszolgáltatást. A cél az volt, hogy egy alapértelmezett ENUMszolgáltatást lehessen definiálni. Ezt arra lehet használni, hogy az adott NAPTR rekordban ne kelljen tovább részletezni, hogy rekordban megnevezett erőforrás milyen szolgáltatásokat támogat. Az ilyen rekordot definiáló ENUM Előfizető kijelenti, hogy az NAPTR rekordban leírt erőforrás(ok) Az ENUM hazai megvalósításának előkészítése

- 48 -

Az ENUM technológia minden szolgáltatást támogat(nak). Ez azonban a gyakorlatban azt jelenti, hogy a végfelhasználónak tovább fel kell dolgoznia az NAPTR rekordot kifejtve a reguláris kifejezést annak érdekében, hogy azonosítani tudja a benne definiált URI-t és eldönthesse, hogy a szóban forgó NAPTR rekordot fel tudja használni, vagy el kell dobnia. − all:ENUM 1. Megjegyzés: Ez a bejegyzés használható akár arra, hogy az Előfizető egy másik aldomainbe átirányítsa az ENUM felhasználót, ahol az előfizető az igazi NAPTR bejegyzéseit tárolja, vagy akár arra, hogy a 1. szintű nyilvántartón keresztül egy másik domainbe. 2. Megjegyzés: Az [3] dokumentumban definiált "ENUM:" URI séma azonos az [4] dokumentum által definiált "tel:" URI sémával mindenféle paraméter nélkül, csak E.164 telefonszámokat használva. Fejlesztőknek célszerű figyelembe venni, hogy az "ENUM:" URI helyett használható a "tel:" URI ugyanazokkal a korlátozásokkal.

5.3.2 További ENUMszolgáltatások Ezen ENUMszolgáltatások megvalósítása előtt további vizsgálatok szükségesek. 5.3.2.1 ENUMszolgáltatások helymeghatározásra

Ez az ENUMszolgáltatás mező jelzi, hogy a hozzá társított erőforrás képes földrajzi elhelyezkedés azonosítására alkalmas információt adni. A tervek szerint az információt Geography Markup Language (GML) segítségével lehet elérni. − loc:http 5.3.2.2 ENUMszolgáltatások nyilvános kulcs (Public Key) megadására

Ez az ENUMszolgáltatás mező jelzi, hogy a hozzá társított erőforrásról lehetséges Public Key lekérdezése. − key:ldap − key:http

5.3.3 ENUM kliensek által lekérdezett információ feldolgozása 5.3.3.1 Általános ENUM kliens

Az általános ENUM kliensnek kell lekérdeznie a DNS-től adott domainhez tartozó összes NAPTR rekordot. Az általános ENUM kliensnek fel kell ismernie az 5.3.1 fejezetben megadott ENUM szolgáltatások minimális halmazát: − Ez nem jelenti azt, hogy az ENUM klienst használó alkalmazásnak minden, az 5.3.1 fejezetben megadott listában szereplő szolgáltatást támogatnia kell.


- 49 -

Az ENUM technológia − Az azonosított (kliens által ismert) ENUMszolgáltatás mezőket tartalmazó NAPTR rekordokhoz a kliens az adott szolgáltatás típusának megfelelő opciókat kínálhatja fel. Az ENUM kliensnek meg kell jeleníteni azokat az ENUM szolgáltatásokat, melyekhez a lekérdezett NAPTR erőforrás rekordok tartoznak. Ha például az ENUMszolgáltatás „E2U+voice:sip”, a hozzá tartozó URI „sip:[email protected]” a kliens felajánlhatja a felhasználónak a „Hívja fel telefonon” opciót. Kivételek: Az „all” ENUMszolgáltatás esetén az URI sémában adott E.164 számot kell használni a további ENUM lekérdezésekhez, és a kapott NAPTR-ek az 5.3.1.7 ENUMszolgáltatások átirányítása c. fejezetben leírt módon kell megjeleníteni. Ez az jelenti, hogy az ENUM klienseknek mindig először az „all:ENUM” ENUMszolgáltatást kell lekérdeznie. Ha van ilyen ENUMszolgáltatáshoz tartozó NAPTR, akkor további lekérdezéseket kell végrehajtani az ”ENUM:” URI sémával megadott ENUM domainre. A végtelen hurkok elkerülésére a kliensnek maximum 5 ilyen átirányítást kell csak figyelembe vennie. Ha az ENUM kliens talált „ann:http” ENUMszolgáltatást, akkor ezt külön jeleznie kell. (Ez a szolgáltatás a lekérdezett számhoz tárolt hirdetmények megjelenítését jelenti.) Az ENUM kliensnek meg kell jelenítenie az összes olyan „ann:http” ENUMszolgáltatást melyek megjeleníthetők az ENUM kliens felhasználói terminálján. Az ENUM kliensek megjeleníthetik (lejátszhatják) az „ann:sip”, „ann:h323” és „ann:tel” szolgáltatásokat amennyiben a felhasználói terminál képes ilyen szolgáltatásokat fogadni, ill. megjeleníteni. (Ezek a szolgáltatások különböző formátumban tárolt üzeneteket jeleznek.) Az ENUM kliensnek lehetővé kell tennie a felhasználó számára, hogy elindíthassa a kliens által megjelenített ENUM szolgáltatásokhoz, ill. URI sémákhoz hozzárendelt, adott típusú szolgáltatást megvalósító alkalmazást. Az ENUM kliensek indíthatják az alkalmazásokat önállóan, vagy nyújthatnak rendelkezési felületet a felhasználónak, ahol hozzárendelhet alkalmazás klienseket az adott „típus:altípus” formában megadott ENUMszolgáltatásokhoz. Például megadhatja a felhasználó, hogy melyik H323 alkalmazás kliens induljon, ha az ENUM kliens talált „voice:h323” NAPTR erőforrás rekordot és a felhasználó használni szeretné ezt a szolgáltatást. A nem támogatott ENUMszolgáltatásokhoz tartozó NAPTR rekordokat az ENUM kliens vagy nem jeleníti meg, vagy valamilyen módon megkülönbözteti a többi rekordtól. A megkülönböztetés módját (ill. azt, hogy egyáltalán megjeleníti-e) vagy globálisan az ENUM kliens vagy az ENUM felhasználó állítja be. 5.3.3.2 ENUM-képes alkalmazás kliens

Az összes rendelkezésre álló (adott helyen elérhető) alkalmazás klienst indíthatja egy általános ENUM kliens. Maguk az alkalmazás kliensek is végezhetnek közvetlen ENUM lekérdezéseket. Ezeket a klienseket ENUM-képes alkalmazás klienseknek nevezik. Az ENUM-képes alkalmazás kliensek csak azokat az ENUMszolgáltatásokat kell támogatniuk, melyek használatára tervezték őket. Az ENUM igénybevétele az E.164 szám „cél” mezőbeli, +NNN formátumban való megadásával történik.


- 50 -

Az ENUM technológia Azoknál az alkalmazásoknál, melyek közvetlenül megértik az E.164 számokat (pl. PC telefonok), megengedett, hogy külön konfigurálni lehessen, hogy egy adott szolgáltatás megvalósítása előtt végezzenek-e először ENUM lekérdezést. Minden ENUM-képes alkalmazás kliensnek mindig először az „all:ENUM” ENUMszolgáltatást kell lekérdeznie. Ha van ilyen ENUMszolgáltatáshoz tartozó NAPTR, akkor további lekérdezéseket kell végrehajtani az ”ENUM:” URI sémával megadott ENUM domainre. A végtelen hurkok elkerülésére a kliensnek maximum 5 ilyen átirányítást kell csak figyelembe vennie. Ha az ENUM-képes alkalmazás kliens talált „ann:http” ENUMszolgáltatást, akkor ezt külön jeleznie kell. (Ez a szolgáltatás a lekérdezett számhoz tárolt hirdetmények megjelenítését jelenti.) Az ENUM-képes alkalmazás kliensnek meg kell jelenítenie az összes olyan „ann:http” ENUMszolgáltatást melyek megjeleníthetők az ENUM-képes alkalmazás kliens felhasználói terminálján. Az ENUM-képes alkalmazás kliensek megjeleníthetik (lejátszhatják) az „ann:sip”, „ann:h323” és „ann:tel” szolgáltatásokat amennyiben a felhasználói terminál képes ilyen szolgáltatásokat fogadni, ill. megjeleníteni. (Ezek a szolgáltatások különböző formátumban tárolt üzeneteket jeleznek.) Az ENUM-képes alkalmazás kliensnek meg kell keresnie az összes olyan NAPTR erőforrás rekordot, melyek olyan ENUMszolgáltatásokhoz tartoznak, melyek az adott alkalmazás kliens által megvalósított szolgáltatással kapcsolatosak. Ha nem található olyan NAPTR rekord mely az alkalmazás kliens számára felhasználható ENUM szolgáltatást tartalmaz, akkor az ENUM-képes alkalmazás kliensnek ezt tudatnia kell a felhasználóval. Ennek a jelzésnek eltérőnek kell lennie a „domain nem található” jelzéstől. 5.3.3.3 Példák ENUM-képes alkalmazás kliensekre

− ENUM-képes SIP kliens − ENUM-képes H323 kliens − ENUM-képes email kliens − ENUM-képes Web browser − ENUM-képes FTP kliens − ENUM-képes fax kliens − ENUM-képes SMS kliens − ENUM-képes helyinformációs kliens Az előző fejezetben leírt ENUM-képes alkalmazás kliensekre vonatkozó általános előírásokon felül a különböző szolgáltatást megvalósító alkalmazás kliensekre további előírások vonatkozhatnak a különböző kísérletekben megvalósított alkalmazás kliensek által nyújtott szolgáltatások kompatibilitásának biztosítása érdekében. Példaként megadunk egy ilyen alkalmazás kliensre vonatkozó leírást. Ezek teljes listája a [4] dokumentumban található.


- 51 -

Az ENUM technológia 5.3.3.4 ENUM-képes SIP kliens

Az ENUM-képes SIP kliens először a „sip” ENUMszolgáltatáshoz tartozó NAPTR rekordokat kell keresnie. Ha megtalálta a „sip” ENUMszolgáltatáshoz tartozó NAPTR rekordot, akkor az abban található SIP URI által definiált végponttal veszi fel a kapcsolatot. Ha nem található „sip” ENUMszolgáltatáshoz tartozó NAPTR rekord, akkor az ENUM-képes SIP kliensnek kereshet „voice:sip” ENUMszolgáltatáshoz tartozó NAPTR rekordot, és ha talál ilyet, akkor létesít csak hang átvitelére alkalmas összeköttetést. Attól függően, hogy milyen szolgáltatásokat kínál fel a felhasználóknak az adott ENUMképes SIP kliens, megkeresheti a „voice:tel”, „video:sip és „video:tel”, azután a „email:mailto” „fax:tel” és „im:sip” ENUMszolgáltatáshoz tartozó NAPTR rekordokat az adott típusú szolgáltatások felajánlása érdekében.


- 52 -

ENUM adatok adminisztrálása

6 ENUM adatok adminisztrálása Ebben a fejezetben az ENUM adatokkal kapcsolatos adminisztrációs feladatokat és szereplőket mutatjuk be. Az adatok adminisztrálása a megvalósításból adódóan szorosan kapcsolódik a DNS rendszerhez, így a feladatok áttekintését is ezzel kezdjük.

6.1 Adminisztrációs szintek a DNS rendszerben

6.1.1 Az ENUM gyökér kezelése Az ENUM gyökér (.e164.arpa) két részből, az e164 domainből és az arpa domainből áll. Az internetes szervezetek (ICANN, IANA, IETF, ISOC és IAB) és az ITU közötti egyeztetés eredményeképpen az e164.arpa domaint a RIPE NCC kezelésébe adták azzal, hogy a RIPE NCC pedig az ITU-val egyeztetve, annak hozzájárulásával végzi a .e164.arpa alá a domainek delegálását. Az ITU minden egyes E.164 szerinti országkód számnak megfelelő tagállam hozzájárulása után engedélyezi az adott számhoz tartozó domain delegálását a tagállam által megjelölt nyilvántartónak a RIPE NCC-n keresztül. A RIPE NCC ellenőrzi és felügyeli a műszaki feltételek meglétét és amennyiben a nyilvántartó a műszaki feltételeket teljesíti, a delegálást elvégzi. Az ENUM gyökér megnevezésére az ITU bevezette a Tier 0 (0. szint) jelölést. Ennek a szintnek a kezelése nincs az ország hatáskörében.

6.1.2 Az országhoz tartozó domain kezelése A nyilvántartó kezeli az E.164 szám országkód szintű domaint (pl. .6.3.e164.arpa). Az ehhez tartozó zónafájlban találhatók azok a mutatók (autoritatív névszerver rekordok), amelyek a teljesen meghatározott domain névhez (pl. 8.7.6.5.4.3.2.1.6.3.e164.arpa) hozzárendelik a végfelhasználók ENUM erőforrás rekordjait tartalmazó adatállományok internetes helyét. A nyilvántartó a végfelhasználó telefonszámából képzett domain névhez regisztrálja a végfelhasználó által megadott mutatókat (az autoritatív névszerver rekordokat) és azokat a globális DNS rendszerben elérhetővé teszi, fenntartja. A regisztrációnak adminisztratív és műszaki feltételei vannak, amit jellemzően egy nyilvános "Regisztrációs szabályzat" ír le. Az ország hívószámhoz tartozó szint megnevezésére az ITU bevezette a Tier 1 (1. szint) jelölést.

6.1.3 A regisztrált aldomainek kezelése A regisztrált aldomainekben kezelik az adott E.164 szerinti számhoz rendelkezésre álló ENUM szolgáltatásokról információt adó erőforrás rekordokat. Az ehhez szükséges névszerverek, adatállományok lehetnek közvetlenül a végfelhasználó kezelésében, illetve tulajdonában lévő számítógépeken vagy a végfelhasználó megbízhat ezzel egy NS szolgáltatót, aki a folyamatos elérhetőséget biztosítja, a beállításokat a végfelhasználó rendelkezései alapján elvégzi. A regisztrált szint megnevezésére az ITU bevezette a Tier 2 (2. szint) jelölést.


- 53 -


6.2 Az adminisztráció szereplői Az ENUM gyökér kezelésében résztvevő szereplőkkel részletesebben nem foglalkozunk, mivel a nemzeti hatáskörön, befolyáson kívül esnek. Részletesen foglalkozunk viszont a következő szereplők feladat és hatáskörével: felügyelő testület, nyilvántartó, regisztrátor, hitelesítő, NS szolgáltató, regisztrált. A szereplők közül több szervezet – elsősorban az Internetes infrastruktúra szervezetei – már a célnak megfelelően jelenleg is működnek (nyilvántartó, regisztrátorok, NS szolgáltatók). Néhány szervezetet újonnan kell létrehozni, ilyen a felügyelő testület, esetleg a hitelesítők.

6.2.1 Felügyelő testület A nemzeti hatáskörbe tartozó ügyekkel kapcsolatos döntésekbe, a szabályok meghozatalába, a szereplők közötti esetleges viták rendezésébe célszerű lehet bevonni az ENUM infrastruktúra működésében érdekelt szereplőket, illetve azok képviselőit. Egy ilyen felügyelő testület tagjai lehetnek a szabályozó és felügyelő intézmények képviselői (minisztérium, hatóság, Internetes önszabályozó szervezetek), a szolgáltatók (internet szolgáltatók, vezetékes és mobil szolgáltatók, nyilvántartó és regisztrátorok) és a felhasználók képviselői, továbbá független műszaki és jogi szakértők is. A felügyelő testület tevékenysége az alábbi területekre terjedhetne ki: − a regisztrációt, a szereplők együttműködését meghatározó szabályzatok elfogadása, − a szabályok működésének felügyelete, szükség szerint a szabályok módosítása, korszerűsítése, − a szabályok betartásával kapcsolatos vitákban állásfoglalás, döntés.

6.2.2 Nyilvántartó A nyilvántartó fenntartja az E.164 országkód szintű domainhez tartozó autoritatív névszervereket és zónafájlt. A zónafájlban őrzi a végfelhasználók telefonszámához tartozó mutatókat (névszerver rekordokat). A regisztrátorok számára lehetővé teszi ezen rekordok elhelyezését, módosítását. A globális DNS rendszerben biztosítja a zóna információk folyamatos, redundáns elérhetőségét. A nyilvántartó továbbá regisztrációs adatbázis rendszert tart fenn, amelyben felhasználói mutatókat és azokhoz kapcsolódó metaadatokat őriz (módosítások időpontját, módosító személyét, a regisztrátor személyét, a végfelhasználó és kapcsolattartóinak kilétére, elérhetőségére vonatkozó adatokat stb.) és tesz hozzáférhetővé a jogosultak számára. A nyilvántartó nincs közvetlen kapcsolatban a regisztráltakkal. Az ENUM domain nevet regisztrálni kívánó jogi vagy természetes személyek a regisztrátorokhoz fordulhatnak az ügyintézés, a szolgáltatás megrendelése, fenntartása, illetve lemondása érdekében. A nyilvántartó sok regisztrátorral áll szerződéses kapcsolatban, akik számára azonos feltételekkel, meghatározott díjazásért hozzáférést biztosít az országkód szintű regisztrációs adatbázishoz. Az érdekütközések elkerülése érdekében a nyilvántartó feladatot ellátó szervezet nem lehet egyben regisztrátor is. A nyilvántartó lényegi feladata, hogy stabilan működjön, minden körülmények között biztosítsa az országkód szintű regisztrációs adatbázis fenntartását, a zóna információk elérhetőségét és a regisztrációs szabályok egységes betartását. A regisztrátorok viszont egymás közötti piaci versenyben működnek, díjaikat maguk állapítják meg, bármikor új regisztrátorok léphetnek a piacra, illetve kedvezőtlen esetben regisztrátorok tűnhetnek el a piacról.


- 54 -

ENUM adatok adminisztrálása A nyilvántartó feladata, hogy a nemzetközi ajánlások és tapasztalatok alapján, valamint a hazai szereplőkkel történő konzultáció után kidolgozza a regisztrációt, a szereplők együttműködését meghatározó szabályzatok tervezetét és ezeket jóváhagyásra a felügyelő testület elé terjessze. A továbbiakban részletesen foglalkozunk a nyilvántartó egyes feladataival. 6.2.2.1 Névszerverek és zóna információk

A zónafájlban találhatók azok a technikai információk, amelyek a DNS rendszer működéséhez szükségesek. A nyilvántartó által őrzött zónafájlban olyan mutatók kerülnek elhelyezésre, amelyek a végfelhasználói névszerverek (elsődleges és egy vagy több másodlagos) helyét határozzák meg. A végfelhasználói névszerverek helyére vonatkozó ezen információkat a regisztrátorok a nyilvántartó adatbázisában helyezik el, illetve módosítják szükség szerint, a végfelhasználók igényei szerint. A nyilvántartó feladata, hogy az adatbázisban tárolt adatokból időről időre új zónafájlt generáljon, majd ezt a zónafájlt elhelyezze az 1. szint elsődleges és egy vagy több másodlagos névszerverén. A nagyobb biztonság, megbízhatóság érdekében több másodlagos névszervert szokás üzemeltetni, továbbá az egyes névszervereket földrajzi és hálózati értelemben egymástól távoli pontokra célszerű elhelyezni, hogy valamilyen meghibásodás vagy katasztrófa ne bénítson meg egyszerre több 1. szintű névszervert is. A DNS rendszer normál működés során automatikusan elvégzi azokat az információcseréket, amelyek ahhoz szükségesek, hogy az elsődleges névszerveren frissített zónafájl áttöltődjön a másodlagos névszerverekre is. A nyilvántartó feladatai a következők: − rendszeres időközönként frissítenie kell a zónafájlt a nyilvántartói adatbázis legújabb állapota alapján, hogy a zónafájl tükrözze a regisztrátorok által kezdeményezett módosításokat az adatbázisban, − a legenerált zónafájlt megbízható és biztonságos eljárással, az IETF szabványok maradéktalan betartásával haladéktalanul továbbítania kell valamennyi 1. szintű névszerverhez, − legalább kettő, de lehetőleg 4-6 névszervert kell közvetlenül vagy más szervezetekkel történő megállapodás alapján működtetnie, amely névszerverek egymástól földrajzi és hálózati értelemben elkülönült helyen vannak, hogy valamilyen meghibásodás vagy katasztrófa ne bénítson meg egyszerre több 1. szintű névszervert is, − a zónafájl frissítés gyakoriságát és a továbbítással eltöltött időt az ENUM infrastruktúra működtetésében érdekelt főbb szereplőkkel egyeztetve kell előzetesen meghatároznia, és az üzemeltetés során ennek megfelelően kell következetesen eljárnia, − a zónafájl frissítési és továbbítási eljárásokat gondosan kell megterveznie és megvalósítania, hogy az ne okozzon problémákat a regisztrátorok adatbázis hozzáférésében, az első szintű névszerverek folyamatos működésében, továbbá a párhuzamos eljárások miatt ne képződhessenek inkonzisztens adatállományok, − a zónafájl frissítésekhez kapcsolódóan megfelelő naplózási és adat-visszaállítási eljárásokról kell gondoskodnia, − gondoskodnia kell arról, hogy a regisztrátorok a zónafájl adatait csak közvetve, a nyilvántartói adatbázison keresztül módosíthassák, viszont gondoskodnia kell arról is, hogy megfelelő interfész álljon a regisztrátorok rendelkezésére ahhoz, hogy az adatbázisban ezeket az adatokat közvetlenül, a nyilvántartói személyzet bevonása nélkül is módosítani tudják. Az ENUM hazai megvalósításának előkészítése

- 55 -

ENUM adatok adminisztrálása 6.2.2.2 Regisztrációs adatbázis rendszer

A nyilvántartónak fenn kell tartania egy olyan adatbázist, amelyben az ENUM domainek regisztrációjával kapcsolatban szükséges és megőrzendő valamennyi adat megtalálható, a megfelelő jogosultság mellett bevihető, módosítható, lekérdezhető. A nyilvántartónak működtetnie kell egy olyan hozzáférési rendszert is, amely lehetővé teszi a regisztrátorok számára az adatbázishoz való hozzáférést (a hozzáférési jogosultságokat ellenőrizve), bizonyos ellenőrzések és állapotváltozások automatikus végrehajtását, továbbá egyes kimenő adatállományok (pl. zónafájl és whois) előállításához a megfelelő kigyűjtések és formátum átalakítások elvégzését. A regisztrációs adatbázis rendszernek a következő képességekkel kell rendelkeznie: − a jogosult regisztrátorok számára, azok számától függetlenül kell diszkrimináció mentes, konkurens hozzáférést nyújtania az adatbázishoz, − nyilván kell tartani a regisztrátorok elérhetőségi adatait (velük egyeztetett módon), az egyes regisztrátor szervezeteknél regisztrációt végző személyeket és hozzáférési azonosítójukat, jogosultságaikat, − az egyes regisztrátorok számára lehetővé kell tenni, hogy saját ügyfeleik (a regisztráltak) adatait a rendszerbe felvihessék, módosíthassák és lekérdezhessék, − lehetővé kell tenni, hogy miközben egy regisztrált ügyfél valamely regisztrátortól megválik és a szolgáltatást a továbbiakban egy másik regisztrátornál veszi igénybe, eközben a nyilvántartó DNS szolgáltatása az érintett ENUM domainre a váltás miatt ne szüneteljen, − nyílt szabványokon alapuló interfészen keresztül kell a regisztrátorok számára hozzáférést biztosítani az adatbázishoz (pl. böngésző http, https protokollok, vagy xml felület, az EPP ajánlás valamely adaptált változata), − legalább a következő információknak kell helyet biztosítani az adatbázisban minden egyes regisztrált domainhez: domain név, névszerverek, regisztrált adatai (név, cím, telefon, fax, email), adminisztratív kontakt adatai (név, cím, telefon, fax, email), műszaki kontakt adatai (név, cím, telefon, fax, email), regisztrátor kiléte, beregisztrálás időpontja, az utolsó módosítás időpontja, jelenlegi státusz, − a regisztrátorok által kiadott parancsokra nézve alapszintű szintaktikai ellenőrzést kell elvégezni (illegális parancsok, hiányzó attribútumok stb.), − megfelelő mechanizmusokat kell működtetni annak megakadályozására, hogy ugyanaz a domain név több regisztrátorhoz, illetve több regisztrálthoz tartozhasson, − megfelelő mechanizmusokat kell működtetni annak megakadályozására, hogy a jogosultakon kívül az adatokat más is módosíthassa, − valamely ENUM domain név regisztrálását megelőzően el kell végezni a műszaki feltételeknek való megfelelésre vonatkozó ellenőrzést (a regisztrálás csak akkor történhet meg, ha műszaki hiba nincs), − a tranzakciókat naplózni kell, a végrehajtott tranzakciókról a regisztrátorok számára is hozzáférhető archívumot kell fenntartani, − gondoskodni kell a regisztrációs adatbázis mentéséről és a gyors adat-visszaállítási eljárásokról, illetve a rendszer megfelelő teljesítményéről és tartalékolásáról,


- 56 -


6.2.3 Regisztrátorok Az ENUM domain nevet regisztrálni kívánó jogi vagy természetes személyek (a regisztráltak) a regisztrátorokhoz fordulhatnak az ügyintézés, a szolgáltatás megrendelése, fenntartása, illetve lemondása érdekében. A regisztrátorok feladata, hogy a regisztrációt igénylők megrendeléseit felvegyék, ellenőrizzék az igények szabályosságát, ellenőrizzék (szükség szerint a hitelesítő bevonásával), hogy az igénylő jogosult-e az igényelt számot ENUM domain névként regisztráltatni, ellenőrizzék, hogy az igénylés a műszaki feltételeknek megfelel-e. Ha az igénylés szabályos, akkor a regisztrátor a nyilvántartó által fenntartott adatbázisban elhelyezi a regisztrált domain (Tier 2) szintű névszervereit kijelölő mutatóit. A regisztrátorok feladata a regisztrációk fenntartása, az adatokban bekövetkezett változások rögzítése a regisztrációs rendszerben. A regisztrátornak folyamatosan kapcsolatot kell tartania megbízójával és rendszeres időközönként (általában évente) ellenőriznie kell, hogy a regisztrálás feltételei továbbra is fennállnak-e. A regisztrátor köteles felmondani a regisztráció fenntartására vonatkozó megbízást, ha a regisztráció már nem felel meg a szabályoknak. A regisztrátor jogosult üzleti megfontolásból felmondani a regisztráció fenntartására vonatkozó megbízást (a megbízási szerződésben foglaltak szerint), ez esetben a regisztrált másik regisztrátorral köthet új megbízási szerződést. Maga a regisztrált is jogosult a megbízás viszszavonására (a megbízási szerződésben foglaltak szerint) és választhat másik regisztrátort. Amennyiben tehát a regisztráció a követelményeknek megfelel a rendszer nem akadályozza, hogy a regisztráltak az igényeiknek legmegfelelőbb regisztrátor szolgáltatását vegyék igénybe. Ugyanakkor a regisztrátoroknak sincs szolgáltatási kötelezettségük. A regisztrátorok egymás közötti piaci versenyben működnek, díjaikat maguk állapítják meg, bármikor új regisztrátorok léphetnek a piacra, illetve kedvezőtlen esetben regisztrátorok tűnhetnek el a piacról. Valamely szervezet a nyilvántartóval kötött szerződéssel nyeri el a regisztrátori licenszet. Mivel a regisztrátor munkálkodása bizalmat igényel (jogosultságot bírál el, adatokhoz fér hozzá, adatokat módosíthat, szolgáltatásokat tehet elérhetővé vagy elérhetetlenné stb.), ezért jogos, ha a nyilvántartóval kötött szerződés fenntartásának feltétele az ilyen bizalom megalapozottsága. Ha a regisztrátor tevékenysége során szabálytalanságot követ el, akkor vele szemben szankciók alkalmazandók, végső soron vissza kell vonni regisztrátori licenszét.

6.2.4 Hitelesítő Különböző módon történhet annak megállapítása, hogy valamely jogi vagy természetes személy használatában van-e az a telefonszám, amelyhez kapcsolódó ENUM domain regisztrációját igényli. Az adott országban meglévő vagy egyszerűen kialakítható nyilvántartási rendszertől függ, hogy a jogosultság ellenőrzésének milyen formáját célszerű választani. Ha létezik a telefonszámoknak és használóiknak egy központi nyilvántartása vagy csak néhány telefonszolgáltató van és azok rendelkeznek ilyen nyilvántartással, akkor megszervezhető, hogy ezekhez a nyilvántartásokhoz hitelesítő szolgáltatás működjön, azaz a nyilvántartó rendszeréből érkező kérdésekre (x telefonszámnak y a használója?) a hitelesítő jóváhagyás kiadása (természetesen mindez elektronikus úton) megtörténhessen. A hitelesítő szolgáltatás azonban ebben a formájában szükség esetén ki is hagyható. A hitelesítés történhet például úgy is, hogy a regisztrált mutat be igazolást (pl. friss telefonszámlát) Az ENUM hazai megvalósításának előkészítése

- 57 -

ENUM adatok adminisztrálása arról a regisztrátornak, hogy jelenleg ő a telefonszám jogos használója. Mobil telefonszám esetében a hitelesítés elképzelhető például SMS alapú visszaigazolással (ha elfogadjuk azt az egyébként elég valószínűnek tekinthető vélelmet, hogy a telefon birtoklója a szám használója). Ha a regisztrátor azonos a regisztrált telefonszolgáltatójával, akkor a hitelesítést a regisztrátor saját szervezetén belül tudja megoldani. Több megfelelő módszer alkalmazható tehát a központi hitelesítés szolgáltatás elhagyásával is.

6.2.5 NS szolgáltató Az NS szolgáltató a regisztrált megbízása alapján fenntartja a NAPTR rekordokat szolgáltató névszerver(eke)t. Olyan folyamatos, megbízható szolgáltatást kell nyújtania, ami megfelel egyrészt az ENUM domain regisztrációs szabályoknak, műszaki előírásoknak, másrészt megfelelően biztos alapot szolgáltat az erre épülő további ENUM szolgáltatásnak. Az NS szolgáltató feladatát elláthatja egy regisztrátor funkciót ellátó szervezet is, de maga a regisztrált is gondoskodhat saját infrastruktúrájával erről. Az NS szolgáltató köteles a műszaki követelmények határai között a regisztrált kívánságainak megfelelő beállításokat, konfigurálásokat elvégezni.

6.2.6 Regisztráltak A regisztráltak azok a jogi vagy természetes személyek, akik úgy döntenek, hogy telefonszámuknak megfelelő ENUM domaint kívánnak regisztráltatni. A regisztrált feladata, hogy teljesítse a regisztráció feltételeit, kiválasszon egy regisztrátort, akivel szerződést köt a szolgáltatásra, továbbá gondoskodjon (maga vagy szolgáltató bevonásával) a NAPTR rekordok szolgáltatásáról, állandó internetes elérhetőségéről legalább két szerveren. A regisztrált felelősséget visel azért, hogy lemondja az ENUM domain fenntartását, ha a kapcsolódó telefonszámnak már nem ő az előfizetője.

6.3 Interfészek a szereplők között

6.3.1 Regisztrált és regisztrátor Ezen az interfészen a regisztrátorral szerződött regisztrált számára biztosítani kell, hogy − megadhassa a regisztrációval kapcsolatos adatokat, − módosíthassa, aktualizálhassa a regisztrált adatokat, − megújíthassa a fenntartást, − más jogosult javára lemondhasson a regisztrációról, − felmondhassa a regisztrációt. Az interfészen keresztül a regisztrátornak értesítéseket kell tudnia küldeni a regisztrált számára legalább a következőkről: − visszaigazolás a regisztrált utasításának (adatmódosítás, megújítás, lemondás, felmondás) végrehajtásáról, Az ENUM hazai megvalósításának előkészítése

- 58 -

ENUM adatok adminisztrálása − tennivalókról műszaki ügyekben (pl. hiba a műszaki feltételek teljesítésében), − tennivalókról adminisztratív ügyekben (díjfizetési kötelezettség, jogosultsági probléma stb.), − regisztrátor felmondási szándékáról. A regisztrátor hatáskörébe tartozik, hogy milyen interfészt alakít ki a fenti kommunikáció céljára. A hagyományos (papír, aláírás, posta) interfésztől kezdve az internetes lehetőségeket is kihasználó módszerekig (pl. jelszavas elektronikus út, böngésző, email) bármi választható. Az elfogadható eljárás(ok)ról a szolgáltatási szerződésben kell rendelkezni.

6.3.2 Regisztrált és NS szolgáltató Ezen az interfészen az NS szolgáltatóval szerződött regisztrált számára biztosítani kell, hogy − megadhassa a névszerverbe, a NAPTR rekordba kerülő adatokat, − módosíthassa, aktualizálhassa a névszerverbe, a NAPTR rekordba kerülő adatokat, − megújíthassa a szolgáltatást, − felmondhassa a szolgáltatást. Az interfészen keresztül az NS szolgáltatónak értesítéseket kell tudnia küldeni a regisztrált számára legalább a következőkről: − visszaigazolás a regisztrált utasításának (adatmódosítás, megújítás, felmondás) végrehajtásáról, − tennivalókról műszaki ügyekben (pl. hiba a NAPTR rekordban, névszerver áthelyezés), − tennivalókról adminisztratív ügyekben (pl. díjfizetési kötelezettség, NS szolgáltató adatai vagy azok változása a műszaki kontakt adatok megadásához), − NS szolgáltató felmondási szándékáról. Az NS szolgáltató hatáskörébe tartozik, hogy milyen interfészt alakít ki a fenti kommunikáció céljára. A hagyományos (papír, aláírás, posta) interfésztől kezdve az internetes lehetőségeket is kihasználó módszerekig (pl. jelszavas elektronikus út, böngésző, email) bármi választható. Az elfogadható eljárás(ok)ról a szolgáltatási szerződésben kell rendelkezni.

6.3.3 Regisztrátor és nyilvántartó Ezen az interfészen a nyilvántartóval szerződött regisztrátor számára lehetővé kell tenni, hogy saját ügyfeleik (a regisztráltak) adatait a rendszerbe felvihessék, módosíthassák és lekérdezhessék. A regisztrátornak a nyilvántartói adatbázisban el kell tudni helyeznie az ügyfelei egyes domainjeihez tartozó következő adatokat: − domain név − domain névszerverei − regisztrált objektuma •

regisztrált neve


- 59 -

ENUM adatok adminisztrálása regisztrált azonosítója későbbi módosításokhoz • regisztrált postacíme • regisztrált elérhetősége telefonon (ha más, mint a domain névhez tartozó szám) • regisztrált elérhetősége faxon (ha van ilyen) • regisztrált elérhetősége emailen (ha van ilyen) − adminisztratív kontakt objektuma •

adminisztratív kontakt neve • adminisztratív kontakt postacíme • adminisztratív kontakt elérhetősége telefonon • adminisztratív kontakt elérhetősége faxon (ha van ilyen) • adminisztratív kontakt elérhetősége emailen (ha van ilyen) − műszaki kontakt objektuma •

műszaki kontakt neve • műszaki kontakt postacíme • műszaki kontakt elérhetősége telefonon • műszaki kontakt elérhetősége faxon (ha van ilyen) • műszaki kontakt elérhetősége emailen A regisztrátornak képesnek kell lennie arra, hogy jelezze a regisztrációs rendszer számára az egyes domainekre vonatkozó •

− regisztrációs igényt, − módosítási igényt, − felmondási igényt. Az interfészen keresztül a regisztrátornak le kell tudni kérdeznie a következő információkat: − az ügyfelei domainjeire vonatkozó összes olyan adatot, amit ő vitt be az adatbázisba, továbbá a beregisztrálás időpontját • az utolsó módosítás időpontját • az utolsó módosítást végrehajtó személy nevét • a domain státuszát (regisztrálásra vár, regisztrált, felmondott) − az általa fenntartott domainekre vonatkozó összesítő adatokat, így •

az általa fenntartott domainek teljes listáját • egy kiválasztott időszakban regisztrált domainek listáját • egy kiválasztott időszakban módosított domainek listáját • egy kiválasztott ügyfél domainjeinek listáját • egy kiválasztott névszerverrel kiszolgált domainek listáját − az ügyfelei domainjeire vonatkozó tranzakciók archivált listáját •

A fenti kommunikáció céljára a nyilvántartónak kell megfelelő elektronikus interfészt kialakítania. A legkézenfekvőbb megoldás egy biztonságos Web szerver szolgáltatás (https protokollal), amelyet a regisztrátorok az elterjedt böngésző programokkal, mint kliensekkel tudnak


- 60 -

ENUM adatok adminisztrálása használni. Ez a megoldás semmilyen olyan speciális licenszt, technikai tudást vagy pénzügyi áldozatot nem kíván a regisztrátoroktól, ami az egyenlő esélyű hozzáférést gátolhatná. Kiegészítésként javasolt az xml alapú kommunikáció is, amelyre a regisztrátorok saját alkalmazási klienseket fejleszthetnek. Bár az ilyen típusú hozzáférés esetében a regisztrátori munka megkezdéséhez el kell készíteni a megfelelő kliens programot, ezután viszont előnyként jelentkezhet, hogy a kliens teljes mértékben a regisztrátor szája íze szerint alakítható ki és kapcsolható össze a regisztrátornál esetlegesen működő egyéb rendszerekkel (pl. számlázó rendszer). Erre a célra dolgozták ki az EPP-t (Extensible Provisioning Protocol), amely azonban jelenlegi formájában csak az alapvető tranzakciók leírására képes és ezért a különböző nyilvántartóknál számos "helyi" variánsa létezik. Mivel a nemzetközi előírások meglehetős szabadságot hagynak az országoknak az 1. szint szabályozásában, ezért a közlejövőben nem várható, hogy nemzetközileg teljesen egységes adminisztrációs szabályok jöjjenek létre, így a nyilvántartó-regisztrátor közötti adminisztrációs interfész sem lesz a közeljövőben olyan mértékben egységesíthető, hogy például egy regisztrátor bármely ország nyilvántartójával ugyanazon eljárással kommunikálhasson.

6.4 Adminisztratív folyamatok Az ENUM domainek regisztrálásával kapcsolatos ügyeket az alábbi csoportokba sorolhatjuk: − új regisztráció − módosítás regisztrált domain adataiban regisztrált személyében bekövetkezett változás (átruházás) • regisztrált elérhetőségi adataiban bekövetkezett változás • névszerverek változása • adminisztratív és műszaki kontakt személyében bekövetkezett változás • adminisztratív és műszaki kontakt adataiban bekövetkezett változás − regisztráció megújítása vagy felmondása •

− regisztráció törlése − regisztrátor váltás Új regisztrációkor a regisztrátor számára adminisztratív feladatot jelent annak megállapítása, hogy a regisztrálást igénylő jogosult-e a kapcsolódó telefonszám használatára, előfizetője-e az adott telefonszámnak? A nyilvántartó ezt a jogosultságot általában nem, legfeljebb panaszra vagy szúrópróba szerűen tudja ellenőrizni, ezért különösen fontos, hogy a regisztrátor feladatát gondosan, megbízhatóan, visszaélésektől mentesen lássa el. A módosítások egy része érzékeny adatokra vonatkozik. Ilyen a regisztrált személye, hiszen ő mindenben jogosult rendelkezni a domainnel kapcsolatban. Ha jogosulatlan részére történik átruházás vagy nem jogosult rendelkezését fogadja el a regisztrátor, akkor abból a jogosult számára számos káros következmény adódhat. Ezért a regisztrációkor a néven kívül (ami nem feltétlenül egyedi) általában a regisztrált valamilyen azonosítóját is rögzítik (személyi igazolvány számát, adószámát) és módosítások esetén ez segít az azonosításban. Érzékeny adat a névszerverek helye is, hiszen rossz beállítás miatt például a szolgáltatások nem működnek vagy illetéktelenek férhetnek hozzá a kommunikációs csatornákhoz. Nem tartozik az érzékeny adatok körébe például a regisztrált fax száma, mivel ez önmagában nem alkalmas visszaélés-


- 61 -

ENUM adatok adminisztrálása re. A regisztrátoroknak érzékeny adatok módosítás kérésénél megfelelő ellenőrző adminisztrációs eljárásokat kell működtetniük, hogy a jogosulatlan módosítást megakadályozzák. A regisztrátor vagy a regisztrált is dönthet úgy, hogy a regisztrációt megújítja vagy esetleg éppen felmondja. A regisztrátornak megfelelő adminisztratív eljárásokat kell működtetnie, hogy ellenőrizze, a regisztrált felmondását a jogosult adta-e ki, illetve hogy regisztrátori felmondás esetén az erről szóló értesítést a jogosult regisztrált vagy adminisztratív kontaktja megkapta-e. Regisztráció törlésére kerülhet sor, ha a regisztrált azt kéri. Regisztráció törlésére kerülhet még sor akkor is, ha a regisztrátornak hitelt érdemlően tudomására hozzák, hogy az adott telefonszámnak előfizetője már nincs vagy a telefonszám előfizetője más, mint a kapcsolódó ENUM domain regisztráltja és az előfizető kéri a másnak történő regisztráció megszüntetését. A regisztrált értesítését a törlésről ilyenkor is meg kell kísérelni a regisztrált által megadott címen. Regisztrátor váltáskor az új regisztrátornak meg kell győződnie, hogy valóban a regisztrált rendeli meg nála a váltást. Ha erről meggyőződött, akkor a regisztrációs rendszerben kezdeményezi, hogy az adott domainnek ő legyen a regisztrátora. A regisztrációs rendszer erről értesíti a volt regisztrátort. A világban ezután kétféle eljárás szokásos. Az egyik szerint (pl. Németország) a régi regisztrátornak jóvá kell hagynia a váltást, amit megtagadhat, ha pl. a regisztrált nem rendezte a számlát, a másik szerint a régi regisztrátor nem akadályozhatja meg, hogy a regisztrált új regisztrátorhoz menjen át. Magyarországon az utóbbi rendszer működik a .hu közdomainek alatt. Sajnos a regisztráltak ilyen fokú védelme gyakran vezet a fizetés elmaradásához. Az eljárás megválasztását érdemes megfontolni.

6.5 Nyilvános információk A domain regisztráció hagyományos rendszerében a nemzetközi ajánlásoknak megfelelően általánosnak tekinthető, hogy a regisztrált domainnel kapcsolatos számos információ nyilvános, az Interneten un. whois szolgáltatás keretében bárki számára hozzáférhető. Jellemzően ilyenek: − domain név − domain névszerverei − regisztrált adatai regisztrált neve • regisztrált címe • regisztrált elérhetősége telefonon • regisztrált elérhetősége faxon (ha van ilyen) • regisztrált elérhetősége emailen (ha van ilyen) − adminisztratív kontakt adatai •

• • • • •

adminisztratív kontakt neve adminisztratív kontakt címe adminisztratív kontakt elérhetősége telefonon adminisztratív kontakt elérhetősége faxon (ha van ilyen) adminisztratív kontakt elérhetősége emailen (ha van ilyen)


- 62 -

ENUM adatok adminisztrálása − műszaki kontakt adatai műszaki kontakt neve • műszaki kontakt címe • műszaki kontakt elérhetősége telefonon • műszaki kontakt elérhetősége faxon (ha van ilyen) • műszaki kontakt elérhetősége emailen − regisztrátor adatai •

regisztrátor neve • regisztrátor címe • regisztrátor elérhetősége telefonon • regisztrátor elérhetősége faxon (ha van ilyen) • regisztrátor elérhetősége emailen − a beregisztrálás időpontja •

− az utolsó módosítás időpontja Az ENUM domainek regisztrációjakor két fontos szempontot is figyelembe kell venni. Az egyik, hogy az előfizetőknek joguk van "titkos" telefonszámon igénybe venni a telefonszolgáltatást. Amennyiben viszont a telefonszám alapján lekérdezett whois szolgáltatás megadná a regisztrált adatait, akkor ez a titkosság veszélybe kerülne. A probléma megoldható úgy is, hogy az előfizető megbízást ad valakinek, hogy ő legyen a telefonszámnak megfelelő ENUM domain regisztráltja, de ez a bonyodalom elkerülhető, ha a regisztrált adatait a whois szolgáltatás nem is adja ki. Ez a megoldás a másik fontos szempont figyelembe vételével adódik. Arról van szó, hogy a hagyományos domain regisztrációhoz képest jóval kevesebb jogvita, érdeksérelem képzelhető el harmadik fél vonatkozásában az ENUM domainek regisztrációjakor. Egy bizonyos ENUM domain név egy előfizetői telefonszámmal egyértelműen megfeleltethető, így a jogosultság az előfizetésből elég egyértelműen következik. Így nem fűződik ahhoz méltányolható érdek, hogy a regisztrált adatait a jogérvényesítést segítendő bárki megtudhassa. Hasonló okból az adminisztratív kontakt adatait sem látszik szükségesnek nyilvánosságra hozni. Adminisztratív probléma esetén a regisztrátoron keresztül történő kapcsolatfelvétel ajánlható. Műszaki problémák viszont nagyon valószínűek, sőt az ENUM szolgáltatások újdonsága és bonyolultsága miatt várhatóan gyakoribbak lehetnek, mint a hagyományos domain regisztrációs környezetben. Ezért a műszaki kontakt (praktikusan az NS szolgáltató) közvetlen elérését erősen indokolt lehetővé tenni adatainak nyilvánosságra hozatalával. Ugyanakkor elvárható, hogy ha valaki (feltehetően inkább szolgáltatók, mint magánszemélyek) ilyen szolgáltatásra vállalkozik, akkor az ezzel járó nyilvánosságot vállalja. A fentiek alapján az ENUM domainekkel kapcsolatos nyilvános whois információkat az alábbi adatokra célszerű korlátozni: − domain név − domain névszerverei − műszaki kontakt adatai • • •

műszaki kontakt neve műszaki kontakt címe műszaki kontakt elérhetősége telefonon


- 63 -

ENUM adatok adminisztrálása műszaki kontakt elérhetősége faxon (ha van ilyen) • műszaki kontakt elérhetősége emailen − regisztrátor adatai •

regisztrátor neve • regisztrátor címe • regisztrátor elérhetősége telefonon • regisztrátor elérhetősége faxon (ha van ilyen) • regisztrátor elérhetősége emailen − a beregisztrálás időpontja •

− az utolsó módosítás időpontja

6.6 Vitarendezés A hagyományos domain név regisztráció mellé általában komoly vitarendező apparátust szokás telepíteni. Az ENUM típusú domain nevek esetében azonban csak igen kevés vita várható. Mindenekelőtt az ENUM domain neveknek nincs jelentéstartalma (pl. védjegy, cégnév), továbbá nem nyújthatnak be többen is azonos névre regisztrációs igényt, hanem csak a kapcsolódó szám előfizetője, vagy annak meghatalmazottja. Így sem a jelentéstartalommal, sem az elsőbbséggel kapcsolatos viták nem merülhetnek fel. Vitatható lehet esetleg, hogy valójában ki egy telefonszám előfizetője, ha a telefonszolgáltatók nyilvántartása erre nem tud egyértelmű választ adni, vagy abban hiba van. Ezek az esetek várhatóan a regisztrátor-nyilvántartó-telefonszolgáltató körben kivizsgálhatók és a felek számára megnyugtatóan rendezhetők. Arra az esetre, ha valamiért mégis olyan bonyolult helyzet adódik, hogy a rendezést valamelyik fél nem tartja elfogadhatónak, akkor javasolt, hogy az ügyet vizsgálja ki a felügyelő testület (illetve általa felkért független szakértő) és foglaljon állást a vitában. A regisztrátor és a nyilvántartó ezek után az állásfoglalásnak megfelelően jár el, ami ellen a panaszos (ha mindezek ellenére nem tartja elfogadhatónak a döntést) a polgári bírósághoz fordulhat.


- 64 -

ENUM rendszer a végfelhasználó szemével

7 ENUM rendszer a végfelhasználó szemével Az ENUM rendszerre épülő alkalmazások a végfelhasználók számára számos előnnyel szolgálhatnak. A legegyszerűbb példa lehet erre egy egyszerű VoIP kapcsolat felépítése, de számos fejlett szolgáltatási megoldás is elképzelhető az ENUM rendszerrel. Ebben a fejezetben ezeket a lehetőségeket foglaljuk össze.

7.1 ENUM felhasználók köre

7.1.1 ENUM felhasználók Az ENUM rendszer felhasználói különböző csoportokba sorolhatók aszerint, hogy a rendszer felhasználása és működtetése során milyen szerepet játszanak. Ezek a szerepek a következők lehetnek: − ENUM adminisztráció és működtetés ENUM Regisztrátor • ENUM NS szolgáltató − Szolgáltatók •

ENUM alkalmazásszolgáltató (ASP) • ENUM kliens szállítója − ENUM előfizető (regisztrált) •

− ENUM végfelhasználó

7.1.2 Végfelhasználók A végfelhasználók illetve végfelhasználói alkalmazások az ENUM rendszer segítségével, ENUM klienseket magukban foglaló alkalmazás kliensek igénybevételével kapcsolatot létesíthetnek az alkalmazásszolgáltatók ENUM rendszerben azonosítható szolgáltatási végpontjain található szolgáltatásokkal. A végfelhasználók számára mindez azt jelenti, hogy a szolgáltatók vagy operátorok által bevezetett és telefonszámokhoz kötött alkalmazások könnyen elérhetőkké vállnak. Az ENUM által szolgáltatott NAPTR rekordokban tárolt URI-k biztosítják a szám birtokosának különféle módokon, különféle szolgáltatásokon keresztüli elérhetőségét: telefon, fax, hangposta, email, üzenő szolgáltatás, weboldal, stb. Lehetővé válik a globális átirányítás, valamint fejlett telefonkönyv jellegű szolgáltatások nyújthatók.


- 65 -


7.2 ENUM szolgáltatások, alkalmazások

7.2.1 ENUM-ra épülő szolgáltatások Az ENUM-ra építet szolgáltatások az ENUM felhasználók szerepei szerint kategorizálhatók: − Szolgáltatók és operátorok tevékenységét hatékonyabbá tevő alkalmazások. − Végfelhasználókat (lakossági és vállalati) segítő, kiszolgáló alkalmazások. Ezek a szolgáltatások tovább kategorizálhatóak: információs szolgáltatások, • session orientált szolgáltatások, • fejlett szolgáltatások • fenntartási és karbantartási szolgáltatások. A szolgáltatás illetve alkalmazás szó ebben a kontextusban általában felcserélhető. Míg az Internetes környezetben általában alkalmazásokról beszélnek, addig a telekommunikációs szféra inkább a szolgáltatás elnevezést használja. •

Az ENUM-ra épített szolgáltatások vagy alkalmazások egyrészt hatékonyabbá tehetnek létező szolgáltatói megoldásokat. Másrészt, és vélhetően ez lesz az ENUM fő előnye új, kiterjesztett funkcionalitású alkalmazások létrehozását teszik lehetővé, melyek új szolgáltatásokra a telefonhálózatok és az Internet integrációja lesz a jellemző. Az alkalmazások fejlesztésének nehézsége a két rendszer szignifikáns tervezési, működtetési és technológiai eltéréseinek áthidalásában van.

7.2.2 Kiindulási és végződtetési pontok Az ENUM-ra épülő szolgáltatások működési modellje egyszerű. Egy felhasználó (hívó fél), aki azonosítható E.164 száma alapján, kapcsolatot létesíthet egy alkalmazás vagy terminál segítségével egy másik felhasználóval, vagy alkalmazással (hívott fél), aki szintén azonosítható E.164 száma alapján. A két félhez tartozó ENUM URI listák alapján különböző típusú szolgáltatások vagy alkalmazások vehetik fel egymással a kapcsolatot. Az alkalmazások meghatározásához tisztázni kell az adott szolgáltatás megvalósításakor szóba jöhető technológiai, adminisztratív és gazdasági szempontokat. Az alkalmazások kategorizálása abból a szempontból történhet, hogy mennyire konvencionális telefonszámok alkalmazása az adott kontextusban. Ez alapján megkülönböztethetünk különböző szolgáltatási kategóriákat: − tradicionális kommunikációs szolgáltatások, pl. PSTN-GSM, − kiterjesztett szolgáltatások, pl. IP telefónia (VoP)-PSTN, email-email, − konverziós szolgáltatások, pl. email-SMS. Az egyes területek (kommunikációs hálózatok) közötti átjárhatóságot az ENUM gateway-ek felhasználása teszi lehetővé (10. ábra). A gateway feladata elérhetővé tenni az ENUM által kezelt információt az adott kommunikációs hálózaton, ill. konvertálni az adatokat a hálózatok közötti adatátvitel esetén.


- 66 -


Alkalmazás kliens PSTN ENUM kliens ENUM végfelhasználó

GW GW

Internet PLMN

ENUM szolg. GW

10. ábra ENUM szolgáltatások kiindulási és végződtetési pontjai

A következő táblázatban lehetséges kiindulási és végződtető szolgáltatásokat soroltunk fel, melyek között van hagyományos távközlési szolgáltatások és Internetes alkalmazás is: Hálózat 1. Internet

Terminál/alkalmazás Dedikált IP telefon PC alapú IP telefon Chat Video Játékok Virtuális valóság E-mail File transfer Web browser Directory/Catalogue

2. PSTN

Telefon PABX terminal Telefon konferencia


- 67 -

ENUM rendszer a végfelhasználó szemével Hálózat

Terminál/alkalmazás Pager Fax Premium hívások Freephone hívások Nemzetközi hívások Other

3. PLMN

NMT GSM Voice GSM Fax GSM Voice mailbox GSM Nemzetközi hívás GSM voice mailbox, nemzetközi GSM/SMS GSM/MMS GSM/WAP GPRS EDGE UMTS

4. ISDN

Videó konferencia

5. Kábel TV 6. Egyéb

X.400 mail X.500 catalogue

Jelenleg, a táblázatban felsorolt szolgáltatások nem mindegyikéhez létezik definiált URI séma, ezen a területen további szabványosításra van még szükség. Bizonyos, különböző típusú hálózatban levő kiindulási és végződési pont kombinációknál meg kell határozni az értelmes átjárási lehetőségeket.


- 68 -


7.2.3 Végfelhasználói alkalmazások 7.2.3.1 Információs szolgáltatások

A végfelhasználók számára ezek az ENUM rendszerre épülő szolgáltatások közvetlen információs szolgáltatásként jelennek meg. A legalapvetőbb használat esetén az információs szolgáltatást megvalósító kliens alkalmazás visszaadja az ENUM lekérdezés által megszerzett URI listát. A kiterjesztett információs szolgáltatások a nyers URI-ken kívül járulékos információkat is szolgáltatnak, pl. postacím. Fontos felhasználási terület lehet a tarifa-információs szolgáltatás. Ekkor a végfelhasználó megtudhatja, hogy mekkora a költsége egy E.164 szám felhívásának hagyományos kapcsolaton keresztül vagy akár portoltan, valamilyen alternatív kommunikációs csatornán. 7.2.3.2 Session orientált szolgáltatások

A szolgáltatások ezen csoportja alatt azokat a szolgáltatásokat érthetjük, melyeknél az alkalmazások vagy terminálok kapcsolatot létesítenek egymással E.164 telefonszám alapján. Ezeknek a szolgáltatásoknak a körét az alkalmazások tervezői határozzák meg. Néhány lehetséges alkalmazási terület különböző végpontok összekapcsolásával (példák): − Tradicionális kommunikációs szolgáltatások Vezetékes PSTN telefonok közti kapcsolat felépítése. Ebben az esetben az ENUM használata akkor jöhet szóba, ha a két végoperátor között az Internet egy olcsóbb tranzit megoldásként jelenik meg. • Ugyanez lehet érvényes vezetékes és mobil, valamint mobil-mobil telefonok közötti kapcsolatlétesítés esetén. • A PSTN vagy PLMN telefonok és szolgáltatások közötti kapcsolat felépítés lehetővé teszi, hogy például premium és freephone szolgáltatásokat vegyünk igénybe E.164 számokon keresztül. • Lehetséges SIP telefonok közötti összeköttetés létesítés is. A SIP „telefonok” lehetnek dedikált IP telefonok vagy telefon funkcionalitású szoftverek. • Az SIP szoft- vagy hardver telefonok és PSTN vagy PLMN telefonok közötti összeköttetés lehetővé teszi, hogy SIP telefonokról vezetékes vagy mobil számokat hívjuk (földrajzi körzetek, nemzetközi hívások). Fordított irányban is igénybe vehetjük ezeket a szolgáltatásokat. − Konverziós alkalmazások és szolgáltatások •

•

• • •

Általános SIP és SIP végpontok összekötése változatos szolgáltatások megvalósítására vezethet. A végponti alkalmazások mindkét oldalon változatosak lehetnek: hang, videó, chat, interaktív játékok, virtuális valóság alkalmazások (ld. 11. ábra). Általános SIP alkalmazási végpontok és PSTN vagy PLMN összekötése. Email-ek konvertálása faxüzenetekké. Elektronikus dokumentumok konvertálása faxüzenetekké.


- 69 -

ENUM rendszer a végfelhasználó szemével Faxok konvertálása más elektronikus üzenetekké, például: email, elektronikus dokumentum, SMS, hangüzenet. A konverziós szolgáltatások használatával mód nyílik költség orientált célvégpont kiválasztásra. Amennyiben például rendelkezésre áll UPT szolgáltatás egy Internet címmel nem rendelkező E.164 számhoz, akkor lehetséges, hogy ENUM adatok alapján PSTN-PSTN hívásokat építsenek ki az érintett SIP szolgáltatások. •

Az egyik felmerülő probléma ezen a területen, hogy PSTN hívások esetén sor kerüljön-e az ENUM szolgáltatás igénybevételére. A megoldás az lehet, hogy az ügyfél megállapodik az operátorral (telekom szolgáltatójával), hogy az adott számra érkező hívások esetén az ENUM szolgáltatás ellenőrzésre kerüljön. Ez esetleg megoldható úgy, hogy az ügyfél adott számhoz tartozó készüléke kezdeményezze az ENUM lekérdezést, majd a hívás esetleges átirányítását egy másik (PABX területen kívüli) PSTN számra. − Kiterjesztett szolgáltatások •

•

•

•

Email címzése E.164 számmal. Ebben az esetben az email kliens arra használja az E.164 számot, hogy meghatározza az email címet. Email küldése SMS/MMS-ként vagy viszont. Az E.164 szám az SMS vagy MMS szám meghatározására szolgál. Egy http kérés címzése E.164 számmal. Az E.164 szám felhasználása a homepage címének meghatározására történik. Hang üzenet küldésére és fogadására, valamint email küldésére és fogadására alkalmas végpontok közötti adatátvitel, ill. az ennek megfelelő konverzió.

ENUM Nyilvántartó NS

SIP szerver

SIP szerver

11 ábra Egy egyszerű ENUM-ra épülő szolgáltatás


- 70 -


7.2.3.3 Fejlett szolgáltatások

A fejlett szolgáltatások az előzőekben ismertetett alapszolgáltatások igénybevételével biztosítanak olyan intelligens szolgáltatásokat, melyekben az alkalmazás döntést hoz különböző alternatívák között. Ebbe a kategóriába tartozhatnak például a következő táblázatban felsorolt alkalmazások: Megnevezés

Leírás

Extended messaging

Olyan alkalmazás, mely az üzenet elküldésének alternatív módjai közül egy intelligens döntéssel választ. Például a küldő fél egy email-t akar küldeni a fogadó félnek. Amennyiben a megadott E.164 számhoz tartozik email cím, úgy arra kézbesíti a levelet. Ha nincs email cím, akkor az üzenet mondjuk elküldésre kerülhet SMS-ként.

Extended Universal Personal Telecommunications number, UPT

A hagyományos UPT keretei között a felhasználó megadhatja, hogy egy adott időpontban milyen telefonszámon lehet őt elérni. A szám kiválasztása esetleg lehet helyzetfüggő is. Az ENUM használatával lehetőség van a rendszer kiterjesztésére telefonszámokról különböző Internet szolgáltatásokra és SMS/MMS-re is.

Extended unified messaging

Az előző szolgáltatás kiterjesztése a hívó fél általi csatorna kiválasztással az ENUM lekérdezés eredménye alapján.

E-meetings/conferences

Az ENUM lehetővé teszi fejlett elektronikus meeting-ek és konferenciák megvalósítását különféle kommunikációs csatornákat (PSTN, PLMN, SIP) használó felek bevonásával.

MMS kezelés

Az ENUM segítségével meggyőződhetünk róla, hogy a címzett képes-e valamilyen formában MMS fogadására. A lehetséges fogadási helyek nem korlátozódnak csak mobil telefonokra, hanem elérhető web címek vagy email címek is szóba jöhetnek.

Call center support

Két fél között lehetővé tesz egy intelligens telefonbeszélgetést, például web-en keresztüli további kiegészítő dialógusok folytatását, támogató információk cseréjét.

Egyszerű és biztonságos mobil Internet hozzáférés

Jelenlegi formájában a mobil telefonos Internet hozzáférés nehézkes lehet. Ezt a hozzáférést egyszerűsítheti az ENUM alkalmazása a megfelelő biztonság fenntartása mellett. Például lehetővé teszi a kibocsátó számára egy LDAP URI-n keresztüli nyilvános kulcs megadást.

A kezdeményező számának felhasználására épített szolgáltatások

Egy hasznos tulajdonság lehet, hogy egy PSTN hívó fél számát elérhetjük az Internet alkalmazásokban is, és felhasználhatjuk azonosításra. Az információ felhasználható a nemkívánatos felhasználók szolgáltatásokból való kizárására is


- 71 -

ENUM rendszer a végfelhasználó szemével 7.2.3.4 Renumerációs szolgáltatások

Az ENUM szolgáltatással kiegészített alkalmazások az E.164 számmal adott végponthoz tartozó paraméterek és egyéb felhasználói adatok segítségével meghatározhatnak további végpontokat. Az ENUM lehetővé teszi, hogy az érintett pontok ne csak E.164 számmal azonosított végpontok legyenek, hanem az ENUM lekérdezés során előállított tetszőleges címlisták. Az ENUM felhasználható tarifaoptimalizálásra is, hiszen az Internet használható kiindulásként, végződtetésre illetve tranzit jellegű átvitelre is. A 12. ábra egy nagyvállalat esetén mutatja, hogyan lehet ezt felhasználni a legalacsonyabb költségű hívási útvonalak igénybevételére az ENUM nyújtotta többféle szolgáltatási kombinációk közül.

Internet

GWY

GWY

Hazai szolgáltató PSTN

Külföldi szolgáltató PSTN

GWY

Vállalati hálózat

GWY

Internet

Vállalati hálózat külföldön

12. ábra Tarifaoptimalizált hívás ENUM segítségével

7.2.4 Fenntartási, karbantartási szolgáltatások Magának az ENUM rendszernek a fizikai működtetése megkívánja a fenntartási és karbantartási szolgáltatások megvalósítását. Ezen a szolgáltatások végfelhasználóinak bizonyos esetekben maguk az ENUM szolgáltatók tekinthetők. A következő felsorolás néhány ilyen szolgáltatást tartalmaz: − URI management. Ez magában foglalja új URI információk hozzáadását a regiszterhez, URI információk módosítását valamint törlését. Ezen módosítások végrehajtása megkívánja olyan protokollok kidolgozását, melyekkel megadhatók és módosíthatók osztott nyilvántartásokban elhelyezett objektumok. Jelenleg az IETF megfelelő munkacsoportja még dolgozik az XML alapú Extensible Provisioning Protocol specifikálásán. − Kiterjesztett UPT management. A korábbiakban leírt kiterjesztett UPT szolgáltatás megköveteli, hogy a felhasználók dinamikusan tudják módosítani elérhetőségi profiljukat. Az ENUM hazai megvalósításának előkészítése

- 72 -

ENUM rendszer a végfelhasználó szemével − Kiterjesztett Unified Messaging. A kiterjesztett Unified Messaging olyan eszközök kidolgozását jelenti, melyekkel a különböző csatornákon érkező üzenetek egységes nézetben kezelhetők, menedzselhetők.

7.3 Üzleti modellek Az ENUM-ra épülő szolgáltatások és alkalmazások definiálásakor a megoldandó problémáknak csak egy része technikai/technológia jellegű. A szolgáltatások megvalósítása érdekében nagyon fontos, hogy a különböző szolgáltatásokhoz ki kell dolgozni a megfelelő üzleti modelleket és díjszabási sémákat. Azok a telekommunikáció azon területei melyeket az ENUM öszszeköt, különböző díjszabási megoldásokat alkalmaznak. Míg az Internet hozzáférésekre az átalányár alkalmazása jellemző, addig a PSTN/PLMN világot a perc vagy átvitt információ mennyiség alapú számlázás jellemzi. A különféle szolgáltatási scenáriókra alkalmazható díjszabási megoldásokat a bevezetési kísérletek során kell kiértékelni. Az ENUM szolgáltatás által generált más költség profilba tartozó E.164 számra történő átirányítás esetén meg kell oldani a fellépő problémás helyzeteket. Például ha egy földrajzi számra irányuló hívás egy mobil vagy emeltdíjas számra kerül átirányításra, akkor a hívó feltételezi a földrajzi számra tartozó tarifát, míg a végződtető operátor a magasabb végződtetési költséget várja el. Vagyis a kiindulási operátornak meg kell győződnie róla, hogy a hívó állja-e a drágább hívási költséget vagy az ENUM szolgáltató kompenzálja a végződtető operátort az ENUM előfizető költségére.


- 73 -

ENUM biztonsági keretrendszer

8 ENUM biztonsági keretrendszer 8.1 Bevezető Ez a fejezet az ENUM biztonsági kérdésit vizsgálja. Először - általános informatikai biztonsági alapelveknek megfelelően – vesszük szemügyre a szolgáltatást. Meghatározzuk milyen veszélyekkel, fenyegetettségekkel kell szembe néznie az ENUM rendszernek. Végül felállítjuk azokat a biztonsági követelményeket, irányelveket melyek az ENUM szolgáltatást nyújtók számára követelmény a rendszer vagy szolgáltatás biztonságos működtetéséhez.

8.2 Alapvető informatikai biztonsági definíciók Az informatikai biztonság nagyon tág témakör. Mi ennek csupán szűk – kimondottan az ENUM szolgáltatást érintő – részével kívánunk foglalkozni. A felmerülő biztonsági, azonosítási, jogosultsági problémák kezelése előtt szükségesnek látjuk a témába vágó fogalmak pontos definiálást. Ez elengedhetetlen a szolgáltatás biztonsági keretrendszerének vizsgálatához.

8.2.1 Azonosítás – Authentication Az azonosítás az a folyamat, melynek során a szolgáltatásban résztvevő entitások igazolják magukat. Megválaszolják egymásnak a „Te ki vagy?” kérdést! Ez a folyamat tipikusan a szolgáltató és a szolgáltatást igénybe vevő – továbbiakban: felhasználó – között zajlik. Ha a folyamat során mindkét fél azonosította magát, azt kölcsönös azonosításnak nevezzük. Kölcsönös azonosítás kell hogy képezze az alapját minden ENUM tranzakciónak.

8.2.2 Jogosultság – Authorization A biztonsági keretrendszer következő komponense a jogosultság megállapítása. Miután az azonosítás megtörtént a szolgáltatónak meg kell állapítania, hogy a felhasználó a rendszeren belül milyen szolgáltatások igénybevételére jogosult. Valójában meg kell válaszolni a „Mit tehet a felhasználó?” kérdést.

8.2.3 Adat letagadhatatlanság - Data Non-Repudiation Az adat letagadhatatlanság az elektronikus dokumentum és adatkezelés megbízhatóságáért felelős - egyik legfontosabb – összetevő. (A megbízhatóság (trust) jelentése ebben a kontextusban az, hogy biztosak lehetünk a tárolt adatok valódiságában). Az adat letagadhatatlanság két független folyamat eredménye. Először is tárolnunk kell az adatot létrehozó felhasználó azonosítóját, másodszor a rendszernek biztosítania kell, a tárolt adatok integritását. (Adat integritásnak nevezzük azt a folyamat, mely garantálja, hogy a tárolt adatok nem lettek módosítva.)


- 74 -


8.2.4 Adatbiztonság - Data Privacy Ez a komponens felelős a rendszeren belüli adatok biztonságért. (A biztonság szót itt olyan értelemben használjuk, hogy az adatok nem kerülhetnek illetéktelenek kezébe.) Két felhasználási területe, a hálózati kommunikáció és az adattárolás. Például adatbiztonság szempontjából megfelelőnek nevezhetünk egy hálózati kommunikációt, ha az átviteli adatok nem kerülhetnek illetéktelenek kezébe, vagy az illetéktelenek az adatokat nem tudják értelmezni. Az adatbiztonságot első sorban (nyilvános kulcsú) titkosítással garantáljuk. Ez a komponens garantálja, hogy az ENUM rendszeren belüli cím feldolgozás és a NAPTR adatok mind a kommunikáció mind a tárolás során titkosítva legyenek.

Azonosítás Biztonsági szabályzat Jogosultság ENUM Biztonsági Keretrendszer Naplózás

Adat letagadhatatlanság 1000101001010

Adat integritás

1001010101

1001010101

Adatbiztonság

13. ábra Biztonsági keretrendszer elemei

8.2.5 Adat integritás (sértetlenség) - Data Integrity Az adat integritás az a folyamat, mely garantálja a rendszeren belüli adatok sértetlenségét. Az adat integritást fontos összetevője az adat letagadhatatlanság komponensnek. Másik fontos felhasználási terület a hálózati kommunikáció, mely során garantálja, hogy a küldött és a kapott adatok megegyeznek. Az adat integritás a hálózati kommunikáció nélkülözhetetlen összetevője.


- 75 -


8.2.6 Naplózás - Auditing A naplózás az a folyamat, mely leírja (eseménynapló) a rendszerben végrehajtott műveleteket időrendi sorrendben. Alapvető feltétele a naplózásnak, hogy a naplózó rendszer biztonságos (secure) és megbízható (trusted) legyen. A naplózás különös fontosságú a NAPTR adatok megváltoztatása során, különös tekintettel, ha azokat maga a felhasználó kezdeményezni.

8.2.7 Biztonsági szabályzat és adminisztráció - Policy Management and Administration Az ENUM biztonsági keretrendszernek (security framework) része a biztonsági szabályok gyűjteménye, melyet a rendszer adminisztrátora felügyel és karbantart. Ez komponens nagyban felelős a biztonsági rendszer sikeres üzemeltetésért. A biztonsági szabályzatnak nemcsak az ENUM rendszer technikai komponenseire kell kiterjednie, hanem az működésért felelő üzleti folyamatokra is.

8.3 Az ENUM rendszer biztonsági fenyegetettség Az ENUM rendszer vizsgálatát itt két részre bontjuk. Külön tárgyaljuk a regisztrációs és külön a lekérdező (valójában a DNS) szolgáltatás biztonsági kérdéseit. A kettébontást az indokolja, hogy a két területen igen eltérő biztonsági problémákkal találkozunk. Míg a DNS – vagyis a lekérdező rendszer – egy nyílt mindenki számára elérhető, használható szolgáltatás, addig az ENUM regisztrációs rendszere ennek pontosan az ellenkezője, egy zárt azonosítást, jogosultságokat kezelő rendszer.

8.3.1 Az ENUM regisztrációs rendszer biztonsági fenyegetettsége Külső személytől érkező támadás Ebben az esetben egy, a rendszer számára ismeretlen külső személy szerez hozzáférést a rendszerhez, azért, hogy abban kárt okozzon, vagy személyes előnyökhöz jutassa magát. Az ilyen un. „hacker”-ek okozta betörések esetén általában adatokat változtatnak meg vagy törölnek a rendszerből. Nem ritka, hogy olyan változtatásokat eszközölnek a rendszeren, mellyel bizonyos tranzakciókat megakadályoznak, vagy működésképtelenné teszik a rendszer szolgáltatásait. Belső támadások Belső támadásnak azt nevezzük, mikor egy – a rendszerhez jogosultan hozzáférő – személy, hamis tranzakciókat hajt végre, vagy meghamisít szabályszerűen végrehajtott tranzakciókat. A belső támadások egy veszélyesebb formája, mikor a támadó felhasználó valamilyen magasabb –nem felhasználói- szintű hozzáféréssel rendelkezik a rendszerhez, pl. rendszergazda, vagy az ENUM szolgáltatás felügyelet, management része. Ilyen jogosultsággal nagyon könnyű a rendszeren belül adatokat megváltoztatni, hamis adatokat, esetleg nem létező felhasználókat az adatbázisba jutatni.


- 76 -

ENUM biztonsági keretrendszer Hamis azonosság Ha egy felhasználó nem a saját vagy hamis azonosítót használ, esetleg többszörös azonosítóval rendelkezik a rendszerhez, akkor őt a rendszer hamisan azonosítja. Az általa végrehajtott változtatások felelőse nem megállapítható. A külső és belső támadások esetén gyakori cél, hogy a rendszerbe hamis azonosítókat jutassanak. (Belső támadás esetén ez nyilvánvalóan könnyebb, de nagyobb a „lebukás” esély is.) Visszavont jogosultság Előfordulhat, hogy egy adminisztrátor töröl egy felhasználót az ENUM rendszerből, de nem vonja vissza a jogosultságát. Ilyen esetben a volt felhasználó továbbra is hozzáférhet a rendszerhez és abban nem kívánt módosításokat hajthat végre. Hozzáférési információ lopása A rendszerhez való hozzáférési információ – mely lehet név/jelszó, azonosító kártya, vagy bármilyen más módszer – ellopása vagy elvesztése lehetőséget ad idegeneknek, hogy a hozzáférjenek a rendszerhez és jogosulatlan módosításokat hajtsanak végre az adatokan. Szolgáltatás megtagadás Ebben az esetben a támadás arra irányul, hogy az ENUM szolgáltatás elérhetetlenné váljon a (legitim) felhasználók számára. A támadás ebben az estben is érkezhet kívülről, vagy belülről, és gyakran „hackelés”-nek hívják. A támadók legtöbbször ahhoz a módszerhez folyamodnak, hogy az ENUM rendszer egyes elemeit (Regisrty, Registrar) túl terhelik, így azok nem tudják a valós felhasználókat kiszolgálni. Jogosulatlan adatszerzés Ha személyes és egyéb adatok az ENUM rendszerbe történő regisztráció, vagy egy lekérdezés során olyan személyekhez kerülnek, akiknek ezen adatokhoz nincs hozzáférési jogosultságuk, akkor beszélhetünk jogosulatlan adatszerzésről. Ezt első sorban a rendszer nem megfelelő (kijátszható) biztonsági politikája okozza. A jogosulatlan adatszerzés visszaélésekre adhat alkalmat, és aláássa a bizalmat a rendszerrel szemben. Hamis regisztrációs adatok Az ENUM rendszer esetében különleges jelentőséggel bír a regisztrációs adatok ellenőrzése, hitelesítése. Ha ugyanis egy felhasználó nem a saját telefonszáma alapján regisztrál a rendszerbe, azzal megtéveszthet másokat. Ez vonatkozik természetesen a többi személyes jellegű adatra is (az ENUM esetén a keresés elsődleges kulcsa a telefonszám, ezért ennek ellenőrzése, hitelesítése a legfontosabb.)

8.3.2 Az ENUM lekérdező (DNS) szolgáltatás biztonsági fenyegetettsége A DNS mint elosztott, hierarchikus adatbázis, eredetileg nem rendelkezett semmilyen adatbiztonsági mechanizmussal. A későbbi fejlesztések során azonban megfogalmazódtak igények. A DNS speciális felhasználásából adódóan az adatbiztonsági igények bizonyos tekintetben eltérnek az általános adatbázis biztonsági igényektől.


- 77 -

ENUM biztonsági keretrendszer A DNS alapvetően egy nyílt adatbázis, amely biztonsága elsősorban a hitelességet jelenti. A gyakorlatban ismert és az elméletileg elképzelhető támadások – eltekintve a szolgáltatásmegtagadás jellegűektől – mind azon alapulnak, hogy vagy eleve nem valós adatokat helyezünk el a DNS adatbázisban, vagy a lekérdezés során a hamis válaszokat juttatunk a lekérdezőnek. Alapvetően sem az adatok titkos átvitele, sem a lekérdezések korlátozására nincsen szükség. Ezzel szemben hitelesített adatátvitel igénye több ponton is felmerül: − DNS lekérdezésekre adott válasz hitelességnek biztosítása: a DNS kiszolgálótól kapott adat hitelességéről a kliensnek meg kell tudnia győződni a kapott válasz hitelességéről, vagyis arról, hogy az adat valóban abból a zónából származik, amelyből a lekérdezés történt. A szerverek és a kliensek csak hiteles rekordokat tárolhatnak a cache-ben. − A kliensnek biztonságos kommunikációt kell folytatnia a cache-sel. − A nemleges válasznak (pl. nem létező rekord) is hitelesnek kell lennie. − Adatbázis replikáció hitelességnek biztosítása. Az elsődleges és a másodlagos DNS kiszolgálók közti adatcsere során a másodlagos kiszolgálónak meg kell győződnie, hogy valóban az elsődleges kiszolgáló által tárolt hiteles adatokat veszi át. − Dinamikus DNS frissítés esetén csak a megfelelő jogosultságokkal rendelkező frissíthet. A hagyományos DNS rendszer több ponton és több módon is támadható (14. ábra). A lehetséges támadások a következők:

Adat megváltoztatása Elsődleges szerver megszemélyesítése Zóna fájl

Elsődleges szerver

Dinamikus frissítés

Cache / forwarder

Másodlagos szerver(ek)

Engedély nélküli frissítés

Cache megszemélyesít ése

Kliens (resolver)

Cache besszennyezése hamis adatokkal

Kiszolgáló védelme

Adat védelme

14. ábra A DNS szolgáltatás támadhatósági pontjai


- 78 -

ENUM biztonsági keretrendszer − Zóna adtok megváltoztatása: amennyiben az elsődleges kiszolgálón a támadónak sikerül a zónafájl tartalmát megváltoztani, akkor eleve hamis adatokat szolgáltat a rendszer. Mivel egy jól működő rendszerben feltételezhetjük, hogy a DNS kiszolgáló kellően védett, ráadásul egyszerű módszerek vannak a zónafájl eredetiségének vizsgálatára helyben, ezért ez a támadási fajta viszonylag kevésbé lehet sikeres. − Dinamikus DNS engedély nélküli frissítése: rendszerint hibás konfigurációból eredően a kiszolgáló olyan klienseknek is enged frissítést, amelyek erre nem jogosultak. − Cache beszennyezése (cache poisoning): a hatékonyabb működés miatt a DNS rendszer az egyszer már lekérdezett adatokat bizonyos ideig eltárolja és következő lekérdezéskor a tárolt adatokat használja. Amennyiben a támadó rá tudja venni a rendszert, vagy akár műszaki hiba miatt, hamis adat kerül be a cache-be, akkor az adat érvényességének lejáratáig a rendszer egyes elemei ezt a hamis adatot fogják használni. Gyakorlati támadások során ez úgy történhet, hogy a támadó ráveszi a célpontot, hogy lekérdezze a támadó DNS kiszolgálóját. Ez történhet pl. megfelelő web oldallal, stb. Ez a DNS kiszolgáló a válaszban, rendszerint az egyéb adatok szekcióban visszaad egy olyan címet is, amely egyébként nem az övé. Nem megfelelően konfigurált rezolverek ezt az adatot is eltárolhatják. Ezzel megváltoztatható egy domain névhez rendelt IP cím, így a támadó például saját, hamis web oldalára terelheti a támadottat. − A cache poisoning segítségével, akár teljes zónák felett is át lehet venni az irányítást, a megfelelő hamis NS rekord segítségével. (Zónán kívüli domain eltérítés - Out of Zone Domain Hijacking) − A különböző megszemélyesítési támadások azért lehetnek sikeresek, mert egy DNS kérés – válasz nagyon kevés olyan információt tartalmaz, illetve ezek könnyen hamisíthatóak, amely alapján a kliens egyértelműen meg tudja állapítani, hogy a válasz valóban az általa lekérdezett kiszolgálótól érkezett. Így támadó harmadik félnek lehetősége van akár hamisított csomagokat készíteni (Spoofing), amely legitim válasznak látszik, vagy az eredeti csomagot megváltoztatni (Packet Alteration) miközben az eredeti választ célba érkezését valamilyen módon megakadályozza (pl. hálózat túlterhelésével).

8.4 ENUM biztonsági keretrendszer Az ENUM biztonsági keretrendszerét a 15. ábra mutatja. Az ábrán feltüntettük azokat a kommunikációs protokollokat is, a regisztrációs és a lekérdezési folyamatok során szerepet játszanak. Tekintsük át az ábrát balról jobbra haladva. Bal oldalt a regisztrációs, míg jobb oldalt a lekérdezési folyamat látható. A regisztrációs folyamat azzal kezdődik, hogy a Regisztrált felveszi a kapcsolatot a Regisztrátorral biztonságos adatátvitelt (pl. HTTPS vagy TLS) használva. A HTTPS kapcsolat SSL biztonsági mechanizmusa titkosítja az adatokat az átvitel során. Hasonlóan a Regisztrátor és a Validáló (hitelesítő) rendszer között is HTTPS kapcsolat épül fel, melyen keresztül a regisztrációs adatok hitelességének vizsgálata (validálása) zajlik. A Regisztrátor és az 1. és 2. syintű névszerverek között a regisztrációs eljárásokat támogató EPP protokollt használatos. Az EPP ugyancsak HTTPS kapcsolatot használ a biztonságos adattovábbításhoz. AZ EPP nyílt ipari szabvány, mely regisztrátorok és az akkreditált regiszt-


- 79 -

ENUM biztonsági keretrendszer rációs adatbázisok (Tier-1, Tier-2 Registry) között használt interfész (IETF által támogatott szabvány). Az egyetlen kivétel a regisztrációs folyamatban a 2. szintű elsődleges és másodlagos névszerverek közötti kommunikáció, ahol az adatbázisok szinkronizálásához TSIG protokollt használnak. Az ábra jobb oldalán, a lekérdezési folyamatot láthatjuk. Itt az egyes névszerverek között DNSSec protokoll használatos. A DNSSec a végfelhasználó névszervere és az ENUM különböző szintű névszerverei közötti biztonságos kommunikációért felel. Az ábra bal oldalán látható regisztrációs folyamat valójában egy általános web alapú adatbázis kezelési probléma megoldása biztonságos (htttps) protokollok felhasználásával. Ezért a továbbiakban a sokkal inkább ENUM specifikus második, lekérdezési folyamat biztonságos megvalósításával foglalkozunk

ENUM Biztonsági Keretrendszer Root

DNSSec

EPP/HTTPS

HT TPS

Tier 1

Végfelhasználó névszervere

DNSSec

DNSSec

TP

DNSSec

EPP/HTTPS

EPP/HTTPS

T /H PP E

Regisztrált

Regisztrátor

ec SS

HTTPS

N

Tier 0

Validáló rendszer

Lekérdezési folyamat D

EPP/HTT PS

Regisztrációs folyamat

Végfelhasználó

S

Tier 2 elsődleges névszerver

TSIG

Tier 2 másodlagos névszerver

15. ábra ENUM biztonsági keretrendszer


- 80 -


8.5 DNSSEC

8.5.1 ENUM lekérdezés (DNS Cache használata nélkül) Először is tekintsünk át ENUM lekérdezési folyamatot DNS cache használata nélkül! A folyamatot a 16. ábra mutatja, ahol szögletes zárójelbe tettük az egyes lépéseket jelölő számokat: 1

Egy érdeklődő tudni szeretné a 36-1-234-5678 telefonszámhoz tartozó személy e-mail címét.

2

A megadott telefonszámot az érdeklődő névszervere ENUM lekérdezés szerinti szabályos címre fordítja (8.7.6.5.4.3.2.1.3.6.e164.arpa).

3

A kérés először a „root” szerverhez továbbítódik, ahonnan visszaérkezik a 0. szintű (Tier 0) névszerver elérhetősége.

4

A 0. szintű névszerver a telefonszám alapján megválaszolja az 1. szintű (Tier 1) névszerver elérhetőségét.

5

Az 1. szintű névszerver a telefonszám alapján megválaszolja a 2. szintű (Tier-2) névszerver elérhetőségét.

6

A 2. szintű névszerver visszaküldi a telefonszámhoz és a kért szolgáltatáshoz (e-mail cím) tartozó NAPTR rekordot.

[2] e164 szerinti konverzió: 8.7.6.5.4.3.2.1.3.6.e164 [3] Küld: 8.7.6.5.4.3.2.1.3.6.e164.arpa Fogad: a.tier0-ns-servers.net

[4] Küld: 8.7.6.5.4.3.2.1.3.6.e164.arpa Fogad: g.tier1-ns-servers.net Végfelhasználó névszervere

[5] Küld: 8.7.6.5.4.3.2.1.3.6.e164.arpa Fogad: t.tier2-ns-servers.net

Végfelhasználó [1] Mi az E-mail címe? Tel: +36-1-1234-5678

Root

Tier-0 a.tier0-ns-servers.net Tier-1 g.tier1-ns-servers.net

Tier 2 [6] Küld: 8.7.6.5.4.3.2.1.3.6.e164.arpa Fogad: [email protected]

t.tier2-ns-servers.net

16. ábra ENUM lekérdezési folyamat DNS cache használata nélkül


- 81 -


8.5.2 A DNSSEC protokoll Mivel a DNS semmilyen hitelesítési módszerrel sem rendelkezett, ezért megkezdődött a munka ennek megoldására. A hitelesítési kiegészítések először 1997-ben jelent meg az RFC 2065, amelyet 1999-ben leváltott az RFC 2535, amelyhez még jelenleg is készülnek kiegészítések és módosítások. Az ebben leírt rendszer a meglévő DNS szolgáltatásokat egészíti ki olyan módon, hogy a fent leírt biztonsági kérdésekre megoldást adjon. A kiegészítés visszafelé kompatibilis, azaz a meglévő rekordokat újabb rekordípusokkal egészíti ki. A DNSSEC alapvetően digitális aláírással biztosítja az egyes rekordok hitelességét. A DNSSEC szűkebb értelemben a digitálisan aláírt DNS rekordokat jelenti, tágabb értelemben azonban egy teljes rendszert jelent, amely három alapvető funkciót valósít meg: − A DNS rekordok hitelesítése digitális aláírással, és az ehhez kapcsolt egyéb feladatok, mint a zónák hierarchikus hitelesítése, a kulcsok menedzsmentje stb. − Zónatranszferek és egyéb DNS-sel kapcsolatos kommunikációs csatornák hitelesítése a TSIG mechanizmussal. − Dinamikus DNS frissítés a TSIG segítségével. Ez tekinthető az előző pont speciális esetének, azonban logikailag célszerű elkülönítve kezelni. A továbbiakban DNSSEC alatt a szűk értelmezést értjük, és a TSIG mechanizmust külön kezeljük.

8.5.3 A DNSSEC célja A DNSSEC a következő alapvető feladatokat oldja meg: − Biztosítja a DNS adatbázisban tárolt rekordok hitelességét és integritását digitális aláírással. − Az aláírás nem csak egy zónán belül történik, de a szülő hitelesíti a hozzá tartozó gyermek-zónát is. − Elvileg csak a DNS fa gyökerének publikus kulcsát kell biztonságos módon terjeszteni, a többi domain a tanúsítványlánc segítségével hitelesítve lesz. − Kulcsok lecserélése és átadása.

8.5.4 A DNSEC működése A DNSSEC az egyes RR-ok digitális aláírásával teremti meg azok hitelességét. Az aláírás alapvetően egy zónán belül történik, amely során a zóna titkos kulcsával – vagy kulcsaival, akár több különböző algoritmussal is – a zóna RRset-jeit aláírják. Csak a zóna fennhatósága alá tartozó rekordok vannak aláírva. A DNSSEC lényeges pontja, hogy az aláíró a zóna, vagyis a rekordok hitelesítése a zónához képest történik, nem pedig például a szerverhez, vagy más szereplőhöz. Ebből két fontos tulajdonság következik: − A rekordok előre aláírhatóak, akár off-line módon is, mivel az aláírás független a kiszolgálótól, vagy a többi rekordtól. A privát kulcsot ezért nem is kell tárolni a DNS kiszolgálón, elegendő, ha az aláírás művelete során van jelen. A kulcs biztonságos megőrzését ez nagyban javítja. Az ENUM hazai megvalósításának előkészítése

- 82 -

ENUM biztonsági keretrendszer − A hitelesítés nincsen kiszolgálóhoz, vagy máshoz kötve, így például tetszőlegesen cserélhető, vagy áthelyezhető a kiszolgáló számítógép. Ez a rendszer hibatűrése szempontjából lényeges. Az aláírás művelete során minden egyes RRset kiegészítésre kerül a SIG (signature) rekorddal, amely az adott RRset valamely algoritmussal (RSA, Elliptikus, stb.) készített aláírását tartalmazza. A DNS lekérdezés során a visszaadott RRsethez – annak részeként - a kiszolgáló megadja az aláírást, amelyet a fogadó fél az adott zóna publikus kulcsa alapján ellenőriz. Egy RRset akár több különböző kulccsal is aláírható. A kulcsok megtalálhatóak a zóna KEY rekordjaiban. A hagyományos DNS működéshez képest a nem létező választ is hitelesíteni kell. Erre szolgál a DNSSEC NXT rekordja, amely nem létező domain névre irányuló lekérdezés esetén hiteles válaszban közli, hogy a kérdéses domain nem létezik, és egyben megadja a sorban következő létező nevet. Egy zóna esetében a zónából származó adatok hitelesítésére akkor végezhető el, ha a lekérdezést végzőnek birtokában van a publikus kulcs hiteles példányának. Ez kétféle módon történhet: − Valamilyen megbízható módon (off-line, PGP, stb.) megkapja a kulcsot. − Más megbízható zónából származó információ alapján megbizonyosodik az kérdéses zóna által publikált kulcs valódiságáról. Az első eset tulajdonképpen egyszerű, de nyilvánvalóan önmagában csak korlátozottan használható. A második megoldás jelenti a valóban széleskörben használható megoldást. Ideális esetben csak a DNS fa gyökerének kulcsát kell megbízható módon publikálni, minden további ez alatti zóna a szülő által hitelesíthető. Természetesen lehetséges a kombinált megoldás, amikor több zónák kulcsát eltárolva ezeket a zónákat és az általuk hitelesítetteket hitelesnek tekintünk, a többieket pedig hitelesítés nélkül használunk.

8.5.5 Szülő általi hitelesítés A felsőbb szintű zóna által történő hitelesítés megoldása nem egyszerű feladat. Mutatja ezt az is, hogy a DNSSEC-et leíró RFC 2535-höz képest az RFC 3658 2003. decemberében teljesen új, és az eredetivel nem kompatibilis megoldást írt elő. Az eredeti megoldás szerint a szülő zóna kulcsával lenne hitelesítve a gyermek zóna kulcsa. Problémás volt azonban, hogy mely zónában kell tárolni az aláírt kulcsokat, mivel alapelv, hogy egy zóna lehetőleg csak az ő fennhatósága alá tartozó rekordokat írja alá. Ráadásul minden, a kulcsot érintő változás új aláírást igényel, a gyermek elküldi kulcsát a szülőnek, amely aláírva visszaküldi. Ezért RFC 3658 bevezetett egy újabb erőforrás rekordot, a DS (Delegation Signer) rekordot, és ezzel együtt egy új modellt a hitelesítésre. Megkülönböztetünk két kulcsot: − Kulcs aláíró kulcs (KSK – Key Signing Key): ez a kulcs hitelesíti a zóna aláíró kulcsokat. − Zóna aláíró kulcs (ZSK – Zone Signing Key): ez a kulcs hitelesíti az egyes rekordokat Meg kell jegyezni, hogy a kulcsok fizikailag nem feltétlenül különbözőek, főleg kisebb zónák ugyanazt a kulcsot használhatják mindkét célra.


- 83 -

ENUM biztonsági keretrendszer A DS rekord használata a következő módon történik. A szülő zóna tartalmazza a DS rekordban a gyermek zóna KSK-ját aláírva a szülő kulcsával. A gyermek zóna viszont a KSK-val saját maga aláírja a ZSK-t, amellyel az egyes rekordokat hitelesíti. A hitelesség ellenőrzése során a DS rekordban található aláírt kulcsot összehasonlítva a gyermek kulcs aláíró kulcsával, megbizonyosodhatunk a gyermek KSK hitelességéről. A hiteles KSK birtokában a ZSK valódisága is biztosítható, ezzel pedig az RR-ek is hitelesíthetőek.

8.5.6 Kulcsok váltása A zóna kulcsokat időnként váltani kell. Vagy azért, mert valami okból a kulcs kompromittálódott, és ekkor azonnali csere kell, vagy azért, mert a kulcsméretből adódó megtörhetőség miatt erre elővigyázatosságból van szükség. A hosszabb kulcs kriptográfiailag előnyösebb, de számításigényesebb is. Ezért a KSK és a ZSK különböző méretűre választható. Így a gyakran használt ZSK sűrűbben cserélhet. Ezt a gyermek saját hatáskörében megteheti, mert az új kulcsot saját KSK-val hitelesíti. Csak a KSK cseréje esetén van szükség a szülő zóna általi felülhitelesítésre. A KSK viszont kellően hosszúnak választható, így cseréjére csak ritkán van szükség.

8.5.7 Előnyök és hátrányok A DNSEC jelenleg még fejlődő rendszer, ezért várható, hogy a hátrányai a jövőbeli fejlesztések alapján csökkenni fognak. Előnyének tekinthető, hogy egyáltalán létezik. A DNSSEC előtt semmiféle DNS hitelességét biztosító megoldás nem létezett. A DNSSEC célzottan a DNS problémáinak megoldására készült, és a fejlesztés során végül a kezdeti elképzelésektől eltérve nem is próbál más rendszer (PKI, IPSec, stb.) alapja lenni. A DNSSEC hátránya elsősorban nem tervezési hiányosság, hanem implementációs. Még nincsen kiforrott megvalósítás és a használatba vétele is messze van a teljestől. Ráadásul a digitális aláírás használata jelentősen csökkentheti a DNS lekérdezések sebességét.

8.5.8 A DNSSEC és a PKI viszonya Szembetűnő a hasonlóság a DNSSEC és a PKI között, és felmerülhet a kérdés, hogy nem használható-e a DNSSEC egyben PKI-ként is. A hasonlóság valóban szembetűnő, de van néhány olyan pont, amely alapján a DNSSEC nem lehet általános célú PKI: − Nincsen az egész rendszerre érvényes adminisztratív politika, minden domain saját magának határozza meg a követendő eljárásokat. Nincsen például szabályozva, hogy egy felsőbb szintű domain milyen azonosítási és egyéb eljárások alapján hitelesíthet egy alacsonyabb szintűt. − Nem lehet kulcsokat visszavonni. Kompromittálódott vagy hamis kulcs esetében nincs lehetőség explicit visszavonási listákat készíteni. Ez a DNSSEC működésében nem okoz problémát, PKI-ban azonban követelmény. Mindezek mellett kellően zárt rendszerben a DNSSEC használható egyfajta PKI-nak is. Figyelembe kell venni, hogy RFC 3445 kifejezetten tiltja a KEY rekordok más célra történő használatát (PKI, email, IPSec, stb.), mint a DNSSEC, annak ellenére, hogy RFC 2535 eredetileg ezt engedélyezte. Ennek technikai és adminisztratív magyarázatai vannak.


- 84 -


8.5.9 TSIG Nem minden DNS művelethez van szükség a számításigényes hitelesítési műveletekre. Bizonyos eseteken egyszerűbb megoldásokkal is biztosítható a hitelesség: − Az elsődleges és másodlagos DNS kiszolgálók közti zónatranszfer során a másodlagos szervernek kell az elsődleges szerver hitelességéről megbizonyosodni. − Ha a lokális hálózatban DNS cache van, amelyhez a kliensek fordulnak, akkor ennek a kapcsolatnak kell biztonságosnak lennie. Sok implementáció csak úgynevezett „csonka” (stub) rezolvert használ, amely önmagában nem képes lekérdezések végzésére – így DNSSEC használatára sem –, csak egy DNS kiszolgálón keresztül. Az egész lekérdezési lánc biztosítására a rezolver és a kiszolgáló közti szakaszt is megbízhatóvá kell tenni. − Ha a dinamikus DNS bejegyzéseket csak kis számú helyről fogadja el a szerver, akkor ennek biztonságos kapcsolatnak kell lennie. A fent leírt esetekben a PKI technológiánál egyszerűbb megoldások is megfelelnek, amelyek titkos kulcsú algoritmusokon alapulnak. Mindez azért elegendő, mert az átvitt adatok hitelesítéséhez szükséges titkos kulcsok biztonságos cseréje – főként a kis számú és rendszerint egy adminisztratív kezelésben lévő kommunikáló felek miatt – egyszerűen megoldható. Az RFC2845 által definiált TSIG (Secret Key Transaction Authentication for DNS) a fenti feladatokat látja el. A TSIG használatához a két kommunikáló fél (például: elsődleges és másodlagos szerver) közös, titkos kulcsot használ. A kulcsok cseréje a DNS-től független, más, biztonságos úton valósul meg. Rendszerint manuális úton történik a kulcsszétosztás.

RRSet

Zóna fájl

RRSet + aláírás

Elsődleges szerver

Másodlagos szerverek

Kulcs 17. ábra Példa a TSIG alkalmazására

A TISG a kommunikáció során egy – rendszerint – HMAC-MD5 ellenérző összeget készít a válaszról, amelyet a fogadó fél szintén kiszámol a nála is rendelkezésre álló titkos kulccsal. Egyezőség esetén biztosított a hitelesség. A TSIG előnye, hogy egyszerű, és könnyen hasz-


- 85 -

ENUM biztonsági keretrendszer nálható korlátozott számú kommunikáló fél között, amennyiben a kulcsok szétosztása egyszerűen megoldható. A teljes DNS infrastruktúrán belül a TSIG legfontosabb felhasználási területe a szerverszerver kommunikáció (pl. zónatranszfer) megbízhatóvá tétele, a kiszolgálók autentikálása révén. A TSIG elsősorban a kiszolgálóhoz és nem a zónához kapcsolódó megoldás.

8.5.10

Egyéb lehetőségek

A DNS rendszer biztonságos működésére elsősorban a DNSSEC szolgál, azonban más technológiákat is alkalmazhatunk, kiegészítő biztonsági feladatok megoldására. Ezek rendszerint függetlenek a DNS-től. Az IPSec, mint általános, hálózati szintű biztonsági keretrendszer bizonyos esetekben kiegészítheti, vagy kiválthatja a TSIG-et, sőt akár a DNSSEC-et is. Fontos azonban megjegyezni, hogy a DNSSEC a zónához tartozó rekordokat hitelesíti, az IPSec viszont a csomópontok közötti kommunikációt. Az SSL az IPSec-hez hasonlóan alacsonyabb szinten (szállítási szinten) valósít meg hitelesített és/vagy titkosított kapcsolatot.

8.6 A DNSEC és TSIG felhasználása az ENUM rendszer biztonsági megoldásaiban A DNSSEC és TSIG elsősorban a DNS működéséhez szükséges hitelesítési feladatokat oldja meg. Ennek megfelelően az ENUM azon pontjain használható, ahol az ENUM a DNS-re támaszkodik. A következő ENUM funkciók esetében alkalmazhatóak: − ENUM lekérdezések során visszaadott rekordok hitelességének megállapítására, DNSSEC aláírásokkal. − A különböző szintű (Tier-0, Tier-1 stb.) zónák hierarchikus hitelesítésére DNSSEC segítségével. − ENUM adatokat tartalmazó elsődleges és másodlagos kiszolgálók közötti adatcsere TSIG hitelesítésére. − A regisztrátor által esetlegesen alkalmazott dinamikus DNS frissítés TSIG esetleg DNSSEC általi hitelesítésére. − ENUM kliens alkalmazások és kiszolgálók közti kommunikáció hitelesítésére TSIGgel.

8.6.1 Feltételek a DNSSEC használatához Ahhoz, hogy a DNSSEC valójában a tervezetteknek megfelelően működjön, az egész ENUM adatokat tartalmazó DNS fának hitelesítettnek kell lennie. Ez azt jelenti, hogy ennek bevezetésére akkor kerülhet sor, ha legalább az e164.arpa domain rendelkezik DNSSEC-kel, és minden ez alatt lévő zóna is támogatja. Ennek hiányában az alacsonyabb szintű zónák publikus kulcsát megfelelő módon el kell juttatni a felhasználókhoz. A hierarchikus hitelesítések a


- 86 -

ENUM biztonsági keretrendszer normál DNS működéshez képest jóval több kommunikációt és együttműködést kívánnak az alá és fölérendelt szintek között, ennek főleg adminisztratív kezelésére fel kell készülni. Mind a DNSSEC, mind a TSIG időbélyegzéssel védekezik a visszajátszásos támadások ellen, ezért a teljes rendszernek időben szinkronizáltnak kell lennie, legalább néhány perces pontossággal. Célszerű, hogy minden gép NTP-vel időben szinkronizálva legyen. A DNSSEC által használt RR-ok kezeléséhez és adminisztrálásához meg kell lenni a megfelelő szoftver infrastruktúrának, „kézi” kezelésük gyakorlatilag lehetetlen. Jelenleg még csak kevés eszköz létezik erre a célra. A DNSSEC jelenleg is fejlesztés alatt áll, ráadásul korlátozott az ezt támogató implementációk száma. Különösen igaz ez a kliens implementációkra, amelyek gyakorlatilag jelenleg még nem léteznek. Így a DNSSEC használatának tulajdonképpen egyetlen módja a DNSSEC támogatással ellátott forwarder használata. Mindenképpen várható, hogy a DNSSEC működtetése során szerzett tapasztalatok alapján a specifikáció változik, kiegészül. Ugyanez igaz az implementációkra is. A fentiek miatt a DNSSEC bevezetése csak akkor javasolható, ha megfelelő nemzetközi tapasztalatok támasztják alá megbízható működését.


- 87 -

Nemzetközi kitekintés

9 Nemzetközi kitekintés Az elmúlt néhány évben számos kísérleti ENUM projekt indult el a világ különböző országában. A technológia iránt fokozott érdeklődést mutatnak az európai országok, de több ázsiai ország is beindította a kísérleti üzemet. Természetesen az Amerikai Egyesült Államokban is több konferenciát rendeztek, ahol beszámoltak az elért eredményekről, ill. ismertették az elsősorban szabályozási problémákat és azok megoldásainak lehetséges módszereit. Az amerikai számkiosztás miatt ott ugyanis az első szint adminisztrációja nem egyszerű feladat. A tanulmány elkészítése során számos hasznos információt gyűjtöttünk a kísérleti projektek által közzétett munka- és konferencia anyagokból. A következő táblázatban röviden összefoglaljuk az európai kísérleti üzemek fontosabb adatait. A táblázat megjegyzés rovatában feltüntettük a megadott site-okon elérhető információk alapján kialakított szubjektív véleményünket is az adott projekt aktivitásáról. Ország

Adatok, információk összefoglalása

Megjegyzés

Anglia

http://www.ukenumgroup.org

Közepesen aktív

A kísérleti üzem feltehetőleg 2002-ben indult, de pontos információnk nincs. Regisztrációs portált üzemeltet. Ausztria

http://enum.nic.at

Igen aktív

Első lépések 2001. júliusában történtek. Számos profit-orientált támogató partner is részt vesz a kísérletekben. Igen sok dokumentumot és munkaanyagot adtak ki, melyek hasznos információkat tartalmaznak. Ezek letölthetők a fenti site-ról. Rendszeres workshopokat rendeznek. Kísérleti regisztrációs Web szervert üzemeltetnek, melyen keresztül minden ausztriai felhasználó regisztrálhat. Franciaország

http://www.numerobis.prd.fr A projekt 2002. májusában indult. Átgondolt projektszervezetet és projekttervet találhatunk a fenti Web-címen.

Meglehetősen aktív a francia sajátságokkal.

Rendszeres workshopokat szerveznek. A legközelebbi 2004. február 25-én lesz, amely az előzetes program alapján elsősorban az alkalmazásfejlesztőknek szól. Regisztrációs Web szervert üzemeltetnek.


- 88 -

Nemzetközi kitekintés Ország

Adatok, információk összefoglalása

Megjegyzés

Hollandia

http://www.enuminnederland.nl

Aktív

A projekt 2001. júniusában indult. Számos dokumentumot és munkaanyagot adtak ki. Több profit-orientált támogatót is bevontak. Lengyelország

http://www.dns.pl/ENUM

Aktív

A projekt 2002. novemberében indult. Rendszeres események. Jellemző a külföldi anyagok feldolgozása, adaptálása. (lengyel nyelvű site) Németország

http://www.denic.de/de/enum

Aktív

A projekt 2002-ben indult. Számos dokumentumot és munkaanyagot adtak ki. Workshopokat rendeznek. Svédország

http://enum.autonomica.se

Gyengén

A Projekt 2002 második felében indult.

aktív

A portálon néhány fontos dokumentum, és link található. Svájc

http://www.ofcom.ch/de/telekommunikation/numme Aktív rierung/enum/index.html A projekt 2002-ben indult. Számos dokumentumot és munkaanyagot adtak ki. Workshopokat rendeznek.

A megvizsgált kísérleti projektek elsődleges célja a technológia kipróbálása, az együttműködési tesztek lefolytatása, valamint a piaci szereplők megismertetése a technológiával. Fontos eredménye a kísérleti projekteknek az NAPTR rekordok felépítésnek, tartalmának letisztulása, ami az eredményes együttműködés elengedhetetlen feltétele. További fontos eredménye a kísérleti üzemeknek, hogy a lekérdező alkalmazásokkal (kliensekkel) szemben támasztott minimális követelmények meghatározásra és kipróbálásra kerülhetnek. A fent felsorolt európai országokon kívül szinte minden ország bejelentette a RIPE-nál a 0. szinten bejegyzésre kerülő országkódra vonatkozó igényét, mint pl. Magyarország és Románia is, de ismereteink szerint kísérleti üzemet nem indított.


- 89 -

Hazai szabályozási, felügyeleti kérdések és megvalósítási javaslatok

10 Hazai szabályozási, felügyeleti kérdések és megvalósítási javaslatok A tanulmány a távközlés és az Internet konvergenciájának egy részszegmensét, a távközlés területén használt előfizetői azonosítóknak (telefonszámok) Internetes azonosítókká (domain nevek) való átalakításának eljárását (ENUM), az eljárásban résztvevő szereplőket, és a szükséges és lehetséges szabályozási folyamatokat vizsgálta.

10.1 A szabályozás és szervezeti keretei Világosan látható, hogy a szabályozás és annak szervezeti háttere megfelel a világszerte kialakult helyzetnek. A távközlés szabályozása közelmúltban életbe lépett, az elektronikus hírközlésről szóló 2003. évi C. törvény alapján történik. A Kormány felhatalmazást kapott, hogy az Azonosítók Nemzeti Felosztási Tervét (ANFT-t) és az azonosítókkal való gazdálkodás rendjére vonatkozó részletes szabályokat kormányrendeletekben határozza meg. Ez azt jelenti, hogy a nemzetközi gyakorlatnak megfelelően az azonosítók, jelen esetben a telefonszámok használatát továbbra is a hagyományos távközlési szabályok és elvek határozzák meg, és az azonosítókkal való gazdálkodás továbbra is a nemzeti szabályozó hatóság, az NHH feladata. Az Internet azonosítók használatával, kijelölésével kapcsolatos tevékenységeket továbbra is a megfelelő felhatalmazással bíró hazai szervezetek végzik ill. koordinálják. Ez azt jelenti, hogy a telefonszámokból képzett domain nevek kezelését az egyéb domain nevek kezelésére kijelölt szervezetek (Internet Szolgáltatók Tanácsa, mint nyilvántartó és a vele kapcsolatban álló regisztrátor szervezetek) végzik. Ehhez kapcsolódóan 2 javaslatot teszünk: 1. Javaslat: Célszerűnek látszik az ENUM-mal kapcsolatos tevékenységeket meglévő szervezetekre és infrastruktúrára alapozni, azzal a kiegészítéssel, hogy fel kell mérni az új feladatokat, és javaslatot kell tenni azok ellátására.

2. Javaslat: Ki kell dolgozni az ENUM-ra vonatkozó eljárási szabályokat, az egyes résztvevők feladatát, felelősségét és az együttműködés rendjét.


- 90 -

Hazai szabályozási, felügyeleti kérdések és megvalósítási javaslatok

10.2 ENUM kísérleti üzem Az ENUM kísérleti üzem feladata, hogy a piac összes résztvevője kormányzati felügyelet mellett együttesen, a kereskedelmi fázist megelőzően meggyőződhessen az ENUM IETF RFC 2619 szerinti működéséről, a szükséges műszaki, működési feltételek meglétéről. A javasolt résztvevői kör: szabályozó, felügyelő szervezetek (pl. IHM, NHH, Internet Szolgáltatók Tanácsa), szolgáltatói kör (pl. Internet szolgáltatók, vezetékes és mobil szolgáltatók, nyilvántartó, regisztrátorok), kutatóhelyek, egyetemek (pl. BME). A nemzetközi kísérleti projektek tapasztalatai és eredményei alapján fontosnak tartjuk, hogy Magyarország is bekapcsolódjon az ENUM alkalmazás-fejlesztés feladataiba, valamint az ENUM rendszerek együttműködési vizsgálatába. Ez lehetőséget teremt arra, hogy a későbbiekben zökkenőmentesen be tudjunk kapcsolódni a nemzetközi ENUM struktúrába. Így a hazai piac szereplői is képet kaphatnak arról, hogy milyen lehetőségek nyílnak meg számukra ezen új technológia használatával. A tanulmány elkészítése során folytatott konzultációk alapján megállapítható, hogy több szereplő is kifejezte készségét egy kísérleti üzemben való részvételre, melynek során hasznosíthatja megszerzett tudását, korábbi tapasztalatait, így pl. BME-IK, Internet Szolgáltatók Tanácsa, NHH. Az Internet Szolgáltatók Tanácsa elsősorban a nyilvántartói feladatok ellátásával, regisztrátori rendszer működtetésével kapcsolatos teendőket és eljárásokat dolgozná ki és koordinálná a kísérleti üzem kapcsán. A BME-IK alkalmazásfejlesztési és tesztelési ill. projektmenedzsment feladatokat vállalna. Az NHH a nemzetközi koordinációban a felügyeleti és szabályozási tevékenység előkészítésében, a telefonszámok hitelesítésében lát feladatokat. 3. Javaslat: Meg kell szervezni és be kell indítani az ENUM kísérleti üzemet, amely bekapcsolódhat a nemzetközi kísérletekbe. Ehhez kormányzati támogatás szükséges.


- 91 -

Felhasznált irodalom

Felhasznált irodalom [1] ENUM Service registration for SIP Addresses-of-Record http://www.ietf.org/internet-drafts/draft-ietf-enum-sip-01.txt [2] ENUM Service Registration for H.323 URL http://www.ietf.org/internet-drafts/draft-ietf-enum-h323-01.txt [3] The "ENUM" URI scheme http://www.ietf.org/internet-drafts/draft-brandner-ENUM-uri-01.txt [4] The tel URI for Telephone Calls http://www.ietf.org/internet-drafts/draft-antti-rfc2806bis-08.txt. [4] ETSI TS 102 172 Services and Protocols for Advanced Networks (SPAN); Minimum requirements for interoperability of European ENUM trials [5] Osztrák trial weblapjain elhelyezett anyagok http://enum.nic.at [6] Francia trial weblapjain elhelyezett anyagok http://www.numerobis.prd.fr [7] Holland trial weblapjain elhelyezett anyagok http://www.enuminnederland.nl [8] Lengyel trial weblapjain elhelyezett anyagok http://www.dns.pl/ENUM [9] Svéd trial weblapjain elhelyezett anyagok http://enum.autonomica.se [10] Australian Communications Authority, Introduction of ENUM in Australia, 2002. [11] Bernardi, Marco ENUM principles and administration aspects, ETNO ENUM workshop, 2002. [12] ETSI ENUM Administration in Europe, 2002. [13] Dutch ENUM Group (NLEG), ENUM in the Netherlands, 2002. [14] Steven Cheung, Department of Computer Science, Universit yof California A Formal-Speci_cation Based Approach for Protecting the Domain Name System [15] Giuseppe Ateniese, Department of Computer Science and JHU Information Security Institute, The Johns Hopkins University, A New Approach to DNS Security (DNSSEC) [16] Hagnell, Staffan, ENUM 2 Description of Administrative Rioutines for ENUM and Prestudy fro the Trieal, 2002. [17] ITU-T. Global Implementation of ENUM: A Tutorial Paper 2002.


- 92 -

Felhasznált irodalom [18] Nooren, P.A., ENUM Enum in the Netherlands – An operator’s view of the currend status and next steps, ETNO ENUM workshop, 2002. [19] NetNumber Inc, ENUM Securiy Policy and Procedure Overwiew, 2002. [20] Reichinger, Kurt, An update on situation on Austria, ETNO ENUM workshop, 2002. [21] Shockey, Richard, ENUM is everywhere, Woice on the Net, Atlanta, 2002.


- 93 -

Függelék

Függelék 1

1.1

Kapcsolódó szabványok

ITU szabványok

ITU-T Recommendation E.105: International Telephone Service ITU-T Recommendation E.164: The International Public Telecommunication Numbering Plan ITU-T Recommendation E.195: ITU-T International numbering resource administration ITU-T Recommendation E.190: Principles and responsibilities for the management, assignment and reclamation of E-series international numbering resources ITU-T Recommendation E.164.1: Criteria and procedures for the reservation, assignment and reclamation of E.164 country codes and associated Identification Codes (IC) ITU-T Recommendation E.213: Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN) ITU-T Recommendation E.168.1: Assignment procedures for universal personal telecommunications (UPT) numbers in the provisioning of the UPT service ITU-T Recommendation E.168: Application of E.164 numbering plan for UPT ITU-T Recommendation E.169: Application of Recommendation E.164 numbering plan for universal international numbers for international telecommunications services using country codes for global services ITU-T Recommendation E.169.1: Application of Recommendation E.164 numbering plan for universal international freephone numbers for international freephone service ITU-T Recommendation E.169.2: Application of Recommendation E.164 numbering plan for universal international premium rate numbers for international premium rate service ITU-T Recommendation E.169.3: Application of Recommendation E.164 numbering plan for universal international shared cost numbers for international shared cost service


- 94 -

Függelék

1.2

ETSI szabványok

ETSI TS 102 051: ENUM Administration in Europe ETSI TS 102 172: Services and Protocols for Advanced Networks (SPAN); Minimum requirements for interoperability of European ENUM trials

1.3

IETF ajánlások9:

RFC 954:

NICNAME/WHOIS

RFC 974:

Mail routing and the domain system

RFC 1032: Domain administrators guide RFC 1033: Domain administrators operations guide RFC 1034: Domain names - concepts and facilities RFC 1035: Domain names - implementation and specification RFC 1101: DNS encoding of network names and other types RFC 1122: Requirements for Internet hosts - comm. layers RFC 1123: Requirements for Internet hosts - application RFC 1536: Common DNS implementation errors RFC 1537: Common DNS data file configuration errors RFC 1591: Domain Name System structure and delegation RFC 1706: DNS NSAP resource records RFC 1712: DNS encoding of geographical location (GPOS) RFC 1713: Tools for DNS debugging RFC 1738: Uniform Resource Locators (URL) RFC 1794: DNS support for load balancing RFC 1876: Expressing location information in the DNS (LOC) RFC 1886: DNS extensions to support IP v6 (AAAA) RFC 1912: Common DNS operational and configuration errors RFC 1982: Serial number arithmetic RFC 1995: Incremental zone transfer in DNS (IXFR) RFC 1996: Prompt notification of zone changes RFC 2010: Operational criteria for root nameservers RFC 2052: Specification of location of services (SRV) RFC 2065: DNS security extensions (KEY/SIG/NXT) 9 Az RFC-k szövege szabadon hozzáférhető és díjfizetés nélkül letölthető, másolható. Egy xxxx számú RFC szövege elérhető a http://www.ietf.org/rfc/rfcxxxx.txt címen.


- 95 -

Függelék RFC 2119: Key words for use in RFCs to indicate requirement levels RFC 2141: URN Syntax RFC 2181: Clarifications to the DNS Specification RFC 2182: Selection and Operation of Secondary DNS Servers RFC 2168: Resolution of Uniform Resource Identifiers using the Domain Name System RFC 2169: A Trivial convention for using HTTP in URN Resolution RFC 2234: Augmented BNF for Syntax Specifications: ABNF RFC 2255: The LDAP URL Format RFC 2368: The mailto URL Scheme RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax RFC 2483: URI Resolution Services Necessary for URN Resolution RFC 2616: Hypertext Transfer Protokol - HTTP/1.1 RFC 2717: Registration Procedures for URL Scheme Names RFC 2782: A DNS RR for specifying the location of services (DNS SRV) RFC 2818: HTTP over TLS RFC 2915: The Naming Authority Pointer (NAPTR) DNS Resource Record RFC 2916: E.164 number and DNS RFC 2916bis: The E.164 to URI DDDS Application RFC 3026: Liaison to IETF/ISOC on ENUM RFC 3261: SIP: Session Initiation Protocol RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS RFC 3402: Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm RFC 3403: Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application RFC 3405: Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures


- 96 -

Függelék

2

Fogalom meghatározások

A tanulmányban egyes kifejezéseket az ENUM-mal összefüggésben speciális értelemben használunk. Fogalom ENUM kliens

Meghatározás Közvetlenül a DNS-hez hozzáférő szoftver funkció, amelynek domain név kereső kérdés tehető fel és amely válaszul NAPTR rekordokat ad vissza. ENUMszolgáltatás Az ENUM DDDS alkalmazás NAPTR rekordjának szolgáltatás mezőjében található azonosító, amely az adott URI séma funkció osztályát jelzi. Nyilvántartó Az 1. szontű (Tier1) adatbázist őrző, karbantartó szervezet, amely az országkód szintű zónafájlt az Internetről elérhetővé teszi. Az adatokat a regisztrátorok által kezdeményezett tranzakcióknak megfelelően módosítja. Regisztrátor Közvetlenül a regisztráltakat ENUM regisztrációs szolgáltatással kiszolgáló szervezet, amely a megbízás alapján a megfelelő mutatóknak és adatoknak az 1. szintű (Tier 1) adatbázisban történő elhelyezéséről gondoskodik. Regisztrált Aki megrendeli, hogy az E.164 számot az ENUM DNS rendszerben regisztrálják. Előfizető Egy E.164 szám jogosult használója, aki hozzájárult, hogy az E.164 számot az ENUM DNS rendszerbe regisztrálják. NS szolgáltató Az E.164 számhoz rendelt NAPTR bejegyzéseket a regisztrált megbízása alapján őrző és karbantartó szervezet (névszerver szolgáltató). Hitelesítő Az a szervezet, ill. eljárás, amely képes megállapítani, hogy egy adott ügyfél, vagy annak képviselője jogosan jelenti-e be igényét egy adot e164-es domainre. Szintén hitelesítésnek nevezzük azt az eljárást, ami a két program között zajlik, amikor azok meg akarnak győződni egzmás valódiságáról. Ilyen értelemben a DNSSEC eljárásainak leírásánal használjuk a fogalmat. ENUM felhasználó Az ENUM rendszert ENUM kliens vagy alkalmazói kliens közvetítésével lekérdező felhasználó. Alkalmazói kliens Alkalmazáshoz, alkalmazás szerverhez felhasználók részére hozzáférést biztosító szoftver


- 97 -

Függelék

3

Rövidítések

Rövidítés CcTLD

Teljes megnevezés Country code top-level domain

CNAME DDDS

Canonical Name Dynamic Delegation Discovery System Domain Name System E.164 to URI resolution Extended Message Service

DNS E2U EMS ENUM ETSI GML GSM GPRS http IAB IANA ICANN IDN IETF IP ISO ISOC ITU LDAP MMS MX NAPTR NS PSTN RFC

Egyéb információ Országkóddal azonosított legfelső szintű domain. (pl. .hu, .fr, .de, .au) kanonikus név ld. RFC 3401 domain név rendszer E.164 -> URI feloldás kiterjesztett üzenetek

Telephone Number Mapping European Telecommunication Standardization Institute Geography Markup Language Global System for Mobile Global Packet Radio Service

telefonszám megfeleltetés Európai Távközlési Szabványügyi Intézet földrajzi helykijelölő nyelv általános mobil szabvány csomagkapcsolt rádióátviteli rendszer adatok továbbítására Hypertext Transfer Protokol ld. RFC 2616 Internet Architecture Board www.iab.org Internet Address and Naming www.iana.org Authority Internet Corporation for www.icann.org Assigned Names and Numbers Internationalized Domain nemzetköziesített domain Names nevek Internet Engineering Task www.ietf.org Force Internet Protocol internet protokoll International Standardization Nemzetközi Szabványügyi Organization Szervezet Internet Society www.isoc.org International Nemzetközi Távközlési Unió Telecommunication Union Lightweight Directory Access ld. RFC 2255 Protocol Multimedia Message Service multimédia üzenetek Mail Exchange Naming Authority Pointer Name Server Public Switched Telephone Network Request For Comment


email kicserélő ld. RFC 2915, RFC 3403 névszerver hagyományos telefonhálózat Internetes szabványok gyűjteménye

- 98 -

Függelék Rövidítés RIPE NCC

URI URL URN VoIP

Teljes megnevezés Réseaux IP Européens Network Control Center Resource Record Session Initiation Protocol Second Level Domain Short Message Service Start Of Authority Unsolicited comercial electronic communications Transmission Control Protocol Top Level Domain One level of the hierarchal tree Time To Live Universal Mobile Telecommunications System Uniform Resource Identifier Uniform Resource Locator Uniform Resource Name Voice over Internet Protocol

WAP

Wireless Access Protokoll

RR SIP SLD SMS SOA SPAM TCP TLD Tier TTL UMTS


Egyéb információ www.ripe.net erőforrás rekord ld. RFC 3261 második szintű domain rövid üzenetek autoritás kezdet kéretlen elektronikus levelek átvitelvezérlési protokoll legfelső szintű domain egy szint a hierarchikus rendszerben élettartam univerzális mobil telekommunikációs rendszer ld. RFC 2396 ld. RFC 1738 ld. RFC 2141 beszédátvitel internet protokollal veztéknélküli hozzáférési protokoll

- 99 -

Az ENUM hazai megvalósításának előkészítése

Recommend Documents