enum - PRINCIPY, ZKUŠENOSTI A UKÁZKY

Transkript

1 enum - PRINCIPY, ZKUŠENOSTI A UKÁZKY Ing. Jan RŮŽIČKA pracoviště: CESNET, zájmové sdružení právnických osob; mail: janru@cesnet.cz Abstrakt: Článek popisuje dva existující přístupy adresace v komunikačních systémech a ENUM, který může tvořit most mezi těmito světy. Následně se věnuje principu fungování ENUMu, tedy struktuře záznamů a jeho různým typům stromům. Další kapitoly popisují bezpečnost v prostředí ENUMu, jeho výhody a nevýhody a stav implementace v České republice i ve světě. Na závěr jsem připojil něco z našich poznatků z fungování systému. 1 Propojení světů Svět klasické telefonie je založen na telefonních číslech. Tato čísla jsou používána ve standardizovaném formátu E.164 [1]. Formát rozděluje číslo v zásadě na jedno až třímístný národní kód (CC) a doplněním až do patnácti číslic je národní číslo. Jde o hierarchické uspořádaní číselného prostoru. Přidělování mezinárodních kódů (například 420 v případě České republiky) zajišťuje ITU.T a na národních úrovních je za přidělování zodpovědný regulátor, což je v případě ČR Český telekomunikační úřad (ČTÚ). ČTÚ přiděluje čísla jednotlivým operátorům i koncovým účastníkům. Operátoři pak dále přidělují čísla svým zákazníkům. U subjektů, kteří nejsou operátory jde obvykle o velké instituce jako například České dráhy, Ministerstvo vnitra a podobně. CESNET a Západočeská Univerzita (ZČU) využívají takové přímo přidělené bloky (9500 a 9509) pro své vnitřní sítě. Vzhledem k tomu, že již funguje přenositelnost čísla, není s jistotou možné podle prefixů poznat, kterému operátorovi číslo patří. Informace o tom, komu je číslo regulátorem přiděleno naleznete na webu ČTU ( Směrování v telefonních sítí probíhá tedy na základě telefonních čísel a obvykle pomocí protokolu SS7. Dále v tomto světě funguje mnoho dalších subjektů jako tranzitní operátoři a podobně. Navíc se s hovory nebo spíše minutami do určitých destinací (zemí) čile obchoduje a směrování jak tak obohaceno o další prvek, který může ovlivnit cestu hovoru a nesetkáme se s plně distribuovaným směrovacím systémem jako je tomu v internetu. Je asi také vhodné připomenout že v klasické telefonii je hovor sestavován jako pevná (po dobu hovoru) cesta okruh na rozdíl od přenosu v současných datových sítích (internetu) které jsou založeny na přepínání paketů. Nicméně to, že operátor navenek ke svým koncovým zákazníkům nenabízí IP telefonii neznamená, že uvnitř přenosy po IP infrastruktuře nevyužívá. Naproti tomu svět počítačových síti, potažmo internetu spíše využívá adres symbolických. Příkladem je doménové jméno počítače (sip.cesnet.cz) nebo adresy jednotlivých služeb jako ová adresa, sip adresa (sip:janru@cesnet.cz) a tak dále. Adresy služeb jsou obvykle uvedeny včetně schématu, tedy určení o jakou službu jde. Například u u by to bylo mailto:, nicméně v tomto konkrétním případě se s tím málokdy setkáme, protože je automaticky předpokládáno, že jde o . Nicméně stejnou adresu může použít i SIP a lišit se budou právě onou předponou, která může v tomto případě být sip:. Místo identifikátoru uživatele se může v adrese objevit i telefonní číslo. Nicméně samo, tedy bez patřičné domény není dostatečným podkladem pro směrování požadavku. Hierarchickou organizaci v těchto jménech-adresách vyčíst také, tentokrát postupujeme-li od konce. Domény první úrovně nemusí být nutně národní jako.cz ale i mezinárodní jako.com. Následuje několik úrovní, které obvykle identifikují například firmu nebo poskytovatele služeb a její organizační uspořádání až ke jménu počítače v případě doménového jména nebo uživatele (schránky) v případě u a podobných. O přidělování domén první úrovně se stará IANA (Internet Assingn Numbers Authority) a dále pak hierarchicky správci příslušné části stromu. Jak tedy vhodně provázat svět telefonních čísel a identifikátorů využívaných v sítích, aby tyto dva světy mohly spolupracovat? Samozřejmě se nabízí různá řešení v podobě lokálních nebo i sdílených databází. Přestože mohou tyto systémy mít své výhody a uzavřeným komunitám vyhovovat nejsou vhodné pro otevřené nasazení, které by mohlo sloužit v podstatě komukoliv, tak jak je tomu v dnešním internetu běžné. Pro tento případ je odpovědí na výše položenou otázkou ENUM. Sama zkratka je vykládána mnoha způsoby jako například Electronic Numbering, E.164 Number Mapping a podobně. Podstatný je však princip jeho fungování. strana 89

2 2 Princip fungování ENUMu Teorie a praxe IP telefonie - 3. dvoudenní odborný seminář Zjednodušeně si lze ENUM představit jako černou skřínku, kde na jedné straně vkládáme telefonní číslo a požadovaný typ odpovědi a na straně druhé dostáváme požadovaný identifikátor. ENUM tedy slouží k mapování prostoru telefonních číslech na libovolné prostory identifikátoru [5]. Nejčastěji jsou cílovým prostorem SIPové adresy, ale kromě nich to mohou být další identifikátory IP telefonních služeb jako H.323, IAX, ale nejen to, může jít i o ové adresy, adresu webových stránek, vcard nebo elektronickou navštívenku a mnoho dalších. V současné době existuje již několik desítek registrací takových služeb. ENUM je konkrétním příkladem DDDS (Dynamic Delegation Discovery System) popsaných v RFC [2] a sám je popsán v RFC3761 [3]. Obr. 1: ENUM jako černá skřínka Pro uložení pravidel využívá ENUM systém DNS (dle RFC3403) a to konkrétně NAPTR záznamy. Telefonní číslo však není použito v klasickém tvaru (například ), ale je transformováno následujícím způsobem: 1. Jsou vyjmuty všechny mezery pomlčky a úvodní plus. Zůstávají tedy pouze číslice. ( ) 2. Mezi číslice jsou vloženy tečky. ( ) 3. Je převráceno pořadí číslic. ( ) 4. Je přidán řetězec identifikující strom. Zde půjde o.e164.arpa. Problematice stromů se budeme věnovat později. V jmenném serveru jsou například v příslušném zónovém souboru umístěny pro e164.arpa následující záznamy : $ORIGIN e164.arpa. ;;order pref flags service regexp replacement IN NAPTR "u" "E2U+sip" "!^\\+420(.*)$!sip:\\1@cesnet.cz!". IN NAPTR "u" "E2U+h323" "!^\\+(.*)$!h323:\\1@cesnet.cz!". První dvě položky, IN a NAPTR, určují typ záznamu. Pro každý záznam lze specifikovat i TTL (Time To Live). Pokud není uveden, použije se životnost určená pro celou zónu. Doporučil bych nastavovat TTL někde v rozmezí jedné hodiny a jednoho dne aby se případná změna projevila v rozumném časovém horizontu. Záleží však na konkrétní strategii. Pro testovaní je samozřejmě vhodné volit dobu kratší, třeba i jen šedesát vteřin. strana 90

3 Jednotlivé sloupce mají následujíc význam: Teorie a praxe IP telefonie - 3. dvoudenní odborný seminář ORDER: Pořadí záznamu. Podle této hodnoty jsou vzestupně seřazeny všechny záznamy, které dotazující strana obdrží. PREFERENCE: Určuje pořadí při shodě položky ORDER. FLAG: V případě ENUMU nabývá pouze jedné hodnoty a tou je "u", což označuje terminální záznam. SERVICE: Popisuje typ služby. Počáteční E2U je opět specifický identifikátor ENUMu, který je následován typem případně podtypem ENUM služby (napr sip, voice:sip). Každý identifikátor služby musí být zaregistrován. Upozorňuji, že v průběhu vývoje došlo k otočení zápisu tohoto pole. Původně se používal zápis například sip+e2u, ale v současnosti se používá E2U+sip. REGEXP: regulární výraz který je aplikován na původní telefonní číslo (bez mezer a pomlček ale s úvodním plus). Výsledkem aplikace v případě prvního záznamu tak bude sip: @cesnet.cz. Regulární výraz může vypadat také například "!^(.*)$!sip:janru@cesnet.cz!", výsledek je pak zřejmý. REPLACEMENT: není v tomto kontextu využit. Jak bylo již řečeno, registrovaných služeb je několik desítek a jejich počet se zvyšuje. Seznam lze nalézt na ftp://ftp.iana.org/assignments/enum-services. Upozorňuji, že jméno ENUM služby nemusí být totožné se schématem identifikátoru. Dotazující se jednotka, ať již je to například SIP server nebo klient. Provede zmíněnou transformaci a položí DNS dotaz a obdrží zpět sadu záznamů, pokud existují. Tyto seřadí a postupuje podle seznamu. Zjistí, zda je schopen použít službu popsanou v servisním poli a v souhlasném případě aplikuje regulární výraz. Výsledný identifikátor použije pro navázaní spojení pomocí příslušného protokolu. 3 Různé typy ENUMu Mohlo by se zdát že ENUM je jen jeden, ale z jistého pohledu tomu tak není. Pravděpodobně všichni se setkali s různými pojmenováními jako uživatelský ENUM, operátorský ENUM, infrastrukturní, privátní a podobně. Ve skutečnosti je ENUM jako mechanismus pouze jeden, ale zmíněná pojmenování vycházejí z toho jaký strom - jaká přípona je použita a jaká politika se k použití ono stromu váže. Základní rozdělení popisuje následující tabulka. Veřejný Privátní Uživatelský e164.arpa e164.org, nrenum.net Infrastrukturní Není definován e164.info Tab. 1: Typy ENUMu příklady stromů 3.1 Veřejný uživatelský ENUM Veřejný uživatelský ENUM, který je identifikovatelný podle přípony e164.arpa, bývá někdy označován jako jediný správný ENUM. Nicméně především politika jeho použití dala vzniknou i dalším stromům. Existence záznamů v tomto stromě je regulována několika opatřeními. Jde o veřejný strom, tedy do přidělování jednotlivých větví (zón) zasahuje v nejvyšší úrovní ITU.T. Nejvyšší úrovní, kde se strom dělí, obvykle rozumíme národní kódy zemí. Pro přidělení národního kódu je potřeba získat souhlas odpovědné národní instituce, kterou je obvykle regulátor. Už tento krok v mnoha zemích znamená problém, protože pro regulátory je to poměrně nová oblast. Kromě toho se vyskytují i geopolitické problémy jako například u kódu +1, který sdílí přes 20 zemí a oblastí včetně USA a Kanady v rámci takzvaného NANP (North American Numbering Plan). Tyto země by se pro přidělení zóny musely dohodnout, k čemuž nedošlo. Následně i v rámci národní zóny je potřeba prokazovat oprávněnost vložení záznamů validačním procesem, který vyjadřuje zda je žadatel oprávněným uživatelem čísla. Zde je další specifikum veřejného uživatelského ENUMu, záznamy do něj může vkládat pouze uživatel nikoliv operátor. I když existuje výjimka a tou je situace strana 91

4 kdy operátor používá tato čísla pro vlastní potřebu. Uživatel zde sám vyjadřuje jakým způsobem chce být kontaktován a je tedy zcela na něm zda zde uveřejní například svou ovou adresu či nikoliv. 3.2 Infrastrukturní ENUM Veřejný infrastrukturní ENUM [6] by měl být prostředím, kam vkládají své záznamy naopak operátoři. Existují nástiny dvou možností. Prvním je definovat vlastní strom, který bude zcela oddělený od veřejného uživatelského e164.arpa [4]. Takový strom by opět podléhal regulaci ITU.T a zkušenost s tím jak dlouho trvalo než vznikl strom e164.arpa je asi tou hlavní nevýhodou tohoto postupu. Jinak totiž jde o řešení systémově čistší než takzvaný kombinovaný ENUM, který navrhuje využít strom e164.arpa pro uživatelské i operátorské záznamy. Rozlišení těchto částí by proběhlo na úrovni národních čísel, tedy vřazením rozlišujícího znaku mezi národní kód a číslo. Tento přístup pro svou funkci potřebuje poměrně zásadní modifikaci dotazovacího mechanismu, kterou je například tabulka pozice rozlišovacího znaku, protože národní kód má proměnlivou délku jeden až tři čísla. 3.3 Privátní ENUM Problémy spojené s neexistencí nebo špatnou dostupností stromu oficiálního se snaží řešit stromy privátní. V tomto případě je zcela na držiteli kořenové delegace jaká určí pravidla pro vkládání záznamů. Na jedné straně se tu setkáváme s náhradou veřejného uživatelského ENUMu, kterou se snaží být například strom e164.org. Pak tu máme strom e164.info, který se snaží o funkcionalitu operátorskou. Kromě toho je bezpočet dalších stromů. Dalším příkladem, tentokrát v akademické komunitě, je privátní strom nrenum.net ( kam se například po zrušení švýcarské delegace přesunuly záznamy švýcarských akademických institucí. V současné době tento strom plní sedm zemí a převážně akademické instituce dalších zemí se do něj dotazují. Kromě toho lze privátní ENUM využít i uvnitř distribuovaných firemních sítí nebo skupin firemních sítí. 4 Bezpečnost v ENUMu Bezpečnost je v současné době velmi žhavým tématem a je proto logické, že zasahuje i do oblasti ENUMu. V zásadě zde můžeme na bezpečnostní problematiku pohlížet ze dvou rozdílných rovin. První je oblast ochrany osobních údajů a dolování údajů a druhou oblastí je vlastní bezpečnost přenášených dat. V první oblasti je třeba vycházet z toho, že uživatel je ten, kdo řídí zveřejňování údajů v uživatelském ENUMu. Pokud si tedy nepřeje nějaký údaj zveřejnit, tak ho do ENUMu neuvede. Opodstatněnou námitkou, pro kterou bývá někdy ENUM označován jako spamerský zlatý důl je fakt, že ho lze velmi dobře prohledávat. To vychází ze samé podstaty jakým jsou záznamy ukládány a z použití telefonního čísla. Jak bylo popsáno výše ENUM má stromovou strukturu stejně jako celé DNS. Zásadní výhodou pro prohledávaní je fakt, že každá úroveň je identifikována jedinou číslicí má tedy pevnou délku a malý počet hodnot (deset). Další výhodu při prohledávaní nese možnost odřezávat větve pokud zjistíme, že nejsou delegovány. Druhou sledovanou oblastí je přenos dat. Jak zajistit jejich autenticitu? DNS je protokol jednoduchý a pro podvržení záznamů může stačit odpovědět rychleji než server, který byl dotazován. Zabránit podvržení záznamu může nasazení DNSSECu. Současný stav implementace DNSSEC, kdy je zatím podporován v několika serverech (například BIND, Unbound), ale implementace v klientských v podstatě chybí, zatím není zcela uspokojivá. Nicméně lze podniknout alespoň první krok, kdy podepsaný záznam lze ověřit v DNS serveru v domácí síti. Odstraníme tím možnost, že bude záznam pozměněn cestou, obvykle internetem. Stále tu zůstává možnost, že bude záznam pozměněn uvnitř domácí sítě. Hranici lze posunout ještě blíže dotazující aplikaci tím, že nainstalujeme validující DNS server přímo na server aplikace. Nicméně stále nám chybí ten poslední krok kdy sama aplikace má k dispozici informaci zda záznam byl validován a následně může podle toho i rozhodnout o alternativním způsobu směrování. Navíc instalovat validující DNS server na každý aplikační server může být zbytečnou zátěží pro administrátora. strana 92

5 5 Výhody a nevýhody ENUMu Teorie a praxe IP telefonie - 3. dvoudenní odborný seminář Tou asi nejzásadnější výhodou je, že údaje spravuje uživatel čísel a záznamy jsou uložené v distribuovaném systému DNS, který je dobře dostupný a zvládnutý v aplikacích. Pokud zúžíme použití na IP telefonii a představíme si situace několik ostrůvků IP telefonie, které mezi sebou chtějí komunikovat a stále ještě používají jako identifikátory telefonní čísla. Jak si budou vyměňovat informace o směrování? Jednou možností je, že si budou navzájem posílat maily se změnami druhou možností je že vlastními silami vybudují nějakou databázi na sdílení těchto údajů. U firem se nepředpokládají časté změny, ale například u poskytovatelů ano. Jak ale do klubu přibrat dalšího účastníka. Všichni by si museli nováčka přidat do svých seznamů a při každé změně nezapomenout upravit své lokální záznamy. Jednoduchou a dobře dostupnou infrastrukturou pro sdílení informací je ale právě DNS a ENUM záznamy v něm. Jednoduše jsou tak dostupné i informace o subjektech, se kterými dopředu nemusel iniciátor spojení mít žádnou vazbu. Na druhou stranu, zvláště z pohledu operátora, je pochopitelné záznamy ve veřejném uživatelském ENUMu nemusejí mít důvěryhodnost z hlediska fungování spojení. Operátor je zvyklý se svými partnery uzavírat propojovací smlouvy, které mu zajišťují definované parametry služby a především kontakty kam se může obrátit v případě problému a i uživatel od něj očekává, že hovor vždy spojí. To mu záznam obzvláště v uživatelském ENUMu neposkytne. Na druhou stranu to nijak nebrání použití privátních stromů, kde součástí politiky může být povinnost definovat servisní kontakty popřípadě použití certifikátu pro TLS od dané certifikační autority. Existence více stromu však použití služby komplikuje. Jednak se ztrácí ona idea jednoduchosti, kdy se aplikace obrátí s dotazem na jedno místo a pokud záznam existuje použiji ho. Pro některé operátory může být i problémem, že nemohou definovat odpověď v závislosti na dotazujícím. Je však otázkou, zda je něco takového třeba. Možná celkový odklon od sytému jakým funguje klasická telefonie a přesun k filozofii fungování služeb v internetu by takovou potřebu zrušil. Záměrně neuvádím jako výhodu telefonování zadarmo. ENUM to tiž nic o telefonování zadarmo neříká. ENUM sám ani o telefonii nic neví. Slouží jen jako distribuované úložiště a o tom jak bude naloženo s výsledky získanými na základě transformačních pravidel rozhoduje dotazující aplikace. O tom zda bude hovor zpoplatněn či ne rozhoduje dohoda mezi poskytovatelem a jeho zákazníkem, potažmo mezi příjemce a iniciátorem hovoru. Nevšiml jsem si sice, že by někdo hovory vedené prostřednictvím ENUMu zpoplatňoval, ale uživatel se především ani nemusí dovědět, zda pro směrování hovoru byl či nebyl ENUM použit. 6 ENUM v ČR a ve světě ENUM se sice dostal do povědomí poskytovatelů i uživatelů, ale jeho rozšíření stále není dostatečné především pokud mluvíme o veřejném uživatelském ENUMu. Operátoři, i ti kteří jsou poskytovateli IP telefonie, stále váhají. V některých případech jsou také vedeni svou ekonomickou rozvahou, protože jejich stávající vybavení ENUM nepodporuje. Zde můžeme doufat v jediné a to že pod tlakem svých uživatelů se rozhodnout zařízení modernizovat. Nepředpokládám, že by se dostatečným podnětem byl zájem pouze o ENUM, ale dohromady s požadavky na bezpečnou komunikaci a rozšířené služby jako je prezence, krátké textové zprávy, sdílení obsahu (pracovní plochy a aplikací) a video už by mohl přesvědčit poskytovatele povýšení či výměně svých zařízení. V takovém případě se dá předpokládat, že nový sytém bude podporovat i ENUM. Stav delegací národních kódů (jakýchsi domén první úrovně) je možné najít na stránce Je patrné, že v operačním stavu je jich poměrně málo, což bohužel odráží největší bolest ENUMu a tou je právě pomalý rozjezd. Co je však zajímavé, je fakt, že Česká republika a všichni naši sousedé kromě Slovenska mají ENUM v provozním stavu. Dále mají tento status i Holandsko, Finsko, Irsko a Rumunsko. Ve Velké Británii byl v trial fázi zvolen zajímavý postup, kdy v rámci stimulace používání jsou automaticky záznamy vyplňovány a namířeny na operátora, jedná se o takzvaný CRUE (Carrier Registration in User Enum). Samozřejmě pokud oprávněný uživatel zažádá o registraci, tak má přednost. Velmi potěšující informací je fakt, že sdružení CZ.NIC, jako držitel delegace české ENUM zóny, byl vůbec prvním ze správců národních domén, který zajistil podepsání národní zóny a úpravu delegace tak, aby odrážela fakt podpory DNSSEC. Jako druhé dospělo do tohoto stádia Polsko, opět jeden z našich sousedů. To lze považovat za jasný signál pro uživatele aby technologii začali podporovat a/nebo vyžadovat od svých poskytovatelů. Kromě toho CZ.NIC spustil i program podpory softwarových projektů, kde jedním z témat je zlepšení podpory DNSSEC směrem ke koncovým aplikacím. Přesto však cesta rozhodně nebude jednoduchá, protože bude třeba upravit přímo aplikační kód. Podpora DNSSECu se netýká jen ENUM zóny ale i.cz a je možné si všimnout už proklamované podpory u prvních registrátoru a poskytovatelů DNS služeb. strana 93

6 Ne všechny správy jsou však pozitivní. Jak bylo napsáno výše delegace veřejného uživatelského ENUMu může mít i politickou rovinu. Po ztroskotaní jednání je téměř jasné, že k delegaci kódu +1 (NANP) rozhodně v brzké době nedojde. Bohužel jsou již jsou známy i dva případy kdy došlo ke zrušení delegace (Švýcarsko a Austrálie) přestože v případě Švýcarska vypadala situace velmi slibně. Celkově je však problémem nízký objem záznamů, tedy pokrytých čísel. Situaci ilustruje prohledávací systém, který provozuje držitel rakouské ENUM zóny. Aplikaci naleznete na adrese a je z ní patrné, že Česká republika je momentálně devátém místě s více jak patnácti sty záznamy. Toto číslo však může být zavádějící, protože hvězdičkové záznamy jsou počítány jako jeden přesto, že mohou pokrývat i například deset tisíc čísel. Na druhou stranu započítat celých deset tisíc také nemusí odrážet reálně dostupná čísla, protože nemusí být přidělena koncovým zařízením-uživatelům. 7 Postřehy a praktické zkušenosti Sdružení CESNET se zapojilo již do testovacího provozu, kdy dopomohlo svým členům zapojeným do projektu IP telefonie zaregistrovat ENUM domény přímo u CZ.NICu. Jednalo se o několik desítek domén, z nichž většina pokrývala sto a více čísel. Jedním z našich záměrů bylo stimulovat zájem i ostatních subjektů o tuto technologii. Doufali jsme, že pokud se objeví v českém ENUMu deseti tisíce čísel akademických institucí, které se takto stanou lépe dostupné pomocí IP telefonie, bude to dostatečný podnět pro další instituce a uživatele. Následně při přechodu do ostrého provozu si své domény členové přenesly k registrátorům. Proces to nebyl jednoduchý a bohužel stále nejsou všechny záznamy v takovém pořádku, jak bychom si přáli. Do jisté míry je pro nás politika veřejného uživatelského ENUMu svazující, protože nám neumožňuje se o domény školám postarat i kdybychom chtěli. Nemyslím provozní stránku věci, protože stále hostujeme ENUM domény většiny členů na jmenných serverech CESNETu, ale jde o administrativní otázku především validací. Právě fakt, že je třeba každého půl roku třeba validaci obnovit je poněkud omezující i když pro ty, jenž znají pravidla a fungování systému ENUM pochopitelný. Mnozí však zřejmě stále nechápu ten rozdíl proti klasickým doménám, tedy že se tu objevuje další periodický termín kromě registrace (validace), který je třeba hlídat a reagovat na něj složitěji než jen platbou. Myslím, že by věci mohla pomoci elektronická forma validace, která by na uživatele kladla minimální nároky. U jednotlivých čísel je například získání validační SMS poměrně jednoduchý proces, ale v případě bloků čísel, kdy je třeba zasílat faktury, může jít o zbytečnou zátěž. Zaměřímeli se čistě na technické řešení, bylo by jistě příjemné, aby uživatel nemusel do procesu téměř zasáhnout. Registrátor, který zná identitu uživatele (ať již jde o společnost nebo jednotlivce) provede dotaz do centrální databáze přidělených (a i přenesených) čísel, podle které bude kontaktován odpovědný operátor a ten by následně potvrdil-validoval požadavek automatizovanou cestou. Je však pochopitelné, že sami operátoři nemají velký zájem na fungování takové aplikace, protože by bylo třeba i na jejich straně implementace a přitom by nepřinášela pravděpodobně výdělek. Nemají zatím zájem ani na fungování samotného ENUMu, protože by mohl znamenat úbytek jejich výdělku z hovorného. I zde si však dovolím malou poznámku, doufám, že i když třeba pomalu, tak postupně zmizí minutové hovorné a zůstane pouze paušální poplatek stejně tak jako je tomu stalo u samotného připojení k internetu. Nakonec totiž bude telefonie kompletně jen další službou na internetu. To, co momentálně platíme, jsou především minuty do klasických telefonních sítí. Vrátím se ale ještě ke stavu ENUMu v ČR. Pozitivní je přístup některých registrátorů, kteří zatím poskytují registraci a validaci bezplatně. Na druhou stranu například cena pěti set korun za validaci domény pomocí dokumentu, tedy tisíc korun ročně, je poměrně nepříjemná. Otázkou je tedy na jaké ceně registrace a validace se ENUM vzhledem k uživateli ustálí. Zatímco minimální cena registrace může být dána poplatkem CZ.NICu, tak v případě validace jde přímo o kalkulaci registrátora. Zároveň je třeba si uvědomit, že běžný uživatel bude velmi rozvažovat potřebu si číslo registrovat v momentě i kdyby jej to ročně mělo stát jen sto korun. Na první pohled jemu samotnému jeho záznam mnoho nepřinese. Trochu jiná je snad situace u podniků a úřadů, které budou chtít tímto vyjít vstříc svým zákazníkům, partnerů a občanům. Ti si také obvykle registrují celý rozsah čísel. Pravděpodobně i oni ale zváží zda registrovat i několik desítek firemních mobilních telefonů, jejichž čísla nejsou v řadě za sebou a každé je tedy samostatnou doménou. Na samotném sytému ENUMu v České republice oceňujeme především velmi aktivní přístup CZ.NICu, který implementoval vlastní registrační systém (nejen pro ENUM). V rámci něho také funguje zasílání oznámení o vypršení validace a registrace doručované přímo koncovým uživatelům registrujícím domény. Registrátoři zatím tento systém sami, pokud vím, nemají. CZ.NIC vylepšil i svůj whois systém pro ENUM ( který poskytuje dodatečné informace specifické pro ENUM, především o datu validace. Nově je v systému i informace o stavu zabezpečení konkrétní domény pomocí DNSSECu. Sami se v nejbližší době chystáme minimálně zóny patřící přímo CESNETu podepsat, tak jako je tomu u zóny cesnet.cz. strana 94

7 V řídících prvcích IP telefonní infrastruktury využíváme dotazů nejen do stromu e164.arpa, ale také do privátního stromu nrenum.net. Kromě toho jsem si zřídili vlastní privátní ENUM strom. Do tohoto stromu jsou vloženy seznamy čísel, která nám poskytli VoIP operátoři. V jistém smyslu tento strom simuluje infrastrukturní ENUM. S největší pravděpodobností by však pokud by to byl infrastrukturní ENUM ve svém plném významu, tak bychom do něj neměli přístup, protože sdružení není operátorem. Tato zóna však může fungovat minimálně jako jednoduchý zdroj směrovacích dat pro další řídící prvky v síti sdružení bez nutnosti distribuovat informace až přímo k řídícímu prvku manuálně. Rádi bychom navázali v tomto směru i spolupráci s VoIP operátory, ale se zájmem jsem se zatím nesetkali. Zásadní nevýhodou této privátní zóny je fakt, že informace do něj vkládáme my za jiné subjekty. To znamená, že hlavní výhoda ENUMu, kterou je správa záznamů vlastníkem je nevyužita. Statistiku o tom, kolik hovorů pro spojení využije dotazu do ENUMu, si nevedeme. Co se týče konfigurace řídících prvků je vhodné počítat se záložní cestou v případě, že hovor není možné sestavit směrem primárním. Za záložní cestu je možné považovat například připojení k poskytovateli (přes IP nebo ISDN) Samotný ENUM nemusí být na vině, ale výhodou může být možnost v rámci IP telefonní aplikace nastavit specifický timeout pro DNS dotazy nižší než obvyklý třicet vteřin. Také je pozoruhodné chování některých uživatelů kteří při použití IP telefonie nejsou schopni čekat několik vteřin než dostanou vyzváněcí tón a přitom při použitím mobilního telefonu se jistě setkali s velmi dlouhými prodlevami. Literatura [1] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May Dostupné z: [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One to Four, RFC Dostupné z: < [3] Faltstrom, P. and M. Mealling, The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM), RFC 3761, April Dostupné z: < [4] J. Rudinský, Telefonní sítě a VoIP sblíží I-ENUM, Stránky serveru Lupa [online, cit ]. Dostupné z: < [5] J.Peterka: Co je ENUM?, Stránky serveru Lupa [online, cit ]. Dostupné z: < [6] P.Satrapa: ENUM pro operátory, Stránky serveru Lupa [online, cit ]. Dostupné z: < strana 95

8 strana 96