Kluczowe wnioski
- DANE przenosi proces weryfikacji certyfikatów TLS z zewnętrznych urzędów certyfikacji do systemu DNS, wykorzystując podpisywane protokołem DNSSEC rekordy TLSA w celu ustanowienia zaufania.
- Zapobiega atakom typu „downgrade” na protokół STARTTLS poprzez wymuszanie połączeń szyfrowanych zamiast zezwalania na ciche przełączanie na tryb zwykłego tekstu.
- DANE ogranicza ryzyko wystawienia nieprawidłowych lub naruszonych certyfikatów, umożliwiając właścicielom domen dokładne określenie, które certyfikaty są ważne.
- DNSSEC jest niezbędny do prawidłowego działania protokołu DANE. Bez niego nie można uznać rekordów TLSA za wiarygodne ani ich zweryfikować.
- Chociaż protokół DANE jest bardzo skuteczny, jego stosowanie jest nadal ograniczone, dlatego często wykorzystuje się go w połączeniu z MTA-STS oraz uzupełnia o DMARC w celu zapewnienia pełnego bezpieczeństwa poczty elektronicznej.
Uwierzytelnianie podmiotów nazwanych w oparciu o DNS (DANE) to metoda weryfikacji certyfikatów TLS z wykorzystaniem systemu DNS. Opiera się ona na protokole DNSSEC oraz rekordach TLSA, aby zapewnić, że szyfrowane połączenia nie zostaną przechwycone ani obniżone do niższej wersji.
Problem, do rozwiązania którego zaprojektowano system DANE
Wysyłanie wiadomości e-mail za pośrednictwem protokołu SMTP (Simple Mail Transfer Protocol) często wykorzystuje protokół STARTTLS w celu szyfrowania połączeń. Problem polega na tym, że protokół STARTTLS działa w trybie oportunistycznym. Oznacza to, że w przypadku niepowodzenia szyfrowania połączenie może powrócić do trybu tekstu jawnego. To obniżenie poziomu bezpieczeństwa może nastąpić w sposób niezauważalny, co ułatwia atakującym wykorzystanie tego zachowania do przechwytywania wiadomości e-mail.
Standardowa ścieżka:

Ścieżka ataku:

Istnieje również druga wada tradycyjnego protokołu TLS:
Certyfikaty TLS są weryfikowane przez komercyjne urzędy certyfikacji (CA). Urzędy te mogą paść ofiarą ataku lub wydawać certyfikaty nieprawidłowo. Jeśli osoba atakująca zdobędzie ważny certyfikat dla danej domeny, może podszyć się pod ten serwer.
Te dwie kwestie sprawiają, że ataki typu „man-in-the-middle” są możliwe nawet przy użyciu protokołu TLS. Rozwiązanie DANE rozwiązuje oba problemy poprzez przeniesienie procesu weryfikacji certyfikatów do systemu DNS, zabezpieczonego protokołem DNSSEC. Eliminuje to zależność od zewnętrznych urzędów certyfikacji i zapobiega atakom typu „silent downgrade”.
Czym jest DANE?
DANE to protokół bezpieczeństwa internetowego, który umożliwia właścicielom domen publikowanie informacji o swoich certyfikatach TLS bezpośrednio w systemie DNS za pomocą rekordów TLSA.
Zapisy te są chronione przez protokół DNSSEC, który zapewnia:
- Dane nie mogą być zmieniane podczas przesyłania
- Klient może sprawdzić, czy odpowiedź jest autentyczna
Zamiast polegać na zewnętrznym urzędzie certyfikacji, klient weryfikuje certyfikat na podstawie informacji opublikowanych przez samą domenę.
Jak działa DANE: krok po kroku
Krok 1: Właściciel domeny publikuje rekord TLSA w systemie DNS
Administrator domeny tworzy rekord zasobów TLSA (Transport Layer Security Authentication) i publikuje go w swojej strefie DNS. Rekord ten zawiera dane certyfikatu, które klienci będą później wykorzystywać do weryfikacji.

Krok 2: Strefa DNS jest podpisywana przy użyciu protokołu DNSSEC
DNSSEC (rozszerzenia zabezpieczeń DNS) kryptograficznie podpisuje całą strefę DNS, w tym nowy rekord TLSA. Tworzy to łańcuch zaufania od strefy głównej DNS aż po rekordy domeny, zapobiegając manipulacjom.

Krok 3: Klient łączy się z serwerem i wysyła zapytanie dotyczące rekordu TLSA
Gdy klient (np. serwer pocztowy lub przeglądarka) chce nawiązać połączenie TLS z serwerem, najpierw wysyła zapytanie do systemu DNS w celu uzyskania rekordu TLSA dla danej domeny.

Krok 4: Klient weryfikuje odpowiedź DNS za pomocą protokołu DNSSEC
Zanim zaufają rekordowi TLSA, moduł rozpoznający klienta weryfikuje podpisy DNSSEC, przechodząc w górę łańcucha zaufania.

Krok 5: Serwer przedstawia swój certyfikat TLS
Podczas nawiązywania połączenia TLS serwer wysyła do klienta swój certyfikat TLS, aby potwierdzić swoją tożsamość poprzez przedstawienie łańcucha certyfikatów.

Krok 6: Klient porównuje certyfikat z wpisem w bazie TLSA
To najważniejsza część weryfikacji DANE. Na tym etapie klient wyodrębnia odpowiednią część certyfikatu serwera i porównuje ją z danymi zapisanymi w rekordzie TLSA.

Krok 7: Jeśli dane się zgadzają, połączenie zostaje nawiązane
Gdy dane certyfikatu są zgodne z rekordem TLSA, weryfikacja DANE przebiega pomyślnie, co pozwala na pomyślne nawiązanie połączenia TLS.

Krok 8: Jeśli nie są zgodne, połączenie zostanie odrzucone
Gdy certyfikat nie zgadza się z wpisem w TLSA, klient traktuje to jako naruszenie bezpieczeństwa i odmawia zakończenia uzgadniania TLS. Zapobiega to już na samym początku skutecznym atakom typu „man-in-the-middle”.

Czym jest rekord TLSA?
Rekord TLSA to rekord DNS wykorzystywany przez protokół DANE do określenia sposobu weryfikacji certyfikatu TLS.
The format looks like this: <usage> <selector> <matching-type> <certificate-data>
Przykładowy rekord TLSA:
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)
Każde pole pełni określoną funkcję:
- Zastosowanie: Określa, w jaki sposób certyfikat powinien być porównywany i uznawany za wiarygodny
- Selektor: Określa, która część certyfikatu jest wykorzystywana (pełny certyfikat lub klucz publiczny)
- Typ dopasowania: Określa sposób przechowywania danych (pełna wartość lub skrót)
- Dane certyfikatu: Rzeczywista wartość lub skrót, z którym należy dokonać porównania
Wartości wykorzystania certyfikatu
Wyróżnia się cztery rodzaje zastosowań:
0 (PKIX-TA): Ograniczenie dotyczące punktu odniesienia zaufania z wykorzystaniem tradycyjnej infrastruktury PKI
1 (PKIX-EE): Certyfikat podmiotu końcowego zweryfikowany za pośrednictwem infrastruktury PKI
2 (DANE-TA): Punkt odniesienia zaufania zdefiniowany w systemie DNS
3 (DANE-EE): Certyfikat podmiotu końcowego zdefiniowany bezpośrednio w systemie DNS
Jeśli chodzi o bezpieczeństwo poczty elektronicznej, najważniejsze są opcje 2 i 3, ponieważ eliminują one zależność od publicznych urzędów certyfikacji.
Gdzie publikowane są zapisy TLSA
Rekordy TLSA są publikowane w określonych subdomenach związanych z usługami. W przypadku protokołu SMTP wygląda to zazwyczaj następująco: _25._tcp.mail.example.com
DANE w poczcie elektronicznej: jak zabezpiecza protokół SMTP
Protokół DANE pomaga serwerowi wysyłającemu zweryfikować autentyczność certyfikatów serwera odbierającego. Weryfikacja ta pomaga zapobiegać atakom typu „downgrade” protokołu STARTTLS oraz atakom typu „man-in-the-middle”, przyczyniając się do zwiększenia bezpieczeństwa komunikacji SMTP.
DANE stosuje protokół TLS do przesyłania wiadomości e-mail, co zapobiega wysyłaniu wiadomości w postaci zwykłego tekstu oraz ich manipulowaniu podczas przesyłania.
Dlaczego protokół DANE wymaga protokołu DNSSEC
DANE opiera się całkowicie na integralności rekordów DNS. Bez protokołu DNSSEC rekordy TLSA mogłyby zostać sfałszowane, a osoby atakujące mogłyby przekierowywać klientów do złośliwych certyfikatów. Oto, jak działa ta zależność: protokół DNSSEC podpisuje odpowiedzi DNS przy użyciu kluczy kryptograficznych. Dzięki temu klient może zweryfikować, czy odpowiedź nie została zmieniona i czy dane są autentyczne. W związku z tym bez protokołu DNSSEC DANE nie zapewnia żadnych rzeczywistych korzyści w zakresie bezpieczeństwa.
Kto korzysta z DANE?
Wdrażanie protokołu DANE różni się w zależności od regionu, przy czym najwyższy odsetek odnotowuje się wśród europejskich agencji rządowych oraz organizacji w Stanach Zjednoczonych. Popularność tego protokołu rośnie w sektorach, w których poufność wiadomości e-mail ma kluczowe znaczenie. Do typowych użytkowników protokołu DANE należą:
- Wykorzystanie administratorów poczty elektronicznej jako dodatkowego poziomu uwierzytelniania i zabezpieczeń
- Agencje rządowe w krajach europejskich i w Stanach Zjednoczonych, w celu zapewnienia bezpieczeństwa przesyłania wiadomości e-mail w sektorze publicznym (przykład: niemiecka firma T-Online jest jednym z rzeczywistych użytkowników protokołu DANE)
- Dostawcy poczty elektronicznej, tacy jak Comcast, Protonmail itp.
- Firma Microsoft ogłosiła, że od lipca 2024 r. będzie obsługiwać protokół SMTP przychodzący oparty na DANE.
DANE a MTA-STS: Czym się różnią?
Zarówno DANE, jak i protokół MTA-STS (Mail Transfer Agent – Strict Transport Security) mają na celu zabezpieczenie połączeń SMTP, ale opierają się na różnych modelach zaufania. Podczas gdy MTA-STS wykorzystuje protokół HTTPS i urzędy certyfikacji (CA), DANE opiera się na protokole DNSSEC i systemie DNS. Oto kilka kluczowych różnic między tymi dwoma rozwiązaniami:
| Cecha | DANE | MTA-STS |
|---|---|---|
| Wymagany protokół DNSSEC | Tak | Nie |
| Lokalizacja polityki | DNS | Plik zasad HTTPS |
| Zależność od CA | Opcjonalnie | Wymagane |
| Ochrona przed obniżeniem ratingu | Silny | Silny |
| Adopcja | Niski | High |
Aby dowiedzieć się więcej o MTA-STS, przeczytaj nasz kompletny przewodnik poświęcony tej technologii. Aby dowiedzieć się, jak wdrożyć MTA-STS w swojej domenie, zapoznaj się z naszym przewodnikiem po wdrażaniu MTA-STS.
Jak działa TLS-RPT w połączeniu z DANE i MTA-STS
TLS-RPT to protokół raportowania, który zapewnia wgląd w niepowodzenia negocjacji TLS oraz problemy z dostarczaniem wiadomości spowodowane nieprawidłową konfiguracją protokołów DANE lub MTA-STS. TLS-RPT można traktować jako warstwę zapewniającą wgląd, działającą nad protokołami DANE i MTA-STS (warstwami bezpieczeństwa). Chociaż zarówno DANE, jak i MTA-STS pomagają egzekwować stosowanie protokołu TLS w celu zabezpieczenia transmisji poczty elektronicznej, istnieje poważna luka w zakresie jasności co do tego, kiedy i dlaczego dostarczenie wiadomości kończy się niepowodzeniem.
W tym miejscu do akcji wkracza TLS-RPT. Protokół raportowania SMTP TLS (TLS-RPT) wysyła codziennie do serwerów odbiorczych zbiorcze raporty zwrotne dotyczące:
- Błędy podczas negocjacji protokołu TLS
- Problemy z weryfikacją certyfikatów
- Niezgodności protokołów (MTA-STS lub DANE)
- Błędy dostarczania spowodowane wymuszeniem protokołu TLS
Jak sprawdzić, czy Twoja domena posiada rekord DANE/TLSA
Aby sprawdzić konfigurację DANE, należy:
- Czy dla Twojego serwera pocztowego istnieje rekord TLSA
- Czy protokół DNSSEC jest włączony i czy jest prawidłowy
- Czy certyfikat jest zgodny z rekordem TLSA
Możesz skorzystać z bezpłatnego narzędzia DANE Record Checker firmy PowerDMARC, aby szybko sprawdzić poprawność swojej konfiguracji.
Jak wdrożyć protokół DANE w poczcie elektronicznej
Aby wdrożyć protokół DANE w swojej poczcie elektronicznej, wykonaj poniższe czynności:
Krok 1: Włącz protokół DNSSEC
Usługa DANE nie działa bez protokołu DNSSEC, dlatego pierwszym krokiem jest skonfigurowanie protokołu DNSSEC u dostawcy usług DNS lub rejestratora. Możesz sprawdzić, czy protokół ten jest już skonfigurowany dla Twojej domeny, korzystając z naszego narzędzia do sprawdzania DNSSEC.
Krok 2: Uzyskaj dane certyfikatu TLS
Pobierz certyfikat lub skrót klucza publicznego z serwera pocztowego.
Krok 3: Utwórz rekord TLSA
Określ prawidłowe zastosowanie, selektor i typ dopasowania, a następnie opublikuj swój rekord TLSA w odpowiedniej subdomenie.
Krok 4: Sprawdź poprawność wpisu
Skorzystaj z naszego narzędzia do sprawdzania DANE, aby upewnić się, że wpis jest poprawny, a protokół DNSSEC działa prawidłowo.
Krok 5: Monitorowanie zmian w certyfikatach
W przypadku odnowienia lub zmiany certyfikatu TLS należy zaktualizować rekord TLSA. Niezastosowanie się do tego wymogu może spowodować zakłócenia w dostarczaniu poczty.
Słowa końcowe
Jeśli nie zabezpieczają Państwo jeszcze warstwy transportowej poczty elektronicznej za pomocą protokołu MTA-STS, DANE może stanowić doskonały punkt wyjścia. Szczególnie w sektorach zajmujących się przetwarzaniem danych wrażliwych, takich jak instytucje finansowe i agencje sektora publicznego, zabezpieczenie wiadomości przed przechwyceniem ma kluczowe znaczenie.
Jednak DANE nie jest w stanie zapobiec atakom typu spoofing lub phishing przeprowadzanym przy użyciu Twojej własnej nazwy domeny. W tym celu niezbędny jest protokół DMARC. Szukasz kompleksowego pakietu zabezpieczeń domeny, który zajmie się uwierzytelnianiem poczty elektronicznej od początku do końca? Umów się już dziś na prezentację z naszymi ekspertami.
Najczęściej zadawane pytania
Czy DANE to to samo co DNSSEC?
Nie, DANE i DNSSEC to nie to samo, choć DANE wymaga DNSSEC do działania. DNSSEC zabezpiecza rekordy DNS, podczas gdy DANE wykorzystuje DNSSEC do bezpiecznego publikowania informacji o certyfikatach.
Czy potrzebuję zarówno DANE, jak i MTA-STS?
Niekoniecznie, ale stosowanie obu tych rozwiązań zapewnia większą kompatybilność i lepszą ochronę. Ogólnie rzecz biorąc, MTA-STS cieszy się większą popularnością niż DANE.
Czy DANE zastępuje protokoły SPF, DKIM lub DMARC?
Nie. Protokół DANE zapewnia bezpieczeństwo warstwy transportowej, podczas gdy protokoły SPF, DKIM i DMARC zajmują się uwierzytelnianiem wiadomości e-mail i zapobieganiem fałszowaniu adresów. Aby zapewnić kompleksowe bezpieczeństwo poczty elektronicznej, konieczne jest wielowarstwowe podejście łączące wszystkie protokoły wraz ze stałym monitorowaniem i aktualizacjami.
Co się stanie, jeśli moje dane w systemie TLSA są nieprawidłowe?
Jeśli rekord TLSA jest nieprawidłowy, serwery pocztowe stosujące protokół DANE będą odrzucać połączenia. Może to skutkować niepowodzeniami w dostarczaniu wiadomości e-mail. Aby rozwiązać ewentualne problemy, należy sprawdzić poprawność konfiguracji DANE (w tym poprawność rekordu TLSA).
Którzy dostawcy poczty elektronicznej obsługują protokół DANE?
Stopień poparcia dla standardu DANE różni się w zależności od regionu. Niektórzy europejscy dostawcy usług oraz organizacje zajmujące się bezpieczeństwem wymagają jego stosowania, jednak na skalę globalną jego upowszechnienie jest nadal ograniczone.
- Czym jest DANE? Wyjaśnienie uwierzytelniania nazwanych podmiotów w oparciu o DNS (2026) - 20 kwietnia 2026 r.
- Podstawy bezpieczeństwa VPN: najlepsze praktyki w zakresie ochrony prywatności – 14 kwietnia 2026 r.
- Recenzja MXtoolbox: funkcje, wrażenia użytkowników, zalety i wady (2026) – 14 kwietnia 2026 r.


