DNS a SSL: DNS záznamy, DNSSEC, TLS, certifikáty a kompletný checklist

Príklady:

• platný certifikát nepomôže, ak záznam A smeruje na starý server,
• správny záznam A nestačí, ak AAAA smeruje prevádzku IPv6 na nefunkčný stroj,
• automatické obnovenie certifikátu nezafunguje, ak záznam _acme-challenge nie je možné vytvoriť alebo je port 80 zablokovaný,
• DNSSEC môže zvýšiť dôveryhodnosť odpovedí DNS, ale chybný záznam DS môže spôsobiť SERVFAIL pre celú doménu,
• krátky TTL neopraví nesprávnu delegáciu menných serverov,
• zástupný (wildcard) certifikát nezahŕňa hlavnú doménu ani viacúrovňové subdomény, ak neboli zadané samostatne.

V roku 2026 by mala byť správa certifikátov plne automatická. Od 15. marca 2026 môžu mať verejné certifikáty TLS typu Subscriber Certificate maximálne 200 dní platnosti. Limit klesne na 100 dní v marci 2027 a na 47 dní v marci 2029. Let's Encrypt naďalej štandardne vydáva 90-dňové certifikáty, ale poskytuje aj kratšie profily a od mája 2026 profil tlsserver vydáva 45-dňové certifikáty pre používateľov, ktorí si ho vedome zvolia.

TL;DR: udržiavajte aspoň dva nezávisle dostupné autoritatívne servery DNS, kontrolujte záznamy A a AAAA, nasadzujte DNSSEC len s bezpečným procesom správy DS, obmedzte certifikačné autority pomocou CAA, používajte TLS 1.3 s TLS 1.2 ako kompatibilným minimom, automatizujte vydávanie a obnovovanie certifikátov cez ACME a monitorujte dátum platnosti, reťazec certifikátov, SNI, HSTS a chyby validácie z viacerých lokalít.

Informácie a požiadavky boli overené 23. júla 2026.

DNS, SSL a TLS v jednej tabuľke

Vrstva	Zodpovedá za	Najdôležitejšie prvky	Typické poruchy
Registrátor domény	vlastníctvo domény a delegáciu	menné servery, blokovanie prenosu, DS	prevzatie účtu, nesprávna delegácia, starý DS
Autoritatívny DNS	skutočné záznamy zóny	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	nesprávna adresa, chýbajúci záznam, split-brain, nesprávny podpis
Rekurzívny resolver	nájdenie a cache odpovede	TTL, cache, validácia DNSSEC, DoH/DoT	staré dáta v cache, chybná validácia
TCP/QUIC a TLS	bezpečný kanál k serveru	TLS 1.2/1.3, SNI, ALPN, certifikát	slabý protokol, chybný reťazec (chain), nezhoda názvu hostiteľa
Certifikát	potvrdenie identity názvu	SAN, issuer, platnosť, kľúč, podpis	vypršanie platnosti, chýbajúci názov, nesprávny intermediate
HTTP	presmerovanie a politika HTTPS	301/308, HSTS, bezpečnostné hlavičky	redirect loop, mixed content, chýbajúci HSTS

Ako naozaj funguje preklad domény?

DNS je hierarchický a distribuovaný systém názvov. Resolver nedostáva celú odpoveď z jedného centrálneho servera. Zjednodušene:

1. prehliadač a systém skontrolujú lokálnu cache,
2. rekurzívny resolver sa pýta root serverov,
3. root ukáže na servery príslušnej domény najvyššej úrovne, napríklad .pl,
4. server TLD ukáže na autoritatívne servery domény,
5. autoritatívny server vráti záznam, napríklad A, AAAA alebo CNAME,
6. odpoveď sa uchová v súlade s TTL.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

DNS nezaručuje, že uvedený server je funkčný, ani že odpoveď HTTP bude správna. Vracia dáta zapísané v zóne. Monitoring DNS by preto mal byť prepojený s testami TCP, TLS a HTTP.

1. Najdôležitejšie záznamy DNS

A a AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A ukazuje na adresu IPv4,
• AAAA ukazuje na adresu IPv6.

Záznam AAAA nie je nezáväzný doplnok. Ak existuje, klienti podporujúci IPv6 sa môžu pokúsiť pripojiť práve k nemu. Nezverejňujte AAAA, kým firewall, routing, webový server, certifikát a ACME challenge nefungujú správne cez IPv6.

Let's Encrypt pri validácii http-01 uprednostňuje IPv6, keď má doména záznam AAAA. Chybné IPv6 môže spôsobiť neúspešné vydanie alebo obnovenie certifikátu aj vtedy, keď je IPv4 správne.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

CNAME vytvára alias na iný názov DNS. Názov s CNAME by nemal mať súčasne iné bežné dáta, ako A, AAAA či MX, pretože CNAME označuje, že vlastné dáta sa nachádzajú pod iným názvom.

Na apexe zóny, teda example.com, klasický CNAME koliduje s povinnými záznamami SOA a NS. Poskytovatelia to obchádzajú vlastnými mechanizmami ALIAS, ANAME alebo flattening, ale nie sú to bežné záznamy CNAME prenášané v zóne.

NS a SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS určuje autoritatívne menné servery. Delegácia u registrátora a záznamy NS vnútri zóny by mali byť konzistentné.

SOA obsahuje administratívne dáta zóny, okrem iného sériové číslo a parametre používané sekundárnymi servermi. Pri ručnej správe zóny musí sériové číslo po zmenách rásť.

Dobrá prevádzková prax je aspoň dva autoritatívne servery fungujúce v oddelených sieťach alebo lokalitách. ICANN odporúča viacero oddelených autoritatívnych serverov, najlepšie geograficky a topologicky oddelených.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

Nižšie číslo znamená vyššiu prioritu. Cieľ záznamu MX by mal byť názov hosta, nie adresa IP ani CNAME.

Zmena webhostingu by nemala automaticky meniť poštu. Pred migráciou DNS si zaznamenajte záznamy MX, SPF, DKIM a DMARC.

TXT

TXT je textový kontajner používaný okrem iného pre:

• SPF,
• DKIM,
• DMARC,
• validáciu vlastníctva domény,
• ACME dns-01,
• integrácie SaaS.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Viacero záznamov TXT pod jedným názvom môže byť správnych, ale niekoľko konkurenčných záznamov SPF začínajúcich sa na v=spf1 je chybou návrhu.

CAA

CAA umožňuje vlastníkovi domény určiť, ktoré certifikačné autority môžu vydávať certifikáty pre doménu.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue sa týka bežných certifikátov,
• issuewild sa týka zástupných (wildcard) certifikátov,
• iodef určuje kanál na hlásenie porušení politiky.

CAA nenahrádza kontrolu účtu u registrátora, DNSSEC ani monitoring Certificate Transparency. Je dodatočným obmedzením pre verejné CA. Absencia CAA zvyčajne znamená, že ľubovoľná verejne dôveryhodná CA môže vydať certifikát po správnej validácii domény.

PTR

PTR realizuje reverzný DNS, teda mapovanie adresy IP na názov. Záznam nastavuje vlastník rozsahu IP, zvyčajne poskytovateľ VPS alebo hostingu. Je obzvlášť dôležitý pre poštové servery.

192.0.2.10 → mail.example.com

Pri pošte by mal názov PTR zvyčajne viesť späť cez A alebo AAAA na tú istú adresu.

HTTPS a SVCB

Záznamy HTTPS a SVCB môžu klientovi odovzdať informácie o spôsobe pripojenia k službe, alternatívnych endpointoch, podporovaných protokoloch a parametroch potrebných pred nadviazaním spojenia.

Koncepčný príklad:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

Nezadávajte ipv4hint alebo ipv6hint ako náhradu správnych adresových záznamov bez pochopenia správania klientov. HTTPS RR je mechanizmus optimalizácie a signalizácie, nie oprava chybného DNS alebo TLS.

2. TTL a „propagácia DNS“

TTL určuje, ako dlho môže resolver uchovávať odpoveď v cache. Neexistuje jeden globálny časovač propagácie. Po zmene:

• časť resolverov má ešte starú odpoveď,
• časť sa spýta servera okamžite,
• negatívne odpovede, ako NXDOMAIN, sa tiež môžu ukladať do cache,
• lokálny systém, prehliadač, operátor a aplikácia môžu mať samostatné cache.

Rozumné hodnoty TTL

Situácia	Typická hodnota
stabilný produkčný záznam	3600-86400 s
príprava migrácie	300-600 s
záznam ACME DNS-01	30-300 s, ak to poskytovateľ umožňuje
záznam NS alebo SOA	zvyčajne dlhší
núdzové prepnutie	nízky TTL pomôže až po vypršaní predchádzajúcej cache

Pred migráciou znížte TTL aspoň o jeden starý interval TTL vopred. Zníženie TTL päť minút pred zmenou neodstráni odpovede, ktoré si resolver už uložil na 24 hodín.

Po dokončení migrácie zvýšte TTL, aby ste obmedzili počet dopytov a závislosť od dočasných problémov autoritatívneho DNS.

3. DNSSEC: integrita odpovede, nie šifrovanie

DNSSEC pridáva overenie pôvodu dát DNS a ochranu integrity pomocou digitálnych podpisov. Nešifruje dopyty ani neskrýva názvy domén pred poskytovateľom siete alebo resolverom.

Reťazec dôvery využíva okrem iného:

• DNSKEY - verejné kľúče zóny,
• RRSIG - podpisy sád záznamov,
• DS - odtlačok kľúča zapísaný v nadradenej zóne,
• NSEC alebo NSEC3 - kryptografické potvrdenie neexistencie názvu alebo typu.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

RFC 9364 označuje použitie DNSSEC na overovanie pôvodu dát DNS za aktuálnu osvedčenú prax.

Najväčšie riziko DNSSEC

Najčastejším problémom nie je absencia DNSSEC, ale chybný reťazec DNSSEC. Ak u registrátora zostane záznam DS ukazujúci na starý kľúč a nový operátor DNS podpisuje zónu iným kľúčom, validujúce resolvery vrátia SERVFAIL.

Bezpečná migrácia DNSSEC vyžaduje:

1. overenie, kto podpisuje zónu,
2. určenie metódy prenosu alebo rolloveru kľúčov,
3. publikáciu správneho DS v nadradenej doméne,
4. počkanie na TTL záznamov DNSKEY a DS,
5. až potom odstránenie starých kľúčov alebo starej zóny,
6. testovanie prostredníctvom validujúcich resolverov.

Nezapínajte DNSSEC, ak poskytovateľ nezabezpečuje jasný proces správy DS a rotácie kľúčov.

4. DNSSEC verzus DoH a DoT

Tieto mechanizmy riešia rôzne problémy:

Mechanizmus	Chráni	Nezabezpečuje
DNSSEC	autentickosť a integritu dát DNS	dôvernosť dopytu
DNS over TLS	šifrovanie medzi klientom a resolverom cez TLS, zvyčajne port 853	autentickosť dát bez validácie DNSSEC
DNS over HTTPS	šifrovanie DNS v HTTPS	autentickosť dát bez DNSSEC
bežný DNS	základné rozlišovanie názvov	dôvernosť a kryptografickú integritu

DNS over TLS opisuje RFC 7858 a DNS over HTTPS RFC 8484. Šifrovaný transport chráni dopyt pred jednoduchým odpočúvaním na úseku klient-resolver, ale operátor resolvera stále vidí dopyty a ďalšie rozlišovanie závisí od jeho politiky.

5. SSL a TLS: správna terminológia

„Certifikát SSL“ je stále bežné marketingové označenie, ale súčasné stránky používajú TLS. SSL 2.0 a SSL 3.0 sú zastarané a TLS 1.0 a 1.1 boli formálne stiahnuté organizáciou IETF.

V roku 2026:

• TLS 1.3 by mal byť uprednostňovaný,
• TLS 1.2 zostáva kompatibilným minimom pre staršie, stále podporované klienty,
• TLS 1.0, TLS 1.1, SSLv2 a SSLv3 by mali byť vypnuté,
• konfigurácia TLS 1.2 by mala používať moderné sady s AEAD a forward secrecy,
• server by nemal ponúkať zastarané algoritmy a výmeny kľúčov.

RFC 9325 obsahuje aktuálne odporúčania na bezpečné používanie TLS a nahradilo skoršie BCP 195.

6. Čo prehliadač kontroluje v certifikáte?

Počas spojenia TLS klient kontroluje okrem iného:

1. či je certifikát v období platnosti,
2. či sa názov hosta nachádza v subjectAltName,
3. či podpis vedie cez správny medziľahlý reťazec k dôveryhodnej root CA,
4. či sa certifikát nepoužíva na nesprávny účel,
5. či sú parametre spojenia akceptovateľné,
6. či politiky prehliadača certifikát neodmietajú.

Identita servera sa v súčasnosti overuje na základe SAN, nie poľa Common Name ako primárneho zdroja názvu.

SAN

Jeden certifikát môže zahŕňať viacero názvov:

example.com
www.example.com
api.example.com

Každý názov sa musí nachádzať v SAN.

Wildcard

*.example.com

zahŕňa:

www.example.com
api.example.com
shop.example.com

ale automaticky nezahŕňa:

example.com
www.eu.example.com

Hlavnú doménu treba pridať samostatne a wildcard funguje len pre jednu úroveň menovky.

SNI

Server Name Indication umožňuje klientovi odovzdať názov hosta počas handshake, vďaka čomu môže jedna adresa IP obsluhovať viacero certifikátov. Chybná konfigurácia SNI často spôsobí zobrazenie certifikátu inej domény.

Reťazec certifikátov

Server by mal posielať certifikát domény a potrebné medziľahlé certifikáty, ale zvyčajne nie root. Chýbajúci intermediate môže fungovať na jednom zariadení, ktoré si certifikát predtým uložilo, a zlyhávať na inom.

7. Platnosť certifikátov v roku 2026

CA/Browser Forum prijalo harmonogram skracovania verejných certifikátov TLS:

Dátum vydania	Maximálna platnosť
pred 15. marcom 2026	398 dní
15. marca 2026 - 14. marca 2027	200 dní
15. marca 2027 - 14. marca 2029	100 dní
od 15. marca 2029	47 dní

To neznamená, že každá CA vydáva certifikát na maximálne obdobie. Let's Encrypt štandardne naďalej vydáva 90-dňové certifikáty, má voliteľné šesťdňové certifikáty a profil tlsserver so 45-dňovými certifikátmi dostupný pre skoré nasadenia od mája 2026.

Záver je jednoduchý: ručné obnovovanie certifikátov prestáva byť rozumnou prevádzkovou praxou.

8. ACME a automatizácia certifikátov

ACME je štandardný protokol automatizujúci registráciu účtu, validáciu kontroly domény, vydanie, obnovenie a zrušenie certifikátu.

HTTP-01

CA stiahne súbor:

http://example.com/.well-known/acme-challenge/TOKEN

Výhody:

• jednoduchá konfigurácia pre jeden webový server,
• jednoduchá automatizácia,
• nevyžaduje API DNS.

Obmedzenia:

• vyžaduje dostupný port 80,
• nevydáva wildcard,
• challenge sa musí dostať na správny server,
• chybné AAAA, proxy, redirect alebo load balancer môžu prerušiť validáciu.

Let's Encrypt odporúča ponechať port 80 pre verejné webové servery a presmerovať bežnú prevádzku na HTTPS.

DNS-01

Klient publikuje TXT:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Výhody:

• podporuje wildcard,
• funguje bez verejného servera HTTP,
• hodí sa na centrálnu správu certifikátov.

Riziká:

• vyžaduje bezpečný prístup k API DNS,
• propagácia a cache môžu oneskoriť validáciu,
• token API s právom úpravy celej zóny zvyšuje dôsledky úniku,
• staré TXT môžu sťažiť diagnostiku.

Let's Encrypt výslovne odporúča používať DNS-01 s poskytovateľom ponúkajúcim API, pretože automatizácia obnovovaní je kľúčová. Prideľte tokenu čo najmenší možný rozsah: najlepšie len k záznamom _acme-challenge, nie k správe domény, účtu či všetkých zón.

Wildcard v Let's Encrypt vyžaduje DNS-01.

TLS-ALPN-01

Validácia prebieha cez špeciálne spojenie TLS na porte 443 a protokol ALPN. Je užitočná pre špecializované proxy a systémy správy certifikátov, ale zriedkavejšie sa konfiguruje ručne.

Renewal Information

Moderný klient ACME by mal podporovať ACME Renewal Information, teda ARI. Namiesto obnovovania každého certifikátu podľa jedného pevného prahu môže klient dostať od CA odporúčané okno na obnovenie. Let's Encrypt odporúča kontrolovať informácie ARI aspoň dvakrát denne.

9. CAA a ACME: praktický príklad

Pre certifikáty Let's Encrypt:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Ak nechcete wildcard:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Pred vydaním má verejná CA povinnosť skontrolovať CAA. Od 15. marca 2026 požiadavky CA/Browser Forum nariaďujú aj validáciu DNSSEC pre dopyty súvisiace s CAA vykonávané z hlavnej sieťovej perspektívy a chybu validácie DNSSEC nemožno považovať za súhlas s vydaním.

Po zmene CA nezabudnite aktualizovať CAA pred spustením nového procesu vydávania.

10. HTTPS, presmerovania a HSTS

Minimálna schéma:

http://example.com
        ↓ 301 lub 308
https://example.com

Po potvrdení plnej funkčnosti HTTPS možno pridať:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS informuje prehliadač, aby v budúcnosti používal len HTTPS a neumožnil obísť časť chýb certifikátu.

Nezačínajte dlhým max-age, includeSubDomains a preload, ak:

• existujú subdomény bez HTTPS,
• časť infraštruktúry spravuje partner,
• nebol otestovaný proces obnovovaní,
• chýba monitoring certifikátov,
• nie je jasné, či stará služba bude ešte potrebná.

HSTS preload umiestňuje pravidlo do distribúcie prehliadačov. Odstránenie záznamu môže trvať týždne.

11. Najčastejšie chyby DNS

Chybný záznam AAAA

IPv4 funguje, ale časť klientov vyberá nefunkčné IPv6. Príznaky sú náhodné v závislosti od siete používateľa.

CNAME a iné záznamy pod tým istým názvom

Alias koliduje s adresovými záznamami, MX alebo TXT. Panel poskytovateľa môže zmenu blokovať alebo vytvárať nejednoznačnú zónu.

Nekonzistentná delegácia NS

Registrátor ukazuje na iné servery ako zóna alebo jeden zo serverov má staršiu verziu dát.

Starý DS po zmene DNS

Doména vracia SERVFAIL len u resolverov validujúcich DNSSEC.

Trvalo príliš nízky TTL

Zvyšuje počet dopytov a citlivosť na dočasnú nedostupnosť DNS, automaticky nezabezpečuje rýchly failover.

Príliš vysoký TTL pred migráciou

Staré adresy zostávajú v cache mnoho hodín.

Ponechané záznamy TXT

Staré overovacie a ACME tokeny sťažujú audit a zvyšujú prevádzkový chaos.

Nekonzistentnosť www a apex

example.com a www.example.com smerujú do rôznych systémov, majú iné certifikáty alebo vytvárajú slučku presmerovaní.

12. Najčastejšie chyby TLS a certifikátov

Certifikát vypršal

Najčastejšie príčinou nie je absencia automatizácie, ale automatizmus, ktorý prestal fungovať bez upozornenia.

Certifikát nezahŕňa hosta

Certifikát pre example.com automaticky nezabezpečuje www.example.com.

Neúplný reťazec (chain)

Chýba medziľahlý certifikát. Problém sa môže vyskytovať len na nových zariadeniach alebo vybraných klientoch.

Nesprávny certifikát cez SNI

Reverse proxy má chybný default virtual host alebo nová doména nebola pridaná do mapovania.

Staré protokoly a cipher suites

Server stále ponúka TLS 1.0/1.1 alebo staré sady, pretože konfigurácia pochádza spred mnohých rokov.

Nezhoda na viacerých vrstvách

CDN má správny verejný certifikát, ale spojenie CDN→origin je nešifrované alebo neoveruje názov hosta.

Obnovenie vykonané, ale proces znovu nenačítal server

Nový súbor certifikátu existuje na disku, ale Nginx, Apache, HAProxy alebo aplikácia stále používa starý certifikát z pamäte.

13. Diagnostika krok za krokom

Záznamy DNS

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delegácia

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

SERVFAIL pri fungovaní bez validácie je silným signálom problému s DNSSEC.

Certifikát a SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Dátumy certifikátu

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP a HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Skontrolujte redirect, Strict-Transport-Security, hostname, konečný stav a neprítomnosť slučky.

Môžete použiť aj bezplatný Inšpektor DNS a SSL POLPROG, ktorý zobrazuje záznamy DNS a informácie o certifikáte TLS. Doplňte test cez Inšpektor bezpečnostných hlavičiek, Kondíciu webu a článok Základy bezpečnosti webových aplikácií.

14. Produkčný monitoring

Nemonitorujte len domovskú stránku z jednej lokality. Minimálna sada:

• odpoveď autoritatívneho DNS,
• záznamy A, AAAA, CNAME, NS, MX a CAA,
• validácia DNSSEC,
• dostupnosť cez IPv4 a IPv6,
• dátumy certifikátu,
• zhoda SAN,
• úplný reťazec (chain),
• TLS 1.2 a TLS 1.3,
• konečný redirect HTTP→HTTPS,
• HSTS,
• odpoveď originu za CDN,
• fungovanie ACME a posledné úspešné obnovenie.

Prahy upozornení certifikátu

Pre plne automatický systém:

Zostávajúci čas	Reakcia
30 dní	varovanie alebo kontrola trendu
14 dní	alert vyžadujúci analýzu
7 dní	prevádzkový incident
3 dni	kritický alert a eskalácia
menej ako 24 h	hroziaca porucha

Prahy treba prispôsobiť dĺžke platnosti certifikátu. Pri šesťdňových alebo 45-dňových certifikátoch musí monitoring reagovať oveľa skôr, úmerne k cyklu obnovovania.

15. Bezpečnostný kontrolný zoznam DNS a TLS

Registrátor a DNS

• Účet registrátora má MFA.
• Prenos domény je zablokovaný.
• Kontaktné údaje a proces obnovy sú aktuálne.
• Používajú sa aspoň dva autoritatívne servery DNS.
• Servery fungujú v oddelených sieťach alebo lokalitách.
• Delegácia NS u registrátora a v zóne je konzistentná.
• Záznamy A a AAAA ukazujú na aktívnu infraštruktúru.
• IPv6 je skutočne monitorované.
• Záznamy MX, SPF, DKIM a DMARC sú zachované pri migráciách.
• CAA povoľuje len používané CA.
• Nie sú zbytočné záznamy TXT a overovacie tokeny.
• TTL bol znížený s predstihom pred migráciou.
• TTL bol zvýšený po stabilizácii.
• Prístup k API DNS má minimálne oprávnenia.

DNSSEC

• Poskytovateľ podporuje DNSSEC a rotáciu kľúčov.
• Záznam DS u registrátora zodpovedá aktívnemu DNSKEY.
• Zmeny operátora DNS majú plán migrácie DNSSEC.
• Staré DS a kľúče sa odstraňujú až po vypršaní cache.
• Doména je testovaná validujúcim resolverom.
• Alert deteguje SERVFAIL a vypršanie podpisov.

Certifikáty

• Certifikáty sú vydávané a obnovované cez ACME.
• Obnovenie bolo otestované, nie len prvé vydanie.
• Proces znovu načíta server po inštalácii nového certifikátu.
• Všetky hosty sa nachádzajú v SAN.
• Wildcard sa používa vedome.
• Reťazec (chain) obsahuje správne intermediates.
• Súkromný kľúč neopúšťa príslušný systém.
• Oprávnenia ku kľúču sú obmedzené.
• Alerty fungujú nezávisle od samotného klienta ACME.
• DNS-01 používa obmedzený token API.
• HTTP-01 funguje cez IPv4 a IPv6.
• Staging CA sa používa na testy automatizácie.

TLS a HTTPS

• TLS 1.3 je zapnutý.
• TLS 1.2 zostáva len pre potrebnú kompatibilitu.
• TLS 1.0, TLS 1.1 a SSL sú vypnuté.
• Server neponúka zastarané cipher suites.
• SNI vracia správny certifikát pre každý host.
• HTTP presmerúva priamo na HTTPS.
• Nie je mixed content.
• HSTS bol nasadený po etapách.
• includeSubDomains je bezpečné pre celú doménu.
• Preload bol analyzovaný pred nahlásením.
• CDN→origin tiež používa správne overený TLS.

Verdikt

Dobrá konfigurácia DNS a TLS v roku 2026 sa opiera o štyri zásady:

1. DNS musí byť konzistentný a prevádzkovo odolný.
2. DNSSEC by mal byť nasadený len so správnou správou DS a kľúčov.
3. Certifikáty musia byť spravované automaticky cez ACME.
4. TLS 1.3, správny reťazec (chain), monitoring a HSTS sú súčasťou jedného procesu, nie oddelenými úlohami.

Najväčším rizikom nie je absencia „zeleného zámku“ v deň spustenia. Je ním tichá porucha o niekoľko mesiacov neskôr: vypršaný certifikát, neaktuálny záznam AAAA, ponechaný DS, token DNS s nadmernými oprávneniami alebo automat obnovovania, ktorý nikto nemonitoroval.