Terk Edilmiş CNAME Kaydı Riski: Subdomain Takeover Nasıl Önlenir?

DNS yönetim panelinizi açtığınızda ekranda 40-50 satır kayıt görüyorsunuz. www, mail, ftp gibi olanları tanıyorsunuz. Ama listenin ortasında blog, destek, kampanya2023, staging gibi adlar var ve bunların hepsi bir CNAME kaydıyla dışarıdaki bir hizmete işaret ediyor: blog.sirketiniz.com → sirketiniz.eskiplatform.io. O platformdaki hesabı iki yıl önce kapattınız. Kayıt hâlâ orada duruyor ve kimse silmeyi düşünmedi.

İşte bu tam olarak bir güvenlik açığıdır. O platformda hesabınız yokken, aynı hostname'i başka biri kendi hesabına tanımlayabilir. Tanımladığı anda blog.sirketiniz.com adresine gelen ziyaretçi onun içeriğini görür — üstelik sizin alan adınız, sizin markanız, çoğu zaman sizin adınıza alınmış geçerli bir HTTPS sertifikasıyla. Bu saldırıya subdomain takeover (alt alan adı ele geçirme), ele geçirilmeye açık kayda ise dangling record ya da Türkçesiyle sahipsiz/boşa düşmüş kayıt denir.

Bu yazı saldırganın nasıl tarama yaptığını anlatan bir bug bounty rehberi değil. Site sahibi tarafından bakıyoruz: panelinizdeki hangi satırlar risklidir, hedefin gerçekten boşta olup olmadığını nasıl test edersiniz, bir servisi kapatırken hangi sırayla ilerlemek gerekir ve aynı hatanın tekrarlanmaması için nasıl bir düzen kurulur.

Subdomain Takeover Nedir ve Kayıt Neden "Sahipsiz" Kalır?#

Bir CNAME kaydı, alt alan adınızı başka bir hostname'e takma ad yapar. Ziyaretçinin çözümleyicisi blog.sirketiniz.com sorduğunda "aslında sirketiniz.eskiplatform.io adresine bak" cevabını alır ve zinciri oradan devam ettirir. Yani içeriğin nerede duracağına dair kararı siz DNS'te verirsiniz; içeriğin kime ait olacağına dair kararı ise hedefteki platform verir.

Bu ayrım her şeyin özüdür. Sizin alan adınız üzerindeki yetkiniz mutlaktır, hedef platformdaki yetkiniz ise sadece orada aktif bir hesabınız olduğu sürece geçerlidir. Hesap kapandığında, deneme süresi bittiğinde veya faturayı ödemediğinizde platform o hostname'i havuzuna geri alır. Havuzdaki hostname'i ilk talep eden kişi sahibi olur. DNS tarafındaki ok ise hâlâ oraya bakmaktadır.

Kayıtların sahipsiz kalmasının pratikte hep aynı birkaç nedeni vardır:

• Servis kapatıldı, DNS unutuldu. Pazarlama ekibi bir landing page platformunu bıraktı, kimse sistem yöneticisine haber vermedi.
• Deneme hesabı doldu. Bir yardım masası veya durum sayfası aracını 14 gün denediniz, CNAME'i tanımladınız, denemeyi uzatmadınız.
• Bulut kaynağı silindi. Nesne depolama kovası, statik site barındırma projesi veya uygulama örneği silindi; onu gösteren kayıt kaldı.
• Kampanya bitti. kara-cuma.sirketiniz.com tek seferlik bir etkinlik içindi, etkinlik geçti.
• Personel değişti. Kaydı ekleyen kişi ayrıldı, kaydın ne işe yaradığını kimse bilmiyor, "belki lazım olur" diye duruyor.

Ortak nokta şu: DNS kaydı eklemek dakikalar sürer ve iz bırakmaz; kaydı silmek ise hiçbir sürecin parçası değildir. Alt alan adlarının nasıl çalıştığını bilen bir ekipte bile, kaydın ömrünü takip eden bir mekanizma yoksa bu birikim kaçınılmazdır.

Hangi Kayıt Tipleri Risklidir?#

Konu çoğunlukla CNAME üzerinden konuşulur ama risk sadece orada değildir. Aşağıdaki tablo hangi kayıt tipinin nasıl boşa düştüğünü özetler.

En tehlikeli ikinci sıradaki NS kaydıdır ve en az konuşulanıdır. musteriler.sirketiniz.com gibi bir alt bölgeyi ayrı bir DNS sağlayıcısına devrettiyseniz ve o sağlayıcıdaki zone'u sildiyseniz, delegasyon kaydı hâlâ o sağlayıcının nameserver'larını gösterir. Aynı sağlayıcıda o bölge adını oluşturan biri, aynı nameserver havuzuna düşerse alt bölgenin tamamına — A, MX, TXT dahil — hükmeder. Bu, tek bir web sayfasını değil, o dal altındaki her şeyi kaybetmek demektir.

Ayrıca wildcard DNS kayıtları riski büyütür. *.sirketiniz.com kaydınız paylaşımlı bir platformu gösteriyorsa, saldırganın var olmayan bir kaydı beklemesine bile gerek kalmaz; o platformda herhangibirsey.sirketiniz.com adını talep etmesi yeterlidir.

Markanız Altında Neler Yapılabilir?#

"Zaten kullanmadığımız bir alt alan adı, ne olacak ki?" sorusu bu konudaki en pahalı yanlış değerlendirmedir. Ele geçirilen alt alan adı, ana sitenizin biriktirdiği güvenin tamamını miras alır.

Oltalama sayfaları. Kullanıcı giris.sirketiniz.com adresini gördüğünde alan adının size ait olduğunu bilir, sertifikada kilit simgesini görür ve kimlik bilgilerini girer. Tarayıcı hiçbir uyarı vermez, çünkü teknik olarak ortada sahtecilik yoktur: alan adı gerçekten sizindir, sertifika gerçekten o alan adı içindir. Oltalama saldırılarına karşı kullanıcıya öğretilen "alan adını kontrol et" refleksi burada tam olarak işe yaramaz.

Çerez hırsızlığı. Ana sitenizde çerezleri Domain=.sirketiniz.com kapsamıyla yazıyorsanız, o çerezler tüm alt alan adlarına gönderilir. Ele geçirilen alt alan adına yapılan tek bir istek, oturum çerezini saldırgana taşır. Bu, kimlik doğrulama katmanınızı hiç kırmadan oturum devralmak demektir.

Allowlist'lerin delinmesi. CSP başlığınızda, CORS ayarlarınızda veya OAuth redirect_uri yapılandırmanızda *.sirketiniz.com benzeri joker bir izin varsa, saldırgan artık o listenin içindedir. Uygulamanızın "kendi alan adımızdan gelen istek güvenlidir" varsayımı çöker.

Geçerli HTTPS sertifikası. Saldırgan alt alan adının içeriğini kontrol ettiği için HTTP tabanlı doğrulamayı geçer ve Let's Encrypt ile ücretsiz bir sertifika alır. Sonuç: tarayıcı adres çubuğunda sizin alan adınız ve tam bir kilit simgesi. Bu sertifika Certificate Transparency günlüklerine de düşer — ki bu, aşağıda anlatacağımız gibi sizin lehinize kullanılabilecek tek işarettir.

İtibar ve arama motoru zararı. Ele geçirilen alt alan adı spam, kumar veya zararlı yazılım dağıtımına kullanılırsa, sonuçları alan adınızın tamamı üstlenir: tarayıcı uyarıları, arama sonuçlarından düşme, e-posta gönderimlerinin spam kutusuna gitmesi.

DNS Kayıt Envanterinizi Nasıl Çıkarırsınız?#

Bulamadığınız kaydı koruyamazsınız, o yüzden ilk iş envanterdir. Amacınız "elimizde hangi alt alan adları var" sorusuna eksiksiz cevap vermek.

1. Zone dosyasını dışa aktarın. Çoğu DNS sağlayıcısı zone'u standart metin biçiminde indirmenize izin verir; cPanel/WHM ve Plesk gibi panellerde de bu seçenek vardır. Elinizdeki dosya zone dosyası biçimini izler ve tüm kayıtları tek ekranda görmenizi sağlar. Panelden nasıl erişileceğini bilmiyorsanız DNS kayıtlarının hangi panelden değiştirildiği yazısı yol gösterir.

2. Yalnızca CNAME ve NS satırlarını süzün. İnceleme yükünü hemen üçte birine indirir:

# Dışa aktardığınız zone dosyasından yalnızca ilgili satırları çıkarın
grep -E '[[:space:]](CNAME|NS)[[:space:]]' sirketiniz.com.zone

# Aynı işi bir alt alan adı listesi üzerinden canlı yapmak isterseniz
while read -r host; do
  echo -n "$host -> "
  dig +short CNAME "$host" | head -1
  echo
done < altalanadlari.txt

3. Unuttuğunuz adları Certificate Transparency günlüklerinden toplayın. Herkese açık bir sertifika alınmış her hostname bu günlüklere düşer. Zone dosyanızda görmediğiniz ama günlüklerde beliren bir ad, geçmişte var olmuş ve unutulmuş bir servisin izidir:

# crt.sh üzerinden alan adınıza ait sertifikalardaki tüm isimleri listeleyin
curl -s 'https://crt.sh/?q=%25.sirketiniz.com&output=json' \
  | tr ',' '\n' | grep -o '"name_value":"[^"]*"' \
  | cut -d'"' -f4 | tr '\\n' '\n' | sort -u

4. Sağlayıcı hesaplarınızı da tarayın. DNS tarafını temizlemek yarısıdır; diğer yarısı "hangi bulut hesaplarımızda hâlâ açık kaynak var" sorusudur. Bulut sağlayıcı konsollarında, statik site platformlarında ve SaaS panellerinde tanımlı özel alan adlarını (custom domain) listeleyin. İki listeyi yan yana koyduğunuzda eşleşmeyen her satır incelenecek bir adaydır.

5. Sonucu bir tabloya yazın. Her kayıt için en az dört alan tutun: ad, hedef, sahibi olan ekip/kişi ve beklenen ömrü. Sahibi belirsiz olan kayıt, zaten sahipsiz kayıt adayıdır.

Bir Kaydın Gerçekten Sahipsiz Olduğunu Nasıl Test Edersiniz?#

Envanterde şüpheli adaylar belirdikten sonra sıra doğrulamada. Burada üç farklı durumu birbirinden ayırmanız gerekir: hedef hiç yok, hedef var ama sizin değil, hedef var ve sizin.

Adım 1 — Zincirin ucunu bulun. CNAME'in nereye gittiğini görün:

dig +short CNAME blog.sirketiniz.com
# çıktı: sirketiniz.eskiplatform.io.

Adım 2 — Hedefin kendisi çözümleniyor mu? Bu en net sinyaldir. Hedef hostname NXDOMAIN dönüyorsa, o hostname platformun DNS'inde artık tanımlı değildir:

dig +noall +comment sirketiniz.eskiplatform.io
# status: NXDOMAIN  -> hedef tamamen boşta, yüksek risk
# status: NOERROR   -> hedef çözümleniyor, HTTP cevabına bakın

dig ve nslookup kullanımını tazelemek isterseniz DNS sorgulama araçları yazısına bakabilirsiniz.

Adım 3 — HTTP cevabına bakın. Hedef çözümleniyorsa platform ayaktadır ama hostname talep edilmemiş olabilir. Bu durumda platform kendine özgü bir "bu ad bize tanımlı değil" sayfası döner:

curl -sI https://blog.sirketiniz.com | head -5
curl -s  https://blog.sirketiniz.com | head -20

Aşağıdaki gibi ifadeler, hostname'in havuzda boş beklediğinin göstergesidir:

Adım 4 — Kendi hesabınızı kontrol edin. HTTP cevabı şüpheli görünse bile, ilgili platformdaki hesabınıza girip o hostname'in gerçekten sizde tanımlı olmadığını teyit edin. Çalışan bir servisin geçici bir hata sayfası döndürmesiyle, tamamen boşta bir hostname'i karıştırmak istemezsiniz.

Adım 5 — Aynı testi düzenli aralıklarla tekrarlayın. Bugün sağlıklı olan bir kayıt, üç ay sonra fatura ödenmediği için sahipsiz kalabilir. Basit bir kontrol betiğini haftalık çalıştırmak, elle yapılan yıllık denetimden çok daha etkilidir:

#!/bin/bash
# Sahipsiz CNAME adaylarını bildiren basit kontrol
while read -r host; do
  hedef=$(dig +short CNAME "$host" | head -1)
  [ -z "$hedef" ] && continue
  durum=$(dig +noall +comment "$hedef" | grep -o 'status: [A-Z]*' | head -1)
  case "$durum" in
    *NXDOMAIN*) echo "RISK: $host -> $hedef ($durum)";;
    *) echo "ok  : $host -> $hedef";;
  esac
done < altalanadlari.txt

Sahipsiz Bir Kayıt Bulduğunuzda Ne Yapmalısınız?#

Panik yapmadan, ama beklemeden ilerleyin. Doğru sıra şudur:

1. Kaydı hemen silin. Tartışma, onay süreci ve "belki lazım olur" değerlendirmesi kaydı sildikten sonra yapılır. Kayıt durduğu her saat risk devam eder.
2. Alt alan adına o an ne servis edildiğine bakın. Silmeden önce cevabın ekran görüntüsünü ve HTTP başlıklarını saklayın; kaydın ne kadar süredir ele geçirilmiş olabileceğini anlamak için gerekir.
3. Ele geçirilmişse kapsamı ölçün. O alt alan adı bir çerez kapsamına, CSP/CORS allowlist'ine veya OAuth yönlendirme listesine dahil miydi? Cevap evetse, ilgili oturumları geçersiz kılın ve allowlist'leri daraltın.
4. Certificate Transparency günlüklerini kontrol edin. Sizin almadığınız bir sertifika varsa, o hostname gerçekten başkasının kontrolüne geçmiş demektir. Sertifikanın tarihi, olayın ne zaman başladığını söyler.
5. Kaydı tamamen kaldırın, "park" etmeyin. Silmek yerine kendi sunucunuza yönlendirmek de kabul edilebilir bir çözümdür; ama boş bir platforma bakan kaydı bir başka boş platforma bakacak şekilde değiştirmek hiçbir şey çözmez.
6. Aynı zone'daki diğer kayıtları da gözden geçirin. Bir sahipsiz kayıt bulunduğu yerde genellikle yalnız değildir.

Servis Kapatırken Doğru Sıra: Önce DNS, Sonra Kaynak#

Bu bölüm yazının en kısa ama en değerli kuralını içeriyor. Bir servisi bırakırken çoğu ekip önce sağlayıcıdaki hesabı/kaynağı siler, DNS kaydını "sonra temizleriz" diye bırakır. Bu sıralama, aradaki tüm süre boyunca kaydı savunmasız bırakır.

Doğru sıralama tersidir:

1. Önce DNS kaydını silin ya da kendi sunucunuza yönlendirin.
2. TTL süresi kadar bekleyin ki çözümleyicilerin önbelleğindeki eski cevap dolaşımdan kalksın. Kapatmayı planladığınız bir servisin TTL'ini birkaç gün önceden 300 saniyeye düşürmek bu bekleme süresini kısaltır.
3. Sonra sağlayıcıdaki kaynağı silin veya hesabı kapatın.

Bu üç satır, subdomain takeover vakalarının büyük çoğunluğunu tek başına ortadan kaldırır. Kaydı silmeden kaynağı bırakırsanız, DNS oku bir süre boşluğa bakar; kaynağı silmeden kaydı kaldırırsanız, en kötü ihtimalle bir süre parası ödenen ama kimsenin ulaşamadığı bir hizmetiniz olur. İkinci senaryonun maliyeti çok daha düşüktür.

Tekrarını Önleyen Kalıcı Düzen#

Tek seferlik temizlik iyidir ama aynı birikim bir yıl içinde geri gelir. Kalıcı çözüm birkaç alışkanlıktan oluşur:

Her kaydın bir sahibi olsun. Zone'unuzun yanında, her kaydın hangi ekip için, hangi amaçla ve ne zamana kadar var olacağını yazan bir tablo tutun. Zone dosyası biçimi yorum satırlarını destekler; sahibi doğrudan kaydın yanına yazmak en dayanıklı yöntemdir:

; sahip: pazarlama | amac: 2026 kampanya LP | gecerlilik: 2026-12-31
kampanya   300  IN  CNAME  sirketiniz.landingplatformu.example.

Geçici kayıtlara kısa TTL verin. Kalıcı kayıtlar için 3600 makul; kampanya, deneme ve staging kayıtları için 300 kullanın. Sileceğiniz gün beklemek zorunda kalmazsınız.

Wildcard kaydını paylaşımlı platforma yöneltmeyin. *.sirketiniz.com mecburen gerekiyorsa hedefi kendi kontrolünüzdeki bir sunucu olsun; dış bir SaaS hostname'i olmasın. Wildcard kayıtların davranışını bilmek burada işinize yarar.

Çerezleri alt alan adlarına yaymayın. Oturum çerezlerini Domain niteliği olmadan, yalnızca yazıldığı hosta ait (host-only) yazın. Böylece ele geçirilen bir alt alan adı oturumlara erişemez. Aynı mantıkla CSP, CORS ve OAuth yönlendirme listelerinde joker alt alan adı kullanmayın; adları tek tek yazın.

Certificate Transparency günlüklerini izleyin. Alan adınız için sertifika alındığında haber veren ücretsiz izleme servisleri vardır. Sizin almadığınız bir sertifika bildirimi, bir ele geçirmenin en erken ve en net alarmıdır.

Kapatma kontrol listesine DNS satırı ekleyin. Bir aracı bırakma kararı verildiğinde açılan görev, "hesabı kapat" maddesinin yanına "ilgili DNS kayıtlarını sil" maddesini de içersin. Süreç belgesine yazılmamış bir kural, uygulanmayan bir kuraldır.

Kısacası subdomain takeover, karmaşık bir zafiyet değil, bir muhasebe sorunudur: eklediğinizi kaydettiğiniz ama sildiğinizi kaydetmediğiniz bir defterin doğal sonucu. Envanteri çıkarın, hedefleri test edin, kapatma sırasını doğru kurun; geriye izlemesi kolay, küçük bir bakım işi kalır.

Sıkça Sorulan Sorular#

Kullanmadığım bir alt alan adının CNAME kaydı gerçekten tehlikeli mi?#

Evet. Tehlike alt alan adını kullanıp kullanmamanızdan değil, kaydın hâlâ sizin adınıza bir hedefi işaret etmesinden kaynaklanır. Kayıt durduğu sürece o adres tarayıcıda sizin alan adınız olarak görünür ve markanızın güvenini taşır. Kullanılmıyor olması, aksine, kimsenin fark etmeden aylarca kötüye kullanılabileceği anlamına gelir.

Sahipsiz kaydı silmek yerine kendi sunucuma yönlendirsem yeterli olur mu?#

Yeterlidir, çünkü kritik olan CNAME'in artık kontrol edemediğiniz bir hedefe bakmamasıdır. Kendi sunucunuzda o alt alan adına bir yönlendirme veya sade bir 404 sayfası tanımlarsanız risk ortadan kalkar. Ancak gerçekten ihtiyaç yoksa silmek daha temizdir: envanterde durmayan kayıt, gelecekte yanlışlıkla yeniden kullanılamaz.

Hedefin boşta olduğunu anlamanın en hızlı yolu nedir?#

CNAME'in gösterdiği hostname'i doğrudan sorgulayın. dig çıktısında NXDOMAIN görüyorsanız hedef DNS'te hiç yok demektir ve bu en güçlü işarettir. NOERROR dönüyorsa hedef ayaktadır; bu kez HTTP cevabına bakıp platformun "bu ad tanımlı değil" sayfasını dönüp dönmediğini kontrol etmeniz gerekir.

Cloudflare veya benzeri bir proxy kullanmak beni korur mu?#

Doğrudan korumaz. Proxy, isteği hedefe iletmeden önce sizin ağınızdan geçirir ama hedefin kime ait olduğunu doğrulamaz. Kayıt sahipsizse proxy de saldırganın içeriğini önünüze getirir. Proxy katmanının sağladığı fayda, ele geçirme sonrasında trafiği hızla kesebilmeniz ve tek noktadan kural yazabilmenizdir; kaydı silme ihtiyacını ortadan kaldırmaz.

NS kaydı üzerinden ele geçirme CNAME'e göre neden daha ciddi?#

CNAME ele geçirildiğinde saldırgan yalnızca o tek alt alan adının içeriğini kontrol eder. NS delegasyonu ele geçirildiğinde ise o alt bölgenin tüm kayıt tipleri saldırgana geçer: A, MX, TXT dahil her şeyi tanımlayabilir. Bu, o dal altında e-posta yönlendirmesinden alan adı doğrulama kayıtlarına kadar geniş bir alanı kapsar.

Bu kontrolleri ne sıklıkla yapmalıyım?#

Otomatik bir kontrol betiğini haftalık, elle yapılan kapsamlı envanter incelemesini ise üç ayda bir çalıştırmak dengeli bir tempodur. Buna ek olarak her servis kapatma işleminden sonra ilgili kayıtların gerçekten silindiğini teyit edin; en çok kayıt, tam da bu geçiş anlarında sahipsiz kalıyor.