Błąd długości formularza DNS może odnosić się do kilku różnych limitów. Długa wartość TXT , pojedyncza etykieta nazwy i cała nazwa DNS nie są mierzone w ten sam sposób. Skrócenie A DKIM klucz lub podział SPF zasady w oddzielnych rekordach może zamienić problem z danymi wejściowymi w błąd uwierzytelnienia.
Określ, który przedmiot jest za długi
Referencje: RFC 1035 §2.3.4, RFC 1035 §3.3, RFC 1035 §3.3.14, RFC 2181 §11.
RFC 1035 ogranicza etykietę DNS do 63 oktetów, a pełną nazwę w formacie łącznika do 255 oktetów, łącznie z polami długości i końcową etykietą główną. Interpunkcja prezentacji i dane wejściowe Unicode mogą przesłaniać te pomiary. Licz zakodowany formularz DNS , a nie tylko to, co wyświetla pole tekstowe przeglądarki. Nie stosuj na ślepo reguł dotyczących znaków nazwy hosta do etykiet usług zawierających podkreślenia.
TXT RDATA składa się z jednego lub większej liczby ciągów znaków, każdy o długości jednego oktetu, a zatem maksymalnie 255 oktetów. Nie jest to ogólny limit 255 znaków dla całości Rekord TXT. Dostawca może obsługiwać dłuższy rekord, przechowując w nim kilka ciągów, z zastrzeżeniem ograniczeń dotyczących komunikatów DNS i usług.
Podziel ciągi bez dzielenia zasad
Referencje: RFC 7208 §3.3, RFC 7208 §4.5, RFC 6376 §3.6.2.1, RFC 6376 §3.6.2.2.
W przypadku SPF ciągi w jednym rekordzie TXT są łączone bez dodatkowych spacji. Zachowaj wymagane odstępy na podzielonej granicy. Oprawa "v=spf1 ip4:192.0.2.10" " -all" rekonstruuje jedną politykę. Każdy z dwóch oddzielnych rekordów zasobów TXT v=spf1 nie są obsługiwanym sposobem jego rozszerzenia; SPF wybiera wiele zasad i zwraca trwały błąd.
Dane klucza DKIM również wymagają zachowania zamierzonej wartości. Użyj udokumentowanej metody wprowadzania długiego TXT dostawcy, a nie ręcznego obcinania. Nie dziel długo selektor etykieta poprzez wstawienie kropki: zmienia to nazwę DNS zapytaną przez weryfikatora, chyba że rzeczywista konfiguracja selektora ulegnie ciągłej zmianie.
Uruchom urządzenia skupiające się na granicach
Referencje: RFC 1035 §2.3.4, RFC 1035 §3.3.
Utwórz ciągi o dokładnie 255 ASCII a oktety i 256 znaków ASCII a oktety. Pojedynczy ciąg znaków DNS może zakodować pierwszy, ale nie może zakodować drugiego. Rekord zawierający dwa ciągi po 128 oktetów każdy jest inną, prawidłową strukturą ciągów obejmującą w sumie 256 oktetów danych. Te znaczniki nie są zasadami uwierzytelniania.
W przypadku nazw porównaj 63-oktetową etykietę ASCII z 64-oktetową etykietą, a następnie niezależnie przetestuj pełną długość nazwy przewodu. Zachowaj błąd walidacji dla każdego odrzuconego przypadku. W osobnej strefie testowej opublikuj ją Rekord SPF z dwoma ciągami, to celowo nieprawidłowy wariant dwóch rekordów zasad. Uchwyć wiarygodne granice RR przed i po poprawionej publikacji jednego rekordu. Oczekiwane wyniki aplikacji to przetwarzanie przy użyciu jednej zasady w porównaniu z przetwarzaniem wielu zasad permerror.
Te mocowania określają zachowanie brzegów. Test lokalnego kodowania może wykazać długości, ale nie może udowodnić, że dostawca DNS akceptuje formularz, aktywna strefa publikuje zamierzony zestaw RR lub odbiorca uwierzytelnia wiadomość. Wyniki wykonania muszą być rejestrowane oddzielnie.
Sprawdź powstałe dane przewodu
Referencje: RFC 7208 §3.3, RFC 6376 §3.6.2.2.
Zapytaj o dokładnego właściciela i wpisz wszystkie aktywne uprawnienia. Użyj parsera DNS , który zachowuje każdy rekord zasobu i jego listę ciągów. Rekonstruuj wartości zgodnie z protokołem zużywającym, zamiast łączyć każdą linię wyjściową. Następnie porównaj odpowiednią odpowiedź rekurencyjną i przetestuj przepływ poczty.
Jeśli formularz nadal odrzuca prawidłowe dane, przechwyć dokładny błąd i sprawdź bieżący limit specyficzny dla dostawcy. Nie dodawaj szerokiej autoryzacji SPF , nie osłabiaj klucza ani nie twórz innej polityki jako dogodnego obejścia. Prawidłowa poprawka zachowuje zarówno zamierzone bajty, jak i strukturę DNS .
Wykonano parser i dowód RRset
Zachowany zapis historyczny z dnia 7 listopada 2026 r., sprawdzony, ale nie uruchomiony ponownie na potrzeby tego przeglądu, wskazuje, że parser dnspython zaakceptował etykietę o długości 63 oktetów i nazwę przewodu o długości 255 oktetów, a odrzucił odpowiednie przypadki o długości 64 i 256 oktetów, z wyjątkami dotyczącymi długości. Rzeczywiste przechwytywanie uprawnień UDP przedstawia stan przed jako dwa oddzielne rekordy SPF TXT , a następnie stan poprawiony jako jeden rekord TXT zawierający dwa uporządkowane ciągi. Usługa przesyłania dalej zwrotnego zwróciła te same granice. To jest publikacja kontrolowana lokalnie, a nie zmiana w panelu dostawcy. permerror SPF dla przypadku dwóch zasad pozostaje oczekiwanym wynikiem zdefiniowanym przez źródło, ponieważ nie wykonano żadnego modułu oceniającego SPF . Dowód graniczny i rejestracyjny nie powinien być mylony z dowodem dostawy na żywo.
Zachowaj wyraźny zakres dowodów
Zarchiwizowany parser i przechwytywanie DNS pozostają niezmienione. W tym przeglądzie sprawdzane są zarejestrowane wyniki i oddzielnie obliczane są lokalnie granice bajtów; nie powtarza publikacji UDP, nie uruchamia ewaluatora SPF ani nie testuje formularza dostawcy. Wynik SPF z dwoma rekordami jest oczekiwaniem normatywnym, a nie przechwyconym wykonaniem uwierzytelnienia.