DNS je systém doménových mien, ktorý umožňuje nájsť internetové služby podľa zapamätateľných názvov. DNS záznamy určujú napríklad IP adresu webového servera, servery na prijímanie e-mailov alebo údaje na overenie domény. Keď otvoríme stránku www.vita.sk, zariadenie potrebuje zistiť, kam má požiadavku odoslať. Práve DNS mu pomáha získať potrebné informácie.

S DNS pracujeme pri spustení webu, pripájaní firemnej pošty, presune hostingu aj pri riešení nefunkčného internetu. V tomto článku si vysvetlíme jeho fungovanie, porovnáme najpoužívanejšie DNS záznamy a ukážeme si praktické nastavenia. Doplníme aj príkazy, pomocou ktorých dokážeme rozlíšiť chybu DNS od problému webu či siete.

Čo je DNS a na čo slúži

Skratka DNS znamená Domain Name System, po slovensky systém doménových mien. Môžeme si ho predstaviť ako distribuovaný adresár internetu, ktorého jednotlivé časti spravujú rôzni prevádzkovatelia. Namiesto zapamätávania číselných IP adries používame názvy domén, napríklad vita.sk. DNS však uchováva aj ďalšie informácie, preto jeho úloha presahuje jednoduchý preklad názvu na IP adresu.

DNS záznamy umožňujú priradiť jednej doméne viac IP adries a na jednej IP adrese môže fungovať viac webových stránok. Prevádzkovateľ zároveň môže presunúť web na nový server bez zmeny názvu, ktorý návštevníci poznajú. Stačí upraviť príslušné záznamy a pripraviť nový hosting. Samotná registrácia domény pritom automaticky nevytvorí funkčný web ani e-mailové schránky.

DNS v praxi pri otvorení webu a doručovaní e-mailu

Pri otvorení e-shopu prehliadač zisťuje adresu servera a následne s ním nadväzuje spojenie. Pri odoslaní správy na info@example.com poštový systém vyhľadáva údaje pre doménu example.com, aby našiel jej prijímacie poštové servery. Majiteľ domény môže cez DNS tiež potvrdiť vlastníctvo domény napríklad pri pripájaní cloudovej služby. Každá z týchto úloh využíva iný typ záznamu.

DNS neposkytuje obsah stránky ani nevytvára zabezpečené HTTPS spojenie. Zistenie správnej adresy je iba časť procesu, po ktorej musí fungovať sieťové spojenie, webový server aj certifikát. Preto môže DNS odpovedať správne a web napriek tomu zobrazovať chybu. Toto rozlíšenie nám pri diagnostike ušetrí množstvo času.

Ako funguje DNS od zadania domény po odpoveď

Vyhľadanie DNS informácie sa nazýva DNS dopyt. Zariadenie ho zvyčajne odosiela nakonfigurovanému resolveru, teda službe, ktorá zabezpečí vyhľadanie odpovede. Časť výsledkov už môže byť uložená v pamäti zariadenia alebo resolvera. V takom prípade sa nemusí opakovať celé vyhľadávanie v hierarchii DNS.

1. Zariadenie potrebuje údaj pre konkrétny názov. Môže ísť napríklad o IPv4 adresu webu.
2. Odošle dopyt resolveru. Ten skontroluje dostupnú vyrovnávaciu pamäť, teda cache.
3. Ak odpoveď nepozná, vyhľadá ju. V zjednodušenom príklade postupuje cez koreňové servery, servery domény najvyššej úrovne a autoritatívne servery príslušnej zóny.
4. Vráti výsledok zariadeniu. Údaj môže dočasne uložiť do cache a zariadenie ho využije na ďalšiu komunikáciu.

Priebeh DNS dopytu cez resolver s využitím cache alebo vyhľadaním odpovede

Zjednodušený priebeh DNS dopytu. Uložené údaje môžu skrátiť celé vyhľadávanie aj jednotlivé kroky v hierarchii.

Pri doméne vita.sk je doménou najvyššej úrovne .sk. Koreňové servery poznajú delegovanie na príslušnú úroveň hierarchie a servery pre .sk pomáhajú nájsť autoritatívne servery domény. Nie každý dopyt však začína pri koreňových serveroch, pretože resolver môže mať časť informácií uloženú. Niektoré resolvery tiež odovzdávajú požiadavky ďalšiemu resolveru.

Rekurzívny resolver a autoritatívny DNS server

Rekurzívny resolver vyhľadáva odpovede v mene klienta a často ich ukladá do cache. Takúto službu nám poskytuje napríklad poskytovateľ internetu, firemná sieť alebo prevádzkovateľ verejného DNS. Autoritatívny DNS server poskytuje údaje za zóny, ktoré obsluhuje. Ide o dve odlišné úlohy, hoci ich určitý softvér môže technicky vykonávať súčasne. [2]

Zmena DNS servera v notebooku preto upravuje službu, ktorej sa notebook pýta na názvy. Ak upravíme DNS záznamy domény, meníme údaje, ktoré sa o tejto doméne publikujú. Ak potrebujeme nasmerovať vlastný web na nový hosting, riešime druhú situáciu. Samotné nastavenie adresy 1.1.1.1 v počítači adresu nášho webu nezmení.

DNS zóna a delegovanie domény

DNS zóna je administratívne spravovaná časť priestoru doménových mien. Obsahuje záznamy, za ktoré zodpovedajú jej autoritatívne servery, pričom niektoré poddomény môžu byť delegované do samostatných zón. Doména a zóna preto nemusia označovať presne rovnaký rozsah. Pri bežnom hostingu pracujeme s ich správou cez administračné rozhranie poskytovateľa.

Registrátor domény, poskytovateľ DNS, webhosting a poskytovateľ pošty môžu byť štyri rôzne spoločnosti. Pred úpravou záznamov si preto overíme, ktoré autoritatívne servery doména skutočne používa. Ak zmeníme údaje v neaktívnej DNS zóne u bývalého poskytovateľa, návštevníci túto zmenu neuvidia. Delegovanie na nové servery sa zvyčajne nastavuje u registrátora.

Ak potrebujeme doplniť širší kontext sieťovej komunikácie, nadviažeme na online kurz Počítačové Siete I. Základy Počítačových Sietí. Venujeme sa v ňom modelom OSI a TCP/IP, adresovaniu, sieťovým zariadeniam aj analýze komunikácie. Lepšie tak pochopíme, kde DNS zapadá do fungovania celej siete.

DNS záznamy a ich typy v prehľadnej tabuľke

DNS záznamy sú jednotlivé údaje publikované v DNS zóne. Každý typ má vlastný účel a formát hodnoty. Pri nastavovaní preto nestačí iba vložiť adresu do ľubovoľného poľa. Musíme vedieť, či služba požaduje IP adresu, názov servera alebo textový údaj.

Prehľad vybraných typov DNS záznamov. Grafika je zjednodušená; MX obsahuje názov poštového servera, ku ktorému zisťujeme záznamy A alebo AAAA.

DNS záznamy A, AAAA, CNAME, MX, TXT, NS, PTR a SRV v prehľade

DNS záznamy A a AAAA pre adresy webového servera

Záznam A obsahuje IPv4 adresu, napríklad 192.0.2.10. Záznam AAAA obsahuje IPv6 adresu, napríklad 2001:db8::10. IPv6 adresa má 128 bitov, teda 16 bajtov. Ten istý názov môže mať oba typy záznamov, ak server a jeho sieťové pripojenie podporujú obidva spôsoby komunikácie. [5]

AAAA záznam pridávame až vtedy, keď na príslušnej IPv6 adrese služba skutočne funguje. Nesprávny AAAA záznam môže spôsobovať problém iba časti návštevníkov, hoci cez IPv4 stránka funguje. Do záznamov A a AAAA nevkladáme predponu https://, cestu k stránke ani číslo portu. Hodnotou je samotná IP adresa.

DNS záznam CNAME a rozdiel oproti presmerovaniu webu

CNAME smeruje názov na iný názov, napríklad www.example.com na example.com. Ide o alias v DNS, ktorý prehliadaču neposiela HTTP presmerovanie. Adresa v jeho riadku sa preto nemusí zmeniť. Presmerovanie z www na verziu bez www nastavujeme na webovom serveri alebo v príslušnej hostingovej službe.

Na rovnakom názve nemôžeme štandardný CNAME kombinovať s bežnými záznamami A, AAAA či MX; osobitne sa posudzujú sprievodné záznamy DNSSEC. Z tohto dôvodu sa štandardný CNAME nehodí na koreň zóny, kde musia existovať NS a SOA. Niektorí poskytovatelia ponúkajú ALIAS, ANAME alebo CNAME flattening, ktoré takúto situáciu riešia vlastným mechanizmom. Ich dostupnosť a správanie si overíme u konkrétneho poskytovateľa DNS.

DNS záznamy MX a TXT pre e-mailové služby

MX určuje, ktoré servery prijímajú poštu pre doménu. Nižšie číslo priority znamená prednostný server, takže priorita 10 má prednosť pred prioritou 20. Cieľom MX je názov servera, nie jeho IP adresa. Tento názov musí byť priamo preložiteľný na adresu cez A alebo AAAA a nemá byť aliasom CNAME.

TXT je univerzálnejší typ záznamu, ktorého obsah číta príslušná služba podľa vlastných pravidiel. Používame ho na overenie vlastníctva domény aj pri e-mailových mechanizmoch SPF, DKIM a DMARC. Tieto názvy nepredstavujú tri ďalšie bežné typy záznamov vedľa A či MX. Ide o mechanizmy, ktoré pri svojej činnosti využívajú DNS, predovšetkým TXT záznamy.

DNS záznamy NS SOA PTR a SRV v správe siete

NS záznamy súvisia s autoritatívnymi servermi zóny a jej delegovaním. SOA obsahuje riadiace informácie, napríklad sériové číslo zóny a časové parametre používané pri jej správe. Ak používame spravovanú DNS službu, tieto údaje často nastavuje poskytovateľ. Zmena NS záznamu priamo v zóne pritom sama osebe nemusí zmeniť delegovanie vedené v nadradenej zóne.

PTR využívame pri reverznom DNS, teda pri zisťovaní názvu podľa IP adresy. Pre IPv4 sa používa priestor in-addr.arpa a pre IPv6 ip6.arpa. Reverznú zónu obvykle spravuje poskytovateľ IP adresy, preto PTR často žiadame od prevádzkovateľa servera či pripojenia. Pridanie PTR do bežnej doprednej zóny domény nemusí mať požadovaný účinok.

SRV záznam obsahuje okrem cieľového servera aj port, prioritu a váhu. Hodí sa napríklad na vyhľadávanie služieb v prostrediach, ktorých klienti SRV podporujú. Bežnému webu však nepriradíme ľubovoľný port iba vytvorením SRV záznamu a očakávaním, že ho každý prehliadač použije. O využití záznamu rozhoduje podpora konkrétneho protokolu a aplikácie.

Ako nastaviť DNS záznamy pre web a firemný e-mail

Skôr než upravíme DNS záznamy, od poskytovateľov hostingu a pošty získame presné požadované hodnoty. Následne otvoríme správu aktívnej DNS zóny a uložíme si jej aktuálnu konfiguráciu. Pri každom novom zázname skontrolujeme názov, typ, hodnotu a TTL. E-mailové nastavenia meníme iba vtedy, keď sa zmena týka aj poštovej služby.

V ďalšom príklade používame doménu example.com a dokumentačné rozsahy IP adries. Slúžia na vysvetlenie a nepredstavujú adresy funkčného hostingu. Pri vlastnej doméne ich nahradíme údajmi poskytovateľa. Rovnako názvy poštových serverov a overovacie hodnoty preberáme z jeho dokumentácie.

Praktický príklad DNS záznamov pre jednu doménu

Pri vypĺňaní formulára pre DNS záznamy znak @ často označuje koreň spravovanej zóny, teda v našom príklade example.com. Názov www vytvorí záznam pre www.example.com, kým blog označuje samostatnú subdoménu. Niektoré rozhrania požadujú celý názov, iné iba jeho relatívnu časť. Bodka na konci názvu v zónovom súbore označuje úplný názov; v administračnom formulári sa riadime pokynmi poskytovateľa.

Priorita MX môže mať vlastné pole, do ktorého vložíme číslo 10, a názov servera zadáme osobitne. Príklad súčasne ukazuje, že web a e-mail môžu používať rôzne servery. Ak presúvame iba web, môžeme zmeniť jeho A a prípadne AAAA bez zmeny MX. Presunutie webu samo osebe nepresťahuje poštové schránky ani ich obsah.

Prehľad DNS nastavení Websupport

Vo Websupporte spravujeme DNS záznamy prostredníctvom administračného rozhrania WebAdmin. Po otvorení príslušnej domény prejdeme v ľavom menu do sekcie DNS, kde nájdeme prehľad existujúcich záznamov. Tabuľka na snímke zobrazuje názov, typ, obsah a hodnotu TTL, pričom jednotlivé položky môžeme upravovať. Nový DNS záznam začneme vytvárať tlačidlom Vytvoriť nový záznam.

DNS záznamy a nastavenia domény vo Websupport WebAdmine

Pri vytváraní nového záznamu najskôr vyberieme jeho typ podľa požiadaviek služby, ktorú pripájame. V zobrazenej časti ponuky nájdeme A, AAAA, ANAME a CAA. Pre IPv4 adresu používame A a pre IPv6 adresu AAAA. Websupport poskytuje aj ANAME na smerovanie hlavnej domény na iný doménový názov a jeho použitie sa riadi pravidlami poskytovateľa.

Výber DNS záznamov A, AAAA, ANAME a CAA vo Websupport WebAdmine

Posunutím zoznamu zobrazíme ďalšie dostupné typy DNS záznamov, napríklad SRV, TXT, CERT, LOC a SSHFP. Záznam TXT využijeme napríklad na overenie vlastníctva domény alebo publikovanie SPF konfigurácie. SRV poskytuje údaje na vyhľadanie konkrétnej služby vrátane cieľového servera a portu. Typ aj hodnoty vyberáme podľa dokumentácie pripájanej služby, pretože samotná dostupnosť položky v ponuke neznamená, že ju na doméne potrebujeme.

Výber ďalších DNS záznamov SRV, TXT, CERT, LOC a SSHFP vo Websupporte

Pred potvrdením hromadných alebo rýchlych nastavení skontrolujeme, ktoré DNS záznamy sa pridajú a ktoré odstránia. Predvoľby môžu upraviť viacero položiek súčasne a ovplyvniť fungovanie webu či pošty. Na kontrolu predchádzajúcich úprav môžeme použiť sekciu Prehľad zmien. Hodnoty zobrazené pri doméne ittest.sk nekopírujeme automaticky na vlastnú doménu a použijeme údaje určené pre naše služby.

DNS záznamy SPF DKIM a DMARC pre dôveryhodnejšiu poštu

SPF určuje, ktoré zdroje smú odosielať správy s príslušnou doménou v SMTP identite odosielateľa. Nekontroluje automaticky zhodu s adresou, ktorú používateľ vidí v hlavičke From. Pre jeden názov publikujeme jeden SPF záznam začínajúci v=spf1; samostatné SPF konfigurácie viacerých služieb musíme správne zlúčiť. Ďalšie TXT záznamy s iným účelom môžu existovať súčasne.

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.30 -all"

Tento model povoľuje jedinú uvedenú IPv4 adresu a pre ostatné zdroje vyjadruje výsledok SPF fail. Do reálnej konfigurácie musíme zahrnúť všetkých oprávnených odosielateľov, napríklad firemnú poštu, e-shop aj rozosielací nástroj. SPF má navyše limit mechanizmov a modifikátorov vyvolávajúcich DNS vyhľadávanie, preto neobmedzene nepridávame ďalšie include. Ukážku s dokumentačnou adresou nevkladáme do produkčnej domény.

DKIM pridáva k odchádzajúcej správe digitálny podpis a umožňuje príjemcovi overiť ho verejným kľúčom dostupným cez DNS. Údaj býva publikovaný pod názvom, ako je selector1._domainkey.example.com. Niektorí poskytovatelia požadujú TXT s verejným kľúčom, iní CNAME na svoj spravovaný záznam. Do verejného DNS nikdy nevkladáme súkromný podpisový kľúč.

DMARC nadväzuje na SPF a DKIM a posudzuje aj väzbu na doménu v hlavičke From. Vlastník domény môže publikovať politiku a požiadať o reporty. Na začiatok si môžeme predstaviť monitorovací záznam s p=none, ktorý sám nežiada odmietanie správ z dôvodu DMARC. Pri sprísňovaní politiky najskôr vyhodnotíme legitímne zdroje a výsledky reportov.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

V reálnom nastavení musí reportovacia adresa existovať a musíme zabezpečiť spracovanie prijímaných reportov. SPF, DKIM a DMARC znižujú možnosti zneužitia domény, ale nezaručujú doručenie každej správy do doručenej pošty. Tieto témy rozvíjame aj v online kurze Počítačové Siete III. Základy Bezpečnosti Sietí. V jeho obsahu nájdeme DNS vyhľadávanie, nastavovanie záznamov aj zabezpečenie domén pomocou SPF, DKIM a DMARC.

Overenie vlastníctva domény cez TXT záznam

Cloudová služba nám môže zobraziť overovací token, ktorý vložíme do TXT záznamu na presne určenom názve. Po uložení spustíme overenie v danej službe a podľa potreby počkáme na obnovenie cache. Existujúce SPF či iné overovacie TXT záznamy pritom nemažeme. To, či môžeme token po úspešnom overení odstrániť, závisí od pravidiel konkrétnej služby.

TTL a zmeny DNS záznamov bez zbytočných výpadkov

DNS záznamy majú hodnotu TTL (Time to Live), ktorá určuje, ako dlho môžeme údaje bežne používať z cache. Hodnota sa zadáva v sekundách, takže TTL 300 predstavuje päť minút a TTL 3600 jednu hodinu. Nižšia hodnota umožňuje rýchlejšie obnovenie záznamu, ale môže zvýšiť počet dopytov na autoritatívne servery. Vyššia hodnota predlžuje použitie uložených údajov.

Ak sa chystáme meniť IP adresu webu, môžeme TTL vopred znížiť napríklad z 86400 na 300, pokiaľ to služba umožňuje. Zmenu pripravíme s predstihom aspoň podľa pôvodného TTL, pretože už uložené odpovede si nové kratšie TTL spätne neprevezmú. Po presune overíme funkčnosť a TTL môžeme opäť zvýšiť. Pôvodný server ponecháme dostupný počas plánovaného prechodu.

Často používané tvrdenie, že každá zmena DNS trvá presne 24 alebo 48 hodín, je príliš všeobecné. Čas závisí od TTL konkrétnych údajov, delegovania, negatívnej cache aj správania resolverov. Cache totiž môže dočasne uchovávať aj informáciu, že určitý názov alebo typ záznamu neexistuje. Pri problémoch s dostupnosťou autoritatívnych serverov navyše niektoré resolvery za určených podmienok využívajú staršie údaje.

Pred zmenou autoritatívnych serverov najskôr pripravíme celú novú zónu vrátane pošty, overovacích TXT a poddomén. Pri doméne s DNSSEC musíme zosúladiť aj podpisovanie a DS záznam v nadradenej zóne. Nesprávne ponechaný DS môže spôsobiť, že validujúce resolvery budú správne vyzerajúce údaje odmietať. Presun DNS preto plánujeme podľa postupu pôvodného aj nového poskytovateľa.

Verejné DNS servery Google Cloudflare AdGuard a OpenDNS

Verejný DNS resolver je služba, ktorá pre naše zariadenie vyhľadáva DNS záznamy verejných domén. Jednotlivé služby sa líšia politikou filtrovania, ochranou súkromia aj dostupnosťou z našej siete. Nasledujúce IPv4 adresy sme overili v dokumentácii poskytovateľov k 17. októbru 2026. Nejde o poradie kvality ani o prísľub, že konkrétny resolver bude všade najrýchlejší.

Orientačný prehľad verejných DNS služieb. Úplné dvojice adries vrátane variantov Cloudflare Families uvádzame v tabuľke.

Verejné DNS servery Google, Cloudflare, AdGuard a OpenDNS s IPv4 adresami

Nastavenie DNS servera v počítači a routeri

V domácej sieti môžeme resolver nastaviť pre konkrétne pripojenie zariadenia alebo ho distribuovať cez router. Najskôr si uložíme pôvodné hodnoty a vyberieme dvojicu adries rovnakej služby a filtračnej politiky. Ak zmiešame filtrovaný a nefiltrovaný resolver, filtrovanie nemusí byť konzistentné. Spôsob výberu medzi viacerými servermi navyše závisí od operačného systému. [16]

Vo Windows hľadáme nastavenie priradenia DNS pri aktívnom sieťovom adaptéri; presné názvy položiek závisia od verzie systému. V routeri rozlišujeme resolver používaný samotným routerom a adresy poskytované klientom cez DHCP. Zohľadníme tiež IPv6 a prípadné zabezpečené DNS nastavené priamo v prehliadači. Po úprave si overíme, ktorému serveru zariadenie dopytyy skutočne odosiela.

Vo firemnej sieti, doméne Active Directory alebo pri VPN sa riadime konfiguráciou organizácie. Verejný resolver nemusí poznať interné názvy a jeho svojvoľná výmena môže znefunkčniť firemné služby. DNS filter zároveň nedokáže odstrániť každý reklamný prvok ani nahradiť antivírus či ďalšie bezpečnostné opatrenia. Jeho účinok závisí od toho, ktoré domény služba dokáže a potrebuje blokovať.

Ako overiť DNS záznamy vo Windows Linuxe a macOS

Keď overujeme DNS záznamy, najskôr zistíme, aký názov a typ nás zaujíma. Potom porovnáme odpoveď používaného resolvera s iným vhodným zdrojom. Verejné domény môžeme preveriť aj cez verejný resolver, kým interné názvy overujeme vo firemnej infraštruktúre. Nasledujúce dopyty sú iba na čítanie a nemenia DNS záznamy domény.

Kontrola DNS záznamov cez nslookup a PowerShell

Nástroj nslookup je dostupný vo Windows a nájdeme ho aj v ďalších systémoch. Bez určenia servera používa nakonfigurovaný resolver a jeho adresu vidíme vo výstupe. Parametrom -type vyberáme konkrétny typ záznamu. Ukážky si môžeme vyskúšať na verejnej doméne VITA.

nslookup vita.sk
nslookup -type=A vita.sk
nslookup -type=AAAA vita.sk
nslookup -type=MX vita.sk
nslookup -type=TXT vita.sk
nslookup -type=NS vita.sk
nslookup -type=A vita.sk 1.1.1.1

Označenie Non-authoritative answer znamená, že odpoveď neprišla ako autoritatívna odpoveď za danú zónu. Pri dopyte na rekurzívny resolver je to bežný výsledok a samo osebe nejde o chybu. Prázdna odpoveď pre AAAA zase automaticky neznamená nefunkčnú doménu, pretože môže fungovať cez A. Pri interpretácii vždy zohľadníme názov aj požadovaný typ.

V prostredí Windows PowerShell môžeme použiť aj príkaz Resolve-DnsName. Umožňuje vybrať typ a server a ponúka štruktúrovaný výstup vhodný na ďalšie spracovanie. Parameter -DnsOnly obmedzuje dopytovanie na DNS. Dostupnosť modulu závisí od systému a jeho prostredia.

Resolve-DnsName -Name vita.sk -Type MX -DnsOnly
Resolve-DnsName -Name vita.sk -Type A -Server 1.1.1.1 -DnsOnly

Overenie DNS záznamov cez dig v Linuxe a macOS

Príkaz dig poskytuje podrobnejší pohľad na odpoveď DNS. Ak ho v Linuxe nemáme, doinštalujeme balík s DNS nástrojmi podľa distribúcie a v macOS býva dostupný. Pri diagnostike sledujeme stav odpovede, sekciu ANSWER, TTL a použitý server. Skrátený výstup +short je pohodlný, no môže skryť údaje potrebné na odhalenie chyby.

dig vita.sk A
dig vita.sk AAAA
dig vita.sk MX
dig vita.sk TXT
dig vita.sk NS
dig @1.1.1.1 vita.sk A
dig vita.sk A +short
dig vita.sk +trace

Priamy dopyt na autoritatívny server zostavíme v tvare dig @ADRESA_AUTORITATIVNEHO_SERVERA DOMENA A +norecurse, pričom zástupné údaje nahradíme overenými hodnotami. Takto odlíšime publikovaný stav zóny od staršej odpovede v cache resolvera. Voľba +trace pomáha sledovať delegovanie, ale môže naraziť na sieťové obmedzenia. Dopyt typu ANY nepovažujeme za úplný výpis zóny, pretože server môže poskytovať iba obmedzenú odpoveď.

Praktickú prácu s diagnostikou rozvíjame v online kurze Počítačové Siete II. Základy Routingu a Switchingu. V jeho osnove nájdeme overovanie DNS pomocou nástrojov Nslookup, Dig a Host, prácu so sieťovými protokolmi aj modelovanie sietí. Kurz tak nadväzuje na postupy, ktoré používame pri overovaní záznamov.

Analýza DNS dopytov vo Wiresharku

Vo Wiresharku môžeme sledovať jednotlivé DNS požiadavky a odpovede. Na už zachytenú komunikáciu použijeme zobrazovací filter dnsa nejde o rovnaký typ filtra ako filter zadávaný pred zachytávaním. Odpovede vyberieme výrazom dns.flags.response == 1 a chybové kódy výrazom dns.flags.rcode != 0. Zachytávame iba komunikáciu v prostredí, ktoré spravujeme alebo na ktoré máme oprávnenie.

DNS záznamy vo Wiresharku s dopytmi, odpoveďami a časom

Na snímke vidíme komunikáciu medzi klientom 192.168.1.6 a zariadením 192.168.1.1. Vybraná odpoveď obsahuje odkaz na súvisiacu požiadavku a nameraný čas 0,00819 sekundy. Tento čas opisuje konkrétnu zachytenú výmenu a nevyjadruje celkovú rýchlosť internetu. Pri šifrovanom DNS obsah dopytov v bežnom zázname prevádzky bez ďalších podmienok takto nevidíme.

Najčastejšie chyby DNS a ich riešenie

Hlásenie o probléme DNS môže súvisieť s preklepom v doméne, nesprávnou konfiguráciou, nedostupným resolverom aj s overovaním DNSSEC. Najskôr zistíme, či problém postihuje jedno zariadenie, jednu doménu alebo všetky služby. Potom si zapíšeme presné chybové hlásenie a výsledok konkrétneho DNS dopytu. Až na základe toho meníme nastavenia.

Kód NOERROR má hodnotu 0 a znamená, že DNS odpoveď nehlási protokolovú chybu. NXDOMAIN má hodnotu 3 a označuje neexistujúci názov. Samotný nulový počet odpovedí preto nemožno vždy premeniť na NXDOMAIN. Rozlišujeme najmä neexistujúci názov, chýbajúci požadovaný typ a odpoveď odkazujúcu na iné servery.

DNS záznamy po zmene stále ukazujú na starý server

Ak DNS záznamy neukazujú očakávané hodnoty, skontrolujeme, či sme upravili aktívnu autoritatívnu zónu a správny názov vrátane variantu s www. Následne porovnáme odpoveď autoritatívneho servera s odpoveďou resolvera a pozrieme sa na zostávajúce TTL. Ak autoritatívny server vracia nový údaj a resolver starý, pravdepodobným vysvetlením je cache. Ak starý údaj vracia aj autoritatívny server, hľadáme chybu v publikovaní alebo vo výbere zóny.

Vo Windows môžeme zobraziť lokálnu DNS cache a následne ju podľa potreby vyprázdniť. Príkaz /flushdns odstraňuje cache klienta v danom počítači; nevyčistí cache verejných resolverov ani nezmení autoritatívne údaje. Pri jeho spustení môže byť potrebné zvýšené oprávnenie. V prehliadači či aplikácii navyše môže existovať ďalšia vlastná cache.

ipconfig /displaydns
ipconfig /flushdns

Chyba DNS konfigurácie pri inštalácii serverovej aplikácie

Priložená snímka zachytáva situáciu pri inštalácii SAP, keď aplikácia nedokázala určiť DNS doménu hostiteľa SAPECC6. Takýto problém sa týka konfigurácie konkrétneho systému a nemusí znamenať výpadok verejného DNS. Skontrolujeme úplný názov hostiteľa, DNS príponu, nakonfigurované servery a požiadavky príslušnej aplikácie. Krátky názov počítača a jeho úplný doménový názov totiž nie sú to isté.

Chyba pri inštalácii SAP s hlásením o neurčenej DNS doméne hostiteľa SAPECC6

Ukážka problému s určením DNS domény servera počas inštalácie SAP. Hlásenie sa týka konkrétnej konfigurácie hostiteľa.

V Linuxe si pred úpravou /etc/resolv.conf overíme, či ho nespravuje NetworkManager, systemd-resolved alebo iná služba. Ručne zapísaný obsah môže systém pri ďalšom pripojení prepísať. Súbor hosts môže pomôcť pri cielenom lokálnom testovaní názvu, ale nenahrádza riadne DNS pre celú sieť. Zároveň nemá zmysel nastavovať verejný resolver, ak aplikácia potrebuje interné firemné názvy.

Na správu serverových rolí nadviažeme v online kurze Microsoft Windows Server I. Začiatočník. Jeho osnova zahŕňa DNS a DHCP, konfiguráciu serverového prostredia aj sieťovú diagnostiku. Získame tak širší základ na riešenie situácií, v ktorých problém DNS ovplyvňuje ďalšiu aplikáciu.

Bezpečnosť DNS a moderné DNS záznamy

Pri DNS rozlišujeme pravosť získaných údajov a ochranu komunikácie počas prenosu. Bežné nešifrované dopyty samy osebe neposkytujú dôvernosť obsahu. Pri prevádzke vlastného DNS navyše chránime účty správcu a obmedzujeme prístup k citlivým operáciám. Zmena DNS zóny totiž môže ovplyvniť dostupnosť webu aj pošty.

DNSSEC a šifrované DNS cez DoH a DoT

DNSSEC umožňuje overovať pôvod a integritu DNS údajov pomocou digitálnych podpisov a reťazca dôvery. Sám však nešifruje dopyty a nezaručuje bezpečnosť obsahu navštívenej stránky. Pri správe domény sú dôležité záznamy DNSKEY, RRSIG a DS, ktoré poskytovatelia často obsluhujú automatizovane. Chybná väzba medzi DS a podpisovými kľúčmi môže viesť k odmietnutiu odpovede validujúcim resolverom.

DNS over HTTPS, skrátene DoH, a DNS over TLS, skrátene DoT, chránia komunikáciu medzi klientom a resolverom pomocou šifrovania. DoH využíva HTTPS a DoT štandardne TLS na porte 853. Samotné zapísanie verejnej IPv4 adresy do poľa DNS ešte nezaručuje použitie šifrovaného prenosu. Ten musí podporovať a používať aj klient a príslušná služba.

DNSSEC a šifrovaný transport môžeme používať spoločne, pretože riešia odlišné časti ochrany. Prevádzkovateľ resolvera pritom spracúva naše dopyty aj pri šifrovanom spojení k nemu. Pri výbere služby preto hodnotíme tiež jej pravidlá a firemné požiadavky. Na spravovaných zariadeniach nastavenie zosúladíme s organizáciou.

DNS záznamy CAA HTTPS a SVCB

CAA umožňuje vlastníkovi domény určiť certifikačné autority oprávnené vydávať certifikáty pre jeho doménu. Nenahrádza samotný TLS certifikát ani jeho nasadenie na serveri. Pred jeho vytvorením si overíme, ktoré autority používa náš hosting a automatická obnova certifikátov. Nesprávne obmedzenie môže komplikovať vydanie alebo obnovenie certifikátu.

Moderné DNS záznamy HTTPS a SVCB sprostredkúvajú podporovaným klientom ďalšie informácie na vytvorenie spojenia so službou. Môžu sa týkať podporovaných protokolov či ďalších parametrov pripojenia. Pri bežnom webe sa však naďalej stretávame s A, AAAA a CNAME. HTTPS a SVCB nastavujeme podľa dokumentácie služby a dostupnej podpory klientov.

DNS pritom nie je obmedzené výhradne na UDP. Klasické DNS používa port 53 cez UDP aj TCP a podpora TCP je dôležitá aj pre bežnú prevádzku. Rozšírenie EDNS umožňuje väčšie UDP správy, takže historický limit 512 bajtov nemožno považovať za všeobecný dnešný limit všetkých DNS odpovedí. Pri nastavovaní firewallu preto nezablokujeme TCP len na základe predstavy, že DNS ho nepotrebuje.

Online kurzy VITA pre DNS a správu počítačových sietí

DNS najlepšie pochopíme pri práci s konkrétnou zónou, pri overovaní dopytov a pri riešení sieťových problémov. Vhodný kurz si vyberieme podľa toho, či potrebujeme doplniť základy, precvičiť diagnostiku alebo spravovať celú infraštruktúru. Nasledujúce kurzy obsahovo nadväzujú na témy článku. Podrobnosti a aktuálnu osnovu nájdeme na ich stránkach.

Záver a odporúčania k téme DNS

DNS prepája doménové názvy s informáciami, ktoré aplikácie potrebujú na nájdenie webu, pošty a ďalších služieb. Správne DNS záznamy preto patria k základom funkčnej internetovej prezentácie aj firemnej infraštruktúry. Pri nastavovaní vychádzame z požiadaviek poskytovateľa, rozlišujeme jednotlivé typy a pred zmenou si overíme aktívnu zónu.

V praxi nám pomôže jednoduchý postup: uložíme pôvodnú konfiguráciu, pripravíme požadované údaje, zohľadníme TTL a overíme odpoveď vhodným nástrojom. Ak potrebujeme rozšíriť tieto zručnosti na samostatnú správu systémov, môžeme pokračovať v online kurze Administrátor a Správca IT. DNS tak zasadíme do širšieho kontextu správy operačných systémov, sietí a služieb.

Použité zdroje, literatúra a technická dokumentácia k DNS

Technické zdroje a stránky odporúčaných kurzov sme skontrolovali 17. októbra 2026. Ukážkové konfigurácie slúžia na vysvetlenie a konkrétne hodnoty pre vlastnú doménu preberáme od poskytovateľa služby.

1. RFC 1034 – Domain Names Concepts and Facilities.
2. RFC 9499 – DNS Terminology.
3. RFC 1035 – Domain Names Implementation and Specification.
4. Cloudflare – DNS record types.
5. RFC 3596 – DNS Extensions to Support IP Version 6.
6. RFC 2181 – Clarifications to the DNS Specification a Cloudflare – CNAME record.
7. RFC 7208 – Sender Policy Framework.
8. RFC 6376 – DomainKeys Identified Mail a Microsoft Learn – DKIM vo vlastnej doméne.
9. RFC 9989 – DMARC a RFC 9990 – DMARC Aggregate Reporting.
10. RFC 2782 – DNS SRV.
11. RFC 2606 – Reserved Top Level DNS Names, RFC 5737 – IPv4 Address Blocks Reserved for Documentation a RFC 3849 – IPv6 Address Prefix Reserved for Documentation.
12. Amazon Route 53 – Best practices for DNS.
13. RFC 2308 – Negative Caching of DNS Queries.
14. RFC 8767 – Serving Stale Data to Improve DNS Resiliency.
15. RFC 4033 – DNS Security Introduction and Requirements.
16. Google Public DNS – Get Started.
17. Cloudflare – IP addresses for 1.1.1.1 and Families.
18. AdGuard – Verejné DNS.
19. OpenDNS – Setup Guide a OpenDNS – oficiálna stránka.
20. Microsoft Learn – nslookup.
21. Microsoft Learn – Resolve-DnsName.
22. ISC BIND 9 – manuál nástroja dig.
23. RFC 8482 – Providing Minimal Sized Responses to DNS Queries That Have QTYPE=ANY.
24. Wireshark – Display Filter Reference Domain Name System.
25. Microsoft Learn – ipconfig.
26. RFC 8484 – DNS over HTTPS a RFC 7858 – DNS over TLS.
27. RFC 8659 – DNS Certification Authority Authorization.
28. RFC 9460 – SVCB and HTTPS Resource Records.
29. RFC 7766 – DNS Transport over TCP a RFC 6891 – Extension Mechanisms for DNS.
30. systemd – Writing Network Configuration Managers a NetworkManager – konfiguračný manuál.