Gdy zmienił się klucz główny internetu, nasza poczta wychodząca czekała dziewięć godzin
Od około 19:00 UTC 12 października 2026 do 4:20 UTC następnego dnia serwer poczty, który DARCH prowadzi dla siebie i swoich klientów, nie mógł wysyłać poczty. Nic nie zostało odrzucone i nic nie zginęło. Przyczyną była przeprowadzona dzień wcześniej planowa zmiana klucza, którym podpisana jest strefa główna DNS. W tej notatce opisujemy, co się stało, dlaczego i co zmieniliśmy.
Co się stało
- Każda wiadomość wychodząca z naszego serwera poczty była wstrzymywana z komunikatem
4.4.3 Host or domain name not found. Serwer nie mógł znaleźć adresu dla żadnej nazwy, także dla Gmaila. - 13 października o 4:10 UTC resolver DNS serwera został zrestartowany. Od 4:20 UTC wstrzymana poczta zaczęła wychodzić.
- Serwery poczty przez kilka dni ponawiają próby wysłania wstrzymanych wiadomości, więc wszystkie dotarły, choć z opóźnieniem. Ponad 50 e-maili wysłanych tamtego wieczoru dostarczono między 4:20 a 5:30 UTC następnego ranka. Nic nie zostało odrzucone ani nie wygasło.
- Nic nas wtedy nie zaalarmowało: żaden test nie pilnował kolejki poczty wychodzącej. Opóźnienie zauważyliśmy 14 października, czytając eksport poczty.
Dlaczego
Serwer poczty ma własny resolver DNS, bo listy blokujące spam odrzucają zapytania, które przychodzą przez duże publiczne resolvery. Nasz resolver, część serwera poczty Mailu z otwartym kodem źródłowym, sprawdza podpisy DNSSEC. Ufa systemowi DNS w internecie tylko na tyle, na ile ufa kluczowi strefy głównej.
- 11 października 2026 strefa główna zaczęła być podpisywana nowym kluczem, KSK-2024 (key tag 38696), zamiast KSK-2017 (key tag 20326). Nowy klucz był opublikowany w strefie głównej od stycznia 2025.
- Nasz resolver działał z obrazu zbudowanego 30 września 2026. Jego lista zaufanych kluczy zawierała oba, ale nowy tylko jako oczekujący. Zgodnie z RFC 5011 resolver przyjmuje nowy klucz po 30 dniach obserwacji: w przypadku tego obrazu około 30 października.
- Gdy strefa główna była już podpisana tylko nowym kluczem, nasz resolver przestał czemukolwiek ufać. W jego logu powtarzał się wpis
failed to prime trust anchor -- DNSKEY rrset is not secure, a każde zapytanie kończyło się błędem. - Dwóch rzeczy nie udało się udowodnić. Dlaczego awaria zaczęła się dzień po zmianie: wyjaśniałoby to wygaśnięcie kopii starego zestawu kluczy w pamięci podręcznej. I dlaczego pomógł restart: po restarcie resolver ufał obu kluczom.
Co zmieniliśmy
- Nowy test co pięć minut sprawdza z wnętrza serwera poczty, czy działa rozwiązywanie nazw, i liczy wiadomości w kolejce wychodzącej. Nieudane zapytania DNS powinny wywołać alert po około 15 minutach, podobnie jak każda wiadomość, która czeka dłużej niż godzinę. Oba alerty przetestowaliśmy na atrapach; na prawdziwym serwerze żaden jeszcze się nie pojawił.
- 17 października zaktualizowaliśmy serwer poczty. Resolver w obecnych obrazach Mailu ma oba klucze główne zapisane na stałe jako kotwice zaufania i odświeża je przy każdym starcie.
- Awaria, jej objawy i polecenia do sprawdzenia resolvera są w naszych instrukcjach.
Jeśli prowadzisz Mailu, Unbound lub inny resolver z weryfikacją DNSSEC w kontenerze
- Sprawdź klucze, którym ufa działający resolver, a nie plik w obrazie. W zapytaniach wysyłanych przez Unbound
_ta-4f66oznacza, że ufa tylko staremu kluczowi, a_ta-4f66-9728, że obu (4f66 i 9728 to 20326 i 38696 w zapisie szesnastkowym). - Poszukaj w jego logu
failed to prime trust anchor. Każdy taki wpis po 11 października 2026 oznacza, że resolver nie ma drogi do strefy głównej. - Obraz zbudowany tuż przed zmianą może mieć nowy klucz jako oczekujący, a kontener odtworzony z takiego obrazu zaczyna 30-dniowe oczekiwanie od nowa.
- Pilnuj kolejki poczty wychodzącej, a nie tylko tego, czy odpowiadają porty poczty. Nasze odpowiadały przez całą noc.
- Stary klucz, KSK-2017, ma zostać unieważniony w pierwszym kwartale 2027. Sprawdź wtedy wszystko jeszcze raz.
Źródła
Wszystkie źródła są po angielsku.