Az ENUM technológia. - oktatási anyag - Budapesti Műszaki és Gazdaságtudományi Egyetem, Informatikai Központ Verzió: 1.0 Dátum:

Az ENUM technológia - oktatási anyag -

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

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

Tartalomjegyzék

TARTALOMJEGYZÉK 1

BEVEZETŐ...................................................................................................................... 3

2

AZ ENUM ÁLTALÁNOS ISMERTETÉSE.................................................................. 4 2.1 2.2

3

KAPOCS AZ INTERNET ÉS A TÁVKÖZLŐ HÁLÓZAT KÖZÖTT........................................... 4 FUNKCIONÁLIS MODELL .............................................................................................. 4

A DOMAIN NÉV RENDSZER (DNS) ÁTTEKINTÉSE ............................................. 6 3.1 A DOMAIN NÉV RENDSZER (DNS) ............................................................................... 6 3.1.1 A domain név rendszer (DNS) jelentősége ......................................................... 6 3.1.2 A domain nevek hierarchiája ............................................................................. 6 3.1.3 Domain nevek írásmódja.................................................................................... 7 3.1.4 Domain nevek formai követelményei.................................................................. 7 3.1.5 Domain nevek egyedisége .................................................................................. 8 3.1.6 Név-cím hozzárendelés, név feloldás.................................................................. 8 3.1.7 Domain név szerverek ........................................................................................ 8 3.1.8 Delegálás, kezelők ............................................................................................ 10 3.1.9 Cím-név hozzárendelés..................................................................................... 10 3.1.10 DNS gyökér névszerverek................................................................................. 11 3.1.11 Erőforrás rekordok........................................................................................... 11

4

AZ ENUM TECHNOLÓGIA ....................................................................................... 16 4.1 KERESÉS A TELEFONSZÁM ALAPJÁN .......................................................................... 16 4.1.1 Az ENUM eljárás ............................................................................................. 16 4.1.2 A DNS gyökér meghatározása.......................................................................... 16 4.1.3 Az E.164 szerinti számok átalakítása domain névvé ........................................ 17 4.1.4 A DNS lekérdezésre adott válasz...................................................................... 18 4.2 A KIKERESETT INFORMÁCIÓ ÉRTELMEZÉSE ............................................................... 19 4.2.1 Az ENUM adatmodell....................................................................................... 19 4.2.2 Az ENUM alkalmazások működésének általános sémája ................................ 20 4.2.3 Együttműködési követelmények ........................................................................ 22 4.3 ENUM SZOLGÁLTATÁSOK ÉS A HOZZÁJUK TARTOZÓ URI SÉMÁK ............................ 25 4.3.1 ENUM szolgáltatások minimális alaphalmaza ................................................ 25 4.3.2 További ENUM szolgáltatások......................................................................... 28 4.3.3 ENUM kliensek által lekérdezett információ feldolgozása .............................. 28

5

ENUM ADATOK ADMINISZTRÁLÁSA................................................................... 31 5.1 ADMINISZTRÁCIÓS SZINTEK A DNS RENDSZERBEN ................................................... 31 5.1.1 Az ENUM gyökér kezelése................................................................................ 31 5.1.2 Az országhoz tartozó domain kezelése ............................................................. 31 5.1.3 A regisztrált aldomainek kezelése .................................................................... 31 5.2 AZ ADMINISZTRÁCIÓ SZEREPLŐI................................................................................ 32 5.2.1 Felügyelő testület ............................................................................................. 32 5.2.2 Nyilvántartó...................................................................................................... 32 5.2.3 Regisztrátorok .................................................................................................. 35 5.2.4 Hitelesítő .......................................................................................................... 35 5.2.5 NS szolgáltató................................................................................................... 36 5.2.6 Regisztráltak..................................................................................................... 36

Az ENUM rendszerről

-1-

Tartalomjegyzék 5.3 INTERFÉSZEK A SZEREPLŐK KÖZÖTT ......................................................................... 36 5.3.1 Regisztrált és regisztrátor ................................................................................ 36 5.3.2 Regisztrált és NS szolgáltató ............................................................................ 37 5.3.3 Regisztrátor és nyilvántartó ............................................................................. 37 5.4 ADMINISZTRATÍV FOLYAMATOK ............................................................................... 38 5.5 NYILVÁNOS INFORMÁCIÓK ........................................................................................ 40 6

ENUM RENDSZER FELHASZNÁLÓI SZEMMEL................................................. 41 6.1 ENUM FELHASZNÁLÓK KÖRE ................................................................................... 41 6.2 ENUM SZOLGÁLTATÁSOK, ALKALMAZÁSOK ............................................................ 41 6.2.1 ENUM-ra épülő szolgáltatások........................................................................ 41 6.2.2 Kiindulási és végződtetési pontok .................................................................... 42 6.2.3 Végfelhasználói alkalmazások.......................................................................... 44 6.2.4 Fenntartási, karbantartási szolgáltatások........................................................ 48 6.3 ÜZLETI MODELLEK .................................................................................................... 48

7

AZ ENUM RENDSZER BIZTONSÁGI FENYEGETETTSÉGE ............................ 49 7.1.1 Az ENUM regisztrációs rendszer biztonsági fenyegetettsége .......................... 49 7.1.2 Az ENUM lekérdező (DNS) szolgáltatás biztonsági fenyegetettsége ............... 50 7.2 ENUM BIZTONSÁGI KERETRENDSZER ....................................................................... 51 7.3 DNSSEC................................................................................................................... 52 7.3.1 ENUM lekérdezés (DNS Cache használata nélkül) ......................................... 52 7.3.2 A DNSSEC protokoll ........................................................................................ 53 7.3.3 A DNSSEC célja ............................................................................................... 54 7.3.4 A DNSEC működése ......................................................................................... 54 7.3.5 Szülő általi hitelesítés....................................................................................... 55 7.3.6 Kulcsok váltása ................................................................................................ 56 7.3.7 Előnyök és hátrányok ....................................................................................... 56 7.3.8 TSIG ................................................................................................................. 56 7.3.9 Egyéb lehetőségek ............................................................................................ 57 7.4 A DNSEC ÉS TSIG FELHASZNÁLÁSA AZ ENUM RENDSZER BIZTONSÁGI MEGOLDÁSAIBAN .................................................................................................................. 57 7.4.1 Feltételek a DNSSEC használatához................................................................ 58

FELHASZNÁLT IRODALOM ............................................................................................ 59 FÜGGELÉK ........................................................................................................................... 61 1

KAPCSOLÓDÓ SZABVÁNYOK ......................................................................................... 61 1.1 ITU szabványok .................................................................................................... 61 1.2 ETSI szabványok .................................................................................................. 62 1.3 IETF ajánlások:.................................................................................................... 62 2 FOGALOM MEGHATÁROZÁSOK ...................................................................................... 64 3 RÖVIDÍTÉSEK ................................................................................................................ 65


-2-

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.


-3-

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

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.

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ázist használják fel arra, hogy a telefonszámokhoz a Az ENUM rendszerről

-4-

Az ENUM általános ismertetése 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. ITU

0. szint nyilvántartó

Nemzeti keretszabályozás

Delegálás


Validálás

ENUM regisztrátor

Delegálás


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

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. 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. Az ENUM rendszerről

-5-

A domain név rendszer (DNS) áttekintése

3 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.

3.1 A domain név rendszer (DNS)

3.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.

3.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 net org

egyetemek, oktatási intézmények Vállalatok katonai szervezetek Kormányzat hálózati szervezetek, szolgáltatók mindenféle más szervezet


-6-

A domain név rendszer (DNS) áttekintése 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).

3.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).

3.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. Használhatóvá váltak 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.


-7-


3.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.

3.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.

3.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.


-8-

A domain név rendszer (DNS) áttekintése 3.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. 3.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. 3.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.


-9-


3.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.

3.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.


- 10 -


3.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

3.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.


- 11 -

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. 3.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, és 1 hetes (604800) expire 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.1

1 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.


- 12 -

A domain név rendszer (DNS) áttekintése 3.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. 3.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. 3.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-


- 13 -

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. 3.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. 3.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 rendszerről

- 14 -

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. 3.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. 3.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. 3.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.


- 15 -

Az ENUM technológia

4 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.

4.1 Keresés a telefonszám alapján

4.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.

4.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 rendszerről

- 16 -

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ó.

4.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

.bme

.in-addr

.6.3.e164.arpa

.ik

... 2. szintű domain

3. szintű domain

... 8.7.6.5.4.3.2.1.6.3.e164.arpa

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


- 17 -

.com

2. szintű domain

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.

4.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, immá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.


- 18 -


4.2 A kikeresett információ értelmezése

4.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. 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 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 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


- 19 -

Az ENUM technológia 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. ENUM szolgáltatás azonosító (+ jel és szöveg), amit egy protokoll azonosító követ (: jel és szöveg). Pl. "E2U+message:mailto". Az ENUM szolgá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 ENUM szolgá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.

4.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. 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.


- 20 -

Az ENUM technológia ENUM 1.szint Nyilvántartó NS

ENUM 2.szint Nyilvántartó NS

ENUM frissítések

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. 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 ENUM szolgá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.


- 21 -


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.

4.2.3 Együttműködési követelmények Annak veszélye, hogy az egyes kísérletekben kidolgozott, ENUM szolgáltatásokat megvalósító rendszerek nem tudnak együttműködni a következő elvek betartásával jelentősen csökkenthető: − 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 ENUM rendszerről

- 22 -

Az ENUM technológia − 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 (ENUM szolgáltatás) mezőt a 4.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 lennie, 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 ENUM szolgáltatásoknak melyek azonosítói az ENUM-hoz tartozó NAPTR rekordok Szolgáltatás mezőjében szerepelhetnek. A definiált ENUM szolgá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ó ENUM szolgáltatások és URI Sémák a 4.3. fejezetben kerülnek felsorolásra. Ez nem jelenti azt, hogy egy ENUM kliensnek minden, a listában szereplő ENUM szolgáltatást támogatnia kell. Fel kell ismernie a listában szereplő ENUM szolgáltatások jelentését és a nem támogatott ENUM szolgáltatások és URI Sémák esetén előre definiált módon kell viselkednie.

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. 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. 4.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 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:


- 23 -

Az ENUM technológia •

•

•

• •

•

•

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 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 truncated 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


- 24 -


•

•

•

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 ENUM szolgá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 ENUM szolgáltatáshoz tartozna. 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ötődnek egy-egy URI-hoz, vagyis ezen szolgáltatásokhoz tartozó kombinált NAPTR rekord több URI-t kellene, hogy tartalmazzon.

4.3 ENUM szolgáltatások és a hozzájuk tartozó URI sémák

4.3.1 ENUM szolgáltatások minimális alaphalmaza Minden ENUM szolgá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. 4.3.1.1 ENUM szolgáltatások média stream átvitelre

Ez az ENUM szolgá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.

4.3.1.1.1 Hang átviteli szolgáltatások Az ENUM rendszerről

- 25 -

Az ENUM technológia − voice:sip − voice:h323 − voice:tel

4.3.1.1.2 Videó átviteli szolgáltatások − video:sip − video:h323 − video:tel 4.3.1.2 ENUM szolgá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. − email:mailto − fax:tel − sms:tel − ems:tel − mms:tel 4.3.1.3 ENUM szolgáltatások információ forrásokra

Ezek az ENUM szolgáltatás mezők olyan NAPTR rekordokat jelölnek, melyekben azonosított erőforrások információforrások lehetnek. − web:http − web:https − ftp:ftp 4.3.1.4 ENUM szolgáltatások szolgáltatást feloldó (engedélyező) szolgáltatásokhoz

Ezt a csoportját az ENUM szolgá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 Ez az egyetlen olyan szolgáltatás, ahol a protokoll rész nem használt. Erről az ENUM szolgáltatásról az [1] és [2] irodalmak tartalmaznak bővebb információt.


- 26 -

Az ENUM technológia 4.3.1.5 ENUM szolgáltatások session-oriented üzenet küldésre

Ezek az ENUM szolgá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 − im:sip 4.3.1.6 ENUM szolgáltatások hirdetmények megjelenítésére

Az ENUM szolgá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 − ann:http − ann:ftp 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ó. 4.3.1.7 ENUM szolgáltatások átirányítása

Ez az ENUM szolgáltatás különleges abból a szempontból, hogy magában foglalja az összes többi ENUM szolgáltatást. A cél az volt, hogy egy alapértelmezett ENUM szolgá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) 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.


- 27 -


4.3.2 További ENUM szolgáltatások 4.3.2.1 ENUM szolgáltatások helymeghatározásra

Ez az ENUM szolgá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 4.3.2.2 ENUM szolgáltatások nyilvános kulcs (Public Key) megadására

Ez az ENUM szolgá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

4.3.3 ENUM kliensek által lekérdezett információ feldolgozása 4.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 a 4.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, a 4.3.1 fejezetben megadott listában szereplő szolgáltatást támogatnia kell. − Az azonosított (kliens által ismert) ENUM szolgá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 ENUM szolgá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” ENUM szolgá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 a 4.3.1.7 ENUM szolgá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” ENUM szolgáltatást kell lekérdeznie. Ha van ilyen ENUM szolgá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” ENUM szolgá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.)


- 28 -

Az ENUM technológia Az ENUM kliensnek meg kell jelenítenie az összes olyan „ann:http” ENUM szolgá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 ENUM szolgá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 ENUM szolgá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. 4.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 igénybevétele az E.164 szám „cél” mezőbeli, +NNN formátumban való megadásával történik. 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” ENUM szolgáltatást kell lekérdeznie. Ha van ilyen ENUM szolgá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” ENUM szolgá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” ENUM szolgá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 ENUM szolgáltatásokhoz tartoznak, melyek az adott alkalmazás kliens által megvalósított szolgáltatással kapcsolatosak.


- 29 -

Az ENUM technológia 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. 4.3.3.3 ENUM-képes SIP kliens (alkalmazás kliens példa)

Az ENUM-képes SIP kliens először a „sip” ENUM szolgáltatáshoz tartozó NAPTR rekordokat kell keresnie. Ha megtalálta a „sip” ENUM szolgá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” ENUM szolgáltatáshoz tartozó NAPTR rekord, akkor az ENUMképes SIP kliensnek kereshet „voice:sip” ENUM szolgá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” ENUM szolgáltatáshoz tartozó NAPTR rekordokat az adott típusú szolgáltatások felajánlása érdekében.


- 30 -

ENUM adatok adminisztrálása

5 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.

5.1 Adminisztrációs szintek a DNS rendszerben

5.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.

5.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.

5.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.


- 31 -


5.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).

5.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.

5.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.


- 32 -

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. 5.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 rendszerről

- 33 -

ENUM adatok adminisztrálása 5.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,


- 34 -


5.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.

5.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 rendszerről

- 35 -

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.

5.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.

5.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.

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

5.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 rendszerről

- 36 -

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.

5.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.

5.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 (név, azonosító, cím, telefonszám, faxszám, emailcím) − adminisztratív kontakt objektuma (név, azonosító, cím, telefonszám, faxszám, emailcím) Az ENUM rendszerről

- 37 -

ENUM adatok adminisztrálása − műszaki kontakt objektuma (név, azonosító, cím, telefonszám, faxszám, emailcím) 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 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.

5.4 Adminisztratív folyamatok Az ENUM domainek regisztrálásával kapcsolatos ügyeket az alábbi csoportokba sorolhatjuk: Az ENUM rendszerről

- 38 -

ENUM adatok adminisztrálása − ú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ésre. 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ű-


- 39 -

ENUM adatok adminisztrálása 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.

5.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 (név, cím, telefonszám, faxszám, emailcím) − adminisztratív kontakt adatai (név, cím, telefonszám, faxszám, emailcím) − műszaki kontakt adatai (név, cím, telefonszám, faxszám, emailcím) − regisztrátor adatai (név, cím, telefonszám, faxszám, emailcím) − 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. 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. 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 (név, cím, telefonszám, faxszám, emailcím) − regisztrátor adatai (név, cím, telefonszám, faxszám, emailcím) − a beregisztrálás időpontja − az utolsó módosítás időpontja


- 40 -

ENUM rendszer felhasználói szemmel

6 ENUM rendszer felhasználói szemmel 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 röviden.

6.1 ENUM felhasználók köre 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ó

6.2 ENUM szolgáltatások, alkalmazások

6.2.1 ENUM-ra épülő szolgáltatások Az ENUM-ra épített 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 teleAz ENUM rendszerről

- 41 -

ENUM rendszer felhasználói szemmel fonhá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.

6.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. 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


- 42 -


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 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


- 43 -

ENUM rendszer felhasználói szemmel Hálózat

Terminál/alkalmazás 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 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.

6.2.3 Végfelhasználói alkalmazások 6.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. 6.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.


- 44 -

ENUM rendszer felhasználói szemmel 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é. • 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ó.


- 45 -


ENUM Nyilvántartó NS

SIP szerver

SIP szerver

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

6.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


- 46 -

ENUM rendszer felhasználói szemmel Megnevezés

Leírás (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

6.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

- 47 -

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


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

6.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. − 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.

6.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.


- 48 -

Az ENUM rendszer biztonsági fenyegetettsége

7 Az ENUM rendszer biztonsági fenyegetettsége 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.

7.1.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. 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. 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ó. 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 adatokon. 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. A támadók legtöbbször ahhoz a módszerhez folyamodnak, hogy az ENUM rendszer egyes Az ENUM rendszerről

- 49 -

Az ENUM rendszer biztonsági fenyegetettsége elemeit (Registry, 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. 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.

7.1.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, mivel alapvetően egy nyílt adatbázis, amely biztonsága elsősorban a hitelességet jelenti. 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

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


Cache megszemélyesít ése

- 50 -

Az ENUM rendszer biztonsági fenyegetettsége − Zóna adatok megváltoztatása: amennyiben az elsődleges kiszolgálón a támadónak sikerül a zónafájl tartalmát megváltoztatni, 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).

7.2 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. szintű 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-


- 51 -

Az ENUM rendszer biztonsági fenyegetettsége 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

15. ábra ENUM biztonsági keretrendszer

7.3 DNSSEC

7.3.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:


- 52 -

Az ENUM rendszer biztonsági fenyegetettsége [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.

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

7.3.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 rekordtí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: Az ENUM rendszerről

- 53 -

Az ENUM rendszer biztonsági fenyegetettsége − 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.

7.3.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.

7.3.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. − 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.


- 54 -

Az ENUM rendszer biztonsági fenyegetettsége 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 a kérdéses zóna által publikált kulcs valódiságáról. 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.

7.3.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. 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.


- 55 -


7.3.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.

7.3.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.

7.3.8 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.


- 56 -


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 TSIG 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 haszná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.

7.3.9 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.

7.4 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: Az ENUM rendszerről

- 57 -

Az ENUM rendszer biztonsági fenyegetettsége − 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.

7.4.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 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.


- 58 -

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.


- 59 -

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.


- 60 -

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


- 61 -

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ások2:

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) 2 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.


- 62 -

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


- 63 -

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. ENUM szolgá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


- 64 -

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

- 65 -

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

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 SÍP SLD SMS SOA SPAM TCP TLD Tier TTL UMTS


- 66 -

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

Az ENUM technológia. - oktatási anyag - Budapesti Műszaki és Gazdaságtudományi Egyetem, Informatikai Központ Verzió: 1.0 Dátum:

Recommend Documents