Domena, DNS, certyfikat i poczta po starcie aplikacji — co wygasa, kto tego pilnuje i co się psuje?

Co ma termin: cztery rzeczy, które wygasają same

Po starcie aplikacja stoi na czterech elementach z własnym zegarem: domenie, strefie DNS, certyfikacie TLS i rekordach poczty. Najkrótszy zegar ma certyfikat — domyślny certyfikat Let's Encrypt jest ważny 90 dni (odczyt 31 sierpnia 2026).

Trzy z tych elementów odnawiają się automatycznie albo nie odnawiają wcale, w zależności od jednego warunku: czy rekordy DNS wskazują tam, gdzie powinny. Domena jest wyjątkiem — jej nikt nie odnowi bez opłaty i bez decyzji właściciela.

Dlatego awaria po miesiącach spokoju wygląda zawsze podobnie. W kodzie nikt niczego nie zmienił, a strona przestaje się otwierać albo przeglądarka pokazuje pełnoekranowe ostrzeżenie. Zmienił się stan jednego wpisu poza aplikacją.

Automatycznie odnawia się dokładnie jeden wiersz z sześciu — certyfikat. Reszta ma właściciela z nazwiskiem albo nie ma nikogo, a wtedy pilnuje jej przypadek.

Okno między odnowieniami certyfikatu będzie się skracać i jest to decyzja branżowa, nie wybór hostingu. CA/Browser Forum ma zapisany harmonogram: maksymalna ważność certyfikatu to 200 dni od 15 marca 2026, 100 dni od 15 marca 2027 i 47 dni od 15 marca 2029 (odczyt 31 sierpnia 2026).

Let's Encrypt dodaje przy tym, że tych okresów nie da się ustawić po swojemu: „There is no way to adjust these lifetimes, there are no exceptions”. Odnowienie zaleca po 60 dniach przy certyfikacie 90-dniowym i co trzy dni przy wariancie sześciodniowym.

Wniosek dla właściciela aplikacji jest praktyczny. Ręczne odnawianie certyfikatu przestaje być realne — od 15 marca 2029 ten sam obowiązek wracałby co niecałe siedem tygodni. Automat musi działać, a ktoś musi widzieć, że działa.

Kto jest właścicielem czego?

Domena i konto u rejestratora stoją na firmie od pierwszego dnia — to zasada, nie uprzejmość. Zakłada się je na dane firmy i na adres e-mail, który firma kontroluje. Konto u dostawcy hostingu i bazy — zgodnie z umową; zespół, który buduje, dostaje do niego dostęp, nie zawsze jego własność.

Różnicę widać dopiero przy zmianie wykonawcy albo przy sporze. Konto założone na prywatny adres programisty jest jego kontem, choćby faktura szła na firmę. Odzyskanie domeny z takiego konta to procedura u rejestratora, a nie jedno kliknięcie.

Podział, który się broni, ma trzy poziomy. Domena i konto u rejestratora — firma, zawsze. Hosting, baza i konto operatora płatności — zgodnie z umową, zwykle z dostępem zespołu utrzymania do czasu jej zakończenia. Konta narzędziowe zespołu (monitoring, repozytorium) — zespół, ale z eksportem konfiguracji na żądanie.

Czwarty element bywa pomijany: adres e-mail, na który przychodzą przypomnienia o odnowieniu domeny i faktury od dostawców. Jeśli to prywatna skrzynka jednej osoby, terminy znikają razem z tą osobą.

Kolejność przekazywania dostępów przed startem — kto co zakłada i co blokuje termin — opisaliśmy w tekście o materiałach, decyzjach i dostępach.

Gdzie to się psuje?

Pięć awarii, które wyglądają jak awaria aplikacji, a nią nie są. Każdą widać dopiero po fakcie, bo w logach aplikacji nic się nie dzieje.

• Przepięcie serwerów nazw bez sprawdzenia, czy strefa DNS w ogóle powstała. Domena kupiona u jednego dostawcy i wskazana serwerami nazw na hosting nie dostaje strefy DNS sama.

  To lekcja z własnego serwisu, sierpień 2026. Od tamtej pory po podpięciu domeny sprawdzamy, czy rekordy adresu, certyfikatu i poczty faktycznie istnieją i odpowiadają, zanim ogłosimy start.

• Przekierowanie www ustawione w pliku konfiguracyjnym projektu. U nas taki wpis w konfiguracji hostingu nie zadziałał — przekierowanie z www na domenę główną ustawiamy na poziomie domeny, u dostawcy domeny.

  Objaw jest mylący: adres bez www otwiera się poprawnie, więc temat wygląda na zamknięty. Klient, który wpisał adres z www, widzi błąd albo ostrzeżenie o certyfikacie.

• Certyfikat, który nie odnowił się po cichu. Hosting próbuje odnowić certyfikat w oknie 14–30 dni przed wygaśnięciem, ale przy błędnej konfiguracji domeny — jak podaje dokumentacja Vercela — najpewniej tego nie zrobi.

  Sygnał, na który część zespołów liczyła, też nie przyjdzie: od 4 czerwca 2025 Let's Encrypt nie wysyła już e-maili o zbliżającym się wygaśnięciu certyfikatu.

• Poczta firmowa wyłączona przez przepięcie domeny. Zmiana serwerów nazw zastępuje rekordy, które trzymał dotychczasowy dostawca — razem z wpisami MX poczty.

  Dokumentacja Vercela mówi wprost, że domyślne rekordy obsługują stronę, nie pocztę, i że wpisy MX oraz weryfikacyjne trzeba dodać ponownie. Bez tego listy do firmy nie mają dokąd trafić.

• Wygasła karta u rejestratora. Odnowienie domeny nie jest zadaniem technicznym, tylko płatnością — i przepada z tego samego powodu, z którego przepadają inne płatności cykliczne.

  Domena .pl po zakończeniu opłaconego okresu rozliczeniowego przebywa w tym stanie do 30 dni. Potem umowa zostaje rozwiązana, a domena czeka jeszcze 5 dni (rejestr NASK, odczyt 31 sierpnia 2026).

Wspólny mianownik jest jeden: wszystkie pięć awarii mieszka poza kodem aplikacji. Monitoring, który sprawdza tylko, czy adres główny odpowiada, złapie z nich najwyżej dwie — i to z opóźnieniem.

Co obserwować po starcie, jakimi narzędziami i w jakich interwałach, opisaliśmy w tekście o monitoringu, aktualizacjach i incydentach.

Jak to sprawdzić samemu w 5 minut

Pięć sprawdzeń bez narzędzi programisty i bez dostępu do kodu. Każde kończy się datą albo odpowiedzią „tak / nie”, którą można zapisać i pokazać wykonawcy.

• Data wygaśnięcia domeny. Sprawdź nazwę w wyszukiwarce WHOIS rejestru (dla domen .pl prowadzi ją NASK) albo w panelu rejestratora. Interesuje cię jedna data i jedna odpowiedź: czy odnowienie jest opłacone automatycznie.
• Ważność certyfikatu. Kliknij kłódkę obok adresu w przeglądarce i wejdź w szczegóły certyfikatu. Zobaczysz datę „ważny do”. Jeśli zostało mniej niż 14 dni, a nikt nie potwierdził, że automat działa — to jest temat na dziś.
• Adres z www i bez www. Otwórz oba warianty na telefonie, w oknie prywatnym. Oba mają skończyć na tej samej stronie i z kłódką. Jeden wariant z ostrzeżeniem oznacza brakujący rekord albo brakujące przekierowanie.
• Poczta w obie strony. Wyślij wiadomość z aplikacji na skrzynkę Gmail i na Outlook, a potem odpisz na adres firmowy z prywatnej skrzynki. Sprawdzasz dwie różne rzeczy: wysyłkę z aplikacji i odbiór na domenie.
• Skrzynka z przypomnieniami. Znajdź w niej wiadomość od rejestratora domeny z ostatnich miesięcy. Jeśli takiej wiadomości nie ma w skrzynce, którą czyta ktoś z firmy, terminów nie pilnuje nikt.

Piąty punkt rozstrzyga częściej niż cztery pierwsze. Termin, którego nikt nie widzi, mija bez ostrzeżenia — a przypomnienie o certyfikacie od urzędu certyfikacji już nie przyjdzie.

Trzy rekordy nadawcze poczty — SPF, DKIM i DMARC — oraz powody, dla których wiadomości z aplikacji lądują w spamie, to osobny temat, który opisaliśmy w tekście o poczcie z aplikacji. Tutaj wystarczy zasada: rekordy poczty przepisuje się przed przepięciem serwerów nazw, nie po nim.

Po czym poznać porządną opiekę nad tą warstwą?

Sześć pytań do wykonawcy albo do zespołu utrzymania. Każde ma odpowiedź w postaci daty, nazwiska albo adresu — odpowiedź „to się dzieje samo” jest w każdym z nich odpowiedzią negatywną.

• Gdzie jest kalendarz terminów? Data odnowienia domeny, data ważności certyfikatu i terminy planów u dostawców w jednym miejscu, z alarmem 30 dni przed. Nie w głowie i nie w skrzynce jednej osoby.
• Na kogo są konta? Domena, rejestrator, hosting, baza, operator płatności i poczta — na danych firmy. Zespół utrzymania dostaje dostęp, nie własność.
• Kto dostaje faktury i przypomnienia? Adres, który czytają co najmniej dwie osoby z firmy. Skrzynka wykonawcy nie jest tym adresem.
• Czy certyfikat jest w monitoringu? Sprawdzanie samego adresu nie wystarczy — monitor ma alarmować przed wygaśnięciem, nie po nim. Narzędzia i ich limity opisaliśmy w tekście o monitoringu.
• Czy rekordy sprawdzono przed ogłoszeniem startu? Adres, certyfikat i poczta — trzy odpowiedzi „sprawdzone”, każda z datą. U nas to warunek ogłoszenia startu, nie punkt na liście życzeń.
• Co się stanie, gdy odejdzie osoba, która to ustawiała? Odpowiedź ma wskazać miejsce, w którym zapisano dostępy i terminy. Jeśli zawiera tylko imię, to nie jest odpowiedź.

Jeśli na trzy z tych pytań pada „sprawdzimy”, opieki nad tą warstwą nie ma. Jest za to termin, który minie w sobotę, i nikt nie zobaczy tego wcześniej niż klient.

Czego ten tekst nie rozstrzyga?

Nie ma tu zasad dotyczących sekretów, kluczy i polityk dostępu — te zebraliśmy w tekście o bezpieczeństwie aplikacji od pierwszego dnia. Nie ma też opisu warstw, na których stoi aplikacja — to osobny tekst o warstwach.

Ten artykuł opisuje jedno: co wygasa poza kodem, w jakim czasie i kto ma ten termin w kalendarzu. Cztery daty, jedno konto e-mail i jeden alarm — tyle wystarczy, żeby aplikacja nie przestała działać z powodu, który nie ma nic wspólnego z aplikacją.