Özel DNS Çözümleyici Nasıl Kurulur?
Özel DNS çözümleyici, istemciler adına DNS sorgularını yanıtlamak ve sonuçları önbelleğe almak için yerel ağda çalıştırılan bir recursive resolver (özyinelemeli DNS çözümleyicisi) hizmetidir. Alan adının kayıtlarını yayımlayan yetkili DNS sunucusundan farklı olarak istemcinin sorgusuna tam yanıt bulmaya çalışır.
Önbellekte yanıt yoksa hizmet, gerektiğinde kök sunuculardan başlayıp yetkili DNS sunucularını izleyerek çözümlemeyi kendisi yapabilir. DNS forwarder (DNS yönlendirici) olarak yapılandırılırsa sorguyu bir üst recursive resolver'a iletir. Aynı yazılım, alan adına göre bu iki yöntemi birlikte de kullanabilir.
Tek bir kurulum komutu bütün yazılım ve işletim sistemleri için geçerli değildir. Unbound, BIND veya Knot Resolver gibi güncel bir ürün seçin; aşağıdaki mimariyi üreticinin yayımladığı belgelerdeki seçenek adlarına göre uygulayın. Başlamadan önce erişim kapsamını, DNSSEC doğrulamasını, günlük politikasını ve arıza davranışını yazılı hale getirin.
Kurulum Öncesi Görev ve Kapsamı Belirleme
Önce hizmetin yalnız aynı cihazı mı, bir ofis ağını mı yoksa VPN kullanıcılarını mı kapsayacağını belirleyin. Recursive resolver için sabit bir servis adresi ayırın; istemcilerin bu adrese hangi ağ yoluyla ulaşacağını ve kesinti sırasında ne yapacağını tanımlayın.
- Yetkili DNS sunucularından doğrudan çözümleme, üst DNS hizmetine yönlendirme veya alan adına göre karma model seçin.
- Dinlenecek IP adreslerini ve sorgu gönderebilecek ağları listeleyin.
- DNSSEC doğrulamasını recursive resolver'ın mı yoksa üst DNS hizmetinin mi yapacağını belirleyin.
- Önbellek boyutunu, günlük kapsamını, saklama süresini ve izleme ölçütlerini planlayın.
- Yazılım güncellemesi, yapılandırma yedeği, ikinci recursive resolver ve geri dönüş sorumlularını belirleyin.
İç alan adlarını çözen özel bir yetkili sunucu kullanılıyorsa bu bölgeleri koşullu yönlendirme veya ürünün yerel bölge özelliğiyle ayırın. Herkese açık alan adlarının çözümlenmesini iç kayıtların yayımlanmasıyla karıştırmayın.
Yetkili Sunuculardan Çözümleme ve DNS Forwarder Kullanımı
| Ölçüt | Yetkili sunuculardan çözümleme | DNS forwarder ile yönlendirme |
|---|---|---|
| Sorgu yolu | Kök, üst düzey alan ve yetkili sunucuları izleyerek cevabı bulur. | Sorguyu seçilen bir veya daha fazla üst DNS hizmetine gönderir. |
| Bağımlılık | Tek bir üçüncü taraf recursive resolver'a bağlı değildir; DNS hiyerarşisine erişir. | Üst hizmetin erişilebilirliğine, politikasına ve yanıtlarına bağlıdır. |
| Gizlilik | Tek bir üst hizmet tüm sorguları görmez; ağ işletmecisi ve yetkili sunucular yine bazı verileri görebilir. | Üst hizmet kendisine iletilen sorgu akışını ve kaynakla ilgili verileri görebilir. |
| İşletim yükü | Kök sunucu ipuçları, DNSSEC güven zinciri, dış erişim ve performans yerelde yönetilir. | Üst hizmet seçimi, şifreli taşıma, doğrulama ve kesinti politikası yönetilir. |
| Uygun kullanım | Çözümleme denetimini yerelde tutmak isteyen ağlara uygundur. | Merkezi politika veya şifreli bir üst hizmet kullanmak isteyen ağlara uygundur. |
DNS forwarder kullanmak yerel önbelleği veya DNSSEC doğrulamasını kendiliğinden kaldırmaz. Birden fazla üst hizmet varsa seçim sırasını, sağlık kontrolünü ve başarısızlık davranışını belirleyin. Bazı ürünlerde yönlendirme başarısız olduğunda yetkili DNS sunucularından doğrudan çözümlemeye geçme seçeneği vardır; bu davranış kurumun kayıt ve güven politikasını aşabileceği için bilinçli olarak açılmalıdır.
Dinleme Adresi ve İstemci Erişimini Sınırlama
Hizmet yalnız aynı cihazda kullanılacaksa loopback (geri döngü) adresinde dinleyebilir. Ağdaki istemciler için LAN veya VLAN üzerindeki belirli adresleri kullanın. IPv4 ve IPv6 ayrı ayrı denetlenmelidir; yalnız IPv4 trafiğini sınırlandırmak IPv6 üzerinden oluşabilecek erişimi engellemez.
Dinleme adresi, ACL (Access Control List) ve güvenlik duvarı farklı katmanlardır. ACL içinde izinli kaynakları CIDR (Classless Inter-Domain Routing) bloklarıyla açıkça tanımlayın, diğer kaynakları reddedin. Unbound belgelerinde, IPv4 için varsayılan olarak yalnız 127.0.0.0/8 bloğuna izin verildiği belirtilir. Diğer ürünlerin varsayılanlarını da aynı kabul etmeyin; izinli IPv4 ve IPv6 kaynaklarını her kurulumda kontrol edin.
Güvenlik duvarında aynı izinli kaynaklardan hem UDP hem TCP için 53 numaralı porta izin verin. Genel amaçlı DNS uygulamaları her iki aktarımı da desteklemelidir. TCP’yi engellemek, DNSSEC veya büyük yanıtlar nedeniyle yalnız bazı sorgularda görülen aralıklı hatalara yol açabilir.
Recursive resolver'ı internete açık bir hizmete dönüştürmeyin. Modem üzerinde port yönlendirme yapmayın; bulut güvenlik grubunda tüm IPv4 veya IPv6 kaynaklarına 53 numaralı portu açmayın. Açık recursive resolver'lar, sahte kaynak adresli yansıtma ve yükseltme saldırılarında kullanılabilir. Erişimi uygulama, işletim sistemi güvenlik duvarı ve ağ sınırında birlikte daraltın.
Kök Sunucu İpuçları ve Üst DNS Hizmeti
Üst DNS hizmetine yönlendirmeden çözümleme yapacak recursive resolver, başlangıç için kök sunucuların ad ve adreslerini içeren kök sunucu ipuçlarına ihtiyaç duyar. Yazılımın yerleşik listesi kullanılabilir; ayrı dosya seçiliyorsa dosyayı IANA’nın güncel kök dosyalarından alın ve güncelleme yöntemini belgeleyin. Recursive resolver daha sonra başlangıç sorgusuyla güncel kök verisini önbelleğine alır.
DNS forwarder için tüm sorguları kapsayan bir üst hizmet, yalnız iç alanlar için koşullu yönlendirme veya ikisinin birleşimi kullanılabilir. Üst hizmetin IP adreslerini, desteklediği taşıma biçimini, kayıt politikasını ve kesinti davranışını birlikte değerlendirin. DoT (DNS over TLS) kullanılıyorsa sertifika adını ve güven zincirini doğrulayın; yalnız trafiğin şifrelenmiş olmasına güvenmeyin.
ECS (EDNS Client Subnet), istemcinin IP adresinin ağ bölümünü üst DNS hizmetine iletebilir ve konuma göre yanıt seçimini etkileyebilir; gizlilik gereksinimine göre kapatın veya sınırlandırın. Ürün destekliyorsa QNAME minimisation özelliği, yetkili sunuculara her aşamada yalnız gereken ad bölümünü göndererek sorgulanan adın gereksiz yere paylaşılmasını azaltır.
Doğrudan çözümleme yapacak hizmetin kök ve yetkili DNS sunucularına, yalnız DNS forwarder olarak çalışacak hizmetin ise onaylı üst DNS hizmetlerine erişebildiğini test edin. IPv6 çıkışını ancak ağda gerçekten çalışıyorsa kullanın; yarım yapılandırılmış IPv6, cevap gelmeyen denemeler ve gecikmeler oluşturabilir.
DNSSEC, Güven Çıpası ve 2026 KSK Değişimi
DNSSEC, imzalı DNS verisinin kökenini ve bütünlüğünü güven zinciriyle doğrular; sorguyu veya cevabı şifrelemez. DNSSEC doğrulayan recursive resolver, güven zincirinin başlangıcı olarak kullandığı güncel bir trust anchor’a (kök güven çıpasına) ihtiyaç duyar. KSK (Key Signing Key) ve DNSKEY kaydı güncellemeleri için yazılımın desteklediği otomatik güven çıpası mekanizmasını etkinleştirin. Hizmet hesabının güven çıpası dosyasına ve geçici güncelleme dosyalarına gerekli yazma yetkisine sahip olduğunu kontrol edin.
IANA, KSK-2024 anahtarının 11 Ekim 2026’da kök bölgeyi imzalamaya başlamasını planlıyor. DNSSEC doğrulayan recursive resolver'lar bu tarihten önce güncel güven çıpasını edinmiş olmalıdır. Üreticinin güncelleme talimatını uygulayın; otomatik güncellemeyi, paketle gelen güven çıpasını ve recursive resolver'ın tanıdığı anahtarları doğrulayın. Sabitlenmiş eski bir anahtar, değişim sonrasında geçerli alanların hatalı biçimde doğrulanamamasına yol açabilir.
İmzaların geçerlilik aralıkları nedeniyle sistem saati doğru olmalıdır. Bilerek geçersiz DNSSEC imzası taşıyan bir test alanına yapılan sorguda SERVFAIL yanıtı beklenir. Bu denetimi geçerli imzalı bir alanın başarıyla çözüldüğü testle birlikte yapın; tek başına SERVFAIL yanıtı DNSSEC doğrulama hatasını kanıtlamaz.
Önbellek, Gizlilik ve Günlük Ayarları
Önbellek tekrar sorgularını azaltır ve yanıt süresini düşürür. Kayıttaki TTL değerini gerekçe olmadan uzatmak eski verinin gereğinden uzun tutulmasına neden olabilir. Olumsuz cevapların da önbelleğe alınabileceğini hesaba katın; minimum ve maksimum TTL müdahalelerini yalnız ölçülmüş bir gerekçeyle kullanın. Bellek sınırını istemci ve sorgu hacmine göre ayarlayın.
Sorgu günlükleri istemci IP adresi, alan adı, kayıt türü ve zaman bilgisi içerebilir. Hata, güvenlik ve kapasite izlemesi için gereken en az veriyi kaydedin; erişim yetkisini, saklama süresini ve güvenli silme yöntemini belirleyin. Sürekli ayrıntılı günlük hem kişisel veri riskini hem disk ve işlem yükünü artırır.
DoH (DNS over HTTPS) veya DoT, istemci ile seçilen recursive resolver arasındaki taşıma yolunu şifreler. Üst hizmet sorguları görmeye devam eder; DNSSEC de gizlilik sağlamaz. Bu nedenle şifreleme, DNS sağlayıcısının kayıt politikası ve ECS ayarı birlikte değerlendirilmelidir.
Yazılım destekliyorsa istemci başına sorgu oranını, bekleyen sorgu sayısını ve kaynak sınırlarını tanımlayın. Oran sınırlama, hatalı veya ele geçirilmiş bir istemcinin kaynak tüketimini azaltır; ACL ve güvenlik duvarının yerini tutmaz.
Recursive Resolver Kurulumu ve İstemci Ayarları
- İstemci ağlarını, beklenen sorgu hacmini ve sabit servis adresini belirleyin.
- Güncellemeleri süren bir recursive resolver yazılımını güvenilir paket kaynağından kurun; mümkünse hizmeti ayrı ve kısıtlı bir hesapla çalıştırın.
- Yalnız gereken IPv4 ve IPv6 adreslerini dinleyin; izinli CIDR bloklarını ACL’ye ekleyip diğer kaynakları reddedin.
- Yetkili DNS sunucularından doğrudan çözümleme için kök sunucu ipuçlarını, yönlendirme için üst DNS hizmetlerini ve koşullu alan kurallarını yapılandırın.
- DNSSEC doğrulamasını ve güven çıpası güncellemesini etkinleştirin; sistem saatini ve dosya izinlerini kontrol edin.
- Güvenlik duvarında yalnız izinli kaynaklardan UDP ve TCP 53 erişimine izin verin; WAN yönündeki port açmalarını kaldırın.
- Önbellek, günlük, oran sınırı ve kaynak ayarlarını kapasiteye göre düzenleyip yapılandırmayı ürünün denetim aracıyla doğrulayın.
- İstemcilere adresi DHCP, VPN profili veya kontrollü statik ayarla dağıtın.
- Onaylanmamış DNS adreslerinin kullanımını, arıza davranışını ve geri alma adımlarını belgeleyin.
İstemcilere ikinci bir DNS sunucusu adresi vermek, bu sunucunun yalnız ilki yanıt vermediğinde kullanılacağını garanti etmez. İki sunucu da aynı güvenlik, filtreleme ve günlük politikasını uygulamalı; genel bir DNS hizmeti, politika etkileri denetlenmeden yedek olarak eklenmemelidir.
Çözümleme, TCP ve DNSSEC Testleri
| Test | Beklenen sonuç | Hata neyi düşündürür? |
|---|---|---|
| İzinli istemciden UDP ve TCP sorgusu | İki aktarımda da doğru kayıt döner. | Güvenlik duvarı, dinleme veya TCP desteği eksik olabilir. |
| İzinli ağ dışından recursive resolver'a sorgu | İstek reddedilir veya cevaplanmaz. | ACL ya da ağ sınırı recursive resolver'ı dışarı açmış olabilir. |
| Geçerli ve bilerek bozuk DNSSEC verisi | Geçerli alan çözülür; bozuk veri doğrulama hatası verir. | Güven çıpası, saat veya DNSSEC ayarı incelenmelidir. |
| Aynı sorgunun tekrarı | Önbellek istatistiğinde isabet görülür. | Önbellek kapalı, taşmış veya politika tarafından atlanmış olabilir. |
| Üst DNS hizmetinin kesilmesi | Tanımlı yedek devreye girer ya da belirlenen hata oluşur. | Gizli geri dönüş veya zaman aşımı politikası yanlış olabilir. |
Yalnız bir alan adının açılmasına bakmayın. Farklı kayıt türlerini, var olmayan adların olumsuz cevaplarını, büyük cevapları, IPv4 ve IPv6 yolunu, koşullu iç alanları ve izin verilmeyen kaynakları ayrı ayrı sınayın. Günlük ve istatistiklerde yalnız beklenen istemci ağlarının bulunduğunu kontrol edin.
Sık Yapılan Kurulum Hataları
- Recursive resolver ile yetkili DNS sunucusunu aynı görev sanmak.
- ACL olmadan yalnız güvenlik duvarına veya güvenlik duvarı olmadan yalnız uygulama ayarına güvenmek.
- UDP 53’e izin verip TCP 53’ü engellemek ve aralıklı çözümleme hatalarını yanlış yorumlamak.
- IPv4’ü sınırlandırırken IPv6 güvenlik duvarını ve bulut güvenlik grubunu denetlememek.
- Üst DNS hizmeti arızasında fark edilmeden yetkili DNS sunucularına doğrudan sorgu gönderen bir ayarla kayıt politikasını aşmak.
- Bozuk saat, eski güven çıpası veya yanlış dosya izni yüzünden DNSSEC doğrulamasını bozmak.
- Ayrıntılı sorgu günlüklerini süresiz tutarak gereksiz veri ve kaynak yükü oluşturmak.
- İstemcilere farklı güven politikasındaki bir genel DNS adresini ikinci seçenek olarak dağıtmak.
Güncelleme, İzleme ve Yedeklilik
DNS yazılımının ve işletim sisteminin güvenlik güncellemelerini düzenli uygulayın. Kök sunucu ipuçları, güven çıpası, sertifika deposu ve üst DNS hizmeti ayarlarının nasıl güncellendiğini belgeleyin. Servis durumuna ek olarak çözümleme başarısızlıklarını, gecikmeyi, önbellek isabet oranını, reddedilen sorguları, TCP kullanımını, bellek ve disk tüketimini izleyin.
Süreklilik gerekiyorsa ikinci recursive resolver'ı aynı güç, ağ veya sanallaştırma arızasından etkilenmeyecek bağımsız bir yerde çalıştırın. İki recursive resolver'da aynı ACL, DNSSEC, güncelleme, günlük ve izleme politikalarını uygulayın. Bakım sırasında birini devreden çıkarıp istemcilerin diğerine gerçekten geçtiğini test edin; yedekliliği yalnız yapılandırmada iki adres görünmesine dayanarak kabul etmeyin.
