1.1.1.1'i kim işletiyor? Bir DNS adresine güvenmeden önce kontrol etmek

1.1.1.1'i VPN'in DNS alanına yapıştırdınız, sayfa yüklendi ve eğitim artık doğrulanmış görünüyor. Bu gözlem göründüğünden daha dar: uygulama farklı davrandı ve değişiklik henüz sorguyu kimin yanıtladığı ya da eski düzenin neden başarısız olduğu hakkında hiçbir şey söylemiyor. Kopyalanan bir eğitim, tanıdık bir genel adresi sık sık “VPN'in DNS'i” olarak adlandırır ve bu, erişilebilirlik değil sahiplik hakkında bir iddiadır. Adresin neyi temsil ettiğini kontrol etmek beş dakika alır ve yanlış nedenle yapılan kalıcı bir değişikliği önler.

Çalışan bir ayar kimlik değildir

Ayar alanındaki adres bir uç noktadır ve bir uç noktanın işletmecisi vardır. Bu iki olgu ayrıdır ve ikincisi insanların atladığıdır. En sık kopyalanan çift için yanıt herkese açıktır: Cloudflare, 1.1.1.1 ve 1.0.0.1 adreslerini çözümleyicisinin adresleri olarak yayımlar ve bunları kendi resmî adres başvurusunda listeler. Bu yüzden işletmecinin adı adresin yanında yer alır, ayrı bir eğitimde değil.

Bu çifti bir tünel açıkken girmek, VPN şirketini onun işletmecisi yapmaz ve trafiği anonim yapmaz. Sorgu, adres aralığını yayımlayan bir şirkete doğru makinenizden çıkar ve o şirket saygın olabilir ama yine de eğitimin ima ettiği taraf olmayabilir. Yönergelerdeki etiket ile gerçeklikteki işletmeci iki farklı iddiadır. Hiçbiri aradaki ağ yolunu kimin işlettiğini söylemez.

Bir adres çiftini veya şifreli bir uç noktayı doğrulamak için çözümleyicinin kendi yayımlanmış başvurusunu kullanın. Başka bir sağlayıcının önerisi meşru olabilir ve “tarafından önerilen”, “üzerinden ulaşılan” ve “tarafından işletilen” hâlâ üç farklı ilişkiyi tanımlar.

Bir kaydın ihtiyaç duyduğu üç şeyi karşılaştırın

İncelemeye hazır bir kayıt üç soruyu ayırır: sorguyu kim almalı, alışveriş düz mü yoksa şifreli mi ve hangi yol onu taşımalı. Sağlayıcı adı ikinciyi ya da üçüncüyü dolduramaz ve ülke etiketi hiçbirini dolduramaz. Değişiklikten önce üç girdiyi yazın ve sonra karşılaştırın. Bu girdiler birbirinin yerine geçmez ve onları tek bir şey olarak ele almak, bir tahminin belgeye dönüşme yoludur.

Çalışan bir ayarı belgelenmiş bir karara dönüştüren şey karşılaştırmadır. O olmadan bir sonraki kişi hiçbir gerekçesi eklenmemiş bir adresi devralır. Önce aşağıdaki tablonun üçüncü sütununu okuyun, çünkü çoğu kendinden emin açıklama gerçekte orada durur.

Tablo bilerek kısadır. Amacı, her girdinin farklı bir soruyu yanıtlaması ve tek bir alanın üçünü birden doldurmamasıdır.

Yerel bir yönlendirici gerçek kaynağı gizler

Yönlendiricisini DNS olarak kullanacak şekilde yapılandırılmış bir aygıt bir yönlendiriciye işaret eder. O adres, sorgunun bir sonraki alıcısını tanımlar, sonunda yanıtlayan çözümleyiciyi değil. Yerel bir stub çözümleyici aynı ek adımı ekler, ve her durum çıktısında göründüğü için gerçek şeyle karıştırmak kolaydır.

Stub, aynı çıktının da listelediği kaynaklara iletir, genellikle daha aşağıda. İşletmeci hakkında herhangi bir sonuca varmadan önce tüm zinciri okuyun, çünkü ilk satır tüm yanıt değildir. Aksi hâlde resepsiyonu şirket olarak adlandırıyorsunuz.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

İkinci komut, işletmecinin yayımladığı yerde çözümleyicinin yankı adını kullanarak gördüğü kaynak adresi bildirir. Üçüncüsü, yanıt veren sunucuyu adlandırır ve bu genellikle yapılandırdığınız adres değildir. Bir işletmeci yazmadan önce üç çıktıyı da karşılaştırın.

Şifreli DNS neyin görünür olduğunu değiştirir, kimin gördüğünü değil

DNS over HTTPS ve DNS over TLS, istemci ile çözümleyici arasındaki alışverişi korur. Çözümleyici, kendisine sorulan her adı okumaya devam eder, çünkü yanıtlamak onun işidir. Değişen, alışverişi kimin izleyebildiğidir: yerel ağ, düz metin sorgu akışı yerine tek bir uç noktaya bağlantı görür.

Değişmeyen şey, o uç noktayı işleten kuruluşa işaret etmeye devam eden güven ilişkisidir. Kendi güvenli DNS ayarına sahip bir tarayıcı, işletim sisteminin çözümleyicisini tamamen atlayabilir. Bunları iki kez uygulanmış tek bir ayar olarak değil, anlaşamayabilecek iki yapılandırma olarak ele alın.

Özel adlar yine kendi kararlarına ihtiyaç duyar. Bir iş tüneli seçili alan adlarını kurumsal çözümleyicilere yönlendirebilir ve bunu genel bir hizmetle değiştirmek iç aramaları bozabilir veya iç adları yanlış tarafa açığa çıkarabilir. Tüm bir bağdaştırıcının ayarlarını değiştirmeden önce alan adı ilkesini kontrol edin.

Gözlemi dar tutun

Karşılaştırırken eski yapılandırmayı koruyun ve ayarları birer birer değiştirin. Uygulamayı, işlemi, çözümleyici ilkesini ve yeniden bağlandıktan sonra genel ve izin verilen özel adların hâlâ çözülüp çözülmediğini kaydedin. İki değişiklik içeren bir karşılaştırma ikisini de kanıtlamaz. Sonucu bir sonraki kişinin bulacağı yere, ayarın hemen yanına yazın.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Uygulama çalışmaya başlarsa, iddiayı kanıtların izin verdiği kadar küçük tutun. O değişiklik bir teste yardımcı oldu ve önceki çözümleyicinin kötü niyetle davranıp davranmadığı, tünelin bozuk olup olmadığı veya başka bir aygıtın aynı değişime ihtiyaç duyup duymadığı hakkında hiçbir şey söylemez. Kalıcı sonuç, işletmecisini ve amacını açıklayabildiğiniz bir yapılandırmadır.