Edytor DNS zgłaszający limit 255 znaków niekoniecznie oznacza, że Twój SPF zasady muszą stać się wieloma rekordami. Format DNS TXT umożliwia umieszczenie wielu ciągów znaków w jednym rekordzie zasobu. SPF traktuje ich zawartość jako jedną ciągłą wartość. Wyzwaniem operacyjnym jest zachowanie zamierzonego tekstu przy jednoczesnym zapewnieniu możliwości zarządzania polityką i odpowiedziami DNS .
Oddziel trzy różne limity
Po pierwsze, pojedynczy ciąg znaków TXT jest ograniczony do 255 oktetów. Zawartość SPF to ASCII, więc każdy z jego zwykłych znaków zajmuje jeden oktet. Singiel Rekord TXT może zawierać więcej niż jeden taki ciąg. RFC 7208 sekcja 3.3 wyraźnie zezwala na taką reprezentację.
Po drugie, odpowiedź DNS ma rozmiar. Zawiera nazwy, metadane rekordów i inne rekordy TXT zwrócone pod nazwą tego właściciela, a nie tylko tekst SPF . Sekcja 3.4 zaleca, aby odpowiedzi DNS SPF były wystarczająco małe, aby umożliwić obsługę starszego protokołu UDP o długości 512 oktetów. Jest to zalecenie dotyczące zgodności, a nie uniwersalne maksimum 512 znaków dla SPF . Nowoczesne możliwości transportu DNS nie eliminują każdego problemu z programem rozpoznawania nazw, zaporą ogniową lub obcięciem.
Po trzecie, ocena SPF ma ograniczenia zasobów. Dzielenie tekstu na ciągi nie zmniejsza przetwarzania zagnieżdżonego włączania ani limitu dziesięciu terminów powodujących wyszukiwanie. Krótka polityka może przekroczyć ten limit oceny; dłuższa lista wyraźnych adresów może nie. Niezależnie oceń składnię, transport DNS i koszt oceny.
Zachowaj spacje celowo
SPF łączy ciągi znaków bez wstawiania spacji. W reprezentacji pliku strefy "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" tworzy zamierzoną ciągłą politykę, ponieważ pierwszy ciąg kończy się spacją. Usunięcie tej spacji łączy dwa sąsiednie mechanizmy w nieprawidłowy tekst.
Powyższe adresy służące wyłącznie do celów dokumentacyjnych mają charakter poglądowy. Nie są to autoryzowane wartości dla Twojej domeny. Cudzysłowy to składnia prezentacji pliku strefy; To, czy wprowadzisz je w hostowanym edytorze DNS , zależy od udokumentowanego interfejsu tego dostawcy. Niektórzy redaktorzy automatycznie dzielą długie wartości, podczas gdy inni udostępniają oddzielne pola tekstowe. Sprawdź podaną odpowiedź, zamiast zakładać, że wyświetlacz edytora odpowiada formatowi przewodu.
Nie twórz na początku drugiego rekordu zasobu TXT v=spf1 trzymać resztę. Wybrano wiele Rekordy SPF wytwarzać permerror. I odwrotnie, nie usuwaj niepowiązanych rekordów weryfikacyjnych TXT , ponieważ narzędzie diagnostyczne wyświetla kilka odpowiedzi TXT .
Sprawdź opublikowaną wartość
Przechwyć wiarygodną odpowiedź TXT i określ, które ciągi należą do poszczególnych rekordów zasobu. Zrekonstruuj wartość SPF , łącząc tylko ciągi w jednym rekordzie. Sprawdź spacje na każdej podzielonej granicy i upewnij się, że istnieje jeden znacznik wersji, prawidłowe mechanizmy i zamierzona instrukcja końcowa.
Następnie przetestuj rekursywne odpowiedzi DNS z ważnych sieci. Jeśli odpowiedź zostanie obcięta lub rozpoznanie nie powiedzie się, zamiast usuwać dowolne mechanizmy, sprawdź transport DNS i konfigurację dostawcy. DNSSEC a szerszy zestaw odpowiedzi może mieć wpływ na wielkość odpowiedzi; proste zliczanie znaków nie jest testem pełnego rozmiaru pakietu.
Wolisz porządkowanie zasad niż sprytne pakowanie
Rosnąca polityka często sygnalizuje skumulowane usługi. Przegląd przestarzałych obejmuje niepotrzebnie szerokie mechanizmy i powielanie zezwoleń przed zwiększeniem złożoności. W stosownych przypadkach należy zachować obecne mechanizmy zarządzane przez dostawcę, zamiast kopiować jego obecne adresy IP wyłącznie w celu skrócenia lub zmiany kształtu rekordu. Ręcznie spłaszczone adresy mogą stać się nieaktualne, gdy dostawcy zmienią infrastrukturę.
W przypadku zasad, które nadal wymagają wielu ciągów, zapisz zamierzony niepodzielony tekst obok opublikowanej reprezentacji. Daje to przyszłym administratorom stabilny cel porównawczy. Nieszkodliwego przeformatowania edytora nie należy mylić ze zmianą polityki semantycznej.
Sprawdź wynik widoczny dla czytelnika
Po zatwierdzeniu zmiany przetestuj reprezentatywne źródła i niedopasowane źródło przy pomocy osoby oceniającej znającej standardy, a następnie sprawdź rzeczywiste wyniki zaufanego odbiorcy. Zapisz zrekonstruowaną wartość, obserwacje reakcji i wyniki oceny. Zamknij problem, gdy zarówno reprezentacja DNS , jak i zachowanie autoryzacji są prawidłowe, a nie tylko wtedy, gdy edytor zaakceptuje zapis.
Zrekonstruuj odpowiedź na zapytanie
Poniżej znajduje się syntetyczne ćwiczenie diagnostyczne, a nie zapytanie, które wykonaliśmy rekord opublikować. Zastąp rzeczywistą nazwę właściciela SPF i zweryfikowaną autorytatywę serwer nazw przed użyciem tych poleceń tylko do odczytu. W tych szablonach używane są zastrzeżone nazwy przykładów.
dig @ ns1.example.net example.com TXT +noall +answer dig example.com TXT +noall +answerPierwsze polecenie odpytuje określony autorytatywny serwer; drugi używa mechanizmu rozpoznawania nazw skonfigurowanego na tym komputerze. Odpowiedź z jednego rekursywnego mechanizmu rozpoznawania nazw nie dowodzi, że każdy odbiorca widzi te same dane. Jeśli to konieczne, zapytaj bezpośrednio inny znany program tłumaczący, używając @adresu-serwera.
Odpowiedź syntetyczna:
example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "Zrekonstruowana wartość:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -allBez końcowej spacji w pierwszym ciągu granica będzie wynosić 192.0.2.10ip4: 198.51.100.20 . Edytor może zaakceptować dane TXT , ale nie oznacza to, że zasada SPF jest ważna. Natomiast dwa oddzielne rekordy odpowiedzi, każdy rozpoczynający się v=spf1 stanowią problem związany z wieloma zasadami, a nie rozwiązanie polegające na dzieleniu ciągów.
Zapisz zapytany serwer, nazwę właściciela, znacznik czasu i odpowiedź. Rekonstruuj po jednym rekordzie, porównuj go z zamierzoną zasadą niepodzielenia, a następnie osobno oceniaj autoryzację nadawcy. Polecenia sprawdzają reprezentację DNS ; nie przeprowadzają pełnej oceny SPF . Widzieć RFC 7208 sekcja 3.3 do łączenia i Sekcja 4.6.4 dla limitów oceny.