Cloudflare'e Nasıl Geçilir? DNS Kayıtları Neden Kaybolur?

Cloudflare'e geçiş, nameserver'ları değiştirip alan adınızın DNS yönetimini devretmekten ibarettir. Riskli olan kısım geçişin kendisi değil, Cloudflare'in eski sağlayıcınızdaki kayıtları otomatik tararken bazılarını bulamaması — ve sizin elinizde karşılaştıracak tam bir liste olmaması.

Bizde tam olarak bu oldu. Ana site açılıyordu, ama yonetim.algoritmaajans.com — müşteri ve kasa kayıtlarını tutan iç yönetim panelimiz — DNS'te hiç yoktu.

Daha kötüsü: sorun ilk yarım saat boyunca fark edilmedi.

Neden hemen fark edilmiyor

Nameserver değişikliği yayılırken eski kayıt hâlâ çözümleyicilerin önbelleğinde durur. Siz tarayıcıdan panele girmeye devam edersiniz, her şey normal görünür.

Bizim ilk kontrolümüz şuydu:

dig +short A yonetim.algoritmaajans.com
# — KAYIT YOK

curl -s -o /dev/null -w '%{http_code}' https://yonetim.algoritmaajans.com
# 307

Otoriter cevap "kayıt yok" diyordu ama site hâlâ açılıyordu. Çünkü bilgisayarımızın çözümleyicisi eski kaydı önbellekte tutuyordu.

Önbellek süresi dolduğunda panel erişilemez hale gelecekti — ve o an gece yarısı da olabilirdi, müşteri ararken de.

Bu gecikmenin süresini belirleyen şey eski kaydınızın TTL değeri. TTL (Time To Live), bir DNS kaydının çözümleyicilerde kaç saniye saklanacağını söyler. Paylaşımlı hosting'lerde varsayılan genelde 14400 (4 saat), bazen 86400 (24 saat). Yani en kötü ihtimalle bir gün boyunca "her şey yolunda" görürsünüz.

Mevcut TTL'nizi görmek için +noall +answer kullanın — +short TTL'yi göstermez:

dig alanadiniz.com A +noall +answer
# alanadiniz.com.  14400  IN  A  192.0.2.10
#                  ^^^^^ TTL

Geçişten en az bir gün önce TTL'yi 300'e indirin. Böylece bir sorun çıktığında geri dönüş beş dakikada yayılır, dört saatte değil. Bu tek hazırlık adımı, geçişin en stresli kısmını ortadan kaldırıyor.

Kök sebep: içe aktarma eksik yapar

Cloudflare, bir alan adını eklediğinizde mevcut DNS kayıtlarını otomatik taramaya çalışır. Bu tarama tam değildir ve Cloudflare bunu belgelerinde açıkça söyler.

Neden eksik kalır:

• Tarama, bilinen kayıt adlarını dener; sizin özel bir subdomain'iniz varsa (panel, crm, staging, api) tahmin edemez.
• Eski sağlayıcıda zone transfer kapalıysa (paylaşımlı hosting'de genelde kapalıdır) Cloudflare kayıtları tek tek deneyerek bulmaya çalışır.
• CNAME zincirleri, MX ve TXT kayıtları sıklıkla atlanır.
• DKIM kayıtları neredeyse hiç bulunamaz, çünkü adları tahmin edilemez: secim1._domainkey.alanadiniz.com gibi, ve seçici adı posta sağlayıcınıza göre değişir.

Bizim durumumuzda www kaydı da düşmüştü — o Hostinger'ın CDN'ine CNAME'di.

Geçişten önce yapılması gereken tek şey

Mevcut kayıtların tam listesini alın ve bir yere yazın. Nameserver'ları değiştirdikten sonra eski sağlayıcının DNS panelinde ne olduğunu göremezsiniz — hangi kaydın kaybolduğunu anlamanın yolu kalmaz.

Eski sağlayıcının panelinde "DNS bölgesini dışa aktar" seçeneği varsa kullanın; çıkan zone dosyası en güvenilir kaynaktır. Yoksa elle sorgulayın:

D=alanadiniz.com
for tip in A AAAA CNAME MX TXT NS SRV CAA SOA; do
  echo "── $tip"
  dig +short $tip $D
done

Subdomain'ler için — bunları sorgulamadan bilemezsiniz, listeyi kendiniz çıkarmalısınız:

for alt in www mail ftp panel yonetim crm api staging test blog shop \
           webmail cpanel autodiscover autoconfig vpn dev demo; do
  cevap=$(dig +short A $alt.$D)
  [ -n "$cevap" ] && echo "$alt.$D → $cevap"
done

Posta doğrulama kayıtları ayrı bir tur ister, çünkü onlar özel adlarda durur:

dig +short TXT $D                        # SPF burada
dig +short TXT _dmarc.$D                 # DMARC
for s in default google selector1 selector2 secim1 k1 mail; do
  dig +short TXT $s._domainkey.$D | head -1
done

Son döngü DKIM seçicilerini tahmin etmeye çalışıyor. Seçici adınızı bilmiyorsanız kendinize bir mail atın ve gelen postanın kaynağındaki DKIM-Signature satırındaki s= değerine bakın — orada yazar.

Hangi subdomain'lerinizin olduğunu hatırlamıyorsanız hosting panelinizdeki site listesine bakın. Bizim üç subdomain'imiz vardı ve ikisinin DNS kaydı zaten yoktu — geçişte kaybolan sadece bir tanesiydi ama o tanesi en kritiğiydi.

Çıkardığınız listeyi bir dosyaya yazın ve geçiş bitene kadar silmeyin:

{ for tip in A AAAA CNAME MX TXT NS CAA; do
    echo "## $tip"; dig +noall +answer $tip $D
  done; } > dns-yedek-$(date +%F).txt

Nameserver değişimi adım adım

Sıra karışırsa kesinti yaşarsınız. Doğru sıralama şu:

1. Cloudflare'e alan adını ekleyin, ama nameserver'ı henüz değiştirmeyin. Cloudflare taramayı yapar ve size bulduğu kayıtları gösterir. Bu ekran, hazırladığınız listeyle karşılaştıracağınız yerdir.

2. Eksikleri elle ekleyin. Listenizde olup ekranda olmayan her kaydı girin. Bu adımı geçişten önce yapmak, sonra yapmaktan çok daha ucuz: nameserver hâlâ eski sağlayıcıda olduğu için hiçbir hata yayına çıkmaz.

3. Kayıtları gri buluta alın. Cloudflare bazı kayıtları varsayılan olarak turuncu ekler. Hepsini gri yapın; turuncuya çevirmek son adım.

4. Nameserver'ları kayıt firmanızın panelinden değiştirin. Bu, alan adını satın aldığınız yerde yapılır — Cloudflare'de değil. Türkiye'de .com.tr uzantısı kullanıyorsanız değişiklik nic.tr üzerinden gider ve onay süreci daha uzun sürebilir.

5. Bekleyin ve doğrulayın. dig +short NS Cloudflare'i dönene kadar başka bir şey yapmayın.

6. Kayıtları tek tek karşılaştırın. Yukarıdaki doğrulama komutlarını çalıştırın.

7. Sertifikayı kurun, HTTPS'i doğrulayın, sonra turuncuya geçin.

İkinci adımı atlayıp "sonra hallederim" derseniz, eksik kayıtları canlı bir sitede aramaya başlarsınız. Aradaki fark, sorunu ziyaretçilerin mi yoksa sizin mi bulacağınız.

Geçişten sonra doğrulama

Nameserver değişikliği yayıldıktan sonra listeyi tek tek karşılaştırın:

for alt in "" www. yonetim. mail.; do
  echo "$alt$D → $(dig +short A $alt$D @1.1.1.1 | tr '\n' ' ')"
done

Genel bir çözümleyiciye sorun (@1.1.1.1 ya da @8.8.8.8), kendi bilgisayarınızın çözümleyicisine değil. Kendi çözümleyiciniz eski kaydı önbellekte tutuyor olabilir ve size yanlış güven verir.

Bu bizim başımıza geldi: ISS'imizin çözümleyicisi saatlerce eski IP'yi döndürdü. Tarayıcıda eski sunucuyu görürken 1.1.1.1 yeni sunucuyu gösteriyordu. İki farklı gerçeklik.

Nameserver'ın gerçekten değiştiğini de doğrulayın — bu, geçişin tamamlandığının tek kesin göstergesi:

dig +short NS $D
# beklenen: ...ns.cloudflare.com çiftiniz

Eski nameserver'lar hâlâ dönüyorsa geçiş henüz yayılmamıştır; kayıt eksikliği aramaya başlamadan önce bunu bekleyin. Yayılma tipik olarak birkaç saat sürer, alan adı uzantısına göre 24-48 saati bulabilir.

Proxy bulutu: turuncu mu gri mi

Cloudflare'de her kaydın yanında bir bulut ikonu vardır. Turuncu = proxy açık, trafik Cloudflare üzerinden geçer. Gri = yalnızca DNS.

Yeni kurulumda gri ile başlayın. Sebebi şu: proxy açıkken Cloudflare sunucunuza HTTPS ile bağlanmaya çalışır. Sunucunuzda henüz sertifika yoksa site tamamen erişilemez olur — ve hata mesajı Cloudflare'den geldiği için sunucunuzda sorun ararsınız.

Bizde tam bu oldu. Site boş yanıt dönüyordu, HTTP durum satırı bile yoktu. Sunucu doğrudan sorulduğunda 200 veriyordu. Sebep basitti: nginx yalnızca 80 portunu dinliyordu, 443 kapalıydı.

Sıralama şöyle olmalı:

1. Kayıtları gri bulutla ekleyin
2. DNS'in yayılmasını bekleyin
3. Sunucuda Let's Encrypt sertifikasını kurun
4. HTTPS'in çalıştığını doğrulayın
5. Ancak o zaman proxy'yi turuncuya çevirin ve Cloudflare'de SSL modunu Full (strict) yapın

Adım 3'te bir tuzak var: proxy açıkken Let's Encrypt'in HTTP-01 doğrulaması Cloudflare'e takılabilir. Sertifikayı proxy kapalıyken alın, sonra açın.

SSL modlarının ne yaptığı sık karıştırılıyor:

Mod	Ziyaretçi → Cloudflare	Cloudflare → Sunucu	Ne zaman
Off	Şifresiz	Şifresiz	Asla
Flexible	Şifreli	Şifresiz	Asla — kilit simgesi yalan söyler
Full	Şifreli	Şifreli, sertifika doğrulanmaz	Geçici
Full (strict)	Şifreli	Şifreli, sertifika doğrulanır	Doğru ayar

"Flexible" modu, ziyaretçiye kilit simgesi gösterirken Cloudflare ile sunucunuz arasındaki trafiği şifresiz akıtır. Sertifikanız yokken siteyi ayakta tutmanın kolay yolu gibi görünür; kalıcı hale gelirse güvenlik açığıdır. Sertifikayı kurup Full (strict)'e geçin.

Cloudflare'e geçtikten sonra ilk ayarlar

Panel açıldığında karşınıza onlarca ayar çıkar. Yeni bir kurulumda gerçekten önemli olan beş tanesi var.

Always Use HTTPS. HTTP isteklerini HTTPS'e yönlendirir. Sunucu tarafında da yönlendirme varsa çift yönlendirme oluşmadığından emin olun — curl -sIL ile zincirin kaç adım olduğuna bakın. İki adımdan fazlaysa bir yerde fazlalık var.

Minimum TLS Version. 1.2'ye çekin. 1.0 ve 1.1 artık güvenli sayılmıyor.

Auto Minify ve Rocket Loader. Bunları kapalı tutun. Modern framework'lerin çıktısını yeniden işlemek, çözdüğünden çok sorun çıkarır; JavaScript sıralamasını bozduğu için sayfanın bir kısmının hiç çalışmaması gibi teşhisi zor arızalara yol açar.

Browser Cache TTL ve Caching Level. Varsayılanla başlayın. Önbellek başlıklarını uygulamanızdan yönetmek, Cloudflare panelinden yönetmekten daha öngörülebilir — iki yerden birden yönetirseniz hangisinin kazandığını bulmak için saatler harcarsınız.

Development Mode. Dağıtım yaparken üç saatliğine açın; Cloudflare önbelleği tamamen baypas eder ve değişikliğinizi anında görürsünüz. Kapatmayı unutmayın, kendiliğinden de kapanıyor.

Bir de yapmamanız gereken bir şey: "Under Attack" modunu sürekli açık bırakmak. Her ziyaretçiye tarayıcı doğrulaması gösterir ve arama motoru botlarını da engelleyebilir. Gerçekten saldırı altındayken açılır, sonra kapatılır.

Posta kayıtlarını unutmayın

Web sitesi çalışıyor diye geçiş tamamlanmış sayılmaz. MX ve SPF kayıtları taşınmadıysa:

• Size gelen postalar hiçbir yere ulaşmaz
• Sizin gönderdikleriniz SPF doğrulaması yapamadığı için spam'e düşer

İkisi de sessiz arızadır. Kimse size "mailiniz gelmiyor" demez, sadece cevap alamazsınız.

dig +short MX $D
dig +short TXT $D | grep spf
dig +short TXT _dmarc.$D

Üçü de boş dönüyorsa posta akışınız kopmuş demektir.

Bir kritik kural daha: posta kayıtları proxy'lenemez. MX kaydı zaten proxy edilemez, ama mail.alanadiniz.com gibi bir A kaydını turuncu bulutla eklerseniz posta sunucunuzun gerçek IP'si gizlenir ve posta trafiği kesilir. Cloudflare HTTP/HTTPS proxy'sidir; SMTP, IMAP ve POP3 oradan geçmez.

Posta ile ilgili her kayıt gri bulut olmalı: mail, smtp, imap, webmail, autodiscover, autoconfig.

Sık yapılan beş hata

1. Nameserver'ı değiştirmeden önce liste çıkarmamak. Yazının tamamı bu maddenin etrafında dönüyor.

2. TTL'yi indirmeyi atlamak. Sorun çıktığında geri dönüş dört saat sürer.

3. Posta kayıtlarını turuncu bulutla eklemek. Posta akışı sessizce kesilir.

4. Sertifika hazır olmadan proxy'yi açmak. Site tamamen erişilemez olur ve hatayı sunucuda ararsınız.

5. Cloudflare'in kendi önbelleğini hesaba katmamak. Proxy açıldıktan sonra Cloudflare statik dosyaları önbelleğe alır. Dağıtım yaptığınızda eski dosyaları sunmaya devam edebilir — bu, CDN önbelleği yazısında anlattığımız sorunun aynısı, sadece farklı bir CDN'de.

Geri dönüş planı

Bir şey ters giderse geri dönüş yolu şudur: alan adı kayıt firmanızın panelinden nameserver'ları eski değerlerine çevirin. Eski sağlayıcıdaki bölge kaydı silinmediyse dakikalar içinde eski haline döner.

Bu yüzden eski hosting hesabını geçişten hemen sonra kapatmayın. Bölge kaydı orada durduğu sürece geri dönüş ücretsiz ve hızlıdır. Birkaç gün bekleyin, her şeyin oturduğundan emin olun, sonra kapatın.

Aynı ilke sunucu taşımasında da geçerli — kesintisiz geçişin adımlarını paylaşımlı hosting yazısının sonunda sıraladık.

Cloudflare geçişi neyi çözer, neyi çözmez

Dürüst bir liste, çünkü beklenti yönetimi bu işin yarısı.

Çözer: DNS yönetimini tek panele toplar, TTL kontrolünü size verir, ücretsiz SSL sunar, statik dosyaları kenar düğümlerden dağıtır, temel DDoS koruması sağlar, kayıt değişikliklerini saniyeler içinde yayar.

Çözmez: Yavaş bir sunucuyu hızlandırmaz — dinamik sayfalar hâlâ sizin sunucunuzdan üretilir. Kötü yazılmış bir uygulamayı kurtarmaz. Yanlış yapılandırılmış önbellek başlıklarını düzeltmez, aksine sorunu büyütür. Ve güvenlik duvarı yerine geçmez; sunucunuz hâlâ doğrudan IP üzerinden taranıyor olabilir.

Son madde önemli: proxy açtığınızda ziyaretçiler gerçek IP'nizi görmez, ama IP'niz zaten bilinen bir kayıttaysa (geçişten önceki DNS geçmişi) saldırgan Cloudflare'i baypas edebilir. Sunucu tarafında güvenlik duvarını daraltmak hâlâ gerekli — yeni sunucu güvenliği yazısında ilk saatte 54 SSH denemesi almamızın sebebi tam olarak buydu.

Kaybolan panel: hikayenin sonu

Baştaki yonetim.algoritmaajans.com kaydını elle ekledik ve gri bulutta bıraktık. Ama olay bize ikinci bir soruyu sordurdu: bu panelin DNS'te herkese açık bir A kaydı olarak durması doğru mu?

Cevap "şart değil". İç kullanıma açık bir yönetim arayüzü için üç seçenek var:

Kayıt dursun, erişim kısıtlansın. DNS'te görünür kalır ama sunucu tarafında yalnızca belirli IP'lerden erişime izin verirsiniz. En basit yol, en az bakım isteyen yol.

Cloudflare Access ile kimlik doğrulaması koyun. Uygulamanın kendi giriş ekranından önce bir katman daha ekler. Ücretsiz planda küçük ekipler için yeterli kullanıcı hakkı var.

Tamamen kapatın, VPN üzerinden erişin. En güvenli, en zahmetli.

Biz birinciyi seçtik, çünkü panel zaten kimlik doğrulaması istiyordu ve ek bir katman operasyonu yavaşlatacaktı. Ama bu tercih işletmeye göre değişir: içinde kasa ve müşteri kaydı tutan bir panel için ikincisi de fazla değil.

Alınacak asıl ders şu: DNS geçişi bir envanter çalışmasıdır. Kaybolan kayıtları ararken elinizde uzun zamandır bakmadığınız bir liste oluşur — ve o listedeki bazı satırların orada durmaması gerektiğini o an fark edersiniz.

Geçiş kontrol listesi

Öncesinde:

• Tüm DNS kayıtları bir dosyaya yazıldı (A, AAAA, CNAME, MX, TXT, CAA, SRV)
• Subdomain listesi hosting panelinden doğrulandı
• SPF, DKIM ve DMARC kayıtları ayrıca not edildi
• TTL değerleri 300'e indirildi ve eski TTL kadar beklendi

Sonrasında:

• dig +short NS Cloudflare nameserver'larını dönüyor
• Her kayıt @1.1.1.1 üzerinden tek tek doğrulandı
• Posta kayıtları gri bulutta
• Kendinize test maili gönderildi ve ulaştı
• SSL modu Full (strict)
• Eski hosting hesabı hâlâ açık

Özet

Cloudflare'e geçmek beş dakikalık bir iş gibi görünür. Riskli olan kısım DNS değil, elinizde eksik bir liste olması.

Geçmeden önce mevcut kayıtların tamamını yazın, TTL'yi indirin. Geçtikten sonra genel bir çözümleyiciyle tek tek doğrulayın. Sertifikanız hazır olmadan proxy'yi açmayın, posta kayıtlarına dokunmayın.

Bu tür altyapı işlerinin bir web projesinin bütçesinde nereye düştüğünü merak ediyorsanız web sitesi fiyatları yazısında kalemleri ayırdık. Kesintinin doğrudan ciroya yansıdığı bir e-ticaret kurulumundaysanız e-ticaret sitesi nasıl kurulur yazısı taşıma öncesi okunacak listeyi de içeriyor.