Kimlik doğrulama kaydı, başka bir kuruluşun ad sunucularına veya kayıtlarına bağlıyken DNS konsolunda yerel görünebilir. Kullanılabilirliği değerlendirmek için tedarikçileri saymak veya gösterge tablosunun çalışma süresi rakamına bakmak yerine çözüm ve kimlik doğrulama yolunu izleyin. Yararlı soru, bir alıcı bu özel mesajı değerlendirirken hangi bağımlılığın cevaplanması gerektiğidir.
Delegasyon mekanizmalarını ayırt edin
Yetki verilen bir DNS bölgesi, bölge sınırının altındaki adlara ilişkin yetkiyi belirtilen ad sunucularına aktarır. A CNAME Bir ismi başka bir isme işaret eder. SPF dahil etme ve yönlendirme, bölge delegasyonu değil, uygulama düzeyindeki politika ilişkileridir. Farklı hata yolları oluştururlar ve birbirinin yerine kullanılabilen barındırma biçimleri olarak değerlendirilemezler. RFC 1034 yetkili hizmeti ve özyinelemeli çözümü açıklar; RFC 7208 SPF DNS kullanımını belirtir.
Her adım için tam sahip adını ve kayıt türünü çizin. İçin DKIM bu şununla başlıyor seçici imzalama alanı için _domainkey altında. SPF için ilgili kimliği doğrulanmış kimlikle başlayın ve politika şartlarını izleyin. İçin DMARC, politika-keşif bağımlılığını ayrı ayrı değerlendirin. Bir sağlayıcı üçüncüyü çalıştırmadan bunlardan ikisini çalıştırabilir.
Yalnızca çalışma süresini değil, arıza anlamını da kaydedin
Hedefin hiçbir veri döndürmemesi, açık bir olumsuz yanıt vermesi, hatalı biçimlendirilmiş bir politika veya zaman aşımı yaşaması durumunda ne olacağını sorun. Bunlar eşdeğer değil. SPF kalıcı ve geçici hata sonuçlarını tanımlamıştır. DKIM doğrulaması, mevcut olmayan veya geçersiz anahtar bilgilerinden etkilenebilir. Bir alıcının nihai ileti işlemesi aynı zamanda başka bir hizalanmış kimlik doğrulama yoluna ve yerel politikaya da bağlı olabilir; bu nedenle, bir arama hatasının postayı her zaman engelleyeceğini veya her zaman teslim edeceğini vaat etmekten kaçının.
Önbelleğe alma, daha önceki kullanılabilir bir yanıtı geçici olarak koruyabilir, ancak sınırsız bir yedekleme değildir. Cevabın TTL'sini ve gözlem süresini kaydedin. Olumsuz yanıtlar, bölümünde açıklanan kurallar uyarınca da önbelleğe alınabilir. RFC 2308. Artık bir TTL'yi azaltmak, halihazırda başka bir yerde önbelleğe alınmış yanıtların ömrünü geriye dönük olarak kısaltmaz.
İki kurtarma bağımlılığını karşılaştırın
Onaylanmış bir yetkili sorgunun yeni yapılandırılmış bir seçici hedefi döndürdüğünü, yinelemeli bir çözümleyicinin ise hâlâ daha önce önbelleğe alınmış hedefi döndürdüğünü varsayalım. Hem kaynakları hem de zaman damgalarını kaydedin. Yetkili değişiklik bu sunucuda gözlemlenir; tüm alıcıların yeni hedefi kullandığını kanıtlamaz. Şimdi, yedek imzalama hizmetinin ilgili özel anahtardan yoksun olduğunu varsayalım. İlgili her arama düzeltildikten sonra bile DNS tek başına bu hizmetin başarıyla imzalanmasını sağlayamaz.
Bunlar varsayımsal gözlemlerdir, yerel bir DNS laboratuvarı veya üretim testi değildir. Bunlar ayrı ayrı sonraki adımlara yol açar: Onaylanmış görüş noktalarında önbelleği ve hedef çözümlemeyi doğrulamak ve yedek imzalayanın gerçek yapılandırmasını ve mesaj çıktısını doğrulamak. Sunucuyu, adı, türü, yanıt kodunu, işaretleri, TTL'yi ve tam yanıtı saklayın. Bu örnek alıştırma yapmıyor DNSSEC, yönlendirmeler veya olumsuz önbelleğe alma; mimarinin gerektirdiği yerlerde bunları bağımsız olarak test edin.
Bağımlılığın kabul edilebilir olup olmadığına karar verin
Her bir dış hedefe bir sahip atayın ve tedarikçinin fiili kurtarma ve çıkış düzenlemelerini belgeleyin. Kaydı değiştirip değiştiremeyeceğinizi, gerekli genel meta verilere sahip olup olmadığınızı ve imzalama değişikliğinin başka bir hizmet içinde işlem gerektirip gerektirmediğini düşünün. Aynı yetkili altyapı üzerindeki birden fazla kontrol paneli, bu paylaşılan bağımlılığı ortadan kaldırmaz.
Değişimi yetkili bir ortamda test edin ve gözlem yerine bir kesintinin ne zaman bir değişikliği tetiklediğini tanımlayın. Aceleye getirilmiş bir düzenleme, bir SPF hatası ekleyebilir veya seçiciyi yanlış anahtara yönlendirebilir. Önceki kaydı ve karar günlüğünü saklayın, ancak kurtarmanın önbellekler ve erişim kaybı nedeniyle kısıtlandığını unutmayın. Sonuç, tüm DNS yetkilendirmesinin güvensiz olduğu iddiası değil, kanıtlarla birlikte bağımlılığa özgü bir risk kararı olmalıdır.