SPF çok fazla DNS sorgusu: 10 sorgu sınırı ve permerror nasıl düzeltilir

“Too many DNS lookups” ne anlama gelir?

Alıcı sunucu SPF’i kontrol ederken zarf göndericisi alan adındaki (MAIL FROM adresi, sonradan Return-Path olarak görünür) v=spf1 ile başlayan TXT kaydını okur ve terimlerini soldan sağa değerlendirir. Bazı terimler alıcının yeniden DNS sorgulamasına yol açar. RFC 7208, bölüm 4.6.4 bu terimleri, include ettiğiniz her kaydın içindekiler dahil, kontrol başına 10 ile sınırlar. Bir değerlendirme on birincisini gerektirdiğinde alıcı durmalı ve permerror döndürmelidir; bu, yayımlanan kaydın doğru yorumlanamadığını belirten sonuçtur.

Bunu genellikle üç yerde fark edersiniz: teslim edilmiş bir iletinin Authentication-Results başlığında (RFC 8601), örneğin spf=permerror smtp.mailfrom=example.com; çok sayıda sorgudan söz eden bir geri dönüş (bounce) iletisinde; ya da DMARC toplu raporlarındaki SPF hatalarında.

İki ayrıntı hatayı kafa karıştırıcı yapar. Alıcılar sorguları değerlendirme sırasında sayar ve değerlendirme eşleşen ilk terimde durur. Listede erken yer alan bir servisin postası yine geçebilir; include’u onuncu sorgudan sonra gelen servisin postası ise permerror alır, bu yüzden sorun aralıklı görünebilir. Ayrıca permerror bir fail değildir: SPF yalnızca yardımcı olmayı bırakır. DMARC, From adresiyle hizalı bir alan adı için SPF veya DKIM geçtiğinde geçer (RFC 9989); dolayısıyla hizalı DKIM imzası olan ileti yine geçer, yalnızca SPF’e dayanan ileti geçmez. Bunun ötesinde alıcının permerror’a nasıl davranacağı kendi kararıdır.

Hangi SPF terimleri sınıra sayılır, hangileri sayılmaz?

Bütçe tek bir kayda değil, tüm değerlendirmeye aittir. Bir include kendisi için bir sorgu, ardından arkasındaki kaydın en son iç içe düzeye kadar harcadığı kadar sorgu tutar. Sağlayıcılar kendi kayıtlarını değiştirir, örneğin adres aralıklarını daha fazla iç içe include’a yayarlar; bu yüzden sizin tarafınızda hiçbir değişiklik olmadan toplam değişebilir.

Sınır var çünkü SPF kayıtları alıcıların yayımlayan adına DNS sorgusu göndermesini sağlar; RFC 7208’in 11.1 bölümü, bir saldırganın bunu üçüncü bir tarafın DNS’ini boğmak için nasıl kullanabileceğini anlatır. RFC ayrıca tüm kontrol için en az 20 saniyelik bir zaman sınırı önerir. Sürenin dolması permerror değil, geçici hata olan temperror verir.

İkinci sınır: en fazla iki void lookup

RFC 7208, boş dönen sorgular için ayrı bir sınır ekler: kaydı olmayan bir yanıt (cevap sayısı sıfır olan NOERROR) veya Name Error (NXDOMAIN, ad mevcut değil). Bunlara void lookup denir. Uygulamalar ikiden fazlasına izin vermemelidir (SHOULD) ve aşılması, toplam hâlâ 10’un altında olsa bile permerror verir. Bu, bir SPF kaydının alıcıları var olmayan uzun ad listelerinin peşine düşürmesini engeller.

Void lookup’lar çoğunlukla artık kalıntılardan gelir:

• Eski sunucunun DNS adı silindikten sonra kalan a:old-web.example.com.
• MX kaydı olmayan bir adda mx veya mx:example.org. Mekanizma adın A kaydına geri düşmemelidir, bu yüzden hiçbir şey bulamaz.
• Web sitesi yalnızca www üzerinde yanıt veren bir sunucuya taşındıktan sonra çıplak alan adındaki a.

include: bundan daha katıdır. Include edilen ad yoksa veya SPF kaydı yayımlamıyorsa include yalnızca void sayılmaz: tüm sonucu hemen permerror yapar (bölüm 5.2). Kullanmayı bıraktığınız bir sağlayıcı, kaydınızın hâlâ include ettiği alan adını kapattığında olan budur. Kaydınızın işaret ettiği her adı sorgulayın; hiçbir şey döndürmeyen ad düzeltilmeli veya kaldırılmalıdır.

SPF sorgularını elle nasıl sayarsınız?

Gönderdiğiniz bir iletinin Return-Path başlığından okuyabileceğiniz zarf göndericisi alan adından başlayın ve kaydı özyinelemeli olarak izleyin:

1. Kaydı okuyun: dig +short TXT example.com veya Windows’ta nslookup -type=TXT example.com.
2. include, a, mx, ptr, exists ve redirect için 1; ip4, ip6 ve all için 0 puan verin.
3. Her include ve redirect için işaret ettiği kaydı okuyun ve iç içe ne kadar derinse o kadar aynı şekilde puanlayın.
4. Hepsini toplayın ve kayıt döndürmeyen adları not edin.

İşte yüzeyde yalnızca beş DNS sorgulayan terimi olan varsayımsal bir kayıt:

example.com.  TXT  "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:news.example.net a -all"

Toplam en kötü durumdur. İlk include ile eşleşen bir gönderen en fazla beş sorguya ihtiyaç duyar ve geçer. Daha önce hiçbir şeyle eşleşmeyen bir gönderen son a terimine, yani on birinci sorguya ulaşır; böylece sahte posta, -all’un üretmesi amaçlanan fail yerine permerror alır. Yeni bir gönderim servisi eklediğinizde ve zaman zaman bunun dışında da yeniden sayın, çünkü include edilen kayıtlar haber verilmeden değişir.

E-posta kaybetmeden ona nasıl inersiniz?

• Artık kullanmadığınız include’ları kaldırın. Önceki bir posta kutusu sağlayıcısı, iptal ettiğiniz bir bülten aracı, bir CRM denemesi. DMARC toplu raporları, alan adınız adına gerçekte hangi kaynakların gönderdiğini gösterir; bu da kimsenin ihtiyaç duymadığı include’ları fark etmenize yardım eder. Kaldırmadan önce her servisin sahibine danışın.
• Bir include’un hiç değerlendirilip değerlendirilmediğini kontrol edin. SPF, zarf göndericisi alan adına karşı kontrol edilir. Bir servisin iletileri Return-Path’te kendi alan adını gösteriyorsa alıcılar sizin değil, o alan adının SPF kaydını kontrol eder ve include’unuz o posta için hiçbir işe yaramaz. Kaldırmadan önce sağlayıcının belgelerinden doğrulayın.
• Kontrol ettiğiniz sunucular için a ve mx yerine ip4 ve ip6 kullanın. Kendi sunucunuz 192.0.2.10’dan gönderiyorsa ip4:192.0.2.10 hiçbir şeye mal olmaz, a ise bir sorgu harcar. mx’in orada gerçekten gerekli olup olmadığını sorgulayın: postanızı alan sunucular onu göndermek zorunda değildir ve posta kutusu sağlayıcınıza aitlerse include’u gönderim sunucularını zaten listeliyor olabilir. Sunucu taşındığında adresi güncelleyin.
• Yüksek hacimli her göndericiye kendi alt alan adını verin. Bir bülten veya destek talebi servisinin zarf göndericisi olarak news.example.com gibi bir bounce alan adı kullanmasına izin verin; kendi SPF kaydı ve kendi 10’luk sınırı olur. SPF miras alınmaz, bu yüzden alt alan adının o kayda ihtiyacı vardır. DMARC’ın varsayılan gevşek (relaxed) hizalamasında news.example.com, example.com’daki bir From adresiyle yine hizalanır. Birçok servis buna özel return-path veya bounce alan adı der.
• ptr’yi bırakın. RFC 7208 bunun yayımlanmaması gerektiğini söyler: yavaştır, bağlanan IP adresinin sahibinin denetlediği ters DNS’e dayanır ve sorgu bütçesini tüketir. Yerine ip4/ip6 veya sağlayıcının include’unu kullanın.
• Yeniden sıralamayı çözüm saymayın. En yoğun göndericiyi öne taşımak, on birinci sorguya daha az iletinin ulaşması demektir; ama kayıt, -all’a takılması gereken sahte posta dahil, aşağıdaki her şey için bozuk kalır.

DKIM de baskıyı azaltır. DMARC yalnızca bir hizalı geçişe ihtiyaç duyar ve DKIM genellikle iletmeden (forwarding) sağ çıkarken SPF çıkamaz. Her servisin sizin alan adınızla imzaladığından emin olun, sonra SPF kaydını sadeleştirin.

SPF flattening: daha az sorgu, daha fazla bakım

Flattening, bir include’u bugün çözümlendiği ip4 ve ip6 aralıklarıyla değiştirir. Sorgu sayısı düşer, ancak kaydınız artık başkasının listesinin bir kopyasını taşır ve bu kopya kendini güncellemez.

Otomatik flattening servisleri include’ları belirli aralıklarla çözümler ve kaydınızı yeniden yazar. Bu, eskimiş aralıkları halleder ama DNS’inizde üçüncü bir tarafa rol verir ve başarısız bir güncelleme SPF’inizi bozar. Önce diğer çözümleri deneyin. Flatten ederseniz hangi include’u ne zaman değiştirdiğinizi not edin, sağlayıcının yayımladığı aralıklarla düzenli karşılaştırın ve her değişiklikten sonra SPF’i test edin (Microsoft Learn kendi müşterilerine aynı tavsiyeyi verir).

Ad başına tek SPF kaydı ve doğru bölme

Bir adın v=spf1 ile başlayan tam olarak bir TXT kaydı olmalıdır. İki tane olursa alıcı seçim yapamaz ve permerror döndürür (RFC 7208, bölüm 4.5). Bu genellikle yeni bir servisin kurulum kılavuzu “bu TXT kaydını ekleyin” dediğinde, biri ilk kaydı düzenlemek yerine ikinci bir SPF kaydı eklediğinde olur. İkinci kayıt bütçeyi ikiye katlamaz; ikisini birleştirin:

# Wrong: two SPF records on one name
example.com.  TXT  "v=spf1 include:_spf.mail.example.net -all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

# Right: one record
example.com.  TXT  "v=spf1 include:_spf.mail.example.net include:spf.crm.example.org -all"

Aynı addaki site doğrulama belirteçleri gibi diğer TXT kayıtları sorun değildir; yalnızca v=spf1 ile başlayanlar sayılır. Bir TXT kaydı içindeki tek bir dize en fazla 255 karakter tutar. Daha uzun bir SPF kaydı, birkaç tırnaklı dizeden oluşan tek bir TXT kaydı olarak kalır; alıcılar bunları araya boşluk eklemeden birleştirir (bölüm 3.3), bu yüzden bir terimin bittiği yerde dizeyi boşlukla bitirin:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.mail.example.net " "include:spf.crm.example.org -all"

Başka birkaç hata da aynı permerror’u üretir: kaydın herhangi bir yerinde include: yerine include= yazmak gibi sözdizimi hataları (bölüm 4.6) veya SPF kaydı olmayan bir alan adını include etmek. SPF kayıtları miras da alınmaz; zarf göndericisi olarak kullanılan her ad kendi kaydına ihtiyaç duyar ve her birinin kendi 10 sınırı vardır.

Ücretsiz SPF ve DMARC kontrolü neyi sayar?

Ücretsiz Yayına Hazırlık Snapshot’ı, kayıt olmadan tek bir herkese açık alan adında sekiz pasif kontrol çalıştırır; bunlardan biri e-posta DNS kayıtlarını okur. Pentest değildir, altı alanlı denetim de değildir ve e-posta göndermez.

• Tam ana makine adı. Girdiğiniz addaki SPF kaydını, üst alan adına geri dönmeden okur. Zarf göndericisi alan adının kendisini girin; örneğin www.example.com değil, example.com.
• Üst düzey sayım. O kayıttaki DNS sorgulayan terimleri (include, a, mx, ptr, exists ve redirect) sayar ve ondan fazlasını orta risk sinyali olarak işaretler.
• İzlenmeyenler. include: veya redirect= izlemez, void lookup saymaz ve aynı addaki ikinci bir SPF kaydını işaretlemez. Yukarıdaki beş terimli örnek, alıcılar on bir sorguya ihtiyaç duysa da bu sayımdan geçer; bu yüzden özyinelemeli sayımı kendiniz de yapın.
• Diğer SPF sinyalleri. +all yüksek, ?all düşük risk olarak işaretlenir; ana makinede MX kayıtları varsa eksik SPF veya DMARC kaydı işaretlenir.

E-posta DNS kontrolünü önce açmak için ücretsiz SPF ve DMARC kontrolünü kullanın: aynı snapshot’ı çalıştırır ve bu kontrolü diğer yedisinin üstünde gösterir. Kaydın geri kalanı için, ~all ile -all farkından DMARC’ı none’dan reject’e taşımaya kadar, SPF ve DMARC rehberine bakın.