TSIG ve nsupdate ile DNS Dinamik Güncelleme ve Güvenli Bölge Transferi

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

DNS altyapısında güvenlik açısından en çok ihmal edilen konulardan biri dinamik güncellemeler ve bölge transferleri. Özellikle büyük kurumsal ortamlarda onlarca DHCP sunucusu, çeşitli otomasyon araçları ve farklı ekiplerin DNS’e yazma ihtiyacı olduğunda, “herkes güncelleme yapsın” yaklaşımı ciddi güvenlik açıklarına yol açıyor. TSIG (Transaction SIGnature) ve nsupdate kombinasyonu, bu kaosa düzen getirmenin en pratik yolu. Yıllarca production ortamlarında bu mekanizmayı kullandım ve doğru kurulduğunda hem güvenli hem de son derece esnek bir çözüm sunduğunu söyleyebilirim.

TSIG Nedir ve Neden Önemlidir

TSIG, RFC 2845 ile tanımlanmış bir DNS güvenlik mekanizmasıdır. Temel olarak paylaşımlı gizli anahtar (shared secret) kullanarak DNS mesajlarını imzalar. Böylece hem kimlik doğrulama (authentication) hem de bütünlük kontrolü (integrity check) sağlanmış olur.

TSIG olmadan dinamik DNS güncellemesi yapmak, kapınızı açık bırakıp “zaten kimse girmez” demek gibi. Herhangi biri ağa erişim sağladığında DNS kayıtlarınızı değiştirebilir. TSIG ile bu işlem imzalı hale gelir; sunucu anahtarı doğrulamazsa güncellemeyi reddeder.

TSIG’in çalışma prensibi oldukça basittir: İstemci ve sunucu aynı gizli anahtarı paylaşır. İstemci DNS isteğini göndermeden önce bu anahtarla HMAC imzası oluşturur. Sunucu kendi anahtarıyla aynı imzayı hesaplar ve karşılaştırır. Eşleşirse işlem onaylanır. Ayrıca zaman damgası da kontrole dahil olduğundan replay saldırılarına karşı da koruma sağlar.

TSIG Anahtarı Oluşturma

BIND kurulu bir sistemde tsig-keygen veya eski adıyla dnssec-keygen aracını kullanabilirsiniz. Modern sistemlerde tsig-keygen tercih edilmeli.

# HMAC-SHA256 ile anahtar oluşturma
tsig-keygen -a hmac-sha256 dhcp-update-key

# Çıktı doğrudan BIND uyumlu formatta gelir
# Örnek çıktı:
key "dhcp-update-key" {
    algorithm hmac-sha256;
    secret "r4nd0mB4s364Str1ng==";
};

Farklı algoritmalar için seçenekler:

  • hmac-md5: Eski sistemlerle uyumluluk için, güvenlik açısından artık önerilmiyor
  • hmac-sha1: MD5’ten daha iyi ama yeterli değil
  • hmac-sha256: Production için minimum standart, bunu kullanın
  • hmac-sha384: Yüksek güvenlik gerektiren ortamlar için
  • hmac-sha512: Maksimum güvenlik, performans maliyeti ihmal edilebilir düzeyde

Birden fazla istemci için ayrı anahtar üretmek iyi bir uygulama. Her DHCP sunucusu, her otomasyon sistemi için ayrı anahtar tutun. Böylece bir anahtarın ele geçirilmesi durumunda sadece o istemciyi devre dışı bırakırsınız.

# Farklı sistemler için anahtarlar oluşturun
tsig-keygen -a hmac-sha256 dhcp-server-01-key > /etc/named/keys/dhcp-server-01.key
tsig-keygen -a hmac-sha256 dhcp-server-02-key > /etc/named/keys/dhcp-server-02.key
tsig-keygen -a hmac-sha256 automation-api-key > /etc/named/keys/automation-api.key

# Dosya izinlerini kısıtlayın, named kullanıcısı dışında kimse okuyamaz olsun
chown root:named /etc/named/keys/*.key
chmod 640 /etc/named/keys/*.key

BIND Sunucusunu TSIG İçin Yapılandırma

Anahtarları oluşturduktan sonra BIND konfigürasyonuna eklemeniz gerekiyor. /etc/named.conf dosyasını ya da include kullandığınız bir alt dosyayı düzenleyin.

# /etc/named/keys/dhcp-server-01.key içeriğini named.conf'a include edin
# ya da doğrudan ekleyin

# /etc/named.conf veya /etc/named/named.conf.local
include "/etc/named/keys/dhcp-server-01.key";
include "/etc/named/keys/dhcp-server-02.key";
include "/etc/named/keys/automation-api.key";

# Zone tanımında allow-update direktifini ayarlayın
zone "sirket.local" IN {
    type master;
    file "/var/named/sirket.local.db";
    allow-update {
        key "dhcp-server-01-key";
        key "dhcp-server-02-key";
        key "automation-api-key";
    };
    allow-transfer {
        key "slave-transfer-key";
        192.168.1.50;  # Slave sunucu IP'si ek güvenlik katmanı olarak
    };
};

Yapılandırmayı test etmeyi ve uygulamayı unutmayın:

# Syntax kontrolü
named-checkconf /etc/named.conf

# Zone dosyasını da kontrol edin
named-checkzone sirket.local /var/named/sirket.local.db

# Konfigürasyonu yeniden yükleyin (zone dosyası değişikliklerinde)
rndc reload

# Ya da sadece konfigürasyonu yeniden oku
rndc reconfig

nsupdate ile Dinamik DNS Güncellemesi

nsupdate, BIND paketinin bir parçası olarak gelen komut satırı aracıdır. DNS sunucusuna RFC 2136 standartlarında dinamik güncelleme mesajları gönderir.

Temel kullanım oldukça sezgiseldir. Etkileşimli modda çalıştırabilir ya da script içinden kullanabilirsiniz:

# Etkileşimli mod - TSIG anahtarı ile
nsupdate -k /etc/named/keys/dhcp-server-01.key

# nsupdate> prompt gelecek, komutları girebilirsiniz
> server 192.168.1.10
> zone sirket.local
> update add webserver01.sirket.local 3600 A 192.168.10.25
> send
> quit

Betik içinde kullanmak için heredoc yaklaşımı çok daha temiz:

#!/bin/bash
# dns_update.sh - Otomatik DNS kayıt güncelleme betiği

DNS_SERVER="192.168.1.10"
ZONE="sirket.local"
KEY_FILE="/etc/named/keys/automation-api.key"
TTL=3600

add_a_record() {
    local hostname=$1
    local ip=$2

    nsupdate -k "${KEY_FILE}" << EOF
server ${DNS_SERVER}
zone ${ZONE}
update delete ${hostname}.${ZONE} A
update add ${hostname}.${ZONE} ${TTL} A ${ip}
send
EOF

    if [ $? -eq 0 ]; then
        echo "[OK] ${hostname} -> ${ip} kaydı güncellendi"
    else
        echo "[HATA] ${hostname} -> ${ip} kaydı güncellenemedi" >&2
        return 1
    fi
}

# PTR kaydını da ekleyelim (reverse zone için)
add_ptr_record() {
    local ip=$1
    local hostname=$2
    # 192.168.10.25 -> 25.10.168.192.in-addr.arpa
    local ptr=$(echo "${ip}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa"}')

    nsupdate -k "${KEY_FILE}" << EOF
server ${DNS_SERVER}
zone 10.168.192.in-addr.arpa
update delete ${ptr}. PTR
update add ${ptr}. ${TTL} PTR ${hostname}.${ZONE}.
send
EOF
}

add_a_record "webserver01" "192.168.10.25"
add_ptr_record "192.168.10.25" "webserver01"

Gerçek Dünya Senaryosu: DHCP-DNS Entegrasyonu

En yaygın kullandığım senaryo DHCP sunucusunun otomatik DNS kaydı güncellemesi. ISC DHCP kullandığınızda bu entegrasyon neredeyse hazır geliyor, ama manuel kontrol isteyenler için ayrı bir betik yaklaşımı da işe yarıyor.

ISC DHCP ile TSIG entegrasyonu için /etc/dhcp/dhcpd.conf:

# TSIG anahtarını DHCP konfigürasyonuna ekleyin
key "dhcp-server-01-key" {
    algorithm hmac-sha256;
    secret "r4nd0mB4s364Str1ng==";  # Gerçek secret buraya
};

# DNS güncelleme zone tanımları
zone sirket.local. {
    primary 192.168.1.10;
    key "dhcp-server-01-key";
}

zone 10.168.192.in-addr.arpa. {
    primary 192.168.1.10;
    key "dhcp-server-01-key";
}

# Global DDNS ayarları
ddns-update-style interim;
ddns-updates on;
update-static-leases on;
ddns-domainname "sirket.local.";
ddns-rev-domainname "in-addr.arpa.";

# Subnet tanımı
subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.100 192.168.10.200;
    option domain-name-servers 192.168.1.10;
    option domain-name "sirket.local";
    option routers 192.168.1.1;
    default-lease-time 86400;
    max-lease-time 172800;
}

Güvenli Bölge Transferi (AXFR/IXFR) Yapılandırması

Zone transfer güvenliği çoğu zaman göz ardı edilir. AXFR (tam transfer) ya da IXFR (artımlı transfer) için TSIG kullanmak, yetkisiz zone kopyalamasını engeller.

Slave sunucu tarafında anahtar dosyasını da oluşturmanız ve aynı secret’ı kullanmanız gerekir:

# Slave sunucuda named.conf konfigürasyonu
# Anahtarı master ile aynı secret kullanarak tanımlayın
key "slave-transfer-key" {
    algorithm hmac-sha256;
    secret "sl4v3Tr4nsf3rS3cr3t==";
};

# Slave zone tanımı
zone "sirket.local" IN {
    type slave;
    file "/var/named/slaves/sirket.local.db";
    masters {
        192.168.1.10 key "slave-transfer-key";
    };
    allow-notify { 192.168.1.10; };
};

Master sunucu tarafında da aynı anahtarla transfer izni vermek gerekiyor:

# Master sunucu - named.conf
key "slave-transfer-key" {
    algorithm hmac-sha256;
    secret "sl4v3Tr4nsf3rS3cr3t==";
};

zone "sirket.local" IN {
    type master;
    file "/var/named/sirket.local.db";
    allow-update {
        key "dhcp-server-01-key";
        key "automation-api-key";
    };
    allow-transfer {
        key "slave-transfer-key";
    };
    also-notify { 192.168.1.50; };
};

Transfer testini şu şekilde yapabilirsiniz:

# TSIG anahtarı olmadan zone transfer deneyin - reddedilmeli
dig @192.168.1.10 sirket.local AXFR

# TSIG anahtarı ile zone transfer
dig @192.168.1.10 sirket.local AXFR -k /etc/named/keys/slave-transfer-key.key

# Alternatif olarak nsupdate değil, doğrudan dig ile test
dig -y hmac-sha256:slave-transfer-key:sl4v3Tr4nsf3rS3cr3t== @192.168.1.10 sirket.local AXFR

Sorun Giderme ve İzleme

TSIG ile ilgili sorunların büyük çoğunluğu saat senkronizasyonu problemlerinden kaynaklanır. TSIG zaman damgası kontrolü yapar ve sunucu ile istemci arasındaki saat farkı 300 saniyeyi (5 dakika) aşarsa işlem reddedilir.

# Sistem saatini kontrol edin
timedatectl status

# NTP senkronizasyonunu doğrulayın
chronyc tracking
# ya da
ntpq -p

# BIND log dosyasında TSIG hatalarını arayın
tail -f /var/log/named/named.log | grep -i "tsig|update|refused"

# journald kullanıyorsanız
journalctl -u named -f | grep -i "tsig|refused|denied"

BIND’in named.conf’unda detaylı loglama açmak sorunları bulmayı kolaylaştırır:

logging {
    channel update_log {
        file "/var/log/named/ddns-updates.log" versions 5 size 20m;
        severity dynamic;
        print-time yes;
        print-severity yes;
        print-category yes;
    };

    category update { update_log; };
    category update-security { update_log; };
    category security { update_log; };
};

Başlıca hata durumları ve çözümleri:

  • REFUSED hatası: Ya TSIG anahtarı yanlış ya da allow-update kuralı IP’yi veya anahtarı kapsamamıyor. named.log‘a bakın.
  • NOTAUTH hatası: Güncellemek istediğiniz zone bu sunucuda master olarak tanımlı değil.
  • BADSIG hatası: Anahtar secret’ı uyuşmuyor. Her iki taraftaki anahtar dosyalarını karşılaştırın.
  • BADTIME hatası: Saat senkronizasyonu sorunu. NTP servisini kontrol edin.
  • NXDOMAIN veya SERVFAIL: Zone dosyası ya da zone tanımında sorun var, named-checkzone çalıştırın.

Kubernetes ve Modern Altyapılarda external-dns Entegrasyonu

Kubernetes ortamlarında external-dns projesi TSIG ile doğrudan çalışabilir. Bu, pod ve servisler için otomatik DNS kaydı oluşturmanın en temiz yolu.

# external-dns için TSIG anahtarı oluşturun
tsig-keygen -a hmac-sha256 external-dns-key > /etc/named/keys/external-dns.key

# Kubernetes secret olarak saklayın
kubectl create secret generic external-dns-tsig 
  --from-literal=tsig-secret="b4s364EncodedS3cr3t==" 
  -n external-dns

# external-dns deployment için temel argümanlar (values.yaml veya deployment manifest)
# --provider=rfc2136
# --rfc2136-host=192.168.1.10
# --rfc2136-port=53
# --rfc2136-zone=sirket.local
# --rfc2136-tsig-secret=$(EXTERNAL_DNS_TSIG_SECRET)
# --rfc2136-tsig-secret-alg=hmac-sha256
# --rfc2136-tsig-keyname=external-dns-key
# --rfc2136-tsig-axfr=true

BIND tarafında zone yapılandırmasına key "external-dns-key" eklemeyi unutmayın.

Anahtar Rotasyonu

Güvenlik açısından TSIG anahtarlarını periyodik olarak rotate etmek gerekiyor. Bunu kesintisiz yapmanın yolu önce yeni anahtarı ekleyip her iki anahtarla çalışmasını sağlamak, ardından eski anahtarı kaldırmak.

#!/bin/bash
# tsig_rotate.sh - Anahtar rotasyonu için yardımcı betik

KEY_DIR="/etc/named/keys"
OLD_KEY="automation-api-key"
NEW_KEY="automation-api-key-v2"
NAMED_CONF="/etc/named/named.conf.local"

# Yeni anahtar oluştur
tsig-keygen -a hmac-sha256 "${NEW_KEY}" > "${KEY_DIR}/${NEW_KEY}.key"
chown root:named "${KEY_DIR}/${NEW_KEY}.key"
chmod 640 "${KEY_DIR}/${NEW_KEY}.key"

echo "Yeni anahtar oluşturuldu: ${KEY_DIR}/${NEW_KEY}.key"
echo "Şimdi named.conf'a yeni include ekleyin ve zone allow-update'e ekleyin"
echo "İstemcileri yeni anahtarla güncelleyin"
echo "Tüm istemciler güncellendikten sonra eski anahtarı kaldırın"

# named'ı reload et
rndc reconfig && echo "named yeniden yapılandırıldı"

Rotasyon sürecini şu adımlarla yönetin: Yeni anahtarı oluştur, named.conf’a ekle, zone allow-update’e dahil et, rndc reconfig yap, istemcileri yeni anahtarla güncelle, eski anahtarın kullanılmadığını loglardan doğrula, sonra eski anahtarı kaldır.

Sonuç

TSIG ve nsupdate kombinasyonu, DNS altyapınıza gerçek bir güvenlik katmanı ekler. IP tabanlı kısıtlamalar artık yeterli değil; NAT arkasındaki sistemler, bulut ortamları ve dinamik IP’ler nedeniyle kaynak IP doğrulaması kolayca atlatılabiliyor. TSIG ile imza tabanlı kimlik doğrulama bu problemi çözüyor.

Pratikte dikkat edilmesi gereken birkaç kritik nokta var: Anahtar dosyalarına dosya sistemi izinlerini doğru ayarlayın, NTP senkronizasyonunu her zaman sağlıklı tutun, her istemci için ayrı anahtar kullanın ve anahtarları düzenli rotate edin. Zone transfer için de mutlaka TSIG kullanın, aksi halde zone içeriğiniz yetkisiz kişilerin eline geçebilir.

Modern altyapılarda Kubernetes, Terraform veya Ansible gibi otomasyon araçlarıyla entegrasyon da artık çok daha kolay. RFC 2136 standardını destekleyen her araç TSIG ile çalışabilir; external-dns buna güzel bir örnek. DNS altyapınızı ne kadar otomasyona açarsanız, TSIG güvenliğinin önemi o kadar artıyor. Bir kez doğru kurduğunuzda yıllarca sorunsuz çalışan, bakım maliyeti düşük ve gerçekten güvenli bir DNS güncelleme altyapısına kavuşmuş olursunuz.

Bir yanıt yazın

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