Wiszące rekordy DNS: czym są i jak zapobiegać przejęciu subdomeny

„Wiszący” rekord DNS to wpis w systemie DNS, który nadal wskazuje na zasób, który już nie istnieje, na przykład usuniętą usługę w chmurze, wycofany z eksploatacji serwer lub nieaktywną platformę zewnętrzną. Rekord ten nadal jest rozpoznawany, mimo że docelowy zasób już nie istnieje, a właśnie ta rozbieżność stanowi okazję dla atakujących.

Dla zespołów IT i ds. bezpieczeństwa problemem rzadko jest znalezienie pojedynczego uszkodzonego rekordu. Wyzwaniem jest zapewnienie ciągłej widoczności w obrębie domen, subdomen i rekordów uwierzytelniających w miarę zmian zachodzących w infrastrukturze. Każda migracja, zmiana dostawcy i wycofanie usługi z eksploatacji pozostawia po sobie potencjalne problemy.

Czym są zwisające rekordy DNS?

„Wiszący” rekord DNS to wpis DNS, który wskazuje na zasób, który już nie istnieje lub jest niedostępny. Cyberprzestępcy w Internecie nieustannie poszukują takich wpisów DNS, ponieważ narażone są one na wyciek informacji. Niektóre z tych wpisów mogą zawierać poufne informacje dotyczących domeny, stając się dla cyberprzestępców prawdziwą kopalnią danych, z której mogą czerpać korzyści.

Typowe sytuacje prowadzące do powstania „wiszących” rekordów DNS

Błędy w konfiguracji systemu DNS. System nazw domenowych (DNS) jest konfigurowany niezależnie od zasobów internetowych, z którymi chcemy nawiązać połączenie. Rekordy DNS dodane do serwera DNS wskazują na te zasoby, ułatwiając nam dostęp do nich. W niektórych przypadkach wcześniej skonfigurowany zasób może zostać wycofany przez jego dostawcę. Na przykład właściciel domeny skonfigurował rekord DNS tak, aby wskazywał na adres IP serwera. Serwer ten nie jest już jednak używany. Rekord DNS wskazuje obecnie na zasób, który już nie istnieje, i w związku z tym można go określić jako wpis „dangling DNS”.

Wygasłe lub usunięte zasoby w chmurze. Jeśli usługa w chmurze, z której korzysta właściciel domeny, wygaśnie lub zostanie usunięta, każdy rekord DNS wskazujący na tę usługę stanie się wiszącym . Ten wpis DNS pozostaje nadal aktywny, a każdy atakujący może wykorzystać ten zasób do udostępniania złośliwych treści.

Adresy IP wycofane z użytku. Firma może przenieść usługi do nowego dostawcy, a poprzednie adresy IP przestają być używane. Jeśli zespół zapomni zaktualizować lub usunąć stare rekordy DNS, stają się one podatne na przejęcie subdomeny i mogą zostać łatwo wykorzystane.

Wycofanie lub zaprzestanie świadczenia usługi. Serwer poczty elektronicznej, konto hostingowe lub usługa zewnętrznego dostawcy zostaje wycofana lub wyłączona, jednak rekordy DNS, takie jak MX, A i CNAME, pozostają aktywne i skonfigurowane. Atakujący mogą wykorzystać te aktywne, „wiszące” rekordy DNS do podszywania się pod wycofaną usługę.

Które rekordy DNS stają się „wiszącymi” i jakie ryzyko wiąże się z każdym z nich

Luka w zabezpieczeniach wynika z rozbieżności między warstwą DNS a warstwą zasobów. Rekord może być poprawny pod względem składniowym, a mimo to stanowić zagrożenie, jeśli zasób docelowy, do którego się odnosi, nie jest już w posiadaniu właściciela lub nie jest już udostępniony. Poniższa tabela przedstawia tę rozbieżność w podziale na typy rekordów.

Częsty błąd

Traktowanie pomyślnego wyszukiwania DNS jako dowodu, że rekord jest prawidłowy. Rekord „wiszący” rozstrzyga się normalnie, ponieważ sam wpis jest prawidłowy. Liczy się to, czy Twoja organizacja nadal jest właścicielem i sprawuje kontrolę nad miejscem docelowym. Sprawdzanie rozstrzygnięcia bez weryfikacji własności jest powodem, dla którego takie rekordy przechodzą audyty.

Gdzie najczęściej pojawiają się niekompletne rekordy

Niektóre części osiedla dostarczają tych danych znacznie bardziej niezawodnie niż inne. Wiedza o tym, które to są, pozwala przeprowadzać kontrole w oparciu o prawdopodobieństwo, zamiast za każdym razem sprawdzać cały obszar.

• Koszary w chmurze i serwery hostujące strony statyczne: nazwy zasobników są unikalne w skali globalnej i można je dowolnie ponownie rejestrować, więc usunięty zasobnik z aktywnym rekordem CNAME jest jednym z najłatwiejszych celów do przejęcia
• Poddomeny własne w sieciach CDN i usługach SaaS: help.example.com, status.example.com i careers.example.com zazwyczaj kierują do platform zewnętrznych, które zwalniają nazwę hosta w momencie wygaśnięcia subskrypcji
• Narzędzia marketingowe i do tworzenia stron docelowych: poddomeny kampanii są szybko udostępniane przez zespoły spoza działu IT i rzadko wiążą się z procesem wycofywania z eksploatacji
• Środowiska testowe i stagingowe: rekordy dev, uat i staging przetrwają projekty, w ramach których zostały utworzone, i nikt tego nie zauważa, ponieważ żaden rzeczywisty ruch nie jest od nich zależny
• Domeny nabyte lub zależne: odziedziczone strefy zawierają rekordy, których pierwotni właściciele już nie istnieją, a dokumentacja rzadko jest do nich dołączona
• Wycofani dostawcy usług poczty elektronicznej i wsparcia technicznego: Wpisy MX, rekordy CNAME DKIM oraz reguły SPF dla platformy, za którą przestałeś płacić w zeszłym roku

Cechą łączącą te przypadki jest „dryf własnościowy”. Każdy rekord został poprawnie utworzony przez osobę uprawnioną do tego, a następnie przetrwał dłużej niż związek, który uzasadniał jego istnienie. Dlatego też za porządkowanie danych odpowiedzialny jest ten, kto wycofuje usługę, a nie ten, kto zarządza systemem DNS.

Rekordy TXT DMARC

Rekordy DMARC są publikowane jako rekordy TXT i często zawierają adresy docelowe raportów poprzez tagi „rua” i „ruf”. Jeśli adresy te wskazują na nieaktywne lub niemonitorowane skrzynki pocztowe, zespoły tracą wgląd w nieudane próby uwierzytelnienia i próby podszywania się, a błędy nie są w ogóle wykrywane. Sprawdź, w jaki sposób publikujesz rekord DMARC za każdym razem, gdy zmieniają się adresy raportowania lub właściciele.

Rekordy SPF i TXT

Rekordy SPF zawierają listę autoryzowanych usług wysyłających wraz z adresami IP oraz opisują stosowane mechanizmy. Jeśli rekord SPF odwołuje się do wycofanej usługi zewnętrznej lub porzuconej domeny, uwierzytelnianie staje się niewiarygodne, a osoba atakująca, która zarejestruje tę porzuconą domenę dostawcy, przejmuje uprawnienia do wysyłania wiadomości. Wraz ze wzrostem liczby nadawców korzystających z usług SaaS rekordy te przekraczają również limit 10 wyszukiwań DNS, dlatego spłaszczanie SPF pozwala utrzymać je w ramach tego limitu. Dowiedz się więcej o SPF.

Rekordy TLS-RPT

Rekordy TLS-RPT określają, gdzie SMTP TLS powinny być wysyłane. Jeśli miejsce docelowe raportów jest nieaktywne, nieprawidłowo skonfigurowane lub nie jest już monitorowane, zespoły mogą przeoczyć awarie zabezpieczeń transportu, które mają wpływ na dostarczanie zaszyfrowanej poczty. Dowiedz się więcej o TLS-RPT oraz MTA-STS.

Rekordy DKIM CNAME

Rekordy DKIM mogą być publikowane jako rekordy CNAME wskazujące na host DKIM dostawcy usług wysyłkowych. Jeśli konto dostawcy zostanie usunięte lub domena docelowa przestanie być aktywna, podpisywanie i weryfikacja DKIM przestaną działać bez żadnego ostrzeżenia. Na przykład subdomena mail.domain.com jest aliasem dla rekordu CNAME info.domain.com. W związku z tym, gdy serwer wyszukuje adres mail.domain.com, zostanie przekierowany do info.domain.com. Twój system uwierzytelniania DKIM jest często dodawany do systemu DNS jako rekord CNAME.

Uwaga: Rekordy MX, NS, A, AAAA, CNAME i TXT mogą stać się „wiszącymi”, gdy odnoszą się do nieaktywnej infrastruktury, wycofanych usług lub porzuconych dostawców zewnętrznych. Niniejszy artykuł skupia się na rekordach uwierzytelniania poczty elektronicznej, ponieważ właśnie te awarie pozostają niewidoczne najdłużej.

W jaki sposób „dangling DNS” prowadzi do przejęcia subdomeny

Ukryte Luki w zabezpieczeniach DNS , takie jak „dangling DNS”, mogą prowadzić do nadużyć związanych z domenami i zagrożeń cybernetycznych. W sektorach podlegających regulacjom, takich jak finanse, opieka zdrowotna, edukacja, handel detaliczny i sektor publiczny, nierozwiązane problemy związane z DNS i uwierzytelnianiem utrudniają również przeprowadzanie przeglądów bezpieczeństwa i przygotowanie do audytów.

Sam atak przebiega według przewidywalnego schematu, co jest przydatne, ponieważ pokazuje dokładnie, w którym miejscu element sterujący przerywa ten łańcuch.

1. Wykrywanie poddomen. Atakujący skanuje Twoją domenę w poszukiwaniu subdomen, korzystając z publicznych narzędzi DNS, dzienników przejrzystości certyfikatów lub metody wyliczeniowej typu „brute force”.
2. Identyfikacja wiszącego rekordu. Atakujący wykrywa rekord CNAME, A lub MX wskazujący na usługę zewnętrzną, która zwraca komunikat „nie ma takiego konta” lub „niezarejestrowane”.
3. Zajmowanie zasobów. Atakujący rejestruje to samo konto, zasób lub nazwę hosta na platformie zewnętrznej, niezależnie od tego, czy jest to zasób w chmurze, punkt końcowy CDN czy poddomena SaaS.
4. Przejęcie ruchu. Ponieważ Twój rekord DNS nadal wskazuje na tę subdomenę, każde żądanie kierowane do niej jest teraz przekierowywane przez infrastrukturę kontrolowaną przez atakującego.
5. Nadużycie zaufania wynikającego z dziedziczenia. Ta zaufana poddomena wyświetla następnie strony phishingowe, hostuje złośliwe oprogramowanie, kradnie pliki cookie sesji, wysyła sfałszowane wiadomości e-mail lub zbiera dane uwierzytelniające – a wszystko to pod nazwą domeny Twojej organizacji.

Czym jest atak polegający na przejęciu subdomeny?

Gdy osoba atakująca wykryje nieaktualny wpis DNS, który wskazuje na zasób o usuniętej konfiguracji, może przejąć ten porzucony zasób i przekierować ruch przez infrastrukturę, którą kontroluje. Atakujący przejmuje kontrolę nad (pod)domeną, do której wskazuje zawieszony wpis DNS, kierując w ten sposób cały ruch do domeny kontrolowanej przez atakującego, uzyskując pełny dostęp do treści i zasobów tej domeny.

Skala szkód wykracza poza samą zniszczoną stronę. Działania atakujących obejmują kradzież danych uwierzytelniających za pośrednictwem fałszywych stron logowania, złośliwe oprogramowanie umieszczone w zaufanej subdomenie, podszywanie się pod markę w wiadomościach e-mail i w sieci, przechwytywanie plików cookie sesji, nadużycia w zakresie SEO wykorzystujące autorytet domeny, nadużycia związane z dostarczaniem wiadomości e-mail wynikające z nieprawidłowo skonfigurowanych rekordów MX lub SPF, a także utratę reputacji, która ujawnia się później podczas kontroli zgodności.

„Wisząca” nazwa hosta a „wiszący” rekord DNS

Te dwa terminy są ze sobą ściśle powiązane i są używane zamiennie, choć opisują różne zjawiska. „Wiszący” rekord DNS to sam wpis — rekord typu CNAME lub A — który nadal istnieje w pliku strefy, ale wskazuje na usunięty lub nieprzypisany do nikogo zasób. „Wisząca” nazwa hosta to subdomena, której adres docelowy nie jest już kontrolowany przez nikogo w organizacji.

W praktyce to właśnie ten rekord tworzy nazwę hosta. Jeśli adres dev.example.com posiada rekord CNAME wskazujący na wycofane konto hostingowe, wówczas dev.example.com jest „wiszącą” nazwą hosta, a rekord CNAME stanowi „wiszący” rekord stojący za nią. To rozróżnienie ma znaczenie, ponieważ narzędzia skanujące sygnalizują jeden lub drugi problem, podczas gdy oba wymagają tego samego działania naprawczego: należy zweryfikować własność docelowego adresu, a następnie usunąć lub zmienić kierowanie rekordu.

Jak wykrywać nieprzypisane rekordy DNS

Wczesne wykrywanie wpisów DNS, które odsyłają do zasobów, dla których nie przydzielono uprawnień, może pomóc w ochronie Twojej marki. Można to zrobić na dwa sposoby: ręcznie lub automatycznie.

Wykrywanie ręczne

Chociaż audyt ręczny jest czasochłonny, może pomóc w wykryciu nieaktualnych wpisów DNS, zwłaszcza po migracji do chmury, zmianie dostawcy, wycofaniu usługi z eksploatacji lub wdrożeniu nowego nadawcy.

• Sprawdź swoje wpisy DNS: Porównaj wszystkie rekordy DNS w systemie zarządzania DNS z aktywnymi zasobami w Twoim środowisku. Poszukaj wpisów wskazujących na nieistniejące usługi lub adresy IP.
• Sprawdź poprawność konfiguracji DNS: Użyj narzędzi takich jak nslookup lub dig, aby sprawdzić każdy rekord i upewnić się, że odpowiadający mu zasób jest skonfigurowany i aktywny. Sama odpowiedź DNS nie stanowi dowodu bezpieczeństwa, dlatego należy potwierdzić, że docelowy zasób należy do Twojej organizacji i jest przez nią aktywnie zarządzany.
• Sprawdź, czy nie ma usług osieroconych: Sprawdź usługi, takie jak hosting zewnętrzny, platformy chmurowe lub dostawcy CDN, które mogły zostać wyłączone bez usunięcia powiązanych wpisów DNS.

W celu weryfikacji poszczególnych rekordów można również sprawdzić każdy wpis za pomocą narzędzia do sprawdzania rekordów DNS , aby sprawdzić, do jakiego adresu obecnie prowadzi, zanim zdecydujesz, czy go zachować.

Dlaczego ręczne wykrywanie zawodzi w przypadku dużych zbiorów danych

Chociaż metody ręczne są dokładne, są podatne na błędy ludzkie i mogą stać się niemożliwe do opanowania w przypadku domen o rozbudowanych lub złożonych konfiguracjach DNS. Istnieje kilka czynników, które sprawiają, że stają się one zawodne na długo przed tym, zanim strefa osiągnie duże rozmiary.

• Zdecentralizowane zarządzanie systemem DNS w ramach różnych zespołów i działów
• Zapomniane środowiska testowe i przejściowe, w których nadal znajdują się aktywne wpisy DNS
• „Shadow IT” oraz nie monitorowane integracje z usługami SaaS innych dostawców
• Wygasłe zasoby w chmurze, które nigdy nie zostały objęte formalnym procesem wycofania z eksploatacji
• Wiele stref DNS odzyskanych w wyniku przejęć lub domen spółek zależnych
• Niewiele informacji na temat przestarzałej infrastruktury, za którą obecnie nikt nie ponosi odpowiedzialności

Automatyczne wykrywanie

Zautomatyzowane monitorowanie staje się konieczne, gdy domeny, subdomeny, nadawcy i usługi w chmurze zmieniają się szybciej niż trwa cykl audytowy. Zamiast okresowych kontroli scentralizowana platforma na bieżąco wykrywa nieaktywne rekordy, nieprawidłowe konfiguracje uwierzytelniania oraz podejrzane zmiany w całym portfolio.

Praktyczną korzyścią jest raczej oszczędność czasu niż dokładność. Audyt przeprowadzany co kwartał w końcu wykryje ten sam błąd, ale nastąpi to dopiero po upływie kwartału, w którym istniało ryzyko. Ciągłe monitorowanie eliminuje ten okres między wycofaniem usługi a kolejną kontrolą, a właśnie w tym przedziale faktycznie tkwi ryzyko przejęcia.

Jak naprawić nieprzypisane rekordy DNS

Po zidentyfikowaniu „wiszącego” rekordu kolejność czynności ma znaczenie. Usunięcie rekordu przed odzyskaniem zasobu może spowodować powstanie luki, a pominięcie etapu TTL oznacza, że propagacja poprawki potrwa godziny zamiast minut.

1. Zidentyfikuj rekord i jego adres docelowy. Skorzystaj z narzędzi DNS lub platformy monitorującej, aby zlokalizować konkretny wpis i sprawdzić, do czego obecnie prowadzi.
2. Sprawdź, czy jesteś właścicielem docelowego obiektu. Sprawdź, czy Twoja organizacja nadal kontroluje miejsce docelowe, wysyłając zapytanie do dostawcy lub rejestru kont.
3. Najpierw zmniejsz wartość TTL. Przed wprowadzeniem zmian zmniejsz tę wartość do zakresu od 60 do 300 sekund, aby aktualizacje były szybko propagowane po podjęciu działań.
4. Odzyskaj zasób, jeśli można go przejąć. Jeśli celem jest nieprzypisany zasób w chmurze lub punkt końcowy CDN, należy go przypisać przed wprowadzeniem zmian w DNS, aby zamknąć okno przejęcia.
5. Usuń rekord lub zmień jego odnośnik. Usuń go, jeśli usługa została wycofana. Jeśli musi pozostać aktywny, skieruj go na zasób, który obecnie posiadasz i który został przez Ciebie udostępniony.
6. Sprawdź poprawność propagacji. Użyj polecenia dig lub nslookup, aby sprawdzić, czy rekord jest poprawnie rozpoznawany, a stary adres docelowy już nie odpowiada.
7. Zarejestruj tę zmianę. Zapisz, co uległo zmianie, dlaczego, kiedy i przez kogo, a następnie zaktualizuj spis zasobów DNS i przypisz stałą odpowiedzialność za te zasoby.

Jak zapobiegać przejęciu subdomeny spowodowanemu nieaktualnymi wpisami DNS

Zapobieganie łączy w sobie dbanie o porządek w systemie DNS z ciągłym monitorowaniem. Poniższe środki kontroli mają największe znaczenie dla zespołów IT, zespołów ds. bezpieczeństwa oraz dostawców usług zarządzanych (MSP) zarządzających wieloma domenami.

• Należy natychmiast usunąć nieużywane wpisy DNS: usuń rekordy CNAME, A, AAAA, MX i TXT po wycofaniu usług, zamiast pozostawiać je na wszelki wypadek
• Przed skonfigurowaniem odnośników do zasobów stron trzecich należy je zweryfikować: najpierw upewnij się, że zasoby w chmurze, CDN, poczty e-mail i hostingu są aktywne i należą do Twojej organizacji
• Monitoruj rekordy uwierzytelniania poczty elektronicznej: regularnie sprawdzaj DMARC, SPF, DKIM, MTA-STS, TLS-RPT i BIMI pod kątem nieaktywnych lub nieprawidłowych odniesień
• Własność dokumentów: prowadź wykaz domen, subdomen, nadawców i właścicieli usług, podając imię i nazwisko właściciela w każdym wpisie
• Włączenie czyszczenia DNS do procesu wycofywania z eksploatacji: usunięcie rekordów powinno być obowiązkowym etapem w przypadku wycofania z eksploatacji usługi w chmurze, platformy SaaS lub konta hostingowego
• Skonfiguruj automatyczne powiadomienia: monitoruj osierocone usługi, odchylenia DNS oraz nowe subdomeny pojawiające się w Twojej strefie
• Przeprowadzaj cykliczne audyty higieny: co miesiąc lub co kwartał, w zależności od stopnia złożoności, oraz bezpośrednio po każdej migracji, zmianie dostawcy lub nabyciu domeny

Co zrobić ze starymi lub nieużywanymi subdomenami

Gdy poddomena przestaje być potrzebna, zazwyczaj dochodzi do jednego z pięciu możliwych scenariuszy.

• Usuń rekord, gdy subdomena nie ma już uzasadnienia biznesowego
• Przywróć porzucony zasób zewnętrzny, gdy subdomena musi pozostać aktywna, a konto nadal można przejąć
• Parkuj bezpiecznie kierując go do kontrolowanego zasobu wewnętrznego, a nigdy do platformy zewnętrznej, gdy musi on przeprowadzić rozpoznanie adresu, ale nie udostępnia żadnych treści
• Przekierowanie tylko wtedy, gdy istnieje ku temu uzasadnienie biznesowe, oraz upewnij się, że strona docelowa jest własnością firmy i jest aktywna
• Dokument należy udokumentować każdą decyzję i wyznaczyć osobę odpowiedzialną przed wycofaniem czegokolwiek z eksploatacji

Jak pomaga PowerDMARC

PowerDMARC centralizuje monitorowanie uwierzytelniania domen i poczty elektronicznej, dzięki czemu zespoły mogą wykrywać problemy związane z protokołami DMARC, SPF, DKIM, MTA-STS, TLS-RPT i BIMI bez konieczności ręcznego sprawdzania każdego rekordu DNS. Celem nie jest znalezienie pojedynczego nieprawidłowego rekordu. Chodzi o zapewnienie ciągłej widoczności każdej domeny, subdomeny i rekordu uwierzytelniającego, które mają wpływ na stan bezpieczeństwa.

• Scentralizowany pulpit nawigacyjny: domeny, subdomeny i status uwierzytelnienia widoczne w jednym miejscu
• Szybkie wykrywanie problemów: błędy konfiguracji są wykrywane, zanim wpłyną na bezpieczeństwo lub dostarczalność
• Zautomatyzowane zarządzanie SPF: mniej nieudanych wyszukiwań i bardziej przejrzyste źródła wysyłki w miarę zmian platform SaaS
• Gotowość do zapewnienia zgodności z przepisami: wsparcie w przygotowaniu do audytu dla zespołów z branży finansowej, opieki zdrowotnej, edukacji, handlu detalicznego oraz sektora publicznego
• Wsparcie ekspertów: globalne wsparcie pomagające w szybkim zbadaniu, weryfikacji i usunięciu ryzykownych wpisów

Dla dostawców usług scentralizowane grupowanie domen oraz dostęp oparty na rolach umożliwiają praktyczne monitorowanie wielu środowisk klientów jednocześnie. Programy Programy MSP i MSSP zostały opracowane z myślą o tym przebiegu pracy.

Jeśli chcesz szybko sprawdzić, jak wygląda Twoja obecna postawa, sprawdź swoją domenę za pomocą bezpłatnego narzędzia analitycznego. Wpisz swoją domenę, kliknij „Sprawdź teraz”, a zobaczysz konfiguracje rekordów DNS, wykryte błędy konfiguracji oraz praktyczne wskazówki dotyczące ich usunięcia.

Najczęściej zadawane pytania

Obejmują one kwestie operacyjne, które pojawiają się po ustaleniu koncepcji.

Jak naprawić niepoprawne rekordy DNS?

Zidentyfikuj nieaktualny wpis, sprawdź, czy Twoja organizacja nadal jest właścicielem obiektu docelowego, a następnie skróć czas TTL. Jeśli zasób można przejąć, najpierw go przejmij, następnie usuń wpis lub zmień jego odniesienie, sprawdź propagację za pomocą polecenia `dig` i udokumentuj zmianę.

Czym jest „dangling hostname”?

Poddomena, która prowadzi do miejsca docelowego, nad którym właściciel domeny nie ma już kontroli. Powoduje to istnienie „wiszącego” rekordu DNS. Jeśli adres dev.example.com wskazuje na wyłączone konto w chmurze, jest to „wisząca” nazwa hosta.

Czy nieprzypisane rekordy DNS mogą wpływać na bezpieczeństwo poczty elektronicznej?

Tak. Rekordy DMARC, SPF, DKIM, MTA-STS i TLS-RPT stają się nieaktywne, gdy odwołują się do nieaktywnych domen, wycofanych nadawców lub niemonitorowanych skrzynek raportujących. Skutkiem tego są błędy uwierzytelniania oraz niewidoczne luki w widoczności.

Jak często organizacje powinny przeprowadzać audyt rekordów DNS?

Po każdym wycofaniu usługi, migracji dostawcy, przejęciu domeny lub zmianie nadawcy. Należy wprowadzić cykliczne audyty – miesięczne lub kwartalne, w zależności od stopnia złożoności – oraz ciągłe monitorowanie w celu wykrywania odchyleń występujących w międzyczasie.

Czy brakujący rekord zawsze oznacza, że subdomenę można przejąć?

Nie. Przejęcie wymaga, aby docelowy zasób mógł zostać przejęty przez kogoś innego, co często ma miejsce w przypadku zasobników w chmurze, punktów końcowych CDN oraz subdomen SaaS. Rekord wskazujący na nieaktywny adres IP nadal powoduje przerwy w działaniu i stwarza ryzyko przechwycenia danych.

Kto powinien być odpowiedzialny za porządkowanie rekordów DNS w firmie?

Odpowiedzialność za wycofanie usługi spoczywa na jej właścicielu, a nie wyłącznie na administratorze DNS. Rekordy tracą aktualność w momencie wycofania usługi, dlatego ich usunięcie powinno znaleźć się na liście czynności związanych z wycofaniem usługi, a nie stanowić odrębnego przeglądu DNS.

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty elektronicznej w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• Przewodnik po konfiguracji DKIM, DMARC i SPF firmy Network Solutions – 2 września 2026 r.
• Przewodnik po uwierzytelnianiu wiadomości e-mail serwisu Simply.com: SPF, DKIM i DMARC – 1 września 2026 r.
• Przewodnik po uwierzytelnianiu w usługach QQ Mail i Tencent Enterprise Mail: SPF, DKIM i DMARC – 1 września 2026 r.