DNS i SSL: rekordy DNS, DNSSEC, TLS, certyfikaty i kompletna checklista

Przykłady:

• prawidłowy certyfikat nie pomoże, jeśli rekord A prowadzi do starego serwera,
• poprawny rekord A nie wystarczy, jeśli AAAA kieruje ruch IPv6 do niedziałającej maszyny,
• automatyczne odnowienie certyfikatu nie zadziała, jeśli rekord _acme-challenge nie może zostać utworzony albo port 80 jest zablokowany,
• DNSSEC może zwiększyć zaufanie do odpowiedzi DNS, ale błędny rekord DS może spowodować SERVFAIL dla całej domeny,
• krótki TTL nie naprawi złej delegacji serwerów nazw,
• certyfikat wildcard nie obejmuje domeny głównej ani wielopoziomowych subdomen, jeśli nie zostały wpisane osobno.

W 2026 roku obsługa certyfikatów powinna być w pełni automatyczna. Od 15 marca 2026 roku publiczne certyfikaty TLS typu Subscriber Certificate mogą mieć maksymalnie 200 dni ważności. Limit spadnie do 100 dni w marcu 2027 roku i do 47 dni w marcu 2029 roku. Let’s Encrypt nadal wydaje domyślnie certyfikaty 90-dniowe, ale udostępnia również krótsze profile, a od maja 2026 roku profil tlsserver wydaje certyfikaty 45-dniowe dla użytkowników, którzy świadomie go wybiorą.

TL;DR: utrzymuj co najmniej dwa niezależnie dostępne autorytatywne serwery DNS, kontroluj rekordy A i AAAA, wdroż DNSSEC tylko z bezpiecznym procesem obsługi DS, ogranicz urzędy certyfikacji przez CAA, używaj TLS 1.3 z TLS 1.2 jako kompatybilnym minimum, automatyzuj wydawanie i odnawianie certyfikatów przez ACME oraz monitoruj datę ważności, łańcuch certyfikatów, SNI, HSTS i błędy walidacji z wielu lokalizacji.

Informacje i wymagania zostały zweryfikowane 23 lipca 2026 roku.

DNS, SSL i TLS w jednej tabeli

Warstwa	Odpowiada za	Najważniejsze elementy	Typowe awarie
Rejestrator domeny	własność domeny i delegację	serwery nazw, blokada transferu, DS	przejęcie konta, zła delegacja, stary DS
Autorytatywny DNS	prawdziwe rekordy strefy	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	zły adres, brak rekordu, split-brain, zła sygnatura
Rekurencyjny resolver	znalezienie i cache odpowiedzi	TTL, cache, walidacja DNSSEC, DoH/DoT	stare dane w cache, błędna walidacja
TCP/QUIC i TLS	bezpieczny kanał do serwera	TLS 1.2/1.3, SNI, ALPN, certyfikat	słaby protokół, błędny chain, hostname mismatch
Certyfikat	potwierdzenie tożsamości nazwy	SAN, issuer, ważność, klucz, podpis	wygaśnięcie, brak nazwy, zły intermediate
HTTP	przekierowanie i polityka HTTPS	301/308, HSTS, nagłówki bezpieczeństwa	redirect loop, mixed content, brak HSTS

Jak naprawdę działa rozwiązywanie domeny?

DNS jest hierarchicznym i rozproszonym systemem nazw. Resolver nie otrzymuje całej odpowiedzi z jednego centralnego serwera. W uproszczeniu:

1. przeglądarka i system sprawdzają lokalne cache,
2. rekurencyjny resolver pyta serwery root,
3. root wskazuje serwery odpowiedniej domeny najwyższego poziomu, na przykład .pl,
4. serwer TLD wskazuje autorytatywne serwery domeny,
5. autorytatywny serwer zwraca rekord, na przykład A, AAAA albo CNAME,
6. odpowiedź jest przechowywana zgodnie z TTL.

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

DNS nie gwarantuje, że wskazany serwer jest zdrowy ani że odpowiedź HTTP będzie prawidłowa. Zwraca dane zapisane w strefie. Monitoring DNS powinien więc być połączony z testami TCP, TLS i HTTP.

1. Najważniejsze rekordy DNS

A i AAAA

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

• A wskazuje adres IPv4,
• AAAA wskazuje adres IPv6.

Rekord AAAA nie jest dodatkiem bez konsekwencji. Jeżeli istnieje, klienci obsługujący IPv6 mogą próbować połączyć się właśnie z nim. Nie publikuj AAAA, dopóki firewall, routing, serwer WWW, certyfikat i challenge ACME nie działają prawidłowo po IPv6.

Let’s Encrypt przy walidacji http-01 preferuje IPv6, gdy domena ma rekord AAAA. Błędne IPv6 może spowodować nieudane wydanie lub odnowienie certyfikatu nawet wtedy, gdy IPv4 jest poprawny.

CNAME

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

CNAME tworzy alias do innej nazwy DNS. Nazwa z CNAME nie powinna mieć jednocześnie innych zwykłych danych, takich jak A, AAAA czy MX, ponieważ CNAME wskazuje, że właściwe dane znajdują się pod inną nazwą.

Na apexie strefy, czyli example.com, klasyczny CNAME koliduje z obowiązkowymi rekordami SOA i NS. Dostawcy obchodzą to przez własne mechanizmy ALIAS, ANAME albo flattening, ale nie są to zwykłe rekordy CNAME przesyłane w strefie.

NS i SOA

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

NS określa autorytatywne serwery nazw. Delegacja u rejestratora i rekordy NS wewnątrz strefy powinny być spójne.

SOA zawiera dane administracyjne strefy, między innymi numer seryjny i parametry używane przez serwery wtórne. Przy ręcznym utrzymaniu strefy numer seryjny musi rosnąć po zmianach.

Dobra praktyka operacyjna to co najmniej dwa serwery autorytatywne działające w odrębnych sieciach lub lokalizacjach. ICANN zaleca wielokrotne, odrębne serwery autorytatywne, najlepiej rozdzielone geograficznie i topologicznie.

MX

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

Niższa liczba oznacza wyższy priorytet. Cel rekordu MX powinien być nazwą hosta, nie adresem IP ani CNAME.

Zmiana hostingu WWW nie powinna automatycznie zmieniać poczty. Przed migracją DNS zapisz rekordy MX, SPF, DKIM i DMARC.

TXT

TXT jest kontenerem tekstowym używanym między innymi przez:

• SPF,
• DKIM,
• DMARC,
• walidację własności domeny,
• ACME dns-01,
• integracje SaaS.

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

Wiele rekordów TXT pod jedną nazwą może być poprawnych, ale kilka konkurencyjnych rekordów SPF zaczynających się od v=spf1 jest błędem projektowym.

CAA

CAA pozwala właścicielowi domeny wskazać, które urzędy certyfikacji mogą wydawać certyfikaty dla domeny.

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 dotyczy zwykłych certyfikatów,
• issuewild dotyczy wildcard,
• iodef wskazuje kanał raportowania naruszeń polityki.

CAA nie zastępuje kontroli konta u rejestratora, DNSSEC ani monitoringu Certificate Transparency. Jest dodatkowym ograniczeniem dla publicznych CA. Brak CAA oznacza zazwyczaj, że każdy publicznie zaufany CA może wydać certyfikat po poprawnej walidacji domeny.

PTR

PTR realizuje reverse DNS, czyli mapowanie adresu IP na nazwę. Rekord ustawia właściciel zakresu IP, zwykle dostawca VPS lub hostingu. Jest szczególnie istotny dla serwerów pocztowych.

192.0.2.10 → mail.example.com

Dla poczty nazwa PTR powinna zazwyczaj prowadzić z powrotem przez A lub AAAA do tego samego adresu.

HTTPS i SVCB

Rekordy HTTPS i SVCB mogą przekazywać klientowi informacje o sposobie połączenia z usługą, alternatywnych endpointach, obsługiwanych protokołach oraz parametrach potrzebnych przed nawiązaniem połączenia.

Przykład koncepcyjny:

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

Nie należy wpisywać ipv4hint lub ipv6hint jako zamiennika poprawnych rekordów adresowych bez zrozumienia zachowania klientów. HTTPS RR jest mechanizmem optymalizacji i sygnalizacji, a nie naprawą błędnego DNS lub TLS.

2. TTL i „propagacja DNS”

TTL określa, jak długo resolver może przechowywać odpowiedź w cache. Nie istnieje jeden globalny zegar propagacji. Po zmianie:

• część resolverów ma jeszcze starą odpowiedź,
• część odpyta serwer natychmiast,
• negatywne odpowiedzi, takie jak NXDOMAIN, również mogą być cache’owane,
• lokalny system, przeglądarka, operator i aplikacja mogą mieć osobne cache.

Rozsądne wartości TTL

Sytuacja	Typowa wartość
stabilny rekord produkcyjny	3600-86400 s
przygotowanie migracji	300-600 s
rekord ACME DNS-01	30-300 s, jeśli dostawca pozwala
rekord NS lub SOA	zwykle dłuższy
awaryjne przełączenie	niski TTL pomaga dopiero po wygaśnięciu wcześniejszego cache

Przed migracją zmniejsz TTL co najmniej o jeden stary okres TTL wcześniej. Obniżenie TTL pięć minut przed zmianą nie usuwa odpowiedzi, które resolver już zapisał na 24 godziny.

Po zakończeniu migracji podnieś TTL, aby ograniczyć liczbę zapytań i zależność od chwilowych problemów autorytatywnego DNS.

3. DNSSEC: integralność odpowiedzi, nie szyfrowanie

DNSSEC dodaje uwierzytelnienie pochodzenia danych DNS i ochronę integralności za pomocą podpisów cyfrowych. Nie szyfruje zapytań ani nie ukrywa nazw domen przed dostawcą sieci lub resolverem.

Łańcuch zaufania wykorzystuje między innymi:

• DNSKEY - publiczne klucze strefy,
• RRSIG - podpisy zestawów rekordów,
• DS - odcisk klucza zapisany w strefie nadrzędnej,
• NSEC lub NSEC3 - kryptograficzne potwierdzenie nieistnienia nazwy lub typu.

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

RFC 9364 określa użycie DNSSEC do uwierzytelniania pochodzenia danych DNS jako aktualną dobrą praktykę.

Największe ryzyko DNSSEC

Najczęstszym problemem nie jest brak DNSSEC, lecz błędny łańcuch DNSSEC. Jeżeli u rejestratora pozostanie rekord DS wskazujący na stary klucz, a nowy operator DNS podpisuje strefę innym kluczem, walidujące resolvery zwrócą SERVFAIL.

Bezpieczna migracja DNSSEC wymaga:

1. sprawdzenia, kto podpisuje strefę,
2. ustalenia metody transferu lub rollover kluczy,
3. publikacji właściwego DS w domenie nadrzędnej,
4. odczekania TTL rekordów DNSKEY i DS,
5. dopiero potem usunięcia starych kluczy lub starej strefy,
6. testowania przez walidujące resolvery.

Nie włączaj DNSSEC, jeśli dostawca nie zapewnia jasnego procesu obsługi DS i rotacji kluczy.

4. DNSSEC kontra DoH i DoT

Te mechanizmy rozwiązują inne problemy:

Mechanizm	Chroni	Nie zapewnia
DNSSEC	autentyczność i integralność danych DNS	poufności zapytania
DNS over TLS	szyfrowanie między klientem a resolverem przez TLS, zwykle port 853	autentyczności danych bez walidacji DNSSEC
DNS over HTTPS	szyfrowanie DNS w HTTPS	autentyczności danych bez DNSSEC
zwykły DNS	podstawowe rozwiązywanie nazw	poufności i kryptograficznej integralności

DNS over TLS opisuje RFC 7858, a DNS over HTTPS RFC 8484. Szyfrowany transport chroni zapytanie przed prostym podsłuchem na odcinku klient-resolver, ale operator resolvera nadal widzi zapytania, a dalsze rozwiązywanie zależy od jego polityki.

5. SSL a TLS: poprawna terminologia

„Certyfikat SSL” jest nadal powszechnym określeniem marketingowym, ale współczesne strony używają TLS. SSL 2.0 i SSL 3.0 są przestarzałe, a TLS 1.0 i 1.1 zostały formalnie wycofane przez IETF.

W 2026 roku:

• TLS 1.3 powinien być preferowany,
• TLS 1.2 pozostaje kompatybilnym minimum dla starszych, nadal wspieranych klientów,
• TLS 1.0, TLS 1.1, SSLv2 i SSLv3 powinny być wyłączone,
• konfiguracja TLS 1.2 powinna używać nowoczesnych zestawów z AEAD i forward secrecy,
• serwer nie powinien oferować przestarzałych algorytmów i wymian kluczy.

RFC 9325 zawiera aktualne rekomendacje bezpiecznego używania TLS i zastąpił wcześniejsze BCP 195.

6. Co sprawdza przeglądarka w certyfikacie?

Podczas połączenia TLS klient sprawdza między innymi:

1. czy certyfikat jest w okresie ważności,
2. czy nazwa hosta występuje w subjectAltName,
3. czy podpis prowadzi przez poprawny łańcuch pośredni do zaufanego root CA,
4. czy certyfikat nie jest używany do niewłaściwego celu,
5. czy parametry połączenia są akceptowalne,
6. czy polityki przeglądarki nie odrzucają certyfikatu.

Tożsamość serwera jest obecnie weryfikowana na podstawie SAN, nie pola Common Name jako podstawowego źródła nazwy.

SAN

Jeden certyfikat może obejmować wiele nazw:

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

Każda nazwa musi znaleźć się w SAN.

Wildcard

*.example.com

obejmuje:

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

ale nie obejmuje automatycznie:

example.com
www.eu.example.com

Domenę główną należy dodać osobno, a wildcard działa tylko dla jednego poziomu etykiety.

SNI

Server Name Indication pozwala klientowi przekazać nazwę hosta podczas handshake, dzięki czemu jeden adres IP może obsługiwać wiele certyfikatów. Błędna konfiguracja SNI często powoduje wyświetlenie certyfikatu innej domeny.

Łańcuch certyfikatów

Serwer powinien wysyłać certyfikat domeny oraz potrzebne certyfikaty pośrednie, ale zwykle nie root. Brak intermediate może działać na jednym urządzeniu, które wcześniej zapisało certyfikat, i zawodzić na innym.

7. Ważność certyfikatów w 2026 roku

CA/Browser Forum przyjęło harmonogram skracania publicznych certyfikatów TLS:

Data wydania	Maksymalna ważność
przed 15 marca 2026	398 dni
15 marca 2026 - 14 marca 2027	200 dni
15 marca 2027 - 14 marca 2029	100 dni
od 15 marca 2029	47 dni

To nie oznacza, że każdy CA wydaje certyfikat na maksymalny okres. Let’s Encrypt domyślnie nadal wydaje certyfikaty 90-dniowe, ma opcjonalne certyfikaty sześciodniowe i profil tlsserver z certyfikatami 45-dniowymi dostępny dla wczesnych wdrożeń od maja 2026 roku.

Wniosek jest prosty: ręczne odnawianie certyfikatów przestaje być rozsądną praktyką operacyjną.

8. ACME i automatyzacja certyfikatów

ACME jest standardowym protokołem automatyzującym rejestrację konta, walidację kontroli domeny, wydanie, odnowienie i unieważnienie certyfikatu.

HTTP-01

CA pobiera plik:

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

Zalety:

• prosta konfiguracja dla pojedynczego serwera WWW,
• łatwa automatyzacja,
• nie wymaga API DNS.

Ograniczenia:

• wymaga dostępnego portu 80,
• nie wydaje wildcard,
• challenge musi dotrzeć do właściwego serwera,
• błędne AAAA, proxy, redirect albo load balancer mogą przerwać walidację.

Let’s Encrypt rekomenduje pozostawienie portu 80 dla publicznych serwerów WWW i przekierowywanie normalnego ruchu do HTTPS.

DNS-01

Klient publikuje TXT:

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

Zalety:

• obsługuje wildcard,
• działa bez publicznego serwera HTTP,
• nadaje się do centralnej obsługi certyfikatów.

Ryzyka:

• wymaga bezpiecznego dostępu do API DNS,
• propagacja i cache mogą opóźnić walidację,
• token API z prawem edycji całej strefy zwiększa skutki wycieku,
• stare TXT mogą utrudnić diagnostykę.

Let’s Encrypt wyraźnie zaleca używanie DNS-01 z dostawcą oferującym API, ponieważ automatyzacja odnowień jest kluczowa. Przydzielaj tokenowi najmniejszy możliwy zakres: najlepiej tylko do rekordów _acme-challenge, nie do zarządzania domeną, kontem czy wszystkimi strefami.

Wildcard w Let’s Encrypt wymaga DNS-01.

TLS-ALPN-01

Walidacja odbywa się przez specjalne połączenie TLS na porcie 443 i protokół ALPN. Jest użyteczna dla wyspecjalizowanych proxy i systemów zarządzania certyfikatami, ale rzadziej konfigurowana ręcznie.

Renewal Information

Nowoczesny klient ACME powinien obsługiwać ACME Renewal Information, czyli ARI. Zamiast odnawiać każdy certyfikat według jednego sztywnego progu klient może otrzymać od CA sugerowane okno odnowienia. Let’s Encrypt zaleca sprawdzanie informacji ARI co najmniej dwa razy dziennie.

9. CAA i ACME: przykład praktyczny

Dla certyfikatów Let’s Encrypt:

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

Jeśli nie chcesz wildcard:

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

Przed wydaniem publiczny CA ma obowiązek sprawdzić CAA. Od 15 marca 2026 roku wymagania CA/Browser Forum nakazują również walidację DNSSEC dla zapytań związanych z CAA wykonywanych z głównej perspektywy sieciowej, a błędu walidacji DNSSEC nie wolno traktować jako zgody na wydanie.

Po zmianie CA pamiętaj o aktualizacji CAA przed uruchomieniem nowego procesu wydawania.

10. HTTPS, przekierowania i HSTS

Minimalny schemat:

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

Po potwierdzeniu pełnego działania HTTPS można dodać:

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

HSTS informuje przeglądarkę, aby w przyszłości używała tylko HTTPS i nie pozwalała ominąć części błędów certyfikatu.

Nie zaczynaj od długiego max-age, includeSubDomains i preload, jeśli:

• istnieją subdomeny bez HTTPS,
• część infrastruktury jest zarządzana przez partnera,
• nie przetestowano procesu odnowień,
• nie ma monitoringu certyfikatów,
• nie wiadomo, czy stara usługa będzie nadal potrzebna.

HSTS preload umieszcza regułę w dystrybucji przeglądarek. Usunięcie wpisu może trwać tygodniami.

11. Najczęstsze błędy DNS

Błędny rekord AAAA

IPv4 działa, ale część klientów wybiera niedziałające IPv6. Objawy są losowe zależnie od sieci użytkownika.

CNAME i inne rekordy pod tą samą nazwą

Alias koliduje z rekordami adresowymi, MX lub TXT. Panel dostawcy może blokować zmianę albo generować niejednoznaczną strefę.

Niespójna delegacja NS

Rejestrator wskazuje inne serwery niż strefa albo jeden z serwerów ma starszą wersję danych.

Stary DS po zmianie DNS

Domena zwraca SERVFAIL tylko u resolverów walidujących DNSSEC.

Zbyt niski TTL na stałe

Zwiększa liczbę zapytań i wrażliwość na chwilową niedostępność DNS, nie zapewnia automatycznie szybkiego failover.

Zbyt wysoki TTL przed migracją

Stare adresy pozostają w cache przez wiele godzin.

Pozostawione rekordy TXT

Stare tokeny weryfikacyjne i ACME utrudniają audyt oraz zwiększają chaos operacyjny.

Brak spójności www i apex

example.com i www.example.com kierują do różnych systemów, mają inne certyfikaty albo tworzą pętlę przekierowań.

12. Najczęstsze błędy TLS i certyfikatów

Certyfikat wygasł

Najczęściej przyczyną nie jest brak automatyzacji, lecz automat, który przestał działać bez alertu.

Certyfikat nie obejmuje hosta

Certyfikat dla example.com nie zabezpiecza automatycznie www.example.com.

Niepełny chain

Brakuje certyfikatu pośredniego. Problem może występować tylko na nowych urządzeniach lub wybranych klientach.

Zły certyfikat przez SNI

Reverse proxy ma błędny default virtual host albo nowa domena nie została dodana do mapowania.

Stare protokoły i cipher suites

Serwer nadal oferuje TLS 1.0/1.1 lub stare zestawy, bo konfiguracja pochodzi sprzed wielu lat.

Brak zgodności na wielu warstwach

CDN ma prawidłowy certyfikat publiczny, ale połączenie CDN→origin jest nieszyfrowane albo nie weryfikuje nazwy hosta.

Odnowienie wykonane, ale proces nie przeładował serwera

Nowy plik certyfikatu istnieje na dysku, lecz Nginx, Apache, HAProxy lub aplikacja nadal używa starego certyfikatu z pamięci.

13. Diagnostyka krok po kroku

Rekordy 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

Delegacja

dig example.com NS
dig +trace example.com

DNSSEC

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

SERVFAIL przy działaniu bez walidacji jest silnym sygnałem problemu DNSSEC.

Certyfikat i SNI

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

Daty certyfikatu

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 i HSTS

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

Sprawdź redirect, Strict-Transport-Security, hostname, status końcowy i brak pętli.

Możesz również użyć bezpłatnego Inspektora DNS i SSL POLPROG, który pokazuje rekordy DNS oraz informacje o certyfikacie TLS. Uzupełnij test przez Inspektor nagłówków bezpieczeństwa, Kondycję witryny i artykuł Podstawy bezpieczeństwa aplikacji webowych.

14. Monitoring produkcyjny

Nie monitoruj tylko homepage z jednej lokalizacji. Minimalny zestaw:

• odpowiedź autorytatywnego DNS,
• rekordy A, AAAA, CNAME, NS, MX i CAA,
• walidacja DNSSEC,
• dostępność po IPv4 i IPv6,
• daty certyfikatu,
• zgodność SAN,
• pełny chain,
• TLS 1.2 i TLS 1.3,
• końcowy redirect HTTP→HTTPS,
• HSTS,
• odpowiedź originu za CDN,
• działanie ACME i ostatnia udana odnowa.

Progi alertów certyfikatu

Dla w pełni automatycznego systemu:

Pozostały czas	Reakcja
30 dni	ostrzeżenie lub kontrola trendu
14 dni	alert wymagający analizy
7 dni	incydent operacyjny
3 dni	krytyczny alert i eskalacja
mniej niż 24 h	awaria oczekująca

Progi należy dopasować do długości certyfikatu. Dla certyfikatów sześciodniowych lub 45-dniowych monitoring musi reagować znacznie wcześniej proporcjonalnie do cyklu odnowienia.

15. Bezpieczna checklista DNS i TLS

Rejestrator i DNS

• Konto rejestratora ma MFA.
• Transfer domeny jest zablokowany.
• Dane kontaktowe i proces odzyskiwania są aktualne.
• Używane są co najmniej dwa autorytatywne serwery DNS.
• Serwery działają w odrębnych sieciach lub lokalizacjach.
• Delegacja NS u rejestratora i w strefie jest spójna.
• Rekordy A i AAAA wskazują aktywną infrastrukturę.
• IPv6 jest rzeczywiście monitorowane.
• Rekordy MX, SPF, DKIM i DMARC są zachowane przy migracjach.
• CAA pozwala tylko używanym CA.
• Nie ma zbędnych rekordów TXT i tokenów weryfikacyjnych.
• TTL został obniżony z wyprzedzeniem przed migracją.
• TTL podniesiono po stabilizacji.
• Dostęp do API DNS ma minimalne uprawnienia.

DNSSEC

• Dostawca wspiera DNSSEC i rotację kluczy.
• Rekord DS u rejestratora odpowiada aktywnemu DNSKEY.
• Zmiany operatora DNS mają plan migracji DNSSEC.
• Stare DS i klucze są usuwane dopiero po wygaśnięciu cache.
• Domena jest testowana przez walidujący resolver.
• Alert wykrywa SERVFAIL i wygaśnięcie podpisów.

Certyfikaty

• Certyfikaty są wydawane i odnawiane przez ACME.
• Odnowienie zostało przetestowane, nie tylko pierwsze wydanie.
• Proces przeładowuje serwer po instalacji nowego certyfikatu.
• Wszystkie hosty występują w SAN.
• Wildcard jest używany świadomie.
• Chain zawiera właściwe intermediates.
• Klucz prywatny nie opuszcza właściwego systemu.
• Uprawnienia do klucza są ograniczone.
• Alerty działają niezależnie od samego klienta ACME.
• DNS-01 używa ograniczonego tokenu API.
• HTTP-01 działa po IPv4 i IPv6.
• Staging CA jest używane do testów automatyzacji.

TLS i HTTPS

• TLS 1.3 jest włączony.
• TLS 1.2 pozostaje tylko dla potrzebnej kompatybilności.
• TLS 1.0, TLS 1.1 i SSL są wyłączone.
• Serwer nie oferuje przestarzałych cipher suites.
• SNI zwraca właściwy certyfikat dla każdego hosta.
• HTTP przekierowuje bezpośrednio do HTTPS.
• Nie ma mixed content.
• HSTS wdrożono etapami.
• includeSubDomains jest bezpieczne dla całej domeny.
• Preload został przeanalizowany przed zgłoszeniem.
• CDN→origin również używa poprawnie weryfikowanego TLS.

Werdykt

Dobra konfiguracja DNS i TLS w 2026 roku opiera się na czterech zasadach:

1. DNS musi być spójny i odporny operacyjnie.
2. DNSSEC powinien być wdrożony tylko z poprawnym zarządzaniem DS i kluczami.
3. Certyfikaty muszą być obsługiwane automatycznie przez ACME.
4. TLS 1.3, poprawny chain, monitoring i HSTS są częścią jednego procesu, a nie oddzielnymi zadaniami.

Największym ryzykiem nie jest brak „zielonej kłódki” w dniu uruchomienia. Jest nim cicha awaria kilka miesięcy później: wygasły certyfikat, nieaktualny rekord AAAA, pozostawiony DS, token DNS z nadmiernymi uprawnieniami albo automat odnawiania, którego nikt nie monitorował.