VPS ağları için özel DNS: Nasıl çalışır ve ne zaman gerekir

Üçüncü bir sunucu açıyorsunuz, makinelerin birbirine IP yerine adla ulaşmasını istiyorsunuz ve "private DNS VPS" araması yapıyorsunuz. Üç sonuç geliyor ve birbirini tutmuyorlar. Biri telefonunuzun sorgularını şifreleyen bir Android ayarı. Biri bir alan adının ad sunucularını markalamak için hazırlanmış bir cPanel rehberi. Biri de özel barındırılan bölgelere dair bir AWS belgesi. 20 Temmuz 2026'da Cloudflare, Internal DNS'i genel kullanıma sundu ve bunu "bazen özel DNS olarak da anılır" şeklinde tanımladı; böylece karışıklık artık altyapı sağlayıcılarından da geliyor.

Terim aşırı yüklenmiş durumda. Bu makale farklı anlamları ayırıyor, ardından VPS ağ anlamına odaklanıyor: sunucular arası iletişim için dahili bir DNS bölgesi. Sonunda hangi sisteme ihtiyacınız olduğunu belirleyebilir, filonuzun özel DNS gerektirip gerektirmediğine karar verebilir ve yaygın tasarım hatalarından kaçınabilirsiniz.

Özetle

• "Özel DNS" birbiriyle ilgisiz en az üç sistemi adlandırır: bir sunucu ağı için dahili DNS bölgesi, Android'in DNS-over-TLS şifreleme özelliği ve cPanel'in markalı ad sunucuları. Bu makale terimi ilk anlamıyla kullanıyor: bir VPS ağı için dahili DNS bölgesi.
• Bir VPS özel DNS bölgesi, ağ kapsamlı dahili bir ad alanıdır ve şu gibi ana bilgisayar adlarını db.internal.example.com özel IP adreslerine eşler. Kayıtları genel DNS'te yayımlanmaz.
• Sabit IP'lere sahip birkaç sunucu için /etc/hosts gerçekten yeterlidir. Dahili bir DNS sunucusu; filo büyüdüğünde, IP'ler sık değiştiğinde ya da servisler güvenilir ad çözümlemesine ihtiyaç duyduğunda kendini amorti eder.
• Çoğu üretim VPS ağı için sahibi olduğunuz bir alt alan adı kullanın, örneğin internal.example.com. .internal ad alanını yalnızca ağlar arası ad çakışmalarının, özel bir CA ile sertifika yönetiminin ve özel DNSSEC işleyişinin kabul edilebilir olduğu izole bir kurulumda kullanın. mDNS tarafından ayrılmış olan .local'dan kaçının.

Bu Makalenin Kapsamadığı Konular

Bu yazı, özel DNS'in VPS ağ anlamıyla sınırlı kalıyor. İlgisiz tüketici ve barındırma markası kullanımlarını kapsamıyor:

• Bir telefonda Android'in özel DNS veya DNS-over-TLS ayarını yapılandırmak.
• Bir barındırma markası için cPanel özel ad sunucuları kurmak.
• BIND 9, Unbound, dnsmasq veya CoreDNS için tam bir kurulum rehberi. Buradaki uygulama, adım adım yapılandırma değil, referans düzeyinde kalıyor.
• 1.1.1.1 veya NextDNS gibi şifreli tüketici çözümleyicileri, bunları ağ anlamından ayırt etmenin ötesinde.

"Özel DNS" gerçekte ne anlama geliyor?

"Özel DNS" tek bir sistem değildir. Terim birbiriyle ilgisiz en az üç sistemi adlandırır: bir VPS veya VPC ağı içinde dahili ana bilgisayar adlarını çözen, ağla sınırlı bir DNS bölgesi; Android'in DNS-over-TLS şifreleme özelliği; ve cPanel'in özel markalı yetkili ad sunucuları. Bu makale birincisini ele alıyor: sunucularınızın birbirini bulmak için sorguladığı dahili bölge. Dördüncü, daha gevşek bir kullanım da var: "özel" diye pazarlanan şifreli genel çözümleyiciler.

Dört anlam yalnızca bir adı paylaşır, başka hiçbir şeyi değil:

Cloudflare'in Internal DNS genel kullanıma sunum duyurusu, ilk anlamın güncel ve yönetilen bir örneği ve bu karışıklığın yeni yeni görünür olmasının nedenlerinden biri: bir altyapı sağlayıcısı artık lansman metninde "özel DNS"i dahili DNS ile eş anlamlı kullanıyor. Tarif ettiği sistem, Enterprise müşteriler için Gateway Resolver ile Internal Authoritative DNS ikilisi, bir VPS filosunda kendiniz kurduğunuzla aynı kategoride, sadece yönetilen hâli.

Bölümün özeti: "Özel DNS" denen başlıca sistemler bir etiketi paylaşır, bir işlevi değil. Bir kurulum rehberini izlemeden önce hangi anlamın kastedildiğini belirleyin.

Özel DNS bir VPS ağında nasıl çalışır?

Bir VPS özel DNS bölgesi, sunucularınızın kullanacak şekilde yapılandırıldığı bir çözümleyici tarafından sunulan, ağ kapsamlı bir ad alanıdır. Şu gibi dahili ana bilgisayar adlarını db.internal.example.com denetlediğiniz bir aralıktaki özel IP adreslerine eşler. Kayıtlar genel DNS'te yayımlanmaz; yine de sorgular çözümleyiciye ulaşmadan önce özel bir tünelden ya da yönetilen bir DNS kontrol düzleminden geçebilir. Bu ayrım, özel DNS ile genel DNS arasındaki farkın özüdür: protokol aynıdır, ancak bölgenin görünürlüğü ve erişim kapsamı farklıdır.

İşi üç parça yapar. Yetkili bir sunucu ya da bölge kaynağı dahili bölgeyi ve kayıtlarını tutar. Bir çözümleyici, sunucularınızın gönderdiği sorgulara yanıt verir. Bölgenin A ve AAAA kayıtları da dahili ana bilgisayar adlarını özel adreslere eşler; böylece app.internal.example.com uygulama katmanına çözülür ve db.internal.example.com veritabanına çözülür. Diğer kayıt türleri takma adlar veya servis bilgisi sağlayabilir. Bölge ve çözümleyici yolu doğru yapılandırıldığında, çözümleyici dahili sorguyu genel DNS köküne göndermek yerine yerel olarak yanıtlar.

Bulut platformları bunu makineye değil ağa bağlar; bu da işe yarar bir referans modeldir. AWS Route 53 özel barındırılan bölgeleri yalnızca VPC'de hem enableDnsHostnames hem de enableDnsSupport true olarak ayarlıysa çalışır ve çözümleyici, bölgeyle ilişkilendirdiğiniz her VPC için özel bölgeden yanıt verir. Google Cloud özel bölgeleri yetkilendirilmiş VPC ağlarıyla sınırlıdır ve standart VPC çözümleme sırasında bir giden sunucu politikası yolu değiştirmediği sürece genel DNS'ten önce kontrol edilirler. Bunları bir platform eğitimi değil, deseni gösteren örnekler olarak okuyun: kendi yönettiğiniz dahili bir DNS sunucusu da aynı fikirdir, sadece kendi VPS'inizde çalışır.

Bölgeyi genel DNS'in dışında tutmak işin yalnızca yarısı. DNS servisini özel bir arayüze bağlayın ya da UDP ve TCP 53 numaralı bağlantı noktasını özel ağınıza veya VPN'inize kısıtlayın. Özyinelemeli servisi genel internete açmayın; çünkü açık bir çözümleyici DNS yükseltme saldırılarında kötüye kullanılabilir.

Özel ve genel bölgeler aynı DNS kayıt ve önbellekleme modelini kullanır. Kayıtlar bir TTL taşır ve önbellekleyen çözümleyiciler bir yanıtı normalde o TTL dolana kadar yeniden kullanır; yine de çözümleyiciye özgü ayarlar etkili önbellek süresini değiştirebilir. Bu davranışı, bir alan adını VPS'e yönlendirme rehberimizde ele alıyoruz, şunlar dahil: DNS yayılımı ve TTL temelleri; bu yüzden burada yeniden anlatılmıyor.

VPS ağınızın özel DNS'e gerçekten ne zaman ihtiyacı olur?

İki ya da üç sabit sunucu için /etc/hosts gerçekten yeterlidir. Dahili bir DNS sunucusu; filo büyüdüğünde, IP'ler düzenli olarak değiştiğinde ya da uygulamalar güvenilir servis keşfine ihtiyaç duyduğunda kendini amorti eder. Asıl tetikleyici, sabit bir sunucu sayısı değil, operasyonel karmaşıklıktır.

/etc/hosts her Linux makinesinde zaten bulunan, ana bilgisayar adını IP'ye eşleyen statik bir haritadır. Ne bir arka plan servisine ne de bölge dosyasına ihtiyaç duyar; ama eskimiş ya da tutarsız kopyalar gerçek birer arıza biçimidir. Her sunucunun özel IP'sini dosyaya ekleyin, kopyaları eşitli tutun; makineler birbirini adla bulabilir. Küçük ve sabit bir filo için doğru yanıt budur; onun yerine BIND 9'a uzanmak, hiçbir kazanç sağlamadan bakımını üstleneceğiniz bir servis eklemek olur.

Bu yaklaşım üç durumda tıkanır. Sunucuları sık sık ekleyip çıkardığınızda, statik bir dosyayı her ana bilgisayarda tutarlı tutmak elle yapılan bir angaryaya dönüşür. IP'ler otomatik ölçeklendirme, yeniden kurulum ya da sağlayıcı yeniden atamalarıyla değiştiğinde dosya sessizce eskir. Konteynerler veya izole çalışma ortamları ana bilgisayarın kayıtlarını devralmadığında ise eşleme artık evrensel olmaktan çıkar. Bunlardan herhangi biri gerçek tetikleyicidir. Tek başına sunucu sayısı kaba bir göstergedir, asıl sinyal değil.

Bölümün özeti: tetikleyici, sunucu sayısı değil, operasyonel değişim hızıdır. Donmuş, on makinelik bir filo /etc/hostsile idare edebilir; her gece yeniden kurulan üç makinelik bir filo muhtemelen edemez.

Root erişimi, NVMe ve AMD EPYC gücüne sahip bir Linux VPS üzerinde geliştir.

Linux Planlarını Gör

Hangi DNS sunucusunu çalıştırmalısınız: BIND 9, Unbound, dnsmasq mı CoreDNS mi?

Filonuzun biçimine göre seçin. dnsmasq, hafif DNS ve gerektiğinde aynı servisten DHCP isteyen küçük ağlara uyar. Unbound, yalın ve doğrulama yapan özyinelemeli bir çözümleyicidir; mütevazı bir yerel bölgeye de yanıt verebilir. BIND 9, en geniş yapılandırma yüzeyiyle kapsamlı yetkili ve özyinelemeli yetenekler sunar. CoreDNS ise DNS'in servis keşfinin parçası olduğu konteyner ve Kubernetes filolarına uygundur.

Seçim mantığı kısa. Hosts benzeri bir dosyaya dayanan küçük bir çözümleyiciye ihtiyacınız varsa ya da zaten DHCP kiralamaları dağıtıyorsanız, dnsmasq sistemden hareketli bir parça eksiltir. Çoğunlukla dışarı yönlendiren, doğrulama yapan ve mütevazı bir dahili bölgeye yanıt veren bir çözümleyiciye ihtiyacınız varsa, Unbound tam da bu dar özellik kümesini tam bir BIND 9 kurulumu olmadan sunar. Tam yetkili denetim, yetki devri ve gece üçte dayanabileceğiniz en geniş belge birikimi gerekiyorsa, daha geniş yapılandırma yüzeyine rağmen BIND 9 ihtiyatlı seçimdir. DNS zaten bir konteyner ya da Kubernetes servis keşif yığınının parçasıysa, CoreDNS onu olduğu yerde karşılar. Genel kural: filonuzun biçimini karşılayan en küçük şeyi çalıştırın.

Üretim ortamındaki bir filoda tek bir DNS örneğini her dahili ada giden yegâne yol hâline getirmeyin. Bölgeye yanıt verebilecek en az iki DNS örneği en az iki örneği çalıştırın, mümkün olduğunda bunları ayrı arıza alanlarına yerleştirin ve istemcileri her ikisine de erişecek şekilde yapılandırın. Aksi hâlde tek bir DNS kesintisi, sağlıklı servisleri ölmüş gibi gösterebilir.

Dahili alan adınızı nasıl adlandırmalısınız: .internal, .local mi yoksa bir alt alan adı mı?

Çoğu üretim VPS ağı için sahibi olduğunuz bir alt alan adı kullanın, örneğin internal.example.com. .internal ad alanını yalnızca ağlar arası ad çakışmalarının, özel bir CA ile sertifika yönetiminin ve özel DNSSEC işleyişinin kabul edilebilir olduğu izole bir kurulumda kullanın. mDNS tarafından ayrılmış olan .local'dan kaçının.

.local sorunu somuttur. RFC 6762 .local ile biten adlara Multicast DNS kapsamında özel bir işleyiş tanır; bu yüzden aynı soneki kullanan tek noktaya yayın bir BIND 9 veya Unbound bölgesi, Apple cihazlarındaki ve mDNS destekli diğer sistemlerdeki mDNS davranışıyla çakışabilir. İstemciye özgü geçici çözümlere bel bağlamak yerine farklı bir ad alanı kullanın.

Uzman ipucu: Devraldığınız dahili bir .local bölgesi varsa bunu teknik borç sayın. Bazı istemciler .local sorgularını tek noktaya yayın DNS sunucunuza değil mDNS'e gönderir; bu da istemciye göre değişen ya da aralıklıymış gibi görünen arızalara yol açabilir.

ICANN Yönetim Kurulu, .internal alan adını kalıcı olarak ayırdı ve Temmuz 2024'te, daha önceki bir SSAC tavsiyesinin ardından genel DNS kökünde yetkilendirilmesini engelledi. Bunun altındaki adlar tasarım gereği küresel DNS üzerinden çözülmeyecek. Bunun ödünleri var: .internal adları küresel olarak benzersiz değildir, genel sertifika otoritelerinin bunlara sertifika vermesi beklenmez ve küresel güven çıpasına dayanarak DNSSEC doğrulaması yapan çözümleyiciler bunları çözemez. .internal üzerinde HTTPS gerekiyorsa, özel bir CA işletmeyi planlayın.

Burada iki şeyi ayrı tutun. ICANN'in ayırma kararı nihaidir. Bundan ayrı olarak, etkin bir Internet-Draft olan draft-davies-internal-tld-066 Mayıs 2026'da, bu ad alanını belgelemek ve RFC 1918 özel adreslemesiyle karşılaştırmak için yayımlandı. Bu hâlâ üzerinde çalışılan bir Internet-Draft, yayımlanmış bir RFC değil; dolayısıyla .internal'ı bir IETF standardı olarak değil, ICANN tarafından ayrılmış özel kullanım amaçlı bir üst düzey alan adı olarak tanımlayın.

Çoğu VPS filosu için, denetlediğiniz bir alan adının alt alanı daha güvenli varsayılandır. ISC bir alt alan adı hiyerarşisi öneriyor; örneğin kendi alan adınızın dahili bir alt alanı, aynı üst bölgenin ayrı ve eksik dahili ve genel sürümlerini sürdürmeye tercih edilir. Bu tercih bir üslup meselesi değil; bir sonraki bölümdeki arızayı önlüyor.

Bölümün özeti: ad alanı kararı uzun ömürlüdür. Denetlediğiniz bir alt alan adı, küresel benzersizliği koruduğu ve genel PKI ile çalıştığı için çoğu üretim ortamında varsayılandır. İzole ve özel bir ad alanı daha uygunsa ve DNSSEC, sertifika ve çakışma ödünlerini kabul ediyorsanız .internal kullanın.

Bölünmüş ufuklu DNS ve onu bozan hatalar

Bölünmüş ufuklu DNS, aynı ana bilgisayar adına soranın kim olduğuna göre farklı yanıt verir: içeride özel IP, dışarıda genel IP. En sık, aynı alan adı üzerindeki NXDOMAIN tuzağı, amaçlanan görünümü atlayan alternatif çözümleyiciler ve beklenen üst sunucuya ulaşmayan konteyner DNS yolları yüzünden bozulur. Bunu doğru yapmak tek bir şeye değil, aynı anda üç şeye bağlıdır.

NXDOMAIN tuzağı, tam da ISC'nin doğrudan uyardığı arızadır. Dahili sunucularınız üst alan adı için yetkiliyse, ama bölgenin onlardaki sürümü www ana bilgisayarı gibi bir genel kaydı içermiyorsa, bu adı sorgulayan dahili bir istemci, genel bölgede kayıt bulunmasına rağmen NXDOMAIN alır. Dahili bölge yetkilidir ve üst alan adı için genel DNS'e geri düşmez. Adlandırma bölümündeki alt alan adı hiyerarşisi yaklaşımının ISC'nin tercih ettiği tasarım olmasının nedeni tam olarak budur.

Uzman ipucu: Sunucularınızı aynı alan adı üzerindeki bölünmüş ufuklu bir kuruluma yönlendirmeden önce, ağın içinden o alan adındaki bilinen bir genel adı sorgulayıp deneyin. Dışarıda sorunsuz çözülen bir ad için NXDOMAIN yanıtı almak, bu tuzağın imzasıdır.

Gözden kaçması kolay üç tuzak daha var. Bir ana bilgisayarda ya da konteynerde yapılandırılmış alternatif bir çözümleyici bu ayrımı atlayabilir; çözümleyici uygulamasına göre bir zaman aşımının ardından ya da paralel olarak sorgulanabilir, dolayısıyla yanıtlar değişebilir. Docker'ın varsayılan köprüsündeki konteynerler başlarken ana bilgisayarın DNS yapılandırmasının bir kopyasını alır; özel ağlardaki konteynerler ise Docker'ın gömülü çözümleyicisini 127.0.0.11adresinden sorgular. O çözümleyici, dış sorguları ana bilgisayar veya konteyner için yapılandırılmış DNS sunucularına iletir; dolayısıyla split-DNS davranışı yalnızca konteynerin kendi çözümleyici dosyasına değil, Docker ve ana bilgisayar yapılandırmasına bağlıdır. Dahili bir servis şu gibi bir ters vekil sunucunun arkasındaysa: Nginx Proxy Yöneticisisertifika doğrulaması başarısız olabilir; çünkü sertifika istenen ana bilgisayar adını kapsamıyor ya da onu veren CA istemcide güvenilir değildir. İçeride farklı bir sertifika kullanmak tek başına hata değildir. Bunlar yapılandırma boşluklarıdır, araç hataları değil.

Uzaktaki istemciler de aynı arızaya düşebilir; örneğin bir kendi barındırdığınız VPN DNS sorgularını amaçlanan dahili çözümleyiciye göndermez ya da yönlendirmezse.

Bir de güvenlik boyutu var. Dahili ana bilgisayar adları ve özel IP'ler genel DNS kayıtlarına sızarsa, dahili adlandırma ve adresleme şemanızın bir bölümünü sorgulayan herkese açmış olursunuz. Bölünmüş ufuk kısmen bu haritayı içeride tutmak için vardır ve yanlış yapılandırılmış bir genel bölge bunu sessizce bozar.

Bölümün özeti: bölünmüş ufkun arızaları yapılandırma tuzaklarıdır, araç kusurları değil. Doğruluk; adlandırma disiplinine, her istemcinin gerçekte hangi çözümleyiciye sorduğunu bilmeye ve bölgeyi doğru kapsamlandırmaya bağlıdır, tek bir ayara değil.

OKU

Bir Alan Adı VPS'ye Nasıl Yönlendirilir: Hızlı Rehber

Sonuç: Doğru özel DNS tasarımını seçmek

Artık hangi "özel DNS" sisteminden söz ettiğinizi ayırt edebilirsiniz. VPS ağı bağlamında bu, Android'in DNS-over-TLS ayarı ya da markalı yetkili ad sunucuları değil, dahili DNS bölgesidir. Filonuz küçük ve sabitse /etc/hosts savunulabilir bir tercihtir. Değilse, varsayılan ad alanı olarak sahibi olduğunuz bir alt alan adını kullanın, filonuza uyan en küçük DNS sunucusunu seçin; erişimi, yedekliliği ve bölgenin dahili mi genel mi olduğunu açıkça belirleyin. .internal'ı yalnızca izole bir ad alanı daha uygun olduğunda ve sertifika, DNSSEC ve çakışma ödünlerini kabul ettiğinizde kullanın.

Sıkça Sorulan Sorular