Split-DNS yakalama: her gözlemin nerede alındığını söyleyin

İki kişi aynı Split-DNS sorununu inceler ve farklı çözümleyici adresleri elde eder. Biri bir arama aracı kullandı, diğeri bağdaştırıcıda paket yakaladı, üçüncüsü ise istemcinin kendi tanılamasını okudu. Hiçbiri yalan söylemiyor ve hiçbiri aynı aşamayı anlatmıyor. Gözlem noktasını adlandırmak çelişkiyi haritaya dönüştürür.

Bir arama, birkaç gözlem noktası

Tek bir iç ad için bakılacak en az beş yer vardır: uygulama ve çağırdığı çözümleyici API'si, istemcide geçerli alan adı ilkesi, bağdaştırıcı veya filtre üzerinde yakalama, denetlenen ağ geçidi sınırı ve sorguyu gerçekten alan çözümleyici.

Her biri farklı bir soruyu yanıtlar ve hiçbiri tek başına sorgunun nereye gittiğini kanıtlamaz.

Bağdaştırıcıdaki yakalama paketleri gösterir, niyeti değil. İstemcinin hangi çözümleyiciyi seçtiğini söylemez ve boş bir yakalama, atılan bir paket yerine önbelleğe alınmış bir yanıt veya başka bir çözümleyici API'si anlamına gelebilir. Her gözlemi bir aşamaya ilişkin kanıt olarak değerlendirin. Sonra aşamaları bir yolda birleştirin.

İstemci filtresi uygulama ile kablo arasında durur

Split-DNS kullanan bir VPN istemcisi, paket makineden çıkmadan önce alan adı eşleştirmesini uygular. Tünellenen son ekteki adlar iç çözümleyiciye gider; diğer her şey yerel olana gider. Filtre bir ilkedir ve ilke platforma ve istemci sürümüne göre değişebilir.

Cisco'nun Secure Client Split-DNS rehberi alan adı eşleştirmesini ve Windows filtresini kapsar; uygulamanın yerel çözümleyici API'sini kullandığında gördüğünü nslookup gibi bir aracın gördüğünden ayırır. Asıl önemli olan bu farklardır.

Geçerli profilden ve uygulamanın olağan bir aramasından başlayın. Belirli bir sunucuyu adlandıran her test bilinçli bir sapmadır; onu istemcinin kendi tanılamasıyla açıklayın ve kabul ölçütü olmasına izin vermeyin.

nslookup uygulamadan farklı bir yol izler

nslookup kendi DNS sorgusunu kurar ve işletim sisteminin çözümleyici ilkesini atlayabilir. Bu onu belirli bir sunucuya belirli bir soru sormak için yararlı, uygulamanın ne yaşayacağını test etmek için ise yanıltıcı bir araç yapar.

Windows'ta ad çözümleme ilkesi tablosu hangi son ekin hangi sunucuyu kullandığına karar verir. Onu okumak uygulamanın izleyeceği ilkeyi gösterir ve çoğu zaman eksik parça odur.

İlkeyi okuyun ve ardından aynı soruyu normal çözümleyici üzerinden sorun:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Şifrelenmiş çözümleyiciler sorguyu gizler, bağlantıyı değil

Kendi DNS-over-HTTPS çözümleyicisi olan bir tarayıcı bambaşka bir durumdur. Sorgu TLS içinde çıkar, bu yüzden paket yakalaması bir çözümleyici adresine bağlantı gösterir ama sorulan adı göstermez.

Önce tarayıcının yönetilen ilkesini belirleyin, sonra bunu işletim sisteminin aramasıyla karşılaştırın. Kendi çözümleyicisini seçmesine izin verilen bir tarayıcı Split-DNS ilkesini hiç görmeyebilir.

Aynı dikkat, kendi çözümleyicisini getiren her istemci için geçerlidir. Uzak bağlantıyı tanımlayan bir yakalama, sorgu adına ilişkin kanıt değildir. Ada ihtiyacınız varsa, onu çözümleyicinin kendi günlüklerinden veya uygulamanın tanılamasından alın; geçerli gizlilik kurallarıyla birlikte.

Etiketlenmiş bir testle karşılaştırın

Test için onaylanmış bir iç ad ve hassas anlam taşımayan bir genel ad seçin. Her biri için zamanı, kayıt türünü, yanıtı ve beklediğiniz ilkeyi not edin.

İzin verilen yerlerde, çözümleyicinin alışını istemci veya ağ geçidinden yapılan tek bir dar gözlemle karşılaştırın:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Yalnızca bir karşılaştırma oluşturmak için özel adları ilgisiz genel çözümleyicilere asla göndermeyin ve paylaştığınız her şeyi sansürleyin. Son olarak, doğru DNS yanıtını onu izleyen hizmet bağlantısından ayırın: çözülen özel adres hâlâ bir yola ve uygulama yetkisine ihtiyaç duyar.