[ DNS i domeny ]

Umiędzynarodowione nazwy domen i punycode w kontrolach DNS

Porównaj międzynarodowe etykiety domen w ich Unicode i zweryfikowanych formularzach ASCII przed uruchomieniem kontroli DNS i uwierzytelniania.

Przez zespół badawczy EmailAuth

[Kluczowe punkty]

  • Zachowaj dane wejściowe Unicode, zatwierdzone dane wyjściowe z etykietą A i dokładny profil IDNA.
  • Konwertuj domenę przed dodaniem etykiet podkreśleń protokołu.
  • Prawidłowe uwierzytelnienie nie ustanawia własności podobnej marki.
Na tej stronie

Domenę wyświetlaną w Unicode można przeszukiwać za pomocą reprezentacji zgodnej z ASCII. Zachowaj oba formularze i reguły konwersji, aby można było odtworzyć wynik sprawdzania. Znajomość wizualna nie jest dowodem na to, że dwie nazwy identyfikują tę samą domenę lub należą do tej samej organizacji.

Oddziel domenę od skrzynki pocztowej

Referencje: RFC 5890 §2.3.2.1, RFC 5891 §5.

Umiędzynarodowiona etykieta domeny może mieć etykietę U, jej prawidłową formę Unicode, i etykietę A, której zweryfikowana forma zgodna z ASCII zaczyna się od xn--. Przetwarzanie IDNA działa na etykietach domen. Nie konwertuje lokalnej części poczty e-mail na skrzynkę pocztową ASCII i nie ustanawia obsługi SMTPUTF8.

Rekordy uwierzytelniające dodają etykiety protokołów w całej domenie. Przekonwertuj umiędzynarodowioną część domeny na odpowiednią implementację IDNA, a następnie skonstruuj właściciela, np _dmarc. plus domena A-label. Nie uruchamiaj modułu sprawdzania poprawności IDNA opartego wyłącznie na nazwie hosta na etykietach podkreśleń protokołu i nie stwierdzaj, że podstawowa domena jest nieprawidłowa.

Waliduj, a nie tylko koduj

Referencje: RFC 5890 §2.3.2.1, RFC 5891 §4, RFC 5895 §2.

Punycode jest częścią reprezentacji etykiety A, ale nie każdy ciąg znaków rozpoczynający się od xn jest prawidłową etykietą A. Walidacja obejmuje obowiązujące zasady IDNA, dozwolone znaki i ograniczenia kontekstowe. RFC 5891 definiuje przetwarzanie protokołu, podczas gdy wybory mapowania aplikacji mogą wpływać na dane wejściowe użytkownika przed tym przetwarzaniem.

Zapisz bibliotekę i wersję, profil IDNA, dane wejściowe Unicode i wynikowy formularz ASCII. Domyślne ustawienia narzędzi mogą się różnić, szczególnie w przypadku znaków, na które wpływa mapowanie lub starsze zachowanie IDNA. Unikaj cichego normalizowania niejednoznacznego wpisu użytkownika i prezentowania wyniku jako jedynej możliwej zamierzonej domeny.

Odtwórz spotkanie w obie strony

Używając zainstalowanej biblioteki idna języka Python, która implementuje IDNA2008, uruchom idna.encode("bü cher.example ", uts46=False).decode("ascii"). Oczekiwany wynik to xn--bcher-kva.example. Zdekoduj go za pomocą tej samej biblioteki i zweryfikuj podróż w obie strony w Unicode. Przykład ma charakter ilustracyjny i nie stanowi twierdzenia dotyczącego działającej domeny organizacji.

Skonstruować _dmarc.xn--bcher-kva.example I s1._domainkey.xn--bcher-kva.example jako ciągi właściciela DNS . W laboratorium lub w kontrolowanym programie sprawdzającym sprawdź, czy narzędzie akceptuje dane wejściowe Unicode, konwertuje je, odrzuca lub wysyła inne pytanie. Zachowane przechwytywanie historyczne rejestruje jedynie konwersję bibliotek w wersji idna 3.18. Nowa kontrola konwersji offline w tej recenzji rejestruje osobno zainstalowaną wersję; nie jest to również test DNS ani SMTPUTF8.

Dodaj urządzenie ujemne z nieprawidłową etykietą xn-- i zachowaj aktualny wyjątek biblioteki. Traktuj odmowę jako użyteczny dowód, zamiast usuwać znaki, dopóki dane wejściowe nie zostaną przekazane. W przypadku innych mapowań dostępnych dla użytkownika należy wyraźnie udokumentować alternatywny profil, zamiast zakładać, że ścisły wynik IDNA2008 pasuje do każdej przeglądarki.

Porównaj rzeczywiste tożsamości w dowodach pocztowych

Referencje: RFC 9989 §4.4, RFC 9989 §5.3.1.

Zachowaj oryginał Z nagłówka oraz reprezentacje domen używane przez SPF, DKIM I DMARC analiza. Dla DMARC , RFC 9989 §5.3.1 wymaga, aby wyodrębniona domena autora etykiety U została przekonwertowana do postaci etykiety A w celu dalszego przetwarzania. Skorzystaj z protokołu wyrównanie zasad, a nie wizualne porównanie wyświetlanych nazw. Jeśli narzędzie nie obsługuje składni wiadomości lub zachowań związanych z internacjonalizacją, zgłoś ograniczenie, zamiast po cichu wybierać dogodną tożsamość.

Użyj znanego kontekstu własności, aby zbadać podobieństwa. Domena może przejść własne uwierzytelnienie i nadal wizualnie przypominać nazwę innej organizacji. Konwersja IDNA poprawia odtwarzalność; nie potwierdza własności marki, usuń phishing ryzykować lub udowodnić, że wiadomość e-mail została autoryzowana przez oczekiwaną stronę.

[Na wynos]

Prawidłowe uwierzytelnienie nie ustanawia własności podobnej marki.

[ Według roli ]

Co to oznacza dla Ciebie

Wybierz swoją rolę, aby uzyskać praktyczne dalsze kroki.

Administrator IT / poczty

Zapisz zachowanie normalizacyjne

Osoba sprawdzająca musi ujawnić, jakiej nazwy DNS faktycznie używała.

Kolejne kroki

  1. Przechwytuj formularze Unicode i ASCII.
  2. Przypnij profil i wersję IDNA.
  3. Odrzucenie testu i podróże w obie strony.

CISO / SecOps

Oceniaj podobne osoby, nie przechwalając się

Prawidłowa internacjonalizacja sama w sobie nie jest podejrzana ani godna zaufania.

Kolejne kroki

  1. Porównaj rzeczywiste etykiety.
  2. Zachowaj oryginalne tożsamości wiadomości.
  3. Należy odróżniać wyniki phishingu i protokołów.

Założyciel / Nietechniczny

Oddziel tożsamość od wyglądu

Znajomo wyglądająca domena może należeć do kogoś innego.

Kolejne kroki

  1. Sprawdź rzeczywisty kontekst własności domeny.
  2. Unikaj twierdzeń dotyczących marki na podstawie samego uwierzytelnienia.
  3. Eskaluj niejednoznaczne raporty klientów.

[ Często zadawane pytania ]

Często zadawane pytania

Co to jest etykieta A?

Prawidłowa reprezentacja międzynarodowej etykiety domeny, zgodna z ASCII, przy użyciu formularza xn--.

RFC 5890 §2.3.2.1

Czy każdy ciąg xn-- jest prawidłowy?

Nie. Musi spełniać kryteria IDNA, a nie tylko przypominać Punycode.

RFC 5890 §2.3.2.1

Czy IDNA konwertuje część lokalną skrzynki pocztowej?

Nie. Konwersja domeny jest odrębna od obsługi międzynarodowych adresów e-mail.

Czy powinienem przekonwertować _dmarc jako etykietę nazwy hosta IDNA?

Konwertuj część domeny i oddzielnie konstruuj właściciela protokołu; podkreślone etykiety usług mają inną rolę.

RFC 5891 §5

Dlaczego dwa narzędzia normalizują się inaczej?

Mogą korzystać z różnych wersji IDNA lub profili mapowania. Zapisz oba wyraźnie.

RFC 5895 §2

Co powinien zachować test w obie strony?

Zamierzona prawidłowa etykieta Unicode i odpowiadająca jej forma ASCII w ramach podanego profilu.

RFC 5890 §2.3.2.1

Czy uwierzytelniony sobowtór należy do marki?

Nie. Uwierzytelnienie tej domeny nie ustanawia własności innej marki.

Czy przykład został wysłany jako e-mail?

Nie. Dowody ograniczają się do konwersji bibliotek offline i sprawdzania poprawności danych wejściowych; DNS , dostarczanie wiadomości i SMTPUTF8 nie były testowane.

[ Źródła ]

Źródła

  1. RFC 5890

    Sekcje §2.3.2.1

  2. RFC 5891

    Sekcje §4 · §5

  3. RFC 5895

    Sekcje §2

  4. RFC 9989

    Sekcje §4.4 · §5.3.1

[ Słowniczek ]

Słowniczek

Etykieta U
Prawidłowa forma Unicode międzynarodowej etykiety domeny.

RFC 5890 §2.3.2.1

Etykieta A
Sprawdzona etykieta IDNA zgodna z ASCII.

RFC 5890 §2.3.2.1

Punycode
Kodowanie używane w reprezentacji ASCII międzynarodowych etykiet.

RFC 5890 §2.3.2.1

Pochodzenie przedsiębiorstwa

Dlaczego najlepsze instytucje finansowe i rządy wycofali swoje panele bezpieczeństwa poczty e-mail.

Tradycyjne platformy uwierzytelniania poczty e-mail oferują pulpit nawigacyjny i proszą inżynierów o wykonanie pracy. W środowiskach o dużej stawce ręczny nadzór oznacza opóźnione egzekwowanie, zmianę konfiguracji i niemonitorowane domeny-cienie.

EmailAuth to platforma agentowego pochodzenia wiadomości e-mail. Nasi agenci egzekwują p=reject, dostosuj zewnętrznych nadawców i przenieś swoje domeny do pełnych adresów RFC 9989 zgodność, nowy standard DMARC , z możliwością kontroli przez człowieka.

Rządy Duże przedsiębiorstwa Instytucje finansowe poziomu 1

SaaS · Dedykowany najem · Lokalne rozwiązanie typu air-gapped · Szyfrowanie BYOK

Baza wiedzy