Czy zwykle obowiązuje limit wyszukiwania 10 DNS w specyfikacji SPF?

Rozumiem, że specyfikacja SPF określa, że ​​odbiorca wiadomości e-mail nie powinien wykonywać więcej niż 10 wyszukiwań DNS w celu zebrania wszystkich dozwolonych adresów IP dla nadawcy. Więc jeśli rekord SPF ma, include:foo.com include:bar.com include:baz.coma każda z tych trzech domen ma rekordy SPF, które również mają 3 includewpisy, teraz mamy do 3 + 3 + 3 + 3 = 12 wyszukiwań DNS.

1. czy moje zrozumienie powyżej jest prawidłowe?

2. W mojej domenie korzystam tylko z 2 lub 3 usług i już przekroczyłem ten limit. Czy ten limit jest zazwyczaj (lub kiedykolwiek) egzekwowany przez głównych / mniejszych dostawców poczty e-mail?

Zarówno libspf2(C), jak i Mail::SPF::Query(perl, używane w sendmail-spf-milter ) implementują limit 10 mechanizmów powodujących DNS , ale ten drugi nie stosuje (AFAICT) limitów MX ani PTR. libspf2ogranicza także każdy z mx i ptr do 10.

Mail::SPF(perl) ma limit 10 mechanizmów powodujących DNS i limit 10 wyszukiwań na mechanizm, na MX i na PTR. (Dwa pakiety perla są zwykle, choć nie domyślnie, używane w MIMEDefang .)

pyspfma ograniczenia 10 na wszystkich: „odnośnikach”, MX, PTR, CNAME; ale podczas operacji wyraźnie pomnaża MAX_LOOKUPS przez 4. O ile nie jest w trybie „ścisłym”, mnoży również MAX_MX i MAX_PTR przez 4.

Nie mogę komentować komercyjnych / zastrzeżonych implementacji, ale powyższe (z wyjątkiem pyspf) wyraźnie implementują górny limit 10 mechanizmów wyzwalających DNS (więcej na ten temat poniżej), daj lub bierz, chociaż w większości przypadków można to zmienić podczas uruchamiania czas.

W twoim konkretnym przypadku masz rację, to 12 obejmuje i to przekracza limit 10. Spodziewałbym się, że większość oprogramowania SPF zwróci „PermError”, jednak niepowodzenia wpłyną tylko na ostatecznego dostawcę (-ów), ponieważ liczba będzie obliczany jako bieżąca suma: mechanizmy SPF są oceniane od lewej do prawej, a kontrole będą „wcześnie wychodzić” podczas przejścia, więc zależy to od tego, w której sekwencji pojawia się serwer wysyłający.

Rozwiązaniem tego problemu jest użycie mechanizmów, które nie wyzwalają wyszukiwania DNS, np. ip4I ip6, a następnie użycie, mxjeśli to możliwe, ponieważ daje to do 10 kolejnych nazw, z których każda może mieć więcej niż jeden adres IP.

Ponieważ SPF powoduje dowolne żądania DNS z potencjalnie skalowaniem wykładniczym, można go łatwo wykorzystać do ataków DOS / wzmocnienia. Ma celowo niskie limity, aby temu zapobiec: nie skaluje się tak, jak chcesz.

10 mechanizmów (ściśle mechanizmy + modyfikator „przekierowania”) powodujących wyszukiwanie DNS nie jest dokładnie tym samym, co 10 wyszukiwania DNS. Nawet „wyszukiwania DNS” są otwarte na interpretację, nie wiesz z góry, ile wymaganych jest wyszukiwań dyskretnych, i nie wiesz, ile wyszukiwań dyskretnych może być konieczne wykonanie przelicznika rekurencyjnego (patrz poniżej).

RFC 4408 §10.1 :

Implementacje SPF MUSZĄ ograniczyć liczbę mechanizmów i modyfikatorów, które wykonują wyszukiwania DNS, maksymalnie do 10 na sprawdzenie SPF, w tym wszelkie wyszukiwania spowodowane użyciem mechanizmu „włącz” lub modyfikatora „przekierowania”. Jeśli liczba ta zostanie przekroczona podczas sprawdzania, MUSI zostać zwrócony błąd PermError. Mechanizmy „włącz”, „a”, „mx”, „ptr” i „istnieje”, a także modyfikator „przekierowania” liczą się do tego limitu. Mechanizmy „all”, „ip4” i „ip6” nie wymagają wyszukiwania DNS i dlatego nie liczą się do tego limitu.

[...]

Podczas oceny mechanizmów „mx” i „ptr” lub makra% {p} MUSI istnieć limit nie więcej niż 10 MX lub PTR RR sprawdzonych i sprawdzonych.

Możesz więc użyć do 10 mechanizmów / modyfikatorów, które wyzwalają wyszukiwanie DNS. (Sformułowanie tutaj jest kiepskie: wydaje się, że określa ono jedynie górną granicę limitu, implementacja potwierdzająca może mieć limit 2).

§5.4 dla mechanizmu mx i §5.5 dla mechanizmu ptr ma limit 10 wyszukiwań tego rodzaju nazwy, i dotyczy to tylko przetwarzania tego mechanizmu, np .:

Aby zapobiec atakom typu „odmowa usługi” (DoS), NIE MOŻNA wyszukiwać ponad 10 nazw MX podczas oceny mechanizmu „mx” (patrz rozdział 10).

tzn. możesz mieć 10 mechanizmów MX z maksymalnie 10 nazwami MX, więc każdy z nich może spowodować 20 operacji DNS (10 MX + 10 wyszukiwań DNS każdy) w sumie 200. To jest podobne dla ptr lub % {p} , ty może wyszukiwać mechanizmy 10 ptr , stąd 10x10 PTR, każdy PTR również wymaga wyszukiwania A, ponownie w sumie 200.

Dokładnie to sprawdza zestaw testów 2009.10 , zobacz testy „ Limity przetwarzania ”.

Nie ma jasno określonego górnego limitu całkowitej liczby operacji wyszukiwania DNS klienta na sprawdzenie SPF, obliczam to domyślnie jako 210, daję lub biorę. Istnieje również sugestia ograniczenia objętości danych DNS na sprawdzenie SPF, jednak nie sugeruje się faktycznego limitu. Możesz uzyskać przybliżone oszacowanie, ponieważ rekordy SPF są ograniczone do 450 bajtów (co niestety jest współużytkowane ze wszystkimi innymi rekordami TXT), ale suma może przekroczyć 100 kB, jeśli jesteś hojny. Obie te wartości są wyraźnie otwarte na potencjalne nadużycie jako atak wzmacniający, czego dokładnie wymaga §10.1.

Empirycznych dowodów sugeruje sumie 10 mechanizmów wyszukiwania jest powszechnie wdrażane w ewidencji (sprawdź SPF dla microsoft.com, którzy wydają się już do pewnych starań, aby go dokładnie 10 zachować). Trudno jest zebrać dowody niepowodzenia zbyt wielu wyszukiwań, ponieważ wymagany kod błędu to po prostu „PermError”, który obejmuje wszystkie rodzaje problemów ( może to jednak pomóc raportowanie DMARC ).

Często zadawane pytania dotyczące OpenSPF utrwalają limit „10 wyszukiwań DNS”, a nie bardziej precyzyjny „10 mechanizmów powodujących DNS lub przekierowań”. To FAQ jest prawdopodobnie błędne, ponieważ faktycznie mówi:

Ponieważ istnieje limit 10 wyszukiwań DNS na rekord SPF, określenie adresu IP [...]

który nie zgadza się z RFC, która nakłada ograniczenia na operację „sprawdzania SPF”, nie ogranicza w ten sposób operacji wyszukiwania DNS i wyraźnie stwierdza, że rekord SPF jest pojedynczym tekstem RR RR. Często zadawane pytania sugerują, że restartujesz liczenie podczas przetwarzania „dołączenia”, ponieważ jest to nowy rekord SPF. Co za bałagan.

Wyszukiwanie DNS

Co to właściwie jest „wyszukiwanie DNS”? Jako użytkownik . Uważam, że „ ping www.microsoft.com” dotyczy pojedynczego „wyszukiwania DNS”: jest jedna nazwa, którą spodziewam się przekształcić w jedno IP. Prosty? Niestety nie.

Jako administrator wiem, że www.microsoft.com może nie być zwykłym rekordem A z pojedynczym adresem IP, może to być CNAME, który z kolei potrzebuje innego dyskretnego wyszukiwania, aby uzyskać rekord A, chociaż taki, który prawdopodobnie wykona mój poprzedni program rozpoznawania nazw zamiast resolvera na moim pulpicie. Dziś dla mnie www.microsoft.com to łańcuch 3 CNAME, które ostatecznie kończą się jako rekord A na stronie akamaiedge.net, czyli (przynajmniej) 4 operacje zapytań DNS dla kogoś. SPF może widzieć CNAME z mechanizmem „ptr”, jednak rekord MX nie powinien być CNAME.

Wreszcie, jako administrator DNS wiem, że udzielenie odpowiedzi (prawie) na każde pytanie wiąże się z wieloma dyskretnymi operacjami DNS, pojedynczymi pytaniami i transakcjami odpowiedzi (datagramy UDP) - przy założeniu pustej pamięci podręcznej rekurencyjny program rozpoznawania nazw musi zacząć od katalogu głównego DNS i działać po swojemu w dół: . → com→ microsoft.com→ www.microsoft.compytanie o określone typy rekordów (NS, A itp.) zgodnie z wymaganiami i postępowanie z CNAME. Możesz to zobaczyć w akcji dig +trace www.microsoft.com, chociaż prawdopodobnie nie uzyskasz tej samej odpowiedzi z powodu oszustw związanych z geolokalizacją (przykład tutaj ). (Ta złożoność jest nawet nieco większa, ponieważ bariery SPF na rekordach TXT, a przestarzałe limity 512 bajtów na odpowiedzi DNS mogą oznaczać ponawianie zapytań przez TCP).

Co zatem SPF uważa za wyszukiwanie? Jest naprawdę najbliżej punktu widzenia administratora , musi być świadomy specyfiki każdego rodzaju zapytania DNS (ale nie do punktu, w którym faktycznie musi liczyć poszczególne datagramy lub połączenia DNS).

RFC4408 s10.1 , jak zauważyłeś, nakłada pewne ograniczenia na aktywność DNS. Konkretnie:

Implementacje SPF MUSZĄ ograniczyć liczbę mechanizmów i modyfikatorów, które wykonują wyszukiwania DNS, maksymalnie do 10 na sprawdzenie SPF, w tym wszelkie wyszukiwania spowodowane użyciem mechanizmu „włącz” lub modyfikatora „przekierowania”. Jeśli liczba ta zostanie przekroczona podczas sprawdzania, MUSI zostać zwrócony błąd PermError. Mechanizmy „włącz”, „a”, „mx”, „ptr” i „istnieje”, a także modyfikator „przekierowania” liczą się do tego limitu. Mechanizmy „all”, „ip4” i „ip6” nie wymagają wyszukiwania DNS i dlatego nie liczą się do tego limitu. Modyfikator „exp” nie wlicza się do tego limitu, ponieważ wyszukiwanie DNS w celu pobrania ciągu objaśnienia następuje po ocenie rekordu SPF.

a ponadto

Podczas oceny mechanizmów „mx” i „ptr” lub makra% {p} MUSI istnieć limit nie więcej niż 10 MX lub PTR RR sprawdzonych i sprawdzonych.

Zauważ, że to pierwsze ogranicza liczbę mechanizmów , a nie liczbę wykonanych przeglądów; ale wciąż jest limit.

O ile mogę powiedzieć, tak, limity te są egzekwowane dość mocno. Zostały zaprojektowane tak, aby powstrzymywać ludzi przed tworzeniem dowolnie złożonych rekordów SPF i wykorzystywaniem ich do serwerów DoS, które sprawdzają ich zapis, zatrzymując je w ogromnym łańcuchu wyszukiwań DNS, więc jest to w najlepszym interesie każdego, kto wdraża sprawdzanie SPF w celu uszanuj ich.

Masz rację, zauważ, że zagnieżdżone dołączenia mogą powodować największy problem z tymi limitami, a jeśli zdecydujesz się na dołączenie kilku domen, z których każda sama intensywnie wykorzystuje dołączenia, możesz dość szybko je przejrzeć. Nietrudno jest znaleźć przykłady ludzi, dla których stworzyło to konkretne problemy .

Rezultatem wydaje się być to, że problemy zwykle pojawiają się, gdy ludzie decydują się na użycie zarówno SPF, jak i kilku różnych i odmiennych firm do obsługi wychodzących wiadomości e-mail. Wnioskuję z twojego pytania, że ​​pasujesz do tej kategorii. Wydaje się, że SPF nie jest przeznaczony do obsługi ludzi, którzy zdecydują się to zrobić . Jeśli nalegasz na zrobienie tego, prawdopodobnie będziesz musiał mieć jakieś zadanie cron na serwerze DNS, które stale ocenia wszystkie rekordy SPF, które chciałbyś uwzględnić, wyraża je jako serię ip4:i ip6:mechanizmy (na liczbę których nie ma limitu) i ponownie publikuje wynik jako rekord SPF.

Nie zapomnij dokończyć -all, bo całe ćwiczenie było bezcelowe.