Kluczowe wnioski
- W dokumencie NIST SP 800-81r3 system DNS został formalnie przeklasyfikowany z pasywnej infrastruktury sieciowej do aktywnej, dynamicznej warstwy zapewniającej bezpieczeństwo.
- W ramach tej aktualizacji wprowadzono technologię Protective DNS (PDNS), która przekształca serwery rozpoznające nazwy z biernych narzędzi do wysyłania zapytań w aktywne filtry zdolne do blokowania zagrożeń, takich jak domeny podszywające się pod inne.
- Protokoły takie jak SPF, DKIM i DMARC są publikowane wyłącznie w postaci rekordów TXT w systemie DNS; jeśli Twój system DNS nie jest zabezpieczony, uwierzytelnianie Twojej poczty elektronicznej może zostać łatwo naruszone.
- Wdrożenie egzekwowania DMARC bez zastosowania rozszerzeń bezpieczeństwa DNS (DNSSEC) naraża Twoje zasady na ataki typu „zatrucie pamięci podręcznej DNS” oraz manipulację danymi podczas przesyłania.
- Bezpośrednie fałszowanie adresów jest blokowane przez DMARC, jednak ataki z wykorzystaniem domen podobnych (typosquatting) wymagają zastosowania PDNS oraz proaktywnej higieny DNS, aby wykrywać zagrożenia, zanim użytkownicy wejdą z nimi w interakcję.
Według singapurskiej policji w kwietniu 2026 r. firma zajmująca się handlem surowcami z siedzibą w Singapurze przelała 6,6 mln USD na fałszywe konto bankowe w Omanie. Przyczyną nie było wyrafinowane włamanie do sieci ani bezpośredni atak hakerski. Zamiast tego sprawcy wykorzystali klasyczny trik polegający na typosquattingu i wysłali e-maile z domeny, w której zamieniono miejsca tylko dwóch liter. Sfałszowany adres wyglądał praktycznie identycznie jak adres prawdziwego dostawcy tej firmy.
Ten katastrofalny incydent pokazuje, dlaczego traktowanie systemu nazw domenowych (DNS) jako biernej infrastruktury stanowi ogromne zagrożenie dla bezpieczeństwa. Aby wyeliminować właśnie te luki, Narodowy Instytut Standardów i Technologii (NIST) sfinalizował 19 marca 2026 r. dokument NIST SP 800-81r3. Wydanie to stanowi pierwszą od 13 lat znaczącą aktualizację federalnych wytycznych NIST dotyczących bezpieczeństwa DNS, oficjalnie przenosząc DNS z roli tła infrastruktury sieciowej do roli aktywnego, pierwszoplanowego mechanizmu kontroli bezpieczeństwa. Dla zespołów IT i ds. bezpieczeństwa zarządzających uwierzytelnianiem poczty elektronicznej oznacza to znaczącą zmianę w podejściu do obsługi systemu DNS.
Czym jest norma NIST SP 800-81r3?
Publikacja specjalna NIST (SP) 800-81 stanowi ostateczny standard odniesienia w zakresie bezpiecznego wdrażania systemu DNS. Poprzednia wersja, rewizja 2, została opublikowana w 2013 roku. W ciągu ostatnich 13 lat środowisko technologiczne przedsiębiorstw uległo całkowitej przemianie wraz z rozwojem architektury chmurowej, powszechnym rozprzestrzenianiem się oprogramowania ransomware, protokołów szyfrowanych oraz modeli „Zero Trust”.
Niedawno sfinalizowane wytyczne NIST SP 800-81r3, opracowane przez Scotta Rose’a z NIST we współpracy z ekspertami firmy Infoblox – Cricketem Liu i Rossem Gibsonem – stanowią unowocześnienie dotychczasowych wytycznych. Chociaż przestrzeganie tych wytycznych jest bezwzględnie obowiązkowe dla amerykańskich agencji federalnych w celu spełnienia wymogów współczesnych rozporządzeń wykonawczych dotyczących cyberbezpieczeństwa, stanowią one również punkt odniesienia na arenie międzynarodowej. Na przykład organizacje europejskie mogą traktować je jako podstawowy standard techniczny w ramach dyrektywy UE NIS2 (Network and Information Security 2).
NIST SP 800-81r3: Strategia dotycząca architektury podstawowej
Trzy filary, które pozwalają spojrzeć na system DNS z nowej perspektywy jako na aktywny mechanizm zabezpieczający
| Filar 1: Proaktywne egzekwowanie zasad bezpieczeństwa | Filar 2: Zabezpieczanie protokołów | Filar 3: Ochrona infrastruktury |
|---|---|---|
| Aktywne blokowanie zagrożeń Filtrowanie zapytań i rejestrowanie zdarzeń | Podpisywanie DNSSEC Szyfrowane transmisje DNS | Zabezpieczanie serwerów Kontrola dostępu |
Podstawowa zmiana wprowadzona w tej aktualizacji jest prosta: DNS nie jest już usługą typu „ustaw i zapomnij”. Nowoczesna architektura wymaga od organizacji traktowania DNS jako dynamicznego punktu egzekwowania zabezpieczeń, który musi aktywnie blokować zagrożenia, dostarczać dane telemetryczne do działu bezpieczeństwa oraz podlegać ciągłemu audytowi.
Pięć najważniejszych zmian w normie SP 800-81r3

1. Ochronny system DNS – od pasywnego serwera rozpoznającego do aktywnego filtra
Najważniejszą zmianą koncepcyjną w nowych wytycznych jest formalne wprowadzenie ochronnego systemu DNS (PDNS). Usługa ochronnego systemu DNS pełni rolę aktywnego filtra bezpieczeństwa, a nie jedynie podstawowego narzędzia do wyszukiwania w katalogu. Analizuje ona wszystkie wychodzące zapytania DNS, porównuje je z danymi z baz informacji o zagrożeniach i blokuje połączenia ze znanymi złośliwymi domenami lub infrastrukturą phishingową.
- Elastyczność wdrożenia: NIST zaleca model infrastruktury hybrydowej i dąży do połączenia skalowalnych rozwiązań PDNS opartych na chmurze z lokalnymi zaporami DNS pełniącymi rolę rezerwową, co ma zapewnić odporność systemu.
- Proaktywne ograniczanie zagrożeń: System PDNS aktywnie ogranicza ryzyko, uniemożliwiając użytkownikom i urządzeniom łączenie się z niebezpiecznymi serwerami.
- Zapobieganie oszustwom z wykorzystaniem domen o podobnej nazwie: W kontekście singapurskiej sprawy dotyczącej ataków typu „business email compromise” (BEC) aktywna warstwa PDNS może całkowicie zablokować rozpoznawanie nowo zarejestrowanych domen o podobnej nazwie.
2. Szyfrowane DNS – DoT, DoH i DoQ
Tradycyjne zapytania DNS są przesyłane przez Internet w postaci zwykłego tekstu, co umożliwia atakującym przechwytywanie ruchu sieciowego i identyfikowanie wewnętrznych zasobów organizacji lub jej zewnętrznych partnerów. Zaktualizowane wytyczne oficjalnie zalecają stosowanie szyfrowanych protokołów DNS w celu ochrony poufności zapytań.
- Obsługiwane protokoły: Aktualizacja standaryzuje protokoły DNS over Transport Layer Security (DoT), DNS over HTTPS (DoH) oraz DNS over QUIC (DoQ).
- Ochrona przed podsłuchem: Szyfrowanie tych kanałów uniemożliwia zewnętrznym podmiotom stanowiącym zagrożenie podsłuchiwanie żądań systemowych.
- Blok rozpoznawczy: Uniemożliwia on atakującym przechwytywanie zapytań dotyczących bezpieczeństwa wychodzących wiadomości e-mail, które często wykorzystują do mapowania sieci docelowych przed rozpoczęciem kampanii typu spear-phishing.
3. System DNS jako punkt egzekwowania zasad modelu „zero trust”
W architekturze Zero Trust żaden użytkownik ani urządzenie nie są domyślnie uznawane za zaufane, a każde żądanie dostępu musi zostać wyraźnie zweryfikowane. Nowe wytyczne nadają systemowi DNS status kluczowego punktu egzekwowania zasad (PEP) w modelu Zero Trust.
- Zabezpieczenia przed nawiązaniem połączenia: Ponieważ rozpoznawanie nazw DNS odbywa się przed nawiązaniem jakiegokolwiek połączenia sieciowego, stanowi to najwcześniejszy możliwy poziom blokowania nieautoryzowanej komunikacji.
- Informacje kontekstowe: Dane z zapytań dostarczają kluczowych informacji kontekstowych, które pozwalają zespołom ds. bezpieczeństwa analizować zachowanie urządzeń na podstawie domen, z którymi próbują się połączyć.
- Izolacja infrastruktury: Jeśli system próbuje nawiązać połączenie ze znanym złośliwym serwerem dowodzenia i kontroli, warstwa DNS oznaczy urządzenie i natychmiast przerwie komunikację.
4. Lepsze wdrożenie protokołu DNSSEC
DNSSEC chroni integralność danych DNS poprzez dodawanie podpisów kryptograficznych do rekordów. Zaktualizowana wersja zawiera kluczowe zmiany, które zwiększają bezpieczeństwo i wydajność DNSSEC.
- Nowoczesna kryptografia: NIST zwraca uwagę na kwestie związane z nowoczesnymi algorytmami DNSSEC i zauważa, że algorytmy takie jak ECDSA i Ed448 są w wielu wdrożeniach preferowane w stosunku do RSA, ponieważ generują mniejsze klucze i podpisy.
- Minimalizacja długości QNAME: Serwery rozpoznające nazwy wysyłają teraz w górę łańcucha wyszukiwania jedynie niezbędną część zapytania o nazwę domeny.
- Kompaktowe odrzucenie istnienia: Ta funkcja ogranicza ilość informacji strukturalnych ujawnianych atakującym w sytuacji, gdy serwer zwraca odpowiedź NXDOMAIN (domena nie istnieje).
5. Rejestrowanie danych DNS, integracja z systemem SIEM oraz zakres OT/IoT
Ostatnia duża aktualizacja skupia się przede wszystkim na widoczności oraz rozszerzeniu zakresu zabezpieczeń na środowiska nietradycyjne.
- Przekazywanie danych do systemu SIEM: Wiarygodne i rekurencyjne logi DNS muszą być przekazywane bezpośrednio do systemów zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM).
- Korelacja adresów IP: Organizacje muszą porównać logi DNS z danymi dotyczącymi dzierżaw protokołu DHCP (Dynamic Host Configuration Protocol), aby precyzyjnie powiązać złośliwe zapytania z konkretnymi urządzeniami fizycznymi.
- Zakres dotyczący technologii operacyjnej (OT) i Internetu rzeczy (IoT): W ramach tych wytycznych wprowadzono jasno określone wymagania bezpieczeństwa dostosowane do urządzeń technologii operacyjnej (OT) i Internetu rzeczy (IoT), które często nie posiadają wbudowanych funkcji zabezpieczających.
Dlaczego norma SP 800-81r3 ma znaczenie dla protokołów DMARC, SPF i DKIM
Jeśli kierujesz działem IT, być może postrzegasz bezpieczeństwo poczty elektronicznej i bezpieczeństwo DNS jako całkowicie odrębne projekty. To niebezpieczny błąd. W rzeczywistości stabilność całego systemu uwierzytelniania poczty elektronicznej zależy wyłącznie od stabilności infrastruktury DNS, na której jest on oparty.
SPF, DKIM i DMARC to rekordy DNS
Każdy protokół uwierzytelniania poczty elektronicznej opiera się całkowicie na katalogu DNS. Gdy zdalny serwer pocztowy odbiera wiadomość z Twojej domeny, natychmiast wysyła wiele zapytań DNS:
- Sprawdza rekordy SPF typu TXT, aby ustalić, czy adres IP nadawcy jest autoryzowany.
- Pobiera Twój publiczny klucz DKIM przy użyciu określonego selektora DNS w celu zweryfikowania podpisu kryptograficznego w wiadomości e-mail.
- Sprawdza rekord polityki DMARC, aby ustalić, jakie działania należy podjąć w przypadku niepowodzenia tych kontroli.
Jeśli osoba atakująca manipuluje tymi zapytaniami poprzez zatruwanie pamięci podręcznej DNS lub atak typu „hijacking”, system ochrony poczty elektronicznej przestaje działać. Sfałszowany rekord SPF może autoryzować nieautoryzowany serwer osoby atakującej, natomiast zmanipulowany rekord DMARC może spowodować zmianę polityki egzekwowania z odrzucania wiadomości na brak egzekwowania. Nowa struktura wyraźnie wskazuje na tę zależność i ostrzega, że uwierzytelnianie poczty elektronicznej wymaga zweryfikowanej integralności DNS, aby działało niezawodnie.
DNSSEC chroni rekordy uwierzytelniające poczty elektronicznej
Wdrożenie egzekwowania DMARC bez zabezpieczenia strefy DNS powoduje powstanie poważnej luki w zabezpieczeniach. Bez DNSSEC rekurencyjny serwer rozpoznający nie jest w stanie zweryfikować, czy odpowiedź DNS została zmieniona podczas przesyłania.
W typowym scenariuszu zatrucia pamięci podręcznej (cache poisoning) osoba atakująca wprowadza fałszywe wpisy do pamięci podręcznej lokalnego serwera DNS. Jeśli ta pamięć podręczna dostarczy fałszywy, całkowicie otwarty rekord SPF do odbierającej bramy pocztowej, brama ta uzna fałszywe wiadomości e-mail za całkowicie wiarygodne. Podpisując swoją strefę przy użyciu nowoczesnych algorytmów ECDSA zgodnie z nowymi wytycznymi, gwarantujesz, że serwery odbierające otrzymają niezmienione, autentyczne zasady dotyczące poczty elektronicznej.
Problem domen podobnych
Przypadek singapurskiej firmy zajmującej się surowcami doskonale pokazuje, gdzie standardowe metody uwierzytelniania wiadomości e-mail napotykają swoje ograniczenia strukturalne. Sprawcy tego ataku nie podszywali się bezpośrednio pod nazwę domeny ofiary ani nie złamali obowiązującej polityki DMARC. Zamiast tego zarejestrowali zupełnie odrębną, łudząco podobną nazwę domeny.
Ponieważ byli właścicielami tej domeny o podobnej nazwie, ich wiadomości e-mail bez problemu przechodziły własne testy SPF i DMARC.
| Warstwa zabezpieczeń | Co chroni | Gdzie to się kończy |
|---|---|---|
| Egzekwowanie DMARC | Chroni tożsamość Twojej prawdziwej, legalnej domeny przed bezpośrednim sfałszowaniem. | Nie da się uniemożliwić atakującemu zarejestrowania zupełnie odrębnej domeny o podobnej nazwie. |
| Ochronny system DNS (PDNS) | Sprawdza ruch wychodzący i blokuje przekierowania do złośliwych, nowo zarejestrowanych lub zajmowanych w wyniku typosquattingu domen. | Aby zapewnić pełną ochronę, konieczne jest odpowiednie skonfigurowanie tej funkcji wraz z uwierzytelnianiem poczty elektronicznej. |
Właśnie dlatego zaktualizowane ramy kładą nacisk na połączenie protokołów poczty elektronicznej z aktywną higieną DNS. Podczas gdy DMARC zabezpiecza tożsamość konkretnej domeny, ochronna warstwa DNS zapewnia niezbędną ochronę przed domenami o podobnej nazwie, blokując dostęp użytkowników, zanim dojdzie do jakiejkolwiek interakcji.
SP 800-81r3 – Lista kontrolna zgodności dla zespołów ds. bezpieczeństwa poczty elektronicznej
Aby dostosować swoją infrastrukturę do współczesnych modeli zagrożeń i wytycznych federalnych, skorzystaj z tej praktycznej, technicznej listy kontrolnej.

1. Włącz i zweryfikuj protokół DNSSEC w swojej domenie
- Podpisuj swoje autorytatywne strefy DNS przy użyciu zalecanych algorytmów kluczy ECDSA.
- Upewnij się, że rekordy TXT SPF, DKIM i DMARC są w pełni objęte podpisami DNSSEC.
- Wprowadź minimalizację QNAME w swoich rekurencyjnych serwerach nazw, aby ograniczyć wyciek informacji wychodzących.
2. Wdrażanie standardu DMARC wykraczające poza monitorowanie
- Nie należy pozostawiać swojej domeny bez ochrony przez czas nieokreślony, stosując bierną politykę monitorowania typu „p=none”.
- Należy opracować jasny plan działania mający na celu osiągnięcie stanu egzekwowania DMARC z parametrem p=reject.
- Wykorzystaj dedykowaną platformę DMARC Analyzer do ciągłego monitorowania zbiorczych danych telemetrycznych oraz bezpiecznego autoryzowania prawidłowych przepływów wiadomości wychodzących w trakcie procesu przejścia.
3. Sprawdź i uporządkuj rekordy SPF i DKIM
- Sprawdź konfiguracje SPF, aby upewnić się, że nie przekraczają one standardowego limitu 10 zapytań.
- Należy upewnić się, że każdy aktywny dostawca usług poczty elektronicznej korzysta z unikalnego klucza selektora DKIM, a także niezwłocznie unieważniać przestarzałe lub nieużywane klucze publiczne.
- Należy upewnić się, że wszystkie rekordy TXT dostępne publicznie znajdują się w całości w strefach chronionych protokołem DNSSEC, aby zapobiec manipulacjom na dalszych etapach łańcucha.
4. Wdrożenie architektury ochronnej DNS
- Wdrożyć rozwiązanie PDNS klasy korporacyjnej w modelu wdrożenia hybrydowego, aby zapewnić, że źródła informacji o zagrożeniach w chmurze są wspierane przez lokalne mechanizmy kontroli.
- Skonfiguruj wyraźne powiadomienia dotyczące bezpieczeństwa dla wyszukiwań prowadzących do nowo zarejestrowanych domen lub znanych wariantów nazwy Twojej marki, które są przedmiotem typosquattingu.
5. Przejście na szyfrowany transport DNS
- Należy egzekwować konfiguracje DoT lub DoH we wszystkich wewnętrznych rekurencyjnych serwerach nazw przedsiębiorstwa w celu zachowania prywatności zapytań.
- Należy nadać priorytet protokołowi DoT w zarządzanych sieciach korporacyjnych, aby uprościć standardowe monitorowanie portów i filtrowanie przez zaporę sieciową.
6. Scentralizuj dane telemetryczne DNS w systemie SIEM
- Przekieruj wszystkie logi autorytatywnych i rekurencyjnych zapytań DNS do swojej centralnej platformy SIEM.
- Skonfiguruj alerty operacyjne w czasie rzeczywistym dotyczące nietypowych działań, takich jak nieoczekiwane zmiany rekordów MX, nagłe modyfikacje rekordów TXT lub próby rozpoznawania znanej infrastruktury phishingowej przez wewnętrznych klientów.
Zakres zgodności: kogo to dotyczy?
| Ramy zgodności / Jurysdykcja | Zastosowanie i skutki |
|---|---|
| Amerykańskie agencje federalne i wykonawcy | Jest to bezwzględnie obowiązkowe. Zgodność z tymi wymogami jest bezpośrednio zgodna z federalnymi wytycznymi dotyczącymi modelu „zero trust” oraz rozporządzeniami wykonawczymi w zakresie cyberbezpieczeństwa. |
| Unia Europejska (dyrektywa NIS2) | Dla europejskich organizacji podlegających wymogom dyrektywy NIS2 norma SP 800-81r3 może stanowić przydatny punkt odniesienia w zakresie bezpieczeństwa systemu DNS. |
| PCI DSS 4.0 (Standard bezpieczeństwa danych w branży kart płatniczych) | Standard PCI DSS 4.0.1 wymaga stosowania zabezpieczeń przed phishingiem i zaleca stosowanie takich mechanizmów kontroli jak DMARC, SPF i DKIM, jednak nie określa DMARC jako jedynego obowiązkowego mechanizmu kontroli; wdrożenie tych wytycznych zapewnia bezpieczeństwo podstawowej infrastruktury DNS niezbędnej do prawidłowego działania DMARC. |
| Certyfikacja ISO 27001 | Jest to w pełni zgodne z wytycznymi zawartymi w załączniku A dotyczącymi bezpieczeństwa sieci (A.8.20) oraz zarządzania komunikacją. |
Słowa końcowe
Opublikowanie normy NIST SP 800-81r3 jasno pokazuje kluczową rzeczywistość: silne uwierzytelnianie poczty elektronicznej i bezpieczne wdrożenie systemu DNS stanowią całkowicie nierozerwalne elementy zabezpieczeń. Po prostu nie da się prowadzić niezawodnej i bezpiecznej obsługi poczty elektronicznej, jeśli podstawowy katalog sieciowy jest podatny na manipulacje. Incydent związany z przejęciem firmowej poczty elektronicznej w Singapurze, który spowodował straty rzędu wielu milionów dolarów, dowodzi, że poleganie na podstawowej widoczności domeny nie wystarcza już do ochrony przedsiębiorstwa.
Prawdziwe bezpieczeństwo wymaga wielowarstwowej ochrony. Zabezpieczenie tożsamości domeny wymaga wyjścia poza bierną obserwację i wzmocnienia infrastruktury za pomocą aktywnych, odpornych protokołów.
Zrób pierwszy krok już dziś: sprawdź, czy Twoje rekordy są poprawnie opublikowane i zabezpieczone. Skorzystaj z bezpłatnego narzędzia DMARC Record Checker oraz kompleksowych narzędzi do wyszukiwania rekordów DNS w serwisie PowerDMARC, aby w mniej niż 60 sekund uzyskać pełną ocenę stanu Twojego wdrożenia w czasie rzeczywistym.
Najczęściej zadawane pytania
Jaka jest główna różnica między normą NIST SP 800-81r2 a normą SP 800-81r3?
W poprzedniej wersji (wersja 2), opublikowanej w 2013 roku, system DNS traktowano jako statyczne narzędzie, które wystarczy skonfigurować tylko raz. Wersja 3 (sfinalizowana 19 marca 2026 roku) unowocześnia tę strukturę, uwzględniając model „Zero Trust”, przetwarzanie w chmurze oraz szyfrowany transport danych. Jej celem jest przedefiniowanie systemu DNS jako ciągłego, aktywnego mechanizmu zabezpieczeń, który integruje się z systemem SIEM i proaktywnie filtruje zagrożenia.
Czy egzekwowanie standardu DMARC zapobiegłoby atakowi typu BEC w Singapurze, w wyniku którego stracono 6,6 mln dolarów?
Nie, DMARC na legalnej domenie nie może powstrzymać atakującego przed zarejestrowaniem zupełnie odrębnej domeny o podobnej nazwie. W sprawie z Singapuru z kwietnia 2026 r. atakujący wykorzystali domenę typu „typosquatting”, w której zamieniono miejscami dwie litery. Ponieważ byli właścicielami tej fałszywej domeny, ich wiadomości e-mail mogły technicznie przejść własne kontrole DMARC. Powstrzymanie tego rodzaju ataków wymaga zastosowania systemu Protective DNS (PDNS) w celu zablokowania rozpoznawania domen o podobnej nazwie.
Dlaczego norma NIST SP 800-81r3 nakazuje przejście na algorytm ECDSA w ramach protokołu DNSSEC?
Starsze algorytmy RSA powodują powstawanie większych kluczy kryptograficznych i większych rozmiarów pakietów, co może spowolnić proces rozpoznawania adresów i narazić systemy na ataki amplifikacyjne. Zaktualizowane wytyczne nakazują przejście na algorytm ECDSA, ponieważ zapewnia on wyższy poziom bezpieczeństwa, szybsze przetwarzanie oraz znacznie mniejsze rozmiary kluczy.
W jaki sposób minimalizacja QNAME chroni prywatność danych mojej firmy?
W tradycyjnych wyszukiwaniach DNS pełne zapytanie dotyczące nazwy domeny jest wysyłane do każdego serwera autorytatywnego w łańcuchu wyszukiwania DNS. Minimalizacja QNAME zmienia ten proces, polegając na wysyłaniu jedynie minimalnej części nazwy domeny niezbędnej na danym etapie procesu rozpoznawania.
Kto jest prawnie zobowiązany do przestrzegania normy NIST SP 800-81r3?
SP 800-81r3 to oficjalne wytyczne NIST dotyczące bezpiecznego wdrażania systemu DNS; mają one szczególne znaczenie dla agencji federalnych Stanów Zjednoczonych, wykonawców federalnych oraz organizacji podlegających regulacjom, które muszą spełniać federalne wymagania w zakresie cyberbezpieczeństwa.
- Wyrównanie SPF: co to jest i dlaczego jest potrzebne? - 28 lipca 2026 r.
- Przewodnik po konfiguracji DMARC dla Office 365 (2026) - 21 lipca 2026 r.
- Jak naprawić błędy „Podpis DKIM jest nieprawidłowy” i „Skrót treści nie został zweryfikowany” – 16 lipca 2026 r.


