VPS'te kendi DNS çözücünüzü çalıştırın: kimsenin tutmadığı günlük

Sizi tarayıcı geçmişinizden daha iyi tanımlayan günlük

Makineniz bir web sitesine tek bir şifreli bayt gönderebilmeden önce, o web sitesinin nerede yaşadığını birine sorması gerekir. Bu soru açık metin halinde, neredeyse kesinlikle seçmediğiniz bir çözücüye gider ve onu kimin tuttuğunun cevabı, hayatınızın ne kadarının kayda geçtiğini belirler. Bir tarayıcı geçmişi, tutmayı seçtiğiniz sayfaların bir listesidir. Bir çözücü günlüğü ise her şeydir: her site, güncelleme kontrolü yapan her uygulama, telefonunuzun siz uyurken konuştuğu her bulut hizmeti, açtığınız her e-postadaki her alan adı, sırayla, zaman damgalarıyla, ekrana bir insan bakıyor olsun ya da olmasın.

Bir haftalık kaydını okuyun, bir kişiyi yeniden inşa edebilirsiniz. Kullandığı banka, az önce ayırttığı uçuş, eczane, flört uygulaması, işe alım uzmanının başvuru takip sistemi, uyandığı saat ve durduğu saat. Bunların hiçbiri herhangi bir şifrelemeyi kırmayı gerektirmez. İsimler tek başına yeter ve isimler, işlemin, çoğu kurulumda hâlâ tasarım gereği bir üçüncü tarafa teslim edilen tek parçasıdır.

Bugün o üçüncü taraf, DHCP kiralamanızın sizi yönlendirdiği her kimse — internet sağlayıcınız, işvereniniz, kafe. Bunu fark eden insanlar genellikle herkese açık bir çözücüye geçer; bu, bütünlük açısından gerçek bir iyileşme ve gizlilik açısından yanal bir hareket: gözlemciyi kaldırmadınız, hangi şirket olduğunu değiştirdiniz ve düzenlemeye tabi bir telekomu, reklamcılığa yakın bir CDN ya da politikası fonlamasıyla değişebilecek bir kâr amacı gütmeyen kurumla takas ettiniz. İyi olanlar dürüst saklama politikaları yayımlar ve bazıları bunlara gerçekten uyar. Ama bir politika, davranışa dair bir vaattir; bir yapılandırma dosyası ise yeteneğe dair bir beyandır. Bir vaadi denetleyemezsiniz. Kendi yazdığınız yirmi satırı, kendi kiraladığınız bir kutuda, kendi seçtiğiniz bir ülkede denetleyebilirsiniz.

Forwarding günlüğü taşır. Recursion onu parçalara böler.

"Kendi DNS sunucunuzu çalıştırın" diyen yazıların neredeyse tamamı bir forwarder inşa etmekle sonuçlanır: bilmediği her şeyi 1.1.1.1'e ya da 9.9.9.9'a ileten, ağınızda küçük bir önbellek. Gerçekten kullanışlı bir şeydir — hızlıdır, beş satırdır ve yerel ağınızın sizi izlemesini durdurur. Ama toplu günlüğü tam olarak olduğu yerde bırakır. Aradığınız her isim hâlâ tek bir şirkete ulaşır; artık uygun bir şekilde çözücünüzün tek IP adresiyle önceden etiketlenmiş olarak, bu da akışı zorlaştırmak yerine kime ait olduğunu belirlemeyi kolaylaştırır.

Recursive bir çözücü işi devretmek yerine kendisi yapar. news.example.io sorulduğunda, önce bir kök sunucuya .io'yu kimin çalıştırdığını sorar, sonra .io sunucularına example.io'yu kimin çalıştırdığını sorar, sonra doğrudan o operatöre sorar. Hiçbiri toplama işiyle uğraşmayan üç ilgisiz tarafla üç konuşma ve — önemli olan kısım burası — bunlardan hiçbiri asla sizin tam sorgu akışınızı görmez. Kök operatörleri, üst düzey alan adı isteklerinin bir damlasını görür. Verisign, adresinizdeki birinin .com altında bir şeye dokunduğunu görür. Bir alan adının yetkili sunucusu, zaten görecek olduğu trafiği görür, çünkü siz nasılsa ona bağlanmak üzeresinizdir.

QNAME minimisation bunu önemli ölçüde netleştirir ve modern Unbound bunu varsayılan olarak yapar. Zincirdeki her sunucuya tüm ismi göndermek yerine — çözücülerin otuz yıl boyunca yaptığı şey budur — her sunucuya yanıt vermek için gereken tek etiketi gönderir: köke io., .io sunucularına example.io., ve yalnızca ondan sonra buna hakkı olan operatöre tam news.example.io.'yu. Hiyerarşi, niyetlerinizin bir yayını olmaktan çıkar ve çizildiği şey olur: bir devir.

Takas gerçektir ve açıkça belirtilmeye değer. Soğuk bir recursive sorgu, bir forwarder'ın bir tane yaptığı yerde birkaç gidiş-dönüş yapar, dolayısıyla tanımadık bir alan adına ilk ziyaret ölçülebilir şekilde daha yavaştır. Eskiden başkasının sorunu olan bir önbelleğin sorumluluğunu üstlenirsiniz. Ve artık milyonlarca başka insan tarafından ısıtılmış paylaşımlı bir önbellekten yararlanmazsınız. Karşılığında, neye baktığınızın eksiksiz, sıralı, zaman damgalı kaydı, kendi diskiniz dışında hiçbir yerde var olmayı bırakır.

Bunun gizlediği şey, ve açıkça gizlemediği şey

Dürüst kapsam, özel DNS etrafındaki pazarlamanın öne sürdüğünden daha dardır ve sınırları bilmek, sizi iyi bir hisin gücüyle kötü bir karar vermekten koruyan şeydir.

Bir şeyi ortadan kaldırır: tek bir gözlemcinin elinde tutulan toplu isim günlüğü. Bu büyük bir şeydir, çünkü ticari değeri olan ve toplu talep edilen şey tam da bu toplamdır. Ama her şey değildir.

Bağlantıyı gizlemez. Arama çözüldükten sonra, cihazınız hâlâ o adrese bir oturum açar ve uplink'inizi izleyen herkes hedef IP'yi görür. Özel altyapıdaki bir site için IP, kimliğin ta kendisidir. Hostname'i de hat üzerinde gizlemez: her iki uç da Encrypted Client Hello desteklemedikçe, TLS el sıkışması sunucu adını hâlâ açık metin olarak taşır — bu, çözücünüzün zaten sahip olacağı bilginin aynısıdır.

Sorguları barındırma sağlayıcınızdan gizlemez. Bu, insanların yanlış anladığı noktadır, dolayısıyla çekinmeden söylenmeyi hak eder: çözücünüzün üst akış trafiği — köke, üst düzey alan adına ve yetkili sunuculara sorduğu sorular — VPS'ten UDP 53 portundan şifrelenmemiş olarak çıkar ve sunucunuzun üzerinde bulunduğu ağ bunun tamamını okuyabilir. Köke giden bir DoT yoktur. Gözlemciyi silmiş olmaktan çok, onu taşımış olursunuz: veri satan ve kendi ülkenizde mahkeme celplerine yanıt veren bir tüketici internet sağlayıcısından, bilerek seçtiğiniz bir yargı bölgesindeki bir barındırma ağına — QNAME minimisation sayesinde parçalanmış bir akış gören bir ağa. Bu gerçek bir iyileşmedir ve bir yapılandırma dosyasının çözebileceği bir şeyden çok, hatta hangi hukukun uygulandığına dair bir tartışmadır.

Ve size bir kalabalık vermez. Bir hanede kullanılan bir çözücü, içindeki her sorguyu hiçbir belirsizlik olmadan o haneye atfeder. Küresel pasif bir düşmana karşı, meşgul, paylaşımlı bir çözücü gerçekten daha iyi bir gizlenme yeridir. İnternet sağlayıcınıza, işvereninize, çözücü telemetrisi satın alan veri komisyoncularına ve sıradan insanların başına gerçekten gelen rutin toplu isteklere karşı ise sizinki daha iyidir — cihazlarınızdan son sıçramanın bir tünel içinde olması koşuluyla. Bunu yerine değil, kendi WireGuard tünelinizle birlikte çalıştırın. Tek başına, özel bir çözücü meta verinizi büyük ölçüde başka bir yere taşır. Bir tünelin arkasında ise tünelin açık bıraktığı tek kanalı kapatır.

Çözücünüzü başkasının silahına dönüştüren hata

Bunu ciddi şekilde yanlış yapmanın tam olarak bir yolu var, kazayla yapmak kolay ve sonuçları önce yabancılara, sonra size ulaşır.

Herkese yanıt veren bir çözücü, açık bir çözücüdür ve açık bir çözücü bir yükselticidir. DNS, UDP üzerinden çalışır, UDP kaynak adresleri önemsiz bir şekilde sahtelenebilir ve küçük bir sorgu, kendi boyutunun kat kat fazlası bir yanıt üretebilir. Bir saldırgan, kutunuza, gönderen olarak bir kurbanın adresi sahtelenmiş 60 baytlık bir soru gönderir; kutunuz da görevini yaparak kurbana kendisinden onlarca kat daha büyük bir yanıt gönderir. Bunu birkaç bin açık çözücüden aynı anda yapın, kurban internetten düşer — paket düzeyinde doğru bir şekilde sizden geliyormuş gibi görünen bir selin altında kalmıştır. Hedef siz değilsiniz. Siz silahsınız ve olay raporundaki trafik sizindir.

Ardından gelenler hiç de gösterişli değildir: hiç adını duymadığınız ağlardan gelen kötüye kullanım raporları, kendi transitini korumak için adresinizi null'a yönlendiren bir sağlayıcı ve yaşamak istemeyeceğiniz bir hesap görüşmesi. Tam olarak DDoS ilk saat çalışma kılavuzumuzda anlatılan olayın sebep olan tarafında bulursunuz kendinizi ve bu hikâyenin, çalışma sürenizin hayatta kaldığı bir versiyonu yoktur.

Bunu iki bağımsız kilit önler ve ikisini de istersiniz, çünkü her biri diğerinin başarısızlığını kapatır. Birincisi, Unbound'un kendi access-control'ıdır; bu, her iki IP ailesinde de tüm interneti refuse etmeli, sonra açıkça loopback'e ve tünel alt ağınıza allow vermelidir — izin veren bir kuyruğu olan bir izin listesi değil, varsayılan reddeden bir liste. İkincisi, daemon'ın nerede dinlediğidir: onu 127.0.0.1'e ve tünel adresine bağlayın, asla 0.0.0.0'a değil, ve 53 portunu genel arayüzde güvenlik duvarında kapalı tutun.

Tuzak, yalnızca birincisini yapmaktır. Bir access-control kuralı portu ortadan kaldırmaz; reddedilen bir sorgu yine de alınan bir paket ve gönderilen bir pakettir, adresiniz yine de açık çözücüleri haritalayan taramalarda görünür ve yanlış bir bölüme yapılan tek bir sonraki düzenleme, bir reddi bir yanıta dönüştürür. Bağlama ve güvenlik duvarına alma, bu hatayı bir yapılandırma satırı uzaklıkta olmaktan çıkarır, yapısal olarak imkânsız kılar. Kutu aynı zamanda konteyner çalıştırıyorsa, yazdığınız kuralın geçerli kural olduğunu varsaymadan önce Docker'ın portları güvenlik duvarınızın etrafından nasıl yayımladığını yeniden okuyun.

Unbound'un varsayılanları akıllıcadır. Özel değildir.

Unbound, doğruluk ve kararlılık için ayarlanmış şekilde gelir; bu da çoğunlukla internet sağlayıcıları tarafından devreye alınan bir yazılım için doğru varsayılandır. Bir avuç ayar, onu çalıştıran kişi için inşa edilmiş bir şeye dönüştürür. Hiçbiri egzotik değildir; kutudan çıktığında sadece kapalıdırlar ya da görüş belirtmezler.

Kendiniz hakkında soruları yanıtlamayı bırakın. Varsayılan olarak bir çözücü, yazılım sürümünü ve hostname'ini CHAOS sınıfı üzerinden — version.bind ve hostname.bind — seve seve bildirir; bu da kutunuzun ilgiye değer olup olmadığına karar veren herkes için bedava bir keşiftir. hide-identity ve hide-version hiçbir şeye mal olmaz ve bir parmak izini ortadan kaldırır.

Kapalı başarısız olun, açık değil. DNSSEC doğrulaması, sahte bir yanıtı tespit eden bir çözücü ile onu sunan bir çözücü arasındaki farktır. harden-dnssec-stripped, imzalanmış olması gereken bir bölge için imzasız bir yanıtı kabul etmeyi reddeder; harden-glue ve harden-below-nxdomain, iki klasik önbellek zehirleme yolunu kapatır ve aggressive-nsec, çözücünün var olmayan isimleri yeniden sormak yerine doğrudan önbelleğe alınmış reddetme kayıtlarından yanıtlamasını sağlar. use-caps-for-id, kör sahtecilik saldırılarına karşı ek entropi olarak rastgele büyük/küçük harf ekler — ucuzdur ve nadiren kötü kurulmuş bir yetkili sunucuyla uyumsuzdur; çözülmeyen bir alan adı için bir öğleden sonranızı harcamadan önce bunu bilmekte fayda var.

Hiçbir şey yazmayın. Unbound, istenmedikçe sorguları günlüğe kaydetmez, ama bunu yapacak ayarlar yalnızca yorum satırı olmaktan çıkarılmış bir satır kadar yakındır ve bazı dağıtım paketleri daha konuşkan bir varsayılanla gelir. verbosity: 0 ayarlayın ve log-queries: no'yu açıkça belirtin, böylece niyet, yokluğundan çıkarılmak yerine dosyada görünür olsun. Sonra bir ayar olmayan kısmı hatırlayın: önbelleğin kendisi bir kayıttır. Çalışan bir kutuda unbound-control dump_cache, o kutunun az önce ne aradığının yakın geçmişini yazdırır ve bu, başkasının ellerinin ulaşabileceği bir makinenin belleğinde yaşar. Kendiliğinden süresi dolar — kısa önbellek ömürleri ile gizliliğin hafif bir gerginlik içinde olmasının tüm nedeni budur — ve hiç güvenmediğiniz bir host üzerinde bir çözücüyü aylarca canlı tutmamanızın nedeni de budur.

Kasıtlı olarak önbelleğe alın. Önbellekten sunulan her yanıt, üst akışta hiç gerçekleşmeyen bir gözlemdir, dolayısıyla sağlıklı bir önbellek yalnızca bir hız özelliği değil, bir gizlilik özelliğidir de. prefetch, popüler kayıtları süreleri dolmadan yeniler, böylece yaygın durum ağa hiç dokunmaz hâle gelir; serve-expired, yetkili bir sunucuya kısa süreliğine ulaşılamadığında sizi çevrimiçi tutar. cache-min-ttl'yi yükseltmek üst akış trafiğini daha da azaltır, ama alan adı operatörlerinin kasıtlı seçimlerini geçersiz kılar — düşük TTL'ler, CDN'lerin ve failover'ın çalışma biçimidir — dolayısıyla bir iki dakikalık bir alt sınır mantıklıdır ve bir saat er ya da geç sizi ölü bir adreste bırakır.

İçeri girmenin iki yolu: tünel ya da DNS-over-TLS

Cihazlarınızın çözücüye bir şekilde ulaşması gerekir ve iki akıllıca seçenek arasındaki tercih büyük ölçüde ne yayımlamaya razı olduğunuza bağlıdır.

Tünel, neredeyse herkes için daha iyi cevaptır. Laptop'unuz ve telefonunuz o sunucuya zaten bir WireGuard oturumu tutuyorsa, çözücü tünel adresinde dinleyebilir ve 53 portunda sıradan DNS konuşabilir. Trafik zaten şifrelidir ve zaten tünel tarafından kimliği doğrulanmıştır, dolayısıyla alınacak bir sertifika, internete açık yeni bir port, yabancılara açık bir TLS yığını yoktur ve — hafife alınan kısım — hiçbir yerde bir hostname yoktur. Bu sitedeki WireGuard rehberi, istemcileri DNS = 9.9.9.9'a işaret edilmiş halde bırakır, tam olarak çünkü oraya koyacak daha iyisi henüz yoktu. Onun yerine o satıra girecek olan budur: kendi sunucunuzun tünel adresi.

DNS-over-TLS, tünel tutamayan cihaz içindir. Android'in Private DNS alanı bunun için en güçlü örnektir — sistem çapında uygulanır, yeniden başlatmalara dayanır ve başka türlü dokunamayacağınız uygulamaları kapsar. Bedeli, geçerli bir sertifikaya sahip bir hostname'dir ve bir sertifika, o ismi oluşturduğunuz anla bağlayan, Certificate Transparency günlüklerinde herkese açık, kalıcı bir kayıt anlamına gelir. Ardından passive DNS, ismi sunucunun adresine bağlar. Bu çalışmanın amacı adınızı altyapıdan uzak tutmaksa, size hiç yaklaşmayan bir hostname kullanın ve onu bir alan adını anonim olarak kaydetme rehberinde anlatılan dikkatle kaydedin — her şey için kullandığınız alan adının bir alt alanı değil, ki bu ikisini kalıcı olarak birbirine bağlar.

İkinci, daha ince bir bedel daha var. Dolaşımdaki telefonların ulaşabildiği bir DoT uç noktası kaynak adresine göre sınırlandırılamaz, dolayısıyla tanım olarak, ismi öğrenen yabancıların kullanabileceği bir çözücüdür. Bir yükseltici değildir — TCP üzerinden TLS tamamlanmış bir el sıkışma gerektirir, dolayısıyla kaynak sahtelenemez ve yansıtılacak bir şey yoktur — ama vazgeçtiğiniz bir kapasitedir ve taranmaya değer bir hizmettir. IP başına hız sınırlarını açık tutun, kimsenin tahmin edemeyeceği bir hostname seçin ve bunu varsayılan kapı olarak değil, bir iki cihaz için kasıtlı bir istisna olarak ele alın.

DNS-over-HTTPS üçüncü bir seçenektir ve burada genellikle yanlış olanıdır. Çözücünün önünde bir web sunucusu gerektirir, bu da web trafiğinden ayırt edilemez olmanın tek yararı için daha fazla hareketli parça ve daha büyük bir saldırı yüzeyi demektir. Bu yarar, DoT'u engelleyen bir ağı aşmaya çalışıyorsanız belirleyicidir ve öyle değilseniz önemsizdir.

Engelleme farklı bir üründür; eklemeden önce karar verin

Er ya da geç biri engelleme listeleri eklemeyi önerir ve teklif gerçekten cazip görünür: çözücüde filtreleme, akıllı TV ve hiçbir eklentinin ulaşamadığı telefon uygulamaları dahil, tüneldeki her cihazı kapsar. Özellikle mobilde araya girilebilecek tek pratik yerdir. Ayrıca sizi sessizce kendi altyapınıza güvensizleştirmeye en çok yatkın özelliktir ve nedenini olurken değil, olmadan önce anlamakta fayda vardır.

Birinci bedel, arızaların arıza gibi görünmemesidir. Bozuk bir çözücü kendini ilan eder; engellenmiş bir alan adı ise hiçbir şey yapmayan bir ödeme düğmesi, dönen bir yükleme simgesinde sıkışmış bir uygulama, hiç gelmeyen bir e-posta olarak kendini gösterir. Belirti, listeyi kurduktan haftalar sonra, hakkında hiç düşünmediğiniz bir cihazda ortaya çıkar ve başka bir ay verdiğiniz bir DNS kararıyla hiçbir şey onu ilişkilendirmez. Kurduğunuz her engelleme listesi, bir yabancı tarafından yazılmış ve haneniz üzerinde sessizce uygulanan bir politikadır. Bir tane eklerseniz, eklediğinizi not edin, küçük ve güvenilir tutun ve onu kapatmanın tek komutluk bir yolunu saklayın — ağınızdaki açıklanamayan her şey için ilk hata ayıklama adımı "filtreyi atla ve tekrar dene" olur ve bu adımın ucuz olması gerekir.

İkinci bedel, insanların umduğunu yapmamasıdır. Sabit kodlanmış bir çözücü adresi olan ya da kendi DoH istemcisi gömülü bir uygulama, çözücünüze hiçbir şey sormaz; sabit kodlanmış bir IP'ye bir bağlantı açar ve gider. Tarayıcılar, aksi söylenmedikçe artan biçimde kendi DoH'ları üzerinden çözer. DNS engelleme, düşük emekli takip ve reklam gürültüsünün çoğunu kaldıran bir hijyen katmanıdır ve bir güvenlik kontrolü değildir, çünkü düşmanca olan her şey tasarım gereği onun etrafından dolanır.

Yine de istiyorsanız, ikinci bir daemon yerine Unbound içinde küçük bir yerel bölgeyi tercih edin — local-zone: "tracker.example." always_nxdomain ne ek bir yazılım, ne sonra savunmak zorunda kalacağınız bir portta bir web arayüzü, ne de çökebilecek ve isim çözümlemenizi de kendisiyle birlikte götürebilecek yeni bir hizmet gerektirir. Makinenin iş tanımını tek satırda tutun: isimleri çözer. Ona verdiğiniz her ek sorumluluk, her şeyin bir anda çalışmayı durdurmasının bir başka yoludur.

Çalıştırdığınız bir çözücü, sahip olduğunuz bir bağımlılıktır

Barındırdığınız bir web sitesi çöktüğünde, bazı insanlar bir şeyi okuyamaz. Çözücünüz çöktüğünde ise hiçbir şey çalışmaz — tarayıcı da çalışmaz, e-posta da, paket yöneticisi de, sunucunun çöktüğünü size söyleyecek olan uygulama da. Ucuz bir kutuya koyabileceğiniz en yük taşıyan hizmettir ve DNS gibi görünmeyen şekillerde bozulur.

Gerçekçi arıza biçimlerini önceden bilmekte fayda var, çünkü her birinin farklı bir imzası var. VPS yeniden başlar ve Unbound önyüklemede hiç etkinleştirilmemiştir, dolayısıyla ilk planlanmamış yeniden başlatmaya kadar her şey çalışır. Büyük bir engelleme listesi, 1 GB'lık bir örnekte önbelleği swap'a iter ve OOM killer çözücüyü seçer. Bir yerdeki bir bölge kendi DNSSEC imzalarını bozar ve doğru yapılandırılmış çözücünüz yanıtı reddederken, doğrulama yapmayan bir çözücüdeki herkes gezinmeye devam eder — kutunuz haklıdır ve site size hâlâ bozuk görünür, ki doğruladığınızı unutmuşsanız bu kafa karıştırıcı beş dakikadır. Ya da tünel düşer ve DNS = 10.66.0.1 yalnızca tünelin içinde var olduğu için, cihazın hiç çözücüsü kalmaz ve çevrimdışı olduğunu bildirir.

Önlemler hayli ucuzdur. Hizmeti önyüklemede etkinleştirin ve varsaymak yerine bir yeniden başlatmayla gerçekten test edin. İstemcilere ikincil bir çözücü verin, böylece ölü bir tünel durmak yerine daha kötü çalışsın — o yuvada herkese açık bir çözücü, yalnızca sizinki erişilemezken geçerli olan küçük, açık bir gizlilik tavizidir ve genellikle doğru takastır. Kısa bir üst akış kesintisinin sizin kesintiniz olmaması için serve-expired'ı açık tutun. Çözücüyü makinenin kendisinden değil, başka bir yerden kontrol edin — "çökmüş" ile "erişilemez" arasındaki farkı fark etmenin tek yolu budur.

Ve yapılandırmanın bir kopyasını saklayın. Bunun tamamı, doğru hâle getirmenin bir öğleden sonranızı aldığı ve bir yıl sonra hatırlamayacağınız birkaç düzine satırdır; WireGuard anahtarlarının yanında, şifrelenmiş, sunucu dışı yedeklerinizde yer almalıdır, böylece yeniden kurmak ikinci bir öğleden sonra değil, yirmi dakika sürer. Bu çalışmanın tamamının dürüst özeti budur: listedeki en ucuz planın fiyatına, tek bir işi yapan küçük bir kutu, saklama hakkında bir vaadi, kaydın basitçe hiç oluşturulmadığı bir düzenlemeyle değiştirir.

Adım adım

1. 01

   Zaten kilitlenmiş bir kutudan başlayın

   Bir çözücü küçük, sessiz bir hizmettir, bu da onu ortalıkta duran herhangi bir şeye kurmayı cazip kılar. Yapmayın — bu kutu, tünelinizdeki her cihazın aradığı her ismi görecek, dolayısıyla sır tutan başka her şeyle aynı muameleyi görmeyi hak ediyor. Beğendiğiniz en küçük planı devreye alın; aşağıdaki önbellek boyutları onlarca megabaytla ölçüldüğü için 1 GB RAM bir hane için bolca yeterlidir. Her şeyden önce devreye alma sonrası ilk saati tamamlayın: isimli bir kullanıcı, yalnızca anahtarla SSH, her iki IP ailesinde de varsayılan reddetme, gözetimsiz güvenlik güncellemeleri.

   Sonra Unbound'u kurun. Dağıtım paketi, kök ipuçlarını ve DNSSEC kök güven çapasını birlikte gönderir ve çapanın otomatik rollover'ını devreye alır — bu, paketlenmiş sürümün sizi gerçekten gelecekteki bir bozulma sınıfından kurtardığı az sayıdaki durumdan biridir.

   sudo apt update && sudo apt install -y unbound dnsutils
   unbound -V | head -n 3
   
   # the packaged trust anchor the resolver will validate against
   sudo ls -l /var/lib/unbound/root.key

   root.key eksikse, paketiniz unbound-anchor'ı çalıştırmamıştır ve doğrulama her şeyde kapalı başarısız olur. Devam etmeden önce onu bir kez sudo -u unbound unbound-anchor -a /var/lib/unbound/root.key ile üretin.

2. 02

   53 portunu systemd-resolved'dan geri alın

   Çoğu güncel dağıtımda 53 portu zaten birinin elindedir: systemd-resolved, 127.0.0.53 üzerinde bir stub dinleyici çalıştırır ve /etc/resolv.conf, ona işaret eden bir sembolik bağlantıdır. Bu çözülmeden Unbound başlamayı reddedecek, ya da başlayıp hiçbir işe yaramayacak şekilde bağlanacaktır. Düzenlemeden önce bakın.

   ss -ulpn 'sport = :53'
   ls -l /etc/resolv.conf

   Bir sonraki bloğu çalıştırmadan önce bu paragrafı okuyun: stub'ı devre dışı bırakmakla Unbound'u başlatmak arasında, bu makinenin çalışan hiçbir DNS'i yoktur. 3. ve 4. adımları aynı oturumda tamamlayın ve önce başka bir pencerede bir apt işlemi başlatmayın — bu, bir isim aramasında askıda kalacak ve siz bunu henüz başlatmadığınız çözücü sanıp yanlış teşhis edeceksiniz.

   # stop resolved from holding the port (appends inside the [Resolve] section)
   printf 'DNSStubListener=no\n' | sudo tee -a /etc/systemd/resolved.conf
   sudo systemctl restart systemd-resolved
   
   # point the host at the resolver it is about to run
   sudo rm -f /etc/resolv.conf
   printf 'nameserver 127.0.0.1\noptions edns0 trust-ad\n' | sudo tee /etc/resolv.conf
   
   # the port should now be free
   ss -ulpn 'sport = :53'

3. 03

   Recursion yapan ve unutan bir yapılandırma yazın

   Paketlenmiş yapılandırmayı olduğu gibi bırakın ve kendi dosyanızı drop-in dizinine ekleyin, böylece bir paket yükseltmesi kararlarınızı asla sessizce geri almaz. Aşağıdaki her satır, ya yabancıları reddetmekle, ya kökten recursion yapmakla ya da kayıt tutmamakla ilgilidir. Farklıysa, 10.66.0.1 ve 10.66.0.0/24'ü kendi WireGuard sunucunuzdaki tünel adresi ve alt ağıyla değiştirin.

   sudo tee /etc/unbound/unbound.conf.d/private-resolver.conf > /dev/null <<'EOF'
   server:
       # listen for the host itself and for the tunnel — never on 0.0.0.0
       interface: 127.0.0.1
       interface: 10.66.0.1
       port: 53
   
       # default-deny: refuse the internet, then allow what you trust
       access-control: 0.0.0.0/0 refuse
       access-control: ::/0 refuse
       access-control: 127.0.0.0/8 allow
       access-control: 10.66.0.0/24 allow
   
       # recurse from the root and send each server only the label it needs
       qname-minimisation: yes
       harden-dnssec-stripped: yes
       harden-below-nxdomain: yes
       harden-glue: yes
       aggressive-nsec: yes
       use-caps-for-id: yes
   
       # answer nothing about the software or the host
       hide-identity: yes
       hide-version: yes
   
       # keep no query log, and say little to the journal
       verbosity: 0
       log-queries: no
       log-replies: no
   
       # a warm cache is an upstream observation that never happens
       cache-min-ttl: 120
       cache-max-ttl: 86400
       prefetch: yes
       prefetch-key: yes
       serve-expired: yes
   
       # belt and braces if a rule above is ever loosened
       ratelimit: 1000
       ip-ratelimit: 100
   
       # sizing for a small instance
       num-threads: 2
       so-reuseport: yes
       msg-cache-size: 32m
       rrset-cache-size: 64m
   EOF

   Dosyada olmayan şeye dikkat edin: forward-zone yoktur. Onun yokluğu, bunu başkasının önbelleği önünde bir önbellek değil, recursive bir çözücü yapan şeydir. Daha sonra bir öğreticiden birini ekleyen bir parça yapıştırırsanız, çalışmanın tüm amacını sessizce geçersiz kılmış olursunuz.

4. 04

   Başlatın, sonra DNSSEC'in gerçekten doğruladığını kanıtlayın

   Herhangi bir şeyi yeniden başlatmadan önce sözdizimini kontrol edin — kendi resolv.conf'u artık Unbound'a işaret eden bir kutuda, bir yapılandırma hatası, hata ayıklarken hiç isim çözümlemesi olmaması anlamına gelir.

   sudo unbound-checkconf
   sudo systemctl enable --now unbound
   systemctl --no-pager status unbound | head -n 5

   Şimdi önemli olan iki davranışı doğrulayın, çünkü yanıt veren bir çözücü, doğrulayan bir çözücüyle aynı şey değildir. İmzalı bir isim ad bayrağıyla — authenticated data — geri gelmelidir ve kasıtlı olarak bozulmuş imzalara sahip bir isim, çözülmek yerine SERVFAIL ile kapalı başarısız olmalıdır.

   # should show: flags: qr rd ra ad
   dig @127.0.0.1 example.com +dnssec | grep -E '^;; flags'
   
   # should show: status: SERVFAIL  (not NOERROR, not an address)
   dig @127.0.0.1 dnssec-failed.org | grep -E '^;; ->>HEADER'
   
   # and a normal name should simply work
   dig @127.0.0.1 +short cloudflare.com

   Bozuk bölge bir adrese çözülüyorsa, doğrulama çalışmıyordur: /var/lib/unbound/root.key'ın var olduğunu ve unbound kullanıcısı tarafından okunabilir olduğunu kontrol edin. Her şey SERVFAIL ise, olağan neden ciddi şekilde yanlış olan bir saattir — imzaların geçerlilik pencereleri vardır ve senkronizasyonu birkaç saat kaymış bir kutu, internetin tamamını reddeder.

5. 05

   Herkese açık kapıyı kapatın, yalnızca tüneli açın

   Yapılandırma zaten yabancıları reddediyor. Bu adım, bir yabancının en baştan ulaşabileceği hiçbir şey olmamasını sağlar — iki kilitten ikincisi ve birincisine ileride yapılacak bir düzenlemeden sağ çıkan kilit.

   # DNS is reachable from the tunnel interface only
   sudo ufw allow in on wg0 to any port 53 proto udp
   sudo ufw allow in on wg0 to any port 53 proto tcp
   sudo ufw status verbose

   Sonra bunu, önemli olan tek yolla, başka bir makineden doğrulayın. Sunucunun kendisinden test etmek hiçbir şey kanıtlamaz — loopback'e kasıtlı olarak izin verilir. Bunu laptop'unuzdan, tünel kapalıyken, ya da sahip olduğunuz başka bir host'tan çalıştırın.

   # must time out. an answer here means you are running an open resolver.
   dig @SERVER_PUBLIC_IP example.com +time=3 +tries=1
   
   # same question over IPv6, which is the half people forget
   dig -6 @SERVER_IPV6 example.com +time=3 +tries=1

   İkisinden biri bile bir yanıt döndürürse, kötüye kullanım raporundan sonra değil, şimdi durup düzeltin. Olağan nedenler, paketlenmiş bir yapılandırma dosyasında bırakılmış bir interface: 0.0.0.0, daha önceki bir denemeden kalan 53'e genel olarak izin veren bir güvenlik duvarı kuralı, ya da ufw'yi tamamen atlayan, bir konteyner portu yayımlayan Docker'dır.

6. 06

   Cihazlarınızı ona yönlendirin

   İstemci tarafında bu tek satırlık bir değişikliktir. WireGuard istemci yapılandırmasında, DNS satırı, herkese açık bir çözücü yerine sunucunuzun tünel adresi olur — bu, DNS = 9.9.9.9'u WireGuard rehberinden devreden çıkaran düzenlemedir.

   [Interface]
   PrivateKey = <paste client.key>
   Address = 10.66.0.2/32, fd86:ea04:1115::2/128
   DNS = 10.66.0.1
   
   [Peer]
   PublicKey = <paste server.pub>
   Endpoint = YOUR_SERVER_IP:51820
   AllowedIPs = 0.0.0.0/0, ::/0
   PersistentKeepalive = 25

   Tüneli kaldırın ve istemciden iki ayrı şeyi doğrulayın: yanıtların çözücünüzden geldiğini ve recursion'ın gerçekten başka bir yerden değil, VPS'inizden çıktığını. İkinci kontrol asıl yararlı olandır — whoami.akamai.net, sorduğu çözücünün adresini döndürür, dolayısıyla sunucunuzun herkese açık IP'sini ve başka hiçbir şeyi yazdırmalıdır.

   # answers should come from the tunnel address
   dig example.com | grep -E 'SERVER:'
   
   # should print your VPS public IP — this is the leak test
   dig +short whoami.akamai.net
   
   # and the ad flag should still be there, end to end
   dig example.com +dnssec | grep -E '^;; flags'

7. 07

   DNS-over-TLS'i yalnızca tünel tutamayan bir cihaz için ekleyin

   Kalıcı bir tünel olmadan kapsanmasını istediğiniz belirli bir cihazınız — genellikle sistem çapındaki Private DNS ayarı üzerinden bir Android telefon — olmadıkça bu adımı atlayın. Bir hostname ve bir sertifika gerektirir ve bu hostname, Certificate Transparency günlüklerinde kalıcı, herkese açık bir kayıt haline gelir, dolayısıyla diğer kimliklerinize hiç yaklaşmayan bir isim seçin.

   sudo apt install -y certbot
   sudo ufw allow 80/tcp comment 'certbot, temporarily'
   sudo certbot certonly --standalone -d dns.example.net
   sudo ufw delete allow 80/tcp
   
   # unbound must be able to read the key
   sudo usermod -a -G ssl-cert unbound 2>/dev/null || true
   sudo chgrp -R ssl-cert /etc/letsencrypt/live /etc/letsencrypt/archive
   sudo chmod -R g+rX /etc/letsencrypt/live /etc/letsencrypt/archive

   TLS dinleyicisini kendi drop-in dosyası olarak ekleyin, böylece fikrinizi değiştirirseniz onu bir hamlede silebilirsiniz.

   # NOTE: drop-in files are read in alphabetical order and the last
   # access-control line for a given prefix wins — so this file must
   # sort AFTER private-resolver.conf, or its refuse rule overrides
   # the allow below and every DoT client gets REFUSED.
   sudo tee /etc/unbound/unbound.conf.d/zz-dot.conf > /dev/null <<'EOF'
   server:
       interface: 0.0.0.0@853
       interface: ::0@853
       tls-service-key: "/etc/letsencrypt/live/dns.example.net/privkey.pem"
       tls-service-pem: "/etc/letsencrypt/live/dns.example.net/fullchain.pem"
       # roaming clients have no fixed address, so this endpoint must accept any.
       # safe only because port 53 stays bound to loopback + wg0 and blocked at
       # the firewall — TLS over TCP cannot be spoofed, so it cannot be reflected.
       access-control: 0.0.0.0/0 allow
       access-control: ::/0 allow
   EOF
   sudo ufw allow 853/tcp
   sudo unbound-checkconf && sudo systemctl restart unbound

   Ona güvenmeden önce tünelin dışından test edin, sonra hostname'i telefonun Private DNS alanına girin. Yenileme, üç ay sonra sessizce bozulan kısımdır — certbot sertifikayı değiştirir ama Unbound eskisini bellekte tutar, dolayısıyla onu yeniden yükleyen bir deploy hook'u ekleyin.

   kdig -d @dns.example.net +tls-ca +tls-host=dns.example.net example.com
   
   echo 'systemctl reload unbound' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/unbound.sh
   sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/unbound.sh