Alan Adı Seçerken Yapılan 7 Yaygın Hata

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllar önce bir müşterimin production ortamında e-posta teslimat sorunu vardı. Günlerce debug ettik, SPF kayıtlarını inceledik, MX kayıtlarını kontrol ettik. Sonunda fark ettik ki sorun alan adının kendisindeydi. Müşteri, şirket adını alan adına yansıtırken bir harf fazla yazmış ve kimse fark etmemişti. Üç yıl boyunca bazı e-postalar sessiz sedasız kaybolup gitmişti. Bu tip hatalar göründüğünden çok daha sık yaşanıyor ve çoğu zaman başlangıçta alınan birkaç iyi karar bunların tamamını önleyebilir.

1. Uzun ve Karmaşık Alan Adları Seçmek

Bunu hep söylüyorum ama yine de insanlar “marka kimliğimizi yansıtsın” diyerek 40 karakterlik alan adlarıyla geliyor. Problem şu: Alan adı sadece tarayıcı adres çubuğunda değil, e-posta imzalarında, DNS kayıtlarında, SSL sertifikalarında ve her türlü konfigürasyon dosyasında geçiyor.

Uzun alan adları ile karşılaşılan teknik sorunları düşündüğünüzde akla ilk gelen şey yazım hatalarıdır. Ama bunun ötesinde DNS kayıt yönetimi de ciddi bir kabus haline gelebilir.

# Uzun alan adıyla SPF kaydı oluşturmak zorunda kaldığınızda
dig TXT uzun-ve-karmasik-sirket-ismi-ile-alan-adi.com.tr

# Subdomain eklenince durum daha da kötüleşiyor
# mail.uzun-ve-karmasik-sirket-ismi-ile-alan-adi.com.tr
# vpn.uzun-ve-karmasik-sirket-ismi-ile-alan-adi.com.tr
# api.uzun-ve-karmasik-sirket-ismi-ile-alan-adi.com.tr

Her subdomain tanımladığınızda bu uzun string’i tekrar tekrar yazıyorsunuz. Ansible playbook’larında, Nginx konfigürasyonlarında, Kubernetes ingress tanımlarında. Bir harf yanlış gittiğinde prodda bir şeyler çalışmıyor ve saatlerce debug ediyorsunuz.

Pratik kural: Alan adı 15 karakterin altında olsun. Zorunluluk varsa 20’ye kadar çıkabilir ama bunun ötesi gereksiz karmaşıklık.

2. TLD Seçimini Hafife Almak

“.com.tr” mü alayım, “.com” mu, yoksa trend TLD’lerden biri mi? Bu soruyu ciddiye almayan çok sistem yöneticisi gördüm. TLD seçimi sadece marka meselesi değil, aynı zamanda teknik ve operasyonel bir karardır.

# Farklı TLD'lerin whois yanıt sürelerini karşılaştırmak için
whois sirketismi.com | grep -i "expir"
whois sirketismi.com.tr | grep -i "expir"
whois sirketismi.io | grep -i "expir"

“.io” gibi ccTLD’ler (ülke kodu TLD’leri) teknik açıdan cazip görünebilir ama bu alan adları gerçekte British Indian Ocean Territory’ye ait ve yönetimi üçüncü parti şirketlerin elinde. Yarın ne olacağını kimse bilmiyor. Benzer şekilde “.tk”, “.ml” gibi ücretsiz TLD’leri production’da kullananları gördüm; bunlar spam filtreleri tarafından genellikle şüpheyle karşılanıyor.

E-posta teslimat açısından TLD önemli mi? Evet, önemli. Bazı büyük e-posta sağlayıcıları belirli TLD’lerden gelen e-postaları varsayılan olarak daha şüpheci değerlendiriyor. Bunu test edebilirsiniz:

# Mail-tester gibi araçlarla skor kontrol etmek için
# Önce bir test e-postası gönderin, sonra:
curl -s "https://www.mail-tester.com/test-[test-id]" | grep -i score

# Ya da mxtoolbox ile domain reputation kontrolü
# API ile otomatize edebilirsiniz:
curl "https://api.mxtoolbox.com/api/v1/Lookup/blacklist/?argument=sirketismi.com" 
  -H "Authorization: your-api-key"

.com.tr uzantısı Türk kullanıcılar için güven verici ama uluslararası pazara açılmayı düşünüyorsanız hem .com hem .com.tr‘yi almanız ve birini diğerine yönlendirmeniz en sağlıklı yaklaşım.

3. Alan Adı Yenileme Takibini Düzgün Yapmamak

Bu en çok acı yaşatılan konu. Kayıt sistemi eski bir e-posta adresine bağlı, o e-posta artık aktif değil, alan adı süresi doluyor ve siz habersizsiniz. Sonra site çöküyor, e-postalar gelmiyor, müşteriler arayıp soruyor.

# Alan adı sona erme tarihini kontrol etmek için basit bir script
#!/bin/bash
DOMAIN="sirketismi.com"
EXPIRY=$(whois $DOMAIN | grep -i "expir" | head -1 | awk '{print $NF}')
echo "Alan adı sona erme tarihi: $EXPIRY"

# Daha kapsamlı kontrol için:
whois $DOMAIN | grep -iE "(expir|renew|paid-till)"

Bunu düzgün yönetmek için bir monitoring sistemi kurmanız gerekiyor. Basit bir cron job ile başlayabilirsiniz:

#!/bin/bash
# /usr/local/bin/domain-expiry-check.sh
# Cron: 0 9 * * 1 /usr/local/bin/domain-expiry-check.sh

DOMAINS=("sirketismi.com" "sirketismi.com.tr" "backup-domain.com")
ALERT_DAYS=30
SLACK_WEBHOOK="https://hooks.slack.com/services/xxx/yyy/zzz"

for domain in "${DOMAINS[@]}"; do
    EXPIRY_DATE=$(whois $domain 2>/dev/null | grep -iE "expir" | grep -oE "[0-9]{4}-[0-9]{2}-[0-9]{2}" | head -1)
    
    if [ -z "$EXPIRY_DATE" ]; then
        echo "UYARI: $domain için sona erme tarihi bulunamadı"
        continue
    fi
    
    EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s 2>/dev/null)
    TODAY_EPOCH=$(date +%s)
    DAYS_LEFT=$(( ($EXPIRY_EPOCH - $TODAY_EPOCH) / 86400 ))
    
    if [ $DAYS_LEFT -lt $ALERT_DAYS ]; then
        MESSAGE="UYARI: $domain alan adının sona ermesine $DAYS_LEFT gün kaldı!"
        curl -s -X POST $SLACK_WEBHOOK 
            -H 'Content-type: application/json' 
            --data "{"text":"$MESSAGE"}"
    fi
done

Bu script’i birden fazla kanalda uyarı verecek şekilde yapılandırın. Sadece e-posta yetmez; Slack, PagerDuty veya ne kullanıyorsanız oraya da bağlayın. Alan adı yenilemeyi asla tek bir kişinin sorumluluğuna bırakmayın.

4. Typosquatting Riskini Görmezden Gelmek

Şirketinizin alan adının yaygın yazım hatası versiyonlarını siz almadıysanız başkası almış olabilir. Bu hem kullanıcılarınız için güvenlik riski oluşturur hem de rakiplerinizin önünü açar.

# Olası typo versiyonlarını listelemek için dnstwist aracını kullanabilirsiniz
# Kurulum:
pip3 install dnstwist

# Analiz:
dnstwist --registered sirketismi.com

# Çıktıdan sadece kayıtlı olanları filtrele:
dnstwist sirketismi.com | grep -v "^original"

Örneğin “google.com” için “googIe.com” (küçük L yerine büyük i), “g00gle.com” (sıfırlarla), “gogle.com” gibi versiyonlar mevcut. Sizin alan adınız için de benzer durumlar geçerli.

# DNS kayıtlarını karşılaştırarak phishing amaçlı kullanımı tespit etmek:
for domain in sirketismi.com sirketisnii.com sirketsmi.com; do
    echo "=== $domain ==="
    dig +short A $domain
    dig +short MX $domain
done

MX kaydı olan bir typo domain varsa bu ciddi bir alarm işareti; birisi o domain üzerinden e-posta alıyor demektir.

Ne yapmalısınız?

  • En yaygın yazım hatası versiyonlarını kayıt altına alın ve ana domain’e yönlendirin
  • Marka adınızın farklı TLD versiyonlarını en azından bloklama amaçlı kaydedin
  • Google Alerts ile marka adınızı takip edin
  • WIPO tahkim süreçlerini araştırın; eğer biri sizin markanızı domain olarak kullanıyorsa hukuki yollarınız var

5. DNS Konfigürasyonunu Sağlam Temele Oturtmamak

Alan adını aldınız, hosting’e bağladınız, çalışıyor. Ama DNS konfigürasyonu gerçekten sağlam mı? Bu soruyu çoğu sysadmin gerektiği kadar ciddiye almıyor.

# DNS delegation kontrolü - tüm nameserver'lar tutarlı mı?
dig NS sirketismi.com
dig NS sirketismi.com @8.8.8.8
dig NS sirketismi.com @1.1.1.1

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

# TTL değerlerini kontrol et - çok uzun TTL değişiklik yapmayı zorlaştırır
dig A sirketismi.com | grep -i ttl

TTL değeri kritik bir parametredir. Varsayılan olarak çoğu registrar 3600 (1 saat) veya daha yüksek TTL koyar. Bu, bir migration sırasında DNS değişikliğinin yayılması için en az 1 saat beklemek zorunda kaldığınız anlamına gelir. Bunu önceden ayarlayın:

# Migration öncesinde TTL'i düşürün (birkaç gün önce)
# Bu değişiklik eski TTL kadar süre sonra aktif olur
# Örnek: Route53 CLI ile
aws route53 change-resource-record-sets 
  --hosted-zone-id ZONE_ID 
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "sirketismi.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "1.2.3.4"}]
      }
    }]
  }'

Migration sonrası her şey yolundaysa TTL’i tekrar normal değere (3600 veya 7200) çekin.

DNSSEC’i ihmal etmeyin. Özellikle finans, sağlık veya herhangi bir kritik sektördeyseniz DNSSEC olmadan DNS cache poisoning saldırılarına açık kalırsınız.

# DNSSEC durumunu kontrol etmek için
dig DNSKEY sirketismi.com
dig +dnssec A sirketismi.com

# Online araçla kontrol:
# dnssec-analyzer.verisignlabs.com adresini kullanabilirsiniz

6. Birden Fazla Kayıt Firmasına Dağıtık Alan Adı Yönetimi

Farklı zamanlarda farklı ihtiyaçlarla alan adı aldınız ve bunlar farklı registrar’larda dağılmış durumda. Biri GoDaddy’de, biri Natro’da, biri Name.com’da. Her birinin ayrı paneli, ayrı ödeme sistemi, ayrı 2FA kurulumu.

Bu durumun operasyonel maliyeti düşündüğünüzden yüksek:

  • Her registrar’da ayrı güvenlik yapılandırması gerekiyor
  • Yenileme takibi karmaşıklaşıyor
  • Ekip üyelerine erişim vermek zorlaşıyor
  • Audit trail tutmak neredeyse imkansız hale geliyor
# Hangi registrar'da hangi domain'lerin olduğunu listelemek için
# Whois çıktısından registrar bilgisini çek:
for domain in sirketismi.com sirketismi.com.tr yedek-domain.com; do
    REGISTRAR=$(whois $domain | grep -i "registrar:" | head -1)
    echo "$domain: $REGISTRAR"
done

Çözüm: Tüm alan adlarını tek bir enterprise-grade registrar’a veya DNS yönetim platformuna taşıyın. Cloudflare Registrar, AWS Route53 veya Türkiye’deki alternatifler için Natro ya da Isimtescil üzerinden yönetim kolaylaşıyor. Önemli olan tek bir yerden yönetim ve API erişimi.

# Cloudflare API ile tüm domain'leri listelemek:
curl -X GET "https://api.cloudflare.com/client/v4/zones" 
     -H "X-Auth-Email: [email protected]" 
     -H "X-Auth-Key: api_key_buraya" 
     -H "Content-Type: application/json" | jq '.result[] | {name: .name, status: .status}'

7. Subdomain Envanteri Tutmamak

Alan adını aldınız, onlarca subdomain oluşturdunuz, sistem büyüdü, ekip değişti. Şu an kaç aktif subdomain’iniz var? Hangisi neye hizmet ediyor? Hangisi eski bir servise işaret ediyor ama hala çözümleniyor?

Bu “subdomain sprawl” problemi ciddi bir güvenlik riskidir. Dangling DNS kayıtları, subdomain takeover saldırılarının temel sebebi.

# Subdomain enumeration - kendi domain'inizi test edin
# Amass aracıyla (önce kurun: go install github.com/owasp-amass/amass/v4/...@master)
amass enum -d sirketismi.com -o subdomains.txt

# Alternatif olarak subfinder:
subfinder -d sirketismi.com -o subdomains.txt

# Bulunan subdomain'lerin hangisinin aktif olduğunu kontrol et:
while read subdomain; do
    if dig +short A $subdomain | grep -q "^[0-9]"; then
        echo "AKTIF: $subdomain -> $(dig +short A $subdomain)"
    else
        echo "PASIF: $subdomain"
    fi
done < subdomains.txt

Özellikle tehlikeli senaryo şu: Bir subdomain eski bir cloud kaynağına (AWS S3, GitHub Pages, Heroku uygulama URL’i gibi) işaret ediyorsa ve siz o kaynağı silmişseniz, saldırgan o kaynağı yeniden claim edip subdomain’inizi ele geçirebilir.

# CNAME kayıtlarını kontrol et - hangisi belirsiz bir hedefe işaret ediyor?
while read subdomain; do
    CNAME=$(dig +short CNAME $subdomain)
    if [ ! -z "$CNAME" ]; then
        echo "$subdomain -> $CNAME"
        # Bu hedef var mı?
        if ! dig +short A $CNAME | grep -q "^[0-9]"; then
            echo "  ^^^ DİKKAT: Bu CNAME hedefi çözümlenemiyor! Subdomain takeover riski!"
        fi
    fi
done < subdomains.txt

Subdomain yönetimi için pratik adımlar:

  • Tüm DNS kayıtlarınızı Infrastructure as Code ile yönetin (Terraform, Pulumi veya benzeri)
  • Her DNS kaydına comment veya tag ekleyin: ne işe yarıyor, kim talep etti, ne zaman oluşturuldu
  • Kullanılmayan servislerin DNS kayıtlarını hemen silin
  • Ayda bir subdomain audit yapın
# Terraform ile DNS kaydı yönetimi örneği (AWS Route53)
# Bu yaklaşım ile her değişiklik git history'de görünür

# dns/records.tf
resource "aws_route53_record" "api" {
  zone_id = var.zone_id
  name    = "api.sirketismi.com"
  type    = "A"
  ttl     = 300
  records = [var.api_server_ip]
  
  # Kim ne zaman neden oluşturdu? Git commit mesajında olacak.
}

Sonuç

Alan adı seçimi ve yönetimi, sistem yönetiminin en göz ardı edilen ama en kritik parçalarından biri. Bir kez yanlış gidince düzeltmek hem teknik hem operasyonel hem de bazen hukuki açıdan ciddi efor gerektiriyor.

Özetlemek gerekirse:

  • Kısa ve net alan adı seçin, karmaşıklık operasyonel maliyeti artırır
  • TLD’yi stratejik seçin, “ucuz” veya “trend” olmak yeterli kriter değil
  • Yenileme takibini otomatize edin, insan hafızasına güvenmeyin
  • Typosquatting’e karşı proaktif olun, siz almadıysanız biri almıştır
  • DNS konfigürasyonunu doğru yapın, TTL ve DNSSEC ihmal edilmesin
  • Tüm alan adlarını tek platformda yönetin, dağıtık yönetim risk demek
  • Subdomain envanteri tutun ve düzenli audit yapın

Bu maddeleri bir checklist olarak ekibinizle paylaşın. Yeni bir alan adı alınmadan önce bu adımları gözden geçirin. Production’da bir şeyler patladıktan sonra “keşke baştan yapseydık” demek yerine baştan doğru yapmak her zaman daha az maliyetli.

Bir yanıt yazın

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