Subdomain Takeover ve Boşta Kalan DNS Kayıtları: Cloudflare ve cPanel İçin Uygulamalı Rehber

Subdomain takeover, DNS tarafında küçük gibi görünen bir hatanın tüm markayı riske atabildiği, son yılların en kritik web güvenlik açıklarından biri. Özellikle Cloudflare üzerinde DNS yöneten, arka tarafta ise cPanel kullanılan yapılarda; test ortamları, eski kampanya alt alan adları ve kapatılmış üçüncü taraf servisler yüzünden boşta kalan (dangling) DNS kayıtları sıkça karşımıza çıkıyor. Güvenlik denetimleri sırasında DCHost ekibi olarak birçok projede, artık kullanılmayan ama DNS kaydı hâlâ duran subdomain’lerin saldırganlar tarafından ele geçirilebilir durumda olduğunu gördük. Bu makalede, hem Cloudflare hem de cPanel tarafında adım adım ilerleyerek subdomain takeover riskini nasıl tespit edeceğinizi, boşta kalan DNS kayıtlarını nasıl temizleyeceğinizi ve yeni kayıtlar eklerken bu açığı en baştan nasıl engelleyeceğinizi pratik örneklerle anlatacağız. Hedefimiz; ajanslar, yazılım ekipleri ve kurumsal IT birimleri için uygulanabilir, günlük iş akışına entegre edilebilen net bir yol haritası sunmak.

Subdomain takeover nedir ve neden bu kadar tehlikeli?

Subdomain takeover, bir alt alan adının (örnek: kampanya.ornekdomain.com) DNS kaydı hâlâ aktifken, bu subdomain’in yönlendirildiği servis ya da sunucunun artık sizde olmaması nedeniyle saldırganın aynı kaynağı ele geçirip kendi içeriğini yayınlamasıdır. Kısaca, DNS hala işaret ediyor ama arkada kimse yok; boşta kalan kapıya ilk gelen saldırgan taşınıyor.

Bu genellikle şu senaryolarda yaşanır:

• Eski bir test ya da staging alt alan adı için üçüncü taraf bir serviste hesap açılır, proje biter, servis kapatılır ama DNS kaydı kalır.
• Geçici kampanya için ayrı bir uygulama sunucusu kurulur; sunucu silinir, DNS kaydı unutulur.
• Farklı ekipler tarafından yönetilen çoklu domain portföylerinde, kimin hangi subdomain’den sorumlu olduğu belirsizdir ve temizlik asla tam yapılmaz.

Saldırgan, bu boşta kalan subdomain’i ele geçirdiğinde:

• Markanızın alt alanında phishing sayfaları, zararlı kodlar ya da sahte giriş ekranları yayınlayabilir.
• Subdomain’i kullanarak çerez hırsızlığı, oturum çalma gibi gelişmiş saldırılar gerçekleştirebilir.
• SEO manipülasyonu, spam backlink, zararlı dosya barındırma gibi itibar kırıcı eylemler yapabilir.

DNS ve subdomain’lerin temelleri için, henüz okumadıysanız DNS kayıtları hakkında detaylı rehberimizi de mutlaka gözden geçirmenizi öneririz.

Boşta kalan DNS kaydı (dangling record) tam olarak nedir?

Boşta kalan DNS kaydı, DNS tarafında hâlâ görünen fakat işaret ettiği kaynak artık sizde olmayan kayıttır. Bu kavram subdomain takeover’un kalbinde yer alır.

En sık görülen türler:

• CNAME ile üçüncü taraf servise işaret eden kayıtlar
  Örneğin: kampanya.ornekdomain.com → CNAME → ornekkampanya.ucuncutaraf.com
  Üçüncü taraf servisteki ornekkampanya.ucuncutaraf.com hesabınızı sildiğinizde, eğer DNS kaydı duruyorsa, saldırgan aynı serviste bu ismi alıp kontrolü ele geçirebilir.
• A/AAAA kaydı ile silinmiş ya da yeniden tahsis edilmiş IP’lere işaret eden kayıtlar
  Örneğin: beta.ornekdomain.com → A → 198.51.100.42
  Bu IP artık sizin sunucunuz değilse ve başka birine verilmişse, o kişi alt alan adınız üzerinden yayın yapabilir.
• NS kaydı ile delege edilen alt alanlar
  Örneğin: app.ornekdomain.com alt alanının yönetimini farklı bir DNS sağlayıcısına NS kayıtları ile devredersiniz. Oradaki bölge (zone) silinir ama ana DNS’de NS kayıtları kalırsa, saldırgan bu alt alan için yeni bir zone oluşturup kontrolü alabilir.

Boşta kalan kayıtların tespiti, düzenli DNS envanteri çıkarma ve değişikliklerin izlenmesiyle başlar. Çoklu sağlayıcı DNS senaryoları kuruyorsanız, çoklu sağlayıcı DNS rehberimizdeki envanter ve geçiş pratikleri burada da işinize yarar.

Cloudflare tarafında subdomain takeover riskini tespit etme

Cloudflare kullanıyorsanız, DNS yönetim paneli genellikle projenin ortasında açılır ve yıllar içinde onlarca kayıt birikir. İlk adım, mevcut kayıtlarınızı sistematik biçimde gözden geçirmek olmalı.

1. DNS envanteri çıkarma

Cloudflare panelinde ilgili domain için DNS sekmesine gidin ve şu şekilde gruplayın:

• Türüne göre: A, AAAA, CNAME, NS, TXT, MX vb.
• Alt alan adına göre: www, app, beta, test, staging, kampanya, promo, dev, old vb.
• Cloudflare proxy durumu: turuncu bulut (proxy açık) / gri bulut (sadece DNS).

Özellikle şu kalıplar kritik:

• test.*, dev.*, staging.*, beta.*, demo.*
• eski kampanyalar: kampanya2021.*, blackfriday.*, yilbasi.* vb.
• üçüncü taraf CNAME kayıtları: *.ucuncutaraf.com, *.cdnservis.com, *.appservis.net gibi dış hostlara giden kayıtlar.

2. Riskli görünen kayıtları teknik olarak test etme

Her şüpheli kayıt için:

1. Tarayıcıdan doğrudan alt alan adını açın (https ve http ile test edin).
2. Komut satırından aşağıdaki sorguları yapın:
   dig altalan.ornekdomain.com +short
curl -I https://altalan.ornekdomain.com

Şu durumlar kırmızı bayraktır:

• Servis sağlayıcının ‘bu alt alan adı için herhangi bir site bulunamadı’ tarzı özel hata sayfası.
• 404 ya da 5xx dönen ama üst bilgi ve içerik olarak size ait görünmeyen sayfalar.
• Boş, varsayılan bir sayfa; üzerinde sizin logonuz ya da markanız yok.

Özellikle bazı SaaS hizmetleri, kaldırılmış alt alanlar için bile özel hata sayfası döndürür ve bu durum ele geçirilebilir anlamına gelir. Böyle bir kayıt bulduğunuzda, önce gerçekten hâlâ kullanılıyor mu sorusuna içeride yanıt bulmalı, sonra da ya güvenli hâle getirmeli ya da tamamen silmelisiniz.

3. Kullanılmayan kayıtları güvenle temizleme

Her riskli kayıt için şu adımları izleyin:

1. İlgili alt alanı kullanan uygulama, kampanya ya da entegrasyon gerçekten kapanmış mı; proje sahiplerinden teyit alın.
2. Subdomain SEO açısından önemli bir geçmişe sahipse, tamamen silmek yerine ana siteye 301 yönlendirme yapmak isteyebilirsiniz (Bunu genellikle web sunucusu ya da uygulama seviyesinde yaparsınız; DNS tarafında sadece işaret ettiği IP’yi güncellersiniz).
3. Kesinlikle artık kullanılmayacağına emin olduğunuz kaydı Cloudflare DNS ekranından tamamen silin.

DNS değişikliklerinin yayılımı konusunda daha net olmak için DNS yayılım süresi rehberimizdeki TTL ve önbellekleme anlatımına da göz atabilirsiniz.

4. Yeni kayıt eklerken güvenlik prensipleri

İleride aynı sorunların tekrar etmemesi için Cloudflare üzerinde yeni subdomain açarken şu prensipleri uygulayın:

• Proje ömrü kısa ise (kampanya, etkinlik vb.), bitiş tarihini not alın ve takvime temizlik görevi ekleyin.
• Üçüncü taraf servise CNAME veriyorsanız, bu servisten ayrılma planı yaparken mutlaka DNS tarafında temizlik görevi de ekleyin.
• Her yeni subdomain için bir ‘sahip ekip’ belirleyin (örneğin Pazarlama, Yazılım, Dış ajans X) ve bu bilgiyi dokümante edin.
• Cloudflare’de mümkün olduğunca açıklayıcı notlar kullanın; DNS kaydının ne için açıldığını kısa da olsa yazmanız, yıllar sonra büyük fark yaratır.

cPanel tarafında subdomain ve DNS yönetimi: En sık yapılan hatalar

Cloudflare’de DNS yönetip, arka tarafta cPanel hosting kullanmak çok yaygın. Ancak cPanel üzerinde subdomain ve addon domain yönetimi doğru yapılmadığında, hem güvenlik açıkları hem de karmaşa oluşabiliyor.

1. cPanel’de subdomain oluşturma ve kaldırma mantığı

cPanel’de bir subdomain oluşturduğunuzda, genellikle iki şey olur:

• Sunucu tarafında ilgili klasör oluşturulur (örnek: public_html/kampanya).
• cPanel DNS zone’unda bu subdomain için A kaydı eklenir.

Eğer Cloudflare kullanıyorsanız, çoğu senaryoda nameserver’lar Cloudflare’e işaret ettiği için, cPanel’deki DNS kaydı internete yansımaz. Bu durumda Cloudflare ile cPanel DNS kayıtlarınızın senkron olmayabileceğini bilmeniz çok önemli. Bunu detaylı ele aldığımız Cloudflare DNS mi, hosting DNS’i mi rehberimiz, mimari tercihi yaparken size iyi bir çerçeve sunar.

2. cPanel’de alt alanı silip Cloudflare’de DNS kaydını unutmak

En sık gördüğümüz hata şu:

1. cPanel’den subdomain silinir, dosyalar kaldırılır.
2. Cloudflare DNS panelinde aynı subdomain için CNAME veya A kaydı kalır.
3. Arkada artık size ait olmayan bir IP ya da servis olduğu için subdomain takeover riski doğar.

Bu nedenle; cPanel’de bir subdomain veya addon domain kaldırdığınız anda, Cloudflare DNS’te karşılığını kontrol etmek için bir operasyon adımı tanımlayın. Bunu iç süreçlerinizin bir parçası hâline getirmek, riski dramatik şekilde düşürür.

3. cPanel güvenliği ve yetki ayrımı

Subdomain takeover sadece DNS’ten ibaret değil; aynı zamanda panel erişimi ve yetkilerle de ilgili. cPanel tarafında aşağıdaki önerileri uygularsanız, genel yüzey alanınızı da daraltırsınız:

• Her müşteri siteyi ayrı cPanel hesabında tutun; addon domain kalabalığı yerine izolasyonu tercih edin.
• Gereksiz FTP hesaplarını, eski SSH erişimlerini ve kullanılmayan e-posta kutularını temizleyin.
• Güvenlik sertleştirmesi için cPanel güvenlik sertleştirme kontrol listemizdeki adımları uygulayın.

Ajanslar, freelancer’lar ve çoklu domain portföyü için pratik süreçler

Birden fazla müşterinin DNS ve hosting’ini yöneten ajanslar için subdomain takeover riski katlanarak artar. Zaman içinde kullanılan SaaS hizmetleri, kampanya siteleri ve A/B test subdomain’leri unutulmaya çok müsaittir.

1. Ortak bir DNS envanter tablosu tutun

Her alan adı için en az şu sütunları içeren paylaşımlı bir tablo oluşturun:

• Alan adı
• Subdomain (örnek: beta.musteri.com)
• DNS türü (A, CNAME, NS vb.)
• İşaret ettiği hedef (IP ya da host)
• Sahip ekip (Pazarlama, Yazılım, Dış ajans)
• Açılış tarihi ve planlanan kapanış tarihi

Bu tabloyu yeni her kampanyada güncellemek, sonradan temizlik yaparken hayat kurtarır.

2. Yıllık ya da altı aylık DNS temizlik sprint’leri planlayın

Proje yoğunluğunda DNS temizlik işleri her zaman ertelenir. Bu yüzden, ajans takviminize yılda en az bir kez, ideal olarak altı ayda bir DNS temizlik sprint’i ekleyin. Bu sprint’te:

• Eski kampanya domain ve subdomain’lerini gözden geçirin.
• Üçüncü taraf servislerden ayrılmış mısınız, kontrol edin.
• Artık anlam ifade etmeyen subdomain’leri kapatın veya ana siteye yönlendirin.

Birden fazla alan adı ve DNS erişimini yönetirken, genel yaklaşımı ajanslar için DNS ve alan adı erişimi yönetimi rehberimizde ayrıntılı anlattık; bu yazıyla birlikte okumanız bütün resmi tamamlamanıza yardımcı olur.

3. Müşteriye raporlama: Bulduğunuz riskleri görünür kılın

Subdomain takeover risklerini tespit ettiğinizde, bunu müşteriye sadece teknik bir not olarak değil, somut etkileriyle anlatın:

• Marka itibar riski (phishing, zararlı yazılım barındırma vb.).
• SEO ve organik trafik zararları.
• Hukuki ve KVKK/GDPR kapsamında doğabilecek yükümlülükler.

Böylece, DNS güvenliği için zaman ve bütçe ayırmanın neden gerekli olduğunu daha kolay kabul ettirebilirsiniz.

Cloudflare güvenlik özelliklerini subdomain takeover ile birlikte düşünmek

Cloudflare sadece DNS için değil, aynı zamanda WAF, oran sınırlama, mTLS ve origin doğrulama gibi gelişmiş güvenlik özellikleri için de güçlü bir platform. Subdomain takeover riskini azaltmak için şu stratejileri de göz önüne alın:

1. Origin’i gerçekten korumak

Alt alanlarınız Cloudflare arkasında ise, sadece DNS takeover değil, aynı zamanda kaynak sunucunun kimliğini doğrulama konusu da önem kazanır. Özellikle kritik uygulamalar için authenticated origin pulls ve mTLS kullanarak, yalnızca Cloudflare’den gelen trafiği kabul etmeniz çok güçlü bir ek katman sağlar.

2. Yönetim panellerini ve hassas alt alanları ek katmanlarla kapatmak

Cloudflare Access, IP kısıtlamaları ve ek kimlik doğrulama katmanları ile yönetim panellerinizi korurken, sunucu tarafında da mTLS ile erişimi kısıtlamanız mümkündür. Yönetim panellerini Nginx tarafında istemci sertifikaları ile kapatmak için yönetim panellerini mTLS ile koruma rehberimizi inceleyebilirsiniz.

3. Cloudflare Tunnel ve özel ağ senaryoları

Bazı durumlarda, internete doğrudan açık bir IP yerine, sadece Cloudflare Tunnel üzerinden erişilen servisler kurmak isteyebilirsiniz. Böyle bir mimaride bile, yanlış yapılandırılmış DNS kayıtları yüzünden subdomain takeover riskleri oluşabilir. Bu nedenle Tunnel ile çalışırken bile DNS envanterinizi disiplinli yönetmek şart. Cloudflare Tunnel kullanımını, kapalı portlarla yayın mantığını anlattığımız port açmadan yayın rehberi ile birlikte değerlendirmenizi öneririz.

DCHost altyapısında pratik öneriler: Domain, hosting, VPS ve dedicated sunucu tarafı

DCHost olarak, müşterilerimizin domain, hosting, VPS, dedicated sunucu ve colocation altyapılarını tasarlarken DNS güvenliğini işin en başına koyuyoruz. Subdomain takeover’ı önlemek için siz de altyapınızı planlarken şu maddeleri referans alabilirsiniz:

• Yeni projede mimari planlama: Domain ve subdomain hiyerarşisini proje başında tasarlayın; hangi alt alan hangi sunucuya gidecek, kim yönetecek, netleştirin.
• VPS ya da dedicated sunucu kullanırken aynı sunucuya onlarca test subdomain’i yığmak yerine, ömrü kısa olan projeler için ayrı ortamlar ve temizleme takvimi planlayın.
• Colocation ortamlarında kendi DNS’inizi yönetiyorsanız, zone dosyalarınıza dönemsel otomatik testler eklemeyi düşünün (örneğin cron ile çalışan küçük bir kontrol aracı).
• DNSSEC, CAA kayıtları, güvenli SSL/TLS konularında da projenin başında standartlar belirleyin; bu konuları derinlemesine anlattığımız DNSSEC rehberi ve CAA kayıtları yazısı iyi başlangıç noktalarıdır.

Adım adım kontrol listesi: Subdomain takeover ve boşta kalan DNS kayıtlarını önlemek

Son bölümde, hem Cloudflare hem de cPanel kullanan yapılar için uygulanabilir bir kontrol listesi bırakalım. Bunu kendi iç dokümantasyonunuza kolayca uyarlayabilirsiniz.

1. Mevcut durumu analiz et

• Tüm alan adlarının Cloudflare DNS kayıtlarını dışa aktar ya da ekran üzerinden listele.
• Özellikle CNAME, A, AAAA ve NS kayıtlarını ayrı bir tabloda grupla.
• test, dev, staging, beta, promo, kampanya gibi alt alanları işaretle.

2. Riskli kayıtları bul

• Her şüpheli subdomain’i tarayıcı ve komut satırından test et (dig, curl vb.).
• Üçüncü taraf servis hata sayfaları veya size ait olmayan varsayılan sayfalar tespit et.
• Silinmiş ya da sana ait olmayan IP’lere işaret eden A/AAAA kayıtlarını belirle.

3. Temizle ve konsolide et

• Artık kullanılmayan kayıtları ilgili ekiplerden onay alarak sil.
• Gerekiyorsa bazı alt alanları ana siteye 301 yönlendirme ile konsolide et.
• cPanel ve Cloudflare DNS kayıtlarını mümkün olduğunca senkron tut.

4. Süreç ve otomasyon kur

• Yeni subdomain açarken bir sahip ekip ve planlanan kapanış tarihi belirle.
• Yıllık ya da altı aylık DNS temizlik sprint’leri takvime ekle.
• VPS ya da dedicated sunucularda, log ve izleme sistemlerine DNS değişikliklerini de dahil et (örneğin değişiklik olduğunda e-posta bildirimi).

5. Güvenliği bütünsel düşün

• Subdomain takeover, web güvenliği tablosunun tek parçası; WAF, TLS, HTTP güvenlik başlıkları, zayıf parolalar gibi diğer riskleri de birlikte ele al.
• Genel güvenlik yaklaşımınızı güçlendirmek için hosting sektöründe siber güvenlik tehditleri ve VPS sunucu güvenliği rehberlerimizi inceleyin.

Son söz: Küçük bir DNS kaydı, büyük bir güvenlik açığına dönüşmesin

Subdomain takeover, çoğu ekip için ancak bir güvenlik denetiminde veya kötü bir olay yaşandıktan sonra gündeme gelen bir konu. Oysa bu risk, düzenli DNS envanteri, basit temizlik süreçleri ve Cloudflare–cPanel ikilisini disiplinli kullanmakla büyük ölçüde kontrol altına alınabiliyor. DCHost olarak pratikte gördüğümüz en büyük fark, teknik karmaşıklıktan değil, süreç eksikliğinden kaynaklanıyor: Kimin hangi subdomain’den sorumlu olduğu belirsizse, kimse gereksiz DNS kaydı silmeye cesaret edemiyor. Bu makaledeki kontrol listesini ekibinizle paylaşın, ilk etapta en görünür riskleri temizleyin ve ardından düzenli temizlik sprint’leri planlayın. Domain, hosting, VPS, dedicated sunucu ya da colocation altyapınızı tasarlarken DNS güvenliğini mimarinin ayrılmaz bir parçası hâline getirirseniz, subdomain takeover sizin için teoride kalır. DCHost ekibi olarak, altyapınızı planlarken ve gözden geçirirken bu tür konularda yanınızda olmaya devam edeceğiz.