[ DNS ve alanlar ]

Yetkili ve özyinelemeli DNS yanıtları karşılaştırıldı

DNS anlaşmazlıklarının doğru kimlik doğrulama incelemesine yol açması için bir bölgenin yetkili yanıtını çözümleyicinin yanıtından ayırın.

EmailAuth araştırma ekibi tarafından · 6 dakikalık okuma

[ Anahtar noktalar ]

  • Doğrudan yetkili gözlem ve özyinelemeli gözlem farklı soruları yanıtlar.
  • RD ve RA, bir yanıtın yeni çözüldüğünü göstermez.
  • Tutarlı adlar, uç noktalar, zamanlar, işaretler ve aktarım, karşılaştırmaları faydalı kılar.
Bu sayfada

Cevabı kimin ürettiğini sorun

İki DNS araması, her iki araç da bozulmadan aynı fikirde olmayabilir. Yetkili bir sunucudan bölgenin güncel verileri istenebilir; bir başkası daha önceki bir cevabı tutan özyinelemeli bir çözümleyiciye sorabilir. Yararlı bir kimlik doğrulama araştırması, herhangi bir arama sitesinden gelen yeşil kontrolü etki alanının son durumu olarak ele almak yerine, her bir gözlemin hangi yolu ürettiğini kaydeder.

Yetkili bir sunucu, hizmet verdiği bölgelerden yanıt verir. Özyinelemeli çözümleyici, müşteri adına çalışır, diğer sunuculara danışır veya önbelleğe alınmış bilgileri yeniden kullanır. Saplama çözümleyici genellikle soruları yinelemeli bir hizmete iletir. Aynı yazılım birden fazla rolü yerine getirebilir; dolayısıyla bir ürün adına güvenmek yerine bu özel yanıtın rolünü tanımlayın. RFC 1034 , bölüm 4.3.1 ve 5.3.1.

Bu ayrım, yeni yayınlanmış bir eser söz konusu olduğunda önemlidir. DKIM seçici DNS ana bilgisayarının araçlarında görünür ancak doğrulayıcı tarafından kullanılamaz durumda kalır. Yetkili, bir sunucunun şu anda neye hizmet ettiğini belirleyebilir; özyinelemeli sonuç, alıcı yolun ne görebileceğini açıklamaya yardımcı olur. Hiçbir gözlem diğerinin yerine geçmez.

Bir uç nokta seçmeden önce heyeti oluşturun

Mesajın veya servis talimatının tam olarak sahibiyle ve türüyle başlayın. O sahipten sorumlu bölgeye giden heyeti takip edin. Bir alt bölge, üst bölgeden farklı yetkili sunuculara sahip olabilir ve sağlayıcı takma adı tekrar farklı bir bölgeye yönlendirebilir. Eski bir bilette görüntülenen DNS ana bilgisayarı artık yetki verilen ana bilgisayar olmayabilir. RFC 1034 , bölümler 4.2.1–4.2.2.

Yetkili sunucu adları ve adreslerinin bir listesini hazırlayın, ardından ilgili sunucuları doğrudan sorgulayın. Hangi adresle iletişime geçildiğini koruyun. Farklı yetkililer farklı kayıtlar döndürürse öncelikle DNS yayını veya bölgeye hizmet verme sorununu araştırın. Bir çözümleyici, mevcut herhangi bir otoriteyle yasal olarak karşılaşabilir; İstenilen cevaba sahip sunucuyu seçmek tutarsızlığı çözmez.

Bir izleme, delegasyon yolunun incelenmesine yardımcı olabilir, ancak bu ayrı bir gözlemdir. Bir alıcının önbelleğe alınmış yolunu, iletme yapılandırmasını, kaynak ağını veya DNSSEC doğrulama davranışı İzlemeyi posta sağlayıcının sorgu geçmişi olarak sunmak yerine izleme olarak etiketleyin.

Bayrakları limitleriyle birlikte yorumlayın

AA bayrağı, DNS yanıtındaki yetkili yanıtı tanımlar. RD yinelemenin talep edildiğini kaydeder; RA özyinelemenin kullanılabilirliğini duyurur. RD ve RA, sunucunun bu yanıt için yeni bir arama yaptığını kanıtlamaz. Özyinelemeli bir sunucu, önbellekten gelen bir isteği karşılayabilir. RFC 1035 , bölüm 4.1.1.

Doğrudan yetki kontrolü için yineleme talep etmeyin ve gerçek yanıtı inceleyin. AA içermeyen bir yanıt, yönlendirme, REFUSED veya zaman aşımı yorum gerektirir; sunucu adresi tek başına her yanıtı yetkili kılmaz. Takma adların göründüğü yerlerde, her sahibi ve hedefi görünür tutun ve hangi bölgenin nihai verileri sağladığını belirleyin. Takma ad sahibi üzerindeki yetki, otomatik olarak hedefi üzerinde yetki oluşturmaz.

Soru, cevap ve yetki bölümlerinin tamamını saklayın. Yalnızca TXT dizelerini yazdıran bir komut, eski önbelleğe alınmış verileri, yönlendirmeyi, takma adı ve yokluk yanıtını ayırt etmek için gereken bağlamı gizler. Kısa çıkış, teşhis kaydının tamamı kaydedildikten sonra hızlı okuma için kullanışlıdır.

Kurgusal bir çift çözümleyici gözlemini karşılaştırın

Kurgusal bir seçici hayal edin blue._domainkey.example.com. Saat 10:00 UTC'de, iki ilgili yetkili sunucu yeni amaçlanan genel anahtar kaydını döndürür. Saat 10:02'de, Çözümleyici A, 420 saniye kala eski bir anahtarı döndürürken, Çözümleyici B yeni anahtarı döndürür. Bu zamanlar, sonuçlar ve TTL'ler mantığı göstermek için icat edilmiştir; herhangi bir ağ ölçümü yapılmadı.

Bu model farklı önbellek geçmişleriyle tutarlıdır ancak gözlem tek başına sebebi kanıtlamaz. Tüm soruların aynı adı, türü ve sınıfı kullandığını, sunucu uç noktalarının kaydedildiğini ve hiçbir bölünmüş görünüm veya iletme politikasının yanıtı değiştirmediğini kontrol edin. Çözümleyici A daha sonra tutarsız bir yetkiyle yenilenirse yalnızca beklemek sorunu çözmeyebilir.

Önerilen olay notunda şunlar belirtiliyor: "Örneklenen yetkililer yeni anahtar üzerinde hemfikir; Çözümleyici A hâlâ eski anahtarı döndürüyor; alıcı sonucu henüz gözlemlenmedi." Her alıcının güncellendiğini veya kimlik doğrulamanın artık geçtiğini belirtmez. Arama ekranının düzenli görünmesini sağlamak için kayıtları silmek yerine, eski genel anahtarın kullanılabilirliğini ve gönderenin imzalama geçişini koordineli bir rotasyon planı altında tutun.

Veri sorunlarını erişilebilirlik sorunlarından ayırın

Özyinelemeli bir SERVFAIL şunu kanıtlamaz: bir kayıt yok. Bir yetkiliye ulaşılamıyor olabilir, yetkilendirme başarısız olabilir veya DNSSEC doğrulaması çözümleyicinin yanıtı kabul etmesini engelleyebilir. Bir sunucudan gelen doğrudan yanıt, araştırmayı daraltır ancak özyinelemeli çözümleyici için tüm bağımlılıkların sağlıklı olduğunu kanıtlamaz.

Ulaşım da önemli. DNS TCP desteği gerektirir ve kesilmiş bir UDP yanıtı, TCP'nin yeniden denenmesini gerektirebilir. Önerilen bir karşılaştırma dig @AUTH_IP blue._domainkey.example.com . TXT +norecurse aynı sorguyu kullanarak +tcp taşıma söz konusu olduğunda. Yalnızca testi geçmek için güvenlik duvarı veya güvenlik ayarlarını değiştirmeyin; Sorumlu operatörün teşhis edilen yolu incelemesini sağlayın. RFC 7766 , bölümler 5–6.

Karşılaştırmayı tekrarlanabilir hale getirin

Sorgu başına bir çalışma sayfası satırı kullanın: UTC zaman damgası, operatör konumu, sunucu uç noktası, yineleme seçimi, sahip, tür, sınıf, yanıt kodu, bayraklar, kayıtlar, TTL'ler ve aktarım. Seçilen gözlemleri belgelenmiş bir aralıkta tekrarlayın ve önceki satırları koruyun. DNS önbellekleri gelişir, bu nedenle ilk sonucun üzerine yazmak yararlı zamanlama kanıtlarını ortadan kaldırır.

Etkilenen gönderen aracılığıyla kontrollü bir mesajla işlemi tamamlayın ve kimlikleri ve güvenilir alıcı sonuçlarını koruyun. DNS karşılaştırması bir bağımlılığı açıklayabilir; gelen kutusu yerleşimini veya belirli bir alıcının dahili aramasını gösteremez. Bu makalede önerilen bir iş akışı ve kurgusal bir karşılaştırma sunulmaktadır. Katalog kanıt kapısının kapatılabilmesi için orijinal zaman damgalı yetkili ve özyinelemeli yanıtlar gerekli olmaya devam etmektedir.

[ Götürmek ]

İki farklı DNS yanıtını yorumlamadan önce sunucu rolünü tanımlayın ve sorgu içeriğini tamamlayın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

DNS operatörü

Tutarsız yetkiyi önbelleğe alma işleminden ayırın

Bir çözümleyici yalnızca karşılaştığı DNS yolunun sunduğu verileri ve erişilebilirliği alabilir.

Sonraki adımlar

  1. Özyineleme devre dışı bırakılmış ilgili yetkili uç noktaları karşılaştırın.
  2. Çözümleyicinin eski olduğunu bildirmeden önce farklı bölge yanıtlarını iletin.

Mesajlaşma destek mühendisi

Alıcıya bakan yolu koruyun

Herkese açık bir arama sitesi, etkilenen alıcının dahili arama geçmişini açığa çıkaramaz.

Sonraki adımlar

  1. Etkilenen iletideki seçiciyi ve imzalama alanını tam olarak kaydedin.
  2. Her yinelemeli uç noktayı etiketleyin ve tam sonucunu koruyun.

Olay koordinatörü

Kanıt ölçeğinde sonuçları yazın

Olayın küresel bir yayılma iddiasına değil, örneklenen yollar hakkında sınırlı bir açıklamaya ihtiyacı var.

Sonraki adımlar

  1. Hangi yetkililerin ve çözümleyicilerin ne zaman kontrol edildiğini belirtin.
  2. DNS geri yüklemesini ve başarılı mesaj doğrulamayı ayrı kilometre taşları olarak tutun.

[ SSS ]

Sık sorulan sorular

Özyinelemeli bir yanıt her zaman önbellekten mi gelir?

Hayır. Çözümleyici, önbelleğe alınmış verileri kullanabilir veya çözümleme gerçekleştirebilir. Rolü ve özyineleme bayrakları tek başına yetkililerle ne kadar yakın zamanda iletişime geçtiğini açıklamaz.

AA doğrudan sunucu yanıtında bana ne söylüyor?

AA yetkili bir yanıtı işaretler. Gönderdiğiniz her ad için bir uç noktanın yetkili olduğunu varsaymak yerine, gerçek yanıtı ve takma ad içeriğini inceleyin.

RA, çözümleyicinin az önce DKIM anahtarımı getirdiği anlamına mı geliyor?

Hayır. RA yinelemenin mevcut olduğunu gösterir; RD yineleme isteğini kaydeder. Her iki bayrak da tazelik makbuzu değildir.

Neden birden fazla yetkili sunucuyu sorgulamalısınız?

Farklı sunucular tutarsız veriler sunabilir veya erişilebilirlik açısından farklılık gösterebilir. Özyinelemeli bir çözümleyici başka bir yetkiliyle karşılaşabilir, bu nedenle istenen bir yanıt, bir anlaşmazlığı çözmez.

Dig +trace bir posta alıcısının aramasını yeniden oluşturabilir mi?

Hayır. İzleme, kendi ortamından gelen bir temsilci yolunu inceler. Alıcının önbelleğini, iletim kurallarını, ağını veya doğrulama davranışını yeniden yapılandırmaz.

Ana bölgenin ad sunucuları neden sorgulanacak yanlış sunucular olabilir?

Talep edilen sahip, ayrı olarak yetki verilen bir alt bölgede olabilir. Bir takma ad, aramayı başka bir bölgedeki bir hedefe de götürebilir.

Doğrudan olumlu bir yanıt artı özyinelemeli SERVFAIL neyi kanıtlar?

Bu, örneklenen otoritenin bu özyinelemeli yol başarısız olduğunda veri sağladığını gösterir. Benzersiz bir nedeni belirlemez veya doğrulamanın ve diğer tüm otoritelerin sağlıklı olduğunu tespit etmez.

TCP karşılaştırması ne zaman faydalıdır?

Kesme veya aktarıma ulaşılabilirlik söz konusu olduğunda. Aynı adı, türü ve sunucuyu TCP ile tekrarlayın ve her iki sonucu da koruyun; TCP desteği DNS gereksinimlerinin bir parçasıdır.

[ Kaynaklar ]

Kaynaklar

  1. RFC 1034 : Alan adları: kavramlar ve olanaklar
  2. RFC 1035 : Alan adları: uygulama ve spesifikasyon
  3. RFC 7766 : TCP Üzerinden DNS Aktarımı: Uygulama Gereksinimleri

[ Sözlük ]

Sözlük

Yetkili sunucu
Yetkisine sahip olduğu bir bölge için veri sunan bir DNS sunucusu.
Özyinelemeli çözümleyici
Bir müşterinin sorusunu diğer sunuculara danışarak veya önbelleğe alınmış bilgileri kullanarak çözen bir hizmet.
Saplama çözümleyici
Kendi adına çözümleme gerçekleştirmek için normalde özyinelemeli bir hizmete güvenen bir çözümleyici bileşeni.
AA bayrağı
Soru ve yanıt bağlamında yorumlanan, yetkili yanıtı tanımlayan DNS yanıt bayrağı.
Yönlendirme
İstenen nihai verileri sağlamak yerine, çözümü temsilci bölgeden sorumlu sunuculara yönlendiren bir DNS yanıtı.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası