BAKALÁŘSKÁ PRÁCE
Systém pro registraci a správu DNS domén druhého řádu
2015
Jan Baroš
Vedoucí práce: Mgr. Jan Outrata, Ph.D.
Studijní obor: Aplikovaná informatika, kombinovaná forma
Bibliografické údaje Autor:
Jan Baroš
Název práce:
Systém pro registraci a správu DNS domén druhého řádu
Typ práce:
bakalářská práce
Pracoviště:
Katedra informatiky, Přírodovědecká fakulta, Univerzita Palackého v Olomouci
Rok obhajoby:
2015
Studijní obor:
Aplikovaná informatika, kombinovaná forma
Vedoucí práce:
Mgr. Jan Outrata, Ph.D.
Počet stran:
47
Přílohy:
1 CD/DVD
Jazyk práce:
český
Bibliograhic info Author:
Jan Baroš
Title:
System of second level DNS domain registration and management
Thesis type:
bachelor thesis
Department:
Department of Computer Science, Faculty of Science, Palacký University Olomouc
Year of defense:
2015
Study field:
Applied Computer Science, combined form
Supervisor:
Mgr. Jan Outrata, Ph.D.
Page count:
47
Supplements:
1 CD/DVD
Thesis language:
Czech
Anotace Cílem práce bylo vytvořit program pro usnadnění úkonů spojených s registrací a správou DNS domén 2. řádu. Program byl vytvořen jako řešení pro registrátora ProfiHOSTING s.r.o. pokrývající potřeby společnosti a jejich zákazníků, včetně spojených administrativních úkonů.
Synopsis The main goal of the thesis was to create a program to make registration and management of second level domain names more feasible. The program has been created as a solution for registrar ProfiHOSTING s.r.o. while covering the needs of the company and their customers, including related administrative tasks.
Klíčová slova: doména, doménové jméno, tld, registr, registrátor, technický správce, DNS server, skupina DNS serverů Keywords: domain, domain name, tld, registry, registrar, technical contact, DNS server, DNS server group
Rád bych poděkoval za vedení mé práce panu Mgr. Janu Outratovi, Ph.D, za podnětné připomínky a doporučení, které měly na samotnou práci velký vliv. Dále děkuji zástupcům společnosti ProfiHOSTING s.r.o., paní Ivetě Brixové a panu Tomášovi Vrbickému za laskavé poskytnutí součinnosti, přístupu k dokumentačním materiálům, přístupů na testovací servery registrů a virtualizovaného serveru pro testovací provoz programu. V neposlední řadě děkuji své nastávající manželce Mgr. Gabriele Večerkové za neskutečnou trpělivost a podporu i v těch nejkritičtějších chvílích.
Místopřísežně prohlašuji, že jsem celou práci včetně příloh vypracoval samostatně a za použití pouze zdrojů citovaných v textu práce a uvedených v seznamu literatury.
datum odevzdání práce
podpis autora
Obsah 1 Úvod 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Představení profilu společnosti ProfiHOSTING s.r.o. . . . . . . . . 2 Úvod do problematiky domén 2.1 Doména prvního a druhého řádu 2.2 Princip delegace . . . . . . . . . . 2.3 Životní cyklus domény . . . . . . 2.4 Podpora IDN . . . . . . . . . . .
7 7 7
. . . .
. . . .
9 . 9 . 10 . 12 . 14
3 Popis elektronické komunikace s registry CZNIC a EURid 3.1 Autentizace a zabezpečení . . . . . . . . . . . . . . . . . . . . 3.2 Správa kontaktů . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Správa kontaktů v registru CZNIC . . . . . . . . . . . 3.2.2 Správa kontaktů v registru EURid . . . . . . . . . . . . 3.3 Správa domén . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Správa domén v registru CZNIC . . . . . . . . . . . . . 3.3.2 Správa domén v registru EURid . . . . . . . . . . . . . 3.4 Správa skupin DNS serverů . . . . . . . . . . . . . . . . . . . 3.4.1 Správa skupin DNS serverů v registru CZNIC . . . . . 3.4.2 Správa skupin DNS serverů v registru EURid . . . . . 3.5 Poskytované údaje o účtu registrátora . . . . . . . . . . . . . . 3.6 Zprávy zasílané registrem registrátorovi . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
16 17 17 18 18 19 19 19 19 20 20 20 20
. . . . . . . . . . . . . . .
22 22 22 25 29 29 31 32 33 34 35 35 38 41 41 42
. . . .
. . . .
. . . .
. . . .
. . . .
4 Implementace 4.1 Použité technologie a programy . . . . . . 4.2 Návrh architektury programu . . . . . . . 4.3 Popis implementace komunikace s registry 4.4 Popis jednotlivých fasád . . . . . . . . . . 4.4.1 ValueObject a CommandObject . . 4.4.2 Fasáda DomainContactFacade . . . 4.4.3 Fasáda DomainNSSetFacade . . . . 4.4.4 Fasáda DomainNameFacade . . . . 4.4.5 Fasáda InvoicingOrderFacade . . . 4.4.6 Fasáda InvoicingPricelistFacade . . 4.5 Schéma databáze a komunikace s databází 4.6 Zabezpečení programu . . . . . . . . . . . 4.7 Popis webového rozhraní programu . . . . 4.8 Testování programu . . . . . . . . . . . . . 4.9 Instalace programu a požadavky na server Závěr
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
44
5
Conclusions
45
A Obsah přiloženého CD/DVD
46
Bibliografie
47
6
1 1.1
Úvod Motivace
Porozumění problematice registrace a správy DNS domén druhé úrovně je dnes stále vlastní jen odborné veřejnosti. Velká část vlastníků webových stránek má problém pochopit, proč je jim účtován registrační poplatek domény navíc ke službám webhostingu. Navzdory snaze správců registrů popularizovat toto téma, např. v podobě TV spotů “Jak na internet” provozovatele registru CZNIC, se situace nelepší. Stále je patrná velká režie přenesená na zaměstnance registrátorů spojená s jednoduchými administrativními úkony a velmi nízká samostatnost vlastníků DNS domén. Část viny nese složitost problematiky samotné, druhým viníkem jsou příliš složité nebo z hlediska uživatelského rozhraní překomplikované programy poskytované samotnými registrátory. Další kapitolou jsou pak nástroje, které mají zaměstnanci registrátorů k dispozici pro zajištění správy DNS domén. Pokud společnost registrátora nezainvestovala do vlastního vývoje administračního systému, musí své procesy přizpůsobit nástrojům poskytovaným přímo samotnými registry. Je zřejmé, že v takovém případě se nutně musí část režie s administrativními úkony přenést na vlastníky domén a komunikace mezi nimi a registrátorem se takto značně ztíží. Cílem práce je navrhnout a implementovat program DNMS (Domain Name Management System), který poskytne prostředky pro běžné administrativní úkony spojené se správou DNS domén pro potřeby zaměstnance registrátora, velkoobchodního zákazníka (tj. přeprodejce služeb registrátora, tzv. subregistrátor) a stejně tak i pro vlastníka domény. Důraz je přitom kladen na jednoduchost a přehlednost programu. Program by měl implementovat on-line komunikaci s registrem české domény .cz a evropské .eu, přičemž uživatel by neměl být příliš vystaven odlišnostem obou registrů a administrativní úkony by měly být maximálně zjednodušeny. Stejně tak by program měl být navržen s výhledem na přidání podpory dalších registrů. Vedlejšími požadavky jsou příprava na fakturaci a úhrada administrativního úkonu formou kreditu.
1.2
Představení profilu společnosti ProfiHOSTING s.r.o.
Společnost Profihosting s.r.o. je provozovatelem webhostingových služeb ProfiWH.cz a zároveň je akreditovaných registrátorem domén .cz a .eu. V jeho portfóliu se nachází cca 7 000 aktivních domén, z čehož necelých 6 000 činí domény registru .cz. Společnost sídlí v Olomouci, ale mezi svými zákazníky má i zahraniční webová studia. Akreditovaným registrátorem .eu domén je již od veřejného spuštění registru (tzv. fáze landrush), takže se podílel na prvních registracích .eu domén vůbec. „Realizací daného programu by došlo ke značné úspoře času a práce spojené se správou domén a to zejména domén typu .cz a .eu. Většina pracovních úkonů se zabývá ze 70% registrací, prodloužením či změnami (majitele nebo DNS) u domén. Každá prováděná změna je podmíněna použitím určitého a často i kompliko7
vaného příkazu ve speciálním programu poskytovaným přímo registrem .cz domén CZ.NIC. Pro .eu domény je nutno se přihlašovat do webového administračního nástroje registru (http://www.registry.eu). Tímto by došlo ke zjednodušení práce s doménami, kdy bychom pouze zadávali požadovanou změnu v rámci jednoho vlastního systému. Doplnění programu o nápovědu by dopomohlo i k širšímu využití ze strany zákazníka, tj. zákazník by byl schopen sám zadávat registrace a změny u domén. Došlo by tak ke zjednodušení celého procesu a urychlení komunikace se zákazníkem. Vysvětlením jednotlivých pojmů by zákazník pochopil, co je po něm požadováno, a do budoucna by již věděl, jak může sám provést základní změny.“ Iveta Brixová, Doménová specialistka společnosti ProfiHOSTING s.r.o.
8
2
Úvod do problematiky domén
2.1
Doména prvního a druhého řádu
Doména je stěžejním prvkem symbolické adresace uzlů v internetu. Doménové jméno vyjadřuje příslušnost k nadřazené doméně a plně kvalifikované jméno je vždy unikátní v rámci celého internetu. Adresace serverů v internetu je realizována pomocí unikátních veřejných IP adres. Pomocí IP adresy je možné komunikovat s jakýmkoli serverem a službou na internetu. Tato adresace je nepraktická pro člověka, seznam IP adres se velice špatně pamatuje, proto byl zaveden mechanismus pro překlad symbolických jmen na IP adresy a zpět. Tento mechanismus byl nazván DNS (Domain Name System). DNS umožňuje přiřadit symbolické jméno k jedné nebo více IP adresám, toto symbolické jméno se nazývá doménové jméno. Aby bylo možné zajistit unikátnost doménových jmen v internetu, byla doménová jména rozdělena na domény jednotlivých úrovní, která se oddělují tečkou a jejichž celý zápis za sebou tvoří plně kvalifikované doménové jméno (např. www.seznam.cz). Jednotlivé úrovně jsou číslovány zprava doleva, poslední část je tedy doména 1. úrovně nebo také nejvyšší úrovně (TLD - Top Level Domain), podle příkladu “cz”. Následuje doména 2. úrovně (SLD Second Level Domain), podle příkladu “seznam”. Doména “www” se pak nazývá 3. úrovní atd.
Obrázek 1: Hierarchické zobrazení struktury domén jednotlivých úrovní „Kořen doménového stromu pak obsahuje veškeré informace o všech TLD. Každé z těchto TLD má pak svůj registr všech svých SLD domén. Každá z těchto domén druhého řádu má svůj seznam domén třetího řádu atd. Na stejném principu roste doménový strom až do libovolného řádu. Informace o každé doméně je fyzicky uložena na DNS serveru, který eviduje jednotlivé záznamy o IP adresách nebo pouze odkazy na další DNS servery, které následují pro danou doménu v 9
doménovém stromu, tzv. delegace.“ [5] Domény nejvyšší úrovně se dále dělí na: • generické (gTLD) - např. com pro komerční subjekty, org pro nevládní organizace • sponzorované (sTLD) - např. aero, asia, gov, int, jobs • národní (označujeme ccTLD - Country Code Top Level Domain) - např. cz, sk • rezervované - např. localhost, example, test TLD domény přiděluje nadnárodní organizace ICANN (Internet Corporation for Assigned Names and Numbers). Tato organizace deleguje správu jednotlivých TLD registrů na regionální a lokální správce, které označuje jako NIC (Network Information Center). Pro registr domény .cz je tímto správcem organizace CZ.NIC a pro registr domény .eu je jím organizace EURid.
2.2
Princip delegace
Delegace obecně znamená pověření nějakou rolí nebo funkcí. V případě domén se jedná o pověření přijímat DNS dotazy a posílat DNS odpovědi o IP adresách přiřazených k dané doméně. Proces delegace prochází jednotlivými úrovněmi domén až najde DNS server, který spravuje požadovanou doménu. DNS servery delegujicí zodpovědnost za každou úroveň odpovídají pouze formou NS vět. V některých případech doplněných o věty A (pro IPv4) nebo AAAA (pro IPv6) s IP adresami delegovaných DNS serverů. Zatímco DNS server hledaného doménového jména odpovídá i dalšími typy DNS vět pro danou doménu. Organizace ICANN deleguje správu TLD domén na regionální a lokální správce registrů, ti pak delegují správu domén druhého řádu na smluvní partnery, které označují za registrátory. Registrátoři pak delegují správu domén třetího a nižšího řádu na vlastníky související domény, respektive jejich poskytovatele webhostingu (ISP). Technicky je tento proces realizován prostřednictvím DNS serverů, které jsou určeny pro domény na jednotlivých úrovních. Celý proces začíná u kořenových DNS serverů, které jsou přiřazeny ke kořenové doméně “.”. Seznam kořenových DNS serverů je veřejně znám a dostupný v podobě seznamu IP adres a mění se pouze výjimečně, protože je na nich závislý celý internet. Kořenová zóna, která je umístěna na těchto serverech, obsahuje seznam všech TLD a k nim přiřazených DNS serverů odpovídajících registrů. ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: 10
. . . . . . . . . . . . .
415551 415551 415551 415551 415551 415551 415551 415551 415551 415551 415551 415551 415551
IN IN IN IN IN IN IN IN IN IN IN IN IN
NS NS NS NS NS NS NS NS NS NS NS NS NS
m.root-servers.net. k.root-servers.net. h.root-servers.net. e.root-servers.net. l.root-servers.net. a.root-servers.net. j.root-servers.net. g.root-servers.net. c.root-servers.net. b.root-servers.net. f.root-servers.net. d.root-servers.net. i.root-servers.net.
Příklad části DNS odpovědi na dotaz na kořenové servery, čili na doménu “.”.1 ;; QUESTION SECTION: ;cz. IN NS ;; AUTHORITY SECTION: cz. 172800 IN NS d.ns.nic.cz. cz. 172800 IN NS c.ns.nic.cz. cz. 172800 IN NS b.ns.nic.cz. cz. 172800 IN NS a.ns.nic.cz. Příklad části odpovědi kořenového DNS serveru na dotaz na doménu “cz”. Ve stejném duchu odpovídají DNS servery TLD registrů na dotazy na domény druhé úrovně, přičemž v odpovědi vrací seznam DNS serverů ISP, který danou doménu spravuje (dále také technický správce). Tyto DNS servery již nemusí delegovat dále domény nižší úrovně ale mohou přímo odpovídat i na dotazy ostatních typů, které již vracejí tazatelem požadované IP adresy. ;; QUESTION SECTION: ;seznam.cz. IN NS ;; AUTHORITY SECTION: seznam.cz. 18000 IN NS ans.seznam.cz. seznam.cz. 18000 IN NS ams.seznam.cz. Příklad části odpovědi DNS serveru registru CZNIC na dotaz na doménu seznam.cz. 1
Jedná se o neautoritativní odpověď z DNS serveru poskytovatele (neautoritativní znamená převzatá). Každý správně nakonfigurovaný DNS server provádějící rekurzivní dotazy má lokálně uloženu zónu “.” s těmito záznamy, proto je schopen na takovýto dotaz odpovědět obratem bez nutnosti doptávat se dalších DNS serverů.
11
;; QUESTION SECTION: ;seznam.cz. IN A ;; ANSWER SECTION: seznam.cz. 300 IN A 77.75.76.3 Příklad části odpovědi DNS serveru společnosti Seznam a.s. na dotaz na doménu seznam.cz. 2 Registrátoři zodpovídají za správu přiřazených domén druhé úrovně vůči odpovídajícímu registru TLD, řídí se jejich pravidly a provádějí požadavky vlastníků domén, případně dalších zprostředkovatelů (tj. subregistrátor, např. webové studio).
2.3
Životní cyklus domény
Životní cyklus domény začíná její registrací a zpravidla končí opětovným uvolněním k registraci pro nové zájemce po vypršení ochranné lhůty. Datem registrace je pak den, kdy byla doména zaregistrována v odpovídajícím registru. Datem expirace se rozumí poslední den lhůty, na kterou byla doména zaregistrována. Dobu registrace pak ovlivňují akce jako samotná registrace domény, prodloužení platnosti nebo v případě registru Eurid změna registrátora. Ochranná lhůta Délka ochranné lhůty a její průběh se u jednotlivých registrů liší, ale v obecné definici se neliší. Ochranná lhůta začíná dnem následujícím po dni expirace domény, po jejímž vypršení je doména uvolněna pro další případnou registraci. Registr CZNIC zavádí ochrannou lhůtu v délce 60 dní, přičemž po uplynutí prvních 30ti dní je zrušena delegace domény (obr. 2). Registr EURid zavádí ochrannou lhůtu v délce 40 dní, přičemž je delegace domény zrušena již na na jejím začátku (obr.3). Registrace domény Registrace probíhá vždy prostřednictvím registrátora na celé násobky roku počínaje datem registrace. Maximální délka registrace je pro oba registry 10 let. Za registraci je účtován registrační poplatek v závislosti na délce registrace. 2
Všimněte si, že odpovídá IP adresou webového serveru, což je odpověď na kterou čeká internetový prohlížeč, aby zobrazil webovou stránku vyhledávače. Tady pomyslný řetěz delegací končí, evidentně nedochází k dalšímu delegování.
12
Prodloužení platnosti domény Doba zbývající do expirace domény se nazývá doba registrace, či doba platnosti. Dobu registrace lze kdykoli a opakovaně prodloužit v celých násobcích roku až na 10 let. Tato akce je rovněž zpoplatněna v závislosti na délce prodloužení. Změna registrátora(transfer) V průběhu doby registrace domény může vlastník kdykoli změnit registrátora. Registr CZNIC změnu provede bezplatně a bez jakéhokoli dopadu na délku registrace domény. U registru EURid je změna zpoplatněna a souvisí s ní automatické prodloužení doby registrace o jeden rok. Den expirace zůstává nezměněn, pouze se zvýší o jeden rok nezávisle na tom, kdy došlo ke změně registrátora. Smazání domény Smazáním domény lze doménu uvést předčasně do ochranné lhůty, aniž by došlo ke změně data expirace. Tato funkce se prakticky využívá jen ve výjimečných případech, zpravidla se doména nechá přirozeně přejít do ochranné lhůty a následně je smazána automaticky.
Obrázek 2: Registr CZNIC zavádí ochrannou lhůtu v délce 60 dní, přičemž po uplynutí prvních 30 dní je zrušena delegace domény. Změna registrátora nemá vliv na délku registrace domény.
13
Obrázek 3: Registr EURid zavádí ochrannou lhůtu v délce 40 dní, přičemž je delegace domény zrušena již na na jejím začátku. Změna registrátora vede k prodloužení doby registrace o 1 rok.
2.4
Podpora IDN
Podpora IDN (Internationalized Domain Name - RFC 3490, 3491, 3492 a 3454) znamená podporu znaků národních abeced v názvu domén. V případě české abecedy se jedná o diakritiku, tedy háčky a čárky. Oba registry již technicky tuto podporu mají zavedenu, pouze CZNIC ji dosud neuvedl v platnost. Důvodem je dlouholetý nezájem české internetové komunity. IDN je např. běžným standardem také v Německu u jejich národní domény .de. Překlad IDN domén Překlad internacionalizovaných domén probíhá formou překladu na ASCI reprezentaci již na úrovni internetového prohlížeče, který dále veškeré dotazy na jmenné servery provádí pomocí této formy. Tato forma se nazývá ACE řetězec (ASCII Compatible Encoding) a proces překladu se nazývá "punycode" a je doplněn o funkci "nameprep", která provede převod na kanonický tvar dle národnostních specifik. Některé národní abecedy mohou obsahovat např. vzájemně zaměnitelné znaky. U české abecedy by tato funkce pouze převáděla velká písma na malé. Samotný proces překladu "punycode" probíhá ve třech krocích: 1. Na začátek přeloženého řetězce se vloží předpona "xn−−", čímž je signalizováno, že jde o IDN doménu. 2. Všechny čistě ASCII znaky zůstanou beze změny. 3. Zaznamená se pozice ne-ASCI znaků a jejich ASCI překlad se připojí na konec. Příklad IDN domény: bücher.ch - doména v unicode 14
xn–bcher-kva.ch - ACE string, který je použit pro dotazy na DNS Registr, který nepodporuje IDN takovýto formát domény zpravidla nepovolí zaregistrovat kvůli dvěma pomlčkám za sebou. Podpora IDN v prohlížečích IDN domény jsou podporovány v prohlížečích ve verzích, které jsou dnes již dávno překonané, proto lze předpokládat, že veškeré moderní prohlížeče budou rovněž podporou disponovat. Microsoft Internet Explorer 7 a vyšší Microsoft Internet Explorer 5 a 6 s iNav pluginem od VeriSign Firefox od verze 0.8 Opera od verze 7.11 Safari od verze 1.2 (Mac OS X 10.3) Konqueror (Linux, KDE 3.2 a vyšší, s GNU IDN knihovnou) Seznam minimálních verzí prohlížečů převzat z [3]. Problémy spojené se zavedením IDN Problémy, které přicházejí se zavedením různých národních abeced do domén, souvisejí se zaměnitelností některých stejně nebo podobně vypadajících znaků. Kromě znaků „I“ (velké i) a „l“ (malé L) a „0“ (číslice nula) a „O“ (velké o), které jsou v některých fontech opticky zaměnitelné již v základní latince, přibývá celá řada znaků s podobnými vlastnostmi napříč národními abecedami (např. řecké „o“ a „o“ v latince). Těmto neduhům lze částečně čelit omezením na výčet povolených znaků a danou abecedu u národních TLD. Toto omezení by pravděpodobně implementoval i registr CZNIC. Nedává smysl registrovat doménu např. v azbuce na doméně .cz. Registr EURid implementoval výše zmíněné omezení, ale s ohledem na národní abecedy všech členských států v roce 2008 spolu se spuštěním podpory IDN. V roce 2015 registr uveřejnil aktualizaci a implementoval do svého systému mechanismus, který blokuje možnost registrovat doménu, jež může být výše zmíněnou metodou zaměněna za některou z již registrovaných. CZNIC a IDN Registr CZNIC má technicky implementovanou podporu IDN již od počátku vývoje svého registračního systému FRED [4] a od roku 2004 provádí průzkumy trhu vždy v dvouletých intervalech a vždy se stejným výsledkem. Česká uživatelská komunita nemá o zavedení IDN pro českou doménu .CZ zájem. V rámci popularizační kampaně spustil CZNIC webovou prezentaci www.háčkyčárky.cz, kde vysvětluje potenciál a úskalí IDN.
15
3
Popis elektronické komunikace s registry CZNIC a EURid
Elektronická komunikace mezi registrem a programem registrátora probíhá prostřednictvím protokolu EPP na bázi XML zpráv. Registr CZNIC i EURid využívá pro komunikaci svůj vlastní systém. Elektronická komunikace mezi systémy registru a registrátora probíhá prostřednictvím protokolu EPP (Extensive Provisioning Protokol, dle RFC 3730) na transportní vrstvě TCP/IP (RFC 3734). Veškerá komunikace je šifrována prostřednictvím SSL. Oba registry disponují vlastními implementacemi systému registru. Registr CZNIC navíc svůj systém FRED[4] uvolnil pro veřejnost jako OpenSource a byl dosud nasazen i u několika dalších národních registrů (např. v Estonsku, Makedonii apod.). Veškerá komunikace probíhá ve formě série příkazů a odpovědí. 1 2 3 4 5 6 7 8 9
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<domain:check> <domain:name>andalucia.eu
Zdrojový kód 1: Příklad příkazu (check domain - dotaz na dostupnost domény)
16
1 2 3 4 5 6 7 8 9 10 11 12 13 14
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:domain-ext="http ://www.eurid.eu/xml/epp/ domain-ext-1.1" xmlns:idn="http://www.eurid.eu/xml/epp/idn-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<msg>Command completed successfully <domain:chkData> <domain:cd> <domain:name avail="false">andalucia.eu <domain:reason lang="en">reserved
Zdrojový kód 2: Příklad odpovědi (doména není volná pro registraci)
Kromě EPP serveru zpřístupňují oba registrátoři služby WHOIS a samozřejmě DNS servery pro delegaci domén. Registr EURid navíc zpřístupňuje službu DAS pro přímé dotazovaní výhradně na dostupnost domén pro registraci. Tato služba je vhodná pro masivní dotazování, které může probíhat např. ve chvíli, kdy má být uvolněna atraktivní doména pro novou registraci. V takové chvíli by zainteresovaní registrátoři nadměrně vytěžovali EPP server přílišným množstvím dotazů na dostupnost této domény. Služba DAS je daleko jednodušší a nevyžaduje takové množství systémových prostředků jako EPP server.
3.1
Autentizace a zabezpečení
Komunikace s registrem podléhá přihlášení ihned po započetí spojení a přijetí uvítací zprávy (tzv. hello). Přihlášení probíhá prostřednictvím příkazu Login a přiděleného uživatelského jména a hesla. Na konci spojení je vhodné provést rovněž odhlášení příkazem Logout. Oba registry implementují další úroveň zabezpečení. Registr CZNIC vyžaduje započetí spojení s využitím SSL autentizace prostřednictvím certifikátu registrátora, zatímco registr EURid povoluje otevření spojení pouze z předem známých IP adres registrátora.
3.2
Správa kontaktů
Kontakt je stěžejním prvkem registru, na který jsou následně navázány domény. Kontakt je reprezentován seznamem informací o fyzické nebo právnické osobě. Kromě základních informací jako je jméno, adresa nebo tel. číslo a e-mail,
17
může obsahovat další informace jako DIČ, jazyk pro komunikaci apod. Implementace kontaktů a série příkazů pro práci s nimi se u obou registrů zásadně liší. Správu kontaktů prostřednictvím protokolu EPP popisuje RFC 3733. 3.2.1
Správa kontaktů v registru CZNIC
Registr CZNIC zavádí kontakt jako sdílenou entitu napříč celým registrem. Jakýkoli registrátor může tedy tento kontakt přiřadit ke své doméně. Kontakt je možné přiřadit ve všech možných podobách (tj. jako vlastníka domény, či administrativní nebo technický kontakt). Změny kontaktu má oprávnění provádět pouze registrátor-vlastník kontaktu. Změnu takového registrátora lze pak provést příkazem pro transfer kontaktu. Kromě tohoto příkazu registr implementuje standardní sérii příkazů na vytvoření, aktualizaci, ověření existence, zobrazení informaci o kontaktu a smazání. Registr dále přidává nad rámec běžné EPP komunikace příkaz-dotaz na seznam kontaktů ve správě daného registrátora a kromě možnosti uvést DIČ (VAT), přidává jako položku kontaktu také osobní identifikační číslo a jeho typ (č. OP, č. pasu nebo datum narození). Rovněž také nahrazuje dvě poštovní adresy jednou jedinou. 3.2.2
Správa kontaktů v registru EURid
Registr EURid zavádí kontakt jako entitu, která je specifická pro každého registrátora. Jednotlivé kontakty tedy nejsou mezi registrátory sdíleny a tedy v důsledku při změně registrátora domény musejí být odpovídající kontakty znovu vytvořený u nového registrátora. Registr EURid navíc zavádí specifické typy kontaktů. Podle typu kontaktu jsou pak určeny povinné informace při vytváření kontaktu (např. položka číslo faxu u kontaktu technického správce) a jakým způsobem lze kontakt použít (přiřadit). Registr zavádí následující typy kontaktů: • Vlastník domény (registrant) - Může být přiřazen k doméně pouze jako její vlastník. • Technický správce (tech) - Může být přiřazen k doméně pouze jako tech. správce. Tento kontakt je určen např. pro provozovatele hostingu, kde je doména vedena. Počet kontaktů tohoto typu je v registru omezen na 10. Technický kontakt musí rovněž obsahovat název společnosti a faxové tel. číslo. Na rozdíl od kontaktu vlastníka domény je zde vyžadována právnická osoba. • Kontakt typu prodejce (reseller) - Tento kontakt je určen pro přeprodejce služeb registrace domén (tj. subregistrátor nebo např. webové studio).
18
• Technický kontakt (onsite) - Může být přiřazen k doméně pouze jako onsite kontakt. Tento kontakt je primárně určen pro provozovatele domény jako webmastera či IT oddělení vlastníka domény. • Fakturační kontakt registrátora - Jedná se o typ kontaktu, který má každý registrátor vždy právě jeden a je přiřazen ke všem doménám v portfoliu daného registrátora. Vzhledem ke způsobu zpracování kontaktů registrem EURid tento registr implementuje standardní sérii příkazů pro správu kontaktů, přičemž vynechává příkaz pro změnu registrátora.
3.3
Správa domén
Registr uchovává o doméně základní informace v podobě údaje o jméně, datu registrace, datu expirace, určeném registrátorovi, odkazu na kontakt vlastníka a seznamu DNS serverů. Podobu entity domény popisuje RFC 3731. Rovněž zavádí příkazy pro manipulaci s doménami prostřednictvím protokolu EPP: příkaz pro registraci domény, prodloužení platnosti, změna údajů o doméně, získání informací o doméně, smazání a změna registrátora domény (tzv. transfer). 3.3.1
Správa domén v registru CZNIC
Registr CZNIC nahrazuje seznam DNS serverů jediným odkazem na entitu skupiny DNS serverů. Dále omezuje způsob změny registrátora, který není možný odložit a provádí se ihned po obdržení příkazu registrem, a zjednodušuje seznam kontaktů na jediný typ “admin”. Nad rámec standardu také zavádí příkaz pro získání seznamu domén ve správě registrátora. 3.3.2
Správa domén v registru EURid
Registr EURid implementuje správu domén na základě RFC 5731 a z možností vést DNS servery jako samostatné entity nebo naopak jako vlastnosti domén zvolil druhou možnost. Servery DNS lze tedy přidávat a přímo příkazy pro registraci aktualizaci domény.
3.4
Správa skupin DNS serverů
Oba registry zavádí podporu seznamů DNS serverů jako samostatných entit, které se následně váží na domény. Nespornou výhodou je snadná aktualizace, která se provádí pouze odebráním nebo přidáním DNS serveru na seznam, změna se projeví v DNS zónách všech navázaných domén aniž by bylo nutné samostatně aktualizovat každou z nich. Skupina DNS serverů může být přiřazena doméně při její registraci nebo při aktualizaci údajů domény odpovídajícím příkazem.
19
3.4.1
Správa skupin DNS serverů v registru CZNIC
Registr CZNIC rozšiřuje svou definicí RFC 3732 přidáním položky “report level” a příkazu pro výpis seznamů DNS serverů registrátora. Registr dále vyžaduje, aby měla skupina DNS serverů přiřazen technický kontakt a přidává příkaz pro výpis seznamu skupin DNS serverů dle kontaktu. Skupina DNS serveru musí obsahovat nejméně dva DNS servery, maximálně však deset. Položka “report level” určuje úroveň technických testů prováděných registrem. 3.4.2
Správa skupin DNS serverů v registru EURid
Registr EURid zavádí vlastní pojetí skupiny DNS serverů prostřednictvím Extension-frameworku EPP protokolu. Jedná se o jednoduchý seznam jmen DNS serverů, ke kterým nelze přiřadit IP adresa na rozdíl od implementace CZNICu. Registr implementuje sérii příkazů pro manipulaci se skupinami DNS serverů v podobě vytvoření, aktualizace, smazání a ověření existence. Skupina DNS serverů smí obsahovat 0-9 DNS serverů. V případě, že má doména nastaveny vlastní DNS servery a je k ní rovněž přiřazena skupina DNS serverů, při generování zónového souboru dojde ke sjednocení obou seznamů.
3.5
Poskytované údaje o účtu registrátora
EPP server poskytuje registrátorovi možnost dotázat se na stavové informace ohledně jeho účtu registrátora vedeného v registru jako je zbylý finanční kredit apod. Registr CZNIC rozeznává příkaz CreditInfo a v odpovědi informuje registrátora o stavu kreditu na jeho účtu. Registr EURid zavádí příkaz InfoRegistrar v jehož odpovědi registrátor získá informaci o stavu kreditu, dále pak množství penalizačních bodů (tzv. hitpointů) a počet kreditů nasbíraných za prodloužení domén v rámci marketingové akce EURidu.
3.6
Zprávy zasílané registrem registrátorovi
EPP server musí implementovat mechanismus, jak informovat registrátora o změnách v registru, které byly provedeny ze strany registru nebo jiného registrátora. Typickým příkladem je změna registrátora, kdy příkaz na změnu zadává nový registrátor a ten původní musí obdržet informaci, že doména již není nadále v jeho portfoliu (tzv. TRANSFER OUT). EPP protokol zavádí k tomu účelu příkaz POLL. EPP server na tento příkaz reaguje tak, že v odpovědi zašle počet nepřevzatých zpráv a podobu první z nich s jednoznačným identifikátorem. Opětovným zavoláním příkazu s parametrem “ack” a s použitím tohoto identifikátoru dojde k potvrzení převzetí zprávy a
20
jejímu odstranění z fronty registrátora. Následující dotaz pak vrátí další zprávu ve frontě nebo pouze informaci o tom, že je fronta prázdná. Oba registry implementují tento mechanismus podle standardu. HTTPs PUSH Registr EURid navíc zavádí alternativní způsob doručení prostřednictvím HTTPs PUSH. Pokud si registrátor zvolí tuto variantu komunikace na úkor EPP POLL, registr se u každé zprávy pokusí o doručení prostřednictvím metody HTTP 1.1 POST na URL adresu specifikovanou registrátorem. Nevýhodou této metody je omezený počet opakování ze strany registru a tedy i potenciální možnost nedoručení a ztráty informace ze zaslané zprávy.
21
4
Implementace
Program pro registraci domén 2. úrovně jsem implementoval formou webové aplikace. Původním předpokladem byl program spouštěný na straně klientského počítače, ale o takovéto řešení neměli pracovníci registrátora zájem. Jsou zvyklí obsluhovat webová rozhraní různých registrů a proto preferují stejnou formu i u implementovaného programu.
4.1
Použité technologie a programy
Program je naprogramován v programovacím jazyce PHP, uživatelské rozhraní je provedeno prostřednictvím HTML 4.1 a JavaScriptu s pomocí frameworku JQuery. Minimální verze PHP, na které je možné program provozovat je PHP 5.5.28. Jako datové úložiště byla použita MySQL relační databáze, především kvůli velmi dobré podpoře v PHP, dosavadním zkušenostem a dostupnému modelovacímu nástroji. MySQL Workbench umožňuje pokročilou správu a modelování dabáze včetně generování inkrementálních změnových souborů např. pro přechod mezi verzemi programu a dále synchronizaci struktury modelu s reálně běžící databází. Jako základní stavební kámen programu byl zvolen webový framework Nette od Davida Grudla ve verzi 2.2. Tento framework poskytuje programu prostředky jako šablonovací systém Latte nebo překladač konfiguračních souborů typu Neon, dále pak zastřešuje základní inicializaci programu a mapování URL adres požadavků na prostředky programu.
4.2
Návrh architektury programu
Struktura programu byla navržena tak, aby byly odděleny základní logické celky programu. Kromě dnes již běžně zažitého oddělení databázové vrstvy, aplikační a prezentační logiky byly definovány servisní třídy a tzv. fasády (obr. 4). Nadefinování pojmů z obrázku 4: Servisní třídy (Service) jsou jednoúčelové samostatné třídy, které poskytují aplikaci specifickou službu např. autorizaci a autentizaci uživatele, logování nebo např. obecné zpracování událostí. Fasády (Facade) jsou třídy, které poskytují veřejné rozhraní programu a zapouzdřují vnitřní logiku (podle návrhového vzoru fasáda). Použití fasád je velmi vhodné v případě, že se uvažuje o různých možnostech přístupu k programu - např. webové rozhraní (controller), komunikace se systémy třetích stran (např. pomocí REST API) nebo použití klientské aplikace typu lehký klient, která využívá webových služeb místo implementace kompletní logiky. Entita (Entity) je třída, která představuje reprezentaci objektu systému (např. doménové jméno), její instance pak odpovídá jednomu řádku v tabulce. En-
22
tita je pouze nositelem informace, tzv. transportní objekt, neimplementuje vnitřní logiku, pouze validační pravidla. Repozitář (Repository) je třída, která zpřístupňuje metody na dotazování se tabulky a vytváření instancí entit. Entity Manager je prostředek objektově-relačního frameworku, který zajišťuje ukládání entit zpět do databáze (tzv. perzistenci), správu transakcí apod.
Obrázek 4: Schéma rozdělení logiky programu (převzato z [7]) Zvolený model architektury programu se podařilo úspěšně implementovat a výsledkem jsou následující fasády, které skrývají vnitřní logiku své části aplikace před ostatními a zpřístupňují pouze své veřejné rozhraní pro interakci. Jednotlivé fasády budou popsány dále v textu. DNMS\Model\DomainContactFacade DNMS\Model\DomainNameFacade DNMS\Model\DomainNSSetFacade DNMS\Model\DomainRegistryFacade DNMS\Model\GroupFacade DNMS\Model\InvoicingOrderFacade DNMS\Model\PricelistFacade DNMS\Model\UserFacade
23
Z diagramu na obr. č. 5 je patrné, jak probíhá komunikace mezi jednotlivými úrovněmi architektury. Třídy DomainNamePresenter a DomainContactPresenter implementují webové rozhraní a komunikují výhradně s fasádami (DomainContactFacade a DomainNameFacade), které zpřístupňují data z repozitářů a služby servisních tříd pro komunikaci s registry prostřednictvím vlastního rozhraní.
Obrázek 5: Zjednodušený diagram skutečné architektury programu Program je dále rozdělen na tři základní logické moduly: • DNMS - základní modul zastřešující vnitřní logiku aplikace, definuje servisní třídy, přistupuje k databázi a řídí chod celého programu • Cznic a Eurid - moduly pro komunikaci s jednotlivými registry TLD, implementují zprávy podle specifikace registru a zajišťují komunikaci s nimi
24
Adresářová struktura Adresářová struktura programu je rozdělena následovně: /app /app/config /app/Cznic /app/data
/app/DNMS /app/Eurid /app/forms /app/model /app/presenters /app/templates /lib /logs /www
/tmp
4.3
Složka app obsahuje vnitřní logiku aplikace, tato složka není přístupná prostřednictvím webového serveru. Složka config obsahuje configurační soubory aplikace Složka Cznic obsahuje soubory modulu pro komunikaci s registrem. Složka obsahuje databázový model pro MySQL Workbench a SQL soubor se strukturou databáze pro instalaci programu. Složka DNMS obsahuje základní modul programu. Složka Eurid obsahuje soubory pro komunikaci s registrem. Složka forms obsahuje třídy zastřešující generování a zpracování webových formulářů. Složka obsahuje třídy definovaných fasád. Složka obsahuje třídy zastřešující zpracování HTTP požadavků. Složka obsahuje šablony webových stránek. Složka obsahuje použité moduly. Složka obsahuje logové soubory programu a modulů registrů. Složka obsahuje soubory pro webové stránky (css styly, javascriptové soubory, obrázky a soubory ke stažení). Pouze tato složka je přístupná přímo prostřednictvím webového prohlížeče. Složka obsahuje dočasné soubory.
Popis implementace komunikace s registry
Komunikace s registrem probíhá formou výměny XML zpráv podle protokolu EPP. EPP server komunikuje s programy registrátorů na portu 700 prostřednictvím transportní vrstvy TCP/IP. Program DNMS odděleně implementuje samotné spojení a generování zpráv, čímž umožňuje lepší testovatelnost závislých tříd použitím pseudoobjektů (tzv. mockování) a zaměnitelnost za jiné typy spojení (např. HTTP). Program zavádí samostatnou třídu DNMS\Connection pro vytvoření spojení s EPP serverem registru a dodává prostředky pro posílání a příjem zpráv, aniž by rozuměla jejich obsahu. Komunikaci s registrem umí zaznamenávat do logu. Třída rovněž implementuje SSL spojení a volitelně provede i přihlášení SSL certifikátem (vyžadováno registrem CZNIC). Třída implementuje rozhraní ConnectionInterface. 25
Jednotlivé typy XML zpráv pro registr a jeho odpovědi jsou reprezentovány samostatnými třídami (např. ContactCreateRequest a ContactCreateResponse pro vytvoření kontaktu). Oba registry mají tyto třídy organizovány v samostatných souborech v podadresáři models svého modulu. Třída typu Request představuje šablonu příkazu pro daný registr, zatímco třída typu Response zpracovává data z odpovědi. Oba typy tříd poskytují přístup k položkám zprávy prostřednictvím vlastností objektu (viz ukázka kódu 3). Třídy typu Request rozšiřují abstraktní třídu RequestAbstract, která přidává metody pro automatické generování identifikátoru zprávy (tzv. clTRID) a odeslání zprávy na EPP server. Metoda execute() odešle sestavenou XML zprávu, vrátí objekt typu Response a provede kontrolu identifikátoru zprávy v odpovědi (viz ukázka kódu 3). Pokud se identifikátor liší, vygeneruje výjimku typu RegistryException. 1 2 3 4 5
/** @var ContactCreateRequest $contactCreateRequest */ $contactCreateRequest->name = ’Jan Baroš’; // nastaví jméno do pož adavku na vytvoˇ rení kontaktu /** @var ContactCreateResponse $contactCreateResponse */ $contactCreateResponse = $contactCreateRequest->execute(); // odešle pˇ ríkaz na server print $contactCreateResponse->contact_id; // vytiskne identifikátor právˇ e vytvoˇ reného kontaktu
Zdrojový kód 3: Práce s objekty typu RequestAbstract a ResponseAbstract
Ve skutečnosti je tento popis funkce metody execute() značně zjednodušený, abychom mohli získat ucelenou představu, musíme nejprve pochopit závislosti této třídy. Třída RequestAbstract rozšiřuje abstraktní třídu XMLMessageAbstract, která zpřístupňuje metody pro zjednodušení práce s XML zprávami obecně, včetně validace. Jak registr CZNIC, tak i EURid zpřístupňují svá .XSD schémata registrátorům. Tyto soubory jsou uloženy v podadresáři “schema” v obou modulech těchto registrů. Metoda execute() tedy před odesláním XML zprávy do registru volá metodu validateSchema() nadřazené třídy XMLMessageAbstract. Pokud zpráva z jakéhokoli důvodu nesplňuje definovaná kritéria, metoda vygeneruje výjimku typu XMLMessageException s popisem nedostatků XML zprávy a k odeslání vůbec nedojde. Vzhledem k tomu, že oba registry implementují penalizační mechanismus 3 za chyby, můžeme tuto bariéru považovat za dobrý krok. Instance všech potomků třídy XMLMessageAbstract, tedy i RequestAbstract, při vytvoření přebírá objekt typu Registry, který třídě zpřístupní seznam jmenných prostorů pro XML zprávy daného registru, metody Login a Logout pro přihlášení 3
Registr CZNIC za každou chybnou zprávu zpomalí reakci na každou další o 1 sekundu. Registr EURid přiděluje za každou chybu tzv. hitPoint a při přesažení stanovené hranice 1000 hitPointů zablokuje registrátorovi přístup na svůj EPP server. Pokud hitPointy nadále nepřibývají po 24ti hodinách nastaví počet hitPointů na 0 a přístup k serveru obnoví. Registrátor může dvakrát za kalendářní měsíc požádat o předčasné odblokování přístupu přes web registru.
26
do registru a objekt typu Connection. Nyní, když známe všechny závislosti, můžeme odhalit kompletní implementaci metody execute() třídy RequestAbstract (viz ukázka zdrojového kódu 4). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
function execute($logout = true) // RequestAbstract::execute { $this->validateSchema(); // validuje XML zprávu $response = new $this->_responseClass($this->_reg); // pˇ ripraví objekt typu ResponseAbstract $conn = $this->_reg->getConnection(); // získá objekt Connection prostˇ rednictvím Registry if ($this->_requiresAuthentication && !$conn->isLoggedIn()) { $this->_reg->Login()->execute(false); // provede pˇ rihlášení do registru, pokud již není } $result = $conn->sendAndReceive($this->getXML()); // odešle xml zprá vu a pˇ ríjme odpovˇ ed $response->parse($result); // naˇ cte XML odpovˇ ed’ do objektu ResponseAbstract $response->validateResponse($this->_clTrid); // provede kontrolu identifikátoru zprávy $this->performLogout($logout); // provede odhlášení a ukonˇ cení spojení return $response; // vratí objekt ResponseAbstract }
Zdrojový kód 4: Implementace kódu metody RequestAbstract::execute()
V ukázce kódu č. 4 si všimněme, že třída typu ResponseAbstract při vytvoření objektu přebírá rovněž objekt typu Registry, je totiž také potomkem třídy XMLMessageAbstract. Dále je patrné, že ve skutečnosti porovnání identifikátoru zprávy v odpovědi provádí třída ResponseAbstract pomocí metody validateResponse(). Kromě této validace metoda validateResponse() kontroluje i návratové kódy v odpovědi a v případě, že identifikuje chybu, vygeneruje výjimku typu ResponseException s popisem chyby. Pro úplnost uvedeme, že třídy Registry podléhají definici rozhraní RegistryInterface, třída RequestAbstract rozhraní RequestInterface a ResponseAbstract rozhraní ResponseInterface. Nyní můžeme konstatovat, že jsme úspěšně implementovali mechanismus pro komunikaci s registrem, který je dostatečně modulární, aby mohl podporovat jakýkoli registr pracující s jakýmkoli protokolem, za předpokladu, že budou implementována definovaná rozhraní. Zároveň jsou jeho součásti samostatně dobře testovatelné. Servisní třídy RegistryService a RegistryServiceFactory V tuto chvíli máme k dispozici způsob, jakým se efektivně můžeme dotazovat jednotlivých registrů. Ale dosud jsme nevyřešili problém možných odlišností ve 27
zprávách samotných. Např. použití objektu zprávy Cznic\Model \ContactCreateRequest se liší od stejného typu zprávy Eurid\Model \ContactCreateRequest, byť oba rozšiřují společného předka DNMS\Request\RequestAbstract. V případě této zprávy bude verze Euridu vyžadovat specifikování vlastnosti objektu “typ kontaktu”, který naopak nebude znát verze CZNICu a bude hlásit chybu, pokud se jej pokusíme ve zprávě nastavit. Pro ostatní části programu to znamená, že musí znát nejen typ příkazu, který chtějí v registru provést, ale také, jaké vlastnosti je možné nastavit, které jsou povinné apod. Vhodným způsobem řešení je odstínit zbylé části aplikace od přímé práce se zprávami pro registr. Zavedením servisní třídy RegistryService pro každý registr a společného rozhraní RegistryServiceInterface definujícího metodu pro každou zprávu typu RequestAbstract docílíme požadovaného efektu (viz ukázka 5.). Všimněme si, že argumentem metody nejsou jednotlivé vlastnosti kontaktu, ale přímo objekt entity. Takto jsme schopni zajistit, že potřebné vlastnosti objektu zprávy nastaví metoda třídy RegistryService. Touto abstrakcí jsme jako vedlejší efekt poskytli řešení pro další odlišnost příkazu ContactCreate a to generování identifikátoru kontaktu v registru. Zatímco Eurid identifikátory přiděluje sám a jsou k dispozici v odpovědi na provedený příkaz, CZNIC vyžaduje specifikování identifikátoru jako součást příkazu. V implementaci metody createContact třídy RegistryService pro registr CZNIC můžeme zavést funkci generující identifikátor v požadovaném tvaru (např. jméno registrátora + identifikátor entity + jméno a příjmení oddělené pomlčkou a zbavené diakritiky). Vše proběhne transparentně, aniž by se jakkoli změnilo veřejné rozhraní servisní třídy. 1 2 3 4
/** @var RegistryService $registryService */ /** @var DomainContact $contact */ $contact_id = $registryService->createContact($contact); print $contact_id;
Zdrojový kód 5: Volání metody RegistryService::createContact(), která zapouzdřuje kód z ukázky 3
Dále je nutné pamatovat na příkazy, které definuje jen jeden z registrů, pokud metodu implementující tento příkaz zavedeme do společného rozhraní, třídy RegistryService ostatních registrů musí metodu implementovat také. V takovém případě je vhodné generovat výjimku NotImplementedException při zavolání metody. Vhodným přístupem je rovněž poskytnout ostatním částem programu mechanismus pro určení správného registru, se kterým potřebují pracovat. Např. doménu .eu není možné registrovat prostřednictvím servisní třídy Cznic a naopak, rovněž je zbytečné nechat implementaci rozhodovacího mechanismu jiné části programu. 28
Poslední abstrakcí, kterou zavedeme je třída RegistryServiceFactory. Tato třída implementuje návrhový vzor Singleton (Jedináček). Dále implementuje metodu getRegistryByDomainName(), která vrací servisní třídu registru odpovídajícímu doméně předané v prvním argumentu. Pro ostatní entity v systému je vhodné využít metodu getRegistryServices, která vrací pole servisních tříd všech registrů a u každého ověří příslušnost příkazem checkTypEntity() (např. checkContact, checkNSGroup apod.). Nyní můžeme konstatovat, že jsme úspěšně odstínili komunikaci s registry od ostatních částí programu a vytvořili jsme standardizované rozhraní pro přístup ke službám registru.
4.4
Popis jednotlivých fasád
Každá třída implementující návrhový vzor fasáda představuje veřejné rozhraní pro ostatní fasády a webové rozhraní (presentery). Fasáda řídí komunikaci se všemi ostatními vrstvami programu. Dotazuje se na databázovou vrstvu, komunikuje s objekty servisních tříd, přijímá požadavky a odesílá odpovědi zpět prezentační vrstvě. Všechny třídy typu Fasáda implementují rovněž návrhový vzor Jedináček. Zároveň platí společný znak, že každá z nich při vytvoření přebírá aktuálně přihlášeného uživatele (entitu UserAccount) a odkaz na servisní třídu implementující systém oprávnění (třídu DNMS\Security\Permission). 4.4.1
ValueObject a CommandObject
Než přistoupíme k popisu jednotlivých fasád a jejich specifického účelu, je třeba si představit další prostředek využívaný programem pro zjednodušení práce s hodnotami. Kromě entit využívá program transportní objekty typu ValueObject. ValueObject slouží pro přenos strukturované informace a na rozdíl od entity není svázán strukturou databáze. Specifickou vlastností třídy typu ValueObject je, že všechny povinné informace jsou předávány formou konstruktoru třídy (viz příklad zdroj. kódu 6) a zároveň jsou ve stejnou chvíli validovány. V důsledku tedy není objekt vůbec vytvořen, pokud validace skončila s chybou. Jestliže jakákoli funkce přijímá jako argument ValueObject, může se spolehnout na to, že tento objekt je vždy validní. Jedinou kontrolu, kterou taková funkce musí provést, je ověření, zda jí nebyla předána hodnota “null” místo požadovaného objektu. Tento přístup je daleko pohodlnější, než mít implementovanou validační funkci, kterou je nutné volat před použitím dané informace. 1
function __construct($contact_type, PersonName $person, $company = ’ ’, $lang, Address $address, EmailAddress $emailAddress, PhoneNumber $voice, PhoneNumber $fax = null)
Zdrojový kód 6: Ukázka zdrojového kódu třídy Contact
29
Jak je patrné z ukázky, třída typu ValueObject se může skládat z dalších tříd typu ValueObject, aby takto přenesl režii na validaci informace, jež může být rovněž použita samostatně v jiném kontextu (např. tel. číslo - ValueObject PhoneNumber). Třída typu ValueObject není určena pro implementaci logiky programu, ale může implementovat např. různé transformace hodnot. ValueObject typu PhoneNumber může tel. číslo rozkládat na mezinárodní volbu, předčíslí a samotné číslo a implementovat metody, které vrátí tel. číslo podle různých zvyklostí (např. +420 verzus 00420 pro ČR). Program tohoto přístupu vhodně využívá zavedením ValueObjectu typu Price reprezentujícího finanční částku. Třída přebírá pouze číselnou hodnotu a ValueObject typu Currency, reprezentující měnu. Formát, v jakém je částka zobrazena v grafickém rozhraní (GUI) programu je implementován právě ve formě metody __toString() této třídy. Další specifickou vlastností je možnost porovnávat objekty typu ValueObject. Zatímco stejné entity se liší minimálně identifikátorem a je možné na ně pohlížet jen jako různé instance, třídy ValueObject stejného typu jsou vzájemně zaměnitelné v případě, že nesou stejné hodnoty. Všechny třídy typu ValueObject v programu pro tento účel implementují metodu Equals() (viz ukázka kódu č. 7). 1 2 3 4 5 6
$phone1 = new PhoneNumber("+420 123 456789"); $phone2 = new PhoneNumber("+420 123 456789"); $phone3 = new PhoneNumber("+420 123 456780"); print $phone1->Equals($phone2); // vrací True, i když jde o r˚ uzné instance tˇ rídy print $phone1->Equals($phone3); // vrací False, jedná se o r˚ uzná tel . ˇ císla
Zdrojový kód 7: Příklad srovnání ValueObjectů stejného typu (PhoneNumber)
Specifickým typem třídy typu ValueObject je tzv. CommandObject. Více než specifickou implementací se od běžné třídy ValueObject liší způsobem použití. Třída typu CommandObject nese informaci určenou pro specifický případ použití (vykonání akce). Příkladem akce může být prodloužení doby registrace domény. Požadované informace pak jsou název domény, aktuální datum expirace a počet let k prodloužení. Můžeme tedy zavést třídu typu CommandObject RenewDomain, která bude při vytváření přebírat ValueObject DomainName pro jméno domény, objekt typu DateTime4 pro datum expirace a číselnou hodnotu pro počet let k prodloužení. Tento CommandObject provede validaci dat, ověří, že není datum expirace v minulosti a po navýšení o daný počet let nedojde k překročení maximální doby registrace. Tato validace by měla proběhnout před vystavením objednávky a znovu při její realizaci, protože mezi vystavením objednávky, přijetím platby a následně její realizací může být časová prodleva, během níž může dojít ke změně 4
DateTime je nativní objekt jazyka PHP.
30
vlastností dané domény (např. k prodloužení jiným uživatelem). Program tedy při odeslání sestaví object typu RenewDomain a uloží jej v serializované5 podobě do položky objednávky. V okamžiku uskutečnění platby, se pokusí znovu sestavit tento objekt z deserializované podoby a přitom se opět provede validace. Třídy typu ValueObject z tohoto důvodu implementují rozhraní Serializable (nativní v PHP), které definuje metody serialize() a unserialize(). Každá z nich při serializaci ukládá číselnou verzi ValueObjectu pro případ, že by došlo ke změnám v objektu, které by mohly ovlivnit zpětný proces deserializace (např. přidaná položka DIČ u ValueObjectu Kontakt). Myšlenka objektů typu ValueObject a CommandObject vychází z přístupu Doménově orientovaného návrhu (Domain Driven Design). V jiných jazycích by se implementovaly formou uživatelsky definovaných datových typů, které bude jazyk PHP podporovat až ve verzi 7 (nyní ve fázi Beta 3, příští verze RC1). 4.4.2
Fasáda DomainContactFacade
Tato třída typu fasáda zastřešuje veškerou správu kontaktů v programu a v registrech a představuje veřejné metody pro založení nového kontaktu, změnu vlastností, ověření existence nebo smazání. Cílem bylo navrhnout použití kontaktů takovým způsobem, aby uživatel programu nemusel přemýšlet nad tím, pro který registr nebo doménu kontakt zakládá. Vzhledem k tomu, že se jednotlivé položky požadované oběma registry významně neliší, je možné zavést v programu jedinou entitu DomainContact, která ponese informace požadované oběma registry, aniž by to znamenalo komplikaci pro uživatele. Entita DomainContact obsahuje referenci na oba registry, kde si ukládá, pod jakým identifikátorem kontakt vede daný registr a tedy i zda je vůbec registrován. Dále bylo nutné navrhnout způsob práce s kontakty jako takovými. Registr Eurid zavádí typy kontaktů a jejich účel. Ukázalo se, že tento model není ani v rozporu s filozofií registru CZNIC. Diskuse se zástupci registrátora odhalila, že technických kontaktů má registrátor v evidenci jen několik jednotek6 , kromě kontaktů vlastníků domén a vlastního fakturačního kontaktu neeviduje žádné kontakty ostatních podporovaných typů (tj. onsite a reseller). Tento trend si evidentně uvědomil i sám registr Eurid, který počet technických kontaktů omezil na 10 na registrátora. Program tedy implementuje coby typy kontaktů: vlastník domény, technický správce a fakturační kontakt. Fakturační kontakt je v tomto případě interní typ pro potřeby fakturace a objednávek. Úspěšně se tedy podařilo splnit předpoklad a odstínit odlišnosti obou registrů při správě kontaktů. Následuje popis nejdůležitějších metod fasády pro práci s kontakty: • Metoda createContact() vytvoří nový kontakt na základě objektu třídy 5
Serializace převede objekt na textovou reprezentaci, díky níž je schopen opačným procesem, deserializací, získat opět stejný objekt. 6 Registrátor ProfiWH v době dokončování této práce eviduje pouze dva technické kontakty.
31
Contact předaném v prvním parametru a uloží jej do databáze. Nově vytvořený kontakt ještě v tuto chvíli není zaregistrován v žádném registru. K jeho registraci dojde až ve chvíli, kdy bude přiřazen k doméně nebo ke skupině DNS serverů. • Metoda updateContact() provádí změny vlastností kontaktů rovněž na základě objektu typu Contact, který nese novou podobu kontaktu. Při ukládání zkontroluje oba registry na existenci daného kontaktu a případně provede i změnu zde. • Metoda deleteContact() ověří, zda na tento kontakt nejsou navázány domény nebo skupiny DNS serverů, následně pomocí servisní třídy RegistryServiceFactory projde všechny registry a smaže kontakt v registru. Pokud vše proběhlo bez problému entitu z programu vymaže. • Metoda find() vrací entitu DomainContact odpovídající předanému identifikátoru a případně provede validaci, zda odpovídá požadovanému typu kontaktu předanému v druhém volitelném parametru. • Metoda setDisabled() na základě parametru provede zneplatnění nebo opětovnou aktivaci entity. Zneplatněná entita nemůže být dále přiřazována k jiným entitám, toto platí obecně pro všechny entity programu. • Metody findAllDomainContact() a listContactsByTypeAutocomplete() poskytují seznam kontaktů pro účely generování přehledů nebo napovídání kontaktů ve formulářích (tzv. funkce autocomplete). 4.4.3
Fasáda DomainNSSetFacade
Fasáda DomainNSSetFacade zastřešuje veškerou správu skupin DNS serverů a poskytuje své metody ostatním částem programu. Cílem bylo, podobně jako u kontaktů, navrhnout jednotný způsob správy skupin DNS serverů navzdory odlišnostem obou registrů. Přístup obou registrů je v tomto případě velice podobný, proto se i zde podařilo zavést společnou entitu DomainNSSet, která obsahuje společné vlastnosti seznamu DNS serverů a identifikátor pro každý registr. Odlišnost, kterou nepodařilo odstínit byla informace o IP adresách DNS serverů. Zatímco registr CZNIC vede IP adresy výhradně v seznamu DNS serverů, registr EURid povoluje IP adresy pouze v záznamech samotné domény. Je zřejmé, že tato režie musí být přenesena na uživatele programu. Úvodní předpoklad se tedy nepodařilo splnit úplně, ale podařilo se zavést jednotnou entitu pro skupinu DNS serverů. Následuje popis nejdůležitějších metod fasády pro práci se skupinami DNS serverů: • Metoda createNSSet() vytvoří skupinu DNS serverů na základě objektu třídy NSGroup a uloží jej do databáze. K jeho registraci dojde až ve chvíli, kdy bude přiřazen k doméně. 32
• Metoda updateNSSet() provádí změny skupiny na základě objektu typu ServerList, který nese nový seznam DNS serverů. Při ukládání zkontroluje oba registry na existenci dané skupiny a případně provede i změnu zde. • Metoda deleteNSSet() ověří, zda na tuto skupinu nejsou navázány domény, následně pomocí servisní třídy RegistryServiceFactory projde všechny registry a smaže skupinu v registru. Pokud vše proběhlo bez problému entitu z programu vymaže. • Metoda find() vrací entitu DomainNSSet odpovídající předanému identifikátoru. • Metoda setDisabled() na základě parametru provede zneplatnění nebo opětovnou aktivaci entity. • Metody findAllNSSets() a listNSSetAutocomplete() poskytují seznam skupin DNS serverů pro účely generování přehledů nebo napovídání ve formulářích (tzv. funkce autocomplete). 4.4.4
Fasáda DomainNameFacade
Fasáda DomainNameFacade zastřešuje veškerou správu domén a poskytuje ostatním částem programu prostředky pro jejich registraci, aktualizaci, prodloužení a převod od jiného registrátora. Všechny tyto funkce provádí prostřednictvím servisních tříd RegistryService a implementuje vnitřní logiku programu pro práci s doménami. Následuje popis nejdůležitějších metod fasády pro práci s doménami: • Metoda createDomain() provede registraci domény na základě předaného objektu třídy CreateDomain (CommandObject). Před samotnou registrací ověří dostupnost domény pro registraci, dále zaregistruje kontakt vlastníka domény a technický kontakt, pokud již nebyly zaregistrovány spolu s jinou doménou nebo skupinou serverů. Stejně tak zaregistruje skupinu serverů, pokud je přiřazena a nebyla dosud registrována. Následně uloží entitu DomainName do databáze. • Metoda renewDomain() provede prodloužení na základě objektu typu RenewDomain (CommandObject) a nastaví nové datum expirace, které obdrží z odpovědi registru na prodloužení. • Metoda deleteDomain() provede předčasné smazání domény. • Metoda transferDomain() provede převod domény od jiného registrátora na základě jména domény a autorizačního kódu pro převod. Tento kód pro převod obdrží vlastník domény od svého stávajícího registrátora.
33
• Metoda updateDomain() provede změnu vlastníka domény nebo technického správce, případně přiřazené skupiny DNS nebo přímo nastavení DNS serverů domény (pouze Eurid). Kontakty případně rovněž zaregistruje, pokud dosud nebyly, stejně tak i skupinu DNS serverů. • Metoda isAvailable() na základě předaného jména ověří dostupnost domény nejprve v systému a následně i v odpovídajícím registru a vrátí pravdivostní hodnotu True, pokud je doména volná pro registraci, jinak vrátí False. • Metoda findByDomainName() vrátí DomainName entitu na základně předaného jména domény. • Metody listDomainNames() a listDomainNamesForRenewal() poskytují seznam domén pro účely generování přehledů nebo napovídání domén ve formulářích (tzv. funkce autocomplete). 4.4.5
Fasáda InvoicingOrderFacade
Fasáda InvoicingOrderFacade přidává k fasádě DomainNameFacade prostředky na sestavení objednávky na jednotlivé akce, které jsou podmíněny platbou. Metody třídy DomainNameFacade obaluje svou interní logikou a přímo je volá až ve chvíli uhrazené objednávky, přičemž využívá mechanismus serializace tříd typu CommandObject popsaný v první části kapitoly. Objednávka může nabývat následujících stavů: • Čeká na platbu - Výchozí stav při vytvoření nové objednávky, všechny položky objednávky kopírují tento stav. • Zaplacená - Ve chvíli, kdy je objednávka označena jako zaplacená jsou všechny její položky převedeny do stavu “čeká na zpracování” a pokusí se je zpracovat vyvoláním přiřazeného objektu typu CommandObject a zavoláním odpovídající metody fasády DomainNameFacade. Pokud vše proběhne v pořádku, označí se jako “dokončeno”, v opačném případě jako “chyba” s popisem chyby. • Zrušená - Objednávka může být manuálně zrušena a to pouze pokud dosud nebyla zaplacena. • Dokončená - Objednávka se automaticky označí jako zaplacená ve chvíli, kdy všechny její položky budou ve stavu “dokončeno”. Následuje popis nejdůležitějších metod fasády: • Metoda createDomain() na základě předaného objektu typu CreateDomain dohledá cenu v ceníku přiřazeného skupině uživatele, sestaví objednávku a uloží ji do databáze jako entitu InvoicingOrder, jednotlivé položky objednávky pak jako entity typu InvoicingOrderItem.
34
• Metoda domainRenew() pracuje analogicky k metodě createDomain() pouze pracuje na základě předaného objektu typu RenewDomain. • Metoda findByOrderNo() vrátí entitu InvoicingOrder na základě předaného čísla objednávky. • Metody listActiveOrders(), listOrdersInDue() a listCompletedOrders() poskytují seznam objednávek pro účely generování přehledů objednávek, v následujícím pořadí: nedokončené objednávky, objednávky po splatnosti a dokončené objednávky (tj. včetně zrušených). 4.4.6
Fasáda InvoicingPricelistFacade
Fasáda InvoicingPricelistFacade poskytuje zbylým částem programu prostředky pro vytvoření nového ceníku, aktualizaci, smazání nebo blokování a dotazování se na ceny jednotlivých položek ceníku. Tyto funkcionality poskytuje prostřednictvím následujících metod: • Metoda CreatePricelist() na základě předaného jména ceníku, měny a seznamu cen položek uloží do databáze entitu InvoicingPricelist a pro jednotlivé položky entity InvoicingPricelistItem. • Metoda UpdatePricelist() provede aktualizaci ceníku a jeho položek na základě předaného seznamu cen. • Metoda DeletePricelist() ověří, zda na ceník nejsou navázány nějaké uživatelské skupiny a následně ceník z programu vymaže. • Metoda findPricelistByCode() vrátí entitu InvoicingPricelist na základě předaného identifikátoru ceníku. • Metoda getPricelistItemsByAction() na základě předaného jména domény a typu ceníkové položky vrátí indexované pole cen pro danou akci při objednání s periodou 1-10 let. • Metody listActivePricelists() a findAllPricelists() poskytují seznam ceníků pro účely generování přehledů objednávek, v následujícím pořadí: neblokované ceníky a všechny ceníky.
4.5
Schéma databáze a komunikace s databází
Jako abstrakční vrstva zapouzdřující komunikaci s databází byl použit ORM framework Doctrine2 [8] ve verzi 2.3. ORM (Object Relation Mapping) slouží pro automatické generování objektů reprezentující záznamy v tabulkách a relační vazby mezi nimi, tyto objekty nazýváme entity. Různé ORM frameworky umožňují různý přístup k vlastnostem jednotlivých entit. Velmi často používají magické funkce (tj. prostředky pro přetěžování neexistujících vlastností nebo metod) a vlastnosti pro přístup k informacím uloženým v entitě. S tímto si bohužel 35
neporadí většina programátorských editorů (IDE), není schopna tyto vlastnosti napovídat při psaní názvů (funkce IDE označovaná jako autocomple, intelisense apod.) nebo validovat a upozornit na případné překlepy. Doctrine2 má opačný přístup, třídy entit fyzicky generuje do souborového systému, vlastnosti objektu zapouzdřuje (jsou označeny jako privátní) a zpřístupňuje je pomocí tzv. getterů a setterů. Jedná se o metody objektu, které umožňují získání a změnu vlastnosti objektu. Jmenná konvence určuje, že getter je pojmenován getNazevVlastnosti() a setter je pojmenován setNazevVlastnosti ($hodnota). Výhodou tohoto přístupu mimo odstranění výše popsaných neduhů je také možnost definovat rozhraní pro danou entitu, což není při dynamickém přístupu možné. Jednotlivé třídy entit generované Doctrine jsou umístěny ve složce projektu v podsložce app/ DNMS/Entity/Om, o úroveň výše jsou uloženy stejně pojmenované třídy, které generované třídy rozšiřují. Tímto je zajištěno, že veškeré ruční úpravy entit zůstanou nedotčeny při přegenerování tříd pomocí Doctrine. Pro každou tabulku databáze je vždy generována právě jedna třída entity. Ve stejné složce je umístěna podsložka Repository ve které se nachází třídy zajišťující uložení dat z entit zpět do databáze (tzv. perzistenci) a dotazování na jednotlivé entity. Pro každou entitu je zde jedna třída typu Repository. Třída Repository implementuje návrhový vzor Singleton. Nejdůležitější částí frameworku Doctrine je tzv. EntityManager, který se stará o přímý přístup k databázi a umožňuje provádění transakcí apod. Schéma databáze části aplikace, která se stará o správu domén, je zobrazeno na obr. č. 6. Z obrázku jsou patrné jednotlivé vazby mezi tabulkami. Přehlednost schématu komplikuje více vazeb mezi tabulkou domain_contact a domain_name, protože je s každou doménou svázáno několik kontaktů v různých rolí (pro připomenutí je to vlastník, technický správce a fakturační kontakt). Tabulka domain_contact je reprezentována v programu entitou DomainContact a uchovává informace o vlastnostech každého kontaktu jako je jméno, adresa a kontaktní informace. Kromě toho definuje vazby na vlastníka kontaktu (user_account a user_group), specifikuje typ kontaktu a eviduje identifikátory pro referenci na objekt v registru (registry_id pro EURid a cznic_id pro CZNIC). Každá tabulka obsahuje sloupce created a updated, které Doctrine automaticky nastaví na datum a čas vytvoření entity, respektive poslední aktualizace. Tabulka domain_nsset je reprezentována entitou DomainNsset a uchovává informace o skupinách DNS serverů. Kromě jména, reference na domain_contact v podobě technického kontaktu a položek pro celkem 9 DNS serverů jsou zde opět identifikátory pro referenci na objekt v registru. Tabulka domain_name je reprezentována entitou DomainName a uchovává informace o vlastnostech domén jako jméno, datum expirace a reference na navázané kontakty, skupinu DNS serverů a tabulky domain_registry a domain_tld. Což jsou pomocné tabulky pro sestavování přehledů podle TLD a registru. Tabulka domain_registry uchovává stavové informace o registru jako dostupný kredit na účtu registrátora nebo počet penalizačních bodů v pří36
padě EURidu.
Obrázek 6: Schéma databáze z pohledu správy domén Schéma databáze části aplikace, která se stará o správu objednávek a ceníků, je zobrazeno na obr. č. 7. Je zde patrná vazba mezi ceníkem (invoicing_pricelist), ceníkovými položkami (invoicing_pricelist_item) a TLD (domain_tld). Ceník je sestaven z cen, které se pro jednotlivé TLD liší. Dále je patrná vazba mezi fakturačním kontaktem reprezentovaným tabulkou domain_contact a objednávkou (invoicing_order), stejně jako mezi položkami objednávky (invoicing_order_item) a objednávkou. U položky objednávky si všiměme sloupce “command”, do kterého se při vytvoření položky objednávky uloží serializovaný objekt typu CommandObject. Z nákresu dále není patrná vazba mezi položkou objednávky a tabulkou domain_name, ta je důležitá pro výpis objednávek vztažených k jednotlivé doméně.
37
Obrázek 7: Schéma databáze z pohledu správy objednávek
4.6
Zabezpečení programu
Webová aplikace, která je permanentně dostupná na serveru prostřednictvím internetu, musí nutně řešit zabezpečení proti nepovolenému přístupu. Program DNMS vyžaduje přihlášení uživatelským účtem a rozděluje role oprávnění, které jsou pak účtům přiřazeny účtům. Hesla k uživatelským účtu jsou uložena v databázi v zašifrované podobě tak, aby nebyla zneužitelná v případě, že by se útočníkovi podařilo data z databáze přečíst. Heslo je zašifrováno pomocí primitivní funkce jazyka crypt() (tj. vestavěná funkce) s přidáním druhého řetězce (tzv. salt) pro zkomplikování reverzního způsobu zjištění hesla. Dále program zajišťuje automatické odhlášení uživatele při neaktivitě po zvolený časový úsek. Ve výchozím nastavení program provede automatické odhlášení po 15 minutách neaktivity uživatele. Vzhledem k tomu, že je heslo při přihlášení přenášeno mezi prohlížečem klienta a programem v čitelné textové podobě, je nutné program zpřístupnit na webovém serveru výhradně prostřednictvím zašifrovaného spojení (HTTPs). Registrátor by si pro tento účel měl zajistit důvěryhodný certifikát od některé z certifikačních autorit s širokou podporou v prohlížečích (např. Thawte, Verisign či RapidSSL). České certifikační autority nejsou pro tento účel příliš vhodné díky jejich chabé podpoře v prohlížečích. Nelze se rovněž spoléhat ani na certifikační autority distribuované s operačním systémem. Prohlížeč Firefox systémové
38
úložiště ve své výchozí konfiguraci nebere v potaz. V neposlední řadě program implementuje další bezpečnostní bariéru, kdy vyžaduje zadání platného hesla při jakékoli změně uživatelského účtu. Pokud by došlo k odcizení přihlášeného sezení uživatele nebude moci změnit heslo či např. e-mailovou adresu v nastavení účtu. V takovémto případě ale může útočník napáchat škody v jiných částech systému (např. provést změnu hesla jinému účtu nebo manipulovat s doménami apod.). Úrovně oprávnění Program je navržen tak, aby reflektoval různé uživatelské oprávnění. Při vytváření uživatelského účtu je nutné zvolit, jakou roli bude uživatel představovat vůči programu. Podle této volby mu bude umožněno provádět příkazy nad doménami, kontakty a dalšími částmi programu. Podle oprávnění uživatele se rovněž zobrazí odpovídající položky v menu programu, jakmile se uživatel přihlásí. Definované role Program ve výchozí konfiguraci rozeznává následující role, které je možné přiřazovat uživatelům: Uživatel Role “uživatel” umožňuje provádět základní akce nad doménami a kontakty, které jsou výhradně přiřazeny k uživateli. Tato role je vhodná pro koncové uživatele (retenční zákazníky). Správce skupiny Tato role rozšiřuje roli “uživatel” a přidává oprávnění manipulovat s doménami a kontakty všech uživatelů v rámci skupiny. Navíc umožňuje správu těchto uživatelů a skupin DNS serverů ve skupině. Tato role je určená pro subregistrátory. Administrátor Role “administrátor” má doslova neomezené oprávnění. Uživatel s touto rolí smí provádět veškeré akce nad doménami, kontakty a dalšími částmi programu. Tato role je určena výhradně pro zaměstnance registrátora pro účely podpory uživatelů a provádění akci na základě požadavků přijatých telefonicky nebo e-mailem.
39
Rozdíly mezi oprávněními všech těchto rolí přehledně zobrazuje tabulka 1. Tabulka 1: Oprávnění pro jednotlivé role
Doménová jména (registrace, prodloužení, změny, transfer) Správa kontaktů (vytvoření, změny, smazání, transfer) Objednávky (vytvoření, přehled) Objednávky (zpracování, zrušení) Skupiny DNS serverů (vytvoření, změny, smazání, transfer Uživatelské skupiny (vytvoření, změny, blokace, smazání) Správa skupin (vytvoření, změny, blokace, smazání) Správa ceníků (vytvoření, změny, blokace, smazání) Obecně platné oprávnění na objekty
Uživatel Pouze vlastní domény
Správce skupiny Domény v rámci skupiny
Administrátor Všechny domény
Pouze vlastní kontakty7
Kontakty v rámci skupiny 7
Všechny kontakty
Pouze vlastní objednávky
Objednávky v rámci skupiny
Pouze vlastní skupiny DNS
Skupiny DNS serverů v rámci skupiny
Všechny objednávky Všechny objednávky Všechny skupiny DNS serverů
Pouze vlastní profil
Uživatelé v rámci skupiny8
Všichni uživatelé
Všechny skupiny
Všechny skupiny
Pouze vlastní objekty
Objekty v rámci skupiny
Všechny objekty
Oprávnění pro jednotlivé role jsou specifikovány v konfiguračním souboru aplikace (app/config/acl.neon). Soubor je formátován v textovém formátu yml a jsou zde definovány jak role, tak typy objektů a akce, které nad nimi daná role může provádět. 7
Kontakty typu “technický správce” může vytvářet pouze Administrátor, upravovat je následně může i správce skupiny v závislosti na příslušnosti kontaktu ke skupině. 8 Správce skupiny může přiřazovat role s maximální úrovní odpovídající jeho roli. Správce skupiny tedy není např. schopen vytvořit uživatele s rolí administrátor nebo s takovým uživatelem jakkoli manipulovat.
40
Následující nastavení povoluje roli “uživatel” získat nabídku skupin DNS serverů pro přiřazení k doméně: - allow(user, DomainNSSet, [listNSSetAutocomplete]) Ve stejném duchu je možné poměrně jednoduše zavést další role se specifickým oprávněním (např. role “účetní” s oprávněním pouze na objednávky nebo roli “technik” s oprávněním pouze na technické změny nastavení DNS).
4.7
Popis webového rozhraní programu
Webové rozhraní je tvořeno podle standardu HTML4.1 a CSS2 s použitím komponent Javascriptového frameworku JQueryUI. Každá stránka programu je vždy rozdělena na hlavičku s panelem uživatele, logem a dvouúrovňovým menu coby hlavním ovládacím prvkem programu. Následuje tělo stránky (viz obr.8). Dále jsou v programu použity následující javascriptové ovládací prvky: • rozbalovací seznam s vyhledáváním: Select2 • správa tabulek: DataTables.net
Obrázek 8: Ukázka webového rozhraní programu
4.8
Testování programu
Každý modul programu obsahuje podsložku tests, kde jsou umístěny jednotkové testy a v některých případech i integrační testy pro automatické testování. Zvolená architektura umožňuje efektivní testování jednotlivých součástí, aniž by bylo nutné řešit složité závislosti. 41
Uživatelské testování programu Pro účely testování programu v testovacím prostředí byl zřízen viruální server. Instrukce a přístupy k testovací verzi aplikace jsou uloženy v adresáři doc/instrukcepro-testovani.txt.
4.9
Instalace programu a požadavky na server
Program je navržen tak, aby byl provozován na serveru a uživatelské rozhraní pro ovládání poskytuje prostřednictvím webového prohlížeče. Požadavky na prostředí serveru jsou následující9 : • operační systém serveru - GNU/Linux (ideálně Debian 7 Wheeze) • webový server - Apache2 (min. 2.4.10) s moduly mod_rewrite a • interpret programovacího jazyka - PHP5.5 (min. 5.5.26) s moduly php5_mysql, php5_mysqlnd, php5_mcrypt (pro vývoj použity balíčky z distribuce DotDeb.org) • databázový server - MySQL 5.6 a vyšší • dále je nutné mít vygenerovány locales s podporou “cs_CZ.utf8” Postup instalace aplikace na připravený server: 1. Aplikaci umístěnou na CD ve složce src/ zkopírujte na server do místa, kam má přístup webový server Apache (obvykle /var/www). 2. Nastavte položku nastavení webového serveru DocumentRoot na cestu k podadresáři programu www. 3. Ujistěte se, že veškeré soubory a složky aplikace jsou určeny pouze pro čtení uživateli, pod kterým běží webový server (obvykle uživatel www-data). 4. Pro následující adresáře nastavte rekurzivně i práva zápisu: • app/templates/ • log/ • temp/ 5. V MySQL serveru vytvořte databázi s kódováním UTF-8 a collation utf8general-ci. 6. Vytvořte uživatele s plným oprávněním na právě vytvořenou databázi. 9
Předmětem této práce není uvést čtenáře do problematiky správy linuxového serveru. Předpokládá se, že si zřízení serveru objedná od dodavatele s potřebnými technickými znalostmi.
42
7. Naimportujte schéma databáze ze souboru data/schema.sql. 8. Proveďte poinstalační konfiguraci programu Konfigurace programu: Konfigurační soubor programu config.neon je uložen v adresáři app/config/. Konfigurační soubor je typu YML, při editaci je tedy nutné zachovat odsazení jednotlivých parametrů. V opačném případě nebude schopen konfigurační soubor číst a skončí chybou. 1. Změňte nastavení pro připojení k databázi v sekci Common -> parameters -> database. 2. Nastavte přístup k EPP serverům registrů. Pro přístup k registru CZNIC je nutné správně nastavit cestu k platnému certifikátu evidovanému registrem! Nyní by mělo být možné zobrazit webové rozhraní programu v prohlížeči zadáním jména serveru. Pokud instalace proběhla v pořádku, zobrazí se přihlašovací dialog a umožní prvotní přihlášení s výchozím uživatelem typu administrátor (uživatelské jméno: admin, heslo: DNMS1234). V případě, že se Vám aplikaci nepodaří spustit, podívejte se do logových souborů v podsložce programu logs/, případně požádejte správce serveru o kontrolu logových souborů webového serveru apache.
43
Závěr Cílem práce bylo vytvořit program pro registraci a správu DNS domén 2. úrovně. První část textu se věnuje vysvětlení základních pojmů z problematiky DNS domén a popisuje elektronickou komunikaci s registry CZNIC a EURid. Dále navazuje popis vlastní implementace programu a způsobu řešení jednotlivých problémů. Architektura programu a mechanismus výměny zpráv se servery registrů byly úspěšně navrženy tak, aby zprostředkovali komunikaci s oběma registry a umožnili přidání podpory jakéhokoli dalšího nezávisle na protokolu. Program byl navíc implementován s výhledem na možnou podporu současné správy portfólia více registrátorů. Stejně tak byly splněny i dílčí požadavky na podporu fakturace ve formě objednávky a zálohové faktury a úhradu za úkony z kreditu uživatele. Úkolem programu nebylo implementovat fakturaci jako takovou, spíše se předpokládá napojení na účetní software registrátora, stejně jako napojení na dostupné platební brány. Ačkoli se program snaží pokrýt většinu administrativních úkonů ve spojitosti se správou domén pro provozovatele webhostingu řeší pouze část jeho vnitřních procesů. Pro další rozšíření programu by tedy bylo vhodné implementovat funkce pro správu webhostingového prostoru. V rámci možného vývoje by bylo rovněž vhodné zapracovat podepisování DNS zón pomocí tzv. DNSSEC klíčů. Oba řešené registry tuto možnost zabezpečení podporují.
44
Conclusions The goal of this thesis was to create a program, which implements registration and management of second level DNS domain names. The first part of the text covers explanation of basic terms related to DNS domains and describes electronic communication with the registries CZNIC and EURid. Then the description of the implementation and of the solutions of problems is mentioned. The architecture of the program and message exchange machanism have been successfully designed the way to provide communication with both registries and to enable addtional support of any other registry despite of the used protocol. The program can be also extended to support more registrars at the same time. The secondary requirement, the invoicing support has been covered by purchase order and proforma invoice. The credit based payments have been implemented as well. The scope of the program wasn’t to replace invoicing system of the registrar, it’s supposed that interface to the invoicing system should be implemented as a possible extension of the program. The same applies to the implementation of payment gateway systems supported by the registrar. Even if the program covers the most of the administrative tasks related to the domain name management, it means only a part of internal processes of the webhosting service provider. The rest could be implemented as an extension. In the meaning of future development, it would be appropriate to implement signing of DNS zones using DNSSEC keys. Both introduced registries already support this kind of security measures.
45
A
Obsah přiloženého CD/DVD
Na samotném konci textu práce je uveden stručný popis obsahu přiloženého CD/DVD, tj. jeho závazné adresářové struktury, důležitých souborů apod. doc/ Text práce ve formátu PDF, vytvořený s použitím závazného stylu KI PřF UP v Olomouci pro závěrečné práce, včetně všech příloh, a všechny soubory potřebné pro bezproblémové vygenerování PDF dokumentu textu (v ZIP archivu), tj. zdrojový text textu, vložené obrázky, apod. src/ Kompletní zdrojové texty programu Program / webové aplikace Webovka se všemi potřebnými (příp. převzatými) zdrojovými texty, knihovnami a dalšími soubory potřebnými pro bezproblémové vytvoření spustitelných verzí programu / adresářové struktury pro zkopírování na webový server. readme.txt Instrukce pro instalaci a spuštění programu Program, včetně všech požadavků pro jeho bezproblémový provoz. / Instrukce pro nasazení webové aplikace Webovka na webový server, včetně všech požadavků pro její bezproblémový provoz, a webová adresa, na které je aplikace nasazena pro účel testování při tvorbě posudků práce a pro účel obhajoby práce. U veškerých cizích převzatých materiálů obsažených na CD/DVD jejich zahrnutí dovolují podmínky pro jejich šíření nebo přiložený souhlas držitele copyrightu. Pro všechny použité (a citované) materiály, u kterých toto není splněno a nejsou tak obsaženy na CD/DVD, je uveden jejich zdroj (např. webová adresa) v bibliografii nebo textu práce nebo v souboru readme.txt.
46
Bibliografie [1] Internationalized Domain Names. Dostupné https://www.icann.org/resources/pages/idn-2012-02-25-en
z:
[2] Jak fungují háčky a čárky v doménách?http://www.lupa.cz/clanky/jak-fungujihacky-a-carky-v-domenach/[Jiří Peterka, 2005] [3] IDN Domain Names with Accents and Umlautshttps://www.nic.ch/reg/cm/wcm-page/faqs/idn.jsp?lid=en [SWITCH Internet Domains, 2015] [4] Free Registry for Enum and Domains http://fred.nic.cz/ [CZ.NIC] [5] Doména, IP adresa, DNS http://www.jaknainternet.cz/page/1261/domena%2Cip-adresa%2C-dns/ [CZ.NIC, 2014] [6] Nette http://nette.org [David Grudl] [7] http://www.zdrojak.cz/clanky/architektura-aplikace-nad-doctrine-2/ [8] http://www.doctrine-project.org/projects/orm.html [9] GRUDL, David.[online]. Dostupné ze http://latte.nette.org/en/ [10] GRUDL, David.[online]. Dostupné z http://ne-on.org [11] Pravidla technické komunikace,https://www.nic.cz/files/nic/doc/ dla_technicke_komunikace_20111001.pdf, online 2005
Pravi-
[12] Popis el. komunikace, https://www.nic.cz/files/nic/doc/constraints.pdf [13] Pravidla registrace doménových jmen v ccTLD .cz, https://www.nic.cz/files/nic/doc/ Pravidla_registrace_CZ_Pravidla_ADR_20150301.pdf [14] EURid, Part I: Registration Guidelines .euRP [PDF, 2015] [15] EURid, Part II: EPP Guidelines [PDF, 2014] [16] EURid, Characters allowed in Name, Organisation and Address fields [PDF, 2013] [17] EURid, Registrar notifications [PDF, 2013]
47
