VPN'niz üç DNS sunucusu gönderiyor: hangisi yanıtlıyor?

Bağlandıktan sonra ayarlar sayfasını açın ve üç DNS adresi listelenir; denetim sorusu, son sorgunuzu hangisinin işlediğidir. Sayı tek başına hiçbir şeyi yanıtlamaz, çünkü istemci gönderimi, fiziksel arayüz ve alan adı başına ilke hepsi aynı görünüme yazar. Bu girişler farklı kapsamlar taşır ve kimin yanıtladığını konum değil kapsam belirler. Kaynakları ayırmakla başlayın, sonra sizin için önemli olan adı elinde tutan kaynağı test edin.

Liste neden profilinizden uzun

VPN istemcisi tünel bağlantısı için çözümleyici adreslerini gönderir ve işletim sistemi bunları fiziksel arayüzün zaten sahip olduğu şeyin yanında tutar. Bir yönlendirici, kurumsal DHCP kiralaması, ikinci bir VPN ve alan adı başına ilke her biri kendi girişini ekler. Bu nedenle sayfadaki üç adres, tek bir iş için üç aday değil üç kapsam anlamına gelebilir. Sayıyı sızıntı kanıtı olarak okumak bu denetimin ilk hatasıdır.

Tek bir arayüz içinde istemci sunucularını gerçekten sırayla dener, bu yüzden sıralı bir liste anlamsız değildir. Kuyruk olmayan şey, profil, fiziksel bağlantı ve alan adı başına kurallardan gelen girişlerin tek bir sıralama olmadan yan yana durduğu birleşik görünümdür. Bu ayrım neyi test edeceğinizi belirler: sıra bir kapsam içindeki davranışı açıklar, kapsam ise geri kalan her şeyi.

Şifreli DNS, tabloyu bir uygulamanın içinden bozar. Kendi DNS-over-HTTPS çözümleyicisi olan bir tarayıcı veya sohbet istemcisi sorguları işletim sisteminin listesini tamamen atlayarak gönderir, bu yüzden ayarlar sayfasındaki adresler uygulamanın hiç üretmediği trafiği tanımlar. Ad yanlış çıktı diye profili suçlamadan önce uygulamanın kendi çözümleyici ayarını denetleyin.

Üç denetimden her biri ne söyler

Her kaynak izini farklı bir yerde bırakır ve tek bir komut hepsini göstermez. Ayarlar sayfasının yanında tutmaya değer eşleme şudur:

systemd-resolved kullanan bir sistemde resolvectl status yetkilidir, çünkü DNS'i yönlendirme alan adlarıyla birlikte her bağlantı için bildirir. macOS scutil --dns aracılığıyla yanıtlar, bu da kapsamlı çözümleyicileri denenme sırasına göre listeler. Windows iki yarıyı ayırır: arayüz başına sunucular için Get-DnsClientServerAddress ve sonek kuralları için Get-DnsClientNrptPolicy. Gerçekte kullanılan çözümleyiciye ait komutu çalıştırın, çünkü konteyner çalışma zamanı ve masaüstü çözümleyicisi olan bir makinede birden fazla kurulu olabilir.

Bölgeniz için yanıt veremeyen bir yedek çözümleyici

İkinci giriş genellikle kullanılabilirlik için vardır ve kullanılabilirlik yalnızca yedek adları biliyorsa işe yarar. Genel bir çözümleyiciye iç ana makine adı sorun, NXDOMAIN döndürür veya sizinle hiç ilgisi olmayan bir arama alanından joker yanıt verir. Kimsenin denetlemediği bir yedek geçiş, tam da ihtiyaç duyulduğu anda kesinti üretir.

Split DNS bunu önlemek için vardır: şirket sonekleri bölgeyi elinde tutan çözümleyiciye gider ve genel adlar varsayılan yolda kalır. Tasarım sağlamdır ve sonek listesinin eksiksiz olmasına bağlıdır. Microsoft, Windows'ta bunu yöneten sonek başına çözümleyici ilkesini belgeler ve aynı fikir systemd-resolved içinde yönlendirme alan adları ve macOS'ta kapsamlı çözümleyiciler olarak görünür.

Yedeğin yanıt verebileceği bölgeleri ilkede bulunan soneklerle karşılaştırın. Bu karşılaştırma, bir kullanıcı tünel değişikliğinden sonra bir iç sitenin çözümlenmeyi bıraktığını bildirmeden önce boşluğu bulur.

İlkenin içinden sorun, çevresinden değil

İşletim sisteminin çözümleyicisi üzerinden sorun, çünkü bir sunucuya doğrudan sorgu ilkeyi atlar ve yalnızca o sunucunun söyleyeceğini bildirir. İki yanıt arasındaki boşluk işin bütünüdür:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Sistem sorgusu özel bir adres döndürürken doğrudan sorgu NXDOMAIN döndürüyorsa ilke çalışıyor ve zayıf nokta yedektir. İkisi de aynı genel yanıtı döndürüyorsa ad, amaçladığınız kapsamın dışında çözümleniyor ve sonek listesi bakılacak yerdir. Her iki çıktıyı da saklayın, çünkü çözümleyici tartışması ayarlar sayfasının ekran görüntüsünden çok iki satırla daha hızlı sonuçlanır.

Ardından başarısızlık yolunu çalıştırın, çünkü kimsenin test etmediği bir yedek yalnızca bir varsayımdır. Tercih edilen çözümleyiciyi tek bir sorgu için kara delik yapın ve hangi adresin döndüğüne bakın:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Sorgu biter bitmez o rotayı silin, yoksa sıradaki kişi bir gizem devralır. O pencerede iç adlar hâlâ çözümleniyorsa, amaçlanan kapsamın dışındaki bir şey onlara yanıt vermiştir. Bunun yerine zaman aşımına uğrarlarsa yedek yoktur veya doğru şekilde sınırlandırılmıştır ve çözümleyicinin kendi günlüğü ikisinden hangisi olduğunu söyler.

Karar verin: tutun, sınırlayın veya kaldırın

İhtiyaç duyduğunuz ad alanını yanıtladığında ve profil altında erişilebilir kaldığında ikinci bir çözümleyici tutun. Yalnızca bir sonek görmesi gerekiyorsa onu sınırlayın ve ne kapsamı ne de belgelenmiş bir amacı varsa kaldırın. İşi olmayan bir giriş, yararı olmayan gelecekteki bir sızıntıdır ve sağlayıcı varsayılanı bir amaç değildir.

Sonucu dört sütun olarak kaydedin: sonek, çözümleyici, arayüz ve sahip. O satır, bir sonraki denetim sorusunu herhangi bir ekran görüntüsünden daha hızlı yanıtlar ve listeyi sessizce yeniden sıralayan istemci güncellemesine dayanır.