Migracja serwerów nazw może wyglądać na udaną we wszystkich panelach administracyjnych, a mimo to strona pozostaje niedostępna. Domena jest aktywna, nowe autorytatywne serwery DNS zwracają oczekiwany adres, a konfiguracja serwera WWW się nie zmieniła. Jednak resolwery weryfikujące DNSSEC zwracają SERVFAIL. Przyczyną bywa delegacja DNSSEC, która nadal wskazuje klucz podpisujący poprzedniego operatora DNS.
W przypadku, na którym opiera się ta analiza, zwykłe zapytania DNS kończyły się niepowodzeniem, lecz te same zapytania działały po pominięciu walidacji DNSSEC. Strefa nadrzędna nadal publikowała stary rekord DS, podczas gdy nowa strefa autorytatywna początkowo nie była podpisana. Opublikowanie pasującego klucza i podpisanie nowej strefy przywróciło poprawne, zweryfikowane odpowiedzi na testowanych resolwerach. Najważniejszy wniosek nie jest taki, że należy wyłączyć DNSSEC. Chodzi o to, że zmiana serwerów nazw i przeniesienie łańcucha zaufania DNSSEC to dwie odrębne operacje.
Dlaczego poprawne rekordy A nie chronią przed SERVFAIL
DNS odpowiada na dwa różne pytania. Rekord A wskazuje resolwerowi adres IPv4 przypisany do danej nazwy. DNSSEC pozwala natomiast sprawdzić, czy odpowiedzi można zaufać. Poprawny adres nie oznacza automatycznie prawidłowego łańcucha zaufania DNSSEC.
W przypadku podpisanej domeny łańcuch zaufania prowadzi od zaufanej strefy nadrzędnej przez rekord DS (Delegation Signer) do klucza DNSKEY w strefie podrzędnej. Strefa podrzędna publikuje podpisy (RRSIG) swoich danych DNS. Rekord DS zawiera skrót identyfikujący uprawniony klucz DNSKEY; nie jest rekordem A, kopią klucza prywatnego ani ustawieniem w typowym edytorze pliku strefy.
Po zmianie autorytatywnych serwerów nazw strefa nadrzędna może nadal publikować rekord DS powiązany z poprzednim kluczem podpisującym. Jeśli nowa strefa nie udostępnia odpowiadającego mu klucza DNSKEY i podpisów, resolwer weryfikujący DNSSEC nie może zbudować pełnego łańcucha zaufania. Zwykle uznaje odpowiedź za nieprawidłową pod względem kryptograficznym i zwraca SERVFAIL zamiast niezweryfikowanego adresu.
To nie jest awaria HTTP: żądanie może w ogóle nie dotrzeć do serwera WWW. Nie jest to też problem wygasłego certyfikatu TLS. DNSSEC weryfikuje dane DNS, a HTTPS zabezpiecza późniejsze połączenie przeglądarki z serwerem.
Test odróżniający problem z DNSSEC od brakującego rekordu
Najbardziej miarodajny test polega na dwukrotnym zapytaniu tego samego resolwera o tę samą nazwę. Najpierw wykonaj zwykłe zapytanie i sprawdź jego status, a nie tylko odpowiedź:
dig example.com A +noall +comments +answerNastępnie powtórz zapytanie z ustawionym bitem CD (DNSSEC Checking Disabled):
dig example.com A +cdflag +noall +comments +answerPodczas opisanej awarii zwykłe zapytanie zwracało SERVFAIL, natomiast zapytanie z bitem CD — oczekiwany rekord A. Takie zestawienie silnie wskazywało na problem z walidacją DNSSEC, a nie brak rekordu DNS czy niedostępność aplikacji. Opcja +cdflag prosi obsługujący ją rekurencyjny resolwer, aby przy danym zapytaniu pominął zwykłą walidację DNSSEC. To narzędzie diagnostyczne, nie sposób na naprawę problemu w przeglądarce ani na wyłączenie DNSSEC dla odwiedzających.
Nie wyciągaj zbyt daleko idących wniosków z pustego wyniku +short. W tym formacie zarówno brak odpowiedzi, jak i SERVFAIL mogą wyglądać jak pusty wynik. Podczas diagnostyki używaj +comments, aby widzieć status: SERVFAIL lub status: NOERROR.
Samo porównanie z bitem CD nie wskazuje, który element DNSSEC zawiódł; pokazuje jedynie, co należy sprawdzić dalej. Resolwer może też chwilowo napotkać błąd po stronie serwera nadrzędnego. W razie potrzeby powtórz test i sprawdź delegację w strefie nadrzędnej.
Sprawdź rekord DS w strefie nadrzędnej, nie tylko w edytorze DNS
Sprawdź rekordy DS domeny:
dig example.com DS +noall +comments +answerAby dokładniej prześledzić ścieżkę delegacji, odpytaj bezpośrednio hierarchię DNS:
dig +trace example.com DSTo, który autorytatywny serwer obsługuje strefę nadrzędną, zależy od domeny najwyższego poziomu. Liczy się zestaw rekordów DS (RRset) publikowany przez strefę nadrzędną, a nie samo podsumowanie w panelu hostingu DNS. Transfer domeny do innego rejestratora może odbyć się bez zmiany serwerów nazw, a serwery nazw można zmienić bez przenoszenia domeny do innego rejestratora. W obu przypadkach rekord DS w strefie nadrzędnej musi być zgodny z aktywną strefą autorytatywną.
Rekord DS ma cztery istotne pola: identyfikator klucza (key tag), algorytm, typ skrótu oraz sam skrót. Identyfikator klucza ułatwia diagnostykę, ale sam w sobie nie dowodzi zgodności z DNSKEY. Również informacje o skrócie i algorytmie muszą odpowiadać kluczowi rzeczywiście udostępnianemu przez strefę autorytatywną.
W opisywanym przypadku stan był jednoznaczny: strefa nadrzędna nadal publikowała wcześniejsze dane zaufania DNSSEC, a interfejs nowej usługi autorytatywnego DNS informował, że podpisywanie jest nieaktywne. Rekordy A istniały i można je było pobrać po pominięciu walidacji. Zmiany w konfiguracji aplikacji ani wielokrotne edytowanie tego samego rekordu A nie usunęłyby tej niezgodności.
Dwa sposoby naprawy nieprawidłowej delegacji DNSSEC
Istnieją dwie prawidłowe strategie przywracania działania domeny. Obie usuwają tę samą niezgodność w łańcuchu zaufania, ale mają różne konsekwencje operacyjne. Wybierz świadomie jedną z nich, zamiast chaotycznie przełączać się między obiema.
Opcja 1: usuń nieaktualny DS i tymczasowo pozostaw strefę niepodpisaną
Poproś obecnego rejestratora lub skorzystaj z udostępnionego przez niego interfejsu zarządzania DNSSEC, aby usunąć nieaktualny rekord DS ze strefy nadrzędnej. Gdy strefa nadrzędna przestanie deklarować bezpieczną delegację, resolwery weryfikujące DNSSEC będą mogły traktować niepodpisaną strefę podrzędną jako niezabezpieczoną, a nie nieprawidłową. DNS znów będzie działać, ale uwierzytelnianie DNSSEC dla domeny zostanie tymczasowo wyłączone.
To często prostsze rozwiązanie awaryjne, o ile istnieje niezawodny sposób zmiany zestawu rekordów DS w strefie nadrzędnej. Zachowaj dotychczasową konfigurację podpisywania do czasu wygaśnięcia starych rekordów DS w pamięciach podręcznych resolwerów rekurencyjnych. Samo usunięcie DS w panelu nie stanowi wystarczającego potwierdzenia: sprawdź rekord zewnętrznie w strefie nadrzędnej i uwzględnij jego TTL. HTTPS działa niezależnie od konfiguracji DNSSEC. Tymczasowe przejście do strefy niepodpisanej opisuje również RFC 8078.
Opcja 2: podpisz nową strefę i opublikuj zgodny rekord DS
Alternatywą jest włączenie DNSSEC u nowego operatora autorytatywnego DNS, wygenerowanie materiału kluczy DNSKEY, podpisanie strefy i opublikowanie odpowiadającego im rekordu DS w strefie nadrzędnej. Dzięki temu resolwer weryfikujący DNSSEC może zbudować zaufaną ścieżkę do nowego DNSKEY i sprawdzić podpis rekordu A.
Właśnie tę metodę zastosowano w opisanym przypadku. Panel zarządzania DNS poinformował, że wygenerował klucze, podpisał strefę i opublikował nowy DS. Późniejsze zapytanie do strefy nadrzędnej pokazało nowy rekord DS obok poprzedniego. Zapytania do walidujących resolwerów rekurencyjnych zaczęły zwracać oczekiwany rekord A. Kolejny test zwrócił też NOERROR z ustawioną flagą ad, która oznacza, że dany resolwer uwierzytelnił dane.
Kolejność ma znaczenie: opublikowany DS będzie użyteczny tylko wtedy, gdy odpowiadający mu DNSKEY i prawidłowe podpisy są już dostępne z autorytatywnej usługi DNS. Komunikat „published” w panelu nie zastępuje niezależnej weryfikacji. Rekordy DS, DNSKEY, RRSIG i NS zapisane w pamięci podręcznej mogą powodować, że poszczególne resolwery zaczną poprawnie działać w różnym czasie.
Dlaczego dwa rekordy DS nie musiały podtrzymywać awarii
Zaskakujące było to, że strefa nadrzędna zawierała jednocześnie nieaktualny i nowy, prawidłowy rekord DS, a mimo to walidacja DNSSEC działała. Nie ma tu sprzeczności. Zestaw rekordów DS może zawierać wiele wpisów, co jest częste podczas zmiany kluczy. Walidator nie wymaga, aby każdy rekord DS wskazywał aktualnie użyteczny klucz. Wystarczy jedna prawidłowa ścieżka uwierzytelniania przez odpowiedni DS do DNSKEY i prawidłowych podpisów. RFC 6840 wyjaśnia, że walidatory powinny akceptować pojedynczą poprawną ścieżkę.
Nie oznacza to, że warto bezterminowo pozostawiać nieaktualne klucze. Stary rekord DS utrudnia zarządzanie i ostatecznie należy go usunąć po zweryfikowaniu nowego łańcucha. To jednak prace porządkowe, a nie powód do kolejnego ryzykownego resetu DNSSEC, gdy zweryfikowane odpowiedzi już działają.
Szczególnie niebezpieczna jest pułapka w panelach administracyjnych: opcja nazwana „emergency unpublish DS” może usuwać wszystkie rekordy DS, w tym nowy, działający rekord. Podobnie wyłączenie podpisywania strefy, gdy DS nadal jest publikowany, może natychmiast wywołać awarię ponownie. Żadna z tych operacji nie oznacza usunięcia tylko jednego, konkretnego nieaktualnego rekordu DS. Jeśli panel nie pozwala wskazać pojedynczego rekordu, skorzystaj z obsługiwanej przez rejestratora możliwości selektywnej zmiany, zamiast resetować wszystko.
Jak bezpiecznie zmienić autorytatywne serwery nazw
Najbezpieczniejsza kolejność zależy od tego, czy stary i nowy operator DNS mogą uzgodnić obsługę kluczy. Przy standardowej migracji z tymczasowym okresem bez podpisywania poniższa procedura pozwala uniknąć niezgodności występującej w opisanym przypadku:
- Najpierw przygotuj strefę docelową. Skopiuj potrzebne rekordy A, AAAA, CNAME, MX, TXT oraz inne istotne wpisy. Przed zmianą delegacji odpytaj bezpośrednio nowe autorytatywne serwery nazw.
- Sprawdź DNSSEC w strefie nadrzędnej. Ustal, czy istnieją rekordy DS i kto może je zmieniać. Zrób to nawet wtedy, gdy nigdy nie włączałeś DNSSEC ręcznie — niektóre usługi DNS automatyzują podpisywanie.
- Usuń stary DS, gdy poprzednia podpisana strefa nadal działa. Potwierdź zmianę na autorytatywnym serwerze strefy nadrzędnej, a następnie odczekaj, aż wcześniej zapisane w cache rekordy DS wygasną. Czas oczekiwania wynika z zaobserwowanych wartości TTL, a nie z uniwersalnej liczby minut.
- Zmień delegację serwerów nazw. Utrzymuj poprzednią usługę autorytatywną, dopóki zapisane w cache delegacje NS mogą na nią wskazywać. Uwzględnij TTL rekordów NS strefy nadrzędnej i sprawdzaj, z jakich serwerów rzeczywiście korzystają różne resolwery.
- Zdecyduj, czy ponownie włączyć DNSSEC. Jeśli nowa strefa ma pozostać niepodpisana, nie publikuj DS. Jeśli ma być podpisana, przed opublikowaniem zgodnego DS sprawdź, czy nowy DNSKEY i podpisy są już poprawnie udostępniane. Skoordynuj to z nadal istniejącymi w cache rekordami NS starej usługi, aby uniknąć kolejnej niezgodności podczas walidacji.
- Sprawdź działanie niezależnie. Zweryfikuj DS w strefie nadrzędnej, DNSKEY na serwerach autorytatywnych, zwykłe rozwiązywanie nazw przez resolwery rekurencyjne i wynik uwierzytelniania odpowiedzi w resolwerach walidujących.
Jeśli DNSSEC musi działać nieprzerwanie, lepszym rozwiązaniem jest jawnie skoordynowana wymiana kluczy lub migracja z wieloma podmiotami podpisującymi. Obaj operatorzy DNS muszą jednak obsługiwać odpowiednią konfigurację kluczy i podpisywania. Samo skopiowanie skrótu starego rekordu DS do nowego operatora nie stanowi wymiany kluczy.
Krótka lista kontrolna po migracji
Po każdej zmianie dotyczącej DNSSEC sprawdź zarówno rekordy DNS, jak i to, czy resolwery akceptują dowód ich autentyczności:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerAby sprawdzić uwierzytelnienie odpowiedzi, użyj walidującego resolwera rekurencyjnego. NOERROR wraz z oczekiwanym rekordem A oznacza poprawne rozwiązanie nazwy, a dodatkowa flaga ad informuje, że resolwer uwierzytelnił odpowiedź zgodnie ze swoją polityką DNSSEC. Sam brak flagi ad nie dowodzi awarii, ponieważ resolwery różnią się możliwościami, polityką i interpretacją flag zapytania. Jeśli podczas awarii zapytania DNSKEY przez walidujący resolwer zawodzą, sprawdź również bezpośrednio aktywną autorytatywną usługę DNS.
Nie poprzestawaj na jednej poprawnej odpowiedzi z jednego resolwera. Różne pamięci podręczne mogą przejściowo przechowywać różne delegacje i klucze. Zaktualizuj też każde otwarte zgłoszenie do wsparcia technicznego: wcześniejsza prośba o usunięcie wszystkich rekordów DS staje się niebezpieczna po opublikowaniu nowego, działającego DS. W kolejnym zgłoszeniu wyraźnie zaznacz, że aktywny klucz ma zostać zachowany, a w razie potrzeby należy usunąć wyłącznie nieaktualny rekord.
Przyczyną awarii nie był błędny adres serwera WWW. Problem wynikał ze zmiany miejsca, z którego udzielano odpowiedzi DNS, bez wcześniejszego dostosowania informacji o zaufanych kluczach, na podstawie których resolwery oceniają wiarygodność odpowiedzi. Dlatego przed każdym przełączeniem serwerów nazw warto zadać pytanie: Jakie rekordy DS publikuje strefa nadrzędna i czy DNSKEY oraz podpisy strefy docelowej pozwolą je zweryfikować?