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

Átírás

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

2 Tartalomjegyzék TARTALOMJEGYZÉK 1 BEVEZETŐ AZ ENUM ÁLTALÁNOS ISMERTETÉSE KAPOCS AZ INTERNET ÉS A TÁVKÖZLŐ HÁLÓZAT KÖZÖTT FUNKCIONÁLIS MODELL A DOMAIN NÉV RENDSZER (DNS) ÁTTEKINTÉSE A DOMAIN NÉV RENDSZER (DNS) A domain név rendszer (DNS) jelentősége A domain nevek hierarchiája Domain nevek írásmódja Domain nevek formai követelményei Domain nevek egyedisége Név-cím hozzárendelés, név feloldás Domain név szerverek Delegálás, kezelők Cím-név hozzárendelés DNS gyökér névszerverek Erőforrás rekordok AZ ENUM TECHNOLÓGIA KERESÉS A TELEFONSZÁM ALAPJÁN Az ENUM eljárás A DNS gyökér meghatározása Az E.164 szerinti számok átalakítása domain névvé A DNS lekérdezésre adott válasz A KIKERESETT INFORMÁCIÓ ÉRTELMEZÉSE Az ENUM adatmodell Az ENUM alkalmazások működésének általános sémája Együttműködési követelmények ENUM SZOLGÁLTATÁSOK ÉS A HOZZÁJUK TARTOZÓ URI SÉMÁK ENUM szolgáltatások minimális alaphalmaza További ENUM szolgáltatások ENUM kliensek által lekérdezett információ feldolgozása ENUM ADATOK ADMINISZTRÁLÁSA ADMINISZTRÁCIÓS SZINTEK A DNS RENDSZERBEN Az ENUM gyökér kezelése Az országhoz tartozó domain kezelése A regisztrált aldomainek kezelése AZ ADMINISZTRÁCIÓ SZEREPLŐI Felügyelő testület Nyilvántartó Regisztrátorok Hitelesítő NS szolgáltató Regisztráltak Az ENUM rendszerről - 1 -

3 Tartalomjegyzék 5.3 INTERFÉSZEK A SZEREPLŐK KÖZÖTT Regisztrált és regisztrátor Regisztrált és NS szolgáltató Regisztrátor és nyilvántartó ADMINISZTRATÍV FOLYAMATOK NYILVÁNOS INFORMÁCIÓK ENUM RENDSZER FELHASZNÁLÓI SZEMMEL ENUM FELHASZNÁLÓK KÖRE ENUM SZOLGÁLTATÁSOK, ALKALMAZÁSOK ENUM-ra épülő szolgáltatások Kiindulási és végződtetési pontok Végfelhasználói alkalmazások Fenntartási, karbantartási szolgáltatások ÜZLETI MODELLEK AZ ENUM RENDSZER BIZTONSÁGI FENYEGETETTSÉGE Az ENUM regisztrációs rendszer biztonsági fenyegetettsége Az ENUM lekérdező (DNS) szolgáltatás biztonsági fenyegetettsége ENUM BIZTONSÁGI KERETRENDSZER DNSSEC ENUM lekérdezés (DNS Cache használata nélkül) A DNSSEC protokoll A DNSSEC célja A DNSEC működése Szülő általi hitelesítés Kulcsok váltása Előnyök és hátrányok TSIG Egyéb lehetőségek A DNSEC ÉS TSIG FELHASZNÁLÁSA AZ ENUM RENDSZER BIZTONSÁGI MEGOLDÁSAIBAN Feltételek a DNSSEC használatához FELHASZNÁLT IRODALOM FÜGGELÉK KAPCSOLÓDÓ SZABVÁNYOK ITU szabványok ETSI szabványok IETF ajánlások: FOGALOM MEGHATÁROZÁSOK RÖVIDÍTÉSEK Az ENUM rendszerről - 2 -

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

5 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 1.2 milliárd telefonszám világszerte 350 millió Internet használó 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 -

6 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 0. szint nyilvántartó Validálás Delegálás ENUM regisztrátor Hatóság, Távközlési szolgáltató 0. szint nyilvántartó ENUM előfizető (regisztrált) E.164 számkijelölés Együttműködés Szabályozás, adminisztráció Alkalmazások 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 -

7 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) 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. 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 ) 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 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 egyetemek, oktatási intézmények com Vállalatok mil katonai szervezetek gov Kormányzat net hálózati szervezetek, szolgáltatók org mindenféle más szervezet Az ENUM rendszerről - 6 -

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

9 A domain név rendszer (DNS) áttekintése 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 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 nevet kell feloldani, mert ott egy Web lapot akarunk megnézni. Ezért az általunk használt Web böngészőnek megadjuk a 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 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 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. Az ENUM rendszerről - 8 -

10 A domain név rendszer (DNS) áttekintése 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 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 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. Az ENUM rendszerről - 9 -

11 A domain név rendszer (DNS) áttekintése 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 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: Az ehhez a címhez tartozó nevet úgy kapjuk meg, hogy a domain rendszertől megkérdezzük a 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. Az ENUM rendszerről

12 A domain név rendszer (DNS) áttekintése 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 i.root-servers.net NORDUNET/KTH Stockholm, Sweden d.root-servers.net University of Maryland College Park, MD, USA e.root-servers.net NASA (Ames) Mt. View, CA, USA c.root-servers.net PSINet Ashburn, VA, USA m.root-servers.net WIDE Tokyo, Japan f.root-servers.net ISC Palo Alto, CA, USA j.root-servers.net Verisign GRS Herndon, VA, USA b.root-servers.net USC-ISI Los Angeles, CA, USA g.root-servers.net US Dept. of Defense (DISA) Vienna, VA, USA l.root-servers.net ICANN Los Angeles, CA, 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 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. Az ENUM rendszerről

13 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 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. ( ;Serial nr ;Refresh 1800 ;Retry ;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 cím, melyet úgy kapunk, ha az első olyan. karaktert, amit nem előz meg backslash (\), at 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. Az ENUM rendszerről

14 A domain név rendszer (DNS) áttekintése 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 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 200- szor 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 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 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 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- Az ENUM rendszerről

15 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 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 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 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 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 10 masina.valahol.hu. MX 20 mas.mashol.hu. Ezek a sorok azt jelentik, hogy a valaki@valahol.hu 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

16 A domain név rendszer (DNS) áttekintése 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 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 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 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 x alakú címekkel, akkor célszerű, ha nála van a 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. Az ENUM rendszerről

17 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 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ó 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 t (például ben 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 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 hierar- Az ENUM rendszerről

18 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ó 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 ). 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. 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 e164.arpa). Ezzel megkaptuk a DNS használatához szükséges ún. teljesen meghatározott domain nevet. Gyökér.arp.hu....com.e164.arp.in-addr.bme 2. szintű domain 2. szintű domain.6.3.e164.arpa.ik 3. szintű domain e164.arpa 7. ábra Az ENUM helye a DNS hierarchiában Az ENUM rendszerről

19 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 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ó címet keresi?" kérdésre nyugodtan beírhatjuk a " " karaktersorozatot, mert a program ezt értelmezi és elvégzi az átalakítási lépéseket, majd a DNS-nek elküldi a 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 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. ü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. Az ENUM rendszerről

20 Az ENUM technológia 4.2 A kikeresett információ értelmezése Az ENUM adatmodell A zónafájlban található ENUM specifikus adatok formátumát, értelmezését az RFC (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 Az ENUM rendszerről