Kapattığın sunucunun IP'si başkasına geçince ne olur: dangling DNS ve subdomain takeover

Ağustos başında kullanılmayan bir bulut sanal makinesini kapattım. Aylık faturayı kesmek için doğru karardı; eksik olan, DNS'e dokunmamaktı. Bir ay sonra bütün canlı adresleri tek satırlık bir tarama scriptinden geçirirken beş A kaydının hâlâ o ölü IP'ye baktığını gördüm. Ölü sandığım IP ise hiç ölü değildi.

Kanıt

IP'de 443 portu açıktı. Sertifikaya baktım: ortak adı başka bir IP, alternatif adları kubernetes.default.svc ile başlıyor, üretim tarihi bir gün önce. HTTPS cevabı bir Kubernetes API sunucusunun "anonim kullanıcıya yasak" mesajıydı. Yani IP havuzdan başka bir müşteriye verilmiş, o müşteri üstüne bir GKE kümesi kurmuştu. Benim beş alt alan adım, bir yabancının kümesine işaret ediyordu.

openssl s_client -connect 34.x.x.x:443 -servername alt.alan-adi.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Neden tehlikeli

Alan adın bir IP'ye bakıyorsa o IP'nin sahibi senin adınla içerik servis edebilir; HTTP doğrulamalı bir sertifika otoritesinden senin alt alan adın için sertifika bile alabilir. Kullanıcı tarayıcıda senin alan adını görür, kilit işaretini görür ve karşısındaki sayfanın sana ait olmadığını bilemez. Bu senaryonun adı subdomain takeover ve saldırganın tek yapması gereken, senin unuttuğun bir kaydın işaret ettiği IP'yi ya da bulut kaynağını ele geçirmek.

Nasıl bulunur

Bölgedeki bütün A ve CNAME kayıtlarını dök, her hedefe canlı bir istek at ve cevabı beklediğinle karşılaştır. Cevap veren ama sertifikası ya da içeriği sana ait olmayan hedef en tehlikeli sınıf; hiç cevap vermeyen hedef ikinci sınıf. Ben bunu 56 adresi tarayan, adres başına tek satır üreten bir script ile yapıyorum: durum kodu, yönlendirme hedefi, sertifika süresi, sayfa başlığı ve .env ile .git sızıntı probu. Her deploy sonrası değil ama her sunucu kapatma sonrası ve ayda bir çalıştırıyorum.

Temizlik, cerrahi

Ölü IP'ye bakan kayıtları sildim; birinin cevabı hâlâ 200'dü, çünkü önünde CDN vardı ve origin'i gölgeliyordu. O kaydı silmek yerine doğru sunucuya çevirdim. Bir tuzak daha: kullandığım yönetim aracının "kayıt sil" işlevi filtre almıyor ve bütün bölgeyi silme riski taşıyordu. Doğrudan REST ile, isim ve tip filtresiyle tek kaydı sildim; işlemden önce bölgenin tam yedeğini aldım. E-posta kayıtlarına, yani MX, SPF, DKIM ve DMARC'a dokunmadan, işlem sonrası hepsini yeniden okuyarak doğruladım.

# Hostinger DNS API — tek kaydı filtreyle sil, bölgeyi değil
curl -X DELETE "https://developers.hostinger.com/api/dns/v1/zones/ALAN-ADI" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"filters":[{"name":"eski-alt","type":"A"}]}'

Kural

Sunucu kapatma işinin son adımı DNS'tir; makineyi kapatmak işin yarısıdır. Kapattığın her kaynağın IP'sini ve hostname'ini bölgede ara; A kaydı, CNAME, hatta yönlendirme kuralı olarak nerede geçiyorsa temizle. Bulutta IP sabit değilse bu daha da acildir: geri dönüş süresi günler değil saatlerdir.

Bu yazı neye dayanıyor

3 Ağustos 2026'da kapatılan bir sanal makine ve 2 Eylül 2026'da yapılan tarama. Sertifika çıktısı ve API cevabı kaydedildi; beş kayıt aynı gün temizlendi ve bölge yedeği alındı.