HTTP'den HTTPS'e Geçişte DNS Değişiklikleri Kontrol Listesi

HTTPS'e geçiş, çoğu zaman yalnızca bir sertifika kurmaktan ibaret gibi görünür; oysa doğru sırayla yapılmayan DNS değişiklikleri, sitenizi birkaç saatliğine veya birkaç güne kadar erişilemez kılabilir. Hangi kaydın önce güncellenmesi, hangisinin son adıma bırakılması gerektiği - bu sıralama, geçişin sorunsuz geçip geçmeyeceğini belirler.

Bir domain'in HTTPS'e taşınması sırasında en az dört farklı DNS kaydı devreye girer: A veya CNAME (sunucu yönlendirmesi), CAA (sertifika yetkisi kısıtlaması), TXT (doğrulama veya SPF), MX (e-posta). Bu kayıtların her biri ayrı TTL değerlerine sahip olabilir ve propagation (yayılma) süreleri birbirinden farklı davranır. Değişiklikleri rastgele sırayla yapmak, bir kayıt yayılırken diğerinin eski değerde kalmasına yol açar.

Aşağıdaki kontrol listesi, geçiş öncesinde, geçiş sırasında ve geçiş sonrasında yapılması gerekenleri sıraya koyar. Her adım bağımsız değil; bir önceki tamamlanmadan sonraki yapılmamalı.

Geçiş Öncesi: TTL Değerlerini Düşürün

TTL (Time to Live), DNS çözümleyicilerinin bir kaydı önbellekte ne kadar süre sakladığını belirler. Değişiklik yapmadan 24-48 saat önce tüm ilgili kayıtların TTL'ini 300 saniyeye (5 dakika) indirmek, olası bir geri dönüşte bekleme süresini minimuma çeker.

Hangi kayıtların TTL'i düşürülmeli? A kaydı, CNAME kaydı, varsa CAA kaydı. MX ve SPF kayıtlarına dokunmak gerekmez; bunlar geçişten etkilenmez. Nameserver kayıtlarının (NS) TTL'i panelden değiştirilmez - registrar seviyesinde yönetilir ve bağımsız çalışır.

TTL düşürme adımını atlamak hemen fark edilmez. Sorun geçiş sonrasında ortaya çıkar: eski değerler önbellekte kaldığı sürece bazı kullanıcılar eski sunucuya ulaşmaya devam eder ve önbellekteki süre dolana kadar sertifika uyuşmazlığı ya da "Bağlantı güvenli değil" uyarısı alabilirler. TTL'i geçiş tamamlandıktan 24-48 saat sonra 3600 saniyeye geri yükseltmeyi de listeye ekleyin.

CAA Kaydı: Hangi Sertifika Yetkilisini Kullanacaksınız?

CAA (Certification Authority Authorization) kaydı, domain için sertifika verebilecek yetkilileri kısıtlar. Bu kayıt yoksa herhangi bir sertifika yetkilisi o domain için sertifika düzenleyebilir. Kayıt varsa, yalnızca izin verilen yetkililer sertifika üretebilir.

Geçiş öncesinde kontrol edilmesi gereken soru şudur: Sertifikanızı alacağınız yetkilinin adı CAA kaydında var mı? Let's Encrypt kullanıyorsanız letsencrypt.org, DigiCert kullanıyorsanız digicert.com değeri eklenmeli. Geçiş sırasında CAA kaydı yanlış yapılandırılırsa sertifika düzenlenme aşamasında hata alırsınız ve bu hatanın kaynağını bulmak zaman alır.

ornek.com. 3600 IN CAA 0 issue "letsencrypt.org"
ornek.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

CAA kaydı her projede zorunlu değildir. Küçük bir kişisel site için bu kaydı atlamak anlamlı bir risk oluşturmaz. Kurumsal ortamlarda veya birden fazla alt alan yönetilen yapılarda, hangi yetkililerin sertifika basabileceğini kısıtlamak güvenlik politikasının parçasıdır; bu durumda CAA kaydı geçişten önce gözden geçirilmeli.

A ve CNAME Kayıtlarını Geçiş Öncesi Doğrulayın

Sertifika almadan önce A veya CNAME kaydının doğru sunucuya işaret ettiğinden emin olun. Let's Encrypt ve benzeri otomatik sertifika yetkilileri, domain doğrulamasını HTTP üzerinden yapar: .well-known/acme-challenge/ yoluna ulaşarak domain'in gerçekten o sunucuya ait olduğunu doğrular. A kaydı eski sunucuya bakıyorsa doğrulama başarısız olur.

Özellikle Vercel veya Netlify gibi platformlara geçiş yapıyorsanız CNAME kaydı genellikle A kaydının önüne geçer. Bu platformlar hem HTTP hem de HTTPS doğrulamasını kendi altyapıları üzerinden yönetir; doğru CNAME değeri girilmeden sertifika otomatik olarak atanamaz.

Kayıt doğrulaması için şu sorguları çalıştırabilirsiniz:

nslookup ornek.com
dig ornek.com A

Sonuç, yeni sunucunun IP'sini göstermelidir. Eski IP hâlâ dönüyorsa ya kayıt güncellenmemiştir ya da TTL süresi henüz dolmamıştır. TTL'i önceden düşürdüyseniz bekleme süresi kısalır; aksi hâlde kaydın yayılması saatler alabilir.

Sertifika Doğrulamada DNS-01 mi HTTP-01 mi?

Bazı sertifika yetkilileri, domain doğrulaması için iki seçenek sunar: HTTP-01 (web sunucusu üzerinden dosya yerleştirme) ve DNS-01 (DNS'e TXT kaydı ekleme). Wildcard (joker) sertifikalar için DNS-01 zorunludur; HTTP-01 joker sertifikayı doğrulayamaz.

DNS-01 doğrulamasında süreç şöyle işler: yetkili size bir TXT değeri verir, bu değeri _acme-challenge.ornek.com adresine TXT kaydı olarak eklersiniz, ardından yetkili bu kaydı sorgular ve domain sahipliğini onaylar. Propagation süresi burada kritik rol oynar; TXT kaydı yayılmadan yetkili sorgularsa doğrulama başarısız olur. Kaydı ekledikten sonra birkaç dakika beklemek ve ardından doğrulamayı tetiklemek daha güvenlidir.

Google Cloud DNS gibi programatik erişim sunan sağlayıcılarda DNS-01 doğrulaması otomatikleştirilebilir; API üzerinden TXT kaydı kendiliğinden eklenip sertifika yenilemeleri yönetilir. HTTP-01 yöntemi kullanıyorsanız web sunucusunun 80. portta erişilebilir olması şarttır. HTTPS'e geçiş sırasında 80. portu tamamen kapatmak, otomatik yenilemeyi engeller; geçiş sonrasında da 80. port açık kalmalı, yalnızca 443'e yönlendirilmeli.

301 Yönlendirme DNS Katmanında Yapılamaz

HTTP'den HTTPS'e yönlendirme, DNS katmanında değil sunucu katmanında yapılır. Apache .htaccess, Nginx server bloğu veya CDN/proxy katmanı bu yönlendirmeyi üstlenir. Bir DNS kaydı, HTTP trafiğini HTTPS'e doğrudan yönlendiremez; DNS yalnızca IP adresi çözümlemesi yapar.

Yönlendirme devreye alınmadan önce sertifikanın çalışması gerekir:

1. Sertifika alınır ve HTTPS çalışır hale getirilir.
2. Sertifika tarayıcıda hata vermeden doğrulanır.
3. HTTP-to-HTTPS 301 yönlendirmesi etkinleştirilir.

Bu sıra tersine çevrilirse, 301 devreye alınır ama sertifika henüz yoksa veya HTTPS çalışmıyorsa, kullanıcılar sonsuz yönlendirme döngüsüne ya da sertifika hatasına düşer. Bazı DNS sağlayıcıları "URL redirect" özelliği sunar ve bu seçenek arka planda bir HTTP yönlendirme servisi çalıştırır; sunucu tarafı yönlendirmeyle çakışmamaya dikkat edin, aksi hâlde iki katmanlı yönlendirme zinciri oluşur.

MX ve E-posta Kayıtlarını Dokunmadan Bırakın

HTTPS geçişi sırasında MX kaydına dokunmak gerekmez. Ne var ki bazı paneller "tüm kayıtları güncelle" seçeneği sunar; bu seçenek yanlışlıkla MX kaydının üzerine yazabilir. Her kaydı ayrı ayrı güncellemek daha güvenlidir.

SPF ve DKIM kayıtları da bu geçişten etkilenmez. Sunucu değişiyorsa ve e-posta aynı domain'den gönderilmeye devam edecekse, SPF kaydındaki ip4: veya include: değerlerinin hâlâ doğru sunucuyu işaret ettiğini kontrol edin. Sunucu IP'si değiştiyse ve SPF güncellenmemişse, gönderilen e-postalar spam klasörüne düşebilir veya reddedilebilir.

Google Workspace DNS kurulumu veya Microsoft 365 e-posta yapılandırması olan domainlerde geçiş sonrası SPF ve DKIM kayıtlarının yerinde durduğunu doğrulayın. Özellikle zone dışa aktarma/içe aktarma işlemleri yapıldıysa tüm TXT kayıtlarını gözden geçirin; bu işlemler sırasında kayıtların önüne boşluk eklenmesi veya tırnak işaretlerinin kaybolması gibi biçim hataları oluşabilir.

Propagation Süresi ve Tam Geçiş Sırası

DNS değişiklikleri anlık değildir. Dünya genelindeki DNS çözümleyiciler, kaydın yeni değerini kendi önbelleklerinde sakladıktan sonra teslim etmeye başlar. TTL'i 300 saniyeye indirmiş olsanız bile bazı çözümleyiciler eski TTL değerini esas alarak daha uzun süre eski kaydı sunar.

Tam propagation genellikle 1 ile 48 saat arasında sürer. 300 saniyelik TTL ile çoğu bölgede 15-30 dakika içinde güncelleme görülür; ancak bazı internet servis sağlayıcıları agresif önbellekleme yapar ve bu süre uzayabilir. Yeni IP'nin döndüğünü farklı coğrafi konumlardan doğrulamak için çevrimiçi DNS sorgu araçlarını kullanabilirsiniz.

Tüm adımları bir arada görmek için tam sıra:

1. TTL'leri 24-48 saat önce 300 saniyeye indirin.
2. CAA kaydını (varsa) sertifika yetkilisine göre güncelleyin.
3. A veya CNAME kaydını yeni sunucuya çevirin.
4. Propagation'ı doğrulayın: yeni IP'nin döndüğünü görün.
5. Sertifikayı alın ve HTTPS'i test edin.
6. HTTP-to-HTTPS 301 yönlendirmesini etkinleştirin.
7. MX, SPF, DKIM kayıtlarının değişmediğini doğrulayın.
8. Geçiş tamamlandıktan 24-48 saat sonra TTL'leri 3600 saniyeye yükseltin.

Geri dönüş için minimum bilgi: eski sunucu IP'si, eski TTL değerleri, değiştirilmiş tüm kayıtların geçiş öncesi halleri. A kaydını eski IP'ye döndürmek en hızlı müdahale yöntemidir ve TTL 300 saniyedeyken bu 5-10 dakika içinde etkili olur. Bu bilgileri düz metin olarak saklayın; DNS paneline erişim olmasa da registrar panelinden değişiklik yapılabilir.

Geçişin herhangi bir adımında sorun yaşandığında, hangi adımda durulduğunu bilmek çözüme ulaşmayı hızlandırır. Kontrol listesini adım adım işaret eden basit bir not - hangi kayıt, ne zaman, hangi değere çevrildi - geçiş sırasında ve sonrasında referans noktası işlevi görür. Geçiş sırasında oluşan hataların büyük çoğunluğu sıralama hatasından kaynaklanır: sertifika alınmadan önce yönlendirme açılmak veya A kaydı değişmeden sertifika doğrulanmaya çalışılmak. Sırayı korumak, hatanın türünü tahmin edilebilir kılar.

DigitalOcean gibi bulut sağlayıcılarda DNS yönetimi doğrudan sunucu panelinden yapılabilir; bu durum bazı adımları kolaylaştırır ama sıralamanın önemini değiştirmez. Hangi panel kullanılırsa kullanılsın, TTL, propagation ve sertifika doğrulama mantığı aynı kalır.

HTTPS geçişi tamamlandıktan sonra domain'i düzenli aralıklarla izleyin; sertifika yenileme tarihleri, CAA kaydı varlığı ve SPF ile DKIM tutarlılığı zamanla kayabilir. Domain portföyünüzü sistematik biçimde takip etmek, bu kaymaları erken fark etmenizi sağlar ve bir sonraki geçişe daha hazırlıklı girmenizi kolaylaştırır.