DNS jest często traktowany jak ustawienie, które raz wpisuje się w panelu i później o nim zapomina. W firmie to jednak wspólna warstwa dla strony, aplikacji, poczty, certyfikatów, weryfikacji usług i części kontroli bezpieczeństwa. Audyt DNS nie powinien więc polegać na odhaczeniu, że rekord A istnieje. Trzeba sprawdzić, czy odpowiedzi prowadzą do właściwych usług, czy delegacja jest kontrolowana, czy rekordy pocztowe mają sens i czy zmiany odpowiadają zatwierdzonej architekturze.
Najcenniejszy audyt jest powtarzalny. Wykonujesz go przed migracją, po migracji, po zmianie dostawcy poczty i po wdrożeniu nowej subdomeny. Każdy wynik ma czas obserwacji, źródło, oczekiwany stan i właściciela. Dzięki temu DNS przestaje być zbiorem rekordów zrozumiałych tylko dla jednej osoby. Staje się kontrolowaną powierzchnią, na której można wykryć drift, niepotrzebne zależności i sygnały wymagające eskalacji.
Ustal zakres i mapę usług
Zanim uruchomisz zapytania, spisz nazwy, które mają znaczenie dla biznesu: domenę główną, www, pocztę, logowanie, API, panel administracyjny, strony kampanii i nazwy używane w integracjach. Przy każdej nazwie dopisz usługę docelową, zespół właścicielski, środowisko oraz spodziewany typ rekordu. Jeżeli rekord jest częścią walidacji certyfikatu lub narzędzia SaaS, zapisz także powód jego istnienia. Rekord bez właściciela jest dobrym kandydatem do wyjaśnienia, ale nie do natychmiastowego usunięcia.
- A i AAAA: czy ruch trafia do właściwej usługi IPv4 i IPv6?
- CNAME: czy alias wskazuje na zatwierdzoną nazwę i nie tworzy pętli?
- MX, SPF, DKIM i DMARC: czy poczta ma pełną, spójną ścieżkę?
- NS, DS i CAA: kto jest autorytatywny i kto może wystawić certyfikat?
- TXT: czy weryfikacje są nadal potrzebne i przypisane do aktualnego dostawcy?
Sprawdź delegację przed rekordami
Rekord w panelu dostawcy nie jest jeszcze dowodem, że Internet otrzymuje tę wartość. Najpierw sprawdź, które serwery nazw są autorytatywne dla domeny i czy odpowiadają zgodnie z planem. Podczas migracji częsty błąd polega na edycji starej strefy, gdy delegacja wskazuje już nową, albo na pozostawieniu części serwerów z innym zestawem rekordów. Odpowiedzi niezgodne między serwerami mogą powodować objawy zależne od resolvera, regionu i czasu cache.
Sprawdź również SOA, serial i minimalny TTL, ale nie wyciągaj z nich zbyt daleko idących wniosków. TTL mówi o oczekiwanym czasie przechowywania odpowiedzi w cache, nie gwarantuje natychmiastowej zmiany ani nie zastępuje planu wdrożenia. Zapisz moment wykonania testu i ponów go po czasie odpowiednim dla danej migracji. Wnioski powinny rozróżniać brak aktualizacji, niespójną delegację i zwykłą widoczność starej odpowiedzi w cache.
Oceń integralność i bezpieczeństwo DNS
DNSSEC pomaga odbiorcy zweryfikować, czy odpowiedź DNS pochodzi z podpisanej ścieżki i nie została po drodze zmieniona. NASK opisuje DNSSEC jako zestaw rozszerzeń zwiększających wiarygodność i integralność odpowiedzi. W audycie sprawdź stan delegacji, rekord DS oraz możliwość poprawnej walidacji. Pamiętaj, że błędne DNSSEC może sprawić, że poprawna usługa przestanie być dostępna dla resolverów walidujących. Zmiana kluczy wymaga więc własnej procedury, a nie tylko kliknięcia w panelu.
Rekord CAA ogranicza, które urzędy certyfikacji mogą wystawiać certyfikaty dla domeny, ale powinien odpowiadać realnym procesom. Zbyt restrykcyjny wpis może przerwać automatyczne odnowienie, a zbyt szeroki nie daje oczekiwanej kontroli. Podobnie rekord TXT używany przez usługę zewnętrzną powinien mieć opis właściciela i datę przeglądu. Audyt nie polega na usuwaniu wszystkiego, co wygląda obco, lecz na zrozumieniu funkcji każdego elementu.
Zbadaj pocztę jako osobny łańcuch
Problemy z pocztą często wynikają z poprawnych technicznie rekordów użytych w złym zestawieniu. Sprawdź, czy MX wskazuje na aktualne serwery, SPF obejmuje wszystkie uprawnione źródła bez niepotrzebnych include, klucze DKIM są publikowane pod właściwymi selektorami, a DMARC ma politykę i skrzynkę raportową, którą ktoś obsługuje. Subdomena wysyłająca pocztę może potrzebować własnego SPF i DKIM. Nie zakładaj, że polityka domeny głównej wyjaśnia każdy przypadek.
Porównaj konfigurację z ruchem i architekturą
Rekordy DNS trzeba odczytać w kontekście usługi. Adres A może należeć do starego środowiska, CNAME do wycofanego dostawcy, a TXT do kampanii sprzed dwóch lat. Zestaw bieżące odpowiedzi z dokumentacją, certyfikatami i obserwowanymi przekierowaniami. Jeśli nie masz dokumentacji, oznacz hipotezę i poproś właściciela usługi o potwierdzenie. Unikaj stwierdzenia „rekord jest zły” tylko dlatego, że nie pasuje do Twojego modelu. Najpierw ustal, jaki model powinien obowiązywać.
Wykorzystaj historię do wykrywania driftu
Jednorazowy audyt pokazuje stan, a historia pokazuje zmianę. Zwróć uwagę na przełączenia NS, nowe adresy A, usunięte MX, nowe rekordy TXT i pojawienie się subdomen powiązanych z certyfikatami. Porównanie nie mówi samo z siebie, czy zmiana była złośliwa. Daje jednak czas, wartość poprzednią i punkt wyjścia do rozmowy z właścicielem. Zmiany bez zadania lub okna wdrożeniowego powinny mieć wyższy priorytet niż różnice zatwierdzone w planie migracji.
- Zachowaj snapshot przed zmianą i po jej zakończeniu.
- Porównaj odpowiedzi wszystkich autorytatywnych serwerów nazw.
- Zweryfikuj widoczność przez kilka resolverów, uwzględniając TTL.
- Zamknij audyt dopiero po potwierdzeniu usługi, poczty i certyfikatów.
Zdefiniuj wynik audytu
Raport powinien jasno rozdzielać błąd, ostrzeżenie, informację i stan nieznany. Błąd to na przykład niespójna delegacja uniemożliwiająca działanie krytycznej usługi. Ostrzeżenie może oznaczać rekord bez właściciela albo brak DNSSEC w domenie, która nie ma jeszcze takiego wymagania. Stan nieznany pojawia się, gdy odpowiedź jest zablokowana, niepełna lub sprzeczna. Takie rozróżnienie jest ważniejsze niż jeden wynik punktowy, bo pomaga podjąć właściwą decyzję i nie tworzyć fałszywego poczucia bezpieczeństwa.
Dla kilku domen audyt można wykonywać ręcznie według stałej checklisty. Przy większym portfelu warto pobierać dane przez API, zapisywać snapshoty i kierować różnice do procesu zmian. Automatyzacja powinna przechowywać nie tylko wynik, lecz także źródło, czas, typ rekordu i poziom pewności. Wtedy człowiek może szybko zweryfikować alert bez powtarzania całego dochodzenia od zera.
Najlepszy audyt DNS nie pyta wyłącznie, czy rekord istnieje. Pyta, czy odpowiada usłudze, właścicielowi i zatwierdzonej zmianie.
Praktyka kontroli DNS
Przejdź przez audyt po migracji krok po kroku
Przed migracją wykonaj snapshot wszystkich rekordów, delegacji i certyfikatów, a następnie oznacz go numerem zmiany. W oknie wdrożeniowym sprawdzaj najpierw serwery nazw, potem rekordy główne, pocztę, walidację certyfikatu i odpowiedzi aplikacji. Po propagacji wykonaj test z kilku resolverów i porównaj stan z planem. Jeżeli część odbiorców widzi starą odpowiedź, nie oznacza to od razu nieudanego wdrożenia. Zapisz TTL, czas obserwacji i zakres różnicy, aby decyzja była oparta na faktach.
Po zmianie dostawcy DNS przejrzyj rekordy, które nie należały do głównej aplikacji: walidacje, systemy pocztowe, narzędzia analityczne, integracje płatnicze i środowiska testowe. To one najczęściej ujawniają się dopiero po kilku godzinach. Nie kopiuj całej starej strefy bez analizy, ale też nie usuwaj jej hurtowo. Każdy rekord powinien mieć właściciela, termin przeglądu i decyzję: zachować, zmienić, usunąć albo potwierdzić jako nieznany.
Odróżnij awarię DNS od awarii usługi
Jeśli strona nie działa, sprawdź osobno rozwiązywanie nazwy, połączenie do adresu, TLS, kod HTTP i odpowiedź aplikacji. Poprawne DNS nie gwarantuje działającego serwera, a działający serwer nie naprawi złej delegacji. Przy poczcie sprawdź MX i polityki uwierzytelniania, ale nie wyciągaj wniosku o dostarczalności z samego istnienia rekordu. Ta segmentacja skraca dochodzenie i pozwala skierować sprawę do właściwego zespołu zamiast zmieniać DNS na ślepo.
- DNS: nazwa rozwiązuje się do oczekiwanego rekordu.
- Transport: adres odpowiada na właściwym porcie i ma oczekiwany certyfikat.
- HTTP: przekierowanie i kod odpowiedzi są zgodne z architekturą.
- Aplikacja: usługa działa, ale jej błąd nie powinien być naprawiany rekordem DNS.
Przy dużej liczbie domen utrzymuj osobne reguły dla produkcji, poczty, marketingu i testów. Automatyczne porównanie może wykrywać różnice, lecz nie powinno samodzielnie usuwać rekordu ani przełączać delegacji. Jeżeli narzędzie nie ma odpowiedzi z jednego resolvera, oznacz stan unknown i ponów kontrolę według budżetu. Dokumentuj także fałszywe alarmy. Ich wzorzec może wskazywać, że próg, TTL albo model oczekiwanego stanu wymaga poprawy.
Zamknij audyt dowodem i właścicielem
Każdy finding powinien mieć nazwę domeny, typ rekordu, zaobserwowaną wartość, oczekiwany stan, źródło, czas i osobę odpowiedzialną. Dodaj rekomendację, termin oraz kryterium zamknięcia. „Naprawić DNS” nie jest kryterium. Lepsze jest „serwery nazw odpowiadają zgodnie z planem, rekord MX wskazuje na aktualną usługę, a kontrola z dwóch resolverów potwierdza stan”. Taki format pozwala audytorowi wrócić do dowodu po wdrożeniu i nie opierać się na deklaracji w komentarzu.
Po zakończeniu poproś właściciela usługi o potwierdzenie działania z perspektywy użytkownika. Dla strony sprawdź główną nazwę i www, dla API punkt wejścia używany przez klienta, a dla poczty wysyłkę i odbiór w kontrolowanym scenariuszu. Jeśli zmiana nie jest możliwa od razu, oznacz ryzyko zaakceptowane, wpisz datę przeglądu i wskaż kompensację. Audyt ma pomagać w decyzji, a nie tylko tworzyć listę technicznych uwag.
- Dowód: co, kiedy i z którego źródła zaobserwowano.
- Oczekiwanie: jaki stan wynika z architektury lub zatwierdzonej zmiany.
- Właściciel: kto potwierdza funkcję i decyduje o remediacji.
- Zamknięcie: jaki ponowny test potwierdzi rozwiązanie.
- Ryzyko: co pozostaje nieznane lub zaakceptowane po terminie.
Po audycie uporządkuj również dokumentację zmian. Właściciel powinien móc odtworzyć, dlaczego rekord dodano, jakie systemy go używają i kiedy nastąpi kolejna weryfikacja. Jeśli decyzja jest niepewna, wpisz ją jako obserwację do wyjaśnienia, a nie jako zaakceptowaną prawdę. Dzięki temu kolejny audyt zaczyna się od aktualnego modelu i historii, zamiast od ponownego zgadywania, które rekordy są ważne.
W praktyce warto zaplanować audyt również po zmianie właściciela domeny, nie tylko po migracji DNS. Nowa osoba może nie znać starych rekordów, a poprzedni dostawca może nadal pozostawić usługę walidacyjną. Porównaj delegację, rekordy pocztowe, CAA i certyfikaty z zaakceptowanym baseline, a różnice przypisz do konkretnego właściciela. Jeżeli nie da się potwierdzić funkcji wpisu, oznacz go jako unknown z terminem wyjaśnienia. Takie podejście ogranicza zarówno przypadkowe usunięcie zależności, jak i utrzymywanie niepotrzebnego dostępu.
Właściciel powinien także opisać, kiedy wynik audytu traci aktualność. Zmiana rejestratora, dostawcy poczty, certyfikatu lub aplikacji powinna uruchamiać nową kontrolę. Dzięki temu raport nie pozostaje formalnością, a zespół wie, kiedy ponownie potwierdzić rekordy, delegację i DNSSEC. Krótka data przeglądu przy każdym findingu jest prostym sposobem na ograniczenie driftu.
Audyt DNS firmy łączy technikę z odpowiedzialnością. Delegacja, rekordy, DNSSEC, poczta, certyfikaty i historia są wartościowe dopiero wtedy, gdy można je odnieść do realnej usługi. Uporządkowany proces ogranicza ryzyko awarii po migracji, ułatwia reakcję na nieautoryzowaną zmianę i sprawia, że wiedza o domenie nie znika wraz z odejściem jednej osoby.