CoreDNS ile Özel DNS Resolver Kurulumu ve Split-Horizon DNS Rehberi

Son Güncelleme: Temmuz 2026

CoreDNS, modern sunucu altyapılarında esnek, modüler ve yönetilebilir DNS çözümleyici (DNS resolver) kurmak için kullanılan hafif bir DNS sunucusudur. Bu rehberde özel DNS resolver, split-horizon DNS, önbellekleme, güvenlik kısıtlamaları ve pratik Linux servis yapılandırmalarını adım adım ele alacağız.

İçindekiler

• CoreDNS Nedir?
• Özel DNS Resolver Neden Kullanılır?
• Split-Horizon DNS Nedir?
• Kurulum Öncesi Planlama
• Linux Sunucuda CoreDNS Kurulumu
• Corefile Yapılandırması
• Split-Horizon Örnek Senaryo
• Güvenlik ve Erişim Kuralları
• Performans, Önbellek ve İzleme
• Sorun Giderme
• Sıkça Sorulan Sorular
• Sonuç

CoreDNS Nedir?

CoreDNS, eklenti tabanlı çalışan, yapılandırması sade ve farklı DNS ihtiyaçlarına kolayca uyarlanabilen bir DNS sunucusudur. Geleneksel DNS servislerinden farklı olarak CoreDNS, Corefile adlı tek bir yapılandırma dosyası üzerinden yönetilir. Bu dosyada hangi alan adlarının çözümleneceği, hangi sorguların başka DNS sunucularına yönlendirileceği, hangi sonuçların önbelleğe alınacağı ve loglama davranışının nasıl olacağı belirlenir.

CoreDNS; şirket içi ağlarda, geliştirme ortamlarında, mikroservis mimarilerinde, Kubernetes kümelerinde, özel veri merkezi ağlarında ve VPS/VDS altyapılarında sıkça tercih edilir. Bir web uygulamasının veritabanı, cache, API ve yönetim servisleri farklı iç IP adreslerinde bulunuyorsa, bu kaynakları sabit IP ezberlemek yerine anlamlı DNS adlarıyla yönetmek operasyonel açıdan büyük kolaylık sağlar.

Örneğin db.internal.example sorgusunun yalnızca iç ağdan erişilebilen özel bir IP adresine dönmesi, dış dünyadan gelen sorgularda ise farklı bir yanıt üretilmesi CoreDNS ile pratik şekilde kurgulanabilir. Bu yaklaşım, özellikle split-horizon DNS veya diğer adıyla bölünmüş DNS mimarilerinde güçlü bir çözüm sunar.

CoreDNS’in Öne Çıkan Özellikleri

• Modüler yapı: Forward, cache, file, hosts, log, errors, prometheus ve rewrite gibi eklentilerle ihtiyaca göre genişletilebilir.
• Basit yapılandırma: Tek bir Corefile dosyası üzerinden okunabilir ve taşınabilir yapılandırma sağlar.
• Hafif kaynak kullanımı: Küçük ve orta ölçekli DNS resolver ihtiyaçlarında düşük CPU ve bellek tüketimiyle çalışabilir.
• İç ağ uyumluluğu: Özel alan adları, dahili servis isimleri ve geliştirme ortamları için kolay yönetim sunar.
• Gözlemlenebilirlik: Loglama ve metrik eklentileri sayesinde DNS sorgularını analiz etmeyi kolaylaştırır.

Özel DNS Resolver Neden Kullanılır?

Özel DNS resolver, istemcilerden gelen DNS sorgularını kurumun veya projenin belirlediği politikalara göre çözen DNS hizmetidir. Genel DNS sağlayıcıları internet üzerindeki alan adlarını çözmek için yeterli olsa da, özel sunucu mimarilerinde her zaman yeterli kontrolü sağlamaz. Özellikle iç ağ servisleri, test ortamları, kapalı API uçları ve yönetim panelleri için kendi resolver yapınızı kurmak daha doğru olabilir.

Birden fazla Sanal Sunucu veya Kiralık Sunucu üzerinde çalışan uygulamalarda DNS, yalnızca alan adı çözümleme aracı değil, aynı zamanda altyapı yönetiminin temel bileşenlerinden biridir. Doğru tasarlanmış bir DNS resolver yapısı, IP değişikliklerinde uygulama yapılandırmalarını tek tek güncelleme ihtiyacını azaltır.

Kullanım Senaryoları

• İç servis adlandırması: mysql.service.local, redis.service.local veya api.internal gibi okunabilir servis adları oluşturabilirsiniz.
• Geliştirme ve test ortamı: Canlı ortamı etkilemeden staging, test ve demo alan adlarını özel IP adreslerine yönlendirebilirsiniz.
• Merkezi DNS politikası: Tüm sunucuların aynı DNS zincirini kullanmasını sağlayarak yönetimi standartlaştırabilirsiniz.
• Önbellekleme: Sık sorgulanan kayıtları cache ederek çözümleme süresini azaltabilirsiniz.
• Güvenlik kontrolü: İç ağ DNS sorgularını sınırlayabilir, yetkisiz istemcilerin resolver kullanmasını engelleyebilirsiniz.

Split-Horizon DNS Nedir?

Split-horizon DNS, aynı alan adı için sorgunun geldiği kaynağa göre farklı DNS yanıtları üretme yaklaşımıdır. Türkçede bölünmüş DNS veya ayrıştırılmış DNS olarak ifade edilebilir. Örneğin panel.example.com alan adı şirket içinden sorgulandığında 10.10.10.20 gibi özel bir IP adresine, internetten sorgulandığında ise genel IP adresine dönebilir.

Bu mimari özellikle yönetim panelleri, dahili API servisleri, staging ortamları, veritabanı uçları ve özel ağ servisleri için kullanışlıdır. Kullanıcılar dış dünyadan yalnızca yayınlanması gereken servislere erişirken, sunucular ve yönetim ekipleri iç ağ üzerinden düşük gecikmeli, güvenli ve doğrudan bağlantı kurabilir.

Split-Horizon DNS Ne Zaman Mantıklıdır?

• İç ve dış IP ayrımı varsa: Aynı servis hem özel ağdan hem internetten farklı IP adresleriyle erişiliyorsa kullanılabilir.
• Yönetim arayüzleri korunacaksa: Admin panel, izleme paneli veya veritabanı arayüzü yalnızca iç ağdan çözülmelidir.
• Çok lokasyonlu mimari varsa: Türkiye, Almanya veya Fransa lokasyonlarında farklı özel ağ yönlendirmeleri gerekebilir.
• Geliştirme ortamları ayrılacaksa: Test ve canlı ortamların DNS düzeyinde ayrılması isteniyorsa tercih edilebilir.

Örneğin Türkiye lokasyonunda barındırılan uygulama için Türkiye VDS Sunucu, Avrupa kullanıcılarına yakın bir yapı için Almanya VDS Sunucu veya Fransa VDS Sunucu tercih edildiğinde, iç DNS kuralları lokasyona göre farklılaştırılabilir.

Kurulum Öncesi Planlama

CoreDNS kurulumundan önce DNS mimarisinin planlanması gerekir. DNS hataları genellikle uygulama seviyesinde bağlantı problemi gibi görünür; ancak kök neden yanlış kayıt, hatalı TTL, erişim kısıtı veya resolver zinciri olabilir. Bu nedenle kurulum öncesinde hangi alan adlarının dahili çözüleceği, hangi sorguların dış DNS sağlayıcılarına aktarılacağı ve hangi istemcilerin bu resolver hizmetini kullanacağı netleştirilmelidir.

Planlama Kontrol Listesi

• Alan adı yapısı: Dahili kullanım için internal.example, corp.local veya gerçek alan adınız altında internal.example.com gibi bir yapı belirleyin.
• IP adres planı: DNS kayıtlarında kullanılacak özel IP adreslerini, alt ağları ve lokasyonları belgeleyin.
• TTL politikası: Sık değişen kayıtlar için düşük, sabit altyapı kayıtları için daha yüksek TTL değeri kullanın.
• Erişim kapsamı: Resolver hizmetini yalnızca güvenilir sunuculara, VPN ağına veya özel ağ bloklarına açın.
• Yedekleme: Corefile ve zone dosyalarını düzenli olarak yedekleyin. Bu noktada Yedekleme Hizmeti kullanmak operasyonel riskleri azaltır.

Örnek Mimari

Linux Sunucuda CoreDNS Kurulumu

CoreDNS, Linux sunucularda ikili dosya olarak çalıştırılabilir. Üretim ortamında ise servis yönetimi için systemd kullanmak daha sağlıklı bir yaklaşımdır. Aşağıdaki örneklerde CoreDNS ikili dosyasının /usr/local/bin/coredns konumunda, yapılandırma dosyasının ise /etc/coredns/Corefile altında tutulduğu varsayılmıştır.

Kurulumdan önce sunucunuzun güncel, güvenli ve sabit IP adresine sahip olması önemlidir. Eğer DNS hizmeti yoğun sorgu alacaksa, kaynakları izlenebilir ve ölçeklenebilir bir Bulut Sunucu ya da özel kaynaklı sunucu altyapısı tercih edilebilir.

Kullanıcı ve Dizin Oluşturma

sudo useradd --system --home /var/lib/coredns --shell /usr/sbin/nologin coredns
sudo mkdir -p /etc/coredns/zones
sudo mkdir -p /var/lib/coredns
sudo chown -R coredns:coredns /var/lib/coredns

CoreDNS İkili Dosyasını Yerleştirme

CoreDNS ikili dosyasını resmi dağıtım paketinden veya güvenilir paket yöneticinizden temin ettikten sonra çalıştırılabilir hale getirin. Dosyanın bütünlüğünü doğrulamak ve sürüm bilgisini kontrol etmek iyi bir güvenlik alışkanlığıdır.

sudo install -o root -g root -m 0755 coredns /usr/local/bin/coredns
/usr/local/bin/coredns -version

Systemd Servis Dosyası

CoreDNS’i arka planda güvenilir şekilde çalıştırmak için bir systemd unit dosyası oluşturabilirsiniz.

sudo nano /etc/systemd/system/coredns.service

[Unit]
Description=CoreDNS DNS Server
Documentation=https://coredns.io
After=network-online.target
Wants=network-online.target

[Service]
User=coredns
Group=coredns
ExecStart=/usr/local/bin/coredns -conf /etc/coredns/Corefile
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Bu servis dosyasında CAP_NET_BIND_SERVICE yetkisi, CoreDNS’in 53 numaralı port gibi düşük portlarda root kullanıcı olmadan çalışmasına yardımcı olur. Böylece servis güvenlik açısından daha sınırlı yetkilerle yönetilebilir.

Corefile Yapılandırması

Corefile, CoreDNS’in davranışını belirleyen ana yapılandırma dosyasıdır. Bu dosyada DNS bölgeleri, forward kuralları, loglama, hata çıktıları, cache süresi ve zone dosyalarının konumu tanımlanır. En basit yapılandırmada CoreDNS, gelen tüm DNS sorgularını üst DNS resolver sunucularına iletir.

Basit Forward Resolver Yapılandırması

sudo nano /etc/coredns/Corefile

.:53 {
    errors
    log
    cache 300
    forward . 1.1.1.1 8.8.8.8
}

Bu örnekte .:53 ifadesi, tüm DNS sorgularının 53 numaralı porttan dinleneceğini belirtir. cache 300, sorgu sonuçlarının 300 saniye önbellekte tutulmasını sağlar. forward satırı ise çözülemeyen sorguların üst DNS sunucularına aktarılacağını gösterir.

Dahili Zone Dosyası Kullanımı

Dahili servis adlarını yönetmek için bir zone dosyası oluşturabilirsiniz. Bu yöntem, belirli bir alan adı altında statik kayıtlar tutmak için idealdir.

sudo nano /etc/coredns/zones/internal.example.com.db

$ORIGIN internal.example.com.
$TTL 300
@       IN SOA  ns1.internal.example.com. admin.internal.example.com. (
        2026072201 ; serial
        3600       ; refresh
        600        ; retry
        86400      ; expire
        300 )      ; minimum

        IN NS   ns1.internal.example.com.
ns1     IN A    10.10.10.10
app     IN A    10.10.10.21
api     IN A    10.10.10.22
db      IN A    10.10.10.31
cache   IN A    10.10.10.41

Corefile İçinde Zone Tanımlama

internal.example.com:53 {
    errors
    log
    file /etc/coredns/zones/internal.example.com.db
    cache 300
}

.:53 {
    errors
    cache 300
    forward . 1.1.1.1 8.8.8.8
}

Bu yapılandırmada internal.example.com alanına ait sorgular lokal zone dosyasından cevaplanır. Diğer tüm sorgular ise üst DNS resolver adreslerine yönlendirilir. Böylece hem dahili kayıtlarınızı yönetebilir hem de sunucuların internet alan adlarını çözmesini sağlayabilirsiniz.

Servisi Başlatma

sudo systemctl daemon-reload
sudo systemctl enable --now coredns
sudo systemctl status coredns

Test Sorguları

dig @127.0.0.1 app.internal.example.com
 dig @127.0.0.1 db.internal.example.com
 dig @127.0.0.1 corelux.com.tr

Test sonucunda dahili kayıtların özel IP adreslerine çözülmesi, internet alan adlarının ise forwarder üzerinden yanıtlanması beklenir. Eğer yanıt alamıyorsanız journalctl çıktısı ve CoreDNS logları incelenmelidir.

Split-Horizon Örnek Senaryo

Split-horizon DNS mimarisinde temel amaç, istemcinin konumuna göre farklı DNS yanıtı üretmektir. CoreDNS tek başına gelişmiş erişim listesi motoru gibi davranmasa da, farklı ağ arayüzlerinde farklı CoreDNS örnekleri çalıştırarak veya firewall yönlendirmeleriyle pratik bir ayrım yapılabilir.

Örnek senaryoda iç ağ istemcileri panel.example.com sorgusunda 10.10.10.50 adresini alırken, dış DNS sağlayıcınız aynı alan adını genel IP adresine yönlendirebilir. İç resolver yalnızca özel ağdan erişilebilir olacağı için dış kullanıcılar bu özel kayıtları göremez.

İç Ağ İçin Hosts Eklentisi

Küçük yapılarda zone dosyası yerine hosts eklentisiyle hızlı kayıt yönetimi yapılabilir. Bu yöntem basittir ancak büyük yapılarda zone dosyası kadar ölçeklenebilir değildir.

internal.example.com:53 {
    errors
    log
    hosts {
        10.10.10.50 panel.internal.example.com
        10.10.10.21 app.internal.example.com
        10.10.10.31 db.internal.example.com
        fallthrough
    }
    cache 60
}

.:53 {
    errors
    cache 300
    forward . 1.1.1.1 8.8.8.8
}

İstemci DNS Ayarı

Linux istemcilerde DNS resolver adresi geçici olarak test edilebilir. Kalıcı yapılandırma dağıtıma göre değişebilir; bu nedenle ağ yöneticisi, Netplan, NetworkManager veya DHCP üzerinden merkezi atama tercih edilmelidir.

resolvectl dns eth0 10.10.10.10
resolvectl domain eth0 internal.example.com
resolvectl status

DHCP kullanıyorsanız, istemcilere DNS sunucusu olarak CoreDNS IP adresini dağıtabilirsiniz. Sunucu ağlarında ise uygulama sunucularının /etc/resolv.conf veya sistem resolver yapılandırmasıyla özel DNS hizmetine yönlenmesi sağlanır.

Uygulama Sunucusu Senaryosu

Bir Laravel, Node.js veya WordPress uygulamasının veritabanı bağlantı adresi IP yerine DNS adıyla tanımlandığında bakım kolaylaşır. Örneğin veritabanı sunucusunu taşıdığınızda uygulama yapılandırmasını değiştirmek yerine yalnızca db.internal.example.com kaydını güncellemeniz yeterli olur.

DB_HOST=db.internal.example.com
REDIS_HOST=cache.internal.example.com
API_BASE_URL=https://api.internal.example.com

Bu yaklaşım, Linux Hosting üzerinde basit projelerden, özel kaynaklı VDS mimarilerindeki karmaşık uygulamalara kadar geniş ölçekte uygulanabilir.

Güvenlik ve Erişim Kuralları

DNS resolver hizmetleri yanlış yapılandırıldığında açık resolver haline gelebilir. Açık resolver, internetteki herkesin DNS sorgusu gönderebildiği ve kötüye kullanılabilen DNS servisidir. Bu durum DNS amplification (DNS yükseltme) saldırılarında altyapınızın aracı olarak kullanılmasına neden olabilir. Bu nedenle CoreDNS hizmetini yalnızca yetkili ağlara açmak kritik öneme sahiptir.

Firewall ile Erişim Kısıtlama

DNS için UDP 53 ve TCP 53 portları dikkate alınmalıdır. UDP sorgular yaygın olsa da büyük yanıtlar, zone transfer denemeleri veya bazı özel durumlarda TCP kullanılabilir.

sudo ufw allow from 10.10.10.0/24 to any port 53 proto udp
sudo ufw allow from 10.10.10.0/24 to any port 53 proto tcp
sudo ufw deny 53
sudo ufw status verbose

Eğer nftables veya farklı bir firewall yönetimi kullanıyorsanız aynı mantıkla yalnızca güvenilir IP bloklarına izin vermelisiniz. Resolver hizmetini doğrudan internete açmak yerine VPN, özel ağ veya güvenilir sunucu aralığı üzerinden erişim vermek daha güvenlidir.

Güvenlik İçin En İyi Uygulamalar

• Açık resolver oluşturmayın: DNS hizmetini yalnızca belirlediğiniz IP bloklarına açın.
• Root ile çalıştırmayın: CoreDNS’i sınırlı yetkili coredns kullanıcısıyla çalıştırın.
• Zone dosyalarını koruyun: /etc/coredns altındaki dosyalara yazma erişimini sınırlandırın.
• Logları izleyin: Ani sorgu artışları, NXDOMAIN yoğunluğu ve yetkisiz kaynak IP adresleri takip edilmelidir.
• Yedek alın: DNS kayıtları altyapı çalışabilirliği için kritik olduğundan düzenli yedekleme yapılmalıdır.
• SSL/TLS planını ayırın: DNS çözümleme ile HTTPS güvenliği farklı katmanlardır. Web servisleri için SSL Sertifikası yönetimi ayrıca planlanmalıdır.

Zone Transfer Konusu

Geleneksel DNS mimarilerinde zone transfer, bir DNS bölgesinin başka bir DNS sunucusuna aktarılması anlamına gelir. Dahili kayıtlar hassas bilgiler içerebileceği için kontrolsüz zone transfer risklidir. CoreDNS yapılandırmanızda zone transfer ihtiyacınız yoksa bu davranışı etkinleştirmemek ve TCP 53 erişimini de yalnızca gerekli kaynaklarla sınırlamak güvenli bir yaklaşımdır.

Performans, Önbellek ve İzleme

DNS performansı, web sayfası yüklenme süresinden mikroservisler arası bağlantı hızına kadar birçok alanı etkiler. Sorgu çözümleme süresinin artması, uygulamaların veritabanı veya API servislerine geç bağlanmasına neden olabilir. Bu nedenle CoreDNS yapılandırmasında cache, log seviyesi, metrik toplama ve sistem kaynak limitleri doğru ayarlanmalıdır.

Cache Süresi Nasıl Belirlenir?

Cache süresi, DNS yanıtlarının ne kadar süre önbellekte tutulacağını belirler. Çok düşük cache değeri üst resolver trafiğini artırabilir; çok yüksek cache değeri ise IP değişikliklerinin istemcilere geç yansımasına neden olabilir.

Prometheus Metrikleri

CoreDNS, metrik eklentisiyle DNS sorgu sayısı, hata oranı ve yanıt süreleri gibi verileri izlemeye yardımcı olabilir. İzleme sistemi kullanıyorsanız CoreDNS metriklerini merkezi gözlem platformunuza dahil edebilirsiniz.

.:53 {
    errors
    cache 300
    prometheus 0.0.0.0:9153
    forward . 1.1.1.1 8.8.8.8
}

Metrik portunu doğrudan internete açmamalısınız. Bu porta yalnızca izleme sunucunuzun erişmesine izin verin. CoreDNS’in DNS portu kadar metrik portu da güvenlik politikasına dahil edilmelidir.

Log Seviyesi

log eklentisi test aşamasında çok faydalıdır; ancak yüksek trafikli üretim ortamlarında tüm DNS sorgularını loglamak disk kullanımını artırabilir. Üretim ortamında yalnızca hata loglarını veya sınırlı örneklemeyi tercih etmek daha verimli olabilir.

journalctl -u coredns -f

Log dosyalarının büyümesini kontrol altında tutmak için sistem log rotasyonu, disk kotası ve merkezi log toplama stratejisi uygulanmalıdır.

Sorun Giderme

CoreDNS sorunları genellikle üç ana başlıkta incelenir: servis çalışmıyor, sorgu geliyor ancak yanıt dönmüyor veya yanlış kayıt dönüyor. Sorun giderme sürecinde sistematik ilerlemek zaman kazandırır.

Servis Durumunu Kontrol Etme

sudo systemctl status coredns
sudo journalctl -u coredns --no-pager -n 100

Servis başlamıyorsa Corefile içinde yazım hatası, port çakışması veya yetki problemi olabilir. 53 numaralı portu başka bir DNS servisi kullanıyorsa CoreDNS aynı portu dinleyemez.

sudo ss -tulpn | grep ':53'

Yapılandırma Dosyasını Test Etme

CoreDNS’i doğrudan komut satırından çalıştırarak yapılandırma hatalarını daha net görebilirsiniz.

sudo -u coredns /usr/local/bin/coredns -conf /etc/coredns/Corefile

Eğer dosya yolu, zone formatı veya eklenti sıralaması hatalıysa çıktı üzerinde ilgili satır görülebilir. Zone dosyalarında seri numarasını düzenli artırmak, değişiklik takibini kolaylaştırır.

DNS Sorgu Testleri

dig @10.10.10.10 app.internal.example.com A
 dig @10.10.10.10 db.internal.example.com A
 dig @10.10.10.10 unknown.internal.example.com A
 dig @10.10.10.10 example.com A

İlk iki sorgu özel kayıtları, üçüncü sorgu hatalı veya tanımsız kayıt davranışını, dördüncü sorgu ise dış forwarder işleyişini test eder. Sorgu hiç dönmüyorsa firewall, route veya servis dinleme adresi kontrol edilmelidir.

Yaygın Hatalar ve Çözümleri

Sıkça Sorulan Sorular

Sonuç

CoreDNS ile özel DNS resolver kurulumu, sunucu altyapılarında servis adlandırmasını kolaylaştıran, iç ağ güvenliğini güçlendiren ve operasyonel esneklik sağlayan etkili bir yöntemdir. Split-horizon DNS yaklaşımı sayesinde aynı alan adı için iç ve dış kullanıcılara farklı yanıtlar üretilebilir; böylece yönetim panelleri, veritabanı servisleri, API uçları ve geliştirme ortamları daha kontrollü hale gelir.

Başarılı bir CoreDNS mimarisi için yalnızca kurulum yapmak yeterli değildir. Alan adı planı, TTL politikası, firewall kısıtları, log yönetimi, metrik izleme ve yedekleme süreçleri birlikte düşünülmelidir. Özellikle açık resolver oluşturmamak, CoreDNS’i sınırlı yetkili kullanıcıyla çalıştırmak ve zone dosyalarını düzenli yedeklemek üretim ortamları için kritik güvenlik adımlarıdır.

Corelux altyapısında projenizin ihtiyacına göre Sanal Sunucu, Kiralık Sunucu, Bulut Sunucu ve Yedekleme Hizmeti seçenekleriyle DNS, uygulama ve veritabanı katmanlarınızı daha güvenli ve yönetilebilir şekilde konumlandırabilirsiniz.