Správa domény nejvyšší úrovně.cz Jan Kryl

Rozměr: px
Začít zobrazení ze stránky:

Download "Správa domény nejvyšší úrovně.cz Jan Kryl"

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická ČVUT FEL katedra počítačů Diplomová práce Správa domény nejvyšší úrovně.cz Jan Kryl Vedoucí práce: Jan Kubr Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpočetní technika Leden 2007

2

3 Poděkování Děkuji rodičům za všestrannou podporu po dobu mého studia.

4

5 Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6

7 Abstrakt Tento dokument vychází z roční práce autora na tvorbě registračního systému internetových domén pro sdružení CZ.NIC. Za jeden rok se systém podařilo vybudovat a úspěšně nasadit do provozu. Ovšem nejedná se pouze o dokumentaci k technickému řešení projektu. Práce si klade za cíl seznámit čtenáře s novým internetovým protokolem EPP (Extensible Provisioning Protocol), jehož implementace je součástí řešení, a ENUM (Telephone Number Mapping) standardem. Projekt je tím zajímavější, že je uvolněn pod svobodnou licencí a očekává se jeho rozšíření po světě. Abstract This paper is based on author s experience with implementation of an internet domain registry. The project took one year and was realized on behalf of CZ.NIC association. At the end the system was successfully applied and operates flawlessly. This paper is more than just documentation of technical solution of the project. It aims to provide information on recent internet protocol EPP (Extensible Provisioning Protocol), which was implemented as part of the project, and ENUM (Telephone Number Mapping) standard. The system was released under free licence, which makes it even more appealing, and is expected to be adopted in various parts of the world.

8 10

9 Obsah 1 Úvod Registr domén: definice a účel Registr české národní domény CZ.NIC Motivace a požadavky na nový registr 19 3 EPP EPP objekty Model transferu Nasazení EPP v praxi ENUM Přizpůsobení registru pro správu ENUM domén ENUM doma a ve světě Architektura systému fred_rif, fred_pif a fred_admin fred_rif fred_pif fred_adif pyfred genzone filemanager mailer techcheck mod_eppd a mod_whoisd mod_whoisd mod_eppd epp_client Závěr Vymezení práce autora Možná budoucí vylepšení

10 12 OBSAH A Výběr databáze 61 B CORBA 63 C O tomto dokumentu 65 D CD přílohy 67 E Bibliografie 69

11 Seznam tabulek 4.1 Stav ENUM registrací dle států Výčet technických testů a jejich úrovní A.1 Databáze používané v ostatních registrech A.2 Výsledky testu rychlosti databáze ORACLE a PostgreSQL

12 14 SEZNAM TABULEK

13 Kapitola 1 Úvod V této kapitole se lehce seznámíme s prostředím registru doménových jmen a jeho úlohou v systému doménových jmen (DNS). Po získání těchto základních vědomostí krátce představíme registr české národní domény CZ.NIC, na jehož půdě je projekt vyvíjen. Poté představíme základní body motivace k vytvoření nového registračního systému doménových jmen. Před částí popisující implementaci systému, jsou dvě spíše teoretické části, které popisují Extensible Provisioning Protocol (EPP) a Telephone Number Mapping (ENUM). EPP a ENUM jsou totiž dva standardy, které ovlivnily implementaci registru nejvíce. EPP byl základním stavebním kamenem implementace a na základě analýzy tohoto protokolu se pak začal navrhovat datový model registru. Dílčí zamyšlení a zhodnocení částí implementace je obsaženo v jednotlivých kapitolách, přesto v závěru je zhodnocení implementace jako celku a neméně zajímavý je pohled do budoucna, co se týká registračního systému. 1.1 Registr domén: definice a účel Registr domén, v angličtině často nazýván jako Network Information Center, je součástí systému doménových jmen. Jeho úkolem je převádět doménová jména na IP adresy. Je představován organizací, která může být komerčního nebo neziskového charakteru. Domény se dělí do dvou základních skupin: generické domény a národní domény. Za přidělování domén do něčí správy zodpovídá IANA (Internet Assigned Numbers Authority), která je zároveň správcem root nameserverů, což je vrchol v hierarchii doménových jmen. Dále je IANA správcem.arpa domény, která slouží k administračním účelům (např. překlad IP adres na doménová jména, tzv. reverse-mapping). Domény se registrují za poplatek, jehož výše je odvislá od společnosti, která doménu spravuje a jiných okolností. Domény jsou registrovány v pořadí, v kterém přicházejí požadavky na jejich registraci, i když existují i vyjímky z tohoto pravidla. Rozlišujeme dva základní modely registru: Úzkovrstvý model. Širokovrstvý model. 15

14 16 KAPITOLA 1. ÚVOD Znázornění rozdílu mezi širokovrstvým (nalevo) a tenkovrstvým (napravo) modelem registru. Zatímco u širokovrstvého modelu vrací whoisový dotaz plnou informaci o doméně, u tenkovrstvého vrací základní údaje a odkaz na registrátora. Až dotaz do databáze registrátora vrací plnou informaci o doméně. V úzkovrstvém modelu je snaha co nejvíce poviností delegovat na tzv. registrátory, což jsou společnosti, které poskytují registrace domén koncovým uživatelům. Na druhé straně tyto zprostředkovatelské společnosti platí poplatky, které jsou pochopitelně menší než koncové ceny, registru domén. Tím dochází k distribuci dat o zákaznících mezi registrem a registrátory. V nejkrajnějším případě v tomto modelu si registr potřebuje udržovat pouze u jaké společnosti a na jak dlouho byla doména registrována a zbytek dat je schopen poskytnout registrátor. Například doména.com je spravována tímto způsobem. V širokovrstvém modelu si registr udržuje všechna data ve své centrální databázi a nespoléhá na databáze registrátorů. V nejkrajnějším případě spojuje roli registru a registrátora, či-li přímo umožňuje registrovat domény koncovým zákazníkům bez zprostředkovatelů, nicméně je to většinou pouze alternativní nabídka vzhledem k ostatním registrátorům a nebývá příliš výhodná. Německá národní doména spravovaná sdružením DENIC je příkladem takového registru. Česká doména donedávna také plnila funkci registrátora, to se ale s novým systémem mění. Některé registry povolují národní znaky v názvech domén, například polská národní doména. Většina registrů je v tomto směru konzervativní a národní znaky nepovoluje. Odbornou veřejností jsou národní znaky zavrhovány. V RFC 2825 jsou shrnuty důvody, kvůli kterým je dobré se národním znakům vyhnout. Dalším možným kritériem pro klasifikaci registrů je, zda-li vynucují dvouúrovňové domény či nikoliv. Povinná doména na druhé úrovni pomáhá vyrovnat se lépe se sploštěním prostoru doménových jmen. Při návrhu systému doménových jmen se nepočítalo s jeho masovým použitím způsobem jakým se dnes používá. Počítalo se, že doménový strom bude mít tvar pyramidy, čímž dojde k distribuci administrativní a výkonové zátěže. V praxi je úroveň pod nejvyšší doménou zoufale přehuštěná a úrovně za druhou úrovní domén jsou nevyužívané. Registry, které vynucují použití domén na třetí úrovni, se snaží čelit této nepříjemné situaci, nicméně jsou v menšině. Příkladem je britská národní doména.

15 1.2. REGISTR ČESKÉ NÁRODNÍ DOMÉNY CZ.NIC 17 Znázornění rozdílu mezi ideálním stavem rozložení doménových jmen (nalevo) a rozložením, ke kterému dochází v praxi, kdy úroveň hned pod nejvyšší doménou je přehuštěna na úkor dalších úrovní (napravo). O problematice přetěžování úrovní v DNS a obecně "zneužívání" systému DNS k účelům, ke kterým nebyl určen, velmi zajímavě pojednává RFC Pro přehlednost je zde uveden výklad pojmů, které se v textu hojně používají a jejichž význam se může snadno zaměnit. Registr Je organizace zodpovědná za správu domény. V užším slova smyslu to může znamenat softwarové a hardwarové vybavení, které správu domén zajišt uje, nebo popřípadě jen databázi, kde jsou data, nutná pro správu, uložena. Registrátor Registrátor je společnost, která zajišt uje prodej domény koncovému zákazníkovi. Je to prostředník mezi registrem a registrantem. Registrant Registrant je koncový zákazník, který si doménu kupuje (nebo přesněji řečeno pronajímá na určité období). 1.2 Registr české národní domény CZ.NIC Sdružení CZ.NIC bylo založeno v roce 1998 skupinou šestnácti poskytovatelů internetu. Jedná se o neziskovou organizaci, která je otevřena novým registrátorům. Je členem uskupení CENTR (skupina evropských registrů národních domén), ve spolku s EU- Ridem (registr pro.eu domény) a součástí kritické infrastruktury českého státu. Systém organizace, druhy členství a pravomoce jednotlivých orgánů jsou poměrně komplikované a jejich popis není cílem této práce. V současnosti CZ.NIC spravuje přes 250 tisíc domén s meziročním nárůstem 50 tisíc domén za poslední rok. V roce 2004 zárověň s výměnou vedení společnosti byly nastartovány zásadní reformy dosavadního fungování registru, který byl po technické stránce kompletně outsourcován. Nové vedení si vytyčilo ambiciózní cíle mezi kterými jsou: snížení koncové ceny domény, spuštění registace ENUM čísel a převedení outsourcovaného CZ registru pod správu CZ.NICu. Z uvedených cílů vyplývá, že klíčovým úkolem je vývoj nového registru pro správu domén. Pokud bychom měli klasifikovat registr české národní domény dle dvou hledisek uvedených v předchozí podkapitole, došli bychom k následujícím závěrům: Registr je širokovrstvý. Všechny informace o doméně jsou uloženy v registru. Whois dotaz je schopen podat plnou informaci o doméně. Nicméně role registrátorů jako prostředníka mezi registrem a registrantem je zachována. Všechny domény jsou v novém systému registrovány výhradně přes registrátory - to je změna vzhledem k předchozímu fungování registru. Registr nevynucuje klasifikaci domén na základě domény na druhé úrovni. To znamená, že registrovány mohou být jakékoliv domény hned pod nejvyšší doménou.cz. Registr nepodporuje národní znaky v názvech domén.

16 18 KAPITOLA 1. ÚVOD Poznámka Čtenář by mohl mít oprávněnou námitku, že se v této práci vůbec nezabýváme původním systémem pro správu.cz domén. Jistě by to byl hodnotný zdroj zkušeností, které by pomohly při implementaci nového registru. Bohužel o původním systému pro správu domén víme velmi málo, což má dva důvody: Původní řešení, které je šité na zakázku pro českou doménu, má uzavřené zdrojové kódy a veřejně dostupná dokumentace není žádná. Neochota společnosti, která za řešením stojí a provozuje ho, sdílet jakékoliv informace o něm. Dosluhující decentralizovaný systém správy domén je v provozu teprve od září roku Slovo decentralizovaný znamená, že správa je rozdělena mezi registr a registrátory tak, jak jsme si tento model popsali v minulé podkapitole. Komunikace s registrátory probíhala přes "protokol EPP", zde jsou uvozovky na místě, protože z formálního hlediska se nejedná o tento protokol, ale něco, co je mu jen velmi podobné. Další zvláštností je, že transportní vrstvou je protokol SMTP zabezpečený TLS, ovšem pro informační příkazy se používá HTTPS. Používání dvou transportních vrstev a protokol navržený ne v souladu se standardem EPP (v té době ještě draftem) nejsou dobrou vizitkou pro tento systém.

17 Kapitola 2 Motivace a požadavky na nový registr Motivace pro vybudování nového centrálního registru vyplývá z předchozí kapitoly pojednávající o společnosti CZ.NIC. V této kapitole si je doplníme o další specifičtější požadavky. Tak získáme hrubou představu o podobě nového registru. Open-source projekt Kód registru bude uvolněn pod svobodnou licencí (pravděpodobně GPL). Očekává se velký zájem zejména ze strany zemí třetího světa, které tak mohou dostat do ruky hotové řešení, mohou vyškolit své pracovníky pro ovládání registru a přizpůsobovat ho volně svým potřebám. Otevřenost zdrojového kódu zvyšuje nároky na jeho bezpečnost a kvalitu. V době započetí projektu se jednalo o vůbec první kompletní open-source řešení tohoto druhu. Uvolnění pod svobodnou, "infekční licencí", jak je někdy GPL nazývána, implikuje požadavek na použité knihovny, které musí být taktéž svobodné. Nezávislost na lokalitě nasazení Řešení musí obsahovat minimum věcí specifických pro české podmínky. Ideálně přenesení registru do jiné země, by mělo znamenat jen změnu konfigurace, nikoliv úseků zdrojového kódu. Možnost správy více zón Registr musí být schopen spravovat libovolné množství zón. Jen v současných podmínkách v CZ.NICu musí být schopen spravovat jak zónu.cz tak ENUM zóny, o kterých bude řeč ještě později. Přidání další zóny do správy by mělo být otázkou nastavení konfigurace, bez nutnosti měnit zdrojový kód. Distribuované řešení Idea registru je, že se bude sestávat z více oddělených částí, které spolu budou komunikovat přes dobře definované rozhraní. Jednotlivé části budou moci běžet na různých strojích. Tento návrh zajistí lepší předpoklady pro zvládnutí složitosti problému a zároveň rozložení zátěže. Výkon Nový registr musí být schopen registrovat domény takovou rychlostí, aby stačil na provoz nejvytíženějších domén současnosti. Podpora pro EPP protokol Řešení by mělo vyhovovat požadavkům EPP protokolu. EPP je relativně nový protokol určený pro komunikaci mezi registrem a registrátory. Ještě se k němu vrátíme podrobně později. V podstatě díky tomu, že je registr stavěn na zelené louce, je možné celý registr navrhnout "kolem" EPP protokolu. Zjednodušení současného málo přehledného modelu Ve starém systému existuje celkem devět kombinací druhu kontaktu a jeho role. Systém je takřka nepochopitelný pro koncového zákazníka. Registrátor ho od této složitosti částečně odstiňuje, ale to není možné zcela. Nový model by měl být průhlednější, snáze pochopitelnější, což přispěje jednak k omezení počtu nedorozumění s koncovým zákazníkem a jednak ke zjednodušení datového modelu. Omezený čas na vývoj nového registru Časový harmonogram byl pevně stanovený ve chvíli započetí projektu. Při vývoji se musí brát ohled na tyto termíny a přizpůsobit tomu rozhodnutí při návrhu a implementaci. 19

18 20 KAPITOLA 2. MOTIVACE A POŽADAVKY NA NOVÝ REGISTR

19 Kapitola 3 EPP EPP (Extensible Provisioning Protocol) je internetový standard definovaný v RFC 3730 z roku Popisuje aplikační úroveň klient-server protokolu pro vytváření a správu objektů ve sdíleném centrálním repozitáři. Protokol je založen na XML a využívá XML namespaců, díky čemuž je snadno rozšiřitelný. Ač byl vytvořen za účelem unifikace rozhraní pro komunikaci registru a registrátorů, mohou jím být spravovány jakékoliv objekty a nejen objekty specifické pro prostředí registru doménových jmen. EPP definuje dva druhy operací. Příkazy, které se přímo netýkají správy objektů: hello Tento příkaz může klient zadat kdykoliv a server na něj musí odpovědět takzvaným greeting rámcem. login Přihlášení uživatele do systému. logout Odhlášení uživatele ze systému. poll Manipulace s došlými zprávami. Tento příkaz má dvě varianty. Jedna varianta získá první zařazenou zprávu od serveru a druhá varianta potvrzuje příjem zprávy a vyřazuje přečtenou zprávu z fronty na straně serveru. Zařazení tohoto příkazu mezi operace, které se přímo netýkají objektu je diskutabilní, protože obsah zprávy se objektu týkat může. Druhou skupinou operací jsou příkazy, které se přímo týkají objektů. check Zjištění registrovatelnosti objektu na základě jeho jména. Jedná se o jediný EPP příkaz, kde se pracuje s více objekty najednou. Pro každý dotazovaný objekt server vrací stav: může být zaregistrován nebo nemůže být zaregistrován. Pokud nemůže, vrací server ještě důvod, proč nemůže být zaregistrován. Tímto příkazem si může například klient před registrací doménového jména zjistit, zda-li je doménové jméno už registrováno nebo je volné. info Výpis informací o objektu. Každý objekt má nějaké vlastnosti (atributy), jinak by nemělo smysl ho spravovat. Například u domény to může být doménové jméno, datum založení a vlastník domény. Příkaz info vrací dostupné informace o objektu. Některé citlivé informace mohou být skryty v případě, že klient, který se ptá nemá dostatečná práva. create Vytvoření objektu. Na příkladu domény je to zaregistrování doménového jména. delete Vymazání objektu. Na příkladu domény je to zrušení registrace doménového jména. renew Prodloužení platnosti objektu. Používá se pouze u objektu domény a slouží k prodloužení platnosti doménového jména na další období. transfer Změna vlastníka objektu. Každý objekt má vlastníka, který se může měnit v průběhu existence objektu v registru. Vlastníkem zde myslíme registrátora, přes kterého je doména registrována, nikoliv držitele domény. update Změna vlastností (atributů) objektu. Ne každý atribut lze změnit přes update. Například vlastník resp. datum expirace jsou měněny přes transfer resp. renew příkazy. 21

20 22 KAPITOLA 3. EPP Než budeme pokračovat v popisu EPP, je vhodné vysvětlit, jaký je vztah EPP standardu a XML. Řekli jsme, že EPP je protokol založený na XML. To znamená, že vyměňované zprávy mezi klientem a serverem jsou XML dokumenty. To si ukážeme na příkladu nejjednodušího EPP příkazu logout. Nejdříve klient pošle příkaz serveru. <?xml version="1.0" encoding="utf-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> <command> <logout/> <cltrid>abc-12345</cltrid> </command> </epp> Jako první je klasická hlavička XML dokumentu, určující jeho verzi a kódování. Atribut standalone říká, jestli (ne)existuje externí definice XML dokumentu, v našem případě je XML dokument definován XML schématem, což je externí definice, čili hodnota no je správná. Pak následuje element epp. To je kořenový element všech dokumentů EPP. Pomocí atributů tohoto elementu je definován defaultní namespace EPP, který se vztahuje na všechny potomky kořenového elementu, pokud nemají explicitně uveden jiný namespace. Potomkem epp je element command, který určuje, že se jedná o příkaz. O jaký příkaz se jedná určuje hned následující element logout, který je doplněn o element cltrid, o kterém se zmíníme ještě později. Po zpracování příkazu serverem, je vrácen klientovi jiný XML dokument (odpověd ). <?xml version="1.0" encoding="utf-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> <response> <result code="1500"> <msg>command completed successfully; ending session</msg> </result> <trid> <cltrid>abc-12345</cltrid> <svtrid>54321-xyz</svtrid> </trid> </response> </epp> Odpověd se liší od příkazu až u elementu response, který říká, že se jedná o odpověd serveru. Tento element má potomky result, který obsahuje lidsky čitelnou zprávu od serveru a návratový kód příkazu Definice významu návratových kódů je součástí EPP standardu. Odpověd obsahuje ještě identifikátory akce cltrid a svtrid. To co jsme na předchozím příkladu popsali slovy o pořadí elementů a jejich obsahu, je popsáno přesně XML schématy. XML schémata popisují strukturu dokumentu a datové typy elementů a atributů. Samozřejmě XML schémata popisují formální stránku XML jazyka (dokumentu). To co nepopisují schémata je sémantika, nebo-li význam jednotlivých elementů a atributů. Popsat jejich význam je předmětem textu EPP standardu. Poznámka XML schémata nejsou jediným jazykem pro popis struktury XML dokumentu. Jeho předchůdcem je DTD (Document Type Definition), který se liší od schémat hlavně tím, že k popisu struktury dokumentu používá jiný jazyk než XML. Druhá závažnější nevýhoda je, že nepodporuje XML namespace, tudíž pro účely definice EPP je nepoužitelný. XML schéma není jediný moderní jazyk pro popis struktury XML dokumentů, zdatně mu konkuruje RELAX-NG, jehož popularita v poslední době roste a který by mohl být použit pro popis EPP stejně tak dobře jako XML schémata.

21 23 Jako objekt může v systému vystupovat cokoliv. Mapování operací definovaných standardem EPP na konktrétní objekty, je předmětem samostatných specifikací. Standard nevyžaduje, aby existovala mapovaní pro všechny jím definované operace, ale pouze pro operace, které pro daný objekt mají smysl. Než budeme pokračovat v základní charakteristice EPP, vyjasníme si základní pojem používaný při výkladu a to je rámec. Je to základní jednotka EPP komunikace. Označuje XML dokument, který reprezentuje příkaz klienta nebo odpověd serveru. EPP je challenge-response protokol, či-li příkaz od klienta je vždy následován odpovědí od serveru. Server nikdy nic klientovi neposílá, pokud to není přímou odpovědí na příkaz od klienta. Vyjímku předchozímu pravidlu tvoří úvodní rámec nově navázaného spojení, kdy server odpovídá greeting rámcem bez toho, že by klient posílal jakýkoliv rámec před tím. Greeting rámec slouží ke zprostředkování informací o serveru jako takovém (číslo verze EPP protokolu, podporované jazyky komunikace, spravované typy objektů atd.). Klient poté vyšle login rámec, který obsahuje uživatelské jméno, heslo a preference uživatele. Tím končí úvodní fáze komunikace a následují různé příkazy, dle výběru uživatele. Komunikace se ukončuje příkazem logout ze strany klienta. Server odpovídá potvrzením o úspěšném zpracování příkazu a tcp spojení je uzavřeno oběma ze stran. Znázornění typického scénáře komunikace mezi klientem a serverem přes EPP/TCP. Toto je zjednodušený model komunikace tak, jak je popsán v RFC 3730 a RFC 3734, které popisuje mapování EPP protokolu na TCP protokol. EPP protokol není totiž svázán s žádným sít ovým protokolem, a tak mapování EPP na různé sít ové protokoly je předmětem samostatných standardů. V současnosti má praktický význam pouze TCP protokol jako nosný protokol EPP. EPP standard je však konkrétní v tom, jaké požadavky musí splňovat jakékoliv mapovaní na sít ový protokol. Kromě předvídatelných požadavků jako je doručování dat v pořadí, ve kterém jsou posílány, zaručená spolehlivost doručení dat, klade standard požadavky na integritu a důvěryhodnost posílaných dat. To v mapování na TCP zaručuje mezivrstva TLS (Transport Layer Security). EPP příkazy jsou navržené tak, aby byly idempotentní, což znamená, že opakované vyvolání stejného příkazu několikrát za sebou, nezmění stav objektu v repozitáři, to je důležitá vlastnost.

22 24 KAPITOLA 3. EPP Již jsme zmínili, že EPP je XML protokol. V RFC 3734 (mapování EPP na TCP) je stanoveno, že každý rámec předchází takzvaná hlavička, která má velikost čtyři bajty a je v ní uložena délka XML dokumentu, který následuje. Tak příjemce rámce ví přesně kolik bajtů má přečíst ze sít ového socketu, aniž by musel jakkoliv parsovat XML dokument. Struktura XML dokumentů je definována pomocí dvou XML schémat. Namespace urn:ietf:params:xml:ns:epp-1.0 je definován základním schématem EPP. Druhé schéma vedlejšího významu definuje namespace urn:ietf:params:xml:ns:eppcom-1.0 a jedná se o definici několika používaných jednoduchých datových typů, u kterých se předpokládá, že budou sdíleny se schématy, které EPP protokol rozšiřují. Jakékoliv úpravy EPP, které by znamenaly změnu těchto dvou schémat, nejsou kompatibilní a protokol, na nich postavený, nesmí být názvem EPP označován. Přesný popis struktury XML dokumentů a význam informací v nich obsažených je předmětem EPP standardu, nicméně pro představu uvádíme výsek z EPP komunikace mezi klientem a serverem. Data zasílaná klientem jsou prefixovaná znaky C:, data zasílaná serverem znaky S:. Výpis neobsahuje hlavičky rámců s jejich délkou. Zde uvedená komunikace se skládá ze čtyř rámců - příkazů login, logout a příslušných odpovědí na ně a jsou převzaté z RFC C:<?xml version="1.0" encoding="utf-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" C: xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <login> C: <clid>clientx</clid> C: <pw>foo-bar2</pw> C: <newpw>bar-foo2</newpw> C: <options> C: <version>1.0</version> C: <lang>en</lang> C: </options> C: <svcs> C: <objuri>urn:ietf:params:xml:ns:obj1</objuri> C: <objuri>urn:ietf:params:xml:ns:obj2</objuri> C: <objuri>urn:ietf:params:xml:ns:obj3</objuri> C: <svcextension> C: <exturi>http://custom/obj1ext-1.0</exturi> C: </svcextension> C: </svcs> C: </login> C: <cltrid>abc-12345</cltrid> C: </command> C:</epp> S:<?xml version="1.0" encoding="utf-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" S: xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>command completed successfully</msg> S: </result> S: <trid> S: <cltrid>abc-12345</cltrid> S: <svtrid>54321-xyz</svtrid> S: </trid> S: </response> S:</epp> C:<?xml version="1.0" encoding="utf-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" C: xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0

23 25 C: epp-1.0.xsd"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemalocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: </domain:info> C: </info> C: <cltrid>abc-12345</cltrid> C: </command> C:</epp> S:<?xml version="1.0" encoding="utf-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" S: xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>command completed successfully</msg> S: </result> S: <resdata> S: <domain:infdata S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemalocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:roid>example1-rep</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostobj>ns1.example.com</domain:hostobj> S: <domain:hostobj>ns1.example.net</domain:hostobj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clid>clientx</domain:clid> S: <domain:crid>clienty</domain:crid> S: <domain:crdate> t22:00:00.0z</domain:crdate> S: <domain:upid>clientx</domain:upid> S: <domain:update> t09:00:00.0z</domain:update> S: <domain:exdate> t22:00:00.0z</domain:exdate> S: <domain:trdate> t09:00:00.0z</domain:trdate> S: <domain:authinfo> S: <domain:pw>2foobar</domain:pw> S: </domain:authinfo> S: </domain:infdata> S: </resdata> S: <trid> S: <cltrid>abc-12345</cltrid> S: <svtrid>54322-xyz</svtrid> S: </trid> S: </response> S:</epp> C:<?xml version="1.0" encoding="utf-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"

24 26 KAPITOLA 3. EPP C: xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <logout/> C: <cltrid>abc-12345</cltrid> C: </command> C:</epp> S:<?xml version="1.0" encoding="utf-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" S: xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1500"> S: <msg>command completed successfully; ending session</msg> S: </result> S: <trid> S: <cltrid>abc-12345</cltrid> S: <svtrid>54321-xyz</svtrid> S: </trid> S: </response> S:</epp> Na příkladech je pozoruhodný element cltrid a svtrid. Jedná se o identifikátory požadavků. Požadavkem máme zde na mysli rámec, který obsahuje příkaz klienta, společně s rámcem, který obsahuje odpověd serveru. cltrid je identifikátor požadavku přidělený klientem a je volitelný. Server musí tento identifikátor uvést ve své odpovědi a navíc povinně přiřadí odpovědi svůj identifikátor svtrid, který identifikuje jednoznačně požadavek v historii všech požadavků vyslaných na server od všech klientů. Zajímavá je zejména prostřední část komunikace, kde klient zadává příkaz info a ptá se jím na doménu example.com. Server v odpovědi vrací informace vedené o doméně example.com v registru. Tento úryvek komunikace je ukázkou mapování objektu do EPP, o čemž bude řeč v příští podkapitole. Elementy info a resdata mohou dle XML schémat obsahovat element z libovolného namespacu. Zde vstupuje do hry RFC 3731, které definuje mapování pro objekt doména a namespace urn:ietf:params:xml:ns:domain-1.0. Kdybychom si definovali vlastní mapování pro objekt doména, což jsme vskutku udělali, a vytvořili tak vlastní namespace například urn:namespace:ident. Vypadal by příkaz na vypsání informací o našem objektu doména následovně: <?xml version="1.0" encoding="utf-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> <command> <info> <domain:info xmlns:domain="urn:namespace:ident" xsi:schemalocation="urn:namespace:ident ident.xsd"> <!-- Co se nachazi zde za elementy je veci definice XML schemat pro namespace "urn:namespace:ident" --> </domain:info> </info> <cltrid>abc-12345</cltrid> </command> </epp> EPP, jak už z názvu vyplývá, je snadno rozšiřitelný protokol. Požadavek rozšiřitelnosti protokolu je velmi podstatný, jelikož každý registr má specifické požadavky na strukturu spravovaných objektů a na protokol obecně. Standard definuje způsoby, jakými je

25 3.1. EPP OBJEKTY 27 možné rozšířit základní EPP protokol a přizpůsobit ho tak svým potřebám bez vytváření nových navzájem nekompatibilních standardů. Podle závažnosti změn a způsobu provedení řadíme možná rozšíření do následujících kategorií: Rozšíření protokolu. Používá se pouze při nejzásadnějších zásazích do protokolu. Můžou se jím definovat nové operace nad spravovanými objekty nebo například funkce pro získavání informací o stavu kreditu přihlášeného uživatele. Rozšíření o nové objekty. Například definice mapování objektu doména (RFC 3731) do EPP je příkladem takového rozšíření. Rozšíření příkazů a odpovědí. Pohodlné rozšíření o nové vlastnosti objektu. Například doména pomocí několika dalších atributů může být rozšířena o podporu DNSSEC standardu. Při návrhu rozšíření by se mělo postupovat směrem od nejméně závažného (posledního) a o úroveň výše pokročit pouze v případě, že navrhované rozšíření vyžaduje větší změnu. Výborným příkladem rozšíření je přidání nových objektů. EPP standard nedefinuje žadné mapování EPP operací na jakékoliv objekty. Pouze obsahuje návod, jak se má při tom postupovat. Doplnění základního EPP o objekty je předmětem jiných RFC dokumentů. EPP protokol tak, jak je navržen, může být použit ke správě téměř čehokoliv, co se registruje ve sdíleném centrálním repozitáři, například SPZ značek na auta. Fred rozšiřuje EPP protokol na všech úrovních (všemi třemi uvedenými způsoby). Na protokolové úrovni zavádí dva nové příkazy. Jeden na zjištění aktuální výše kreditu registrátora a druhý na zaslání autorizační informace pro objekt na držitele domény pro doménu, technického kontaktu pro nsset a objektu kontakt pro objekt kontakt. Motivace pro zavedení tohoto příkazu vyplyne z popisu transferu objektu. Rozšířeními na úrovni objektů se budeme zabývat v následující kapitole a rozšíření na úrovni příkazů a odpovědí se využívá při podpoře ENUM domén, o kterých bude řeč také později. 3.1 EPP objekty Na EPP standard navazuje několik jiných standardů, z nichž většina definuje mapování objektů do EPP. Tyto objekty jsou samozřejmě specifické pro registrátorské prostředí, které bylo hlavní motivací celého EPP standardu. Jako standardy existují tři typy mapování objektů: Doména (RFC 3731) Kontakt (RFC 3733) Host (RFC 3732) Toto jsou standardní mapování, u kterých se předpokládá, že budou použitá s EPP. V naší implementaci registru jsme se rozhodli je nakonec nepoužít a vytvořit si vlastní mapování pro všechny objekty. Přesto naše vlastní mapování vycházejí z těchto standardních a jsou jim velmi podobná. Vyvstává otázka, proč jsme nepoužili k úpravě standardizovaných mapování rozšíření a definujeme si vlastní objekty. Je to proto, že pomocí rozšíření příkazů a odpovědí můžeme snadno přidávat atributy objektu, ale nelze je odebírat. Druhým důvodem je, že pokud je změn až příliš mnoho, působí výměňované XML dokumenty nepřehledným dojmem. Posledním důvodem je, že rozšíření jsou ve schématech definovaná z podstaty věci jako volitelná, ale pokud rozšiřujeme základní vlastnosti objektu, které jsou povinné, klademe větší požadavky na aplikaci, která musí přítomnost atributů zkontrolovat sama a nemůže k tomu účelu použít XML validátor. Přítomnost objektu doména je předvídatelná, jedná se o klíčový objekt. Objekt kontakt reprezentuje fyzickou osobu, která může zastupovat ale i právnickou osobu. Objekt host reprezentuje počítač v síti internet. Mezi jeho vlastnosti patří doménové jméno a ip adresy. V registru doménových jmen se využívá k reprezentaci nameserveru. Tento objekt nebyl převzat, na místo něho je použit jiný objekt, nazývaný nsset. Jedná se o objekt, který sdružuje skupinu nameserverů a tato skupina může být přiřazena doméně. Myšlenka sady nameserverů byla převzata od registru rakouské národní domény. Standardní objekt host nebudem z tohoto důvodu nadále uvažovat a nahradíme jej objektem nsset. Existuje několik atributů, které jsou pro všechny objekty shodné. Zde je jejich výčet ve formátu: název XML elementu, který je označuje, a jejich stručný popis. ROID Zkratka pro Repository Object ID. Jednoznačně identifikuje objekt celosvětově. Skládá se ze dvou částí oddělených pomlčkou. První část je unikátní v rámci jednoho repozitáře a určuje si ji registr sám. Druhá část, celosvětově unikátní, přiděluje se pro celý repozitář a jejím přidělováním je pověřena organizace IANA.

26 28 KAPITOLA 3. EPP clid Je identifikátor registrátora, který je vlastníkem objektu. upid Je identifikátor registrátora, který naposledy provedl operaci update nad objektem. crdate Je datum a čas vytvoření objektu v repozitáři. update Je datum a čas posledního provedeného updatu nad objektem. trdate Datum a čas poslední změny vlastníka objektu (transferu). Ostatní atributy jsou specifické pro každý objekt. Pro objekt doména to je: name Doménové jméno. registrant Identifikátor objektu kontakt, který je veden jako držitel domény. Tím se myslí koncový zákazník, který si doménu pronajal přes registrátora. admin Identifikátor objektu kontakt, který je v roli administrátora pro doménu. Doména může mít více administrátorů. nsset Identifikátor objektu nsset, který sdružuje nameservery, na které je doména delegována. exdate Datum vypršení registrace domény. authinfo Autorizační informace pro doménu. Tato informace je využívaná při transferu domény od jednoho registrátora k jinému. Standard pro objekt doména definuje exdate jako datum a čas. Zkrácení na datum bez času proběhlo, aby se zabránilo nedorozuměním a případným sporům o nevčasném zrušení domény. Expirované domény se totiž vyřazují ze zónového souboru v jeden čas během dne bez ohledu na to, kdy během toho dne doména expirovala. Další změny vyplývají z uvedení nového objektu nsset na scénu, který nahrazuje objekt host. Pro objekt kontakt jsou vedené tyto specifické atributy: id Identifikátor kontaktu. postalinfo Tento element obsahuje jiné elementy, které specifikují poštovní kontaktní údaje objektu kontakt (jméno, organizace, adresa). voice Telefonní číslo kontaktu. fax Faxové číslo kontaktu. ová adresa kontaktu. authinfo Autorizační informace pro kontakt. Tato informace je využívaná při transferu kontaktu od jednoho registrátora k jinému. disclose Potomci tohoto elementu určují, jaké údaje o kontaktu mají být veřejné a jaké mají být skryté. To se projevuje ve výpisu informací o objektu na webu určeném pro veřejnost. ident Údaj, který jednoznačně identifikuje osobu v oficiálním smyslu. Může se jednat o rodné číslo, číslo pasu, občanského průkazu a tak podobně. vat Daňové identifikační číslo kontaktu. Oproti standardnímu objektu kontakt v naší variantě přibyly atributy ident a vat, poštovní údaje jsou dostupné pouze v jedné formě (ve standardu je to mezinárodní a lokální forma). Pro objekt nsset jsou vedené tyto specifické atributy: id Identifikátor nssetu. ns Tento element obsahuje jako potomky element name a volitelné addr elementy, které jsou využívány pro GLUE záznamy. tech Technický kontakt nssetu by měl být správce nameserverů, které nsset sdružuje. Zde je vyplněn identifikátor takového kontaktu. Technických kontaktů může být pro nsset více než jeden. reportlevel Nastavení úrovně technických testů prováděných na doméně. Zde není porovnání se standardním objektem, protože nsset nemá standardní ekvivalent. Všechny tři XML schémata, která definují strukturu objektových rozšíření jsou součástí dodatku se schématy.

27 3.2. MODEL TRANSFERU Model transferu Metoda transferu je poměrně záludná problematika s přihlédnutím k bezpečnostním hrozbám. V naší implementaci registru se liší od metody, kterou popisuje standard, proto se budeme transferem zabývat podrobněji. Nejprve si popíšeme jak probíhá transfer domény dle RFC 3730 a RFC Uživatel, který chce převést doménu k jinému registrátorovi, mu dá pokyn k převední. Nastávající registrátor vyšle žádost o převod domény. Na tuto skutečnost je stávající registrátor upozorněn zprávou a pokud mu jeho klient potvrdí převod, dá svolení k převodu. Tím je doména převedena. Tento postup je aplikovatelný i na objekt kontakt. Samozřejmě proces převodu má i jiné scénáře. Stávající registrátor může transfer odmítnout a nebo nadcházející registrátor může žádost o transfer zrušit ještě před jejím potvrzením nebo zamítnutím. Obrázek znázorňuje průběh úspěšného transferu domény podle postupu definovaného ve standardu. Čísla u šipek značí pořadí akcí. Samozřejmě vyvstávají otázky, co dělat, když transfer stávající registrátor ani nepotvrdí, ani neodmítne. V tom případě je věc serveru, jestli takové žádosti automaticky potvrdí nebo odmítne po stanoveném časovém intervalu. Pokud stávající registrátor odmítne žádost o transfer a přitom by jí měl povolit na základě vůle držitele domény, musí se spor řešit cestami mimo registrační systém. Ve fredu transfer domény probíhá podle následujícího schématu. Klient si nejprve od registrátora (budoucího či stávajícího) vyžádá autorizační informaci pro doménu, kterou chce převést. Tato informace mu je zaslána přímo z registru na ovou adresu, která je u domény vyplněná. Poté předá s žádostí tuto autorizační informaci registrátorovi, ke kterému chce doménu převést. Ten použije autorizační informaci a k převodu dojde bez asistence stávajícího registrátora. Oproti předchozímu modelu má tento výhodu v tom, že stávající registrátor nemůže blokovat převod domény. Na druhou stranu tato metoda obnáší komunikaci registru s koncovým zákazníkem, což nebylo v předchozím modelu nutné.

28 30 KAPITOLA 3. EPP Obrázek znázorňuje průběh úspěšného transferu domény v systému fred. Čísla u šipek značí pořadí akcí. Zároveň s převedením domény je automaticky vygenerována nová autorizační informace, aby původní registrátor, který měl přístup k této informaci, ji nemohl zneužít v budoucnu. Nový registrátor si může autorizační informaci zjistit pomocí info příkazu, který zobrazí autorizační informaci pro objekt, pokud je zadavatel příkazu vlastníkem objektu. 3.3 Nasazení EPP v praxi EPP vznikl na půdě společnosti VeriSign, která mimo dalších svých aktivit je správcem tld domén.net a.com, která je mimochodem nejvytíženější doménou současnosti. Architektem EPP je S. Hollenbeck z této společnosti. EPP protokol byl hned od svého vzniku (v době, kdy byl ještě draftem a ne standardem) adoptován druhým významným hráčem na trhu správců domén - společností Afilias, která je pověřena správou domény.org a.info a kromě těchto dvou domén spravuje ještě několik národních domén. Doména.info je snad první doména, pro kterou byl adoptován EPP protokol na místo rozhraní mezi registrátory a registrem hned od vytvoření této domény v roce EPP není první snahou S. Hollenbecka standardizovat rozhraní mezi registrárory a registrem, nicméně EPP je zatím nejúspěšnějším pokusem. Téměř všechny registry jsou ve stádiu, kdy už EPP podporují nebo se k tomu chystají. EPP je úspěchem, nicméně v určité oblasti selhává. Paradoxně snadná rozšiřitelnost EPP je zároveň kamenem úrazu, nebot různé registry implementují různá rozšíření, a tak EPP jako aspirant na unifikátor registrátorského rozhraní selhává. To vede k tomu, že se musí používat různí klienti pro různé registry. Nicméně krok kupředu EPP jistě znamená, jelikož základní protokol je implementován dle standardu, leč mapování objektů a jejich atributy se mohou lišit. Citlivou otázkou je metoda transferu domény, která se dosti liší napříč evropskými registry národních domén. Transfer je citlivý z toho důvodu, že jednotlivé registry se liší počtem registrátorů, jejich důvěryhodností a dosavadními zvyklostmi. Od švýcarského NICu vzešla iniciativa formou výzvy k diskuzi, která by sjednotila rozpolcenost evropských registrů v této otázce, nicméně zůstala nevyslyšena a autor této práce si není vědom žádných probíhajících diskuzí na toto téma.

29 3.3. NASAZENÍ EPP V PRAXI 31 Podle názoru autora této práce je na tom snad nejhůře EURid (registr.eu domény), pokud nebereme v úvahu dosluhující systém pro správu.cz domény, který se dopouští stejné chyby. Ač změnil základní schémata definující EPP, označuje své dílo nálepkou EPP, což vyloženě odporuje EPP standardu. Poměrně zajímavý přínos představuje myšlenka rakouského registru, který definoval mapování pro zcela nový objekt nsset, který sdružuje více nameserverů do jednoho objektu a tento objekt může být přirazen doméně jako celek. Jak vyplývá z předchozího textu v této kapitole, myšlenka objektu nsset byla převzata i českým registrem, leč mapování nssetu do EPP má vlastní. Pokud bychom měli kriticky zhodnotit naší implementaci EPP, pozitivním faktem je, že respektuje základní schémata EPP standardu, tudíž se jedná skutečně o EPP implementaci a ne jen něco, co se tomu velmi podobá. Na druhou stranu je škoda, že se nenašla u vedení společnosti vůle a odvaha dotáhnout implementaci až do konce, co se týká mapování EPP objektů. Nebylo převzato ani jedno standardní mapování pro doménu, kontakt ani host. A všechna tato standardní mapování byla nahrazena vlastními, což výrazně znepodobňuje protokol s tím, jak je implementován ve světě, a vylučuje použití standardních EPP klientů a knihoven. Navíc proces transferu je zcela jiný než jak je popsán ve standardu (nicméně standard není porušen) a pravděpodobně unikátní na celém světě, což lze opět považovat spíše za prohru z pohledu sjednocování rozhraní mezi registrátory a registrem.

30 32 KAPITOLA 3. EPP

31 Kapitola 4 ENUM ENUM (telephone NUmber Mapping) standard je popsán v RFC 3761 a RFC Jedná se o mapování tradičních telefonních čísel do DNS databáze. To umožnuje přidělit pak IP telefonu klasické telefonní číslo, na které jsou lidé zvyklí. IP telefony, u kterých se data nepřenášejí po síti telefonního operátora, ale po internetu, jsou stále populárnější hlavně díky tomu, že uživatel nemusí platit žádné jiné poplatky než za připojení k internetu. ENUM je v podstatě o způsobu, jak přeložit klasické telefonní číslo na url, které určuje kam se má volající spojit. Samozřejmě by se daly vyvinout nové standardy a speciální software, který by se o překlad klasického telefonního čísla na url postaral. Nicméně autoři ENUMu si všimli podobnosti s překladem domény na IP adresu, kterou zajišt uje DNS systém a rozhodli se využít právě tento systém pro své účely. Výhody tohoto řešení jsou, že DNS infrastruktura je vybudována a software taktéž, či-li myšlenka ENUMu může být uvedena do provozu ihned s nulovými náklady. Nyní si podrobněji popíšeme na hypotetickém příkladu, jak ENUM funguje. Či-li vezmeme si nejjednoduší příklad, kdy uživatel IP telefonu Karel volá uživatelce jiného IP telefonu, Janě. Karel využije výhod ENUMu, nemusí si tudíž pamatovat SIPovou adresu IP telefonu Jany, ale klasické telefonní číslo. "Vytočí" tedy číslo , které se lokálně mechanicky přeloží na doménové jméno e164.arpa. Pak už se jedná o klasický dotaz na doménové jméno s tím, že se neptáme na záznam adresy, ale na NAPTR záznam (definovaný v RFC 2915). Výsledkem je SIPová adresa IP telefonu Jany. Zbytek komunikace probíhá dle SIP protokolu. Mechanismus překladu telefonního čísla na SIP adresu s využitím DNS je poměrně triviální. Nyní několik poznámek k předchozímu příkladu. Pravidla pro překlad telefonního čísla na doménové jméno jsou pevně stanovena. Domény a telefonní čísla si jsou dosti podobné s tím rozdílem, že u telefonního čísla se identifikátor upřesňuje z leva do 33

32 34 KAPITOLA 4. ENUM prava, kdežto u domény z prava do leva. Pak už se liší pouze formalitami v zápisu a množinou povolených znaků. Jednotlivé úseky doménového jména jsou odděleny tečkou na rozdíl od telefonních čísel. Z předchozích myšlenek dojdeme k závěru, že pokud se má přeložit telefonní číslo na doménu, musíme ho zapsat pozpátku, jednotlivé cifry oddělit tečkou a pro zachování pořádku v hierarchii doménových jmen připojit suffix, který zastřešuje všechny ENUM domény - tím je e164.arpa. Doména arpa je k podobným účelům vyhrazená. Účastníci nemusí komunikovat zrovna přes SIP protokol, ale nějakou jeho alternativu. Na mechanismu ENUMu se tím nic nemění, změna protokolu by se musela ale odrazit ve výsledku DNS dotazu na ENUM doménu tak, že url by nezačínala prefixem sip, ale identifikátorem jiného protokolu. NAPTR (Naming Authority Pointer) záznamů může být dokonce i více a mohou mít různou prioritu, takže pokud se nepovede spojení na url s nejvyšší prioritou, použije se url s nižší prioritou. NAPTR záznam je poměrně složitý, protože výsledný záznam vzniká transformací na základě regulárního výrazu. Vstupem pro transformaci je doménové jméno, na které se ptáme. Ne každý DNS server podporuje tyto záznamy. Nicméně, jak uvidíme později, NAPTR záznamy nemají přímou souvislost s registračním systémem. Proto se jimy nebudeme zabývat. Zbývá zodpovědět otázku, jakou roli hraje v překladu ENUM domény na url registr domén. Pro registr je ENUM doména pouze doménou ze zóny, kterou spravuje. Či-li seznam zón se rozrůstá na cz a e164.arpa. Pak se až na detaily pracuje s ENUM doménami stejně jako s cz doménami. Kdybychom se chtěli držet předchozího příkladu a nastínit postup registrace telefonního čísla Jany, odehrávala by se registrace následovně. 1. Jana požádá registrátora o registraci domény, která odpovídá jejímu telefonnímu číslu. 2. Registrátor nejprve ověří, že číslo patří Janě, zasláním sms zprávy, která obsahuje informace o registraci a kód, který se použije při potvrzení registrace ze strany Jany. Tomuto procesu se říká validace. 3. Pokud validace proběhla v pořádku, registrátor vyšle požadavek na registraci domény přes EPP do registru. Při registraci se doméně přiřadí nsset, který sdružuje nameservery pro ENUM doménu. Tím je nová ENUM doména delegována na dané nameservery, které ovšem nejsou ve správě registru, ale bud to koncového zákazníka nebo zprostředkovatelské společnosti. Tím pádem e164.arpa zóna vygenerovaná pro DNS server obsahuje pouze záznam o delegaci na určené nameservery, nikoliv však přímo NAPTR záznamy. 4. V tuto chvíli, pokud se někdo pokusí dovolat ze zařízení, které bere ENUM v potaz, na telefonní číslo Jany, uskuteční se hovor přes internet. 4.1 Přizpůsobení registru pro správu ENUM domén Už bylo naznačeno, že v zásadě jsou ENUM domény velmi podobné klasickým doménám. Přesto v některých ohledech vyžadují vyjímečné zacházení. Předmětem této podkapitoly je upozornit na taková místa, leč seznam nebude úplný, ale zmíníme pouze ty nejdůležitější. V první řadě databáze musí být přizpůsobena ENUM doménám. V databázi je obsažena informace, které zóny jsou spravovány registrem. Každý záznam v této tabulce má atribut, který určuje, jestli se jedná o zónu klasických nebo ENUM domén. Napříč všemi vrstvami registru působí skutečnost, že u ENUM domén existuje dodatečný atribut datum validace, nebo přesněji řečeno datum, kdy vyprší platnost validace. ENUM domény jsou validovány vždy jen na nějaké období (v současné implementaci je to půl rok). Po vypršení této lhůty musí být doména znovu zvalidována, má-li být opět generována do zónového souboru. Je třeba upozornit, že se nejedná o datum expirace domény, ten zůstává v platnosti i na dále. Například ENUM doména je typicky registrována na jeden rok a během tohoto období dojde dvakrát k její validaci. Tato skutečnost se odráží v těchto komponentách: V databázi se objevila nová tabulka, která je vázaná na doménu a uchovává datum validace. EPP protokol byl rozšířen, nebo přesněji řečeno relevantní příkazy a odpovědi týkající se domény byly rozšířeny, standardním mechanismem pro rozšiřování EPP, o datum validace. Rozšíření jsou definovaná XML schématem enumval verze 1.0 (viz dodatek s XML schématy). S předchozím bodem souvisí podpora v EPP klientovi pro definované rozšíření enumval-1.0. Generátor zóny pro ENUM domény musí vyhodnocovat kromě datumu expirace navíc datum validace. Pokud doména není validní, nesmí se vygenerovat do zóny.

33 4.2. ENUM DOMA A VE SVĚTĚ 35 Všude, kde se vypisují informace o doméně (administrátorské rozhraní nebo rozhraní pro veřejnost) se musí respektovat datum validace pro ENUM domény ve výpisu. Teoreticky nic nebrání tomu, aby šlo telefonovat s využitím ENUMu ze sítě telefonního operátora na IP telefon a naopak. Dva důvody tomu brání v praxi a to jsou: Telefonní operátoři by museli přejít na paušální účtování a ne účtování za provolané hovory. To by vedlo k poklesům z tržeb, či-li proto ten chlad tuzemských operátorů k ENUMu. Implementace bran jež by byli styčným bodem mezi sítěmi telefonních operátorů a internetem. 4.2 ENUM doma a ve světě Využití ENUMu pro IP telefonii je poměrně mladá myšlenka. Jistě není čas na bilancování nebo rozsudky typu úspěšný, neúspěšný. Nicméně se v této podkapitole pokusíme shrnout fakta o dosavadních zkušenostech s provozem ENUMu v zahraničí i v České republice. Ke dni bylo v České republice (v zóně e164.arpa) registrováno 2100 ENUM domén, což pokrývalo celkem telefonních čísel. Tolik registrací v současných poměrech, kdy telefonní operátoři se staví k ENUMu velmi chladně a ENUM byl spuštěn zatím jen v trial módu, lze považovat za velký úspěch. Bude zajímavé sledovat, jak se bude popularita ENUMu vyvíjet po spuštění ostrého provozu od Zavádění ENUMu není proces ojedinělý pro Českou republiku. Přehled států, kde se zavádí ENUM, je k dispozici na webových stránkách organizace RIPE, která byla pověřena správou domény sdružující ENUM čísla.e164.arpa. Status Trial provoz Ostrý provoz Státy Česká republika, Finsko, Francie, Japonsko, Irsko Rakousko, Polsko, Německo, Rumunsko Tabulka 4.1: Stav ENUM registrací dle států. Aby vynikl prozatimní úspěch ENUMu v České republice uvedeme, že v sousedním Německu, které představuje mnohem větší trh a ENUM je tam spuštěn už od roku 2003, mají registrováno 7139 ENUM domén.

34 36 KAPITOLA 4. ENUM

35 Kapitola 5 Architektura systému Než si nastíníme rozvržení jednotlivých komponent systému, uděláme si pořádek v názvech komponent a systému jako takového. DSD-NG Označuje název celého systému správy domén. DSD-NG zahrnuje vše co se správou domén souvisí: hardware, software, předpisy pro registraci atd. DSD-NG zkratka znamená Distribuovaná správa domén nové generace. Je to systém specifický pro českou doménu a jinde jako celek nepoužitelný, protože právní podmínky, hardwarové vybavení a okolnosti se liší registr od registru. Fred Fred je název softwarové části systému. Tím jsou myšleny všechny programy vytvořené v rámci projektu, ale i "cizí" programy, na kterých je projekt závislý. Jedná se o universální část použitelnou víceméně napříč různými registry. Fred není specifický pro českou doménu, i když je součástí DSD-NG, který představuje systém pro správu české národní domény. Název fred vznikl z prvních písmen označení: Free Registry for Enum and Domain. Poznámka V užším slova smyslu se pod pojmem Fred může rozumět část centrálního registru napsáná v C++. Takového označení se však vyvarujeme, aby nevznikala nedorozumění. V průběhu vývoje došlo k jednomu přejmenování. Původně se systém nazýval ccreg (Country Code Registry). Ve zdrojových souborech se místy tento název ještě vyskytuje. Centrální registr Centrální registr je ta část Fredu, která "obaluje" databázi a přes rozhraní definované v IDL exportuje funkce, které operují nad databází, pro využití ostatním komponentám v systému. Je to jakési jádro celého registru. Důvod, proč je toto jádro napsáno ve dvou jazycích, spočívá v kompromisu mezi rychlostí programu (C++) a rychlostí vývoje (Python). 37

36 38 KAPITOLA 5. ARCHITEKTURA SYSTÉMU Znázornění pojmů DSD-NG, Fred a Centrální registr formou množin a podmnožin. Názvy uvedené unitř množin mají přiblížit, o co se v dané množině jedná. Poznámka Jako komunikační protokol mezi jednotlivými částmi systému byla vybrána CORBA. CORBA je specifikace vzdáleného volání metod, které je nezávislé na platformě a použitém programovacím jazyku. Základní znalost této technologie je nutná pro pochopení funkce centrálního registru. Čtenář, který není se základy této technologie obeznámen, by si měl přečíst dodatek, který shrnuje to nejpodstatnější z corby a až poté pokračovat ve čtení následujícího textu. Pro jednoduchost se podívejme nejprve na systém jako na černou skříňku. Na systém můžeme nahlížet očima registrátora nebo běžného uživatele internetu. Klíčová role je uživatel na internetu, který požaduje překlad DNS jména na IP adresu. To je koneckonců důvod existence registru. Druhou službou poskytovanou veřejnosti je whois. Whois slouží k získání informací o doméně. Na základě whoisu lze například zjistit komu doména patří, či kdo je zodpovědný za její technický provoz. Whois má dvě podoby. Textová podoba, někdy též nazývaná unixový whois, je popsána internetovým standardem RFC Podrobněji se o protokolu zmíníme v souvislosti s komponentou jež implementuje v registru whois protokol. Díky nárůstu obliby www rozhraní obecně v internetu, drtivá většina registrů poskytuje informace o registrovaných doménách formou html stránek přes http protokol. Toto rozhraní je jednoznačně populárnější a rozšířenější než zastaralý whois protokol, nicméně z důvodů jednoduchosti a možnosti automatizace má unixový whois stále důvod k existenci. Současný trend ve všech registrech je přesun odpovědnosti za zprostředkování informací z registru do webového whoisu, kde mohou být informace lépe chráněny proti zneužití. Mezi registrátorem a registrem proudí informace v obou směrech. Registrátor ukládá do registru informace o objektech a některé informace získává zase zpět z registru. Objektem je myšlena například doména. Podrobnosti o EPP protokolu jsou námětem samostatné kapitoly. Administrátorská role je tak trochu součástí registru jako takového, leč z pohledu implementace je to role jako každá jiná, která má své vlastní rozhraní. Je určeno pro využití pracovníky helpdesku. Administrátorské rozhraní umožňuje získávat rozličné informace z registru a zároveň umožnuje informace i měnit. Změna informací v registru je nazývána manuální zásah.

37 39 Na obrázku jsou znázorněny všechny vstupy a výstupy systému jako celku. Vnitřní architektura systému je záměrně opomenuta pro jednoduchost. Postavičky znázorňují uživatelské role a šipky protokoly, přes které komunikují s registrem. Role administrátor může být považována za součást systému, proto je v obrázku jeho součástí. Vše je soustředěno kolem databáze, která udržuje data registru. Na tuto klíčovou pozici byla vybrána databáze PostgreSQL. Důvody, které vedly k této volbě jsou shrnuty v dodatku o výběru databáze. Pokud bychom všechny komponenty Fredu uspořádali do vrstev podle vzdálenosti od středu, který je představován databází, dostali bychom schéma, které velmi dobře odráží architekturu systému. 1. V první vrstvě nalezneme aplikace, které běží přímo nad databází a přistupují do ní přes databázové C API (v případě PostgreSQL je to knihovna libpq). Souhrně jsou tyto aplikace nazývány Centrální registr a tvoří jádro registračního systému. Jsou mezi nimi určité vzájemné vazby, které zde pro jednoduchost opomíjíme a budou detailněji popsány později. Většina centrálního registru je napsána v C++, ale podstatná část i v Pythnu. Nejedná se o jeden program, ale o skupinu programů. Žádné rozhraní těchto aplikací není přístupné koncovému uživateli. Na místo toho se jedná o CORBA servery, jejichž rozhraní jsou definována v IDL, což je jazyk pro popis rozhraní, a komunikují s nimi CORBA klienti. Až tito klienti vytvářejí rozhraní pro koncové uživatele. 2. Tím jsme se přenesli do druhé vrstvy směrem od středu. Zatímco v první vrstvě byly CORBA servery exportující funkce nad databází, ve druhé vrstvě jsou CORBA klienti, kteří volají metody CORBA serverů. Tito CORBA klienti většinou vystupují z pohledu aplikací, které náleží do nejvzdálenější (třetí) vrstvy, v pozici serverů implementujících rozličné protokoly. Pokud tedy mluvíme o komponentách ve druhé vrstvě v termínech klient a server, je třeba pozorně dbát na kontext, protože mohou vystupovat většinou v obou rolích. 3. Třetí vrstva by teoreticky neměla existovat, protože se jedná o programy na straně koncových uživatelů registru (například web browser a unixový whois klient). Nicméně zde uvedená aplikace epp_client je vyjímkou a je vyvíjena jako součást registru (Fredu). Slouží jako referenční implementace EPP klienta.

38 40 KAPITOLA 5. ARCHITEKTURA SYSTÉMU Na obrázku je schématicky zachycena architektura celého systému, nebo přesněji jeho softwarové části. Sousednost vrstev je dána existujícím rozhraním pro vzájemnou komunikaci. Registr se sestává z následujících funkčních celků, podrobnější popis každé z komponent je obsahem podkapitol této kapitoly. fred_rif Implementuje operace definované EPP protokolem nad databází. Koncovka rif je zkratka "registrar interface", či-li rozhraní pro registrátory. fred_adif Implementuje administrátorské operace nad databází. Koncovka adif je zkratka "administration interface", či-li rozhraní pro administrátory. fred_pif Implementuje funkce nad databází, které zpřístupňují informace o doménách a jiných objektech veřejnosti. Koncovka pif je zkratka "public interface", či-li rozhraní pro veřejnost. pyfred Implementuje různorodé funkce nad databází pro generování zóny, notifikační systém, správce souborů a technické testy.

39 41 genzone Generuje zónový soubor vhodný pro načtení DNS serverem. Jedná se o klienta k modulu z pyfredu se shodným názvem. mod_eppd Modul do Apache pro překlad EPP požadavků na CORBA volání metod centrálního registru. mod_whoisd Modul do Apache překládající dotazy podané přes whois protokol na CORBA volání metod centrálního registru. whois Webový whois jsou www stránky, na kterých je možné zjišt ovat informace týkající se registrovaných domén. epp_client Klientský program komunikující se serverem (tím je mod_eppd) přes EPP protokol. Obrázek zachycuje vnitřní závislosti mezi jednotlivými komponentami v registru. Šipky naznačují roli komponenty ve vztahu, šipka směřuje vždy od klienta k serveru. Závislosti vyznačené tlustou čarou jsou zjevné a stěžejní. Každá šipka má přidělený popisek, bud to s názvem IDL souboru, který definuje rozhraní k serveru, nebo s názvem identifikujícím použitý protokol. Návrh databáze je do značné míry ovlivněn EPP protokolem a požadavkem na archivaci všech provedených změn nad objekty, aby bylo možné snadno revertovat efekt jakékoliv provedené operace. Historie změn se ukázala při návrhu býti nejkomplikovanějším úkolem. Vznik relačního databázového schématu se odehrál ve třech krocích: 1. Návrh tabulek reprezentujících objekty EPP a zachycení jejich vzájemných vztahů. 2. Doplnit schéma o ukládání historie změn objektů. S tím souvisí i ukládání informací o tom, kdo a kdy změnu provedl a v rámci jaké session. 3. Doplnit vše ostatní, co nesouvisí s předchozími kroky.

40 42 KAPITOLA 5. ARCHITEKTURA SYSTÉMU Největší problém představuje rostoucí množství dat v databázi, s kterým se zhoršuje její výkon. Množství dat totiž není úměrné pouze počtu registrovaných objektů, ale také počtu změn vykonaných na objektech. Proto se musí v pravidelných intervalech, které jsou v řádu měsíců až let, provádět prořez dat v databázi. Historická data musí být zaarchivována, aktuální data s částí historie ponechána. Schéma části relační databáze registru. Tabulky jsou rozděleny do skupin podle toho v jakém kroku vznikaly. Tabulky vyplývající z EPP jsou ohraničené plnou čarou, tabulky týkající se ukládání historie jsou ohraničené přerušovanou čarou a jejich výčet není úplný, ale přesně kopírují tabulky ohraničené plnou čarou. Tabulky týkající se správy session jsou na pravo mimo ohraničení. Problém uchování historie změn představuje zajímavý problém a v zásadě jsou dvě možnosti, jak ho řešit. První cestou je postupné inkrementální zaznamenávání změn. Pokud se chceme dostat ke stavu objektu v minulosti, musíme sadu uchovaných

41 5.1. FRED_RIF, FRED_PIF A FRED_ADMIN 43 změn aplikovat směrem od současného stavu do minulosti. Zatímco tato metoda je optimální z hlediska zabraného místa, není optimální z hlediska rychlosti. Druhým způsobem je uchovávat takzvané snapshoty objektů. Při provedené změně je nejdříve objekt, tak jak je, uložen do odkládací tabulky. Pokud chceme získat stav objektu v minulosti, jednoduše vybereme záznam z tabulky. Tato metoda duplikuje v databázi atributy objektu, které se nemění, nicméně je rychlá. Další její výhodou je, že se v relační databázi snadno realizuje. Tabulky na uchovávání snapshotů, kopírují přesně strukturu aktuálních tabulek, pouze se všechny doplní o atribut identifikátoru změny a zruší se některá integritní omezení typu cizích klíčů. Celkem je v databázi kolem sedmdesáti různých tabulek, z toho důvodu se nebudeme pokoušet znázornit věrné schéma databáze, ale pouze jeho nejpodstatnější část, na které jsou zachyceny tabulky reprezentující EPP objekty aktuální a historické, a tabulky související se správou session. Prostor aktuálních objektů a historických objektů spojuje tabulka object_registry, která obsahuje informace, které jsou neměnné po dobu životnosti objektu v registru, a tak jsou společné historickým i současným objektům. Tuto tabulku doplňuje jiná tabulka object, která obsahuje atributy společné všem objektům tak jako object_registry s tím rozdílem, že hodnoty v této tabulce podléhají změnám a proto mají svůj protějšek v historii - tabulku object_history. Pak následují tabulky realizující unikátní vlastnosti každého z objektů. Pro objekt doména je to tabulka domain a pro ENUM rozšíření tabulka enumval, pro objekt kontakt je to tabulka contact a nakonec objekt nsset je realizován tabulkami nsset, host a host_ipaddr_map. Již zmíněný identifikátor změny je ukryt v tabulce history pod atributem id. Tato tabulka váže dohromady změnu stavu objektu a akci, která změnu zapříčinila. Za povšimnutí stojí reprezentace registrátora (uživatele EPP) v databázi, která umožňuje, aby jeden registrátor měl více než jedny přihlašovací údaje (heslo a certifikát). Ostatní tabulky se dělí do logických celků pojmenovaných podle aplikací, jejichž účelům slouží. Z návrhového hlediska nejsou až tak zajímavé jako právě prezentované jádro systému. 5.1 fred_rif, fred_pif a fred_admin Jedná se o komponenty systému, které implementují backendy k jednotlivým rozhraním centrálního registru a dá se říct, registru jako celku. Jedná se o programy, které jsou na sobě při běhu nezávislé. Každý běží ve vlastním procesu. Nicméně při kompilaci sdílejí některé zdrojové soubory, které jsou spíše vedlejšího významu (například rutiny pro parsování konfiguračního souboru). Všechny jsou napsané ve stejném programovacím jazyce C++, sdílejí stejný konfigurační soubor a používají stejnou implementaci ORBu omniorb, který se stará o serverovou stránku programu a rozdělení procesu do vláken fred_rif Daemon fred_rif implementuje EPP operace nad databází. Je využíván modulem mod_eppd, který příchozí požadavky ve formě XML překládá na vzdálená volání metod nad objektem, který je implementován tímto daemonem. Daemon má však širší úlohu, než jen implementaci EPP operací nad databází. Má přehled o přihlášených uživatelích. Pro každého uživatele při přihlášení se do systému, vygeneruje unikátní identifikátor, který slouží k identifikaci session při komunikaci s mod_eppd a pro logování. Všechny operace provedené klientem jsou uloženy do databáze včetně vstupních a výstupních XML dokumentů. Operace, které vedou ke změně objektu v databázi, mají za následek uložení daného objektu do historie před změnou. Z těchto všech údajů jsme schopni velmi přesně zrekonstruovat celou session uživatele, což je důležité v případě nějakého sporu s uživatelem a také pro "rollback" provedených operací v případě potřeby. Činnost daemona je založena na přímočarém návrhu. Každá EPP operace má svůj protějšek v podobě CORBA metody. Té se z mod_eppd předává identifikátor session a další vstupní parametry vyplývající z EPP protokolu. Po provedení operace nad databází se vrátí skrze návratovou hodnotu a výstupní parametry modulu mod_eppd hodnoty, potřebné pro vygenerování EPP odpovědi. Při každé EPP operaci je otevřeno a na konci uzavřeno spojení do databáze, což má neblahý vliv na výkon systému. Proto se používá nástroj pgpool, který cachuje spojení do databáze a tím odstraňuje overhead připojování fred_pif Fred_pif je nejjednoduším daemonem z trojice C++ daemonů centrálního registru. Slouží jako backend pro webový i unixový whois. Webový whois přebírá funkci unixového whoisu, co se týká množství poskytovaných informací. Webový whois lze mnohem snadněji chránit před data-miningem než zastaralý whois protokol. K tomu účelu u webového whoisu slouží CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), která je realizovaná formou obrázku, na kterém se zobrazí znaky, které uživatel musí přepsat do textového políčka. Tím se zabraňuje strojovému procházení webových stránek

42 44 KAPITOLA 5. ARCHITEKTURA SYSTÉMU pomocí takzvaných robotů. Uživatel zadá CAPTCHU pouze při prvním dotazu na objekt. Zobrazená stránka v odpovědi obsahuje odkazy na jiné objekty, které mohou být proklikávány bez nutnosti zadávat CAPTCHU. To je realizováno následovně. Při prvním dotazu na objekt, který je ošetřen CAPTCHOU, se načtou rekurzivně všechny identifikátory objektů, na které se lze proklikat. Když uživatel pak klikne ve výpisu informací o doméně například na administrátorský kontakt pro doménu, webový whois si ověří, že identifikátor objektu se nachází ve stromě povolených identifikátorů objektů. Pokud se v tomto stromě nenachází, je požadováno zadání CAPTCHY. Webový whois tedy vzdáleně volá na objektu exportovaném fred_pifem pouze funkce, pomocí nichž si sestavuje rekurzivně strom identifikátorů povolených objektů, a funkce na získání detailů objektu pro samotný výpis informací o doméně, kontaktu nebo nssetu. CAPTCHA není samospasitelná a přináší závažné nedostatky, co se týká přístupnosti webu pro zrakově postižené lidi a ani ochrana, kouterou poskytuje není stoprocentní, protože rozpoznávací algoritmy se neustále zdokonalují. Nicméně se jednalo v době implementace o rychlé a vyhovující řešení. Ukázka webového whoisu. Zobrazení informací o ENUM doméně e164.arpa. Fred_pif ve skutečnosti exportuje dva CORBA objekty pro použití, jeden pro unixový whois a druhý pro webový whois, protože oba whoisy jsou poměrně rozdílné a nesdílejí žádnou část rozhraní.

43 5.1. FRED_RIF, FRED_PIF A FRED_ADMIN fred_adif Admin a fred_adif tvoří dohromady administrační rozhraní registru. Administrační rozhraní zpřístupňuje nejrůznější informace uložené v registru a dovoluje modifikaci dat v registru. Admin je webové rozhraní napsané v jazyce python pomocí HTTP objektově orientovaného frameworku CherryPy. Jedná se o tenkého klienta, což znamená, že víceméně pouze zobrazuje výsledky operací. Veškerá logika zpracování příkazů a předávání výsledků je na straně komponenty fred_adif. Obě části spolu komunikují přes rozhraní definované v IDL. Výhody architektury tenký klient, tlustý server jsou následující: Snadné nahrazení jednoho klienta jiným v případě, že bychom chtěli místo www klienta používat grafickou aplikaci napsanou například s pomocí knihovny GTK. Odolnost proti selhání klienta. Veškerý kontext připojeného uživatele je uložen na straně serveru. Pokud klient zhavaruje, je znovu nastartován a dojde mu požadavek od uživatele přihlášeného ještě před zhavarováním, dočká se očekávané odpovědi. Minimalizace množství dat přenášených mezi klientem a serverem, protože data jsou filtrována podle různých kritérií už na straně serveru. Možnost sdílení funkcí s ostatními servery centrálního registru napsaných v C++. Uživatel je v průběhu práce identifikován identifikátorem session. S tímto identifikátorem jsou na straně serveru svázány určité prostředky. Podle typu rozlišujeme prostředky na tabulky, filtry a detaily objektů. Tabulka je seznam objektů, filtr představuje kritéria pro výběr objektů z tabulky a detail obsahuje jednotlivé atributy objektu. Ukázka administrátorského www rozhraní. Na obrázku je formulář pro zadání kritérií podle, kterých lze vyhledávat v objektech domén.

44 46 KAPITOLA 5. ARCHITEKTURA SYSTÉMU 5.2 pyfred Pojem pyfred v širším významu je část centrálního registru implementovaná v jazyce python. Jazyk python se hodí tam, kde je potřeba dosáhnout rychlých výsledků a kde výkon není až tak rozhodující. To je důvod proč je centrální registr napsán ve dvou jazycích. Pojem pyfred v užším významu je pouze jakýsi framework, kam lze zasazovat jednotlivé moduly. Modul v kontextu pyfredu je soubor, napsaný v jazyce python samozřejmě, obsahující funkci init, která je zavolána po naloadování modulu do pyfredu při jeho startu. Tato inicializační funkce vrací CORBA objekt a název tohoto objektu, pod kterým má být zaregistrován u nameservice. O zpřístupnění objektu z vnějšku se stará samotný pyfred. Framework pyfred a jednotlivé moduly spolu interreagují pouze při inicializaci, po inicializaci si každý modul (CORBA objekt) žije svým vlastním životem, dá se říct. Framework pyfred poskytuje následující služby modulům: Funkce pro logování. Funkce pro správu spojení do databáze. Parsování konfiguračního souboru. Inicializace Object Request Brokeru a registrace objektů u nameservice. Spouštění pravidelných úloh registrovaných moduly. Díky prostředí, které pyfred vytváří pro moduly, je vývoj nových modulů poměrně rychlou záležitostí, protože nemusíme opisovat kód, který by byl jinak nutný pro všechny moduly, měli-li bychom implementovat každý jako samostatný CORBA server. Riziko chyb se touto cestou také minimalizuje. Pyfred je platforma pro "zásuvné moduly" realizované v pythnu. Dá se říci, že se jedná o sadu serverů, které jsou na sobě nezávislé. Konfigurační soubor je společný pro celý pyfred a je rozdělen do sekcí. Kromě obecné sekce, která konfiguruje pyfred jako framework, může konfigurační soubor obsahovat sekce pro jednotlivé moduly, vyžadují-li konfiguraci. Následuje stručný popis modulů využívaných v ostrém provozu.

45 5.2. PYFRED genzone Modul genzone slouží ke generování zónového souboru. Zónový soubor je vstupem pro DNS server, který zprostředkovává standardní cestou přes DNS protokol informace uživatelům internetu. Přesněji řečeno se jedná o CORBA server generátoru zóny. K vygenerování zónového souboru je třeba ještě klient. Klient-server architektura u generátoru zóny má tu výhodu, že zóna se může generovat na jiném stroji, než kde běží centrální registr, což je pravděpodobná situace, protože težko bychom chtěli, aby nameserver v roli master běžel na stejném stroji jako centrální registr (z hlediska výkonu a bezpečnosti). Vzhledem k velkému objemu dat transfer zóny ze serveru do klienta neprobíhá v jednom kroku, ale po částech jejichž velikost je definovatelná klientem. Schéma komunikace mezi klientem a serverem při generování zóny je poměrně zajímavé a je použito i u jiných modulů. Klient se spojí se serverem a vyžádá si skupinu údajů, jejichž velikost je relativně malá a předem známá. Tuto skupinu dat nazýváme statické, protože známe předem jejich počet a velikost. Server zároveň vytvoří nový CORBA objekt, do kterého uloží data, které tvoří seznam položek a délka tohoto seznamu je předem neznámá, potenciálně neomezená. Tato data nazýváme v našem modelu dynamická. Reference na nově vytvořený objekt je vrácena společně se statickými daty. Klient pak přistupuje k dynamickým datům přes referenci na nový objekt - voláním metody tohoto objektu. Může si určit počet položek seznamu, které se mají vrátit v jednom vzdáleném volání metody. Prázdná množina výsledků je signálem pro klienta, že všechna data byla už přetransferována. Klient na to zavolá metodu objektu, která uvolní část prostředků alokovaných pro transfer dat na straně serveru a označí sebe sama (objekt) jako připravený k vymazání. Pravidelně spouštěné rutiny kontrolují seznam vytvořených objektů na straně serveru a objekty určené k vymazání dealokují. Existující objekty, jejichž délka existence přesáhla určitou mez, jsou označeny jako nečinné a posléze uvolněny. Perioda pravidelné kontroly a mez nečinnosti jsou konfigurovatelné. Typický scénář komunikace klienta a serveru při generování zóny. Hlavní myšlenkou je transferovat data postupně po malých částech a ne v jednom volání vzdálené metody. Transferovaná data mohou mít celkouvou velikost v řádech stovek megabajt. Generátor zóny je klíčová součást registru, jelikož realizuje jeho základní účel, kterým je zařazení doménového jména do zóny, odkud je přístupné veřejnosti. O zařazení nebo nezařazení doménového jména do zóny rozhoduje datum expirace domény, u ENUM domén je to navíc ještě datum validace. Ze zóny jsou vyřazeny domény pokud mají datum expirace včerejší anebo starší plus ochranná lhůta. Ochranná lhůta zajišt uje, že expirovaná nebo nezvalidovaná doména je generována do zóny po nějakou dobu. Pokud v této ochranné lhůtě držitel neprodlouží platnost nebo nezvaliduje nově doménu, doména se přestane generovat do zóny, tím pádem přestane defacto existovat na internetu. Ochraná lhůta je v současnosti 31 dní. Vzhledem k citlivosti faktu (ne)zařazení domény do zóny, je vedena historie zařazení domény v zóně. Tato historie ukládá pouze

46 48 KAPITOLA 5. ARCHITEKTURA SYSTÉMU změny v zařazení a nezařazení domény do zóny oproti předchozímu stavu filemanager FileManager je modul pro správu souborů. K zajištění svých úkolů používá dvě databáze. Souborový systém používá k ukládání souborů jako takových. Databázi centrálního registru používá pro ukládání informací o spravovaných souborech. Každému souboru je při uložení přiděleno identifikační číslo, kterým je možné se na soubor odkazovat. FileManager je využíván pouze aplikacemi v rámci centrálního registru, konkrétně Mailer daemonem pro ové přílohy. Se souborem se uchovává jeho MIME typ, datum vložení do databáze, jeho velikost a volitelné jméno souboru, které je určené k zobrazení na místech použití souboru. Místo uložení souboru na filesystému je dáno vzorem {rok}/{měsíc}/{den}/{id}. Časové údaje jsou vzaty z aktuálního datumu při vložení souboru do databáze. Tímto způsobem je dosaženo rovnoměrného rozložení souborů v adresářích a snadná orientace v adresářové struktuře. Modul implementuje také administrátorské rozhraní, pomocí něhož lze vyhledávat soubory na základě stanovených kritérií. Kritéria pro vyhledávání se odvíjejí od meta dat o souboru uložených v databázi. Mechanizmus stahování výsledku vyhledávání ze serveru do klienta, je totožný s transferem dat při generování zóny mailer Mailer daemon implementuje notifikační systém registru. Spojuje v sobě šablonovací systém, rozesílání elektronické pošty, její archivaci a vše co je spojené se získáváním dat z archivu. Systém produkuje MIME multipart y dle standardu RFC Či-li se může skládat z libovolného množství příloh. Přílohy rozdělujeme do dvou základních skupin podle toho, jestli podléhají šablonovacímu systému či nikoliv. Přílohy, které jsou vytvořeny ze šablon, jsou implicitně textového typu. Přílohy, které nejsou zpracovány pomocí šablon, jsou primárně určeny pro soubory ve formátu pdf, ale mohou obsahovat soubory jakéhokoliv typu. Obrázek znázorňuje vygenerování a odeslání ové zprávy. Nahoře jsou uvedeny zdroje, které jsou předány CORBA metodě na generování u, posléze vstupují do procesu databáze a FileManager, na konci je vygenerovaný předán programu sendmail.

47 5.2. PYFRED 49 Mailer je využíván pouze aplikacemi centrálního registru, konkrétně fred_adifem a fred_rifem. Na vstupu příjímá daemon identifikátor typu u, který určuje jaké šablony se použijí pro sestavení u, hodnoty pro pole v hlavičce u, seznam dat typu klíč-hodnota, která poskytují vstupní data pro šablony, a nakonec identifikátory příloh, které se připojí ke zprávě. Na pozici jádra šablonovacího systému byla vybrána existující knihovna clearsilver, která má stejné možnosti jako známější jazyk XSLT, nicméně vykazuje lepší výkon a tvoření clearsilver šablon je jednodušší pro člověka nezasvěceného do této problematiky (například pracovníka helpdesku). Co šablona to jedna textová příloha u. Přílohy, které nejsou určeny pro šablonování jsou získány od FileManager daemona, který je správcem těchto souborů. Ve chvíli, kdy jsou připravené hlavičky u a všechny přílohy (vzniklé ze šablon nebo získané od FileManagera), je zaarchivován do databáze a předán k poslání unixovému programu sendmail, který se postará o doručení u. Šablony i jejich produkty jsou v UTF-8 kódování, souborové přílohy získané z FileManageru jsou zakódovány do base64. Každý odeslaný má přidělené identifikační číslo, které se mimochodem vyskytuje v ové hlavičce Message-ID. Mailer poskytuje i administrační rozhraní. To obsahuje v současnosti pouze funkce pro vyhledávání v archivu ů. Vyhledávat se může podle rozličných kritérií: Datum vytvoření a odeslání u Jednoznačný identifikátor u Typ u Přílohy u Identifikátory objektů (kontaktů, domén, nssetů) nějakým způsobem spjatých s em Výsledkem vyhledávání je seznam struktur obsahující informace o u i obsah u samotného. Výsledky mohou být odebírány postupným způsobem pro případ, že by množina výsledných ů byla příliš početná. Princip postupného stahování výsledků je totožný jako u generátoru zóny techcheck Modul techcheck zajišt uje kontrolu technického stavu nssetu. Zde je příhodná chvíle vysvětlit zásady správné delegace. Pojem delegace domény na nameserver znamená, že nameserver je autoritativní pro danou doménu, to znamená, že obsahuje SOA záznam pro danou doménu. K zajímavému jevu dochází pokud nameserver, na který je doména delegovaná, má doménové jméno, které je poddoménou oné domény. Pak vzniká problém, že nelze zjistit ip adresu nameserveru, který obsahuje záznamy o oné doméně, protože ip adresa nameserveru je součástí oněch záznamů. Proto se zavádí takzvaný GLUE záznam, který zveřejňuje adresu nameserveru v případě, že je poddoménou domény, pro kterou je autoritativní. Doména musí být delegována aspoň na dva nameservery. Redundance zvyšuje odolnost DNS systému proti výpadkům nameserverů. Technický test domény může být vyvolán nějakou komponentou centrálního registru (například fred_rifem při registraci nové domény) nebo může být součástí pravidelného testu všech registrovaných domén. Existuje několik testů, kterými může být testována doména. Jednotlivé testy jsou dále rozřazeny podle závažnosti do několika kategorií. Je na správci sady nameserverů, aby si zvolil od jaké úrovně se mu mají zasílat hlášení o testech, které skončily chybou. Úroveň testu značí závažnost podmínky, kterou testuje. Vzrůstající hodnota znamená menší závažnost. Nastavení úrovně u nssetu na nulovou hodnotu znamená, že se nebudou provádět žádné testy na nameserverech. Mezi testy existují vzájemné závislosti. Například pokud neprojde test na existenci nameserveru, nemá cenu testovat autoritativnost nameserveru a tak podobně. Tyto závislosti jsou podchycené v implementaci tak, aby se nedělelaly zbytečné testy. Technické testy jsou zadané v databázi a techcheck daemon si před tím, než provádí kontrolu na doméně, informace o testech načte. Součástí záznamu o typu technického testu je i název skriptu, který kontrolu zajišt uje. Tento skript je techcheckem spuštěn a na základě návratového kódu, je určen status testu. Přípustné jsou tři výsledky: prošel, neprošel a výsledek neznámý. Neznámý výsledek nastává v případě neočekávané chyby při testování. Každý výsledek testů je archivován v databázi a je tedy možné získat detailní informace o proběhlých testech na doméně v minulosti. Pokud je technický test vyžádán přes rozhraní pro registrátory (EPP), je odpověd s výsledky testů zaslána asynchroně pomocí EPP zprávy (poll zprávy). Pokud je technický test součástí pravidelné kontroly všech registrovaných domén, je zpráva o nesplněných testech zaslána formou u technickému kontaktu nssetu. Informativní RFC 1912 shrnuje nejčastější chyby při konfiguraci DNS serveru. Návrh testů z toho částečně vychází, leč je mnohem přísnější v mnoha ohledech než informativní dokument. Zacházet při testech nameserverů až do takových detailů může

48 50 KAPITOLA 5. ARCHITEKTURA SYSTÉMU Název testu Závažnost Popis Existence nameserveru 1 Testuje, jestli nameserver existuje. To znamená, že si vyžádá nějaký záznam z nameserveru, ale neanalyzuje odpověd. Přítomnost záznamu 2 Testuje, zda-li je na nameserveru přítomen SOA záznam pro doménu, ke které je přiřazen. Autoritativnost 3 Testuje, zda-li je nameserver pro danou doménu autoritativní. Autoritativnost odpovědi nameserveru se pozná podle nastavení flagu v odpovědi. Rekurzivní nameserver 4 Rekurzivní nameserver zvyšuje riziko DoS útoků. Jestli je nameserver rekurzivní, oznamuje ve své odpovědi nastavením flagu. Rekurzivní nameserver pro veřejnost 4 Jako předchozí vysvětlení, leč ještě nebezpečnější, protože o DoS útok se může pokusit kdokoliv z internetu. V praxi by měl test mít stejný výsledek jako předchozí. Zde se nicméně nespoléháme na flag nastavovaný serverem, ale přímo se zeptáme na doménu, o které víme, že není spravovaná nameserverem. Autonomnost nameserverů 5 Testuje, jestli aspoň dva nameservery v nssetu jsou z různých routovacích domén. Routovací domény se dají zjistit z whois výpisu na ip adresu. Slabinou tohoto testu je, že identifikátor autonomního systému je součástí výpisů pro ip adresy spravované organizací RIPE. Pokud whois odpověd tento údaj neobsahuje, jsou nameservery považovány za autonomní. Heterogení software 6 Testuje jestli se pro doménu používají různé DNS servery. Různé implementace DNS serverů snižují riziko napadení obou dvou nameserverů zároveň a tím znefunkčnění celé zóny. Tabulka 5.1: Výčet technických testů a jejich úrovní

49 5.3. MOD_EPPD A MOD_WHOISD 51 vyvolávat diskuze. Nicméně právě z důvodu, pokud správce nameserverů nesouhlasí s doporučeními CZ.NICu nebo aktuální situace mu neumožňuje obstát ve všech testech, je u objektu nsset atribut, jehož prostřednictvím si technický správce nastaví úroveň testů, které se mají provádět. 5.3 mod_eppd a mod_whoisd mod_eppd a mod_whoisd jsou moduly do apache httpd (zkráceně nazýván apache). Apache je www server, jehož funkcionalita je rozšiřitelná pomocí tzv. modulů, které jsou většinou implementovány jako sdílené knihovny, které se nahrají do procesu apache při jeho startu. Moduly jsou integrovány do apache pomocí API, které je založeno na registraci tzv. hooků. Hook je funkce, která je zavolána v případě, že nastane nějaká událost. Apache a jeho API je natolik universální, že lze implementovat pomocí modulu téměř jakýkoliv protokol, nejen http, pro který je apache primárně určen. Přitom se nemusíme zabývat implementací spousty věcí, které bychom museli řešit, pokud bychom se rozhodli implementovat celý server znova. To znamená výrazné urychlení vývoje a využití cenného know-how, které představuje léty prověřený kód apache. Následující body shrnují, co vše programátor získá automaticky, pokud se rozhodne využít jako základní platformu apache. Parsování konfiguračního souboru. Modul jednoduše sdělí jaké konfigurační direktivy mu náleží a jejich zpracování je přenecháno modulu. Vyřešení sít ování, můžeme se zabývat pouze detaily aplikační vrstvy. Modul přichází do styku pouze s daty, které přicházejí přes spojení. Navázání, management a ukončení spojení je před programátorem modulu ukryto. Zabezpečené spojení pomocí SSL. Do apache existuje standardní module mod_ssl, který transparentně, vzhledem k ostatním modulům, šifruje příchozí a odchozí data. Efektivní zpracování sít ových spojení. Každé spojení běží v samostatném procesu (v případě vláknového apache, v samostatném vláknu). Pomocí takzvaného preforku, což jsou předpřipravené procesy v zásobě, se vyrovnávají provozní špičky. Počet předpřipravených procesů se dynamicky mění podle očekávané zátěže. Apache runtime library, která je součástí apache, je knihovna obsahující množství užitečných funkcí urychlujících vývoj programů, včetně dynamického alokátoru paměti, který minimalizuje časté chyby při práci s pamětí. Navíc zajišt uje přenositelnost mezi různými operačními systémy. Spoustu drobnějších věcí, jako standardní reakce na signály, detailní zobrazení statusu serveru, ladící a debugovací možnosti, logování. Těžko je zde vyjmenovat všechny. Oba dva moduly, mod_eppd a mod_whoisd, vykazují shodné charakteristiky. Oba vystupují v roli CORBA klientů, kteří komunikují s centrálním registrem, a oba slouží zárověň jako servery implementující rozdílné protokoly. Právě jejich společná část, role CORBA klienta, zapříčinila vznik dalšího, třetího modulu mod_corba, který se zabývá správou CORBA objektů, které jsou distribuovány ostatním modulům, které je mohou využít pro volání vzdálených metod. Jedná se o podpůrný modul, proto není zmíněn ve schématu architektury systému. Ve všech třech modulech je využívána knihovna ORBit2, implementace Object Request Brokeru pro GNOME projekt. Výběr byl dán tím, že ORBit2 obsahuje mapping do jazyka C, což například omniorb využívaný v jiných komponentách nemá.

50 52 KAPITOLA 5. ARCHITEKTURA SYSTÉMU mod_corba získá reference na corba objekty, kterým přidělí aliasy a přichytí je na strukturu reprezentující spojení. Postupně, tak jak je spojení zpracovávané ostatními moduly, můžou nebo nemusí využít reference na objekty, které jsou jim k dispozici. Nepřerušovaná čára znázorňuje životní cyklus struktury reprezentující spojení a zvýrazněný úsek chvíli, kdy jsou na strukturu navázané reference na CORBA objekty. Modul mod_corba lze konfigurovat pomocí následujících direktiv: CorbaNameservice HOST Určuje stroj, na kterém je dostupná služba CORBA nameservice. Tato služba poskytuje reference na objekty na požádání. CorbaObject NAME ALIAS Určuje jednu referenci na objekt, která má být ve správě mod_corba modulu. Reference je získána z CORBA nameservice pomocí zadaného jména. Pro ostatní moduly je reference přístupná pod zadaným aliasem. Tato direktiva se může vyskytovat tolikrát, kolik referencí na různé objekty chceme využívat. Základem mod_eppd a mod_whoisd modulů je connection hook, který je zavolán ve chvíli, kdy je navázáno spojení s klientem. Od té chvíle, pokud spojení vyhovuje požadavkům uvedeným v konfiguraci, přechází spojení pod správu modulu a až do jeho uzavření ve správě modulu zůstává. Moduly jsou implementací aplikační vrstvy sít ového zásobníku. Nejdříve se budem zabývat modulem mod_whoisd, který je podstatně méně komplikovanější než mod_eppd mod_whoisd Modul implementuje whois protokol tak, jak je popsaný v RFC Protokol umožňuje získávat informace o objektech uložených v databázi. Klient po navázání tcp spojení se serverem vyšle jednu řádku ukončenou znaky carriage return a line feed. Obsah řádky se interpretuje jako název objektu, o kterém jsou požadovány informace. Původní whois byl velmi benevolentní, co se týče nakládání s informacemi. Umožňoval do názvů objektů zadávat takzvaný "wildcard" znak, který nahrazuje libovolnou skupinu znaků. Moderní hrozby internetu, jako zneužívání těchto lehko dostupných informací k zasílání nevyžádané pošty, zapříčinily zúžení obsahu informací podávaných touto cestou. V současné době stále najdeme registry, kde neplatí žádné restrikce na informace poskytované přes whois včetně vyhledávání přes wildcardové znaky (příkladem budiž předchozí systém na registraci.cz domén, který má být nahrazen fredem). Ovšem všechny nové implementace registrů se možnému automatizovanému zneužívání informací brání (například whois EUridu). Modul mod_whoisd poskytuje informace pouze o technických správcích domény (což jsou v našem modelu kontaktní osoby u sady nameserverů, která je k doméně přidružena) a nameserverech, na které je doména delegována. To jsou totiž informace nezbytně nutné v případě problému s technickým provozem domény. Odpověd z whoisu obsahuje také odkaz na webové stránky CZ.NICu, kde lze získat plnou informaci o doméně včetně vlastníka a administrátorských kontaktů. Tyto webové stránky jsou zabezpečeny proti "data-miningu". U ENUMových domén odkaz na webový whois není uveden, jelikož se na tyto domény vztahují jiná pravidla týkající se zveřejňování informací.

51 5.3. MOD_EPPD A MOD_WHOISD 53 Obrázek znázorňuje funkci apache modulu mod_whoisd. Požadavek přicházející přes whois protokol je překládán na vzdálené volání metody, jejíž návratová hodnota je využita při tvorbě odpovědi na whois dotaz. Funkce whois modulu do apache je soustředěna kolem jedné CORBA funkce, která získá od centrálního registru variabilní údaje, které se posléze doplní do statické šablony, jejíž text tvoří většinu výstupu. Komentáře jsou ve výstupu uvozené znakem procento. % Whoisd Server Version: 1.3 % % % (c) 2006 (http://www.nic.cz) % % Intended use of supplied data and information % % Data contained in the domain name register, as well as information % supplied through public information services of CZ.NIC association, are % appointed only for purposes connected with Internet network % administration and operation, or for the purpose of legal or other % similar proceedings, in process as regards a matter connected % particularly with holding and using a concrete domain name. % % The domain name register is protected by the law according to % appropriate legalities about database protection. Data, information % should not be collected, reproduced, stored or moved beyond this scope % in any form without preceding agreement from CZ.NIC association. The use % of data, information or any part of them contrary to this purpose could % be considered as a breach of the rights of CZ.NIC association, or of % persons whose data are stored in the domain name register or as a % violation of the rights of executors of the property rights. Gathering % of the data or any part of them and /or providing of them for % unrequested message distribution, abuse of network services operation % and breaking the privacy of the other users is particularly considered % as a violation of these rights. Using them contrary to the stated % purpose can also lead to the user being considered as criminally % responsible. % % Attention: Requirements for the provision of data or information are % recorded. If a request or a series of requests is evaluated as an attack % which may cause damage to network services or as an effort to gather % data in conflict with the original purpose, this may lead to a blocking % of the access to information services of CZ.NIC or further action as may % be deemed necessary. % % The restrictions indicated above do not refer to statistical data % provided by CZ.NIC on condition that the use of such information will % not result in any change of the content or context thereof, and also on % condition that a reference is provided along with any such use to the % CZ.NIC Association or the domain name register as a source of such % information. % % By using the WHOIS service or the service of searching in the domain % names register database, the user agrees to the stated conditions and % purposes of data use. % % Timestamp: T10:16:52+01:00

52 54 KAPITOLA 5. ARCHITEKTURA SYSTÉMU Domain: Status: REGISTERED Registered: T15:21:11+01:00 Expiration: Registrant: Please visit webbased whois at for more information. Registrar: Name: LRR Website: Technical Contact: CID:ID01 Nameservers: ns3.domain.cz ns2.domain.cz ns1.domain.cz Modul mod_whoisd je konfigurovatelný pomocí následujících konfiguračních direktiv: WhoisDisclaimer PATH Cesta k souboru, který obsahuje úvodní komentář zobrazený v každé odpovědi whoisu. WhoisWebURL URL Odkaz na webové stránky, kde se může klient dozvědět bohatší informace o doméně. Tento link je součástí odpovědi na whois dotaz v případě, že se nejedná o ENUM doménu. WhoisObject ALIAS Alias, pod kterým zpřístupňuje mod_corba modul referenci na whois objekt. Pomocí tohoto aliasu je reference na whois objekt "vytažena" ze struktury reprezentující navázané spojení mod_eppd Modul mod_eppd slouží podobnému účelu jako mod_whoisd. Překládá jeden protokol na druhý. Nicméně EPP protokol je mnohem komplikovanější než whois protokol, z čehož vyplývá větší rozsáhlost modulu. Komunikace přes EPP protokol probíhá přes šifrované spojení, proto s výhodou využíváme standardního mod_ssl modulu pro apache, který se pro nás transparentně stará o šifrování komunikace. EPP je XML protokol, či-li požadavky a odpovědi jsou zapsané ve formě XML dokumentů. EPP zpráva (budeme ji označovat termínem rámec) je prefixována její délkou v bajtech, na kterou jsou vyhrazeny čtyři bajty. Struktura XML dokumentů je definovaná XML schématy. Modul je vnitřně strukturován na komponenty, z nichž každá plní specifickou roli při zpracování požadavku. Komponenty jsou pojmenovány podle názvu souborů, ve kterých se nachází jejich zdrojový kód. Základní komponenta mod_eppd.c, je základ celého modulu. Je to pojítko modulu s apachem a je v něm ukryta logika zpracování EPP požadavku. Tato komponenta pro zpracování požadavků používá tři pomocné komponenty: epp_parser.c Komponenta parsuje XML, které je jí předáno formou stringu. Na výstupu vyprodukuje strukturu, která obsahuje jednotlivé informace ze vstupního XML dokumentu. Pro práci s XML používá knihovnu libxml2. Před parsováním dokumentu je provedena jeho validace, dle XML schémat definujících EPP protokol. Pro navigaci v XML dokumentu je využit XPath jazyk verze 1.0, což je W3C standard. epp-client.c Komponenta přijímá na vstupu strukturu s daty z XML dokumentu, kterou produkuje epp_parser.c. Tato data převádí do formy definované IDL souborem. Jádro činnosti spočívá v zavolání vzdálené metody, která provede danou operaci nad databází. Výstupní parametry volání vzdálené metody se uloží do struktury ke vstupním datům. Komponenta je postavena nad knihovnou ORBit2. epp_gen.c Komponenta na vstupu přijímá strukturu, kde jsou uložena jak data z pársování XML dokumentu, tak data z výstupu volání vzdálené metody. Účelem je vygenerovat XML dokument, který je odpovědí na zaslaný EPP požadavek. Pro sestavení výstupního XML dokumentu je opět použita knihovna libxml2.

53 5.3. MOD_EPPD A MOD_WHOISD 55 Architektura mod_eppd modulu. Modul není monolit, ale skládá se z několika komponent, které spolu komunikují přes jasně definovaná rozhraní. mod_eppd je konfigurovatelný pomocí následujících konfiguračních direktiv: EPPschema URL URL XML schématu, které definuje EPP protokol. Je nutné pro validaci XML požadavků.

54 56 KAPITOLA 5. ARCHITEKTURA SYSTÉMU EPPservername NAME Název tohoto serveru, který je poslán klientovi jako součást greeting rámce. EPPlog FILE Modul má svůj oddělený log soubor, kam se logují veškeré detaily EPP komunikace. V případě, že EPPlog není nastaven, loguje se do standardního logu apache. EPPloglevel LEVEL Nastavení log levelu pro EPP hlášky. EPPvalidResponse ON OFF Nastavení validace odchozích XML odpovědí. Používá se pouze v testovacím provozu, protože vzniklé zpoždění není zanedbatelné. EPPobject ALIAS Alias, pod kterým mod_corba zprostředkovává přístup k referenci na EPP objekt. Pomocí tohoto aliasu je reference na EPP objekt "vytažena" ze struktury reprezentující navázané spojení. 5.4 epp_client Program epp_client je referenční implementace EPP klienta vyvíjená jako součást fredu. Aplikace je napsána v jazyce python a je určena registrátorům, kteří tímto způsobem dostávají do rukou nástroj, kterým mohou registrovat, mazat a měnit objekty v registru. Registrátorské rozhraní do registru je specifikováno XML schématy, či-li nic nebrání registrátorům ve vytvoření si vlatního EPP klienta, leč v drtivé většině používají tuto referenční implementaci. Jádro klienta tvoří knihovny (v jazyce python nazývané moduly). Nad těmito knihovnami jsou postavená uživatelská rozhraní. V současnosti jsou to dvě rozhraní: textové a grafické. Textové rozhraní je vhodné i pro neinteraktivní používání. Grafické rozhraní je napsáno s podporou knihovny QT verze 4. Je vhodné spíše pro menší registrátory, kteří registrují domény manuálně. Klient má svůj konfigurační soubor v domovském adresáři uživatele, ve kterém lze nastavit host a port EPP serveru, SSL certifikát a privátní klíč, který se má použít pro připojení, a množství dalších, méně podstatných voleb. XML dokumenty, které se odesílají na server, jsou sestavovány pomocí DOMu (Document Object Model). Příchozí XML dokumenty jsou parsovány pomocí knihovny Expat. Jak odchozí tak příchozí XML dokumenty mohou být volitelně validovány dle příslušných XML schémat. Validace se provádí pomocí nástroje xmllint, který je součástí knihovny libxml2. Ukázka obrazovky textového rozhraní EPP klienta. V terminálu jsou viditelné dva příkazy a odpovědi na ně: info-domain a check-domain.

55 5.4. EPP_CLIENT 57 Ukázka obrazovky grafického rozhraní EPP klienta. Záložky v první úrovni představují typ EPP objektu a záložky ve druhé úrovni příkaz nad EPP objektem. Konkrétně je zobrazena odpověd na příkaz info-domain.

3. PRODLOUŢENÍ REGISTRACE DOMÉNOVÉHO JMÉNA 4. DELEGACE DOMÉNOVÉHO JMÉNA

3. PRODLOUŢENÍ REGISTRACE DOMÉNOVÉHO JMÉNA 4. DELEGACE DOMÉNOVÉHO JMÉNA Pravidla registrace doménových jmen v cctld.cz V platnosti od 1.11.2011 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

Pravidla komunikace registrátora ZONER software, a.s. V platnosti od 1.8.2004 OBSAH 1. Úvodní ustanovení 2. Subjekty 3. Registrace Doménového jména 4. Prodloužení registrace Doménového jména 5. Změna údajů

Více

Pravidla komunikace registrátora Web4u s.r.o.

Pravidla komunikace registrátora Web4u s.r.o. Pravidla komunikace registrátora Web4u s.r.o. V platnosti od 24.10.2003 OBSAH 1. Úvodní ustanovení 2. Subjekty 3. Registrace Doménového jména 4. Prodloužení registrace Doménového jména 5. Změna údajů subjektů

Více

ENUM Nová dimenze telefonování. CZ.NIC z.s.p.o. Pavel Tůma / pavel.tuma@nic.cz 22. 11. 2006 http://enum.nic.cz

ENUM Nová dimenze telefonování. CZ.NIC z.s.p.o. Pavel Tůma / pavel.tuma@nic.cz 22. 11. 2006 http://enum.nic.cz ENUM Nová dimenze telefonování CZ.NIC z.s.p.o. Pavel Tůma / pavel.tuma@nic.cz 22. 11. 2006 http://enum.nic.cz 1 Obsah Co je ENUM Jak funguje User ENUM Infrastructure ENUM Co je potřeba Výhody a přínosy

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt. C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt

Více

Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace DNS

Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace DNS Aplikační vrstva Přístup k transportní vrstvě z vrstvy aplikační rozhraní služeb služby pro systémové aplikace, služby pro uživatelské aplikace RIP DNS TELNET HTTP SNMP RTP SMTP FTP port UDP TCP IP 1 Aplikační

Více

Pravidla registrace doménových jmen v cctld.cz

Pravidla registrace doménových jmen v cctld.cz Pravidla registrace doménových jmen v cctld.cz V platnosti od 1.10.2007 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

Pravidla komunikace LRR

Pravidla komunikace LRR Pravidla komunikace LRR Verze 20040801 V platnosti od 1.8.2004 0. OBSAH 1. Úvodní ustanovení 2. Subjekty 3. Registrace Doménového jména 4. Prodloužení registrace Doménového jména 5. Změna údajů subjektů

Více

Úvod do informatiky 5)

Úvod do informatiky 5) PŘEHLED PŘEDNÁŠKY Internet Protokol a služba Jmenná služba (DNS) URL adresa Elektronická pošta Přenos souborů (FTP) World Wide Web (WWW) Téměř zapomenuté služby 1 INTERNET 2 PROTOKOL A SLUŽBA Protokol

Více

Obchodní podmínky společnosti GTS Czech s.r.o. pro registraci doménových jmen v síti Internet (dále jen Pravidla registrace )

Obchodní podmínky společnosti GTS Czech s.r.o. pro registraci doménových jmen v síti Internet (dále jen Pravidla registrace ) Obchodní podmínky společnosti GTS Czech s.r.o. pro registraci doménových jmen v síti Internet (dále jen Pravidla registrace ) 1. ÚVODNÍ USTANOVENÍ 1.1. Tato Pravidla registrace stanoví pravidla pro registraci

Více

Počítačové sítě Aplikační vrstva Domain Name System (DNS)

Počítačové sítě Aplikační vrstva Domain Name System (DNS) Aplikační vrstva Domain Name System (DNS) DNS je distribuovaná databáze, kterou používají TCP/IP aplikace k mapování doménových jmen do IP adres (a naopak) DNS informace jsou rozprostřeny po množině DNS

Více

Systém elektronického rádce v životních situacích portálu www.senorady.cz

Systém elektronického rádce v životních situacích portálu www.senorady.cz Systém elektronického rádce v životních situacích portálu www.senorady.cz Obec Senorady Miroslav Patočka 2006 Obsah: 1. Úvodní informace 1.1 Informace pro uživatele 1.1.1 Přístupnost HTML, PDA, WAP, XML

Více

MojeID: Pravidla motivačního programu pro poskytovatele služeb

MojeID: Pravidla motivačního programu pro poskytovatele služeb MojeID: Pravidla motivačního programu pro poskytovatele služeb V platnosti od 1. 3. 2015 1 Vyhlašovatel CZ.NIC, z. s. p. o. Milešovská 5, 130 00 Praha 3 IČ: 67985726 DIČ: CZ67985726 Zapsáno ve spolkovém

Více

DNS, DHCP DNS, Richard Biječek

DNS, DHCP DNS, Richard Biječek DNS, DHCP Richard Biječek DNS (Domain Name System) Překlady názvů hostname Informace o službách (např. mail servery) Další služby (zpětné překlady, rozložení zátěže) Hlavní prvky DNS: DNS server(y) DNS

Více

Windows Server 2003 Active Directory

Windows Server 2003 Active Directory Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,

Více

Provozní manuál DNSSec pro registr.cz a 0.2.4.e164.arpa

Provozní manuál DNSSec pro registr.cz a 0.2.4.e164.arpa Provozní manuál DNSSec pro registr.cz a 0.2.4.e164.arpa verze 1.9., platná od 1.1.2010 Úvod Tento materiál určuje provozní pravidla, kterými se řídí sdružení CZ.NIC při správě DNSSEC klíčů, konkrétně postupy

Více

Pravidla registrace doménových jmen v cctld.cz

Pravidla registrace doménových jmen v cctld.cz Pravidla registrace doménových jmen v cctld.cz V platnosti od 30.9.2008 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

Pravidla registrace doménových jmen v ENUM

Pravidla registrace doménových jmen v ENUM Pravidla registrace doménových jmen v ENUM V platnosti od 1.10.2007 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé a dalších úrovní pod doménou.0.2.4.e164.arpa

Více

FRED & PostgreSQL. CZ.NIC, z.s.p.o. Jaromír Talíř 13. 2. 2008 http://www.nic.cz/ http://fred.nic.cz

FRED & PostgreSQL. CZ.NIC, z.s.p.o. Jaromír Talíř <jaromir.talir@nic.cz> 13. 2. 2008 http://www.nic.cz/ http://fred.nic.cz FRED & PostgreSQL CZ.NIC, z.s.p.o. Jaromír Talíř 13. 2. 2008 http://www.nic.cz/ http://fred.nic.cz 1 Obsah FRED co to je? Architektura systému, datový model, transakční model Komunikace

Více

Úvod do informačních služeb Internetu

Úvod do informačních služeb Internetu Úvod do informačních služeb Internetu Rozdělení počítačových sítí Počítačové sítě se obecně rozdělují do základních typů podle toho, na jak velkém území spojují počítače a jaké spojovací prostředky k tomu

Více

Celosvětová síť Internet. IKT pro PD1

Celosvětová síť Internet. IKT pro PD1 Celosvětová síť Internet IKT pro PD1 Síť Internet Internet - celosvětová síť navzájem propojených počítačů, nebo specializovaných zařízení. Propojuje instituce nejrůznější povahy i soukromé osoby. Umožňuje

Více

Inovace výuky prostřednictvím šablon pro SŠ

Inovace výuky prostřednictvím šablon pro SŠ Název projektu Číslo projektu Název školy Autor Název šablony Název DUMu Stupeň a typ vzdělávání Vzdělávací oblast Vzdělávací obor Tematický okruh Inovace výuky prostřednictvím šablon pro SŠ CZ.1.07/1.5.00/34.0748

Více

Statutární město Most. Odbor informačního systému. Oddělení správy PC sítě. Systém ENUM pro bezplatné telefonování na Magistrát města Mostu

Statutární město Most. Odbor informačního systému. Oddělení správy PC sítě. Systém ENUM pro bezplatné telefonování na Magistrát města Mostu Statutární město Most Odbor informačního systému Oddělení správy PC sítě Systém ENUM pro bezplatné telefonování na Magistrát města Mostu Radim M lejnek 2009 Osnova Úvod...3 Co je vlastně ENUM?...4 Jak

Více

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5 Funkční specifikace ABOKWS Aplikační rozhraní elektronického bankovnictví ABO-K Verze 0.5 Přehled změn Verze Datum Změnil Popis 0.1 26.2.2013 MB Úvod, Osnova dokumentu, funkce ABOKWS 0.2 18.4.2014 MB Tabulky

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Při prvním přihlášení Vás program vyzve ke změně úvodního hesla.

Při prvním přihlášení Vás program vyzve ke změně úvodního hesla. Návod na používání helpdeskového systému HELP.i. Požadavky směrované na podporu produktů firmy DATACENTRUM systems & consulting, a.s., jsou evidovány v aplikaci HELP.i. V systému jsou evidovány požadavky,

Více

DNS. Počítačové sítě. 11. cvičení

DNS. Počítačové sítě. 11. cvičení DNS Počítačové sítě 11. cvičení Úvod k DNS (Domain Name System) Jmenná služba používaná v Internetu Mapuje doménová jména na IP adresy a naopak Komunikace probíhá nad UDP (port 53), pro velké požadavky/odpovědi

Více

db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka

db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka db-direct internet Customer Self Administration (vlastní správa uživatelů) Uživatelská příručka Deutsche Bank, pobočka Praha Verze 8.2 červenec 2009 Obsah Obsah... 1 Úvod... 2 Detailní popis... 3 Zavedení

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci l Kontakt s klientem SSP automatizované komunikace s ÚP ČR v součinnosti a exekuci Obsah: 1. SEZNAM POUŽITÝCH ZKRATEK... 3 2. POPIS SLUŽBY... 4 2.1 Forma a struktura rozhraní... 4 2.2 Dostupnost služby...

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] implementace přenosu informace o doručení SMS verze 166 / 1.3.2012 1 Obsah 1 Implementace platebního systému 3 1.1 Nároky platebního systému na klienta 3 1.2 Komunikace

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Pravidla pro zveřejňování informací o doménových jménech.eu (WHOIS)

Pravidla pro zveřejňování informací o doménových jménech.eu (WHOIS) Pravidla pro zveřejňování informací o doménových jménech.eu (WHOIS) 1/7 DEFINICE Pojmy definované v Podmínkách a/nebo v Pravidlech řešení sporů týkajících se domén.eu se zde používají s velkým písmenem.

Více

Validace souborů DS3

Validace souborů DS3 Validace souborů DS3 Verze: 1.33 1. Rozsah...1 1.1 Identifikace systému...1 1.2 Přehled systému...1 2. Přehled verzí a změny v nich...1 3. Použité dokumenty...2 4. Shrnutí údajů o programovém vybavení...4

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Domain Name System (DNS)

Domain Name System (DNS) Domain Name System (DNS) Co je DNS RFC 1034, 1035 řeší vzájemné převody mezi jmény a IP adresami rozšířeno na distribuovanou databází informací jména nemají žádnou vazbu s topologií sítě hierarchická struktura

Více

Věc: Dodatečné / upřesňující informace k zadávacím podmínkám a prodloužení lhůty pro podání nabídek

Věc: Dodatečné / upřesňující informace k zadávacím podmínkám a prodloužení lhůty pro podání nabídek K č. j.: 1051/2013 Dodatečné informace číslo: 1 Věc: Dodatečné / upřesňující informace k zadávacím podmínkám a prodloužení lhůty pro podání nabídek Veřejná zakázka: Název: Dodávka řešení softwarových videokonferenčních

Více

Nová áplikáce etesty Př í přává PC ž ádátele

Nová áplikáce etesty Př í přává PC ž ádátele Nová áplikáce etesty Př í přává PC ž ádátele Verze 0.6 Datum aktualizace 20. 12. 2014 Obsah 1 Příprava PC žadatele... 2 1.1 Splnění technických požadavků... 2 1.2 Prostředí PC pro žadatele... 2 1.3 Příprava

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 Zadavatel: Česká republika Ministerstvo životního prostředí Sídlo: Vršovická 1442/65, 100 10 Praha 10 IČO: 00164801 Jednající: Název veřejné zakázky: Ing.

Více

Internet. Počítačová síť, adresy, domény a připojení. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie

Internet. Počítačová síť, adresy, domény a připojení. Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie Internet Počítačová síť, adresy, domény a připojení Mgr. Jan Veverka Střední odborná škola sociální Evangelická akademie Počítačová síť počítačová síť = označení pro několik navzájem propojených počítačů,

Více

On-line dražební systém EDEN návod k použití

On-line dražební systém EDEN návod k použití On-line dražební systém EDEN návod k použití Obsah dokumentu 1. Registrace uživatele... 2 2. Verifikace (ověření) e-mailu... 3 3. Zapomenuté heslo... 3 4. Přihlášení uživatele... 4 5. Změna hesla... 5

Více

Zkrácení zápisu dvojitou dvojtečkou lze použít pouze jednou z důvodu nejednoznačnosti interpretace výsledného zápisu adresy.

Zkrácení zápisu dvojitou dvojtečkou lze použít pouze jednou z důvodu nejednoznačnosti interpretace výsledného zápisu adresy. Vlastnosti IPv6 (I) Minulé díly seriálu IPv6 vysvětlily proč se IPv4 blíží ke svému konci aže jeho nástupcem je nový Internetový Protokol verze 6 (IPv6). Tématem dnešního dílu jsou vlastnosti IPv6 protokolu.

Více

Roční periodická zpráva projektu

Roční periodická zpráva projektu WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových

Více

DNSSEC Validátor - doplněk prohlížečů proti podvržení domény

DNSSEC Validátor - doplněk prohlížečů proti podvržení domény DNSSEC Validátor - doplněk prohlížečů proti podvržení domény CZ.NIC z.s.p.o. Martin Straka / martin.straka@nic.cz Konference Internet a Technologie 12 24.11.2012 1 Obsah prezentace Stručný úvod do DNS

Více

TRANSPORTY výbušnin (TranV)

TRANSPORTY výbušnin (TranV) TRANSPORTY výbušnin (TranV) Ze zákona vyplývá povinnost sledování přeprav výbušnin. Předpokladem zajištění provázanosti polohy vozidel v čase a PČR je poskytování polohy vozidla předepsaným způsobem. Komunikace

Více

24 Uživatelské výběry

24 Uživatelské výběry 24 Uživatelské výběry Uživatelský modul Uživatelské výběry slouží k vytváření, správě a následnému používání tématicky seskupených osob a organizací včetně jejich kontaktních údajů. Modul umožňuje hromadnou

Více

Úvod do Web Services

Úvod do Web Services Úvod do Web Services Základy webových služeb a jejich implementace na platformě OS/2 Jarda Kačer jarda@kacer.biz Český Warpstock 2008 Brno, 20.-21.9.2008 Co je to webová služba? Část business logiky přístupná

Více

Výzvy jsou zasílány za účelem registrace domény, prodloužení domény, transfér domény s prodloužením nebo

Výzvy jsou zasílány za účelem registrace domény, prodloužení domény, transfér domény s prodloužením nebo Verze dokumentu 0.1, 16.3.2004 Řádky pro automatické zpracování e-mailů 1. Výzvy k platbě Výzvy k platb ě jsou zasílány z e-mailové adresy billing@generalregistry.cz na adresu plátce (pole Email ve formuláři

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Příručka uživatele HELPDESK GEOVAP

Příručka uživatele HELPDESK GEOVAP HELPDESK GEOVAP verze 1.2 11.11.2008 OBSAH 1 REGISTRACE DO HELPDESK...1 2 PŘIHLÁŠENÍ A ODHLÁŠENÍ...1 3 ZÁKLADNÍ OBRAZOVKA HELPDESK...2 4 PŘEHLED HLÁŠENÍ...2 5 ZALOŽENÍ NOVÉHO HLÁŠENÍ...3 6 ZOBRAZENÍ/EDITACE

Více

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ

MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ MATLABLINK - VZDÁLENÉ OVLÁDÁNÍ A MONITOROVÁNÍ TECHNOLOGICKÝCH PROCESŮ M. Sysel, I. Pomykacz Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky Nad Stráněmi 4511, 760 05 Zlín, Česká republika

Více

POKYNY K REGISTRACI PROFILU ZADAVATELE

POKYNY K REGISTRACI PROFILU ZADAVATELE POKYNY K REGISTRACI PROFILU ZADAVATELE Stav ke dni 4. 12. 2012 Obsah: 1 Úvod... 3 1.1 Podmínky provozu... 3 1.2 Pokyny k užívání dokumentu... 3 2 Registrace profilu zadavatele... 4 2.1 Přihlášení uživatele...

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Bezdrátové routery LTE & UMTS datové a hlasové brány

Bezdrátové routery LTE & UMTS datové a hlasové brány Bezdrátové routery LTE & UMTS datové a hlasové brány Jak na to? Základní nastavení www.2n.cz 1. Základní nastavení V tomto dokumentu si popíšeme jak jednoduše nastavit základní funkci 2N SpeedRoute nebo

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

Audit bezpečnosti počítačové sítě. Předmět: Správa počítačových sítí Jiří Kalenský kalenj1@fel.cvut.cz

Audit bezpečnosti počítačové sítě. Předmět: Správa počítačových sítí Jiří Kalenský kalenj1@fel.cvut.cz Audit bezpečnosti počítačové sítě Předmět: Správa počítačových sítí Jiří Kalenský kalenj1@fel.cvut.cz Zadání Prověřit bezpečnost v dané počítačové síti (cca 180 klientských stanic) Nejsou povoleny destruktivní

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje:

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje: MET-01/2014 METODIKA SZR-56-1/OPICT-2013 počet stran 28 přílohy 0 Chybová hlášení Gestor, podpis: Ing. Radovan Pártl Zpracovatel, podpis: RNDr. Miroslav Šejdl Odborný garant, podpis: RNDr. Miroslav Šejdl

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] popis platební metody MTSMS a průběhu platby verze / 9..0 Obsah Přehled platebních metod. MTSMS. MTSMS [erotický obsah] Průběh platby. Platba s přesměrování na platební

Více

Webové rozhraní pro datové úložiště. Obhajoba bakalářské práce Radek Šipka, jaro 2009

Webové rozhraní pro datové úložiště. Obhajoba bakalářské práce Radek Šipka, jaro 2009 Webové rozhraní pro datové úložiště Obhajoba bakalářské práce Radek Šipka, jaro 2009 Úvod Cílem práce bylo reimplementovat stávající webové rozhraní datového úložiště MU. Obsah prezentace Úložiště nasazené

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

File Transfer Protocol (FTP)

File Transfer Protocol (FTP) File Transfer Protocol (FTP) protokol pro přenos souborů, jeden z klasických RFC 959 přehled specifikací na http://www.wu-ftpd.org/rfc/ opět architektura klient-server navržen s ohledem na efektivní využívání

Více

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ

KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KAPITOLA 2 - ZÁKLADNÍ POJMY INFORMAČNÍCH A KOMUNIKAČNÍCH TECHNOLOGIÍ KLÍČOVÉ POJMY Internet World Wide Web FTP, fulltext e-mail, IP adresa webový prohlížeč a vyhledávač CÍLE KAPITOLY Pochopit, co je Internet

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

SSL Secure Sockets Layer

SSL Secure Sockets Layer SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

STRUČNÝ NÁVOD K POUŽITÍ

STRUČNÝ NÁVOD K POUŽITÍ STRUČNÝ NÁVOD K POUŽITÍ REPOTEC RP-IP0613 Úvod Bandwidth manager REPOTEC (dále jen BM) je levný a jednoduchý omezovač rychlosti pro jakékoliv sítě založené na protokolu TCP/IP. Velice snadno se ovládá

Více

národních domén.cz, ENUM domén a kontaktů pro tyto domény

národních domén.cz, ENUM domén a kontaktů pro tyto domény Popis emailového API pro automatickou registraci národních domén.cz, ENUM Dokument popisuje formát e-mailových zpráv pro automatickou registraci národních domén.cz, ENUM domén (v zóně 0.2.4.e164.arpa)

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen.

9. Systém DNS. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si problematiku struktury a tvorby doménových jmen. 9. Systém DNS Studijní cíl Představíme si problematiku struktury a tvorby doménových jmen. Doba nutná k nastudování 1,5 hodiny Uvedená kapitola vychází ze zdroje [1]. Celý Internet je z hlediska pojmenovávání

Více

Reranking založený na metadatech

Reranking založený na metadatech České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Reranking založený na metadatech MI-VMW Projekt IV - 1 Pavel Homolka Ladislav Kubeš 6. 12. 2011 1

Více

Datum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží

Datum vytvoření. Vytvořeno 18. října 2012. Očekávaný výstup. Žák chápe pojmy URL, IP, umí vyjmenovat běžné protokoly a ví, k čemu slouží Číslo projektu CZ.1.07/1.5.00/34.0394 Škola SOŠ a SOU Hustopeče, Masarykovo nám. 1 Autor Ing. Miriam Sedláčková Číslo VY_32_INOVACE_ICT.3.01 Název Teorie internetu- úvod Téma hodiny Teorie internetu Předmět

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 35.240.60 materiálem o normě. Systémy dopravních informací a řídicí systémy (TICS) Datová rozhraní

Více

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ

Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ Zápočtová úloha z předmětu KIV/ZSWI DOKUMENT SPECIFIKACE POŽADAVKŮ 10. 5. 2011 Tým: Simplesoft Členové: Zdeněk Malík Jan Rada Ladislav Račák Václav Král Marta Pechová malikz@students.zcu.cz jrada1@students.zcu.cz

Více

Pravidla registrace domén EU registrátora ZONER software, s.r.o. pro objednávky před a v období Sunrise period

Pravidla registrace domén EU registrátora ZONER software, s.r.o. pro objednávky před a v období Sunrise period Pravidla registrace domén EU registrátora ZONER software, s.r.o. pro objednávky před a v období Sunrise period OBSAH 1. VYMEZENÍ POJMŮ...2 2. PŘEDMĚT A ROZSAH PRAVIDEL...2 3. OMEZENÍ ŽÁDOSTÍ NA DOMÉNOVÁ

Více

Analýza aplikačních protokolů

Analýza aplikačních protokolů ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická PROJEKT Č. 4 Analýza aplikačních protokolů Vypracoval: V rámci předmětu: Jan HLÍDEK Komunikace v datových sítích (X32KDS) Měřeno: 28. 4. 2008

Více

Publikování map na webu - WMS

Publikování map na webu - WMS Semestrální práce z předmětu Kartografická polygrafie a reprografie Publikování map na webu - WMS Autor: Ondřej Dohnal, Martina Černohorská Editor: Filip Dvořáček Praha, duben 2010 Katedra mapování a kartografie

Více

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí,

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí, 9. Sítě MS Windows MS Windows existoval ve 2 vývojových větvích 9x a NT, tyto později byly sloučeny. V současnosti existují aktuální verze Windows XP a Windows 2003 Server. (Očekává se vydání Windows Vista)

Více

Active Directory organizační jednotky, uživatelé a skupiny

Active Directory organizační jednotky, uživatelé a skupiny Active Directory organizační jednotky, uživatelé a skupiny V databázi Active Directory jsou uloženy objekty organizačních jednotek, uživatelských účtů a skupin. Organizační jednotka představuje jakýsi

Více

Informatika. 20 Internet

Informatika. 20 Internet Informatika 20 Internet Karel Dvořák 2011 Internet Internet je celosvětový systém navzájem propojených počítačových sítí, ve kterých mezi sebou počítače komunikují pomocí rodiny protokolů TCP/IP. Společným

Více

Český telekomunikační úřad Praha 31. ledna 2003 se sídlem Sokolovská 219, Praha 9 Č.j.: 6569/2003-610

Český telekomunikační úřad Praha 31. ledna 2003 se sídlem Sokolovská 219, Praha 9 Č.j.: 6569/2003-610 Český telekomunikační úřad Praha 31. ledna 2003 se sídlem Sokolovská 219, Praha 9 Č.j.: 6569/2003-610 Český telekomunikační úřad (dále jen Úřad ) jako příslušný orgán státní správy podle 95 bodu 6 písm.

Více

ČESKÁ TECHNICKÁ NORMA

ČESKÁ TECHNICKÁ NORMA ČESKÁ TECHNICKÁ NORMA ICS 35.040 2008 Informační technologie - Registry metadat (MDR) - Část 5: Principy identifikace a tvorby názvů dat ČSN ISO/IEC 11179-5 97 9736 Srpen Information technology - Metadata

Více

Pravidla registrace doménových jmen v cctld.cz

Pravidla registrace doménových jmen v cctld.cz Pravidla registrace doménových jmen v cctld.cz V platnosti od 1.12.2012 1. ÚVODNÍ USTANOVENÍ 1.1. Tento dokument stanoví pravidla pro registraci a delegaci Doménových jmen druhé úrovně pod cctld.cz. 1.2.

Více

Smluvní podmínky pro užívání a správu domén ".sk" u spol. General Registry. Provozovatel. 1. Základní ujednání

Smluvní podmínky pro užívání a správu domén .sk u spol. General Registry. Provozovatel. 1. Základní ujednání u spol. General Registry Provozovatel Provozovatelem jsou v následujícím dokumentu myšleny společnosti: 1. General Registry, s.r.o. Žižkova 1 370 01 České Budějovice Česká republika IČ: 26027267 DIČ:CZ26027267

Více

Počítačové sítě. Počítačová síť. VYT Počítačové sítě

Počítačové sítě. Počítačová síť. VYT Počítačové sítě Počítačové sítě Počítačová síť Je soubor technických prostředků, které umožňují spojení mezi počítači a výměnu informací prostřednictvím tohoto spojení. Postupný rozvoj během druhé poloviny 20. století.

Více

Integrace datových služeb vědecko- výukové

Integrace datových služeb vědecko- výukové České vysoké učení technické v Praze Fakulta elektrotechnická Software Engineering & Networking Projekt Fondu rozvoje sdružení CESNET- 513/2014/1 HS: 13144 / 830 / 8301442C Integrace datových služeb vědecko-

Více

Hot Standby Router Protocol (zajištění vysoké spolehlivosti výchozí brány)

Hot Standby Router Protocol (zajištění vysoké spolehlivosti výchozí brány) České vysoké učení technické v Praze Fakulta elektrotechnická Moderní technologie Internetu Hot Standby Router Protocol (zajištění vysoké spolehlivosti výchozí brány) Abstrakt Popis jednoho z mechanizmů

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Prezentace CRMplus Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Obsah prezentace Představení společnosti Technodat Develop, s.r.o. CRMplus základní charakteristika

Více

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] popis platebních metod PRSMS a průběhu platby verze 17 / 29.2.2012 1 Obsah 1 Přehled platebních metod 3 1.1 Premium rate SMS 3 1.2 Premium rate SMS [erotický obsah] 3

Více

Administrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě. (ve znění platném k 1.

Administrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě. (ve znění platném k 1. Administrativní pokyny pro aplikaci Madridské dohody o mezinárodním zápisu známek a Protokolu k této dohodě (ve znění platném k 1. lednu 2008) OBSAH První část: Definice Kapitola 1: Zkrácené výrazy,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,1

Více

Informační systém ozdravných pobytů zdravotní pojišťovny

Informační systém ozdravných pobytů zdravotní pojišťovny Úvod ní studie @fel.cvut.cz Téma bakalářské práce: Informační systém ozdravných pobytů zdravotní pojišťovny Pokyny pro vypracování: Analyzujte IS ozdravných pobytů dětí a mládeže obecné zdravotní pojišťovny.

Více

Stručný průvodce aplikací Sběr dat pro CEP a CEZ

Stručný průvodce aplikací Sběr dat pro CEP a CEZ Stručný průvodce aplikací Sběr dat pro CEP a CEZ (verze 1.0) Rada pro výzkum a vývoj Úřad vlády ČR Určeno necertifikovanému dodavateli dat RVV 2003 1. Vstup do aplikace Informace pro uživatele, uživatelské

Více

Lokality a uživatelé

Lokality a uživatelé Administrátorský manuál TTC TELEKOMUNIKACE, s.r.o. Třebohostická 987/5 100 00 Praha 10 tel.: 234 052 111 fax.: 234 052 999 e-mail: ttc@ttc.cz http://www.ttc-telekomunikace.cz Datum vydání: 15.října 2013

Více