Wildcard DNS Kaydı Kullanımı ve Dikkat Edilmesi Gerekenler

yazar

DNS yönetimi sırasında en çok kafa karıştıran konulardan biri wildcard DNS kayıtlarıdır. Yanlış yapılandırıldığında ciddi güvenlik açıklarına yol açabilen, ama doğru kullanıldığında hayat kurtaran bu özelliği derinlemesine inceleyelim.

Wildcard DNS Kaydı Nedir?

Wildcard DNS kaydı, bir alan adı altındaki tüm alt alan adlarını (subdomain) tek bir kayıtla karşılayan özel bir DNS yapılandırmasıdır. *.example.com şeklinde tanımlanan bu kayıt, app.example.com, blog.example.com, anything.example.com gibi tüm alt alan adlarını belirtilen IP adresine veya hedefe yönlendirir.

Normal bir DNS kaydı yalnızca tam olarak tanımladığınız alan adı için geçerlidir. Ama wildcard kaydı, o alan adının altındaki tanımsız tüm alt alan adlarını yakalar. Bu fark kritiktir ve pek çok sysadmin bu noktayı gözden kaçırır.

RFC 1034 standardında tanımlanan bu özellik, teoride basit görünse de pratikte dikkatli ele alınması gereken birçok nüansı barındırır.

Ne Zaman Kullanılır?

Wildcard DNS’in gerçekten işe yaradığı senaryoları düşünelim:

SaaS platformları: Her müşteriye özel subdomain vermek istiyorsunuz. musteri1.uygulama.com, musteri2.uygulama.com gibi. Her yeni müşteri için ayrı DNS kaydı oluşturmak yerine wildcard kullanmak çok daha pratiktir.

Geliştirme ve test ortamları: *.dev.sirket.com gibi bir wildcard tanımlayarak geliştiricilerin istedikleri subdomain’i anında kullanmasına imkan tanıyabilirsiniz.

Wildcard SSL sertifikası ile birlikte kullanım: Let’s Encrypt veya ticari CA’lardan aldığınız *.example.com sertifikasıyla birlikte wildcard DNS kullanmak, yeni servis eklerken sertifika sorununu da ortadan kaldırır.

Reverse proxy arkasında çoklu uygulama: Nginx veya Traefik gibi bir reverse proxy kullanıyorsanız, tüm trafiği tek noktaya çekip oradan yönlendirmek için wildcard DNS idealdir.

Temel Wildcard DNS Kaydı Yapılandırması

BIND ile Wildcard Tanımlama

BIND kullanan bir DNS sunucusunda wildcard kaydı zone dosyasına şöyle eklenir:

; /etc/bind/zones/db.example.com

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
        2024010101  ; Serial
        3600        ; Refresh
        1800        ; Retry
        604800      ; Expire
        300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
*       IN  A       203.0.113.10

Buradaki kritik nokta şu: mail kaydı açıkça tanımlandığı için wildcard onu etkilemez. Wildcard yalnızca tanımsız alt alan adlarını yakalar.

dig ile Wildcard Kaydını Test Etme

Yapılandırmayı test etmek için:

# Wildcard kaydını doğrudan sorgula
dig *.example.com A

# Rastgele bir subdomain dene
dig randomsubdomain.example.com A

# Kısa çıktı formatında
dig +short herhangibirsey.example.com A

# SOA kaydını kontrol et
dig example.com SOA

# NS sunucularını sorgula
dig example.com NS

Çıktıda herhangibirsey.example.com için wildcard IP’sini görüyorsanız yapılandırma çalışıyor demektir.

PowerDNS ile Wildcard Kaydı

PowerDNS veritabanı tabanlı çalışıyorsa MySQL üzerinden kayıt eklemek şöyle yapılır:

# PowerDNS veritabanına wildcard kaydı ekle
mysql -u pdns -p pdns << 'EOF'
INSERT INTO records (domain_id, name, type, content, ttl, prio)
VALUES (
    (SELECT id FROM domains WHERE name = 'example.com'),
    '*.example.com',
    'A',
    '203.0.113.10',
    3600,
    0
);
EOF

# Kaydı doğrula
mysql -u pdns -p pdns -e "SELECT name, type, content FROM records WHERE name LIKE '%.example.com';"

Cloudflare ile Wildcard DNS

Cloudflare kullanıyorsanız, API üzerinden wildcard kaydı ekleyebilirsiniz:

# Cloudflare API ile wildcard A kaydı ekle
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" 
  -H "Authorization: Bearer API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "type": "A",
    "name": "*.example.com",
    "content": "203.0.113.10",
    "ttl": 3600,
    "proxied": false
  }'

# Mevcut kayıtları listele
curl -X GET "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records?type=A" 
  -H "Authorization: Bearer API_TOKEN" 
  -H "Content-Type: application/json" | jq '.result[] | {name, content, type}'

Not: Cloudflare’de wildcard kaydını proxy modunda (turuncu bulut) kullanmak için Pro veya üzeri plan gerekir. Free planda wildcard kayıtlar DNS-only (gri bulut) modunda çalışır.

Nginx ile Wildcard DNS Entegrasyonu

Wildcard DNS’in gerçek gücü, arkasındaki uygulama katmanıyla birleşince ortaya çıkar. Nginx üzerinde wildcard subdomain yönlendirmesi şöyle yapılır:

# /etc/nginx/sites-available/wildcard.example.com

server {
    listen 80;
    server_name ~^(?<subdomain>.+).example.com$;

    # Subdomain'e göre root dizini belirle
    root /var/www/sites/$subdomain;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ .php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Geçersiz subdomain'ler için fallback
    error_page 404 /404.html;
}

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/main;

    location / {
        try_files $uri $uri/ =404;
    }
}

Bu yapılandırmada musteri1.example.com geldiğinde Nginx $subdomain değişkenine musteri1 atar ve /var/www/sites/musteri1 dizinini kullanır. Her yeni müşteri için sadece dizin oluşturmanız yeterli olur, DNS veya Nginx’e dokunmanıza gerek kalmaz.

Dikkat Edilmesi Gereken Kritik Noktalar

1. Öncelik (Precedence) Kuralı

Wildcard DNS’in en önemli davranışı şudur: Açıkça tanımlanmış kayıtlar her zaman wildcard’dan önce gelir. Yani mail.example.com için ayrı bir A kaydınız varsa, wildcard bu kaydı ezmiyor.

Ama şunu unutmayın: Eğer bir subdomain için hiç kayıt yoksa wildcard devreye girer. Bu bazen istemediğiniz durumları tetikleyebilir. Örneğin siz ftp.example.com‘u yanlışlıkla sildiyseniz, wildcard onu da yakalar ve kullanıcılar ftp yerine web sunucunuza bağlanmaya çalışır.

2. Wildcard CNAME Kaydı

Wildcard sadece A/AAAA kaydı için değil, CNAME için de kullanılabilir:

# Zone dosyasında wildcard CNAME
*   IN  CNAME   lb.example.com.

# dig ile test
dig app.example.com CNAME
dig test.example.com CNAME

Ancak wildcard CNAME kullanırken dikkatli olun. CNAME ve MX kayıtları bir arada olmamalıdır. Eğer example.com‘un kendisi için wildcard CNAME tanımlarsanız, MX kayıtları etkilenebilir.

3. Güvenlik Riskleri

Wildcard DNS ciddi güvenlik sorunlarına yol açabilir. Şunları mutlaka göz önünde bulundurun:

Phishing ve typosquatting: Wildcard DNS açıkken secure.example.com veya paypal.example.com gibi subdomain’ler otomatik olarak çalışır. Uygulamanız bu subdomain’leri kontrol etmiyorsa kötü niyetli kişiler bunları istismar edebilir.

Sertifika doğrulama sorunları: Wildcard SSL sertifikası *.example.com‘u kapsar ama sub.sub.example.com gibi ikinci seviye subdomain’leri kapsamaz. Bu noktayı gözden kaçırmak çalışmayan HTTPS bağlantılarına yol açar.

Açık relay riski: Wildcard DNS ile birlikte yanlış yapılandırılmış bir mail sunucusu, istenmeyen e-posta (spam) relay’i için kullanılabilir.

# Hangi subdomain'lerin aktif olduğunu kontrol etmek için
# Kendi zone'unuzu tarayın
cat /etc/bind/zones/db.example.com | grep -v "^;" | grep -v "^$"

# Bir subdomain'in wildcard mı yoksa explicit kayıttan mı geldiğini anlamak
dig +additional +multiline rastgele123.example.com

4. MX Kaydı ile Çakışma

Wildcard A kaydınız varken gelen e-postalar için sorun yaşayabilirsiniz. Eğer mail.example.com için wildcard devredeyse ve mail sunucunuzu ayrıca tanımlamadıysanız, e-posta altyapınız çökebilir.

# MX kaydlarını her zaman açıkça tanımlayın
mail    IN  A       203.0.113.20
smtp    IN  A       203.0.113.20
imap    IN  A       203.0.113.20
pop3    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.

# Wildcard DKIM ve SPF ile çakışıyor mu kontrol edin
dig example.com TXT
dig _dmarc.example.com TXT

5. TTL Yönetimi

Wildcard kayıtları için TTL değerini dikkatli seçin. Çok düşük TTL, DNS sunucunuza gereksiz yük bindirir. Çok yüksek TTL ise bir hata durumunda düzeltmenin uzun sürmesine neden olur.

# Değişiklik planlamadan önce TTL'i düşürün
# Önce mevcut TTL'i kontrol edin
dig +nocmd +noall +answer *.example.com

# Değişiklik 24 saat öncesinden TTL'i 300 saniyeye indirin
# Zone dosyasında:
*   300 IN  A   203.0.113.10

# Değişiklik sonrası tekrar eski TTL'e döndürün
*   3600 IN  A  203.0.113.10

Wildcard DNS ve Let’s Encrypt

Wildcard SSL sertifikası almak için Let’s Encrypt’in DNS-01 challenge yöntemini kullanmanız gerekir:

# Certbot ile wildcard sertifika al
# DNS-01 challenge Cloudflare plugin'i ile
pip install certbot-dns-cloudflare

# Cloudflare API token dosyası oluştur
cat > /etc/letsencrypt/cloudflare.ini << 'EOF'
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN
EOF
chmod 600 /etc/letsencrypt/cloudflare.ini

# Wildcard sertifikayı al
certbot certonly 
  --dns-cloudflare 
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini 
  -d example.com 
  -d "*.example.com" 
  --preferred-challenges dns-01

# Sertifikanın hangi domain'leri kapsadığını kontrol et
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem 
  -noout -text | grep -A2 "Subject Alternative Name"

Önemli: Wildcard SSL sertifikası yalnızca bir seviye derinlikte çalışır. *.example.com sertifikası test.example.com‘u kapsar ama a.test.example.com‘u kapsamaz. Bunu aşmak için ayrı sertifika almalısınız.

Wildcard DNS Kaydını Kısıtlama ve Güvenlik Önlemleri

Wildcard DNS kullanırken bazı güvenlik katmanları eklemelisiniz:

# Uygulama katmanında izin verilen subdomain listesi kontrol et
# Örnek: Node.js Express uygulamasında

# Nginx'te izin verilmeyen subdomain'leri reddet
# /etc/nginx/sites-available/default
server {
    listen 80 default_server;
    server_name _;
    return 444;  # Bağlantıyı kapat, yanıt verme
}

# Sadece belirli subdomain pattern'lerine izin ver
server {
    listen 80;
    server_name ~^[a-z0-9-]+.example.com$;
    
    # Subdomain uzunluk kontrolü
    if ($host ~* "^.{64,}.example.com$") {
        return 400;
    }
    
    # Devam et...
}

Bir de DNS firewall katmanı düşünebilirsiniz. Özellikle kurumsal ortamlarda wildcard DNS’in önüne bir DNS filtreleme çözümü koyarak belirli subdomain pattern’lerini engelleyebilirsiniz.

Gerçek Dünya Senaryosu: Multi-Tenant SaaS Platformu

Diyelim ki müşteri başına subdomain veren bir proje yönetim uygulaması işletiyorsunuz. İşte tam stack yapılandırması:

# 1. DNS zone'a wildcard ekle
echo "*.example.com.  3600  IN  A  203.0.113.10" >> /etc/bind/zones/db.example.com

# 2. Serial numarasını güncelle ve BIND'ı yeniden yükle
sed -i 's/2024010101/2024010102/' /etc/bind/zones/db.example.com
named-checkzone example.com /etc/bind/zones/db.example.com
systemctl reload bind9

# 3. Yeni müşteri geldiğinde uygulama şunu yapıyor:
# Veritabanına müşteri kaydı ekle
# Nginx konfigürasyonu otomatik oluştur (template'den)
# Müşteri dizinini oluştur

# Template'den Nginx config oluşturma scripti
generate_nginx_config() {
    local subdomain=$1
    local customer_id=$2
    
    cat > /etc/nginx/sites-available/${subdomain}.example.com << EOF
server {
    listen 443 ssl;
    server_name ${subdomain}.example.com;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Customer-ID ${customer_id};
        proxy_set_header X-Real-IP $remote_addr;
    }
}
EOF
    
    ln -sf /etc/nginx/sites-available/${subdomain}.example.com 
           /etc/nginx/sites-enabled/
    nginx -t && systemctl reload nginx
}

generate_nginx_config "musteri1" "12345"

Bu yapıda DNS değiştirmenize gerek kalmaz. Wildcard zaten her şeyi yakalar. Siz sadece uygulama katmanında yeni müşteriyi tanımlamış olursunuz.

Wildcard DNS Sorun Giderme

En sık karşılaşılan sorunlar ve çözümleri:

# Wildcard çalışmıyor mu? Önce zone dosyasını kontrol et
named-checkzone example.com /etc/bind/zones/db.example.com

# Cache poisoning ya da eski kayıt mı? DNS cache'i temizle
# BIND için:
rndc flush

# systemd-resolved için:
systemd-resolve --flush-caches

# Windows'ta:
# ipconfig /flushdns

# Spesifik bir DNS sunucusunu sorgula (cache'i bypass et)
dig @8.8.8.8 test.example.com A
dig @ns1.example.com test.example.com A

# Zone transfer ile tüm kayıtları gör
dig @ns1.example.com example.com AXFR

# Wildcard'ın doğru IP'yi döndürdüğünü doğrula
for sub in app blog test random123 wildcard; do
    echo -n "$sub.example.com -> "
    dig +short $sub.example.com A
done

Wildcard ve DNSSEC

DNSSEC ile wildcard DNS bir arada kullanmak mümkün ama biraz daha karmaşıktır. DNSSEC ile wildcard kayıtlar imzalanırken NSEC3 kaydı kullanılması önerilir. Çünkü normal NSEC zone’daki tüm kayıtların isimlerini ifşa eder (zone walking saldırısı). NSEC3 ise bu bilgiyi hash’leyerek saklar.

# BIND DNSSEC ile wildcard zone imzalama
dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) 
  -N INCREMENT -o example.com -t db.example.com

# İmzalı zone'u doğrula
dnssec-verify -o example.com db.example.com.signed

# NSEC3 parametrelerini kontrol et
dig example.com NSEC3PARAM

Sonuç

Wildcard DNS kaydı, doğru kullanıldığında hem geliştirme sürecinizi hem de operasyonel yükünüzü ciddi ölçüde azaltır. Özellikle çok kiracılı (multi-tenant) uygulamalar ve dinamik subdomain gerektiren sistemler için vazgeçilmez bir araçtır.

Ama bu gücü sorumlulukla kullanmak gerekiyor. Her subdomain’in otomatik olarak erişilebilir olması hem bir avantaj hem de potansiyel bir güvenlik açığıdır. Uygulama katmanında subdomain doğrulaması yapmadan wildcard DNS kullanmak, kapınızı ardına kadar açık bırakmak gibidir.

Özetlemek gerekirse dikkat etmeniz gerekenler:

  • Açık kayıtlar (mail, ftp, smtp gibi) her zaman zone dosyasında net olarak tanımlanmalı
  • Uygulama katmanı bilinmeyen subdomain’leri reddetmeli veya kontrollü davranmalı
  • Wildcard SSL ile birlikte kullanılıyorsa ikinci seviye subdomain sınırlı kapsama dikkat edilmeli
  • TTL değerleri değişiklik planlamasına göre yönetilmeli
  • Güvenlik açısından düzenli olarak zone dosyası ve erişim logları gözden geçirilmeli
  • DNSSEC kullanılacaksa NSEC3 tercih edilmeli

Doğru yapılandırılmış bir wildcard DNS sistemi, altyapınıza esneklik katarken operasyonel karmaşıklığı da azaltır. Yanlış yapılandırılmış biri ise sizi güvenlik olaylarıyla baş başa bırakabilir. Seçim sizin.

Yorum yapın