resolvectl ile systemd-resolved DNS Sorgularını İzleme, Önbelleği Temizleme ve Sorun Giderme

Yazar:komut.io ekibi Ağ Komutları ve Araçları
0 Yorum

Bir Ubuntu 22.04 sunucusunda “neden bu domain çözümlenmiyor?” sorusunu saatlerce araştırdıktan sonra şunu fark ettim: sorun çoğu zaman DNS’in kendisinde değil, DNS’i nasıl izlediğimizde yatıyor. systemd-resolved modern Linux dağıtımlarının vazgeçilmezi haline geldi, ama çoğu sysadmin hâlâ eski alışkanlıklarla nslookup veya /etc/resolv.conf‘a bakıyor. Oysa resolvectl bu işin gerçek aracı.

systemd-resolved ve resolvectl Ne İşe Yarar?

systemd-resolved, systemd ekosisteminin DNS çözümleme servisidir. Önbellek yönetimi, DNSSEC doğrulama, DNS-over-TLS ve çoklu DNS sunucu desteği gibi özellikleri tek çatı altında toplar. resolvectl ise bu servisin komut satırı arayüzüdür.

Neden önemli? Çünkü modern Ubuntu, Debian, Fedora ve RHEL sistemlerinde /etc/resolv.conf artık doğrudan düzenlenmez. Bu dosya genellikle /run/systemd/resolve/stub-resolv.conf‘a sembolik link olarak işaret eder ve 127.0.0.53 adresini gösterir. Bu IP, systemd-resolved’ın dinlediği stub resolver adresidir.

ls -la /etc/resolv.conf
# lrwxrwxrwx 1 root root 39 ... /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

cat /etc/resolv.conf
# nameserver 127.0.0.53
# options edns0 trust-ad

Bu yapıyı anlamadan DNS sorunlarını çözmeye çalışmak, motorun kaputunu açmadan araba tamir etmeye benziyor.

resolvectl status: Sistemin DNS Durumunu Okumak

Her şeyin başlangıç noktası resolvectl status komutu. Bu komut hem global DNS ayarlarını hem de her ağ arayüzü için özel ayarları gösterir.

resolvectl status

Çıktı şuna benzer bir yapıda gelir:

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
      DNS Servers: 8.8.8.8 8.8.4.4
     DNS Domain: ~.

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
        DNS Domain: office.local

Burada dikkat edilmesi gereken birkaç nokta var:

  • Protocols satırındaki DNSSEC=no/unsupported: Eğer DNSSEC doğrulama yapılmıyorsa ve bunu bekliyor idiysek, burada görürüz.
  • resolv.conf mode: stub: Sistemin stub resolver modunda çalıştığını gösterir. Bu beklenen durum.
  • DNS Domain: office.local: Bu arayüzün hangi domain için varsayılan olduğunu söyler. Search domain mantığıyla çalışır.
  • Current DNS Server: O anda aktif kullanılan sunucu. Birden fazla sunucu tanımlıysa hangisinin kullanıldığını buradan görürüz.

Belirli bir arayüzün durumunu görmek için:

resolvectl status eth0

DNS Sorgularını Gerçek Zamanlı İzlemek

İşte burada resolvectl gerçek gücünü gösteriyor. resolvectl monitor komutu, sistemde gerçekleşen tüm DNS sorgularını canlı olarak izlememizi sağlar.

resolvectl monitor

Bu komutu çalıştırdıktan sonra başka bir terminalde bir şeyler deneyin:

curl https://github.com
ping google.com

Monitor ekranında şunu görürsünüz:

          TIMESTAMP      IN/OUT  PROTOCOL  TYPE     SERVER         NAME                    RCODE
2024-01-15 14:23:11 UTC  OUT     DNS       A        192.168.1.1    github.com              SUCCESS
2024-01-15 14:23:11 UTC  OUT     DNS       AAAA     192.168.1.1    github.com              SUCCESS
2024-01-15 14:23:15 UTC  OUT     DNS       A        192.168.1.1    google.com              SUCCESS

Bu çıktı bir production ortamında inanılmaz değerli. Özellikle şu senaryolarda:

  • Bir uygulama beklenmedik DNS sorguları yapıyor mu?
  • DNS yanıt süreleri neden yavaş?
  • Hangi DNS sunucusu kullanılıyor?

Gerçek hayatta yaşadığım bir örnek: Bir microservice uygulaması rastgele bağlantı hataları veriyordu. resolvectl monitor ile izlediğimde, uygulamanın her 30 saniyede bir aynı servis adını sorguladığını ve zaman zaman NXDOMAIN aldığını gördüm. Sorun uygulamanın kendisinde değil, Kubernetes DNS politikasında bir tutarsızlıktı.

resolvectl query: Manuel DNS Sorguları Yapmak

nslookup veya dig yerine resolvectl query kullanmak, sistemin gerçekte nasıl bir DNS deneyimi yaşadığını görmenizi sağlar. Çünkü bu komut, aynen sistem uygulamalarının kullandığı aynı resolver stack’ini kullanır.

resolvectl query github.com

Çıktı:

github.com: 140.82.121.4
            -- Information acquired via protocol DNS in 45.3ms.
            -- Data is authenticated: no; Data was acquired via local or encrypted transport: no
            -- Data from: network

Buradaki “Data from: network” ifadesi önemli. Eğer önbellekten geliyorsa “Data from: cache” yazar. Sorgunun önbellekten mi ağdan mı geldiğini bu şekilde ayırt edebilirsiniz.

Belirli bir kayıt türünü sorgulamak için:

resolvectl query --type=MX gmail.com
resolvectl query --type=TXT _dmarc.example.com
resolvectl query --type=AAAA ipv6.google.com
resolvectl query --type=SRV _http._tcp.example.com

Belirli bir DNS sunucusuna karşı sorgu yapmak:

resolvectl query --dns-server=1.1.1.1 example.com

Bu parametre özellikle şu senaryoda işe yarıyor: “Local DNS sunucusu farklı cevap mı veriyor, yoksa upstream’den mi geliyor?” sorusunu yanıtlamak için.

Önbellek Yönetimi: Flush ve İstatistikler

DNS önbelleği bazen sorunların kaynağı olur. Bir domain’in IP’si değişti ama sistem hâlâ eski IP’ye gidiyor olabilir. TTL süresi dolmadan bu durumu çözmek için önbelleği temizleriz.

sudo resolvectl flush-caches

Bu komut tüm arayüzlerdeki DNS önbelleğini temizler. Komut sonrasında herhangi bir çıktı vermez, sessizce çalışır. Başarılı olup olmadığını kontrol etmek için istatistiklere bakabiliriz.

resolvectl statistics

Çıktı:

        Transactions: 1482
              Cache: 54/512 currently cached entries
    DNSSEC Verdicts: secure=0 insecure=0 bogus=0 indeterminate=54
  • Transactions: Toplam DNS işlem sayısı. Yüksek bir değer, sistemin yoğun DNS aktivitesi yaptığını gösterir.
  • Cache: Şu an önbellekte kaç kayıt var, maksimum kapasite ne.
  • DNSSEC Verdicts: DNSSEC doğrulama sonuçları. bogus=0 olması iyi; eğer bogus değeri yüksekse bir şeyler yanlış gidiyor demektir.

Flush sonrası istatistikleri tekrar kontrol ettiğinizde cache değerinin sıfırlandığını göreceksiniz. Bu, temizleme işleminin çalıştığını doğrular.

Gerçek Dünya Senaryosu: Şirket İçi DNS Sorununu Çözmek

Kurumsal ortamlarda sık karşılaşılan senaryo: VPN bağlandıktan sonra iç domainler çözümlenmiyor. Mesela app.internal.company.com adresine ulaşılamıyor ama internet çalışıyor.

Önce mevcut durumu kontrol edelim:

resolvectl status

Burada VPN arayüzünün (genellikle tun0 veya wg0) DNS ayarlarına bakıyoruz. Eğer VPN arayüzünde company.com domain’i için özel bir DNS tanımlanmamışsa, sistem bu sorguyu yanlış sunucuya gönderiyor olabilir.

Durumu doğrulamak için:

resolvectl query app.internal.company.com
# Hata alıyorsak:
resolvectl query --type=A app.internal.company.com

Sonra hangi DNS sunucusunun kullanıldığına bakalım:

resolvectl status tun0

Eğer VPN arayüzünde doğru DNS sunucusu atanmamışsa, NetworkManager veya VPN istemci konfigürasyonunu kontrol etmek gerekir. Geçici olarak bir arayüze DNS sunucusu atayabiliriz:

sudo resolvectl dns tun0 10.0.0.1
sudo resolvectl domain tun0 internal.company.com

Bu komutlar tun0 arayüzüne 10.0.0.1‘i DNS sunucusu olarak atar ve internal.company.com domain’ini bu arayüze bağlar. Artık internal.company.com ile biten sorgular 10.0.0.1‘e gönderilir.

Değişikliği doğrulayın:

resolvectl status tun0
resolvectl query app.internal.company.com

Bu yapılandırma geçicidir, sistem yeniden başladığında sıfırlanır. Kalıcı ayar için NetworkManager veya /etc/systemd/resolved.conf dosyasını düzenlemek gerekir.

systemd-resolved Konfigürasyonu

/etc/systemd/resolved.conf dosyası global DNS ayarlarını yönetir. Aşağıda yaygın bir kurumsal konfigürasyon örneği:

cat /etc/systemd/resolved.conf
[Resolve]
DNS=192.168.1.10 192.168.1.11
FallbackDNS=8.8.8.8 1.1.1.1
Domains=company.com internal.company.com
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
Cache=yes
CacheFromLocalhost=no

Önemli parametreler:

  • DNS: Birincil DNS sunucuları. Boşlukla ayrılmış birden fazla sunucu yazılabilir.
  • FallbackDNS: Birincil sunucular yanıt vermediğinde kullanılacak yedek sunucular.
  • Domains: Bu sunucuların yetkili olduğu domain’ler. ~. yazılırsa tüm domainler için kullanılır.
  • DNSSEC: yes, no veya allow-downgrade. Üretimde allow-downgrade genellikle en güvenli pratik seçenek.
  • DNSOverTLS: yes, no veya opportunistic. opportunistic mümkün olduğunda TLS kullanır, başaramazsa düz DNS’e düşer.
  • Cache: Önbelleği etkinleştirir veya devre dışı bırakır. Neredeyse her zaman yes bırakın.

Konfigürasyonu değiştirdikten sonra servisi yeniden başlatın:

sudo systemctl restart systemd-resolved

Log’ları İncelemek: journalctl ile Derinlemesine Analiz

resolvectl monitor yeterince detay vermediğinde veya geçmişteki bir sorunu araştırıyorsanız, journalctl devreye girer.

sudo journalctl -u systemd-resolved -f

-f parametresi canlı takip sağlar. Daha ayrıntılı log için resolved’ın log seviyesini artırmak gerekebilir:

sudo resolvectl log-level debug

Bu komut sonrasında journalctl çıktısı çok daha verbose hale gelir. Her DNS sorgusunun ayrıntılarını görürsünüz. Sorunu bulduktan sonra log seviyesini normale döndürmeyi unutmayın:

sudo resolvectl log-level info

Belirli bir domain ile ilgili log satırlarını filtrelemek:

sudo journalctl -u systemd-resolved --since "1 hour ago" | grep "github.com"

Zaman aralığı belirterek geçmiş olayları incelemek:

sudo journalctl -u systemd-resolved --since "2024-01-15 10:00:00" --until "2024-01-15 11:00:00"

LLMNR ve mDNS: Kapatmak mı, Açmak mı?

resolvectl status çıktısında LLMNR ve mDNS protokollerini görürsünüz. Bunlar yerel ağda isim çözümleme için kullanılan protokollerdir. Ancak kurumsal ortamlarda güvenlik açısından riskli olabilirler.

LLMNR (Link-Local Multicast Name Resolution) özellikle Windows ortamlarında NBNS zehirleme saldırılarına açık kapı bırakabilir. Gerekli değilse kapatın:

# /etc/systemd/resolved.conf içine ekleyin:
# LLMNR=no
# MulticastDNS=no

sudo nano /etc/systemd/resolved.conf
[Resolve]
LLMNR=no
MulticastDNS=no
sudo systemctl restart systemd-resolved
resolvectl status | grep -E "LLMNR|mDNS"

Kapatıldığında status çıktısında -LLMNR -mDNS şeklinde görünür.

DNS-over-TLS Yapılandırması ve Doğrulama

Gizlilik odaklı ortamlarda DNS sorgularını şifrelemek isteyebilirsiniz. DNS-over-TLS (DoT) bunun için kullanılır.

sudo nano /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes

Burada # sonrasındaki kısım, TLS sertifikasını doğrulamak için kullanılan SNI (Server Name Indication) adıdır. Bu sayede sadece IP eşleşmesi değil, sertifika doğrulaması da yapılır.

Değişikliği uygulayın ve test edin:

sudo systemctl restart systemd-resolved
resolvectl status | grep -i TLS
resolvectl query example.com

Sorgu çıktısında “Data was acquired via local or encrypted transport: yes” görüyorsanız DoT çalışıyor demektir.

Pratik Sorun Giderme Akışı

Bir DNS sorunu geldiğinde izlediğim adım sırası şu:

# 1. Servisin çalışıp çalışmadığını kontrol et
systemctl status systemd-resolved

# 2. Genel durumu gözden geçir
resolvectl status

# 3. Problematik domain'i sorgula
resolvectl query problematic-domain.com

# 4. Önbelleği temizle ve tekrar dene
sudo resolvectl flush-caches
resolvectl query problematic-domain.com

# 5. Farklı DNS sunucusuyla karşılaştır
resolvectl query --dns-server=8.8.8.8 problematic-domain.com

# 6. İstatistiklere bak
resolvectl statistics

# 7. Gerekirse canlı izlemeye geç
resolvectl monitor

Bu akış, sorunun önbellekten mi kaynaklandığını, DNS sunucusundan mı yoksa başka bir şeyden mi olduğunu sistematik olarak ortaya koyar.

Bir başka yaygın sorun: /etc/resolv.conf‘un yanlış yapılandırılması. Eğer bu dosya stub resolver’a işaret etmiyorsa, systemd-resolved‘ı bypass ederek doğrudan DNS sorgularına gidilir ve resolvectl çıktılarıyla gözlemlediğiniz ayarlar geçersiz kalır.

# Doğru bağlantıyı kontrol et
ls -la /etc/resolv.conf
# Eğer symlink değilse:
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

resolvectl’in Göz Ardı Edilen Parametreleri

Sık kullanılmayan ama bazen kritik öneme sahip birkaç parametre daha:

  • resolvectl reset-statistics: İstatistik sayaçlarını sıfırlar. Belirli bir zaman dilimini ölçmek istediğinizde işe yarar.
  • resolvectl dns: Bir arayüze DNS sunucusu atar (yukarıda gösterdik).
  • resolvectl domain: Bir arayüze search domain atar.
  • resolvectl default-route: Bir arayüzün varsayılan rota olup olmayacağını belirler. resolvectl default-route eth0 yes gibi kullanılır.
  • resolvectl revert: Bir arayüzün tüm DNS ayarlarını sıfırlar, varsayılana döner.
# eth0'ın DNS ayarlarını sıfırla
sudo resolvectl revert eth0

Bu komut özellikle geçici testler yaptıktan sonra sistemi temiz bırakmak için kullanışlıdır.

Sonuç

resolvectl, modern Linux sistemlerinde DNS sorunlarını çözmek için neredeyse her şeyi sağlıyor: gerçek zamanlı izleme, önbellek yönetimi, arayüz bazlı konfigürasyon ve detaylı istatistikler. Ancak bu aracın değerini tam anlamıyla kullanabilmek için systemd-resolved‘ın mimarisini ve stub resolver konseptini anlamak şart.

Çoğu DNS sorunu aslında üç kategoriden birine giriyor: yanlış DNS sunucusu atanmış, önbellekte eski kayıt kalmış veya arayüz bazlı yönlendirme eksik. resolvectl bu üç durumu da hızla tespit ettiriyor. Eski alışkanlıklarla nslookup veya /etc/resolv.conf düzenlemesiyle vakit kaybetmek yerine, resolvectl status ile başlayıp resolvectl monitor ile devam etmek çok daha verimli bir yaklaşım.

Production’da bir DNS sorunu geldiğinde paniğe gerek yok. Yukarıdaki adım sırasını takip edin, istatistikleri okuyun ve monitörü açın. Sorunun kaynağı büyük olasılıkla birkaç dakika içinde netleşecek.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir