systemd-resolved ile DNS Yönetimi: Kapsamlı Rehber

yazar

Modern Linux sistemlerinde DNS yönetimi artık eskisi kadar basit değil. Eskiden /etc/resolv.conf dosyasına birkaç satır yazıp geçerdin, iş biterdi. Ama günümüzde VPN bağlantıları, farklı ağ arayüzleri, split-DNS gereksinimleri ve cache yönetimi gibi ihtiyaçlar işleri karmaşıklaştırdı. İşte tam bu noktada systemd-resolved devreye giriyor. Ubuntu 18.04’ten itibaren varsayılan olarak gelen, Fedora ve Arch’ta da yaygın kullanılan bu servis, başlangıçta “neden resolv.conf yetmiyor ki?” dedirtiyor ama bir kez anladıktan sonra neden vazgeçilemez olduğunu anlıyorsunuz.

systemd-resolved Nedir ve Neden Önemlidir?

systemd-resolved, systemd ekosisteminin bir parçası olan bir sistem DNS çözümleyicisidir. Basit bir DNS forwarder olmanın ötesinde; DNSSEC doğrulaması, DNS-over-TLS (DoT) desteği, çoklu DNS sunucu yönetimi ve per-interface DNS konfigürasyonu gibi özellikleri bünyesinde barındırır.

Geleneksel yaklaşımda /etc/resolv.conf dosyası tüm sistem için tek bir DNS konfigürasyonu içerirdi. Bu yaklaşımın sorunları:

  • VPN bağlandığında DNS ayarları çakışıyordu
  • Farklı ağ arayüzleri için farklı DNS sunucusu kullanılamıyordu
  • DNS cache yoktu, her sorgu yeniden gidiyordu
  • DNSSEC desteği manuel olarak yapılandırılması gerekiyordu

systemd-resolved tüm bu sorunlara çözüm getiriyor. Ayrıca resolvectl aracı sayesinde DNS durumunu gerçek zamanlı izlemek ve yönetmek çok kolaylaşıyor.

Kurulum ve Servis Durumu Kontrolü

Çoğu modern dağıtımda systemd-resolved zaten kurulu ve çalışıyor olmalı. Durumu kontrol etmek için:

systemctl status systemd-resolved

Eğer kurulu değilse veya çalışmıyorsa:

# Debian/Ubuntu için
sudo apt install systemd-resolved

# Fedora/RHEL için
sudo dnf install systemd-resolved

# Servisi etkinleştir ve başlat
sudo systemctl enable --now systemd-resolved

Servisin gerçekten çalışıp çalışmadığını doğrulamak için basit bir test:

resolvectl status

Bu komut çıktısında hangi DNS sunucularının kullanıldığını, hangi domain’lerin hangi arayüzlerle eşleştiğini ve DNSSEC durumunu göreceksiniz.

/etc/resolv.conf ve systemd-resolved İlişkisi

Bu konu sysadmin’lerin en çok kafasının karıştığı nokta. systemd-resolved çalışırken /etc/resolv.conf dosyasıyla ilişkisi ne olacak?

systemd-resolved çalıştığında 127.0.0.53 adresinde bir stub resolver dinler. Uygulamaların bu stub resolver’ı kullanabilmesi için /etc/resolv.conf dosyasının doğru yapılandırılması gerekir.

Üç farklı mod var:

Stub Mode (Önerilen): /etc/resolv.conf, /run/systemd/resolve/stub-resolv.conf dosyasına sembolik link olur. Bu mod tüm DNS sorgularını systemd-resolved üzerinden yönlendirir.

Full Resolver Mode: /etc/resolv.conf, /run/systemd/resolve/resolv.conf dosyasına sembolik link olur. Bu dosya gerçek upstream DNS sunucularını içerir.

Manuel Mode: /etc/resolv.conf doğrudan düzenlenir, systemd-resolved bypass edilir.

Stub mode’u aktif etmek için:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Mevcut durumu kontrol etmek için:

ls -la /etc/resolv.conf
cat /etc/resolv.conf

Stub mode’da /etc/resolv.conf içeriği şuna benzer:

nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

Ana Konfigürasyon Dosyası

systemd-resolved‘un ana konfigürasyon dosyası /etc/systemd/resolved.conf‘tur. Bu dosya üzerinden global DNS ayarlarını yapabilirsiniz.

sudo cat /etc/systemd/resolved.conf

Varsayılan dosya genellikle büyük ölçüde yorum satırlarından oluşur. Pratik bir konfigürasyon örneği:

[Resolve]
# Birincil ve yedek DNS sunucuları
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

# DNS-over-TLS aktif et
DNSOverTLS=yes

# DNSSEC doğrulaması
DNSSEC=yes

# DNS cache boyutu (0 = devre dışı, negatif = sınırsız)
Cache=yes
CacheSize=2048

# mDNS (multicast DNS) ayarı
MulticastDNS=yes

# LLMNR (Link-Local Multicast Name Resolution)
LLMNR=yes

Değişiklikleri uygulamak için servisi yeniden başlatın:

sudo systemctl restart systemd-resolved

resolvectl ile Günlük Yönetim

resolvectl komutu, systemd-resolved‘ü yönetmek için birincil araçtır. Eski sistemlerde systemd-resolve olarak da geçebilir.

Mevcut DNS Durumunu Görüntüleme

# Tüm arayüzler için DNS durumu
resolvectl status

# Sadece belirli bir arayüz için
resolvectl status eth0

# Kısa özet
resolvectl dns

DNS Sorguları Yapmak

resolvectl ile doğrudan DNS sorgusu yapabilir ve sonuçları ayrıntılı şekilde inceleyebilirsiniz:

# Basit A kaydı sorgusu
resolvectl query google.com

# Belirli kayıt tipi sorgulama
resolvectl query -t MX gmail.com
resolvectl query -t AAAA cloudflare.com
resolvectl query -t TXT _dmarc.google.com

# Belirli bir arayüz üzerinden sorgulama
resolvectl query --interface=eth0 internal.company.com

DNS Cache Yönetimi

# DNS cache istatistiklerini görüntüle
resolvectl statistics

# Cache'i temizle (troubleshooting sırasında çok işe yarıyor)
sudo resolvectl flush-caches

# Cache istatistiklerini sıfırla
sudo resolvectl reset-statistics

Per-Interface DNS Konfigürasyonu: Gerçek Güç Buradan Geliyor

systemd-resolved‘ün en güçlü özelliği, farklı ağ arayüzleri için farklı DNS konfigürasyonu yapabilmektir. Bu özellik özellikle şu senaryolarda kritik:

  • Kurumsal VPN bağlantısı aktifken internal DNS sunucusu kullanmak
  • Test ortamı için farklı DNS kullanmak
  • Split-DNS yapısı kurmak

NetworkManager üzerinden per-interface DNS ayarlamak için:

# Belirli bir bağlantı için DNS sunucusu ayarla
nmcli con modify "Ethernet connection 1" ipv4.dns "192.168.1.1 192.168.1.2"

# DNS search domain ekle
nmcli con modify "Ethernet connection 1" ipv4.dns-search "company.local"

# Değişiklikleri uygula
nmcli con up "Ethernet connection 1"

Eğer systemd-networkd kullanıyorsanız, /etc/systemd/network/ altındaki .network dosyalarını düzenlemeniz gerekir:

# /etc/systemd/network/20-ethernet.network
[Match]
Name=eth0

[Network]
DHCP=yes
DNS=192.168.1.100
Domains=~company.local ~internal.corp

Buradaki ~ işareti önemli! ~company.local yazdığınızda bu alan adı için sorguların sadece bu arayüzün DNS sunucusuna gideceğini söylüyorsunuz. Bu split-DNS için temel mekanizma.

Gerçek Dünya Senaryosu: VPN ile Split-DNS

En sık karşılaşılan senaryo şu: Çalıştığınız şirketin VPN’ine bağlandığınızda internal.company.com gibi internal adresleri çözümleyebilmeniz, aynı zamanda google.com gibi external adreslerin de normal şekilde çalışması gerekiyor.

VPN bağlantısı için systemd-networkd konfigürasyonu:

# /etc/systemd/network/10-vpn.network
[Match]
Name=tun0

[Network]
DNS=10.10.10.1
Domains=~company.com ~internal.corp ~dev.local

Bu konfigürasyonla company.com altındaki tüm sorgular 10.10.10.1‘e giderken, diğer sorgular global DNS sunucularına gidecek.

Konfigürasyonu doğrulamak için:

resolvectl domain tun0
resolvectl dns tun0

DNS-over-TLS Konfigürasyonu

DNS trafiğinizi şifrelemek istiyorsanız DNS-over-TLS (DoT) harika bir seçenek. systemd-resolved bu özelliği natively destekliyor.

Global DoT aktivasyonu için /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes

Burada # işaretinden sonra gelen kısım, TLS sertifika doğrulaması için kullanılan hostname. Bu olmazsa TLS bağlantısı kurulur ama sertifika doğrulanmaz.

DNSOverTLS için üç değer var:

  • no: DoT kullanma
  • opportunistic: Mümkünse DoT kullan, olmazsa düz UDP/TCP’ye düş
  • yes: Sadece DoT kullan, olmadığında hata ver

Test ortamında opportunistic, production ortamında yes kullanmanızı öneririm.

Bağlantıyı test etmek için:

resolvectl query --interface=eth0 --type=A cloudflare.com
resolvectl statistics | grep -i tls

DNSSEC Konfigürasyonu ve Sorunları

DNSSEC, DNS yanıtlarının bütünlüğünü kriptografik olarak doğrular. systemd-resolved DNSSEC’i destekliyor ancak dikkatli olmak gerekiyor çünkü bazı ağlarda sorunlara yol açabiliyor.

[Resolve]
# allow-downgrade: Mümkünse DNSSEC, yoksa devam et
# yes: Sadece DNSSEC doğrulanmış yanıtları kabul et
# no: DNSSEC kullanma
DNSSEC=allow-downgrade

DNSSEC durumunu test etmek için:

# DNSSEC doğrulama testi
resolvectl query sigfail.verteiltesysteme.net

# Bu sorgu başarısız olmalı - başarısız olursa DNSSEC çalışıyor demektir
resolvectl query www.dnssec-failed.org

Eğer systemd-resolved kullanan bir sunucuda bazı DNS sorgularının çalışmadığını fark ederseniz ve DNSSEC aktifse, ilk yapmanız gereken şey DNSSEC’i geçici olarak no yapıp sorunu tekrar test etmek:

sudo resolvectl dnssec eth0 no

Troubleshooting: Sık Karşılaşılan Sorunlar

DNS Çözümlemesi Çalışmıyor

# Önce servis durumunu kontrol et
systemctl status systemd-resolved

# Journal'da hataları gör
journalctl -u systemd-resolved -n 50 --no-pager

# resolv.conf doğru mu işaret ediyor?
ls -la /etc/resolv.conf
cat /etc/resolv.conf

# 127.0.0.53 portu dinleniyor mu?
ss -tlnp | grep 53

Cache Sorunları

Bazen eski DNS kayıtları cache’de takılı kalır. Özellikle bir sunucunun IP adresi değiştiğinde bu sorun yaşanır:

# Cache temizle
sudo resolvectl flush-caches

# Cache istatistiklerini kontrol et
resolvectl statistics

NXDOMAIN Hataları

Bir domain’in çözümlenmediğini düşünüyorsunuz ama aslında çözümleniyor olabilir, sadece yanlış arayüzden sorgulanıyor olabilir:

# Tüm arayüzlerden dene
resolvectl query --interface=eth0 internal.company.com
resolvectl query --interface=tun0 internal.company.com

# Hangi arayüzün hangi domain'i handle ettiğini gör
resolvectl domain

systemd-resolved ve dnsmasq Çakışması

Bazı sistemlerde dnsmasq da port 53’ü kullanmaya çalışır ve çakışma olur:

# Port 53'ü kim kullanıyor?
sudo ss -tlnp | grep ':53'
sudo lsof -i :53

# dnsmasq varsa devre dışı bırak
sudo systemctl disable --now dnsmasq

Monitoring ve Log Analizi

Production ortamında DNS servisini izlemek için birkaç pratik komut:

# Gerçek zamanlı DNS sorgu logları (verbose mode)
sudo resolvectl log-level debug
journalctl -u systemd-resolved -f

# Bittikten sonra log seviyesini normale döndür
sudo resolvectl log-level info

# İstatistik özeti
resolvectl statistics

Düzenli monitoring için bir bash script örneği:

#!/bin/bash
# dns-health-check.sh

echo "=== DNS Health Check ==="
echo "Tarih: $(date)"
echo ""

echo "--- Servis Durumu ---"
systemctl is-active systemd-resolved

echo ""
echo "--- DNS Sunucuları ---"
resolvectl dns

echo ""
echo "--- Cache İstatistikleri ---"
resolvectl statistics | grep -E "Current|Total|Cache"

echo ""
echo "--- Test Sorguları ---"
domains=("google.com" "cloudflare.com" "github.com")
for domain in "${domains[@]}"; do
    result=$(resolvectl query "$domain" 2>&1 | grep -E "Address|NXDOMAIN|error")
    echo "$domain: $result"
done

Bu scripti cron’a ekleyebilir veya monitoring sisteminizle entegre edebilirsiniz.

NetworkManager Entegrasyonu

Ubuntu ve Fedora gibi dağıtımlarda NetworkManager ile systemd-resolved entegrasyonu dikkat gerektiriyor. NetworkManager’ın systemd-resolved‘ü kullanmasını sağlamak için:

# NetworkManager konfigürasyonunu kontrol et
cat /etc/NetworkManager/NetworkManager.conf

# dns=systemd-resolved satırı olmalı, yoksa ekle
sudo tee /etc/NetworkManager/conf.d/dns.conf << EOF
[main]
dns=systemd-resolved
EOF

# NetworkManager'ı yeniden başlat
sudo systemctl restart NetworkManager
sudo systemctl restart systemd-resolved

Bu entegrasyon sayesinde NetworkManager bir ağa bağlandığında DNS bilgilerini otomatik olarak systemd-resolved‘e iletir.

Güvenlik Önerileri

Production sistemlerde systemd-resolved kullanırken dikkat edilmesi gereken güvenlik noktaları:

  • DNSSEC aktif tutun: DNSSEC=allow-downgrade minimum seviye olmalı
  • DNS-over-TLS kullanın: Özellikle public ağlarda çok önemli
  • Trusted DNS sunucuları seçin: ISP DNS’i yerine güvenilir sağlayıcılar tercih edin
  • mDNS ve LLMNR’ı değerlendirin: Güvenli ağlarda kullanışlı, public ağlarda risk oluşturabilir
  • Log analizi yapın: Anormal DNS sorguları güvenlik ihlalinin habercisi olabilir

mDNS’i belirli bir arayüzde devre dışı bırakmak için:

resolvectl mdns eth0 no

Kalıcı yapılandırma için /etc/systemd/network/ altındaki ilgili .network dosyasına ekleyin:

[Network]
MulticastDNS=no
LLMNR=no

Sonuç

systemd-resolved ilk başta “neden bu kadar karmaşık?” dedirtiyor ama bir kez kavradıktan sonra neden bu kadar yaygınlaştığını anlıyorsunuz. Split-DNS desteği, DNS cache, DNSSEC, DNS-over-TLS gibi özelliklerin tek bir serviste bu kadar iyi entegre edilmesi gerçekten takdire değer.

Günlük sysadmin işlerinde en çok kullanacağınız komutlar resolvectl status, resolvectl query ve resolvectl flush-caches olacak. Troubleshooting sırasında journal loglarını ve resolvectl statistics çıktısını incelemek sorunların büyük çoğunluğunu çözmenizi sağlayacak.

Özellikle VPN kullanan geliştiricilerin makinelerini yönetiyorsanız veya split-DNS gerektiren kurumsal ortamlarda çalışıyorsanız, systemd-resolved‘ü derinlemesine öğrenmek için harcadığınız zaman kısa sürede geri dönecek. Eski resolv.conf yaklaşımına dönmek istemeyeceksiniz.

Yorum yapın