Telefonos és internetes világ - hogyan lehet a DNS összekötő kapocs?

Pásztor Miklós
Pázmány Péter Katolikus Egyetem
Információs Technológiai Kar
pasztor-kukac-ppke.hu

A Networkshop konferencián 2003-ban, Pécsett elhangzott előadás

Internet és telefon

Manapság egy maroktelefonban annyi elektronika van, mint néhány évtizeddel ezelőtt egy intézményi számítógépben. A telefonok sok olyan feladatot ellátnak, amit azelőtt csak számítógépek tudtak: nem csak játékok futnak rajtuk, hanem kalkulátorként, szövegszerkesztőként, internetes hálózati kliensként működnek. Számítógépekkel pedig régóta lehet telefonálni, sőt ha kamera van a számítógéphez csatlakoztatva, akkor nem csak hallani, hanem látni is lehet a beszélgetőpartnert. Ilyen évek óta ismert alkalmazás például a CUCME. Nyilvánvaló, hogy az egységesülés tovább folytatódik mégpedig több irányból, többféle módon. Sok protokoll, termék, szabvány, program készült már évtizedek óta, ami ezt szolgálja. Ebben az írásban két ilyen - egymással összefüggő - szabványosítási törekvésről, és különösen ezek internet DNS-hez kapcsolódó oldaláról lesz szó: a SIP-ről és az ENUM-ról.

DNS

Az Internet Domain Name System (DNS) az internet egyik pillére. Néhány figyelemreméltó tulajdonsága:

Osztott
Az internet neveket a hálózaton szétszórt szerverek százezrei szolgáltatják.

Hierarchikus
Az internet nevek hierarchiát alkotnak: a felső szinten helyezkednek el az (amerikai) intézményfajtákhoz tartozó domainok (pl. .edu, .gov, .mil) és az ISO 3166 szabvány szerinti országkódokhoz tartozó domainok (pl. .pl, .pt, .hu). A DNS egyetlen hierarchikus fát alkot.

A név-fa bármely pontján mód van nem csak elágazásra, hanem az osztott adatbázis adminisztrációjához tartozó jog és felelősség továbbdelegálására. Ilyen módon minden intézmény, intézményi egység maga kezelheti a DNS rá tartozó ágát: érvényesül a szubszidiaritás elve.

Hibatűrő
Az egyes neveket a hálózaton általában több névszerver is szolgáltatja. Egy-egy névszerver kiesése nem bénítja meg a névfeloldást.

A több százezer szolgáltató névszerver konfigurációja nem mentes hibáktól, mégis, az egész DNS gyakorlatilag gördülékenyen működik: valójában minden egyes web lap letöltéskor, levélküldéskor használjuk a DNS-t, de legtöbbször nem is veszünk róla tudomást.

SRV rekordok

Az SRV - server - DNS rekord (RFC2782) arra szolgál, hogy megtudhassuk egy bizonyos szolgáltatás bizonyos protokollal való elérhetőségét egy domainra vonatkozóan. Meg lehet adni több szervert, azok közt preferenciákat definiálhatunk, és megadhatjuk, hogy milyen porton működik a szolgáltatás.

Szerkezete:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target

Például:
_http._tcp.x.hu. 3600 IN SRV 10 20 8000 masina.x.hu.

Hasonlít az SRV rekord feladata a régen használt MX rekordhoz, valójában annak általánosítása: nem csak levelezéssel, hanem bármilyen szolgáltatással kapcsolatban megadhatunk SRV rekordot, megadhatunk többet, melyeket a Priority és a Weight paraméterek rendezhetnek, végül megadhatjuk azt is, hogy milyen protokollal, hanyas porton nyújtjuk a szolgáltatást.

SIP

A Session Initiation Protocol - SIP, RFC3261 - arra szolgál, hogy multimédia kapcsolatok létrehozását, paramétereinek egyeztetését támogassa. Nem közvetlenül arra való tehát, hogy például telefonbeszélgetéseket vigyünk át a segítségével, hanem a kapcsolatfelépítésben és bontásban játszik szerepet. Filozófiájában, működésmódjában hasonlít az SMTP (RFC821) vagy még inkább a HTTP protokollokhoz: az egyes protokollelemek szöveges párbeszéd formájúak, fejből és törzsből állnak. Az üzenet törzsét egy másik szabvány, a Session Description Protocol (RFC 2327) határozza meg, hasonlóan ahhoz, ahogy a HTTP üzenetek törzsét a HTML.

SIP segítségével nem csak telefonbeszélgetést lehet kezdeményezni, hanem képek, mozgóképek közvetítését vagy cseréjét, játékokat, rövid üzenetek váltását és hasonlóakat. A sikeres SIP kapcsolatfeltétel eredményeként két partner egymásra talál, és azután közvetlen TCP/IP kapcsolatba lép. Ebben a fázisban a kommunikáció protokollja az RTP (Real-time Transport Protocol, RFC1889), ennek létrejötte fölött bábáskodott a SIP.

SIP klienskét működhet egy számítógép, egy notebook, egy telefon, mobiltelefon, vagy bármilyen más kütyű. Mód van arra, hogy közönséges telefonok egy átjáró segítségével SIP kliensekként jelenjenek meg.

A SIP szerverek a hívó és a hívott SIP kliensek számára nyújtanak szolgáltatást. Feladatuk a híváskezdeményezés, a címzetthez tartozó SIP kliens megtalálása, a paraméterek egyeztetése, másrészt hívások fogadása, a helyi SIP kliensek esetleges helyváltoztatásának nyomon-követése stb.

A SIP kommunikáció egyes elemeit az 1. ábra szemlélteti

Hol van szerepe a DNS-nek SIP kommunikáció esetén? A DNS ebben az esetben klasszikus módon működik: a sip URI ,,valaki@valahol'' részéből a SIP szerver kiveszi a ,,valahol'' domaint és megkeresi az ahhoz tartozó SIP szervert. Ez leggyakrabban egy SRV rekord, de lehet egy A rekord is. A működés nagyon hasonlít ahhoz, amikor egy levelet akarunk küldeni és a hozzánk közel levő SMTP szerver megkeresi a címzetthez tartozó MX vagy A rekordot.

ENUM

Az alapgondolat

Az ENUM játékos elnevezés, ami a felsorolásra, enumerációra utal és egyúttal egy betűszó is: tElephone NUmber Mapping. Az ENUM célja, hogy telefonszámokból DNS neveket képezzünk, a DNS nevek pedig eligazítást adjanak arra nézve, hogy a hívott milyen módokon érhető el. A lehetséges elérési módok egyike a SIP, de voicemail, http, fax és még sok más lehetőség lebeg a szabványrendszer kidolgozóinak szeme előtt. Azonban mielőtt az ENUM-ra térnénk, szükség van néhány más fogalom és szabvány rövid ismertetésére.

URI, URN

A 90-es évek közepén, a www rohamos térhódítása idején az URL (Uniform Resource Locator, RFC1734) is nagy sikert ért el. Egy URL segítségével különböző protokollokat használhatunk de az egyes hálózati helyeket, erőforrásokat mégis egységes szerkezetben nevezhetjük meg. Például:

http://web.szerver.neve/dir ftp://ftp.szerver.valahol/dir/file

Az URI (RFC2396) bővíti az URL fogalmát: nem csak hálózati erőforrások, hanem tetszőleges konkrét, vagy absztrakt erőforrásnak (pl. könyveknek) is szán URI-t. A gyakorlat azt mutatja, hogy az URL-ek illékonyak: gyakran eltűnnek, változnak. Például ugyanazt a web lapot vagy fájlt, sokszor néhány hét múlva már más helyen találjuk, vagy el is tűnik. Drótos László szellemes fogalmazása szerint az URL-eknek ,,felezési idejük'' van, akárcsak az izotópoknak. Ezért az URI-k között kitüntetett szerepe lehet az URN-eknek, amik egy erőforrás nevét adják meg. Ennek lényeges tulajdonsága, hogy nem változik akkor sem, ha az erőforrás helyet változtat, vagy akár már nem lesz elérhető sehol. Egy URN két részből áll: NID-ből (Name Space Identifier) és NSS-ből (Name Specific String). Példák:

urn:ISBN:1-55937-255-9 urn:duns:002372413:annual-report-1997

Az első példa egy könyv ISBN számának URN-ként való megadását mutatja, a második pedig egy vállalathoz tartozó éves jelentést mutat, ahol a vállalatot DUNS cégjegyzékben szereplő száma azonosítja.

URI sémák

Ahogy az idő haladt, az URI és URN között egyre jobban elmosódtak a határok: hiszen minden URN definíció szerint URI is, másrészt minden URI valamit megnevez, tehát URN is. Az interneten folytonosan használatos http, ftp, mailto URI sémák mellett egy sor más URI séma keletkezett. Ilyenek: ,,tel:'', ,,sip:'', ,,fax:'', ,,h323:'', ,,talk:'', hogy csak néhányat említsünk azok közül, melyek telefonhoz közeli szolgáltatások nevét határozzák meg. Ezek az URI sémák mind szerepet játszanak az ENUM elképzelésekben is.

E.164

Az ITU (International Telecommunication Union) E.164-es ajánlása a telefonszámok nemzetközi szabványa. Ha E.164 szerint írunk egy telefonszámot, az egyértelmű az egész földgolyón. Az E.164 rögzíti például azt, hogy a magyarországi telefonszámok 36-tal kezdődnek.

NAPTR rekord

A Naming Authority PoinTeR, (NAPTR) rekordhoz tartozó első RFC (RFC2168) 1997-ben keletkezett azzal a céllal, hogy a URI-k név feloldását lehetővé tegye. A fő cél az, hogy a név definiálása, és a névfeloldás egymástól függetlenné váljon. A névfeloldásban az internet DNS mellett sok más eszköz is szerepet kaphat. Sőt: a dokumentum szerzői kifejezetten átmeneti megoldásként írnak arról, ha a DNS a feloldás eszköze.

Maga a feloldás is többféle lehet, például:

I2R - Adott az URI, keressük magát a dolgot (resource).
I2L - Adott az URI, keressük az URL-t.
N2R - Adott az URN, keressük magát a dolgot (resource).
N2Rs - Adott az URN, keresünk több dolgot, aminek ez a neve.
L2N - Adott az URL, keressük a hozzá tartozó URN-t.
N2C - Adott az URN, keressük a leírását (URC, Uniform Resource Characteristics).
L2C - Adott az URL, keressük a leírását.
N2Ns - Adott az URN, keresünk több nevet, ami hozzá tartozik.

Az ENUM javaslat bevezetett újabbat:

E2U - Adott egy bizonyos formában egy E.164 szám és ehhez keresünk URI-t.

A NAPTR rekord újszerűsége

A klasszikus DNS-ben

1. A kliens mindig egy domain névre volt kíváncsi. Egy ,,baloldal'' ,,jobboldali'' értékére.
2. Kérdés-válasz volt jellemző. Esetleg (CNAME, MX újabban SRV) néhány kérdés-válasz. Az ilyen esetekben is az első kérdésből a következőre lehetett következtetni. Ezért is adhatnak a DNS szerverek ,,Additional information''-t a válasz rekord megfelelő helyén.

NAPTR esetben ez nem így van. Ami a kliens kezében van, az nem egy domain név, hanem valami más, amiből egy vagy több domain nevet és domain név kérdést képez, a választól és a saját konfigurációjától, állapotától függően azután újabb kérdéseket. Az egész folyamat vége aztán egy olyan URL lehet, amit a klasszikus DNS szabályok szerint lehet feldolgozni.

THTTP

A THTTP - Trivial Convention for using HTTP in URN Resolution - protokoll (RFC2169) a NAPTR specifikációval egyszerre keletkezett. Arra ad javaslatot, hogy egy web szerver HTTP válaszok formájában képes legyen egy NAPTR rekordban definiált feloldást elvégezni. Ilyen módon egyszerűen implementálható - például cgi programok segítségével - bármilyen feloldás: a nevek is lehetnek változatos célúak és szerkezetűek, a kliensek is lehetnek programok vagy személyek és maga a feladat, a feloldás is lehet bármi. A javaslat alkotói azt várták, hogy újabb, összetettebb feloldó protokollok születnek. A gyakorlatban - úgy tűnik, a THTTP maradt az egyetlen használt protokoll. Ezt használja például a norvég nemzeti könyvtár az ott definiált URN-ek feloldására: http://urn.nb.no

NAPTR rekord formátum

Domain TTL Class Order Preference Flags Service Regexp Replacement

A NAPTR algoritmus

Ha adott egy URI, akkor a kliens preferenciáitól, a NAPTR rekordból kapott információból és újabb hálózati interakciókból alakul ki az a válasz, aminek eredményeként egy kliens elér egy erőforrást, hozzáfér egy dokumentumhoz stb. Ennek a folyamatnak a során több NAPTR rekord is szerepet játszhat. A NAPTR rekord egyik eleme egy reguláris kifejezés. Ezt a reguláris kifejezést kell a kiinduló URL-re illeszteni, aminek eredményeként újabb kérések - DNS, THTTP vagy más kérések - vezetnek tovább. A reguláris kifejezés segítségével igen hatékony és rugalmas eszköz áll rendelkezésre a névfeloldáshoz. Megkötés, hogy akárhányadik lépésben is tartunk, mindig az eredeti ,,baloldal''-t kell a reguláris kifejezésre illesztenünk, sohasem valami mást, speciálisan sohasem azt, amit az előző NAPTR kérésnél a reguláris kifejezés eredményeként kaptunk. Egy domain névhez több NAPTR rekord is tartozhat. Ezeket az ,,order'' és a ,,preference'' mezők rendezik. A NAPTR rekord létrehozója illetve a felhasználója ezekben határozza meg a sorrendet, ahogy a rekordokat figyelembe kell, illetve lehet venni.

Flag mező

A NAPTR rekord flag mezője határozza meg, hogy mi legyen a következő lépés a névfeloldásban. Ha a mező ,,u'', akkor az output egy (újabb) URI. Ha a mező ,,s'', akkor a következő lépésben egy SRV rekordot kell keresni, ha ,,a'', akkor A rekordot. A ,,p'' flag azt jelenti, hogy a keresés eredménye protokollfüggő.

Service mező

A mező két részből áll, ezeket egy ,,+'' jel választja el egymástól. Azt határozza meg, hogy milyen protokollal, milyen hozzárendelést tudhatunk meg. Például thttp+n2l azt jelenti, hogy thttp-vel URN->URL hozzárendelést.

A NAPTR rekordhoz tartozó második RFC

A NAPTR rekordnak eredetileg URI volt az inputja (RFC2168), a dokumentum neve is az volt: Hogyan oldjunk fel URI-kat DNS segítségével?

A második változatban, az RFC2915-ben már utalások vannak az ENUM-ra. Itt nem csak URI lehet a baloldal. Sőt, ha egy telefonszámból indulunk ki, akkor kifejezetten URI lesz a jobboldal. A kezdeti baloldal egy E.164 telefonszámból képezett DNS név. A NAPTR rekord jobboldalán olyan URI-k szerepelnek, amik a telefonszám tulajdonosának elérhetőségeit adják meg. Az URI-k feloldása aztán újabb NAPTR rekordok feloldását jelentheti, amikben nem csak DNS hanem más algoritmusok - pl. THTTP - játszanak szerepet. Ilyen módon, a kliens fajtájától, jogosultságától, preferenciájától, a felhasználótól függően árnyalt és változatos válaszok lehetségesek. A ,,tel:'', ,,sip:'', ,,fax:'', ,,h323:'', ,,talk:'' URI sémákon kívül a ,,http:'', ,,https:'' ,,ftp:'' vagy ,,mailto:'' is előfordulhat, jelezvén, hogy ezeken a módokon érhető el a telefonszám tulajdonosa. Az ENUM-ot ismerő kliens azután ezen módokon léphet kapcsolatba a hívott féllel.

Az E164.ARPA domain

Az ENUM feloldás kedvéért - hosszas disputa után - bevezettek egy új domaint az .ARPA top level domain alatt. A legismertebb aldomain itt az IP cím -> név feloldáshoz használt in-addr.arpa domain volt. Akár csak ott, itt is fordított sorrendben kell leírni a számot, amihez tartozó DNS rekordra kíváncsiak vagyunk. Abban is hasonlít az eljárás az in-addr.arpa domainhoz, hogy itt is delegálni lehet a szám mező egyes darabjaihoz tartozó tartományokat. Például a 193.225.0.0/16 IP tartományhoz, vagyis minden 193.225-tel kezdődő IP címhez a 225.193.in-addr.arpa domain tartozik, ezt lehet delegálni a tartomány tulajdonosához. Hasonlóan a 43-mal kezdődő - osztrák - E.164 hívószámokhoz a 3.4.e164.arpa zónát lehet delegálni.

Osztrák ENUM pilot

Ausztriában a telefonos és internetes szolgáltatók összefogásával kísérleti ENUM implementáción dolgoznak. A rendszer fejlesztésében részt vesz az Infonova Web AC nevű vállalkozás.

A 3.4.e164.arpa domain-ba közvetlenül regisztrálnak NAPTR rekordokat vállalkozó szellemű felhasználók számára, tehát nem használják ki azt a lehetőséget, hogy az egyes körzetek és szolgáltatók önálló aldomain-eket használhatnának.

Web-es felület szolgál a regisztrációra. A szolgáltató ellenőrzi a felhasználó telefonszámát és más adatait. Ha minden rendben van, akkor a felhasználó kap egy azonosítót és a egy jelszót. Ennek segítségével egy web-es felületen szerkeszthet NAPTR rekordokat, amik az ő telefonszámához tartoznak. A felhasználónak nem kell tisztában lennie a NAPTR rekord minden részletével: a web-es felületen egy html form segíti a használatot. A rendszer nem támogatja az ENUM ajánlás minden lehetséges URI sémáját, csak a következőket: h323, sip, tel, email, http, https. A rendszerről bővebb információkat nyerhetünk a http://enum.nic.at web helyen.

Összefoglalás

A SIP és az ENUM két egymással szorosan összefüggő technológia. Mindkettő használatához elengedhetetlen a DNS szolgáltatás.

A SIP a DNS-t klasszikus módon használja. Várható, hogy különböző intézmények és szolgáltatók SIP szervereket állítanak fel és számítógépekről, vagy SIP-et tudó telefonokról telefonszám helyett a sip:kovacs.geza@x.hu alakban hívhatunk valakit, akár extra költség nélkül.

Az ENUM URI-kat használ és a NAPTR rekordokon alapul. A NAPTR rekord a DNS új, szerteágazó alkalmazása. Sok szempontból szokatlan és bonyolult. Nem várható, hogy a közeljövőben minden telefonszámhoz fog NAPTR rekord tartozni, de a lehetőség bizonyára vonzó a nagy intézmények számára. Várható, hogy ha valamilyen nagy áruházat hívunk, akkor a ragtime hallgatása helyett a NAPTR-ot tudó telefonunkon e technológiának köszönhetően bájos hölgyeket fogunk látni, amint a legújabb akciókról tájékoztatnak, ha valamilyen hivatalt, akkor pedig a munkaidő lejárta után is kaphatunk képes tájékoztatást telefonunkon arról, milyen sok mindent is tettek ott értünk.

Kapcsolódó linkek