Prehľad terminológie, komponentov a konceptov DNS

DNS (Domain Name System) je jedným z kľúčových komponentov poháňajúcich internet. Správne pochopenie toho, ako DNS funguje, môže pomôcť diagnostikovať problémy s konfiguráciou webových stránok a rozšíriť vaše chápanie toho, čo sa deje v zákulisí.

V tejto príručke si povieme o niektorých základných konceptoch DNS, aby sme vám poskytli pevný základ pri práci s vašou konfiguráciou DNS. Táto príručka vám tiež pomôže nastaviť si vlastný názov domény alebo DNS server.

Začnime!

Terminológia domén

Najprv si musíme ujasniť pojmy, ktoré budeme používať. S niektorými z nich už možno máte skúsenosti z iných kontextov. Pri diskusii o názvoch domén a DNS však existuje mnoho špecifických pojmov, o ktorých sa v iných oblastiach informatiky veľa nehovorí.

• Systém názvov domén

Systém názvov domén (skrátene DNS) je sieťový systém, ktorý prekladá pre ľudí zrozumiteľné názvy domén na jedinečné IP adresy.

• Názov domény

Názov domény označuje pre ľudí zrozumiteľný názov používaný na priradenie k internetovému zdroju. Napríklad “cloudsigma.com” je názov domény. Niekto by mohol namietať, že názvom domény je iba časť “cloudsigma”, ale vo všeobecnosti sa to vzťahuje na celok.

URL adresa “cloudsigma.com” je spojená so servermi vlastnenými spoločnosťou CloudSigma. Pri zadaní URL adresy do webového prehliadača komunikuje s DNS, aby sa pripojil k IP adrese cieľového servera.

• IP adresa

IP adresa funguje ako sieťová adresa pre zariadenie pripojené k sieti. Každá IP adresa musí byť v rámci siete jedinečná. V kontexte webových stránok je sieťou väčšinou celý internet.

Existujú dva typy IP adries:

• • IPv4: Toto je najbežnejšia forma IP adresy. Píše sa ako skupina štyroch čísel, pričom každá skupina má až 3 číslice. Jednotlivé skupiny sú oddelené bodkou. Rozsah IPv4 je od 0.0.0.0 do 255.255.255.255.

  • IPv6: Ide o modernejší štandard, ktorý bol vyvinutý na vyriešenie problému s vyčerpaním adries IPv4. IPv4 podporuje až 232 jedinečných adries, zatiaľ čo IPv6 podporuje až 2128 adries. Akákoľvek adresa IPv6 sa píše v hexadecimálnych čísliciach. Môže obsahovať až 32 číslic, rozdelených do 8 sekcií (4 číslice v každej sekcii). Každá sekcia je oddelená dvojbodkou (:).

Doména najvyššej úrovne

Doména najvyššej úrovne (skrátene TLD) je najvšeobecnejšia časť domény. Vzťahuje sa na časť úplne vpravo (oddelenú bodkou). Medzi bežné domény najvyššej úrovne patria:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

Pokiaľ ide o názvy domén, tieto domény sú na vrchole hierarchie. ICANN (Internet Corporation for Assigned Names and Numbers) môže udeliť povolenie na kontrolu nad doménami najvyššej úrovne určitým stranám. S povolením môžu tieto strany distribuovať názvy domén pod danou TLD (zvyčajne prostredníctvom registrátora domén).

• Hostitelia

V doméne môže vlastník špecifikovať jednotlivých hostiteľov, čo sa týka samostatných strojov/služieb prístupných cez doménu. Napríklad je bežnou praxou sprístupniť webové servery prostredníctvom samotnej domény ( example.com) a definície “hostiteľa” “www  ( www.example.com).

Pod všeobecnou doménou je možné mať ďalších hostiteľov, napríklad prístup k API cez hostiteľa “api” ( api.example.com), prístup k FTP cez hostiteľa “ftp” alebo “files” ( ftp.example.com alebo files.example.com).

Upozorňujeme, že názvy domén môžu byť ľubovoľné, pokiaľ sú v rámci domény jedinečné.

• Subdoména

Subdoména je téma súvisiaca s hostiteľmi. DNS funguje v hierarchii. TLD môže mať pod sebou mnoho domén. Napríklad “ example.com”, “ cloudsigma.com”, atď. sú všetky pod TLD “com”. V tomto ohľade je subdoména odkazom na akúkoľvek doménu, ktorá je súčasťou cieľovej domény. Môžeme teda povedať, že “example.com” je subdoménou “com”. Vo všeobecnosti sa časť “example” označuje ako SLD (second-level domain).

Podobne môže doména kontrolovať všetky “subdomény”, ktoré sa pod ňou nachádzajú. Na to sa zvyčajne používa výraz “subdoména”. Napríklad “ history.example.com” je subdoménou “ example.com”.

Kľúčový rozdiel medzi názvom hostiteľa (hostname) a subdoménou je v tom, že hostiteľ definuje počítač/prostriedok, zatiaľ čo subdoména rozširuje nadradenú doménu. Kedykoľvek hovoríme o subdoménach alebo hostiteľoch, môžete si to overiť pohľadom na najľavejšiu časť domény, pretože tá je najšpecifickejšia. Takto funguje DNS: od najšpecifickejšej (najľavejšia strana) po najmenej špecifickú (najpravejšia strana).

• Plne kvalifikovaný doménový názov

Plne kvalifikovaný doménový názov (skrátene FQDN) označuje absolútny doménový názov. V systéme DNS môžu byť domény uvádzané relatívne voči sebe navzájom. To môže viesť k určitej nejednoznačnosti. FQDN je však absolútny názov odkazujúci na absolútny koreň systému doménových názvov.

To znamená, že FQDN špecifikuje každú nadradenú doménu vrátane TLD. Vhodným príkladom by bolo “ mail.google.com”. V konkrétnych prípadoch nemusí FQDN končiť bodkou, ale musí obsahovať koncovú bodku (vyžadovanú štandardmi ICANN).

• Menný server

Menný server je vyhradený počítač na preklad doménových názvov na IP adresy. Menné servery nesú väčšinu záťaže v systéme DNS. Keďže celkový počet požiadaviek na preklad domén je príliš vysoký na to, aby ho zvládol jeden server, požiadavky sú často presmerované na iné menné servery, aby sa zmiernil tlak.

Menný server môže byť “autoritatívny”, čo znamená, že odpovedá iba na dopyty týkajúce sa domén pod jeho správou. Takéto servery môžu požiadavku odovzdať iným menným serverom alebo poskytnúť kópiu údajov iných menných serverov z vyrovnávacej pamäte.

• Zónový súbor

Zónový súbor je textový súbor obsahujúci mapovania medzi doménovými názvami a IP adresami. Slúži ako databáza systému DNS. Toto je katalóg, ktorý DNS používa na vyhľadanie IP adresy, ktorú má kontaktovať pri vybavovaní požiadavky používateľa na určitý doménový názov.

Menné servery vo všeobecnosti hostujú zónové súbory a definujú prostriedky dostupné pod jednou doménou. Môžu tiež obsahovať informácie o tom, kam ísť na získanie týchto informácií.

• Záznamy

Zónový súbor pozostáva z mnohých záznamov. Záznam je tu definovaný ako jedno mapovanie medzi prostriedkom a názvom. Záznamy môžu byť mapovaním doménového názvu na IP adresu, prostriedkami dostupnými pod konkrétnou doménou alebo odkazmi na miesta, kde je možné získať dané informácie.

DNS v akcii

Doteraz sme sa oboznámili s niektorými bežnými termínmi spojenými s DNS. Ako však tento systém v skutočnosti funguje? Na vysokej úrovni sa systém môže zdať veľmi jednoduchý. Prechod do podrobností však odhalí jeho skutočnú zložitosť. Celkovo je systém DNS dôležitý pre masové rozšírenie internetu.

• Koreňové servery

DNS vo svojej podstate funguje v hierarchii. Na samom vrchole systému sa nachádzajú “koreňové servery”. Tieto servery sú pod kontrolou rôznych organizácií. Právomoc týchto serverov je delegovaná organizáciou ICANN (Internet Corporation for Assigned Names and Numbers).

V súčasnosti je v prevádzke približne 13 koreňových serverov. Kvôli záťaži je však každý z týchto serverov zrkadlený. Je dôležité poznamenať, že všetky zrkadlové servery zdieľajú rovnakú IP adresu ako koreňový server. Kedykoľvek je odoslaná požiadavka na koreňový server, požiadavka je presmerovaná na najbližšie zrkadlo tohto servera.

Aké sú úlohy koreňových serverov? Poskytujú informácie o doménach najvyššej úrovne. Kedykoľvek menný server nižšej úrovne nedokáže vyriešiť požiadavku, je presmerovaná na koreňový server domény.

Koreňový server však v skutočnosti nepozná umiestnenie domény. Presmeruje iba požiadavku, ktorú spracuje konkrétne požadovaná doména najvyššej úrovne. Ak je napríklad odoslaná požiadavka na “ blog.cloudsigma.com”, koreňový server ju nebude mať vo svojich záznamoch. Prehľadá svoje zónové súbory, ale nenájde o nej žiadny záznam. Namiesto toho rozpozná doménu najvyššej úrovne (TLD) “com” a presmeruje žiadajúci subjekt na menný server, ktorý spravuje adresy “com”.

• TLD servery

Ak budeme pokračovať v našom predchádzajúcom príklade, žiadajúci subjekt teraz odošle požiadavku na IP adresu (ktorú poskytol koreňový server). V prípade “ blog.cloudsigma.com”, menný server “com” prehľadá svoje záznamy vo svojich zónových súboroch.

Nenájde sa žiadny záznam zodpovedajúci požiadavke. Nájde však záznam s IP adresou menného servera zodpovedného za “ cloudsigma.com”.

• Menný server na úrovni domény

Teraz má žiadajúci subjekt IP adresu menného servera, ktorý skutočne hostí informácie o “ blog.cloudsigma.com”. Teraz odošle novú požiadavku na server so žiadosťou o preklad adresy “www.cloudsigma.com”.

Rovnako ako predtým, menný server skontroluje svoje zónové súbory a nájde ten, ktorý je priradený k “ cloudsigma.com”. Vo vnútri tohto súboru sa bude nachádzať záznam pre hostiteľa “www”. Tento záznam popisuje, kde sa hostiteľ nachádza. Konečná odpoveď sa potom odovzdá žiadajúcemu subjektu.

• Prekladací menný server

V príklade sme spomenuli žiadajúci subjekt. Čo to je? Vo väčšine prípadov bude žiadateľom “prekladací menný server”. Je to server, ktorý je nakonfigurovaný tak, aby kládol otázky iným serverom. Funguje ako sprostredkovateľský server pre používateľov. Ukladá výsledky do vyrovnávacej pamäte (cache), aby sa zvýšila rýchlosť.

Každý používateľ má zvyčajne vo svojom systéme nakonfigurovaných niekoľko prekladacích menných serverov. Prekladacie menné servery vo všeobecnosti ponúka poskytovateľ internetových služieb (ISP) alebo iné organizácie. Napríklad Google ponúka verejné prekladacie DNS servery, na ktoré sa môžete dopytovať. Môžete si ich manuálne nakonfigurovať vo svojom systéme.

Pri zadaní adresy URL do webového prehliadača sa vyhľadáva umiestnenie zdroja. Najprv sa vyhľadávanie vykoná lokálne. To zahŕňa súbor “hosts” (a niektoré ďalšie umiestnenia). Ak sa nenájde, požiadavka sa odošle na prekladací menný server. Po prijatí požiadavky prekladací menný server vyhľadá odpoveď vo svojej vyrovnávacej pamäti. Ak ju nenájde, prejde krokmi uvedenými predtým.

Prekladacie menné servery zjednodušujú proces dopytovania pre koncového používateľa. Klientovi stačí požiadať prekladacie menné servery o umiestnenie zdroja. Menný server to preverí a vráti konečnú odpoveď.

• Zónové súbory

Už sme diskutovali o konceptoch “zónových súborov” a “záznamov”. Ako teda fungujú?

Zónové súbory fungujú ako databáza pre menné servery a ukladajú informácie o doménach, o ktorých vedia. Všetky domény, o ktorých menný server vie, budú uložené v jeho zónovom súbore. Väčšina požiadaviek prichádzajúcich na menný server sa však nerieši pomocou zónového súboru. Ak je konfigurácia servera nastavená na spracovanie rekurzívnych dopytov (napríklad prekladacie menné servery), vráti odpoveď. V opačnom prípade presmeruje žiadajúcu stranu na iné miesto, kde má hľadať ďalej.

Čím viac zónových súborov menný server hostí, tým autoritatívnejšie budú jeho odpovede. Zónové súbory popisujú DNS “zónu” (podmnožinu celého systému pomenovania DNS). Zónový súbor vo všeobecnosti obsahuje konfiguračné údaje len jednej domény. Môže obsahovať množstvo záznamov definujúcich umiestnenie zdrojov príslušnej domény.

Parameter $ORIGIN zóny sa rovná najvyššej úrovni autority danej zóny. Napríklad zónový súbor pre “ cloudsigma.com” bude mať svoj $ORIGIN nastavený ako “ cloudsigma.com”. Hodnota parametra môže byť uložená na začiatku zónového súboru alebo v konfigurácii DNS servera. V každom prípade parameter popisuje, pre ktorú zónu je súbor autoritatívny.

Parameter $TTL nastavuje informáciu o “čase životnosti” (time to live) poskytnutého výsledku. Dá sa opísať ako časovač, ktorý môže ukladací server použiť na sledovanie platnosti uložených odpovedí. Ak hodnota TTL vyprší, odpoveď už nie je platná a zahodí sa.

• Typy záznamov

Zónové súbory pozostávajú z mnohých záznamov. Existujú rôzne typy záznamov. Ďalej si prejdeme niektoré z najbežnejších (a povinných) typov záznamov:

Záznamy SOA

Záznam Start of Authority (skrátene SOA) je povinný vo všetkých zónových súboroch. Musí to byť prvý skutočný záznam v súbore. Avšak záznamy ako $ORIGIN alebo $TTL sa môžu objaviť predtým.

Záznam SOA je jedným zo zložitejších typov záznamov. Jeho štruktúra vyzerá približne takto:

Rozoberme si to podrobnejšie:

• • example.com: Táto časť definuje koreň zóny. V tomto príklade je zónový súbor pre doménu “ example.com”. Niekedy môže byť táto hodnota nahradená znakom @ (zástupný symbol na nahradenie hodnoty $ORIGIN).

  • IN SOA: Výraz “IN” znamená “internet”. Nájdete ho v mnohých záznamoch. Výraz “SOA” označuje, že ide o záznam SOA.

  • ns1.example.com: Táto hodnota obsahuje primárny menný server (nameserver) pre doménu “ example.com”. Menné servery môžu byť primárne alebo sekundárne. Ak boli nakonfigurované s dynamickým DNS, potom musí existovať jeden “primárny” server. Ak nebolo nakonfigurované žiadne dynamické DNS, potom to bude jeden z primárnych menných serverov.

  • admin.example.com: Tu patrí e-mailová adresa správcu zóny. Všimnite si, že znak @ je tu nahradený znakom .. Ak pôvodná e-mailová adresa obsahuje bodku, nahradí sa znakom \. Napríklad “ my.domain@example.com” by sa zmenilo na “ my\domain.example.com”.

  • 12083: Je to sériové číslo zónového súboru. Pri každej úprave zónového súboru sa toto číslo musí aktualizovať, aby sa súbor správne propagoval. Sekundárne servery používajú toto sériové číslo na sledovanie toho, či sú ich vlastné zónové súbory aktuálne.

  • 3h: Predstavuje interval obnovy (refresh interval) pre zónu. Sekundárne servery budú čakať tento čas, kým skontrolujú aktualizácie zónového súboru.

  • 30m: Táto hodnota predstavuje interval opakovania (retry interval) zóny. Ak sa sekundárnemu serveru nepodarí pripojiť k primárnemu serveru po uplynutí doby obnovy, počká tento čas, kým sa znova opýta primárneho servera.

  • 3w: Táto hodnota predstavuje dobu expirácie (expiry period). Ak sa sekundárnemu serveru nepodarí pripojiť k primárnemu serveru po túto dobu, prestane vracať odpovede ako “autoritatívne”.

  • 1h: Táto hodnota predstavuje dobu, po ktorú bude menný server ukladať do vyrovnávacej pamäte chybu názvu (name error), ak sa nenašiel v jeho zónovom súbore.

Záznamy A a AAAA

Tieto záznamy vytvárajú mapovanie medzi hostiteľom a IP adresou. Záznam “A” označuje mapovanie IPv4 na hostiteľa a AAAA mapovanie IPv6.

Toto je základná štruktúra záznamov A a AAAA:

V príklade záznamu SOA sme menný server nazvali “ ns1.exampel.com”. Menný server spadá pod doménu “ example.com”. Takto by vyzeral jeho záznam A:

Všimnite si, že sme nemuseli uviesť celý názov. Iba s názvom hostiteľa (bez FQDN) môže DNS server doplniť zvyšok hodnotou z $ORIGIN. Stále však môžeme použiť FQDN:

Tu je návod, ako definovať webový server ako “www”:

Mali by sme tiež zahrnúť mapovanie na základnú doménu. Záznam by vyzeral takto:

Prípadne môžeme použiť @ symbol na označenie základnej domény (namiesto jej celého názvu):

Je dobrou praxou zahrnúť zástupný záznam (wildcard), ktorý umožňuje prekladať čokoľvek pod touto doménou, čo nebolo explicitne definované:

Rovnaká štruktúra platí pre záznamy typu AAAA. Jediným rozdielom sú IPv6 adresy.

Záznamy CNAME

Záznamy CNAME fungujú ako alias pre kanonický názov servera (definovaný záznamom typu A alebo AAAA). Pozrite sa na nasledujúci príklad:

Tu sme použili “server1” ako alias pre definovanie názvu “www”. Upozorňujeme, že takéto skratky majú vplyv na výkon, pretože server musí spustiť ďalšie dopyty, aby získal konečnú odpoveď. V závislosti od počtu vrstiev aliasov to môže ľahko spôsobiť veľké zníženie výkonu. Existuje však jeden špecifický prípad, ktorý profituje z aliasovania CNAME, napríklad poskytovanie zdroja mimo aktuálnej zóny.

Záznamy MX

Záznamy MX definujú poštové servery (mail exchange) pre doménu. Pomáhajú správnemu doručeniu e-mailu na server. Na rozdiel od iných záznamov, záznamy MX nemapujú hostiteľa na niečo iné, pretože platia pre celú zónu. To je dôvod, prečo záznamy MX vyzerajú približne takto:

Všimnite si, že na začiatku záznamu nie je žiadny názov hostiteľa. Tiež si všimnete, že v riadku je ďalšia hodnota. Je to číslo priority (preferencie), ktoré pomáha rozhodnúť, na ktorý server sa má pošta odoslať (ak je definovaných viacero poštových serverov). Čím nižšie číslo, tým vyššia priorita.

Záznam MX by mal smerovať na hostiteľa definovaného záznamom typu A alebo AAAA (nie CNAME). Majte to na pamäti, ak sú nakonfigurované dva poštové servery, záznamy by vyzerali takto:

V tomto príklade, súdiac podľa čísla priority, je server “mail1” preferovanejší ako “mail2”. Kód môžeme ďalej skrátiť vynechaním celého názvu domény:

Záznamy NS

Tieto záznamy definujú menné servery (nameservery) pre konkrétnu zónu. Teraz sa ponúka otázka: ak sa súbor zóny nachádza v rámci menného servera, prečo vyžaduje odkaz na seba samého? Jednou z odpovedí na túto otázku sú viaceré mechanizmy ukladania do vyrovnávacej pamäte (caching) v systéme DNS. Súbor zóny môže byť v skutočnosti iba kópiou v medzipamäti na iných serveroch.

Podobne ako záznamy MX, aj záznamy NS platia pre celú zónu. Predvolene preto nemajú žiadneho konkrétneho hostiteľa. Záznamy NS budú vyzerať približne takto:

Odporúča sa mať definované dva menné servery pre prípad, že by jeden server nefungoval správne. Väčšina DNS serverov navyše odmietne súbor zóny, ak obsahuje iba jeden menný server.

Mali by sme tiež zahrnúť mapovanie hostiteľov pomocou záznamov typu A alebo AAAA:

Záznamy PTR

PTR záznamy sú opakom klasického záznamu typu A alebo AAAA. Tieto záznamy sa používajú na definovanie názvu priradeného k IP adrese. Tieto záznamy majú jedinečnú vlastnosť, pretože začínajú na .arpa koreni a reprezentujú vlastníka IP adresy. Sú to RIR (Regional Internet Registries - Regionálne internetové registre), ktoré distribuujú IP adresy organizáciám a poskytovateľom služieb. Medzi RIR patria APNIC, AFRINIC, LACNIC, RIPE NCC a ARIN.

Napríklad PTR záznam pre 111.222.333.444 by vyzeral nejako takto:

V ďalšom príklade PTR záznamu sa pozrite na IPv6 DNS server spoločnosti Google 2001:4860:4860::8888:

Môžeme použiť nástroj dig s príznakom -x na vyhľadanie reverzného DNS názvu IP adresy. Pozrite si napríklad reverznú DNS IP adresu pre 8.8.4.4:

Internetové servery používajú PTR záznamy na sledovanie názvov domén v záznamoch logov, prijímanie informovaných rozhodnutí o spracovaní spamu a zobrazovanie ľahko čitateľných informácií o iných zariadeniach.

Bežne používané e-mailové servery vyhľadajú PTR záznam IP adresy, z ktorej bol e-mail odoslaný. Ak je PTR záznam prázdny, existuje vysoká šanca, že e-mail je spam (a preto bude odmietnutý). Upozorňujeme, že zhoda medzi FQDN a názvom domény v PTR zázname nie je podstatná. Dôležitým faktorom je, či je platný PTR záznam priradený k zhodnému a zodpovedajúcemu doprednému záznamu typu A.

Vo všeobecnosti majú sieťové smerovače na internete PTR záznamy zodpovedajúce ich fyzickému umiestneniu. Napríklad “NYC” alebo “CHI” sú platné referencie pre smerovače umiestnené v New Yorku a Chicagu. Táto technika je užitočná pri vykonávaní traceroute alebo MTR a kontrole trasy, ktorou pakety prechádzajú.

CAA záznamy

Tieto záznamy špecifikujú certifikačné autority (CA), ktoré môžu vydávať SSL/TLS certifikáty pre vašu doménu. Od 8. septembra 2017 sú všetky certifikačné autority povinné pred vydaním certifikátu skontrolovať CAA záznamy. Ak neexistuje žiadny CAA záznam, certifikát môže vydať akákoľvek certifikačná autorita. V opačnom prípade majú povolenie vydávať certifikáty iba konkrétne certifikačné autority. CAA záznamy je možné použiť buď na jednotlivých hostiteľov, alebo na celú doménu.

Tu je príklad CAA záznamu:

Časť záznamu špecifická pre CAA je 0 issue "letsencrypt.org". Táto časť sa skladá z troch častí:

• Príznaky: Je to celočíselná hodnota, ktorá určuje, ako má certifikačná autorita zaobchádzať so značkami, ktorým nerozumie. Ak je hodnota príznaku nastavená na 0, potom bude záznam ignorovaný. Ak je hodnota 1, certifikačná autorita musí odmietnuť vydať certifikát.
• Značky: Ide o reťazce označujúce účel CAA záznamu. V súčasnosti medzi platné hodnoty patria issue (oprávňuje certifikačnú autoritu vydávať certifikáty pre konkrétnu doménu), issuewild (povoľuje wildcard certifikáty) a iodef (definuje URL adresu, na ktorej certifikačné autority nahlasujú porušenia pravidiel).
• Hodnoty: Ide o reťazce priradené k značke záznamu. Ak je značka issue alebo issuewild, hodnota bude zvyčajne doména certifikačnej autority, ktorej udeľujete povolenie. Ak je značka iodef, bude to URL adresa kontaktného formulára alebo mailto: odkaz pre e-mailovú spätnú väzbu.

Na získanie CAA záznamov môžeme použiť nástroj dig:

Podrobnejšie informácie o CAA záznamoch nájdete v RFC 6844.

Záverečné myšlienky

Táto príručka popisuje rôzne terminológie súvisiace s DNS. Popisuje tiež, ako do seba všetky komponenty zapadajú. S týmto dôkladným prehľadom by ste mali dobre porozumieť fungovaniu systému DNS. Hoci je všeobecná myšlienka jednoduchá a ľahko pochopiteľná, detaily sa dokážu veľmi rýchlo skomplikovať. Pre neskúsených administrátorov môže byť náročné aplikovať tieto koncepty a stratégie.

Ste zákazníkom CloudSigma? Potom si pozrite správu a aktualizáciu reverzných DNS/PTR záznamov pre vašu infraštruktúru CloudSigma.

Príjemnú prácu s počítačom!