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

ˇ Ceské vysoké uˇcení technické v Praze Fakulta elektrotechnická

ˇ VUT FEL katedra pocˇı´tacˇu˚ C

Diplomová práce

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

Vedoucí práce: Jan Kubr

Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpoˇcetní technika Leden 2007

Podˇekování Dˇekuji rodiˇcu˚ m za všestrannou podporu po dobu mého studia.

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatnˇe a použil jsem pouze podklady uvedené v pˇriloženém seznamu. Nemám závažný d˚uvod proti užití tohoto školního díla ve smyslu §60 Zákona cˇ . 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zmˇenˇe nˇekterých zákon˚u (autorský zákon).

V Praze dne 18.1. 2007

..........................................................................................

Abstrakt Tento dokument vychází z roˇcní práce autora na tvorbˇe registraˇcního systému internetových domén pro sdružení CZ.NIC. Za jeden rok se systém podaˇrilo vybudovat a úspˇešnˇe nasadit do provozu. Ovšem nejedná se pouze o dokumentaci k technickému rˇešení projektu. Práce si klade za cíl seznámit cˇ tenáˇre s novým internetovým protokolem EPP (Extensible Provisioning Protocol), jehož implementace je souˇcástí rˇešení, a ENUM (Telephone Number Mapping) standardem. Projekt je tím zajímavˇejší, že je uvolnˇen pod svobodnou licencí a oˇcekává se jeho rozšíˇrení po svˇetˇe.

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.

10

Obsah

1

Úvod

15

1.1

Registr domén: definice a úˇcel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2

Registr cˇ eské národní domény CZ.NIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2

Motivace a požadavky na nový registr

19

3

EPP

21

4

5

3.1

EPP objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2

Model transferu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3

Nasazení EPP v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

ENUM 4.1

Pˇrizp˚usobení registru pro správu ENUM domén . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2

ENUM doma a ve svˇetˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Architektura systému 5.1

5.2

5.3

5.4 6

33

37

fred_rif, fred_pif a fred_admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.1

fred_rif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.2

fred_pif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.3

fred_adif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

pyfred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.1

genzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2

filemanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.3

mailer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.4

techcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

mod_eppd a mod_whoisd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.3.1

mod_whoisd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3.2

mod_eppd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

epp_client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Závˇer

59

6.1

Vymezení práce autora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2

Možná budoucí vylepšení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

11

12

OBSAH

A Výbˇer databáze

61

B CORBA

63

C O tomto dokumentu

65

D CD pˇrílohy

67

E Bibliografie

69

Seznam tabulek

4.1

Stav ENUM registrací dle stát˚u. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1

Výˇcet technických test˚u a jejich úrovní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.1 Databáze používané v ostatních registrech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.2 Výsledky testu rychlosti databáze ORACLE a PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

13

14

SEZNAM TABULEK

Kapitola 1

Úvod

V této kapitole se lehce seznámíme s prostˇredím registru doménových jmen a jeho úlohou v systému doménových jmen (DNS). Po získání tˇechto základních vˇedomostí krátce pˇredstavíme registr cˇ eské národní domény CZ.NIC, na jehož p˚udˇe je projekt vyvíjen. Poté pˇredstavíme základní body motivace k vytvoˇrení nového registraˇcního systému doménových jmen. Pˇred cˇ ástí popisující implementaci systému, jsou dvˇe spíše teoretické cˇ á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ˇe analýzy tohoto protokolu se pak zaˇcal navrhovat datový model registru. Dílˇcí zamyšlení a zhodnocení cˇ ástí implementace je obsaženo v jednotlivých kapitolách, pˇresto v závˇeru je zhodnocení implementace jako celku a neménˇe zajímavý je pohled do budoucna, co se týká registraˇcního systému.

ˇ 1.1 Registr domén: definice a úcel

Registr domén, v angliˇctinˇe cˇ asto nazýván jako Network Information Center, je souˇcástí systému doménových jmen. Jeho úkolem je pˇrevádˇet doménová jména na IP adresy. Je pˇredstavován organizací, která m˚uže být komerˇcního nebo neziskového charakteru. Domény se dˇelí do dvou základních skupin: generické domény a národní domény. Za pˇridˇelování domén do nˇecˇ í správy zodpovídá IANA (Internet Assigned Numbers Authority), která je zároveˇn správcem root nameserver˚u, což je vrchol v hierarchii doménových jmen. Dále je IANA správcem .arpa domény, která slouží k administraˇcním úˇcel˚um (napˇr. pˇreklad IP adres na doménová jména, tzv. reverse-mapping). Domény se registrují za poplatek, jehož výše je odvislá od spoleˇcnosti, která doménu spravuje a jiných okolností. Domény jsou registrovány v poˇradí, v kterém pˇrichá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

16

KAPITOLA 1. ÚVOD

Znázornˇení 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ˇe, 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ˇe.

V úzkovrstvém modelu je snaha co nejvíce poviností delegovat na tzv. registrátory, což jsou spoleˇcnosti, které poskytují registrace domén koncovým uživatel˚um. Na druhé stranˇe tyto zprostˇredkovatelské spoleˇcnosti platí poplatky, které jsou pochopitelnˇe 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ˇejším pˇrípadˇe v tomto modelu si registr potˇrebuje udržovat pouze u jaké spoleˇcnosti a na jak dlouho byla doména registrována a zbytek dat je schopen poskytnout registrátor. Napˇríklad doména .com je spravována tímto zp˚usobem.

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˚u. V nejkrajnˇejším pˇrípadˇe spojuje roli registru a registrátora, cˇ i-li pˇrímo umožˇnuje registrovat domény koncovým zákazník˚um bez zprostˇredkovatel˚u, nicménˇe je to vˇetšinou pouze alternativní nabídka vzhledem k ostatním registrátor˚um a nebývá pˇríliš výhodná. ˇ Nˇemecká národní doména spravovaná sdružením DENIC je pˇríkladem takového registru. Ceská doména donedávna také plnila funkci registrátora, to se ale s novým systémem mˇení.

Nˇekteré registry povolují národní znaky v názvech domén, napˇríklad polská národní doména. Vˇetšina registr˚u je v tomto smˇeru konzervativní a národní znaky nepovoluje. Odbornou veˇrejností jsou národní znaky zavrhovány. V RFC 2825 jsou shrnuty d˚uvody, kv˚uli kterým je dobré se národním znak˚um vyhnout.

Dalším možným kritériem pro klasifikaci registr˚u je, zda-li vynucují dvouúrovˇnové domény cˇ i nikoliv. Povinná doména na druhé úrovni pomáhá vyrovnat se lépe se sploštˇením prostoru doménových jmen. Pˇri návrhu systému doménových jmen se nepoˇcítalo s jeho masovým použitím zp˚usobem jakým se dnes používá. Poˇcítalo se, že doménový strom bude mít tvar pyramidy, cˇ ímž dojde k distribuci administrativní a výkonové zátˇeže. V praxi je úroveˇn pod nejvyšší doménou zoufale pˇrehuštˇená a úrovnˇe za druhou úrovní domén jsou nevyužívané. Registry, které vynucují použití domén na tˇretí úrovni, se snaží cˇ elit této nepˇríjemné situaci, nicménˇe jsou v menšinˇe. Pˇríkladem je britská národní doména.

ˇ 1.2. REGISTR CESKÉ NÁRODNÍ DOMÉNY CZ.NIC

17

Znázornˇení 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ˇn hned pod nejvyšší doménou je pˇrehuštˇena na úkor dalších úrovní (napravo). O problematice pˇretˇežování úrovní v DNS a obecnˇe "zneužívání" systému DNS k úˇcel˚um, ke kterým nebyl urˇcen, velmi zajímavˇe pojednává RFC 3467. Pro pˇrehlednost je zde uveden výklad pojm˚u, které se v textu hojnˇe používají a jejichž význam se m˚uže snadno zamˇenit. Registr Je organizace zodpovˇedná za správu domény. V užším slova smyslu to m˚uže znamenat softwarové a hardwarové vybavení, které správu domén zajišt’uje, nebo popˇrípadˇe jen databázi, kde jsou data, nutná pro správu, uložena. Registrátor Registrátor je spoleˇcnost, která zajišt’uje prodej domény koncovému zákazníkovi. Je to prostˇredník mezi registrem a registrantem. Registrant Registrant je koncový zákazník, který si doménu kupuje (nebo pˇresnˇeji ˇreˇceno pronajímá na urˇcité období).

ˇ 1.2 Registr ceské národní domény CZ.NIC Sdružení CZ.NIC bylo založeno v roce 1998 skupinou šestnácti poskytovatel˚u internetu. Jedná se o neziskovou organizaci, která je otevˇrena novým registrátor˚um. Je cˇ lenem uskupení CENTR (skupina evropských registr˚u národních domén), ve spolku s EURidem (registr pro .eu domény) a souˇcástí kritické infrastruktury cˇ eského státu. Systém organizace, druhy cˇ lenství a pravomoce jednotlivých orgán˚u jsou pomˇernˇe komplikované a jejich popis není cílem této práce. V souˇcasnosti CZ.NIC spravuje pˇres 250 tisíc domén s meziroˇcním nár˚ustem 50 tisíc domén za poslední rok. V roce 2004 zárovˇenˇ s výmˇenou vedení spoleˇcnosti byly nastartovány zásadní reformy dosavadního fungování registru, který byl po technické stránce kompletnˇe outsourcován. Nové vedení si vytyˇcilo ambiciózní cíle mezi kterými jsou: snížení koncové ceny domény, spuštˇení registace ENUM cˇ ísel a pˇrevedení outsourcovaného CZ registru pod správu CZ.NICu. Z uvedených cíl˚u vyplývá, že klíˇcovým úkolem je vývoj nového registru pro správu domén. Pokud bychom mˇeli klasifikovat registr cˇ eské národní domény dle dvou hledisek uvedených v pˇredchozí podkapitole, došli bychom k následujícím závˇer˚um: • Registr je širokovrstvý. Všechny informace o doménˇe jsou uloženy v registru. Whois dotaz je schopen podat plnou informaci o doménˇe. Nicménˇe role registrátor˚u jako prostˇredníka mezi registrem a registrantem je zachována. Všechny domény jsou v novém systému registrovány výhradnˇe pˇres registrátory - to je zmˇena vzhledem k pˇredchozímu fungování registru. • Registr nevynucuje klasifikaci domén na základˇe 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.

18

KAPITOLA 1. ÚVOD

Poznámka ˇ ˇ Ctenáˇ r by mohl mít oprávnenou námitku, že se v této práci vubec ˚ nezabýváme puvodním ˚ systémem pro správu .cz domén. Jisteˇ by to byl hodnotný zdroj zkušeností, které by pomohly pˇri implementaci nového registru. Bohužel o puvodním ˚ systému pro správu domén víme velmi málo, což má dva duvody: ˚ ˇrešení, které je šité na zakázku pro cˇ eskou doménu, má uzavˇrené zdrojové kódy a veˇrejneˇ dostupná dokumentace • Puvodní ˚ není žádná. ˇ • Neochota spoleˇcnosti, která za ˇrešením stojí a provozuje ho, sdílet jakékoliv informace o nem.

Dosluhující decentralizovaný systém správy domén je v provozu teprve od záˇrí roku 2003. Slovo decentralizovaný znamená, že správa je rozdˇelena mezi registr a registrátory tak, jak jsme si tento model popsali v minulé podkapitole. Komunikace s registrátory probíhala pˇres "protokol EPP", zde jsou uvozovky na místˇe, protože z formálního hlediska se nejedná o tento protokol, ale nˇeco, co je mu jen velmi podobné. Další zvláštností je, že transportní vrstvou je protokol SMTP zabezpeˇcený TLS, ovšem pro informaˇcní pˇrí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ˇe ještˇe draftem) nejsou dobrou vizitkou pro tento systém.

Kapitola 2

Motivace a požadavky na nový registr Motivace pro vybudování nového centrálního registru vyplývá z pˇredchozí kapitoly pojednávající o spoleˇcnosti CZ.NIC. V této kapitole si je doplníme o další specifiˇctˇejší požadavky. Tak získáme hrubou pˇredstavu o podobˇe nového registru. Open-source projekt Kód registru bude uvolnˇen pod svobodnou licencí (pravdˇepodobnˇe GPL). Oˇcekává se velký zájem zejména ze strany zemí tˇretího svˇeta, které tak mohou dostat do ruky hotové ˇrešení, mohou vyškolit své pracovníky pro ovládání registru a pˇrizp˚usobovat ho volnˇe svým potˇrebám. Otevˇrenost zdrojového kódu zvyšuje nároky na jeho bezpeˇcnost a kvalitu. V dobˇe zapoˇcetí projektu se jednalo o v˚ubec první kompletní open-source ˇrešení tohoto druhu. Uvolnˇení pod svobodnou, "infekˇcní licencí", jak je nˇekdy GPL nazývána, implikuje požadavek na použité knihovny, které musí být taktéž svobodné. ˇ Nezávislost na lokalitˇe nasazení Rešení musí obsahovat minimum vˇecí specifických pro cˇ eské podmínky. Ideálnˇe pˇrenesení registru do jiné zemˇe, by mˇelo znamenat jen zmˇenu konfigurace, nikoliv úsek˚u 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ˇcasných podmínkách v CZ.NICu musí být schopen spravovat jak zónu .cz tak ENUM zóny, o kterých bude ˇreˇc ještˇe pozdˇeji. Pˇridání další zóny do správy by mˇelo být otázkou nastavení konfigurace, bez nutnosti mˇenit zdrojový kód. Distribuované rˇ ešení Idea registru je, že se bude sestávat z více oddˇelených cˇ ástí, které spolu budou komunikovat pˇres dobˇre definované rozhraní. Jednotlivé cˇ ásti budou moci bˇežet na r˚uzných strojích. Tento návrh zajistí lepší pˇredpoklady pro zvládnutí složitosti problému a zároveˇn rozložení zátˇeže. Výkon Nový registr musí být schopen registrovat domény takovou rychlostí, aby staˇcil na provoz nejvytíženˇejších domén soucˇ asnosti. ˇ Podpora pro EPP protokol Rešení by mˇelo vyhovovat požadavk˚um EPP protokolu. EPP je relativnˇe nový protokol urˇcený pro komunikaci mezi registrem a registrátory. Ještˇe se k nˇemu vrátíme podrobnˇe pozdˇeji. V podstatˇe díky tomu, že je registr stavˇen na zelené louce, je možné celý registr navrhnout "kolem" EPP protokolu. Zjednodušení souˇcasného málo pˇrehledného modelu Ve starém systému existuje celkem devˇet kombinací druhu kontaktu a jeho role. Systém je takˇrka nepochopitelný pro koncového zákazníka. Registrátor ho od této složitosti cˇ ásteˇcnˇe odstiˇnuje, ale to není možné zcela. Nový model by mˇel být pr˚uhlednˇejší, snáze pochopitelnˇejší, což pˇrispˇeje jednak k omezení poˇctu nedorozumˇení s koncovým zákazníkem a jednak ke zjednodušení datového modelu. ˇ Omezený cˇ as na vývoj nového registru Casový harmonogram byl pevnˇe stanovený ve chvíli zapoˇcetí projektu. Pˇri vývoji se musí brát ohled na tyto termíny a pˇrizp˚usobit tomu rozhodnutí pˇri návrhu a implementaci.

19

20

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

Kapitola 3

EPP EPP (Extensible Provisioning Protocol) je internetový standard definovaný v RFC 3730 z roku 2004. Popisuje aplikaˇcní úroveˇn klient-server protokolu pro vytváˇrení a správu objekt˚u ve sdíleném centrálním repozitáˇri. Protokol je založen na XML a využívá XML namespac˚u, díky cˇ emuž je snadno rozšiˇritelný. Aˇc byl vytvoˇren za úˇcelem unifikace rozhraní pro komunikaci registru a registrátor˚u, mohou jím být spravovány jakékoliv objekty a nejen objekty specifické pro prostˇredí registru doménových jmen. EPP definuje dva druhy operací. Pˇríkazy, které se pˇrímo netýkají správy objekt˚u: hello Tento pˇríkaz m˚uže klient zadat kdykoliv a server na nˇej musí odpovˇedˇet takzvaným greeting rámcem. login Pˇrihlášení uživatele do systému. logout Odhlášení uživatele ze systému. poll Manipulace s došlými zprávami. Tento pˇríkaz má dvˇe varianty. Jedna varianta získá první zaˇrazenou zprávu od serveru a druhá varianta potvrzuje pˇríjem zprávy a vyˇrazuje pˇreˇctenou zprávu z fronty na stranˇe serveru. Zaˇrazení tohoto pˇríkazu mezi operace, které se pˇrímo netýkají objektu je diskutabilní, protože obsah zprávy se objektu týkat m˚uže. Druhou skupinou operací jsou pˇríkazy, které se pˇrímo týkají objekt˚u. check Zjištˇení registrovatelnosti objektu na základˇe jeho jména. Jedná se o jediný EPP pˇríkaz, kde se pracuje s více objekty najednou. Pro každý dotazovaný objekt server vrací stav: m˚uže být zaregistrován nebo nem˚uže být zaregistrován. Pokud nem˚uže, vrací server ještˇe d˚uvod, proˇc nem˚uže být zaregistrován. Tímto pˇríkazem si m˚uže napˇríklad klient pˇred 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ˇejaké vlastnosti (atributy), jinak by nemˇelo smysl ho spravovat. Napˇríklad u domény to m˚uže být doménové jméno, datum založení a vlastník domény. Pˇríkaz info vrací dostupné informace o objektu. Nˇekteré citlivé informace mohou být skryty v pˇrípadˇe, že klient, který se ptá nemá dostateˇcná práva. create Vytvoˇrení objektu. Na pˇríkladu domény je to zaregistrování doménového jména. delete Vymazání objektu. Na pˇrí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ˇena vlastníka objektu. Každý objekt má vlastníka, který se m˚uže mˇenit v pr˚ubˇehu existence objektu v registru. Vlastníkem zde myslíme registrátora, pˇres kterého je doména registrována, nikoliv držitele domény. update Zmˇena vlastností (atribut˚u) objektu. Ne každý atribut lze zmˇenit pˇres update. Napˇríklad vlastník resp. datum expirace jsou mˇenˇeny pˇres transfer resp. renew pˇríkazy.

21

22

KAPITOLA 3. EPP

ˇ Než budeme pokraˇcovat v popisu EPP, je vhodné vysvˇetlit, jaký je vztah EPP standardu a XML. Rekli jsme, že EPP je protokol založený na XML. To znamená, že vymˇenˇ ované zprávy mezi klientem a serverem jsou XML dokumenty. To si ukážeme na pˇríkladu nejjednodušího EPP pˇríkazu logout. Nejdˇríve klient pošle pˇríkaz serveru. <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"> ABC-12345

Jako první je klasická hlaviˇcka XML dokumentu, urˇcující jeho verzi a kódování. Atribut standalone rˇíká, jestli (ne)existuje externí definice XML dokumentu, v našem pˇrípadˇe je XML dokument definován XML schématem, což je externí definice, cˇ ili hodnota no je správná. Pak následuje element epp. To je koˇrenový element všech dokument˚u EPP. Pomocí atribut˚u tohoto elementu je definován defaultní namespace EPP, který se vztahuje na všechny potomky koˇrenového elementu, pokud nemají explicitnˇe uveden jiný namespace. Potomkem epp je element command, který urˇcuje, že se jedná o pˇríkaz. O jaký pˇríkaz se jedná urˇcuje hned následující element logout, který je doplnˇen o element clTRID, o kterém se zmíníme ještˇe pozdˇeji. Po zpracování pˇríkazu serverem, je vrácen klientovi jiný XML dokument (odpovˇed’). <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"> <msg>Command completed successfully; ending session ABC-12345 <svTRID>54321-XYZ

Odpovˇed se liší od pˇríkazu až u elementu response, který ˇríká, že se jedná o odpovˇed’ serveru. Tento element má potomky result, který obsahuje lidsky cˇ itelnou zprávu od serveru a návratový kód pˇríkazu 1500. Definice významu návratových kód˚u je souˇcástí EPP standardu. Odpovˇed’ obsahuje ještˇe identifikátory akce clTRID a svTRID. To co jsme na pˇredchozím pˇríkladu popsali slovy o poˇradí element˚u a jejich obsahu, je popsáno pˇresnˇe XML schématy. XML schémata popisují strukturu dokumentu a datové typy element˚u a atribut˚u. Samozˇrejmˇe 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˚u a atribut˚u. Popsat jejich význam je pˇredmˇetem textu EPP standardu.

Poznámka XML schémata nejsou jediným jazykem pro popis struktury XML dokumentu. Jeho pˇredchudcem ˚ je DTD (Document Type ˇ Definition), který se liší od schémat hlavneˇ tím, že k popisu struktury dokumentu používá jiný jazyk než XML. Druhá závažnejší nevýhoda je, že nepodporuje XML namespace, tudíž pro úˇcely definice EPP je nepoužitelný. XML schéma není jediný moderní jazyk pro popis struktury XML dokumentu, ˚ zdatneˇ mu konkuruje RELAX-NG, jehož popularita v poslední dobeˇ roste a který by mohl být použit pro popis EPP stejneˇ tak dobˇre jako XML schémata.

23

Jako objekt m˚uže v systému vystupovat cokoliv. Mapování operací definovaných standardem EPP na konktrétní objekty, je pˇredmˇetem 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ˇcovat v základní charakteristice EPP, vyjasníme si základní pojem používaný pˇri výkladu a to je rámec. Je to základní jednotka EPP komunikace. Oznaˇcuje XML dokument, který reprezentuje pˇríkaz klienta nebo odpovˇed’ serveru. EPP je challenge-response protokol, cˇ i-li pˇríkaz od klienta je vždy následován odpovˇedí od serveru. Server nikdy nic klientovi neposílá, pokud to není pˇrímou odpovˇedí na pˇríkaz od klienta. Vyjímku pˇredchozímu pravidlu tvoˇrí úvodní rámec novˇe navázaného spojení, kdy server odpovídá greeting rámcem bez toho, že by klient posílal jakýkoliv rámec pˇred tím. Greeting rámec slouží ke zprostˇredkování informací o serveru jako takovém (ˇcíslo verze EPP protokolu, podporované jazyky komunikace, spravované typy objekt˚u atd.). Klient poté vyšle login rámec, který obsahuje uživatelské jméno, heslo a preference uživatele. Tím konˇcí úvodní fáze komunikace a následují r˚uzné pˇríkazy, dle výbˇeru uživatele. Komunikace se ukonˇcuje pˇríkazem logout ze strany klienta. Server odpovídá potvrzením o úspˇešném zpracování pˇríkazu a tcp spojení je uzavˇreno obˇema ze stran.

Znázornˇení typického scénáˇre komunikace mezi klientem a serverem pˇres 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˚uzné sít’ové protokoly je pˇredmˇetem samostatných standard˚u. V souˇcasnosti 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ˇnovat jakékoliv mapovaní na sít’ový protokol. Kromˇe pˇredvídatelných požadavk˚u jako je doruˇcování dat v poˇradí, ve kterém jsou posílány, zaruˇcená spolehlivost doruˇcení dat, klade standard požadavky na integritu a d˚uvˇeryhodnost posílaných dat. To v mapování na TCP zaruˇcuje mezivrstva TLS (Transport Layer Security). EPP pˇríkazy jsou navržené tak, aby byly idempotentní, což znamená, že opakované vyvolání stejného pˇríkazu nˇekolikrát za sebou, nezmˇení stav objektu v repozitáˇri, to je d˚uležitá vlastnost.

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ˇredchází takzvaná hlaviˇcka, která má velikost cˇ tyˇri bajty a je v ní uložena délka XML dokumentu, který následuje. Tak pˇríjemce rámce ví pˇresnˇe kolik bajt˚u má pˇreˇcíst ze sít’ového socketu, aniž by musel jakkoliv parsovat XML dokument. Struktura XML dokument˚u 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ˇekolika používaných jednoduchých datových typ˚u, u kterých se pˇredpokládá, že budou sdíleny se schématy, které EPP protokol rozšiˇrují. Jakékoliv úpravy EPP, které by znamenaly zmˇenu tˇechto dvou schémat, nejsou kompatibilní a protokol, na nich postavený, nesmí být názvem EPP oznaˇcován. Pˇresný popis struktury XML dokument˚u a význam informací v nich obsažených je pˇredmˇetem EPP standardu, nicménˇe pro pˇredstavu 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ˇcky rámc˚u s jejich délkou. Zde uvedená komunikace se skládá ze cˇ tyˇr rámc˚u - pˇríkaz˚u login, logout a pˇríslušných odpovˇedí na nˇe a jsou pˇrevzaté z RFC 3730. C: 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: C: C: ClientX C: foo-BAR2 C: bar-FOO2 C: C: 1.0 C: en C: C: <svcs> C: urn:ietf:params:xml:ns:obj1 C: urn:ietf:params:xml:ns:obj2 C: urn:ietf:params:xml:ns:obj3 C: <svcExtension> C: <extURI>http://custom/obj1ext-1.0 C: C: C: C: ABC-12345 C: C: S: 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: S: S: <msg>Command completed successfully S: S: S: ABC-12345 S: <svTRID>54321-XYZ S: S: S: C: 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

25

C: epp-1.0.xsd"> C: C: 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 C: C: C: ABC-12345 C: C: S: 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: S: S: <msg>Command completed successfully S: S: 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 S: <domain:roid>EXAMPLE1-REP S: <domain:status s="ok"/> S: <domain:registrant>jd1234 S: <domain:contact type="admin">sh8013 S: <domain:contact type="tech">sh8013 S: <domain:ns> S: <domain:hostObj>ns1.example.com S: <domain:hostObj>ns1.example.net S: S: <domain:host>ns1.example.com S: <domain:host>ns2.example.com S: <domain:clID>ClientX S: <domain:crID>ClientY S: <domain:crDate>1999-04-03T22:00:00.0Z S: <domain:upID>ClientX S: <domain:upDate>1999-12-03T09:00:00.0Z S: <domain:exDate>2005-04-03T22:00:00.0Z S: <domain:trDate>2000-04-08T09:00:00.0Z S: <domain:authInfo> S: <domain:pw>2fooBAR S: S: S: S: S: ABC-12345 S: <svTRID>54322-XYZ S: S: S: C: C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

26

KAPITOLA 3. EPP

C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: C: C: ABC-12345 C: C: S: 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: S: S: <msg>Command completed successfully; ending session S: S: S: ABC-12345 S: <svTRID>54321-XYZ S: S: S:

Na pˇríkladech je pozoruhodný element clTRID a svTRID. Jedná se o identifikátory požadavk˚u. Požadavkem máme zde na mysli rámec, který obsahuje pˇríkaz klienta, spoleˇcnˇe s rámcem, který obsahuje odpovˇed’ serveru. clTRID je identifikátor požadavku pˇridˇelený klientem a je volitelný. Server musí tento identifikátor uvést ve své odpovˇedi a navíc povinnˇe pˇriˇradí odpovˇedi sv˚uj identifikátor svTRID, který identifikuje jednoznaˇcnˇe požadavek v historii všech požadavk˚u vyslaných na server od všech klient˚u. Zajímavá je zejména prostˇrední cˇ ást komunikace, kde klient zadává pˇríkaz info a ptá se jím na doménu example.com. Server v odpovˇedi vrací informace vedené o doménˇe example.com v registru. Tento úryvek komunikace je ukázkou mapování objektu do EPP, o cˇ emž bude ˇreˇc v pˇríš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ˇelali, a vytvoˇrili tak vlastní namespace napˇríklad urn:namespace:ident. Vypadal by pˇríkaz na vypsání informací o našem objektu doména následovnˇe: <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"> <domain:info xmlns:domain="urn:namespace:ident" xsi:schemaLocation="urn:namespace:ident ident.xsd"> ABC-12345

EPP, jak už z názvu vyplývá, je snadno rozšiˇritelný protokol. Požadavek rozšiˇritelnosti protokolu je velmi podstatný, jelikož každý registr má specifické požadavky na strukturu spravovaných objekt˚u a na protokol obecnˇe. Standard definuje zp˚usoby, jakými je

3.1. EPP OBJEKTY

27

možné rozšíˇrit základní EPP protokol a pˇrizp˚usobit ho tak svým potˇrebám bez vytváˇrení nových navzájem nekompatibilních standard˚u. Podle závažnosti zmˇen a zp˚usobu provedení ˇradíme možná rozšíˇrení do následujících kategorií: • Rozšíˇrení protokolu. Používá se pouze pˇri nejzásadnˇejších zásazích do protokolu. M˚užou se jím definovat nové operace nad spravovanými objekty nebo napˇríklad funkce pro získavání informací o stavu kreditu pˇrihlášeného uživatele. • Rozšíˇrení o nové objekty. Napˇríklad definice mapování objektu doména (RFC 3731) do EPP je pˇríkladem takového rozšíˇrení. • Rozšíˇrení pˇríkaz˚u a odpovˇedí. Pohodlné rozšíˇrení o nové vlastnosti objektu. Napˇríklad doména pomocí nˇekolika dalších atribut˚u m˚uže být rozšíˇrena o podporu DNSSEC standardu. Pˇri návrhu rozšíˇrení by se mˇelo postupovat smˇerem od nejménˇe závažného (posledního) a o úroveˇn výše pokroˇcit pouze v pˇrípadˇe, že navrhované rozšíˇrení vyžaduje vˇetší zmˇenu. Výborným pˇríkladem rozšíˇrení je pˇridání nových objekt˚u. EPP standard nedefinuje žadné mapování EPP operací na jakékoliv objekty. Pouze obsahuje návod, jak se má pˇri tom postupovat. Doplnˇení základního EPP o objekty je pˇredmˇetem jiných RFC dokument˚u. EPP protokol tak, jak je navržen, m˚uže být použit ke správˇe témˇeˇr cˇ ehokoliv, co se registruje ve sdíleném centrálním repozitáˇri, napˇríklad SPZ znaˇcek na auta. Fred rozšiˇruje EPP protokol na všech úrovních (všemi tˇremi uvedenými zp˚usoby). Na protokolové úrovni zavádí dva nové pˇríkazy. Jeden na zjištˇení aktuální výše kreditu registrátora a druhý na zaslání autorizaˇcní informace pro objekt na email držitele domény pro doménu, email technického kontaktu pro nsset a email objektu kontakt pro objekt kontakt. Motivace pro zavedení tohoto pˇríkazu vyplyne z popisu transferu objektu. Rozšíˇreními na úrovni objekt˚u se budeme zabývat v následující kapitole a rozšíˇrení na úrovni pˇríkaz˚u a odpovˇedí se využívá pˇri podpoˇre ENUM domén, o kterých bude ˇreˇc také pozdˇeji.

3.1 EPP objekty Na EPP standard navazuje nˇekolik jiných standard˚u, z nichž vˇetšina definuje mapování objekt˚u do EPP. Tyto objekty jsou samozˇrejmˇe specifické pro registrátorské prostˇredí, které bylo hlavní motivací celého EPP standardu. Jako standardy existují tˇri typy mapování objekt˚u: • Doména (RFC 3731) • Kontakt (RFC 3733) • Host (RFC 3732) Toto jsou standardní mapování, u kterých se pˇredpokládá, že budou použitá s EPP. V naší implementaci registru jsme se rozhodli je nakonec nepoužít a vytvoˇrit si vlastní mapování pro všechny objekty. Pˇresto naše vlastní mapování vycházejí z tˇechto standardních a jsou jim velmi podobná. Vyvstává otázka, proˇc jsme nepoužili k úpravˇe standardizovaných mapování rozšíˇrení a definujeme si vlastní objekty. Je to proto, že pomocí rozšíˇrení pˇríkaz˚u a odpovˇedí m˚užeme snadno pˇridávat atributy objektu, ale nelze je odebírat. Druhým d˚uvodem je, že pokud je zmˇen až pˇríliš mnoho, p˚usobí výmˇenˇ ované XML dokumenty nepˇrehledným dojmem. Posledním d˚uvodem je, že rozšíˇrení jsou ve schématech definovaná z podstaty vˇeci jako volitelná, ale pokud rozšiˇrujeme základní vlastnosti objektu, které jsou povinné, klademe vˇetší požadavky na aplikaci, která musí pˇrítomnost atribut˚u zkontrolovat sama a nem˚uže k tomu úˇcelu použít XML validátor. Pˇrítomnost objektu doména je pˇredvídatelná, jedná se o klíˇcový objekt. Objekt kontakt reprezentuje fyzickou osobu, která m˚uže zastupovat ale i právnickou osobu. Objekt host reprezentuje poˇcítaˇc v síti internet. Mezi jeho vlastnosti patˇrí doménové jméno a ip adresy. V registru doménových jmen se využívá k reprezentaci nameserveru. Tento objekt nebyl pˇrevzat, na místo nˇeho je použit jiný objekt, nazývaný nsset. Jedná se o objekt, který sdružuje skupinu nameserver˚u a tato skupina m˚uže být pˇriˇrazena doménˇe. Myšlenka sady nameserver˚u byla pˇrevzata od registru rakouské národní domény. Standardní objekt host nebudem z tohoto d˚uvodu nadále uvažovat a nahradíme jej objektem nsset. Existuje nˇekolik atribut˚u, které jsou pro všechny objekty shodné. Zde je jejich výˇcet ve formátu: název XML elementu, který je oznaˇcuje, a jejich struˇcný popis. ROID Zkratka pro Repository Object ID. Jednoznaˇcnˇe identifikuje objekt celosvˇetovˇe. Skládá se ze dvou cˇ ástí oddˇelených pomlˇckou. První cˇ ást je unikátní v rámci jednoho repozitáˇre a urˇcuje si ji registr sám. Druhá cˇ ást, celosvˇetovˇe unikátní, pˇridˇeluje se pro celý repozitáˇr a jejím pˇridˇelováním je povˇeˇrena organizace IANA.

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 cˇ as vytvoˇrení objektu v repozitáˇri. upDate Je datum a cˇ as posledního provedeného updatu nad objektem. trDate Datum a cˇ as poslední zmˇeny 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ˇres registrátora. admin Identifikátor objektu kontakt, který je v roli administrátora pro doménu. Doména m˚uže mít více administrátor˚u. 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ˇcní informace pro doménu. Tato informace je využívaná pˇri transferu domény od jednoho registrátora k jinému. Standard pro objekt doména definuje exDate jako datum a cˇ as. Zkrácení na datum bez cˇ asu probˇehlo, aby se zabránilo nedorozumˇením a pˇrípadným spor˚um o nevˇcasném zrušení domény. Expirované domény se totiž vyˇrazují ze zónového souboru v jeden cˇ as bˇehem dne bez ohledu na to, kdy bˇehem toho dne doména expirovala. Další zmˇeny 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í cˇ íslo kontaktu. fax Faxové cˇ íslo kontaktu. email Emailová adresa kontaktu. authInfo Autorizaˇcní informace pro kontakt. Tato informace je využívaná pˇri transferu kontaktu od jednoho registrátora k jinému. disclose Potomci tohoto elementu urˇcují, jaké údaje o kontaktu mají být veˇrejné a jaké mají být skryté. To se projevuje ve výpisu informací o objektu na webu urˇceném pro veˇrejnost. ident Údaj, který jednoznaˇcnˇe identifikuje osobu v oficiálním smyslu. M˚uže se jednat o rodné cˇ íslo, cˇ íslo pasu, obˇcanského pr˚ukazu a tak podobnˇe. vat Daˇnové identifikaˇcní cˇ íslo kontaktu. Oproti standardnímu objektu kontakt v naší variantˇe pˇribyly atributy ident a vat, poštovní údaje jsou dostupné pouze v jedné formˇe (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ˇel být správce nameserver˚u, které nsset sdružuje. Zde je vyplnˇen identifikátor takového kontaktu. Technických kontakt˚u m˚uže být pro nsset více než jeden. reportlevel Nastavení úrovnˇe technických test˚u provádˇených na doménˇe. Zde není porovnání se standardním objektem, protože nsset nemá standardní ekvivalent. Všechny tˇri XML schémata, která definují strukturu objektových rozšíˇrení jsou souˇcástí dodatku se schématy.

3.2. MODEL TRANSFERU

29

3.2 Model transferu Metoda transferu je pomˇernˇe záludná problematika s pˇrihlédnutím k bezpeˇcnostním hrozbám. V naší implementaci registru se liší od metody, kterou popisuje standard, proto se budeme transferem zabývat podrobnˇeji. Nejprve si popíšeme jak probíhá transfer domény dle RFC 3730 a RFC 3731. Uživatel, který chce pˇrevést doménu k jinému registrátorovi, mu dá pokyn k pˇrevední. Nastávající registrátor vyšle žádost o pˇrevod domény. Na tuto skuteˇcnost je stávající registrátor upozornˇen zprávou a pokud mu jeho klient potvrdí pˇrevod, dá svolení k pˇrevodu. Tím je doména pˇrevedena. Tento postup je aplikovatelný i na objekt kontakt. Samozˇrejmˇe proces pˇrevodu má i jiné scénáˇre. Stávající registrátor m˚uže transfer odmítnout a nebo nadcházející registrátor m˚uže žádost o transfer zrušit ještˇe pˇred jejím potvrzením nebo zamítnutím.

ˇ Obrázek znázorˇnuje pr˚ubˇeh úspˇešného transferu domény podle postupu definovaného ve standardu. Císla u šipek znaˇcí poˇradí akcí. Samozˇrejmˇe vyvstávají otázky, co dˇelat, když transfer stávající registrátor ani nepotvrdí, ani neodmítne. V tom pˇrípadˇe je vˇec serveru, jestli takové žádosti automaticky potvrdí nebo odmítne po stanoveném cˇ asovém intervalu. Pokud stávající registrátor odmítne žádost o transfer a pˇritom by jí mˇel povolit na základˇe v˚ule držitele domény, musí se spor ˇrešit cestami mimo registraˇcní systém. Ve fredu transfer domény probíhá podle následujícího schématu. Klient si nejprve od registrátora (budoucího cˇ i stávajícího) vyžádá autorizaˇcní informaci pro doménu, kterou chce pˇrevést. Tato informace mu je zaslána pˇrímo z registru na emailovou adresu, která je u domény vyplnˇená. Poté pˇredá s žádostí tuto autorizaˇcní informaci registrátorovi, ke kterému chce doménu pˇrevést. Ten použije autorizaˇcní informaci a k pˇrevodu dojde bez asistence stávajícího registrátora. Oproti pˇredchozímu modelu má tento výhodu v tom, že stávající registrátor nem˚uže blokovat pˇrevod domény. Na druhou stranu tato metoda obnáší komunikaci registru s koncovým zákazníkem, což nebylo v pˇredchozím modelu nutné.

30

KAPITOLA 3. EPP

ˇ Obrázek znázorˇnuje pr˚ubˇeh úspˇešného transferu domény v systému fred. Císla u šipek znaˇcí poˇradí akcí. Zároveˇn s pˇrevedením domény je automaticky vygenerována nová autorizaˇcní informace, aby p˚uvodní registrátor, který mˇel pˇrístup k této informaci, ji nemohl zneužít v budoucnu. Nový registrátor si m˚uže autorizaˇcní informaci zjistit pomocí info pˇríkazu, který zobrazí autorizaˇcní informaci pro objekt, pokud je zadavatel pˇríkazu vlastníkem objektu.

3.3 Nasazení EPP v praxi EPP vznikl na p˚udˇe spoleˇcnosti VeriSign, která mimo dalších svých aktivit je správcem tld domén .net a .com, která je mimochodem nejvytíženˇejší doménou souˇcasnosti. Architektem EPP je S. Hollenbeck z této spoleˇcnosti. EPP protokol byl hned od svého vzniku (v dobˇe, kdy byl ještˇe draftem a ne standardem) adoptován druhým významným hráˇcem na trhu správc˚u domén - spoleˇcností Afilias, která je povˇeˇrena správou domény .org a .info a kromˇe tˇechto dvou domén spravuje ještˇe nˇekolik 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ˇrení této domény v roce 2000. EPP není první snahou S. Hollenbecka standardizovat rozhraní mezi registrárory a registrem, nicménˇe EPP je zatím nejúspˇešnˇejším pokusem. Témˇeˇr všechny registry jsou ve stádiu, kdy už EPP podporují nebo se k tomu chystají. EPP je úspˇechem, nicménˇe v urˇcité oblasti selhává. Paradoxnˇe snadná rozšiˇritelnost EPP je zároveˇn kamenem úrazu, nebot’ r˚uzné registry implementují r˚uzná rozšíˇrení, a tak EPP jako aspirant na unifikátor registrátorského rozhraní selhává. To vede k tomu, že se musí používat r˚uzní klienti pro r˚uzné registry. Nicménˇe krok kupˇredu EPP jistˇe znamená, jelikož základní protokol je implementován dle standardu, leˇc mapování objekt˚u a jejich atributy se mohou lišit. Citlivou otázkou je metoda transferu domény, která se dosti liší napˇríˇc evropskými registry národních domén. Transfer je citlivý z toho d˚uvodu, že jednotlivé registry se liší poˇctem registrátor˚u, jejich d˚uvˇeryhodností a dosavadními zvyklostmi. Od švýcarského NICu vzešla iniciativa formou výzvy k diskuzi, která by sjednotila rozpolcenost evropských registr˚u v této otázce, nicménˇe z˚ustala nevyslyšena a autor této práce si není vˇedom žádných probíhajících diskuzí na toto téma.

3.3. NASAZENÍ EPP V PRAXI

31

Podle názoru autora této práce je na tom snad nejh˚uˇre 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ˇc zmˇenil základní schémata definující EPP, oznaˇcuje své dílo nálepkou EPP, což vyloženˇe odporuje EPP standardu. Pomˇernˇe zajímavý pˇrínos pˇredstavuje myšlenka rakouského registru, který definoval mapování pro zcela nový objekt nsset, který sdružuje více nameserver˚u do jednoho objektu a tento objekt m˚uže být pˇrirazen doménˇe jako celek. Jak vyplývá z pˇredchozího textu v této kapitole, myšlenka objektu nsset byla pˇrevzata i cˇ eským registrem, leˇc mapování nssetu do EPP má vlastní. Pokud bychom mˇeli kriticky zhodnotit naší implementaci EPP, pozitivním faktem je, že respektuje základní schémata EPP standardu, tudíž se jedná skuteˇcnˇe o EPP implementaci a ne jen nˇeco, co se tomu velmi podobá. Na druhou stranu je škoda, že se nenašla u vedení spoleˇcnosti v˚ule a odvaha dotáhnout implementaci až do konce, co se týká mapování EPP objekt˚u. Nebylo pˇrevzato 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ˇe znepodobˇnuje protokol s tím, jak je implementován ve svˇetˇe, a vyluˇcuje použití standardních EPP klient˚u a knihoven. Navíc proces transferu je zcela jiný než jak je popsán ve standardu (nicménˇe standard není porušen) a pravdˇepodobnˇe unikátní na celém svˇetˇe, což lze opˇet považovat spíše za prohru z pohledu sjednocování rozhraní mezi registrátory a registrem.

32

KAPITOLA 3. EPP

Kapitola 4

ENUM ENUM (tElephone NUmber Mapping) standard je popsán v RFC 3761 a RFC 3245. Jedná se o mapování tradiˇcních telefonních cˇ ísel do DNS databáze. To umožnuje pˇridˇelit pak IP telefonu klasické telefonní cˇ íslo, na které jsou lidé zvyklí. IP telefony, u kterých se data nepˇrenášejí po síti telefonního operátora, ale po internetu, jsou stále populárnˇejší hlavnˇe díky tomu, že uživatel nemusí platit žádné jiné poplatky než za pˇripojení k internetu. ENUM je v podstatˇe o zp˚usobu, jak pˇreložit klasické telefonní cˇ íslo na url, které urˇcuje kam se má volající spojit. Samozˇrejmˇe by se daly vyvinout nové standardy a speciální software, který by se o pˇreklad klasického telefonního cˇ ísla na url postaral. Nicménˇe autoˇri ENUMu si všimli podobnosti s pˇrekladem domény na IP adresu, kterou zajišt’uje DNS systém a rozhodli se využít právˇe tento systém pro své úˇcely. Výhody tohoto ˇrešení jsou, že DNS infrastruktura je vybudována a software taktéž, cˇ i-li myšlenka ENUMu m˚uže být uvedena do provozu ihned s nulovými náklady. ˇ Nyní si podrobnˇeji popíšeme na hypotetickém pˇríkladu, jak ENUM funguje. Ci-li vezmeme si nejjednoduší pˇríklad, kdy uživatel IP telefonu Karel volá uživatelce jiného IP telefonu, Janˇe. Karel využije výhod ENUMu, nemusí si tudíž pamatovat SIPovou adresu IP telefonu Jany, ale klasické telefonní cˇ íslo. "Vytoˇcí" tedy cˇ íslo +420776015692, které se lokálnˇe mechanicky pˇreloží na doménové jméno 2.9.6.5.1.0.6.7.7.0.2.4.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ˇrekladu telefonního cˇ ísla na SIP adresu s využitím DNS je pomˇernˇe triviální. Nyní nˇekolik poznámek k pˇredchozímu pˇríkladu. Pravidla pro pˇreklad telefonního cˇ ísla na doménové jméno jsou pevnˇe stanovena. Domény a telefonní cˇ ísla si jsou dosti podobné s tím rozdílem, že u telefonního cˇ ísla se identifikátor upˇresˇnuje z leva do

33

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˚u. Jednotlivé úseky doménového jména jsou oddˇeleny teˇckou na rozdíl od telefonních cˇ ísel. Z pˇredchozích myšlenek dojdeme k závˇeru, že pokud se má pˇreložit telefonní cˇ íslo na doménu, musíme ho zapsat pozpátku, jednotlivé cifry oddˇelit teˇckou a pro zachování poˇrádku v hierarchii doménových jmen pˇripojit suffix, který zastˇrešuje všechny ENUM domény - tím je e164.arpa. Doména arpa je k podobným úˇcel˚um vyhrazená. Úˇcastníci nemusí komunikovat zrovna pˇres SIP protokol, ale nˇejakou jeho alternativu. Na mechanismu ENUMu se tím nic nemˇení, zmˇena protokolu by se musela ale odrazit ve výsledku DNS dotazu na ENUM doménu tak, že url by nezaˇcínala prefixem sip, ale identifikátorem jiného protokolu. NAPTR (Naming Authority Pointer) záznam˚u m˚uže být dokonce i více a mohou mít r˚uznou prioritu, takže pokud se nepovede spojení na url s nejvyšší prioritou, použije se url s nižší prioritou. NAPTR záznam je pomˇernˇe složitý, protože výsledný záznam vzniká transformací na základˇe 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ˇe, jak uvidíme pozdˇeji, NAPTR záznamy nemají pˇrímou souvislost s registraˇcním systémem. Proto se jimy nebudeme zabývat. Zbývá zodpovˇedˇet otázku, jakou roli hraje v pˇrekladu ENUM domény na url registr domén. Pro registr je ENUM doména pouze ˇ doménou ze zóny, kterou spravuje. Ci-li seznam zón se rozr˚ustá na cz a 0.2.4.e164.arpa. Pak se až na detaily pracuje s ENUM doménami stejnˇe jako s cz doménami. Kdybychom se chtˇeli držet pˇredchozího pˇríkladu a nastínit postup registrace telefonního cˇ ísla Jany, odehrávala by se registrace následovnˇe. 1. Jana požádá registrátora o registraci domény, která odpovídá jejímu telefonnímu cˇ íslu. 2. Registrátor nejprve ovˇerˇí, že cˇ íslo patˇrí Janˇe, zasláním sms zprávy, která obsahuje informace o registraci a kód, který se použije pˇri potvrzení registrace ze strany Jany. Tomuto procesu se ˇríká validace. 3. Pokud validace probˇehla v poˇrádku, registrátor vyšle požadavek na registraci domény pˇres EPP do registru. Pˇri registraci se doménˇe pˇriˇradí 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ˇe registru, ale bud’to koncového zákazníka nebo zprostˇredkovatelské spoleˇcnosti. Tím pádem 0.2.4.e164.arpa zóna vygenerovaná pro DNS server obsahuje pouze záznam o delegaci na urˇcené nameservery, nikoliv však pˇrímo NAPTR záznamy. 4. V tuto chvíli, pokud se nˇekdo pokusí dovolat ze zaˇrízení, které bere ENUM v potaz, na telefonní cˇ íslo Jany, uskuteˇcní se hovor pˇres internet.

4.1 Pˇrizpusobení ˚ registru pro správu ENUM domén Už bylo naznaˇceno, že v zásadˇe jsou ENUM domény velmi podobné klasickým doménám. Pˇresto v nˇekterých ohledech vyžadují vyjímeˇcné zacházení. Pˇredmˇetem této podkapitoly je upozornit na taková místa, leˇc seznam nebude úplný, ale zmíníme pouze ty nejd˚uležitˇejší. V první ˇradˇe databáze musí být pˇrizp˚usobena 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ˇcuje, jestli se jedná o zónu klasických nebo ENUM domén. Napˇríˇc všemi vrstvami registru p˚usobí skuteˇcnost, že u ENUM domén existuje dodateˇcný atribut datum validace, nebo pˇresnˇeji ˇreˇceno datum, kdy vyprší platnost validace. ENUM domény jsou validovány vždy jen na nˇejaké období (v souˇcasné implementaci je to p˚ul rok). Po vypršení této lh˚uty musí být doména znovu zvalidována, má-li být opˇet generována do zónového souboru. Je tˇreba upozornit, že se nejedná o datum expirace domény, ten z˚ustává v platnosti i na dále. Napˇríklad ENUM doména je typicky registrována na jeden rok a bˇehem tohoto období dojde dvakrát k její validaci. Tato skuteˇcnost se odráží v tˇechto 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šíˇren, nebo pˇresnˇeji ˇreˇceno relevantní pˇríkazy a odpovˇedi týkající se domény byly rozšíˇreny, standardním mechanismem pro rozšiˇrování EPP, o datum validace. Rozšíˇrení jsou definovaná XML schématem enumval verze 1.0 (viz dodatek s XML schématy). • S pˇredchozím bodem souvisí podpora v EPP klientovi pro definované rozšíˇrení enumval-1.0. • Generátor zóny pro ENUM domény musí vyhodnocovat kromˇe datumu expirace navíc datum validace. Pokud doména není validní, nesmí se vygenerovat do zóny.

ˇ Eˇ 4.2. ENUM DOMA A VE SVET

35

• Všude, kde se vypisují informace o doménˇe (administrátorské rozhraní nebo rozhraní pro veˇrejnost) 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ˇe telefonního operátora na IP telefon a naopak. Dva d˚uvody tomu brání v praxi a to jsou: • Telefonní operátoˇri by museli pˇrejít na paušální úˇctování a ne úˇctování za provolané hovory. To by vedlo k pokles˚um z tržeb, cˇ i-li proto ten chlad tuzemských operátor˚u k ENUMu. • Implementace bran jež by byli styˇcným bodem mezi sítˇemi telefonních operátor˚u a internetem.

ˇ eˇ 4.2 ENUM doma a ve svet Využití ENUMu pro IP telefonii je pomˇernˇe mladá myšlenka. Jistˇe není cˇ as na bilancování nebo rozsudky typu úspˇešný, neúspˇešný. Nicménˇe se v této podkapitole pokusíme shrnout fakta o dosavadních zkušenostech s provozem ENUMu v zahraniˇcí i v ˇ Ceské republice. ˇ Ke dni 6.1. 2007 bylo v Ceské republice (v zónˇe 0.2.4.e164.arpa) registrováno 2100 ENUM domén, což pokrývalo celkem 423219 telefonních cˇ ísel. Tolik registrací v souˇcasných pomˇerech, kdy telefonní operátoˇri se staví k ENUMu velmi chladnˇe a ENUM byl spuštˇen zatím jen v trial módu, lze považovat za velký úspˇech. Bude zajímavé sledovat, jak se bude popularita ENUMu vyvíjet po spuštˇení ostrého provozu od 22.1. 2007. ˇ Zavádˇení ENUMu není proces ojedinˇelý pro Ceskou republiku. Pˇrehled stát˚u, kde se zavádí ENUM, je k dispozici na webových stránkách organizace RIPE, která byla povˇeˇrena správou domény sdružující ENUM cˇ ísla .e164.arpa.

Status Trial provoz Ostrý provoz

Státy ˇ Ceská republika, Finsko, Francie, Japonsko, Irsko Rakousko, Polsko, Nˇemecko, Rumunsko

Tabulka 4.1: Stav ENUM registrací dle stát˚u. ˇ Aby vynikl prozatimní úspˇech ENUMu v Ceské republice uvedeme, že v sousedním Nˇemecku, které pˇredstavuje mnohem vˇetší trh a ENUM je tam spuštˇen už od roku 2003, mají registrováno 7139 ENUM domén.

36

KAPITOLA 4. ENUM

Kapitola 5

Architektura systému

Než si nastíníme rozvržení jednotlivých komponent systému, udˇeláme si poˇrádek v názvech komponent a systému jako takového.

DSD-NG Oznaˇcuje 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ˇredpisy pro registraci atd. DSD-NG zkratka znamená Distribuovaná správa domén nové generace. Je to systém specifický pro cˇ 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é cˇ ásti systému. Tím jsou myšleny všechny programy vytvoˇrené v rámci projektu, ale i "cizí" programy, na kterých je projekt závislý. Jedná se o universální cˇ ást použitelnou víceménˇe napˇríˇc r˚uznými registry. Fred není specifický pro cˇ eskou doménu, i když je souˇcástí DSD-NG, který pˇredstavuje systém pro správu cˇ eské národní domény. Název fred vznikl z prvních písmen oznaˇcení: Free Registry for Enum and Domain.

Poznámka ˇ cˇ ást centrálního registru napsáná v C++. Takového oznaˇcení V užším slova smyslu se pod pojmem Fred muže ˚ rozumet ˇ se však vyvarujeme, aby nevznikala nedorozumení. ˇ vývoje došlo k jednomu pˇrejmenování. Puvodn ˚ eˇ se systém nazýval ccReg (Country Code Registry). Ve V prub ˚ ehu zdrojových souborech se místy tento název ješteˇ vyskytuje.

Centrální registr Centrální registr je ta cˇ ást Fredu, která "obaluje" databázi a pˇres 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˚uvod, proˇc je toto jádro napsáno ve dvou jazycích, spoˇcívá v kompromisu mezi rychlostí programu (C++) a rychlostí vývoje (Python).

37

38

KAPITOLA 5. ARCHITEKTURA SYSTÉMU

Znázornˇení pojm˚u DSD-NG, Fred a Centrální registr formou množin a podmnožin. Názvy uvedené unitˇr množin mají pˇriblížit, o co se v dané množinˇe jedná.

Poznámka Jako komunikaˇcní protokol mezi jednotlivými cˇ ástmi systému byla vybrána CORBA. CORBA je specifikace vzdáleného volání metod, které je nezávislé na platformeˇ a použitém programovacím jazyku. Základní znalost této technologie je nutná pro ˇ ˇ pˇreˇcíst dodatek, pochopení funkce centrálního registru. Ctenáˇ r, který není se základy této technologie obeznámen, by si mel ˇ z corby a až poté pokraˇcovat ve cˇ tení následujícího textu. který shrnuje to nejpodstatnejší

Pro jednoduchost se podívejme nejprve na systém jako na cˇ ernou skˇríˇnku. Na systém m˚užeme nahlížet oˇcima registrátora nebo bˇežného uživatele internetu. Klíˇcová role je uživatel na internetu, který požaduje pˇreklad DNS jména na IP adresu. To je koneckonc˚u d˚uvod existence registru. Druhou službou poskytovanou veˇrejnosti je whois. Whois slouží k získání informací o doménˇe. Na základˇe whoisu lze napˇríklad zjistit komu doména patˇrí, cˇ i kdo je zodpovˇedný za její technický provoz. Whois má dvˇe podoby. Textová podoba, nˇekdy též nazývaná unixový whois, je popsána internetovým standardem RFC 3912. Podrobnˇeji se o protokolu zmíníme v souvislosti s komponentou jež implementuje v registru whois protokol. Díky nár˚ustu obliby www rozhraní obecnˇe v internetu, drtivá vˇetšina registr˚u poskytuje informace o registrovaných doménách formou html stránek pˇres http protokol. Toto rozhraní je jednoznaˇcnˇe populárnˇejší a rozšíˇrenˇejší než zastaralý whois protokol, nicménˇe z d˚uvod˚u jednoduchosti a možnosti automatizace má unixový whois stále d˚uvod k existenci. Souˇcasný trend ve všech registrech je pˇresun odpovˇednosti za zprostˇredkování informací z registru do webového whoisu, kde mohou být informace lépe chránˇeny proti zneužití. Mezi registrátorem a registrem proudí informace v obou smˇerech. Registrátor ukládá do registru informace o objektech a nˇekteré informace získává zase zpˇet z registru. Objektem je myšlena napˇríklad doména. Podrobnosti o EPP protokolu jsou námˇetem samostatné kapitoly. Administrátorská role je tak trochu souˇcástí registru jako takového, leˇc z pohledu implementace je to role jako každá jiná, která má své vlastní rozhraní. Je urˇceno pro využití pracovníky helpdesku. Administrátorské rozhraní umožˇnuje získávat rozliˇcné informace z registru a zároveˇn umožnuje informace i mˇenit. Zmˇena informací v registru je nazývána manuální zásah.

39

Na obrázku jsou znázornˇeny všechny vstupy a výstupy systému jako celku. Vnitˇrní architektura systému je zámˇernˇe opomenuta pro jednoduchost. Postaviˇcky znázorˇnují uživatelské role a šipky protokoly, pˇres které komunikují s registrem. Role administrátor m˚uže být považována za souˇcást systému, proto je v obrázku jeho souˇcástí. Vše je soustˇredˇeno kolem databáze, která udržuje data registru. Na tuto klíˇcovou pozici byla vybrána databáze PostgreSQL. D˚uvody, které vedly k této volbˇe jsou shrnuty v dodatku o výbˇeru databáze. Pokud bychom všechny komponenty Fredu uspoˇrádali do vrstev podle vzdálenosti od stˇredu, který je pˇredstavován databází, dostali bychom schéma, které velmi dobˇre odráží architekturu systému.

1. V první vrstvˇe nalezneme aplikace, které bˇeží pˇrímo nad databází a pˇristupují do ní pˇres databázové C API (v pˇrípadˇe PostgreSQL je to knihovna libpq). Souhrnˇe jsou tyto aplikace nazývány Centrální registr a tvoˇrí jádro registraˇcního systému. Jsou mezi nimi urˇcité vzájemné vazby, které zde pro jednoduchost opomíjíme a budou detailnˇeji popsány pozdˇeji. Vˇetšina centrálního registru je napsána v C++, ale podstatná cˇ ást i v Pythnu. Nejedná se o jeden program, ale o skupinu program˚u. Žádné rozhraní tˇechto aplikací není pˇrí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áˇrejí rozhraní pro koncové uživatele. 2. Tím jsme se pˇrenesli do druhé vrstvy smˇerem od stˇredu. Zatímco v první vrstvˇe byly CORBA servery exportující funkce nad databází, ve druhé vrstvˇe jsou CORBA klienti, kteˇrí volají metody CORBA server˚u. Tito CORBA klienti vˇetšinou vystupují z pohledu aplikací, které náleží do nejvzdálenˇejší (tˇretí) vrstvy, v pozici server˚u implementujících rozliˇcné protokoly. Pokud tedy mluvíme o komponentách ve druhé vrstvˇe v termínech klient a server, je tˇreba pozornˇe dbát na kontext, protože mohou vystupovat vˇetšinou v obou rolích. 3. Tˇretí vrstva by teoreticky nemˇela existovat, protože se jedná o programy na stranˇe koncových uživatel˚u registru (napˇríklad web browser a unixový whois klient). Nicménˇe zde uvedená aplikace epp_client je vyjímkou a je vyvíjena jako souˇcást registru (Fredu). Slouží jako referenˇcní implementace EPP klienta.

40


Na obrázku je schématicky zachycena architektura celého systému, nebo pˇresnˇeji jeho softwarové cˇ á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ˇcních celk˚u, podrobnˇejší 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", cˇ i-li rozhraní pro registrátory. fred_adif Implementuje administrátorské operace nad databází. Koncovka adif je zkratka "administration interface", cˇ i-li rozhraní pro administrátory. fred_pif Implementuje funkce nad databází, které zpˇrístupˇnují informace o doménách a jiných objektech veˇrejnosti. Koncovka pif je zkratka "public interface", cˇ i-li rozhraní pro veˇrejnost. pyfred Implementuje r˚uznorodé funkce nad databází pro generování zóny, notifikaˇcní systém, správce soubor˚u a technické testy.

41

genzone Generuje zónový soubor vhodný pro naˇctení DNS serverem. Jedná se o klienta k modulu z pyfredu se shodným názvem. mod_eppd Modul do Apache pro pˇreklad EPP požadavk˚u na CORBA volání metod centrálního registru. mod_whoisd Modul do Apache pˇrekládající dotazy podané pˇres 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ˇres EPP protokol.

Obrázek zachycuje vnitˇrní závislosti mezi jednotlivými komponentami v registru. Šipky naznaˇcují roli komponenty ve vztahu, šipka smˇerˇuje vždy od klienta k serveru. Závislosti vyznaˇcené tlustou cˇ arou jsou zjevné a stˇežejní. Každá šipka má pˇridˇelený 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ˇcné míry ovlivnˇen EPP protokolem a požadavkem na archivaci všech provedených zmˇen nad objekty, aby bylo možné snadno revertovat efekt jakékoliv provedené operace. Historie zmˇen se ukázala pˇri návrhu býti nejkomplikovanˇejším úkolem. Vznik relaˇcního databázového schématu se odehrál ve tˇrech krocích: 1. Návrh tabulek reprezentujících objekty EPP a zachycení jejich vzájemných vztah˚u. 2. Doplnit schéma o ukládání historie zmˇen objekt˚u. S tím souvisí i ukládání informací o tom, kdo a kdy zmˇenu provedl a v rámci jaké session. 3. Doplnit vše ostatní, co nesouvisí s pˇredchozími kroky.

42


Nejvˇetší problém pˇredstavuje rostoucí množství dat v databázi, s kterým se zhoršuje její výkon. Množství dat totiž není úmˇerné pouze poˇctu registrovaných objekt˚u, ale také poˇctu zmˇen vykonaných na objektech. Proto se musí v pravidelných intervalech, které jsou v ˇrádu mˇesíc˚u až let, provádˇet proˇrez dat v databázi. Historická data musí být zaarchivována, aktuální data s cˇ ástí historie ponechána.

Schéma cˇ ásti relaˇcní databáze registru. Tabulky jsou rozdˇeleny do skupin podle toho v jakém kroku vznikaly. Tabulky vyplývající z EPP jsou ohraniˇcené plnou cˇ arou, tabulky týkající se ukládání historie jsou ohraniˇcené pˇrerušovanou cˇ arou a jejich výˇcet není úplný, ale pˇresnˇe kopírují tabulky ohraniˇcené plnou cˇ arou. Tabulky týkající se správy session jsou na pravo mimo ohraniˇcení. Problém uchování historie zmˇen pˇredstavuje zajímavý problém a v zásadˇe jsou dvˇe možnosti, jak ho ˇrešit. První cestou je postupné inkrementální zaznamenávání zmˇen. Pokud se chceme dostat ke stavu objektu v minulosti, musíme sadu uchovaných

5.1. FRED_RIF, FRED_PIF A FRED_ADMIN

43

zmˇen aplikovat smˇerem od souˇcasné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˚usobem je uchovávat takzvané snapshoty objekt˚u. Pˇri provedené zmˇenˇe je nejdˇrí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ˇení, nicménˇe je rychlá. Další její výhodou je, že se v relaˇcní databázi snadno realizuje. Tabulky na uchovávání snapshot˚u, kopírují pˇresnˇe strukturu aktuálních tabulek, pouze se všechny doplní o atribut identifikátoru zmˇeny a zruší se nˇekterá integritní omezení typu cizích klíˇcu˚ . Celkem je v databázi kolem sedmdesáti r˚uzných tabulek, z toho d˚uvodu se nebudeme pokoušet znázornit vˇerné schéma databáze, ale pouze jeho nejpodstatnˇejší cˇ á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˚u a historických objekt˚u spojuje tabulka object_registry, která obsahuje informace, které jsou nemˇenné po dobu životnosti objektu v registru, a tak jsou spoleˇcné historickým i souˇcasným objekt˚um. Tuto tabulku doplˇnuje jiná tabulka object, která obsahuje atributy spoleˇcné všem objekt˚um tak jako object_registry s tím rozdílem, že hodnoty v této tabulce podléhají zmˇenám a proto mají sv˚uj protˇejšek v historii - tabulku object_history. Pak následují tabulky realizující unikátní vlastnosti každého z objekt˚u. Pro objekt doména je to tabulka domain a pro ENUM rozšíˇrení 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ˇený identifikátor zmˇeny je ukryt v tabulce history pod atributem id. Tato tabulka váže dohromady zmˇenu stavu objektu a akci, která zmˇenu zapˇríˇcinila. Za povšimnutí stojí reprezentace registrátora (uživatele EPP) v databázi, která umožˇnuje, aby jeden registrátor mˇel více než jedny pˇrihlašovací údaje (heslo a certifikát). Ostatní tabulky se dˇelí do logických celk˚u pojmenovaných podle aplikací, jejichž úˇcel˚um slouží. Z návrhového hlediska nejsou až tak zajímavé jako právˇe 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 rˇíct, registru jako celku. Jedná se o programy, které jsou na sobˇe pˇri bˇehu nezávislé. Každý bˇeží ve vlastním procesu. Nicménˇe pˇri kompilaci sdílejí nˇekteré zdrojové soubory, které jsou spíše vedlejšího významu (napˇríklad rutiny pro parsování konfiguraˇcního souboru). Všechny jsou napsané ve stejném programovacím jazyce C++, sdílejí stejný konfiguraˇcní soubor a používají stejnou implementaci ORBu omniORB, který se stará o serverovou stránku programu a rozdˇelení procesu do vláken.

5.1.1 fred_rif Daemon fred_rif implementuje EPP operace nad databází. Je využíván modulem mod_eppd, který pˇríchozí požadavky ve formˇe XML pˇreklá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ˇrehled o pˇrihlášených uživatelích. Pro každého uživatele pˇri pˇrihlášení se do systému, vygeneruje unikátní identifikátor, který slouží k identifikaci session pˇri komunikaci s mod_eppd a pro logování. Všechny operace provedené klientem jsou uloženy do databáze vˇcetnˇe vstupních a výstupních XML dokument˚u. Operace, které vedou ke zmˇenˇe objektu v databázi, mají za následek uložení daného objektu do historie pˇred zmˇenou. Z tˇechto všech údaj˚u jsme schopni velmi pˇresnˇe zrekonstruovat celou session uživatele, což je d˚uležité v pˇrípadˇe nˇejakého sporu s uživatelem a také pro "rollback" provedených operací v pˇrípadˇe potˇreby. ˇ Cinnost daemona je založena na pˇrímoˇcarém návrhu. Každá EPP operace má sv˚uj protˇejšek v podobˇe CORBA metody. Té se z mod_eppd pˇredá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ˇrebné pro vygenerování EPP odpovˇedi. Pˇri každé EPP operaci je otevˇreno a na konci uzavˇreno 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ˇnuje overhead pˇripojování.

5.1.2 fred_pif Fred_pif je nejjednoduším daemonem z trojice C++ daemon˚u centrálního registru. Slouží jako backend pro webový i unixový whois. Webový whois pˇrebírá funkci unixového whoisu, co se týká množství poskytovaných informací. Webový whois lze mnohem snadnˇeji chránit pˇred data-miningem než zastaralý whois protokol. K tomu úˇcelu 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ˇrepsat do textového políˇcka. Tím se zabraˇnuje strojovému procházení webových stránek

44


pomocí takzvaných robot˚u. Uživatel zadá CAPTCHU pouze pˇri prvním dotazu na objekt. Zobrazená stránka v odpovˇedi obsahuje odkazy na jiné objekty, které mohou být proklikávány bez nutnosti zadávat CAPTCHU. To je realizováno následovnˇe. Pˇri prvním dotazu na objekt, který je ošetˇren CAPTCHOU, se naˇctou rekurzivnˇe všechny identifikátory objekt˚u, na které se lze proklikat. Když uživatel pak klikne ve výpisu informací o doménˇe napˇríklad na administrátorský kontakt pro doménu, webový whois si ovˇeˇrí, že identifikátor objektu se nachází ve stromˇe povolených identifikátor˚u objekt˚u. Pokud se v tomto stromˇe nenachází, je požadováno zadání CAPTCHY. Webový whois tedy vzdálenˇe volá na objektu exportovaném fred_pifem pouze funkce, pomocí nichž si sestavuje rekurzivnˇe strom identifikátor˚u povolených objekt˚u, a funkce na získání detail˚u objektu pro samotný výpis informací o doménˇe, kontaktu nebo nssetu. CAPTCHA není samospasitelná a pˇrináší závažné nedostatky, co se týká pˇrístupnosti webu pro zrakovˇe postižené lidi a ani ochrana, kouterou poskytuje není stoprocentní, protože rozpoznávací algoritmy se neustále zdokonalují. Nicménˇe se jednalo v dobˇe implementace o rychlé a vyhovující ˇrešení.

Ukázka webového whoisu. Zobrazení informací o ENUM doménˇe 0.2.2.0.2.4.e164.arpa. Fred_pif ve skuteˇcnosti exportuje dva CORBA objekty pro použití, jeden pro unixový whois a druhý pro webový whois, protože oba whoisy jsou pomˇernˇe rozdílné a nesdílejí žádnou cˇ ást rozhraní.

5.1. FRED_RIF, FRED_PIF A FRED_ADMIN

45

5.1.3 fred_adif Admin a fred_adif tvoˇrí dohromady administraˇcní rozhraní registru. Administraˇcní rozhraní zpˇrístupˇnuje nejr˚uznˇejší informace uložené v registru a dovoluje modifikaci dat v registru. Admin je webové rozhraní napsané v jazyce python pomocí HTTP objektovˇe orientovaného frameworku CherryPy. Jedná se o tenkého klienta, což znamená, že víceménˇe pouze zobrazuje výsledky operací. Veškerá logika zpracování pˇríkaz˚u a pˇredávání výsledk˚u je na stranˇe komponenty fred_adif. Obˇe cˇ ásti spolu komunikují pˇres rozhraní definované v IDL. Výhody architektury tenký klient, tlustý server jsou následující: • Snadné nahrazení jednoho klienta jiným v pˇrípadˇe, že bychom chtˇeli místo www klienta používat grafickou aplikaci napsanou napˇríklad s pomocí knihovny GTK. • Odolnost proti selhání klienta. Veškerý kontext pˇripojeného uživatele je uložen na stranˇe serveru. Pokud klient zhavaruje, je znovu nastartován a dojde mu požadavek od uživatele pˇrihlášeného ještˇe pˇred zhavarováním, doˇcká se oˇcekávané odpovˇedi. • Minimalizace množství dat pˇrenášených mezi klientem a serverem, protože data jsou filtrována podle r˚uzných kritérií už na stranˇe serveru. • Možnost sdílení funkcí s ostatními servery centrálního registru napsaných v C++. Uživatel je v pr˚ubˇehu práce identifikován identifikátorem session. S tímto identifikátorem jsou na stranˇe serveru svázány urˇcité prostˇredky. Podle typu rozlišujeme prostˇredky na tabulky, filtry a detaily objekt˚u. Tabulka je seznam objekt˚u, filtr pˇredstavuje kritéria pro výbˇer objekt˚u z tabulky a detail obsahuje jednotlivé atributy objektu.

Ukázka administrátorského www rozhraní. Na obrázku je formuláˇr pro zadání kritérií podle, kterých lze vyhledávat v objektech domén.

46


5.2 pyfred Pojem pyfred v širším významu je cˇ ást centrálního registru implementovaná v jazyce python. Jazyk python se hodí tam, kde je potˇreba dosáhnout rychlých výsledk˚u a kde výkon není až tak rozhodující. To je d˚uvod proˇc 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ˇrejmˇe, obsahující funkci init, která je zavolána po naloadování modulu do pyfredu pˇri jeho startu. Tato inicializaˇcní funkce vrací CORBA objekt a název tohoto objektu, pod kterým má být zaregistrován u nameservice. O zpˇrístupnˇení objektu z vnˇejšku se stará samotný pyfred. Framework pyfred a jednotlivé moduly spolu interreagují pouze pˇri inicializaci, po inicializaci si každý modul (CORBA objekt) žije svým vlastním životem, dá se ˇríct. Framework pyfred poskytuje následující služby modul˚um: • Funkce pro logování. • Funkce pro správu spojení do databáze. • Parsování konfiguraˇcního souboru. • Inicializace Object Request Brokeru a registrace objekt˚u u nameservice. • Spouštˇení pravidelných úloh registrovaných moduly. Díky prostˇredí, které pyfred vytváˇrí pro moduly, je vývoj nových modul˚u pomˇernˇe rychlou záležitostí, protože nemusíme opisovat kód, který by byl jinak nutný pro všechny moduly, mˇeli-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 rˇíci, že se jedná o sadu server˚u, které jsou na sobˇe nezávislé. Konfiguraˇcní soubor je spoleˇcný pro celý pyfred a je rozdˇelen do sekcí. Kromˇe obecné sekce, která konfiguruje pyfred jako framework, m˚uže konfiguraˇcní soubor obsahovat sekce pro jednotlivé moduly, vyžadují-li konfiguraci. Následuje struˇcný popis modul˚u využívaných v ostrém provozu.

5.2. PYFRED

47

5.2.1 genzone Modul genzone slouží ke generování zónového souboru. Zónový soubor je vstupem pro DNS server, který zprostˇredkovává standardní cestou pˇres DNS protokol informace uživatel˚um internetu. Pˇresnˇeji ˇreˇceno se jedná o CORBA server generátoru zóny. K vygenerování zónového souboru je tˇreba ještˇe klient. Klient-server architektura u generátoru zóny má tu výhodu, že zóna se m˚uže generovat na jiném stroji, než kde bˇeží centrální registr, což je pravdˇepodobná situace, protože težko bychom chtˇeli, aby nameserver v roli master bˇežel na stejném stroji jako centrální registr (z hlediska výkonu a bezpeˇcnosti). Vzhledem k velkému objemu dat transfer zóny ze serveru do klienta neprobíhá v jednom kroku, ale po cˇ ástech jejichž velikost je definovatelná klientem. Schéma komunikace mezi klientem a serverem pˇri generování zóny je pomˇernˇe zajímavé a je použito i u jiných modul˚u. Klient se spojí se serverem a vyžádá si skupinu údaj˚u, jejichž velikost je relativnˇe malá a pˇredem známá. Tuto skupinu dat nazýváme statické, protože známe pˇredem jejich poˇcet a velikost. Server zároveˇn vytvoˇrí nový CORBA objekt, do kterého uloží data, které tvoˇrí seznam položek a délka tohoto seznamu je pˇredem neznámá, potenciálnˇe neomezená. Tato data nazýváme v našem modelu dynamická. Reference na novˇe vytvoˇrený objekt je vrácena spoleˇcnˇe se statickými daty. Klient pak pˇristupuje k dynamickým dat˚um pˇres referenci na nový objekt - voláním metody tohoto objektu. M˚uže si urˇcit poˇcet položek seznamu, které se mají vrátit v jednom vzdáleném volání metody. Prázdná množina výsledk˚u je signálem pro klienta, že všechna data byla už pˇretransferována. Klient na to zavolá metodu objektu, která uvolní cˇ ást prostˇredk˚u alokovaných pro transfer dat na stranˇe serveru a oznaˇcí sebe sama (objekt) jako pˇripravený k vymazání. Pravidelnˇe spouštˇené rutiny kontrolují seznam vytvoˇrených objekt˚u na stranˇe serveru a objekty urˇcené k vymazání dealokují. Existující objekty, jejichž délka existence pˇresáhla urˇcitou mez, jsou oznaˇceny jako neˇcinné a posléze uvolnˇeny. Perioda pravidelné kontroly a mez neˇcinnosti jsou konfigurovatelné.

Typický scénáˇr komunikace klienta a serveru pˇri generování zóny. Hlavní myšlenkou je transferovat data postupnˇe po malých cˇ ástech a ne v jednom volání vzdálené metody. Transferovaná data mohou mít celkouvou velikost v rˇádech stovek megabajt. Generátor zóny je klíˇcová souˇcást registru, jelikož realizuje jeho základní úˇcel, kterým je zaˇrazení doménového jména do zóny, odkud je pˇrístupné veˇrejnosti. O zaˇrazení nebo nezaˇrazení doménového jména do zóny rozhoduje datum expirace domény, u ENUM domén je to navíc ještˇe datum validace. Ze zóny jsou vyˇrazeny domény pokud mají datum expirace vˇcerejší anebo starší plus ochranná lh˚uta. Ochranná lh˚uta zajišt’uje, že expirovaná nebo nezvalidovaná doména je generována do zóny po nˇejakou dobu. Pokud v této ochranné lh˚utˇe držitel neprodlouží platnost nebo nezvaliduje novˇe doménu, doména se pˇrestane generovat do zóny, tím pádem pˇrestane defacto existovat na internetu. Ochraná lh˚uta je v souˇcasnosti 31 dní. Vzhledem k citlivosti faktu (ne)zaˇrazení domény do zóny, je vedena historie zaˇrazení domény v zónˇe. Tato historie ukládá pouze

48


zmˇeny v zaˇrazení a nezaˇrazení domény do zóny oproti pˇredchozímu stavu.

5.2.2 filemanager FileManager je modul pro správu soubor˚u. K zajištˇení svých úkol˚u používá dvˇe databáze. Souborový systém používá k ukládání soubor˚u 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ˇri uložení pˇridˇeleno identifikaˇcní cˇ í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ˇe Mailer daemonem pro emailové pˇrí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ˇcené k zobrazení na místech použití souboru. ˇ esíc}/{den}/{id}. Casové údaje jsou vzaty z aktuálního Místo uložení souboru na filesystému je dáno vzorem {rok}/{mˇ datumu pˇri vložení souboru do databáze. Tímto zp˚usobem je dosaženo rovnomˇerného rozložení soubor˚u v adresáˇrích a snadná orientace v adresáˇrové struktuˇre. Modul implementuje také administrátorské rozhraní, pomocí nˇehož lze vyhledávat soubory na základˇe 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ˇri generování zóny.

5.2.3 mailer Mailer daemon implementuje notifikaˇcní systém registru. Spojuje v sobˇe š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 emaily dle standardu RFC 2387. Ci-li email se m˚uže skládat z libovolného množství pˇríloh. Pˇrílohy rozdˇelujeme do dvou základních skupin podle toho, jestli podléhají šablonovacímu systému cˇ i nikoliv. Pˇrílohy, které jsou vytvoˇreny ze šablon, jsou implicitnˇe textového typu. Pˇrílohy, které nejsou zpracovány pomocí šablon, jsou primárnˇe urˇceny pro soubory ve formátu pdf, ale mohou obsahovat soubory jakéhokoliv typu.

Obrázek znázorˇnuje vygenerování a odeslání emailové zprávy. Nahoˇre jsou uvedeny zdroje, které jsou pˇredány CORBA metodˇe na generování emailu, posléze vstupují do procesu databáze a FileManager, na konci je vygenerovaný email pˇredán programu sendmail.

5.2. PYFRED

49

Mailer je využíván pouze aplikacemi centrálního registru, konkrétnˇe fred_adifem a fred_rifem. Na vstupu pˇríjímá daemon identifikátor typu emailu, který urˇcuje jaké šablony se použijí pro sestavení emailu, hodnoty pro pole v hlaviˇcce emailu, seznam dat typu klíˇc-hodnota, která poskytují vstupní data pro šablony, a nakonec identifikátory pˇríloh, které se pˇripojí ke zprávˇe. Na pozici jádra šablonovacího systému byla vybrána existující knihovna clearsilver, která má stejné možnosti jako známˇejší jazyk XSLT, nicménˇe vykazuje lepší výkon a tvoˇrení clearsilver šablon je jednodušší pro cˇ lovˇeka nezasvˇeceného do této problematiky (napˇríklad pracovníka helpdesku). Co šablona to jedna textová pˇríloha emailu. Pˇrílohy, které nejsou urˇceny pro šablonování jsou získány od FileManager daemona, který je správcem tˇechto soubor˚u. Ve chvíli, kdy jsou pˇripravené hlaviˇcky emailu a všechny pˇrílohy (vzniklé ze šablon nebo získané od FileManagera), je email zaarchivován do databáze a pˇredán k poslání unixovému programu sendmail, který se postará o doruˇcení emailu. Šablony i jejich produkty jsou v UTF-8 kódování, souborové pˇrílohy získané z FileManageru jsou zakódovány do base64. Každý odeslaný email má pˇridˇelené identifikaˇcní cˇ íslo, které se mimochodem vyskytuje v emailové hlaviˇcce Message-ID. Mailer poskytuje i administraˇcní rozhraní. To obsahuje v souˇcasnosti pouze funkce pro vyhledávání v archivu email˚u. Vyhledávat se m˚uže podle rozliˇcných kritérií: • Datum vytvoˇrení a odeslání emailu • Jednoznaˇcný identifikátor emailu • Typ emailu • Pˇrílohy emailu • Identifikátory objekt˚u (kontakt˚u, domén, nsset˚u) nˇejakým zp˚usobem spjatých s emailem Výsledkem vyhledávání je seznam struktur obsahující informace o emailu i obsah emailu samotného. Výsledky mohou být odebírány postupným zp˚usobem pro pˇrípad, že by množina výsledných email˚u byla pˇríliš poˇcetná. Princip postupného stahování výsledk˚u je totožný jako u generátoru zóny.

5.2.4 techcheck Modul techcheck zajišt’uje kontrolu technického stavu nssetu. Zde je pˇríhodná chvíle vysvˇetlit 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ˇe, protože ip adresa nameserveru je souˇcástí onˇech záznam˚u. Proto se zavádí takzvaný GLUE záznam, který zveˇrejˇnuje adresu nameserveru v pˇrípadˇe, že je poddoménou domény, pro kterou je autoritativní. Doména musí být delegována aspoˇn na dva nameservery. Redundance zvyšuje odolnost DNS systému proti výpadk˚um nameserver˚u. Technický test domény m˚uže být vyvolán nˇejakou komponentou centrálního registru (napˇríklad fred_rifem pˇri registraci nové domény) nebo m˚uže být souˇcástí pravidelného testu všech registrovaných domén. Existuje nˇekolik test˚u, kterými m˚uže být testována doména. Jednotlivé testy jsou dále rozˇrazeny podle závažnosti do nˇekolika kategorií. Je na správci sady nameserver˚u, aby si zvolil od jaké úrovnˇe se mu mají zasílat hlášení o testech, které skonˇcily chybou. Úroveˇn testu znaˇcí závažnost podmínky, kterou testuje. Vzr˚ustající hodnota znamená menší závažnost. Nastavení úrovnˇe u nssetu na nulovou hodnotu znamená, že se nebudou provádˇet žádné testy na nameserverech. Mezi testy existují vzájemné závislosti. Napˇríklad pokud neprojde test na existenci nameserveru, nemá cenu testovat autoritativnost nameserveru a tak podobnˇe. Tyto závislosti jsou podchycené v implementaci tak, aby se nedˇelelaly zbyteˇcné testy. Technické testy jsou zadané v databázi a techcheck daemon si pˇred tím, než provádí kontrolu na doménˇe, informace o testech naˇcte. Souˇcástí záznamu o typu technického testu je i název skriptu, který kontrolu zajišt’uje. Tento skript je techcheckem spuštˇen a na základˇe návratového kódu, je urˇcen status testu. Pˇrípustné jsou tˇri výsledky: prošel, neprošel a výsledek neznámý. Neznámý výsledek nastává v pˇrípadˇe neoˇcekávané chyby pˇri testování. Každý výsledek test˚u je archivován v databázi a je tedy možné získat detailní informace o probˇehlých testech na doménˇe v minulosti. Pokud je technický test vyžádán pˇres rozhraní pro registrátory (EPP), je odpovˇed’ s výsledky test˚u zaslána asynchronˇe pomocí EPP zprávy (poll zprávy). Pokud je technický test souˇcástí pravidelné kontroly všech registrovaných domén, je zpráva o nesplnˇených testech zaslána formou emailu technickému kontaktu nssetu. Informativní RFC 1912 shrnuje nejˇcastˇejší chyby pˇri konfiguraci DNS serveru. Návrh test˚u z toho cˇ ásteˇcnˇe vychází, leˇc je mnohem pˇrísnˇejší v mnoha ohledech než informativní dokument. Zacházet pˇri testech nameserver˚u až do takových detail˚u m˚uže

50


Název testu

Závažnost

Existence nameserveru

1

Pˇrítomnost záznamu

2

Autoritativnost

3

Rekurzivní nameserver

4

Rekurzivní nameserver pro veˇrejnost

4

Autonomnost nameserver˚u

5

Heterogení software

6

Popis Testuje, jestli nameserver existuje. To znamená, že si vyžádá nˇejaký záznam z nameserveru, ale neanalyzuje odpovˇed’. Testuje, zda-li je na nameserveru pˇrítomen SOA záznam pro doménu, ke které je pˇriˇrazen. Testuje, zda-li je nameserver pro danou doménu autoritativní. Autoritativnost odpovˇedi nameserveru se pozná podle nastavení flagu v odpovˇedi. Rekurzivní nameserver zvyšuje riziko DoS útok˚u. Jestli je nameserver rekurzivní, oznamuje ve své odpovˇedi nastavením flagu. Jako pˇredchozí vysvˇetlení, leˇc ještˇe nebezpeˇcnˇejší, protože o DoS útok se m˚uže pokusit kdokoliv z internetu. V praxi by mˇel test mít stejný výsledek jako pˇredchozí. Zde se nicménˇe nespoléháme na flag nastavovaný serverem, ale pˇrímo se zeptáme na doménu, o které víme, že není spravovaná nameserverem. Testuje, jestli aspoˇn dva nameservery v nssetu jsou z r˚uzný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ˇcástí výpis˚u pro ip adresy spravované organizací RIPE. Pokud whois odpovˇed’ tento údaj neobsahuje, jsou nameservery považovány za autonomní. Testuje jestli se pro doménu používají r˚uzné DNS servery. R˚uzné implementace DNS server˚u snižují riziko napadení obou dvou nameserver˚u zároveˇn a tím znefunkˇcnˇení celé zóny.

Tabulka 5.1: Výˇcet technických test˚u a jejich úrovní

5.3. MOD_EPPD A MOD_WHOISD

51

vyvolávat diskuze. Nicménˇe právˇe z d˚uvodu, pokud správce nameserver˚u nesouhlasí s doporuˇceními CZ.NICu nebo aktuální situace mu neumožˇnuje obstát ve všech testech, je u objektu nsset atribut, jehož prostˇrednictvím si technický správce nastaví úroveˇn test˚u, které se mají provádˇet.

5.3 mod_eppd a mod_whoisd mod_eppd a mod_whoisd jsou moduly do apache httpd (zkrácenˇe nazýván apache). Apache je www server, jehož funkcionalita je rozšiˇritelná pomocí tzv. modul˚u, které jsou vˇetšinou implementovány jako sdílené knihovny, které se nahrají do procesu apache pˇri jeho startu. Moduly jsou integrovány do apache pomocí API, které je založeno na registraci tzv. hook˚u. Hook je funkce, která je zavolána v pˇrípadˇe, že nastane nˇejaká událost. Apache a jeho API je natolik universální, že lze implementovat pomocí modulu témˇeˇr jakýkoliv protokol, nejen http, pro který je apache primárnˇe urˇcen. Pˇritom se nemusíme zabývat implementací spousty vˇecí, které bychom museli ˇreš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ˇredstavuje léty provˇeˇrený 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ˇcního souboru. Modul jednoduše sdˇelí jaké konfiguraˇcní direktivy mu náleží a jejich zpracování je pˇrenecháno modulu.

• Vyˇrešení sít’ování, m˚užeme se zabývat pouze detaily aplikaˇcní vrstvy. Modul pˇrichází do styku pouze s daty, které pˇricházejí pˇres spojení. Navázání, management a ukonˇcení spojení je pˇred programátorem modulu ukryto.

• Zabezpeˇcené spojení pomocí SSL. Do apache existuje standardní module mod_ssl, který transparentnˇe, vzhledem k ostatním modul˚um, šifruje pˇríchozí a odchozí data.

• Efektivní zpracování sít’ových spojení. Každé spojení bˇeží v samostatném procesu (v pˇrípadˇe vláknového apache, v samostatném vláknu). Pomocí takzvaného preforku, což jsou pˇredpˇripravené procesy v zásobˇe, se vyrovnávají provozní špiˇcky. Poˇcet pˇredpˇripravených proces˚u se dynamicky mˇení podle oˇcekávané zátˇeže.

• Apache runtime library, která je souˇcástí apache, je knihovna obsahující množství užiteˇcných funkcí urychlujících vývoj program˚u, vˇcetnˇe dynamického alokátoru pamˇeti, který minimalizuje cˇ asté chyby pˇri práci s pamˇetí. Navíc zajišt’uje pˇrenositelnost mezi r˚uznými operaˇcními systémy.

• Spoustu drobnˇejších vˇecí, jako standardní reakce na signály, detailní zobrazení statusu serveru, ladící a debugovací možnosti, logování. Tˇežko je zde vyjmenovat všechny.

Oba dva moduly, mod_eppd a mod_whoisd, vykazují shodné charakteristiky. Oba vystupují v roli CORBA klient˚u, kteˇrí komunikují s centrálním registrem, a oba slouží zárovˇenˇ jako servery implementující rozdílné protokoly. Právˇe jejich spoleˇcná cˇ ást, role CORBA klienta, zapˇríˇcinila vznik dalšího, tˇretího modulu mod_corba, který se zabývá správou CORBA objekt˚u, které jsou distribuovány ostatním modul˚um, které je mohou využít pro volání vzdálených metod. Jedná se o podp˚urný modul, proto není zmínˇen ve schématu architektury systému. Ve všech tˇrech modulech je využívána knihovna ORBit2, implementace Object Request Brokeru pro GNOME projekt. Výbˇer byl dán tím, že ORBit2 obsahuje mapping do jazyka C, což napˇríklad omniORB využívaný v jiných komponentách nemá.

52


mod_corba získá reference na corba objekty, kterým pˇridˇelí aliasy a pˇrichytí je na strukturu reprezentující spojení. Postupnˇe, tak jak je spojení zpracovávané ostatními moduly, m˚užou nebo nemusí využít reference na objekty, které jsou jim k dispozici. Nepˇrerušovaná cˇ ára znázorˇnuje životní cyklus struktury reprezentující spojení a zvýraznˇený ú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ˇcuje 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ˇcuje jednu referenci na objekt, která má být ve správˇe mod_corba modulu. Reference je získána z CORBA nameservice pomocí zadaného jména. Pro ostatní moduly je reference pˇrístupná pod zadaným aliasem. Tato direktiva se m˚uže vyskytovat tolikrát, kolik referencí na r˚uzné objekty chceme využívat. Základem mod_eppd a mod_whoisd modul˚u 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˚um uvedeným v konfiguraci, pˇrechází spojení pod správu modulu a až do jeho uzavˇrení ve správˇe modulu z˚ustává. Moduly jsou implementací aplikaˇcní vrstvy sít’ového zásobníku. Nejdˇríve se budem zabývat modulem mod_whoisd, který je podstatnˇe ménˇe komplikovanˇejší než mod_eppd.

5.3.1 mod_whoisd Modul implementuje whois protokol tak, jak je popsaný v RFC 3912. Protokol umožˇnuje získávat informace o objektech uložených v databázi. Klient po navázání tcp spojení se serverem vyšle jednu ˇrádku ukonˇcenou znaky carriage return a line feed. Obsah ˇrádky se interpretuje jako název objektu, o kterém jsou požadovány informace. P˚uvodní whois byl velmi benevolentní, co se týˇce nakládání s informacemi. Umožˇnoval do názv˚u objekt˚u zadávat takzvaný "wildcard" znak, který nahrazuje libovolnou skupinu znak˚u. Moderní hrozby internetu, jako zneužívání tˇechto lehko dostupných informací k zasílání nevyžádané pošty, zapˇríˇcinily zúžení obsahu informací podávaných touto cestou. V souˇcasné dobˇe stále najdeme registry, kde neplatí žádné restrikce na informace poskytované pˇres whois vˇcetnˇe vyhledávání pˇres wildcardové znaky (pˇríkladem budiž pˇredchozí systém na registraci .CZ domén, který má být nahrazen fredem). Ovšem všechny nové implementace registr˚u se možnému automatizovanému zneužívání informací brání (napˇrí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˚u, která je k doménˇe pˇridružena) a nameserverech, na které je doména delegována. To jsou totiž informace nezbytnˇe nutné v pˇrípadˇe problému s technickým provozem domény. Odpovˇed’ z whoisu obsahuje také odkaz na webové stránky CZ.NICu, kde lze získat plnou informaci o doménˇe vˇcetnˇe vlastníka a administrátorských kontakt˚u. Tyto webové stránky jsou zabezpeˇceny 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ˇrejˇnování informací.


53

Obrázek znázorˇnuje funkci apache modulu mod_whoisd. Požadavek pˇricházející pˇres whois protokol je pˇrekládán na vzdálené volání metody, jejíž návratová hodnota je využita pˇri tvorbˇe odpovˇedi na whois dotaz. Funkce whois modulu do apache je soustˇredˇena 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ˇrí vˇetšinu výstupu. Komentáˇre 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: 2007-01-15T10:16:52+01:00

54

Domain: Status: Registered: Expiration:


REGISTERED 2007-01-10T15:21:11+01:00 2008-01-10

Registrant: Please visit webbased whois at http://www.nic.cz/ for more information. Registrar: Name: LRR Website: www.lrr.cz 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ˇcních direktiv: WhoisDisclaimer PATH Cesta k souboru, který obsahuje úvodní komentáˇr zobrazený v každé odpovˇedi whoisu. WhoisWebURL URL Odkaz na webové stránky, kde se m˚uže klient dozvˇedˇet bohatší informace o doménˇe. Tento link je soucˇ ástí odpovˇedi na whois dotaz v pˇrípadˇe, že se nejedná o ENUM doménu. WhoisObject ALIAS Alias, pod kterým zpˇrístupˇnuje mod_corba modul referenci na whois objekt. Pomocí tohoto aliasu je reference na whois objekt "vytažena" ze struktury reprezentující navázané spojení.

5.3.2 mod_eppd Modul mod_eppd slouží podobnému úˇcelu jako mod_whoisd. Pˇrekládá jeden protokol na druhý. Nicménˇe EPP protokol je mnohem komplikovanˇejší než whois protokol, z cˇ ehož vyplývá vˇetší rozsáhlost modulu. Komunikace pˇres EPP protokol probíhá pˇres šifrované spojení, proto s výhodou využíváme standardního mod_ssl modulu pro apache, který se pro nás transparentnˇe stará o šifrování komunikace. EPP je XML protokol, cˇ i-li požadavky a odpovˇedi jsou zapsané ve formˇe XML dokument˚u. EPP zpráva (budeme ji oznaˇcovat termínem rámec) je prefixována její délkou v bajtech, na kterou jsou vyhrazeny cˇ tyˇri bajty. Struktura XML dokument˚u je definovaná XML schématy. Modul je vnitˇrnˇe strukturován na komponenty, z nichž každá plní specifickou roli pˇri zpracování požadavku. Komponenty jsou pojmenovány podle názvu soubor˚u, 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ˇem ukryta logika zpracování EPP požadavku. Tato komponenta pro zpracování požadavk˚u používá tˇri pomocné komponenty: epp_parser.c Komponenta parsuje XML, které je jí pˇredá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ˇred 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ˇrijímá na vstupu strukturu s daty z XML dokumentu, kterou produkuje epp_parser.c. Tato data pˇrevádí do formy definované IDL souborem. Jádro cˇ innosti spoˇcí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˚um. Komponenta je postavena nad knihovnou ORBit2. epp_gen.c Komponenta na vstupu pˇrijímá strukturu, kde jsou uložena jak data z pársování XML dokumentu, tak data z výstupu volání vzdálené metody. Úˇcelem je vygenerovat XML dokument, který je odpovˇedí na zaslaný EPP požadavek. Pro sestavení výstupního XML dokumentu je opˇet použita knihovna libxml2.


55

Architektura mod_eppd modulu. Modul není monolit, ale skládá se z nˇekolika komponent, které spolu komunikují pˇres jasnˇe definovaná rozhraní. mod_eppd je konfigurovatelný pomocí následujících konfiguraˇcních direktiv: EPPschema URL URL XML schématu, které definuje EPP protokol. Je nutné pro validaci XML požadavk˚u.

56


EPPservername NAME Název tohoto serveru, který je poslán klientovi jako souˇcást greeting rámce. EPPlog FILE Modul má sv˚uj oddˇelený log soubor, kam se logují veškeré detaily EPP komunikace. V pˇrípadˇe, ž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ˇedí. Používá se pouze v testovacím provozu, protože vzniklé zpoždˇení není zanedbatelné. EPPobject ALIAS Alias, pod kterým mod_corba zprostˇredkovává pˇrí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ˇcní implementace EPP klienta vyvíjená jako souˇcást fredu. Aplikace je napsána v jazyce python a je urˇcena registrátor˚um, kteˇrí tímto zp˚usobem dostávají do rukou nástroj, kterým mohou registrovat, mazat a mˇenit objekty v registru. Registrátorské rozhraní do registru je specifikováno XML schématy, cˇ i-li nic nebrání registrátor˚um ve vytvoˇrení si vlatního EPP klienta, leˇc v drtivé vˇetšinˇe používají tuto referenˇcní implementaci. Jádro klienta tvoˇrí knihovny (v jazyce python nazývané moduly). Nad tˇemito knihovnami jsou postavená uživatelská rozhraní. V souˇcasnosti jsou to dvˇe 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ˇrí registrují domény manuálnˇe. Klient má sv˚uj konfiguraˇcní soubor v domovském adresáˇri uživatele, ve kterém lze nastavit host a port EPP serveru, SSL certifikát a privátní klíˇc, který se má použít pro pˇripojení, a množství dalších, ménˇe podstatných voleb. XML dokumenty, které se odesílají na server, jsou sestavovány pomocí DOMu (Document Object Model). Pˇríchozí XML dokumenty jsou parsovány pomocí knihovny Expat. Jak odchozí tak pˇríchozí XML dokumenty mohou být volitelnˇe validovány dle pˇríslušných XML schémat. Validace se provádí pomocí nástroje xmllint, který je souˇcástí knihovny libxml2.

Ukázka obrazovky textového rozhraní EPP klienta. V terminálu jsou viditelné dva pˇríkazy a odpovˇedi na nˇe: info-domain a check-domain.

5.4. EPP_CLIENT

57

Ukázka obrazovky grafického rozhraní EPP klienta. Záložky v první úrovni pˇredstavují typ EPP objektu a záložky ve druhé úrovni pˇríkaz nad EPP objektem. Konkrétnˇe je zobrazena odpovˇed’ na pˇríkaz info-domain.

58


Kapitola 6

ˇ Záver Projekt se ˇrídil a ˇrídí podle následujícího harmonogramu bˇrezen 2006 Zapoˇcetí projektu - analýza. duben 2006 Zapoˇcetí implementace registru. cˇ ervenec 2006 Uvolnˇení první verze pro testování registrátory. záˇrí 2006 Spuštˇení trial verze pro ENUM doménu 0.2.4.e164.arpa. leden 2007 Spuštˇení ostré verze pro ENUM doménu 0.2.4.e164.arpa. záˇrí 2007 Pˇrevod .cz domény do nového registraˇcního systému. Za dobu necelého jednoho roku, po kterou projekt trvá, se podaˇrilo splnit všechny vytyˇcené cíle v termínech. V souˇcasnosti se projekt nachází již nˇekolik mˇesíc˚u ve fázi intenzivního testování a je takˇrka pˇred uvedením do ostrého provozu. Projekt se však neustále vyvíjí a uvedením do ostrého provozu práce na nˇem nekonˇcí. Samozˇrejmˇe se musí neustále odstraˇnovat nalezené chyby, což platí pro všechny netriviální poˇcítaˇcové programy, a zmˇeny v rozhraní na základˇe zpˇetné vazby všech uživatel˚u systému, také nejsou vylouˇceny. O implementaci registru projevily vážný zájem národní registry v následujících státech: Jižní Afrika, Namíbie, ˇ Súdán, Cerná Hora. Jiné státy jmenovitˇe Gabun, Burundi, Egypt a Kanada se o implementaci registru zajímají.

6.1 Vymezení práce autora Systém fred je výsledkem kolektivní práce malého týmu programátor˚u, který pˇri jeho dokonˇcení cˇ ítal pˇet lidí. Byl jsem u zrodu tohoto projektu, kdy jsem byl jediným programátorem, až po jeho uvedení do ostrého provozu rok po jeho zapoˇcetí. Bˇehem tohoto období jsem se podílel na ˇrešení nejr˚uznˇejších problém˚u, které se vyskytly. Kromˇe všeobecného pˇrehledu o projektu jako celku a pˇrízpˇevk˚u k r˚uzným jeho cˇ ástem, jsem výhradním autorem tˇechto komponent: • mod_eppd - Implementace EPP serveru. Modul do Apache pro pˇreklad EPP požadavk˚u na volání vzdálených metod. • mod_whoisd - Implementace Whois serveru. Modul do Apache pro pˇreklad whois dotaz˚u na volání vzdálených metod. • mod_corba - Modul do Apache pro správu referencí na CORBA objekty. • pyfred - Framework pro moduly implementující CORBA objekty (servanty). • genzone - Modul do pyfredu a pˇríslušný klient pro generování zónového souboru pro nameserver. • mailer - Modul do pyfredu implementující notifikaˇcní systém registru. • techcheck - Modul do pyfredu zajišt’ující pravidelné i pˇríležitostné technické kontroly registrovaných domén. • filemanager - Modul do pyfredu pro správu soubor˚u. Primárnˇe urˇcen pro správu faktur ve formátu pdf. V rané fázi projektu jsem se významnou mˇerou podílel na návrhu databázového schematu. Jsem "patron" EPP protokolu, jakožto i autor všech jeho rozšíˇrení a úprav. Dále jsem provádˇel benchmarky databází.

59

ˇ KAPITOLA 6. ZÁVER

60

6.2 Možná budoucí vylepšení Každý program má vždy možnost být ještˇe lepší a ani systém Fred není vyjímkou, pˇrestože plní úspˇešnˇe svou funkci. Pokusím se shrnout vše, o cˇ em je v souˇcasné dobˇe známo, že v budoucnu bude (nebo by mˇelo být) vylepšeno. 1. Databázové schéma je dobˇre navrženo a nepoˇcítá se s žádnými zásadními zmˇenami, ale doposud nebyla uspokojivˇe vyˇrešena otázka proˇrezávání historických dat. Existuje teoretický návrh, nicménˇe je tˇreba provˇeˇrit ho v praxi. 2. IDL rozhraní mezi mod_eppd a fred_rif musí být pˇrepracováno, aby využívalo výhod objektovosti CORBY. V souˇcasné dobˇe je definován jeden objekt EPP, který slouží jako zprostˇredkovatel metod, ve kterých je session identifikovaná cˇ íselným prvním parametrem metod. Nový objektový návrh pˇredpokládá, že pro každou session bude vytvoˇren vlastní objekt EPP, ve kterém bude uložen veškerý kontext session. 3. Použití CAPTCHY ve webovém whoisu by nemˇelo být považováno za definitivní ˇrešení, ale mˇelo by být nahrazeno heuristikou, rozpoznávající roboty od lidí na základˇe chování na webu. 4. Postupem cˇ asu se ukázalo, že by bylo vhodné mít ještˇe jedno rozhraní pro komunikaci s registrátory a to webové rozhraní. Na portálu pro registrátory by se nezveˇrejˇnovaly pouze novinky a upozornˇení, ale pˇrímo by doplˇnovalo funkci EPP rozhraní. Napˇríklad by se pravidelnˇe generovaly soubory obsahující všechny objekty registrované daným registrátorem. Registrátor by si z pˇredem známeho URL na tomto portálu mohl pravidelnˇe stahovat tento obsáhlý (nˇekolika megabajtový) seznam a synchronizovat ho se svou lokální databází. Možné jsou i jiné funkce, které jsou nevhodné pro realizaci v EPP.

Dodatek A

ˇ databáze Výber Výbˇer databáze pro registr je d˚uležitá úloha, která se nesmí podcenit, jelikož celý registr je soustˇredˇen kolem databáze a úˇcel celého registru je spravovat data. Rychlost vybrané databáze, pak podstatnˇe ovlivˇnuje rychlost celého systému. Samozˇrejmˇe pro projekt takového rozsahu a d˚uležitosti v našich úvahách zohledˇnujeme pouze relaˇcní databáze postavené na modelu klient-server. Informace o situaci v ostatních registrech m˚uže mnohé napovˇedˇet.

Registr P˚uvodní registr CZ Afilias DENIC Nominet EURID DNS NIC.AT II Foundation DNC CODEV-NIC

Zóny .cz .org,.info .de .uk .eu .be .at .se .nz .ci,.mg

Orientaˇcní poˇcet domén 250 tisíc >31 mil, resp. >3 mil. 10 mil. >4 mil. >1,5 mil. >1 mil. >500 tis. 400 tis. >200 tis. ménˇe než 10 tis.

ENUM.AT

3.4.e164.arpa

ménˇe než 10 tis.

Databáze Informix PostgreSQL Sybase Oracle Oracle Oracle MySQL MySQL PostgreSQL PostgreSQL Oracle (výhledovˇe PostgreSQL)

Tabulka A.1: Databáze používané v ostatních registrech Hlavní otázkou je, jestli použít komerˇcní produkt nebo open-source produkt. Výbˇer možných kandidát˚u se tak zúžil na dva nejvyspˇelejší z obou kategorií: PostgreSQL a Oracle. Obˇe databáze, co se týká schopností, jsou na tom podobnˇe (trigery, uložené procedury, implementace standardu SQL). Rozhodujícím kritériem se stala tedy rychlost obou databází s pˇrihlédnutím na finanˇcní náklady. Proto byly vytvoˇreny speciální benchmarky, kde struktura databáze a SQL dotazy, co nejvíce pˇripomínaly skuteˇcný registr. Obˇe databáze byly testovány na tom samém stroji, abychom vylouˇcili vliv hardwarového vybavení. Samozˇrejmˇe nejsou d˚uležitá absolutní cˇ ísla, ale pouze srovnání obou výsledk˚u. Podaˇrilo se zmˇeˇrit následující výsledky.

Test Naplnˇení databáze 60-ti tisíci objekty 90 tisíc selekt˚u

ORACLE 34 minut 18 sekund 15 minut 40 sekund

PostgreSQL 47 minut 50 sekund 0 minut 58 sekund

Tabulka A.2: Výsledky testu rychlosti databáze ORACLE a PostgreSQL

61

62

ˇ DATABÁZE DODATEK A. VÝBER

Vytvoˇrení objektu je komplexní operace, která pˇredstavuje šest INSERT˚u. 60 tisíc objekt˚u je rovnomˇernˇe rozdˇeleno po 20 tisících na domény, kontakty, nssety. Provádˇené dotazy SELECT jsou náhodnˇe vybírány z množiny SELECT˚u používaných v centrálním registru. Obˇe databáze byly pˇri testování ponechány v defaultní konfiguraci. Vzhledem k výsledk˚um a tomu, že odhadované náklady na provoz databáze ORACLE pˇresahují jeden milión korun, byla vybrána databáze PostgreSQL. Jistˇe je na místˇe ptát se, co stojí za tak špatným výsledkem databáze ORACLE. Hlavní pˇríˇciny jsou: • Databáze byly ponechány v defaultní konfiguraci. Defaultní konfigurace PostgreSQL nahrává vˇetšinˇe zp˚usob˚u použití databáze v praxi. Naproti tomu ORACLE je už v defaultní konfiguraci optimalizován na zpracování obrovských množství dat (milióny záznam˚u v tabulkách). • Jelikož ORACLE databáze není volnˇe šiˇritelný software, byla pro testování použita trial verze této databáze, která nedosahuje kvalit plnohodnotné verze, což se mohlo podepsat i na výkonu databáze pˇri testování. • Druhá cˇ ást benchmark˚u, ve kterých ORACLE propadl, se skládala z jednoduchých SELECT˚u, kde se navíc využívalo vyhledávání podle index˚u. Je pravdˇepodobné, že PostgreSQL je na tyto jednoduché SELECTy rychlejší, naopak u ORACLE se pˇredpokládá, že je rychlejší na komplikované dotazy, kde se provádí JOINy tabulek a tak podobnˇe.

Dodatek B

CORBA Toto minimum informací je nutné pro pochopení funkce registru, který je založen na této technologii. CORBA je standard pro vzdálené volání metod. V klient-server modelu je server v podstatˇe objekt, který implementuje urˇcité metody. Tyto metody jsou popsané v IDL (interface definition language). Klient potˇrebuje mít znalost takto definovaného rozhraní, aby mohl zavolat metodu na objektu. To pak zjednodušenˇe ˇreˇceno spoˇcívá v navázání spojení se serverem, v transformaci vstupních parametr˚u dle standardu a jejich vyslání k serveru. Server provede metodu a vrátí návratovou hodnotu a výstupní parametry zpˇet klientovi. V kódu se pak jeví vzdálená volání metody jako obyˇcejné volání funkce a složitost CORBA protokolu je programátorovi skryta. Podobných standard˚u pro vzdálené volání metod/procedur existuje více, napˇríklad RPC, XML-RPC, Java RMI, SOAP. CORBA je narozdíl od nˇekterých tˇechto protokol˚u binární, což znamená, že vymˇenˇ ovaná data nejsou lidsky cˇ itelná a h˚uˇre se tak komunikace ladí, ale na druhou stranu využívá efektivnˇeji pˇrenosový kanál a je tím pádem rychlá. Aˇc je CORBA založená na konceptu objekt˚u, existují implementace i pro neobjektové jazyky (napˇríklad pro jazyk C je to ORBit). Klíˇcovým pojmem je Object Request Broker (ORB). ORB je v podstatˇe implementace standardu CORBA. V modelu klientserver pˇredstavuje ORB koncový bod komunikace na obou stranách. ORB se stará o veškerou režii, která je spojena s voláním nebo obsluhou vzdálené metody. Implementací ORB existuje velké množství, pro r˚uzné platformy, r˚uzné jazyky a vydané pod svobodnými i komerˇcními licencemi. D˚uležitá otázka zní, jakým zp˚usobem se klient dozví o bˇežícím serveru. K tomu slouží reference na CORBA objekt. Reference m˚uže být zapsána r˚uznou formou: reference zakódovaná ve stringu (IOR), corbaloc, corbaname. Zatím co corbaname a corbaloc jsou uživatelsky pˇrívˇetivˇejší formou, protože se velmi podobají URL, IOR obsahuje tu samou informaci leˇc zakódovanou do stringu a pro zobrazení údaj˚u uložených v referenci se musí použít dekoder. Obsah se však pˇríliš neliší, reference obsahuje adresu a port, kde poslouchá ORB a identifikátor objektu. Objekt˚u ve složitˇejších systémech m˚uže být spoustu a v tom pˇrípadˇe jejich správa m˚uže cˇ init problémy. Proto se s oblibou u rozsáhlejších CORBA aplikací používá CORBA nameservice, což je v podstatˇe zase CORBA objekt, který má ale standardizované rozhraní a umožˇnuje ukládat reference na objekty pod nˇejakým aliasem a co ˇ je ještˇe d˚uležitˇejší, získávat pˇres tyto aliasy uložené reference. Ci-li aplikace, která komunikuje s množstvím objekt˚u, staˇcí když má dánu pouze referenci na jediný objekt, nameservice, a pˇres tento objekt a znalost alias˚u služeb, kterých chce využívat, m˚uže získat všechny ostatní potˇrebné reference. Rozbor, zda-li CORBA je tím nejvhodnˇejším kandidátem jako základ centrálního registru, není pˇredmˇetem této práce. Proto se ani nebudem více zabývat výhodami a nevýhodami této technologie a zdržíme se jejího hodnocení.

63

64

DODATEK B. CORBA

Dodatek C

O tomto dokumentu

Live CD obsahuje také soubory nutné k vygenerování tohoto dokumentu. Zdrojový soubor tohoto dokumentu je napsán ve znaˇckovacím jazyce DocBook, který je postaven nad XML. Je tudíž editovatelný obyˇcejným textovým editorem. DocBook vyznává filosofii "single-source publishing" systému. To znamená, že zdrojový text dokumentu je napsán pouze v jednom formátu a do ostatních (výstupních) formát˚u se automatizovanˇe pˇrevádí pomocí transformaˇcního nástroje. V pˇrípadˇe XML bývá tímto transformaˇcním nástrojem xslt procesor, který byl pro tyto úˇcely vytvoˇren a je standardem W3C. Nemá smysl se zde podrobnˇe zabývat standardem pro publikování technických dokumentací DocBook, pouze si struˇcnˇe nastíníme, jak probíhá transformace ze zdrojového souboru do dvou formát˚u, ve kterých je tato práce dostupná.

Celá problematika transformace je o to komplikovanˇejší, že ke znaˇckování je použit DocBook verze 5, v souˇcasnosti nejnovˇejší verze tohoto standardu, která pˇrináší d˚uležitá vylepšení - hlavní z nich je zavedení namespacu pro DocBook znaˇcky a definice struktury dokumentu pomocí Relax-NG jazyka. Zavedení vlastního namespacu pˇrináší nespornou výhodu rozšiˇritelnosti dokument˚u psaných v DocBooku, na druhou stranu ne všechny transformátory podporují novou verzi standardu. Naštˇestí soubor XSLT šablon obsahuje i šablonu, která pˇrevede docbook dokument s namespace na identický dokument s oˇríznutým namespace. Po této transformaci mohou být úspˇešnˇe aplikovány šablony urˇcené pro starší verzi DocBook standardu. Aplikací tˇechto šablon je možné vygenerovat validní xhtml dokument.

Transformace do formátu pdf je komplikovanˇejší, protože pdf není XML jazyk tak jako xhtml. V podstatˇe jsou dvˇe cesty. Jedna vede pˇres FO procesor. Opensource FO procesory implementují bohužel pouze jen cˇ ást FO standardu a tato cesta se nakonec ukázala být neprostupná. Proto byla zvolena zbývající alternativa a to je transformovat zdrojový soubor do vstupního formátu latexu a na zpracování tohoto souboru použít už léty osvˇedˇcené a provˇeˇrené nástroje. O tuto transformaci se starají šablony, které nejsou souˇcástí DocBook šablon, ale jedná se o samostatný projekt s názvem dblatex. Nejedná se pouze o problém transformace, dblatex obsahuje i definice texovských maker, které mají rozhodující vliv na úpravu výsledného dokumentu. Tyto knihovny maker musely být pˇrizp˚usobeny specifickým požadavk˚um na vzhled diplomové práce. Menších zmˇen doznaly ale i šablony. Celý upravený balíˇcek dblatex je souˇcástí Live CD. Program pdflatex pak generuje pˇrímo pdf soubor.

65

66

DODATEK C. O TOMTO DOKUMENTU

Ke generování dokumentu pdf se používá tradiˇcní unixový nástroj Makefile. Procesy, které se odehrávají v Makefilu pˇri generování cíl˚u, jsou znázornˇeny na obrázku. V oblých rámeˇccích jsou vyznaˇceny zdroje, v rámeˇccích podbarvených šedˇe jsou vyznaˇceny transformaˇcní prvky a v kroužcích jsou výstupní formáty. Pro tvorbu tohoto dokumentu byly použity následující nástroje: • Vim - Editování zdrojových soubor˚u. • XFig - Kreslení vektorových obrázk˚u. • xsltproc - Na místˇe xslt procesoru. • DocBook XSLT - DocBook šablony pro transformace. • dblatex - Šablony a TeX makra pro generování pdf. • latex - Latex s podporou unicodu.

Dodatek D

CD pˇrílohy

Souˇcástí diplomové práce jsou dvˇe CD. Jedno je nadepsané "Fred Live CD" a druhé "Sources". První je bootovatelné CD pro pocˇ ítaˇcovou architekturu x86 s operaˇcním systémem založeném na jádˇre Linux a distribucí odvozenou od známé linuxové distribuce Slackware. Pˇri startu systému z CD jsou po nahrání jádra do pamˇeti startovány jednotlivé služby. Mezi nimi i služba s názvem fred, která pˇredstavuje úplný registraˇcní systém se všemi jeho komponentami. Spuštˇení této služny pˇri startu pˇredstavuje napˇríklad spuštˇení Apache httpd serveru a PostgreSQL serveru, proto spuštˇení této služby trvá relativnˇe déle, než je tomu u ostatních služeb. Po spuštˇení všech služeb pˇrejde systém z textového do grafického módu spuštˇením X serveru. Session zaˇcíná se spuštˇeným terminálem a www browserem na ploše. Implicitnˇe jsou v databázi pˇrítomné zóny cz, 0.2.4.e164.arpa a 0.2.4.c.e164.arpa, ve kterých je možné zakládat nové domény a manipulovat s nimi pˇres protokol EPP. EPP klient se spouští z pˇríkazové ˇrádky. Registr obsahuje pˇri startu tˇri registrované objekty: doménu s názvem test.cz, kontakt s identifikátorem CID:CTEST a nsset s identifikátorem NSSID:NTEST. Startovní stránka zobrazená v prohlížeˇci podává v angliˇctinˇe návod, jak otestovat základní funkcionalitu registru. Každou minutu jsou generované všechny spravované zóny a naˇcteny DNS serverem BIND.

Live CD bylo vyvinuto jako souˇcást projektu fred pro úˇcely demonstrace registraˇcního systému pˇri nejr˚uznˇejších pˇríležitostech, zejména na konferencích v zahraniˇcí. Verze registru na live CD je zhruba o dva mˇesíce starší, než aktuální verze registru v dobˇe publikace diplomové práce. Je tˇreba mít na pamˇeti, že CD není urˇceno pro dlouhodobé provozování registru, ale pouze jako demonstrace registraˇcního systému. Pˇri provozu registru je totiž generováno pomˇernˇe velké množství log hlášek, které mohou v ˇrádu hodin až dní (v závislosti na dostupné operaˇcní pamˇeti) zaplnit operaˇcní pamˇet’ poˇcítaˇce.

Druhé CD obsahuje zdrojové soubory projektu, zdrojové soubory tohoto dokumentu a instalaˇcní balíˇcky pro linuxovou distribuci Debian. Zdrojový kód systému je spravován pomocí nástroje subversion, který je velmi podobný programu CVS, nicménˇe odstranˇ uje nˇekteré jeho známé nedostatky. Hned pod koˇrenovým adresáˇrem repozitáˇre se nacházejí adresáˇre jednotlivých komponent, z kterých se projekt skládá. Každá z tˇechto komponent má své verzování, tagy a vˇetve. Nicménˇe pro snadnˇejší orientaci se verzuje i projekt jako celek. Soubor, který mapuje celkovou verzi na jednotlivé verze komponent, se jmenuje RELEASES. Na CD jsou zdrojové soubory získané pˇríkazem svn export a jedná se o verzi systému, která byla nasazená koncem ledna pˇri spuštˇení ostrého provozu. Popíšeme si umístˇení komponent, kterými jsme se zabývali, v adresáˇrové struktuˇre repozitáˇre. Dokumentace formou README soubor˚u nebo html je obsažená u jednotlivých komponent.

67

ˇ DODATEK D. CD PRÍLOHY

68

Náˇcrtek struktury repozitáˇre zdrojových soubor˚u projektu. db Adresáˇr db obsahuje databázová schemata na vytvoˇrení a základní inicializaci databáze. idl Obsahuje definice všech CORBA rozhraní v IDL. Ostatní komponenty se odkazují na pˇríslušné soubory pˇres symbolické linky, nastavením promˇených v Makefile souborech nebo zadáním parametru configure skriptu. ccreg_server Zahrnuje cˇ ást centrálního registru napsanou v C++. To znamená fred_pif, fred_rif a fred_adif. pyfred Zahrnuje cˇ ást centrálního registru napsanou v jazyce Python. V podadresáˇri server se nachází framework pyfred a jednotlivé moduly genzone, filemanager, mailer a techcheck. Klienti k server˚um, které jsou realizované jednolivými moduly, jsou v podadresáˇri clients v samostatných adresáˇrích. Podadresáˇr share obsahuje Makefile, který obsahuje instalaˇcní instrukce a generuje staticky pythoní moduly na základˇe IDL soubor˚u. mod_eppd Obsahuje zdrojové soubory modulu mod_eppd do Apache a XML schémata, jež definují EPP protokol a jeho rozšíˇrení. mod_whoisd Obsahuje zdrojové soubory modulu mod_whoisd do Apache. mod_corba Obsahuje zdrojové soubory modulu mod_corba do Apache, na kterém závisejí mod_eppd a mod_whoisd. cherry_admin Webová aplikace psaná v pythoním frameworku cherrypy realizující front-end k administrátorskému rozhraní registru. whois Webový whois postavený na modulu do Apache mod_python. epp_client Referenˇcní implementace EPP klienta. Obsahuje textové i grafické rozhraní klienta a unit testy, kterými se testuje správná funkˇcnost registru. fred2pdf Program na tvorbu pdf faktur. Na vstupu pˇrijíma data strukturovaná pomocí XML a na výstupu produkuje pdf dokument. Tato komponenta je pomˇernˇe nová a je považována zatím za experimentální. Instalaˇcní balíˇcky mají sv˚uj vlastní README, kde je popsán jejich obsah.

Dodatek E

Bibliografie [RFC1034]

P. Mockapetris, Domain names - concepts and facilities

[RFC1912]

D. Barr, Common DNS Operational and Configuration Errors

[RFC2387]

E. Levinson, The MIME Multipart/Related Content-type

[RFC2825]

Internet Architecture Board, A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols

[RFC2915]

M. Mealling a R. Daniel, The Naming Authority Pointer (NAPTR) DNS Resource Record

[RFC3245]

J. Klensin, The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)

[RFC3467]

J. Klensin, Role of the Domain Name System (DNS)

[RFC3730]

S. Hollenbeck, Extensible Provisioning Protocol (EPP)

[RFC3731]

S. Hollenbeck, Extensible Provisioning Protocol (EPP) Domain Name Mapping

[RFC3732]

S. Hollenbeck, Extensible Provisioning Protocol (EPP) Host Mapping

[RFC3733]

S. Hollenbeck, Extensible Provisioning Protocol (EPP) Contact Mapping

[RFC3734]

S. Hollenbeck, Extensible Provisioning Protocol (EPP) Transport Over TCP

[RFC3735]

S. Hollenbeck, Guidelines for Extending the Extensible Provisioning Protocol (EPP)

[RFC3761]

P. Faltstrom, The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)

[RFC3912]

L. Daigle, WHOIS Protocol Specification

69

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

Recommend Documents