Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

systemd-resolved ile DNS-over-TLS ve DNSSEC Kurulumu ve Sorun Giderme

systemd-resolved ile DNS-over-TLS ve DNSSEC nasıl etkinleştirilir? resolvedctl ve journalctl ile doğrulama ve yaygın doğrulama hatalarının çözümüne adım adım rehber.

Sistemsystemd-resolvedDNS-over-TLSDNSSECresolvedctl

Ben systemd-resolved'i Ubuntu sunucularımda yerel stub çözümleyici olarak bir süredir kullanıyorum. DNS-over-TLS (DoT) ve DNSSEC doğrulamasını kutudan çıkararak sunuyor, bu da unbound veya dnsmasq gibi yerel çözümleyiciler çalıştırmak yerine temiz bir alternatif oluyor. Geçenlerde yeni bir DNSSEC-imzalı bölgede doğrulama hatasıyla karşılaştım ve resolvedctl ile journalctl'in birleşimi tam da ihtiyacım olan şeyi verdi. Ortamımda systemd-resolved ile DoT ve DNSSEC nasıl yapılandırıp doğruladığımı burada paylaşıyorum.

resolved.conf'te DNS-over-TLS ve DNSSEC'i Etkinleştirme

Ana yapılandırma dosyası /etc/systemd/resolved.conf. DNSOverTLS'i opportunistic moda ayarlıyorum böylece TLS deneyerek desteklenmiyorsa düz UDP'ye geri döner. DNSSEC için ise doğrulama etkin ve güvenilen alanlar için DNSSEC zorunlu kılıyorum. Tipik yapılandırma şöyle:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9 149.112.112.112
DNSOverTLS=opportunistic
DNSSEC=allow-downgrade
DNSSEC=true

Düzenledikten sonra hizmeti yeniden başlatıyorum: sudo systemctl restart systemd-resolved. Opportunistic mod büyük Ağ'ların çoğu için güvenli — üst akım TLS'yi desteklemiyorsa çözümleme bozulmaz. Ancak strict zorunluluk istersen DNSOverTLS=yes kullanıp üst akımların gerçekten 853 portunu desteklediğinden emin olmalısın.

resolvedctl ile TLS ve DNSSEC Durumunu Kontrol Etme

resolved çalıştığında resolvedctl status komutunu kullanarak TLS'nin aktif olup olmadığını ve DNSSEC'nin doğrulama yapıp yapmadığını kontrol ederim. Bu komut mevcut DNS sunucuları, kullanılan protokol ve doğrulama durumunu gösterir:

$ resolvedctl status
Global
       DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#google-dns.com
    DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa ...

Her sunucu altında DNS Over TLS: YES veya DNS Over TLS: opportunistic (yes) satırını ararım. Eğer no yazıyorsa TLS kullanılmıyor. DNSSEC için çıktı doğrulamanın aktif olup olmadığını ve herhangi bir NTA (Negatif Güven Ânkarı) konumlandırılıp konumlandırılmadığını gösterir. NTAs bozuk veya tam olarak imzalanmamış bölgelerde doğrulama devre dışı bırakmak için kullanılır — genellikle dağıtımlar sırasında karşılaşılır.

journalctl ile Doğrulama Hatalarını İnceleme

DNSSEC doğrulama başarısız olduğunda systemd-resolved sebebini günlüğe kaydeder. dig veya host ile test ederken gerçek zamanlı log takibi için journalctl -u systemd-resolved -f kullanırım. Yaygın bir hata şöyle görünür:

systemd-resolved[1234]: Using feature UDP fallback for DNS server 9.9.9.9
systemd-resolved[1234]: DNSSEC validation failed: data does not validate

İlk satır TLS'nin kullanılamadığı veya düşürüldüğünü gösterir — strict TLS bekliyorsan bu faydalı. İkinci satır DNSSEC problemi işaret eder: eksik imza, süresi geçmiş anahtar veya saat sapması. Bir bölgenin KSK'sı güncellendi ama üst bölgedeki DS kaydı henüz güncellenmediği zaman buyla karşılaştım genellikle.

Daha derinlemesine inceleme için dig +dnssec example.com @127.0.0.53 ile AD (Kimlik Doğrulanmış Veri) bayrağını sorgularım. AD bayrağı ayarlanmıyorsa doğrulama başarısız oldu demektir. Ayarlıysa resolved verinin gerçekçi olduğuna inanıyor.

Yaygın Sorunların Giderilmesi

DoT veya DNSSEC beklendiği gibi çalışmadığında şunları kontrol ederim:

  • TCP/UDP 853 engellenmiş: ss -tuln | grep 853 veya nmap -p 853 <resolver-ip> ile portun açık olduğunu doğrulayarım. Bazı ISP'ler veya bulut güvenlik duvarları bu portu engeller.
  • Saat sapması: DNSSEC geçerli zaman damgalarına dayanır. Sistem saati birkaç dakika saparsa doğrulama başarısız olur. timedatectl status ile kontrol ederim.
  • Kırık güven zinciri: dig +trace +dnssec example.com ile zincirin kırıldığı yeri görürüm. Genellikle eksik DS kaydı veya yanlış key tag olur.
  • StubResolver güncellenmiyor: resolved.conf değiştirdikten sonra bazen sudo systemctl restart systemd-resolved ve ardından resolvectl flush-caches yapıp eski durumu temizlemem gerekir.

systemd-resolved vs Tam Çözümleyici Kullanımı

Masaüstü, dizüstü ve hafif sunucularda systemd-resolved'e bağlı kalıyorum çünkü basit, entegre ve ihtiyacım olan şifreli DNS ve temel doğrulama işini yapıyor. Önbellekli rekürsif çözümleme, DNS güvenlik duvarı veya gelişmiş günlükleme için hâlâ unbound veya AdGuard Home çalıştırırım. Ancak stub çözümleyici olarak DoT ve DNSSEC ile? Güvenilir ve düşük bakım gerektiriyor.

systemd zamanlayıcılarımdaki yazımda (https://furkanikkan.com/urun/systemd-zamanlayicilariyla-alt-dakikada-calisan-gorevler-accuracysec-ve-onunitactivesec-125) belirttiğim gibi günlük hata ayıklamanın ilk durağıdır — ve resolved ile özellikle DNS doğrulama için bu çok daha doğru.

Kapak görseli: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/52288971213