255 karakterlik bir sınır bildiren bir DNS düzenleyicisi mutlaka sizin SPF politikanın birden fazla kayıt haline gelmesi gerekir. DNS TXT formatı, bir kaynak kaydında birden fazla karakter dizisine izin verir. SPF içeriklerini tek bir sürekli değer olarak ele alır. Operasyonel zorluk, politikayı ve DNS yanıtlarını yönetilebilir tutarken amaçlanan metni korumaktır.
Üç farklı limiti ayırın
İlk olarak, tek bir TXT karakter dizisi 255 oktet ile sınırlıdır. SPF içeriği ASCII'dir, dolayısıyla sıradan karakterlerin her biri bir sekizliyi kaplar. Tek bir TXT kaydı birden fazla böyle dize içerebilir. RFC 7208 bölüm 3.3 bu temsile açıkça izin verir.
İkincisi, DNS yanıtının bir boyutu vardır. Yalnızca SPF metnini değil, söz konusu sahibin adına döndürülen adları, kayıt meta verilerini ve diğer TXT kayıtlarını içerir. Bölüm 3.4, SPF DNS yanıtlarının eski 512 sekizli UDP işleme için yeterince küçük tutulmasını önerir. Bu bir uyumluluk önerisidir, SPF için evrensel maksimum 512 karakterlik bir öneri değildir. Modern DNS taşıma yetenekleri her çözümleyiciyi, güvenlik duvarını veya kesme sorununu ortadan kaldırmaz.
Üçüncüsü, SPF değerlendirmesinin kaynak sınırları vardır. Metni dizelere bölmek, iç içe geçmiş işlemeyi veya aramaya neden olan on terim sınırını azaltmaz. Kısa bir politika bu değerlendirme sınırını aşabilir; açık adreslerin daha uzun bir listesi olmayabilir. Söz dizimini, DNS aktarımını ve değerlendirme maliyetini bağımsız olarak değerlendirin.
Boşlukları bilinçli olarak koruyun
SPF dizeleri boşluk eklemeden birleştirir. Bir bölge dosyası gösteriminde, "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" İlk dize bir boşlukla bittiği için amaçlanan sürekli politikayı üretir. Bu boşluğun kaldırılması iki bitişik mekanizmayı geçersiz metin halinde birleştirir.
Yukarıdaki yalnızca belgelere yönelik adresler örnek amaçlıdır. Bunlar alan adınız için yetkili değerler değildir. Tırnak işaretleri bölge dosyası sunum sözdizimidir; bunları barındırılan bir DNS düzenleyicisine girip girmemeniz o sağlayıcının belgelenmiş arayüzüne bağlıdır. Bazı düzenleyiciler uzun değerleri otomatik olarak bölerken diğerleri ayrı dize alanları ortaya çıkarır. Editörün ekranının tel formatıyla eşleştiğini varsaymak yerine sunulan yanıtı doğrulayın.
Başlangıçta ikinci bir TXT kaynak kaydı oluşturmayın v=spf1 geri kalanını tutmak için. Çoklu seçildi SPF kayıtları üretmek permerror. Bunun tersine, bir tanılama aracında birden fazla TXT yanıtı görüntülendiğinden ilgisiz TXT doğrulama kayıtlarını silmeyin.
Yayınlanan değeri inceleyin
Yetkili TXT yanıtını yakalayın ve her kaynak kaydına hangi dizelerin ait olduğunu belirleyin. Yalnızca tek bir kayıt içindeki dizeleri birleştirerek SPF değerini yeniden oluşturun. Her bölünmüş sınırdaki boşlukları kontrol edin ve tek bir sürüm işaretçisinin, geçerli mekanizmaların ve amaçlanan son ifadenin olduğundan emin olun.
Daha sonra önemli ağlardan gelen özyinelemeli DNS yanıtlarını test edin. Yanıt kesilirse veya çözüm başarısız olursa rastgele mekanizmaları silmek yerine DNS aktarımını ve sağlayıcı yapılandırmasını araştırın. DNSSEC ve daha geniş yanıt seti yanıt boyutunu etkileyebilir; basit bir karakter sayımı, tam paket boyutunda bir test değildir.
Akıllı paketleme yerine politika temizlemeyi tercih edin
Büyüyen bir politika genellikle hizmetlerin biriktiğine işaret eder. Karmaşıklığı artırmadan önce eski içerikleri, gereksiz derecede geniş mekanizmaları ve yinelenen yetkilendirmeleri gözden geçirin. Yalnızca kaydı kısaltmak veya yeniden şekillendirmek için mevcut IP adreslerini kopyalamak yerine, uygun olduğunda mevcut sağlayıcı tarafından yönetilen mekanizmaları koruyun. Sağlayıcılar altyapıyı değiştirdiğinde manuel olarak düzleştirilen adresler eskimiş hale gelebilir.
Hâlâ birden fazla dizeye ihtiyaç duyan bir politika için, amaçlanan bölünmemiş metni yayınlanan gösterimin yanına kaydedin. Bu, gelecekteki yöneticilere istikrarlı bir karşılaştırma hedefi sağlar. Zararsız bir düzenleyici yeniden formatı, anlamsal politika değişikliğiyle karıştırılmamalıdır.
Okuyucuya yönelik sonucu doğrulayın
Onaylanan bir değişiklikten sonra, temsili kaynakları ve eşleşmeyen bir kaynağı standartlara uygun bir değerlendiriciyle test edin, ardından gerçek güvenilir alıcı sonuçlarını inceleyin. Yeniden oluşturulan değeri, yanıt gözlemlerini ve değerlendirme sonuçlarını kaydedin. Yalnızca düzenleyicinin kaydetmeyi kabul etmesiyle değil, hem DNS temsili hem de yetkilendirme davranışı doğru olduğunda sorunu kapatın.
Bir sorgu cevabını yeniden yapılandırma
Aşağıdaki sentetik bir teşhis uygulamasıdır, çalıştırdığımız bir sorgu değil veya bir kayıt yayınlamak. Gerçek SPF sahibinin adını ve doğrulanmış bir yetkiliyi değiştirin ad sunucusu Bu salt okunur komutları kullanmadan önce. Bu şablonlar ayrılmış örnek adları kullanır.
dig @ ns1.example.net example.com TXT +hepsi +yanıt dig example.com TXT +hepsi +yanıtİlk komut belirtilen yetkili sunucuya sorar; ikincisi o makinede yapılandırılmış çözümleyiciyi kullanır. Bir özyinelemeli çözümleyiciden gelen yanıt, her alıcının aynı verileri gördüğünü kanıtlamaz. Gerekirse, @server-address ile bilinen başka bir çözümleyiciyi açıkça sorgulayın.
Sentetik cevap:
example.com . 300 IN TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "Yeniden oluşturulan değer:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -allİlk dizenin sonundaki boşluk olmadan sınır 192.0.2.10ip4: 198.51.100.20 olur. Editör TXT verilerini kabul edebilir ancak bu, SPF politikasını geçerli kılmaz. Buna karşılık, her biri v=spf1 ile başlayan iki ayrı yanıt kaydı, dizeleri bölme çözümü değil, çoklu politika sorunudur.
Sorgulanan sunucuyu, sahibi adını, zaman damgasını ve yanıtı kaydedin. Her seferinde bir kaydı yeniden oluşturun, bunu amaçlanan bölünmemiş politikayla karşılaştırın ve ardından gönderenin yetkilendirmesini ayrı ayrı değerlendirin. Komutlar DNS temsilini denetler; tam bir SPF değerlendirmesi yürütmezler. Görmek RFC 7208 Bölüm 3.3 birleştirme için ve Bölüm 4.6.4 değerlendirme sınırları için.