BIND ile Ters DNS (PTR) Kaydı Yapılandırması

yazar

Ters DNS kaydı, yani PTR (Pointer) kaydı, IP adresinden alan adına yapılan çözümlemenin temelidir. Pek çok sysadmin ileri DNS yapılandırmalarını öğrenirken PTR kayıtlarını atlıyor ya da “zaten mail sunucusu için lazım” deyip geçiştiriyor. Oysa mail teslimatından SSH log analizine, güvenlik duvarı kurallarından monitoring araçlarına kadar pek çok yerde ters DNS çözümlemesi kritik rol oynuyor. Bu yazıda BIND ile sıfırdan PTR kaydı yapılandırmasını, zone dosyası yazımını ve olası sorunların nasıl çözüleceğini gerçek dünya senaryolarıyla ele alacağız.

Ters DNS Nedir ve Neden Önemlidir

Normal (forward) DNS çözümlemesinde ornek.com sorgularsın, karşında 192.168.1.10 çıkar. Ters DNS’te tam tersi: 192.168.1.10 adresini sorgularsın, ornek.com döner. Bu çözümlemeyi sağlayan kayıt tipi PTR (Pointer Record) olarak adlandırılır.

Ters DNS’in neden önemli olduğunu birkaç somut örnekle açıklayayım:

  • Mail sunucuları: Gmail, Outlook ve büyük mail sağlayıcıları, mail gönderen sunucunun PTR kaydı olmadığında ya da PTR kaydı forward DNS ile eşleşmediğinde maili spam olarak işaretler veya reddeder.
  • SSH logları: /var/log/auth.log dosyasında IP adresleri yerine alan adı görmek, güvenlik analizini çok daha hızlı hale getirir.
  • Monitoring ve APM araçları: Grafana, Zabbix gibi araçlar host adlarını ters DNS üzerinden çözdüğünde dashboard’lar çok daha okunabilir olur.
  • Compliance gereksinimleri: PCI-DSS ve bazı ISO 27001 kontrolleri, ağ altyapısında ters DNS çözümlemesinin çalışmasını şart koşar.

in-addr.arpa Zone Mantığını Anlamak

Ters DNS’in teknik altyapısını anlamak, yapılandırmayı çok kolaylaştırır. IANA, in-addr.arpa adlı özel bir domain tanımlamış ve IP adreslerinin ters çevrilmiş haliyle bu domain altında PTR kayıtları tutulur.

Örneğin 192.168.1.10 IP adresinin PTR kaydı şu FQDN altında tutulur:

10.1.168.192.in-addr.arpa

IPv6 için benzer bir yapı olan ip6.arpa kullanılır ama bu yazıda IPv4’e odaklanıyoruz.

Bir /24 subnet için, yani 192.168.1.0/24 bloğu için zone adı şu şekilde olur:

1.168.192.in-addr.arpa

Eğer /16 bir blok yönetiyorsan:

168.192.in-addr.arpa

Bu mantığı kafana oturtmak, ilerleyen adımlarda zone dosyasını doğru yazman açısından kritik.

Senaryo: Küçük Ofis Ağı için Ters DNS Yapılandırması

Diyelim ki 192.168.10.0/24 subnet’inde bir ofis ağın var. Bu ağda birkaç sunucu çalışıyor ve iç DNS sunucun BIND. Amacın bu sunucular için PTR kayıtları oluşturmak.

Sunucularımız şunlar:

  • 192.168.10.1 -> router.ofis.local
  • 192.168.10.10 -> web01.ofis.local
  • 192.168.10.20 -> mail.ofis.local
  • 192.168.10.30 -> db01.ofis.local
  • 192.168.10.100 -> ns1.ofis.local

BIND Kurulumu ve Temel Hazırlık

Henüz BIND kurulu değilse önce kurulumu yapalım:

# Ubuntu/Debian
apt update && apt install -y bind9 bind9utils bind9-doc

# CentOS/RHEL/Rocky Linux
dnf install -y bind bind-utils

# Servis durumunu kontrol et
systemctl status named

BIND’ın ana konfigürasyon dosyası genellikle /etc/bind/named.conf (Debian/Ubuntu) veya /etc/named.conf (RHEL/CentOS) altında bulunur. Biz Debian bazlı sistemi örnek alacağız.

named.conf Dosyasına Zone Tanımlaması Eklemek

Önce mevcut konfigürasyon dosyasının yapısını kontrol edelim:

cat /etc/bind/named.conf
# Genellikle şunları include eder:
# named.conf.options
# named.conf.local
# named.conf.default-zones

Zone tanımlamalarını /etc/bind/named.conf.local dosyasına ekleyeceğiz. Hem forward hem de reverse zone’u buraya tanımlıyoruz:

nano /etc/bind/named.conf.local

Dosyaya şu içeriği ekle:

# Forward zone tanımı
zone "ofis.local" {
    type master;
    file "/etc/bind/zones/db.ofis.local";
    allow-update { none; };
};

# Reverse zone tanımı - 192.168.10.0/24 için
zone "10.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.168.10";
    allow-update { none; };
};

Zone dosyalarını ayrı bir klasörde tutmak düzenli çalışma açısından iyi bir alışkanlık:

mkdir -p /etc/bind/zones

Forward Zone Dosyası

PTR kayıtlarının doğru çalışması için forward zone’un da doğru yapılandırılmış olması gerekir. Çünkü birçok uygulama hem forward hem reverse çözümlemeyi çapraz doğrular.

nano /etc/bind/zones/db.ofis.local
$TTL 86400
@   IN  SOA ns1.ofis.local. admin.ofis.local. (
            2024010101  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Negative Cache TTL

; Name server kaydı
@       IN  NS      ns1.ofis.local.

; A kayıtları
router  IN  A       192.168.10.1
ns1     IN  A       192.168.10.100
web01   IN  A       192.168.10.10
mail    IN  A       192.168.10.20
db01    IN  A       192.168.10.30

; MX kaydı
@       IN  MX  10  mail.ofis.local.

Ters Zone Dosyası (PTR Kayıtları)

Asıl konumuza geldik. Şimdi PTR kayıtlarını içeren reverse zone dosyasını oluşturalım:

nano /etc/bind/zones/db.192.168.10
$TTL 86400
@   IN  SOA ns1.ofis.local. admin.ofis.local. (
            2024010101  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Negative Cache TTL

; Name server kaydı
@       IN  NS      ns1.ofis.local.

; PTR kayıtları - sadece son oktet yazılır
1       IN  PTR     router.ofis.local.
10      IN  PTR     web01.ofis.local.
20      IN  PTR     mail.ofis.local.
30      IN  PTR     db01.ofis.local.
100     IN  PTR     ns1.ofis.local.

Burada dikkat edilmesi gereken önemli noktalar var:

  • PTR kayıtlarında sadece son oktet yazılır (zone zaten 10.168.192.in-addr.arpa olarak tanımlandığı için)
  • PTR kayıtlarının değeri, yani alan adı kısmı mutlaka nokta ile bitmeli (trailing dot). web01.ofis.local. şeklinde. Sondaki noktu unutursan BIND kayıtları hatalı çözümler.
  • SOA bölümündeki serial numarası her değişiklikte artırılmalı. YYYYMMDDNN formatı en yaygın kullanılan formatır.

Yapılandırma Dosyalarını Doğrulama

Değişiklikleri yapmadan önce mutlaka syntax kontrolü yap. Bu adımı atlarsan servis başlamayabilir ve production’da kriz yaşarsın:

# named.conf dosyasını kontrol et
named-checkconf /etc/bind/named.conf

# Zone dosyalarını ayrı ayrı kontrol et
named-checkzone ofis.local /etc/bind/zones/db.ofis.local
named-checkzone 10.168.192.in-addr.arpa /etc/bind/zones/db.192.168.10

Başarılı bir çıktı şöyle görünür:

zone ofis.local/IN: loaded serial 2024010101
OK

zone 10.168.192.in-addr.arpa/IN: loaded serial 2024010101
OK

Eğer hata alırsan, genellikle şu sorunlardan biri vardır: eksik noktalama, yanlış zone adı, SOA formatı hatası. Hata mesajını dikkatlice oku, satır numarası genellikle belirtilir.

BIND Servisini Yeniden Başlatma

Syntax kontrolü başarılıysa servisi yeniden başlat:

# Servisi yeniden başlat
systemctl restart named

# Sadece yapılandırmayı yeniden yükle (daha az kesinti)
systemctl reload named

# Servis durumunu kontrol et
systemctl status named

# Log'ları izle
journalctl -u named -f

rndc aracıyla da zone’ları servis kapatmadan yeniden yükleyebilirsin:

# Belirli bir zone'u yeniden yükle
rndc reload 10.168.192.in-addr.arpa

# Tüm zone'ları yeniden yükle
rndc reload

# Zone durumunu kontrol et
rndc zonestatus 10.168.192.in-addr.arpa

PTR Kayıtlarını Test Etme

Test aşaması çok önemli. Birkaç farklı araçla doğrulama yapabilirsin:

# dig ile ters sorgu - en güvenilir yöntem
dig @192.168.10.100 -x 192.168.10.10

# dig ile daha detaylı çıktı
dig @192.168.10.100 -x 192.168.10.20 +short

# host komutu ile
host 192.168.10.10 192.168.10.100

# nslookup ile
nslookup 192.168.10.30 192.168.10.100

# Tüm PTR kayıtlarını zone transfer ile kontrol et
dig @192.168.10.100 10.168.192.in-addr.arpa AXFR

Başarılı bir dig -x çıktısı şöyle görünmeli:

;; ANSWER SECTION:
10.10.168.192.in-addr.arpa. 86400 IN PTR web01.ofis.local.

/24’ten Büyük Subnet’ler için Classless Delegation

Gerçek dünyada bazen ISP sana /24 değil /27 veya /28 gibi daha küçük bir IP bloğu tahsis eder. Bu durumda ters zone adlandırması biraz daha karmaşık hale gelir.

RFC 2317’nin tanımladığı classless in-addr.arpa delegation yöntemini kullanman gerekir. Örneğin 192.168.10.0/27 (192.168.10.0 – 192.168.10.31) bloğuna sahipsen:

# ISP tarafında (ya da /24'ün sahibi tarafında) şöyle bir CNAME delegation yapılır:
# 10.168.192.in-addr.arpa zone'una eklenir:
0/27    IN  NS  ns1.ofis.local.
1       IN  CNAME  1.0/27.10.168.192.in-addr.arpa.
10      IN  CNAME  10.0/27.10.168.192.in-addr.arpa.
20      IN  CNAME  20.0/27.10.168.192.in-addr.arpa.

Kendi tarafında ise named.conf.local‘e şu zone’u eklersin:

zone "0/27.10.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.168.10.0-27";
    allow-update { none; };
};

Ve zone dosyası:

$TTL 86400
@   IN  SOA ns1.ofis.local. admin.ofis.local. (
            2024010101
            3600
            1800
            604800
            86400 )

@       IN  NS      ns1.ofis.local.

1.0/27.10.168.192.in-addr.arpa.   IN  PTR  router.ofis.local.
10.0/27.10.168.192.in-addr.arpa.  IN  PTR  web01.ofis.local.
20.0/27.10.168.192.in-addr.arpa.  IN  PTR  mail.ofis.local.

Bu yapıyı pratikte çok az kişi doğru kuruyor. ISP’nin CNAME delegation yapmaması durumunda PTR sorguları çalışmaz, mail sunucularında deliverability sorunları yaşarsın.

Mail Sunucusu Senaryosu ve FCrDNS Kontrolü

Mail teslimabilirliği için en kritik kontrol FCrDNS (Forward Confirmed Reverse DNS)‘tir. Bu kontrol şunu doğrular: IP adresinin PTR kaydı bir alan adını göstermeli, o alan adının A kaydı da orijinal IP adresine dönmeli.

Diyelim ki mail sunucunun IP’si 203.0.113.50 ve alan adın mail.sirket.com. Bu durumda:

  • dig -x 203.0.113.50 -> mail.sirket.com. döndürmeli
  • dig mail.sirket.com A -> 203.0.113.50 döndürmeli

Bu iki kayıt eşleşmiyorsa, büyük mail sağlayıcıları seni spam folder’a gönderir ya da reddeder.

Test için basit bir bash scripti:

#!/bin/bash
# fcrDNS kontrol scripti
IP="203.0.113.50"

# Ters çözümleme
PTR=$(dig -x $IP +short)
echo "PTR kaydı: $PTR"

# Forward çözümleme
FORWARD=$(dig $PTR +short)
echo "Forward kaydı: $FORWARD"

# Karşılaştır
if [ "$FORWARD" = "$IP" ]; then
    echo "FCrDNS: GECERLI - Mail teslimabilirligi iyi"
else
    echo "FCrDNS: GECERSIZ - Mail teslimabilirligi sorunu var!"
fi

Sık Karşılaşılan Hatalar ve Çözümleri

Zone dosyasında trailing dot eksikliği: PTR kayıtlarının değeri mutlaka nokta ile bitmeli. web01.ofis.local yazan yerde web01.ofis.local. olmalı. Nokta olmadığında BIND otomatik olarak zone adını sona ekler ve web01.ofis.local.10.168.192.in-addr.arpa. gibi saçma bir kayıt oluşur.

Serial numarası güncellenmemiş: Zone dosyasını değiştirdin ama serial numarasını artırmadın. Secondary DNS sunucular, primary’den güncellenmiş zone’u çekmez. Her değişiklikte serial’ı artır.

Zone adı tersine çevrilmemiş: 192.168.10.0/24 için zone adının 10.168.192.in-addr.arpa olması gerekir, 192.168.10.in-addr.arpa değil. Özellikle yeni başlayanlarda bu hata çok sık görülür.

named.conf’ta yanlış dosya yolu: file direktifinde belirttiğin yol mevcut değil ya da BIND’ın okuma izni yok.

# İzin sorunlarını kontrol et
ls -la /etc/bind/zones/
chown -R bind:bind /etc/bind/zones/
chmod 644 /etc/bind/zones/*

AppArmor veya SELinux engellemesi: Ubuntu’da AppArmor, CentOS/RHEL’de SELinux BIND’ın bazı dizinlere erişimini engelleyebilir.

# Ubuntu - AppArmor loglarını kontrol et
grep named /var/log/syslog | tail -20

# CentOS/RHEL - SELinux loglarını kontrol et
ausearch -c named --raw | audit2why

# Geçici çözüm (production'da dikkatli kullan)
setsebool -P named_write_master_zones 1

Secondary DNS ile Zone Transfer Yapılandırması

Üretim ortamında tek bir DNS sunucusu yeterli değil. Bir secondary DNS sunucusuna zone transfer yapabilmek için named.conf.local‘i şöyle düzenlemelisin:

zone "10.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.168.10";
    allow-transfer { 192.168.10.101; };  # Secondary DNS IP
    notify yes;
};

Secondary sunucuda ise:

zone "10.168.192.in-addr.arpa" {
    type slave;
    file "/var/cache/bind/db.192.168.10";
    masters { 192.168.10.100; };  # Primary DNS IP
};

Zone transferini test etmek için:

dig @192.168.10.100 10.168.192.in-addr.arpa AXFR

Monitoring ve Log Takibi

PTR kayıtlarının çalışıp çalışmadığını periyodik olarak kontrol etmek iyi bir operasyon pratiğidir. Basit bir monitoring scripti:

#!/bin/bash
# PTR kayıtlarını kontrol eden basit script
DNS_SERVER="192.168.10.100"
LOG_FILE="/var/log/ptr-check.log"

declare -A IP_TO_HOST=(
    ["192.168.10.10"]="web01.ofis.local."
    ["192.168.10.20"]="mail.ofis.local."
    ["192.168.10.30"]="db01.ofis.local."
)

for IP in "${!IP_TO_HOST[@]}"; do
    EXPECTED="${IP_TO_HOST[$IP]}"
    RESULT=$(dig @$DNS_SERVER -x $IP +short)

    if [ "$RESULT" = "$EXPECTED" ]; then
        echo "$(date): OK - $IP -> $RESULT" >> $LOG_FILE
    else
        echo "$(date): HATA - $IP icin beklenen: $EXPECTED, gelen: $RESULT" >> $LOG_FILE
        # Burada alert mekanizman tetiklenebilir
    fi
done

Bu scripti cron ile her saat çalıştırabilirsin:

echo "0 * * * * root /usr/local/bin/ptr-check.sh" > /etc/cron.d/ptr-check

Sonuç

Ters DNS yapılandırması, DNS yönetiminin sıkça ihmal edilen ama kritik bir parçası. Özellikle mail sunucu işletiyorsan, PTR kayıtlarının ve FCrDNS doğrulamasının doğru çalışması neredeyse zorunlu. BIND ile bu yapılandırmayı doğru yapmak için şu adımları aklında tut: zone adını IP adresini tersine çevirerek oluştur, PTR kayıtlarında trailing dot’u unutma, serial numarasını her değişiklikte artır ve named-checkzone ile her zaman syntax kontrolü yap.

Gerçek dünyada en sık yaşanan sorun, ISP’nin sahip olduğu /24 blok üzerinde müşteri adına PTR kaydı oluşturmamasıdır. Eğer IP adreslerinin kontrolü sende değilse, ISP’nden reverse DNS delegation veya doğrudan PTR kaydı oluşturma talebinde bulunman gerekir. Kendi datacenter’ında ya da kendi IP bloğunu yönetiyorsan, bu yazıda anlattığımız yapılandırma tam ihtiyacını karşılar.

Yorum yapın