Domain ve DNS Bilgi Rehberi
Anahtar kesme tezgahında uyuşmayan kopya ve duvarda yan yana iki anahtar

Vercel ve Netlify'da Custom Domain Kurulumu Sorunları

Bir proje Vercel'e veya Netlify'a deploy edildikten sonra kendi domain'inizi bağlamak genelde birkaç dakikalık bir işlemdir: platform paneline domain adını yazarsınız, önerilen DNS kaydını registrar'a eklersiniz, birkaç dakika beklersiniz. Ama bu akış her zaman sorunsuz işlemez. Domain paneli saatlerce "Pending" veya "Invalid Configuration" gösterirken, bazen SSL sertifikası hiç verilmez, bazen apex domain çalışırken www çalışmaz veya tam tersi olur.

Bu sorunların büyük kısmı iki nedenden birine dayanır: platformun beklediği kayıt türü ile eklenen kaydın uyuşmaması, ya da domain başka bir katman (genellikle Cloudflare proxied modu) üzerinden geçtiği için platformun doğrulama mekanizmasının domain'in gerçekten kendisine işaret ettiğini görememesi. Kayıt uyuşmazlığı, apex ile www ayrımı, SSL doğrulama takılması ve proxy müdahalesi ayrı sınıflardır; her biri dig ile ayrı okunur. İki platform da aynı temel mantığı kullanır; A kaydı ile IP'ye, CNAME ile platform alt alanına işaret eder. Ama uyguladıkları değerler, hata mesajları ve SSL doğrulama süreleri birbirinden farklıdır.

Vercel ve Netlify'da Custom Domain Ekleme Mekanizması Nasıl Çalışır?

Vercel, apex domain (ornek-sirket.com) için sabit bir A kaydı önerir: 76.76.21.21. www alt alanı için ise kendi hedef alanına işaret eden bir CNAME beklenir: cname.vercel-dns.com. Netlify de benzer bir ikili yapı kullanır; apex için genellikle 75.2.60.5 IP adresine A kaydı veya sağlayıcı destekliyorsa ALIAS/ANAME ile apex-loadbalancer.netlify.com hedefine yönlendirme, www için ise projeye özel <site-adi>.netlify.app hedefine CNAME önerilir.

Domain panelde eklendiğinde her iki platform da arka planda periyodik bir doğrulama sorgusu çalıştırır: kendi nameserver'ından bağımsız olarak, genel resolver'lar üzerinden domain'in gerçekten önerilen değere işaret edip etmediğini kontrol eder. Kayıt doğru göründüğü anda durum "Pending" veya "Invalid Configuration"dan "Valid Configuration"a döner ve SSL sertifikası otomatik tetiklenir. Bu döngü elle tetiklenen bir işlem değildir; kayıt eklendikten sonra platform kendi zamanlamasına göre tekrar sorgular, bu yüzden panelde "Yenile" düğmesine art arda basmak süreci hızlandırmaz.

Bu iki sorgunun çıktısı, panelde gösterilen önerilen değerle karakter karakter eşleşmelidir. Sondaki nokta, büyük/küçük harf farkı önemli değildir ama IP adresinde ya da CNAME hedefinde tek bir rakam farkı, doğrulamanın süresiz beklemede kalmasına yol açar.

DNS Kayıtları Doğru Ama Domain Hâlâ "Invalid Configuration" Gösteriyor

Kayıt registrar panelinde doğru görünmesine rağmen platform hâlâ hata gösteriyorsa, önce hangi resolver'ın hangi değeri döndürdüğüne bakmak gerekir. Platformun doğrulama servisi genellikle kendi seçtiği bir dış resolver üzerinden sorgu yapar; bu resolver, sizin bilgisayarınızın kullandığı yerel önbellekten farklı bir yanıt görüyor olabilir.

Üç sorgu da aynı, doğru değeri döndürüyorsa sorun kayıt tarafında değildir; muhtemelen platformun kendi doğrulama döngüsü henüz bir sonraki kontrolüne ulaşmamıştır ve birkaç dakika içinde kendiliğinden düzelir. Ama sorgulardan biri eski bir değer döndürüyorsa, propagasyon süreci devam ediyordur; eski kaydın TTL değeri ne kadar yüksekse bekleme o kadar uzar. Domain'i yeni bir platforma bağlamadan önce eski A veya CNAME kaydının TTL'ini düşürmek, bu tür geçişlerde standart bir pratiktir; geçiş öncesi bu hazırlığın nasıl planlandığı web sitesi taşırken DNS geçiş planı başlığı altında ayrıca ele alınmıştır.

Apex Domain ve www Alt Alanı İçin Farklı Kayıt Türleri Neden Gerekir?

Bu ayrımın nedeni platform tercihi değil, DNS protokolünün kendi kısıtıdır: zone apex'inde (kök domain'de) CNAME kaydı bulunamaz, çünkü apex zaten SOA ve NS kayıtlarını taşımak zorundadır ve CNAME bir isim için başka herhangi bir kayıt türünün bulunmasına izin vermez. Bu yüzden hem Vercel hem Netlify apex için CNAME değil A kaydı (ya da ALIAS/ANAME destekleyen bir sağlayıcıda ALIAS) ister; www gibi bir alt alan apex olmadığı için orada CNAME serbestçe kullanılabilir.

Pratikte en sık yapılan hata, apex için de bir CNAME denemeye çalışmaktır; bazı registrar panelleri bunu görünürde kabul eder, arka planda otomatik olarak CNAME flattening uygular, ama bazı panellerde işlem doğrudan reddedilir ya da sessizce kaydedilmeyip eski değer kalır. Registrar'ınız apex'te CNAME'e izin vermiyorsa ve platformunuz ALIAS/ANAME desteklemiyorsa, tek seçenek sabit A kaydını kullanmaktır; bu durumda platformun IP'si değiştiğinde kaydı elle güncellemeniz gerekir. ALIAS veya ANAME desteği olan bir DNS sağlayıcısına geçmek, bu güncellemeyi otomatik hale getirir.

www için CNAME yerine yanlışlıkla A kaydı girip platformun IP'sini elle yazmak da yaygın bir hatadır. İlk anda çalışır gibi görünür çünkü IP o anda doğrudur; ama platform arka planda IP havuzunu değiştirdiğinde www alt alanı sessizce erişilemez hale gelir. Platform hangi kayıt türünü önerdiyse (A ya da CNAME) tam olarak o türde eklemek, ileride fark edilmesi zor bir kesintiyi baştan önler.

SSL Sertifikası Neden Takılı Kalır veya Hiç Verilmez?

Hem Vercel hem Netlify, DNS kaydı doğrulandıktan sonra Let's Encrypt üzerinden otomatik olarak bir SSL sertifikası talep eder. Bu talep, doğrulama için genellikle bir HTTP erişimi (domain üzerinden platformun sunucusuna ulaşabilme) ya da DNS üzerinden bir TXT kaydı kontrolü gerektirir. DNS kaydı platformun beklediği değere işaret etmiyorsa, ya da domain başka bir yerden trafiği karşılıyorsa, bu doğrulama başarısız olur ve sertifika süresiz "pending" durumda kalır.

Sertifikanın takılı kalmasının bir başka, daha az bilinen nedeni CAA kaydıdır. Domain'in zone'unda önceden başka bir sertifika otoritesine (örneğin yalnızca DigiCert'e) izin veren bir CAA kaydı varsa ve Let's Encrypt bu listede değilse, sertifika talebi CAA kontrolünde reddedilir. Bu durumda platformun panelindeki hata mesajı genellikle "sertifika verilemedi" gibi belirsiz bir ifadeyle sınırlıdır; asıl nedeni görmek için zone'daki CAA kaydını doğrudan sorgulamak gerekir.

CAA kaydı hiç yoksa herhangi bir otorite sertifika verebilir, bu yüzden çoğu domain'de sorun burada değildir; ama daha önce güvenlik sıkılaştırması yapılmış kurumsal domain'lerde bu kısıt sık karşılaşılan bir engeldir.

Cloudflare Proxied Modu Vercel/Netlify Doğrulamasını Nasıl Bozar?

Domain zaten Cloudflare üzerinden yönetiliyorsa ve turuncu bulut (Proxied) modu açıksa, DNS sorgusu artık platformun gerçek IP'sini değil Cloudflare'in kendi IP'sini döndürür. Bu durum web trafiği için normalde sorun yaratmaz çünkü Cloudflare arka planda gerçek hedefe yönlendirme yapar; ama Vercel ve Netlify'ın domain doğrulama mekanizması tam olarak bu davranıştan rahatsız olur. Platform, kaydın kendi IP'sine ya da CNAME hedefine işaret etmesini beklerken Cloudflare'in IP'sini görür ve "domain yapılandırması hâlâ geçersiz" uyarısı vermeye devam eder.

Bu senaryoda pratik çözüm, en azından apex ve www kayıtlarını doğrulama tamamlanana kadar geçici olarak DNS Only (gri bulut) moduna almaktır. Doğrulama ve SSL verildikten sonra bazı kullanıcılar Cloudflare'in CDN ve DDoS koruması için proxied modu geri açmayı dener; ancak bu durumda iki katmanlı SSL sonlandırma (Cloudflare ile platform arasında) devreye girer ve Cloudflare tarafındaki SSL modunun "Full" veya "Full (Strict)" olarak ayarlanması gerekir, aksi halde "Too many redirects" hatası ortaya çıkar. Proxy katmanı olan bu yapıda DNS planlamasının nasıl şekillendiği reverse proxy kullanırken DNS planlaması yazısında ayrıca ele alınmıştır.

İki veya Daha Fazla Projeye Aynı Domain'i Bağlarken Çakışma

Bir domain daha önce başka bir Vercel projesine, başka bir Netlify sitesine ya da hatta aynı platformdaki farklı bir hesaba bağlanmışsa, o kayıt platformun kendi iç veritabanında hâlâ "sahiplenilmiş" olarak görünebilir. Yeni projeye aynı domain'i eklemeye çalıştığınızda DNS kaydı doğru olsa bile "domain already in use" ya da benzer bir çakışma hatası alırsınız.

Bu durumun çözümü DNS tarafında değil, platform tarafındadır: domain'i önce eski projeden veya eski hesaptan kaldırmak gerekir. Eski projeye artık erişiminiz yoksa (örneğin ajans değişikliği sonrası), platformun destek ekibiyle domain sahipliğini doğrulayarak iletişime geçmek gerekebilir; bu süreç DNS kaydını değiştirmekten bağımsız, tamamen platformun iç yetkilendirme sistemiyle ilgilidir. Aynı domain'i aynı anda iki farklı Vercel projesine (örneğin biri staging biri production) bağlamak isteyen ekipler için doğru yaklaşım, apex'i production projesine, ayrı bir alt alanı (staging.ornek-sirket.com) ise staging projesine ayrı ayrı bağlamaktır.

Doğrulama ve Teşhis: dig ve Platform Panelindeki Sinyaller

Bir custom domain sorununu teşhis ederken sıra genellikle şu şekilde izlenir: önce dig ile kaydın gerçek değerini birden fazla resolver üzerinden kontrol edin, sonra bu değeri platformun panelinde önerilen değerle karakter karakter karşılaştırın, ardından CAA kaydının hedef sertifika otoritesini engellemediğinden emin olun, son olarak domain'in proxied bir CDN üzerinden geçip geçmediğini kontrol edin.

Bu dört sorgunun çıktısı birlikte değerlendirildiğinde çoğu "Invalid Configuration" veya takılı kalmış SSL vakasının nedeni netleşir. NS sorgusunun sonucu ayrıca önemlidir: domain'in nameserver'ı hâlâ eski bir sağlayıcıdaysa ya da yakın zamanda değiştirildiyse, platformun doğrulama servisi henüz güncel zone'u görmüyor olabilir; bu durumda beklenen davranış gecikmeli düzelmedir, kayıt hatası değil. Yüksek trafikli yapılarda anycast DNS kullanan sağlayıcılar, nameserver geçişlerinde farklı PoP'ların farklı yanıtlar vermesine yol açabilir; bu da platformun doğrulama servisinin hangi noktadan sorgu attığına bağlı olarak tutarsız sonuçlar üretir.

Custom domain sorunlarının çoğu, aslında DNS'in kendisiyle ilgili karmaşık bir arıza değil, platformun beklediği tek bir değerle eklenen değer arasındaki küçük bir uyuşmazlıktır. Doğru A kaydı ile CNAME'i birbirine karıştırmamak, apex ve www için farklı kayıt türlerinin zorunlu olduğunu bilmek ve Cloudflare gibi bir proxy katmanının doğrulama sürecine nasıl müdahale ettiğini anlamak, sorunların büyük kısmını dakikalar içinde çözülebilir hale getirir.

Kalan vakaların çoğu zamanlama meselesidir: kayıt doğrudur ama platformun bir sonraki doğrulama döngüsü henüz gelmemiştir, ya da eski kaydın TTL'i propagasyonu geciktirmektedir. Yapılacak en verimli şey panelde sürekli yenilemek değil, birden fazla resolver üzerinden gerçek değeri doğrulamak ve gerçekten bir uyuşmazlık olup olmadığını netleştirmektir.

İlgili Yazılar