TLS üzerinden DNS ve VPN: hangi kısım korunuyor

TLS üzerinden DNS, istemci ile seçtiği resolver arasındaki alışverişi şifreler ve resolver adı yine de okur. Bu cümle DoT ve VPN çevresindeki karışıklığın çoğunu çözer. Şifrelenmiş sorgunun hangi yolu izleyeceğine tünel karar verir, resolver ise neyin sorulduğunu öğrenmeye devam eder. İki mekanizmadan hiçbiri diğerinin yerini tutmaz ve hiçbiri diğerini gereksiz kılmaz.

Sahip olduğunuz düzenin düşündüğünüz düzen olup olmadığını dört denetim belirler.

Denetim 1: şifreleme neyi kapsıyor

DoT, DNS alışverişini TLS'e sarar, böylece yoldaki bir gözlemci sorgu içindeki adı değil, bir adrese ve bağlantı noktasına giden bağlantıyı görür. Resolver'ın kendisi şifreyi çözer ve yanıtlar. Bunu HTTPS üzerinden DNS ile karşılaştırın: ikisi de şifreler ve farklı taşıyıcılar kullanır, bu yüzden web trafiğine izin veren bir ağ DoT bağlantısına otomatik olarak izin vermez.

Bu ayrım, bir captive portal ya da filtreleyen ara kutu 443'e izin verip 853'ü engellediğinde önemlidir. Orada çalışan araç, diğerinin çalışacağının kanıtı değildir.

Denetim 2: sorgu hangi yolu izliyor

Yol, istemci ilkesi meselesidir. DoT resolver'a tünelin içinden, dışından ya da ağla değişen bir yoldan ulaşılabilir. Hangisinin olacağı yollara ve istemcinin kendi DNS soketini koruyup korumadığına bağlıdır. Tüm trafiği yakalayan bir tünel genellikle sorguyu da yanında götürür, resolver adresi ne derse desin.

Bir testte üçüncü taraf resolver adresi görmek bir atlatmayı kanıtlamaz, şifreleme görmek de amaçlanan alıcıyı kanıtlamaz. Resolver'ı ve yolu ayrı ayrı okuyun, sonra çiftin tasarladığınız çift olup olmadığına karar verin.

Denetim 3: iç adlar

İç adlar yayımlayan bir kuruluşun bu kayıtları tutan bir resolver'a ihtiyacı vardır. Genel bir DoT hizmeti özel ad alanınızı bilmez ve istemciyi ona yönlendirmek bu adların başarısız olacağını garanti eder. Bu, yönetilen bir cihazda birinin şifreli DNS'i açması durumunda en sık görülen pratik gerilemedir.

İç son ekler için iç resolver'ı koruyun ve ilke gerektiriyorsa o atlamayı şifreleyin, onu genel bir sağlayıcıyla değiştirmek yerine.

Denetim 4: hata durumunda davranış

Ulaşılabilir bir resolver olmadan katı resolver ayarı, tünel ayakta kalırken ad çözümleme hatası üretir. Anahtarlara veya sertifikalara dokunmak yerine platform moduna ve belgelenmiş yedeğine bakın.

Sessizce düz DNS kullanan bir yedek, kolaylık değil ilke kararıdır. Hatasının görünür mü olması yoksa daha zayıf bir şeye mi düşmesi gerektiğine karar verin ve yanıtı yazın.

Sertifikaya güvenin, yanıta değil

Hizmet için belgelenmiş sağlayıcı ana bilgisayar adını ve doğrulama yapılandırmasını kullanın. Bilinmeyen bir resolver yanıt versin diye TLS denetimlerini kapatmak size doğrulanmamış bir uç noktaya şifreli kanal verir; bu, yerini aldığı düz sorgudan belirli bir açıdan daha kötüdür: güvenli görünür. DNS over TLS belirtimi o denetimin arkasındaki kimlik doğrulama beklentisini ortaya koyar.

Kimliğini doğrulayamadığınız bir resolver'dan gelen yanıt sonuç değil, iddiadır.

Bunun açıklamadığı şeyler

DoT adı resolver'dan gizlemez, bağlantının hedef adresini ağdan gizlemez ve sorgunun tünelden geçip geçmediğine karar vermez. Bunlar üç ayrı soru ve üç ayrı yanıttır.

Resolver kimliğini, geçiş yolunu ve iç ad ilkesini üç satır olarak yazın. Alacağınız bir sonraki DNS sorusu bunlardan biri olacak.