DNS ve SSL sorunları için özel alan adı sorun giderme kontrol listesi

“Özel alan adı çalışmıyor” genellikle ne demektir

“Özel alan adı çalışmıyor” ifadesi birkaç farklı hatayı kapsayan genel bir tanımdır. Tarayıcınız belirtileri gösterir, nedeni değil. Bir şeyi değiştirmeden önce aslında ne gördüğünüzü tanımlayın.

Tipik belirtiler şunlardır:

• “alan adı bulunamadı” sayfası
• Domainin yanlış bir web sitesini yüklemesi
• HTTPS etkin olmasına rağmen “güvensiz” uyarısı
• Yönlendirme döngüleri (http ve https arasında ya da root domain ve www arasında zıplama)

Çoğu zaman yanlış olan tek bir şey vardır:

• DNS yanlış yere işaret ediyor veya gereken kayıt eksik
• Barındırma hedefi o hostname için yapılandırılmamış (sunucu domaininizi tanımıyorsa)
• SSL henüz verilmedi, farklı bir hostname için verildi ya da DNS eşleşmediği için verilemiyor
• Önbellekleme değişikliklerinizi gizliyor (tarayıcı önbelleği, DNS çözücü önbelleği veya eski TTL değerleri)

Sorun gidermeye başlamadan önce iki yere erişiminiz olduğundan emin olun: DNS kayıtlarını düzenlediğiniz yer (kayıt kuruluşu veya DNS sağlayıcı) ve domaini bağladığınız hosting tarafı. Örneğin, dağıtılmış bir uygulamayı Koder.ai üzerinde özel bir alan adına bağlıyorsanız, domain için DNS erişimi ve uygulamanın hosting/dağıtım ayarlarında domain ayarlarına erişiminiz olmalıdır.

Bazı düzeltmeler anında etkilidir (örneğin yazım hatasını düzeltmek). Diğerleri zaman alır. DNS değişikliklerinin görünmesi zaman alabilir ve SSL genellikle yalnızca DNS doğru şekilde işaret edip domain erişilebilir hale gelince tamamlanır. Amaç tahmin etmeyi bırakmak ve her katmanı sırayla doğrulamaktır.

Önemli ama jargon içermeyen küçük DNS kavramları

Çoğu domain sorunu şu üç şeyin uyuşmamasından kaynaklanır: (1) test ettiğiniz hostname, (2) DNS'in yönetildiği yer ve (3) kaydın gerçekte nereye işaret ettiği. Bu üçü uyduğunda, SSL genellikle son adımdır.

Domainlerin iki yaygın formu vardır: root domain (example.com, apex olarak da anılır) ve alt alan adları (www.example.com, app.example.com). İlişkili olsalar da farklı DNS kayıtlarına sahip olabilirler. Bu yüzden www çalışırken apex başarısız olması normaldir veya tam tersi.

Nameserver'lar DNS bölgenizin kimin kontrolünde olduğunu belirler. Bir firmadan domain satın aldıysanız ancak nameserver başka bir firmaya işaret ediyorsa DNS'i nameserver'ların işaret ettiği yerde düzenlemelisiniz. Birçok “güncelledim ama hiçbir şey değişmedi” durumu yanlış kontrol panelinde kayıtların düzenlenmesinden kaynaklanır.

DNS kayıt türleri basitçe

Ana kayıt türlerinin ne yaptığını şöyle özetleyebiliriz:

• A: bir ismi IPv4 adresine işaret eder (ör. 203.0.113.10)
• AAAA: bir ismi IPv6 adresine işaret eder
• CNAME: bir ismi başka bir host adına yönlendirir (www için yaygın)
• TXT: doğrulama ve güvenlik için metin saklar (sahiplik kontrolleri, SPF vb.)

TTL, “ne kadar süre önbellekte tutulsun” zamanlayıcısıdır. Düşük TTL, önbelleklerin daha hızlı yenilenmesi anlamına gelir. Yüksek TTL, kaydı düzelttikten sonra daha uzun beklemeniz gerektiği anlamına gelir. Bir süre eski değeri görmek normal olabilir.

Adım adım: nedeni izole etmek için basit bir karar ağacı

Bir özel alan adı başarısız olduğunda, genellikle dört kategoriden birine ayrılır: DNS çözülmüyor, DNS yanlış yere işaret ediyor, SSL hazır değil veya sadece bazı kişiler için önbellekleme yüzünden başarısız oluyor.

Bu karar ağacını kullanın:

1. Domain hiç çözülebiliyor mu? NXDOMAIN (veya “domain bulunamadı”) görüyorsanız, kayıt eksik, yanlış DNS bölgesini düzenliyorsunuz veya nameserver beklediğiniz gibi değil demektir.
2. Eğer çözülüyorsa, doğru hedefe mi işaret ediyor? Sayfa yükleniyor ama yanlış site, park edilmiş sayfa veya eski sunucu görünüyorsa A/AAAA/CNAME hedefi yanlış ya da öncelik alan eski bir kayıt vardır.
3. Doğru hedefe işaret ediyorsa, sorun sadece HTTPS mi? HTTP çalışıyorsa ama HTTPS sertifika uyarısı gösteriyorsa, SSL hâlâ veriliyor olabilir, sertifikadaki hostname uyuşmuyor olabilir veya platform DNS'in oturmasını bekliyor olabilir.
4. Bir cihazda veya ağda çalışıyor ama diğerinde çalışmıyor mu? Buna önbellekleme veya yayılma olarak yaklaşın.
5. Yönlendirmeler bozuluyor mu (www vs apex)? Eğer www çalışıyorsa ama root domain çalışmıyorsa (veya tersi), muhtemelen sadece bir hostname yapılandırdınız veya çakışan yönlendirme kurallarınız var.

Hızlı hareket etmek için başarısız olan kesin hostname'i (apex veya www) ve gördüğünüz tam hata mesajını yazın. Domainleri ve sertifikaları otomatikleştiren hosting platformlarında “host bulunamıyor” ile “sertifika beklemede” arasındaki fark, DNS kayıtlarını düzeltmeniz mi yoksa DNS göründükten sonra SSL için beklemeniz mi gerektiğini söyler.

Adım 1: hostname ve beklenen hedefi doğrulayın

Birçok domain hatası basit bir uyuşmazlıktan başlar: bir hostname için DNS yapılandırdınız ama başka birini test ediyorsunuz.

Önce canlı yapmak istediğiniz tam hostname'i yazın. Root domain example.com gibi görünür. Bir alt alan www.example.com veya app.example.com gibi görünür. Bunlar ayrı DNS girdileridir, bu yüzden “www çalışıyor” demek root domainin çalıştığı anlamına gelmez.

Sonra hosting platformundan beklenen hedefi bulun. Bazı hostlar bir IP adresi verir (A veya AAAA kaydı için). Diğerleri bir hedef host adı verir (CNAME için). Hostunuz domain kurulum ekranında bir değer veriyorsa, onu gerçek kaynak olarak kabul edin.

Hiçbir şeyi değiştirmeden önce şu bilgileri alın:

• Değiştirdiğiniz hostname için mevcut DNS kayıtlarını kopyalayın
• Var olan A, AAAA, CNAME ve TXT kayıtlarını not edin
• TTL değerini kaydedin

Ayrıca doğru DNS bölgesini düzenlediğinizi doğrulayın. Yanlış domaini, yanlış ortamı veya yanlış sağlayıcı hesabını güncellemek kolaydır.

Adım 2: doğru DNS kayıt tipini seçin (A, AAAA, CNAME, TXT)

Pek çok sorun, bağlanmaya çalıştığınız hostname için yanlış kayıt tipinden kaynaklanır. Önce iki vakayı ayırın: root domain (example.com) ve bir alt alan (www.example.com). Birçok DNS sağlayıcısında bunlar farklı davranır.

A kaydı bir ismi IPv4 adresine yönlendirir. Birçok kurulum root domain için A kaydı kullanır çünkü bazı sağlayıcılar apex'te CNAME'e izin vermez. Hostunuz size bir IP veriyorsa, genellikle A kaydı doğru seçenektir.

AAAA kaydı IPv6 versiyonudur. Eski bir AAAA kaydının yanlış hedefe işaret etmesi kafa karıştırıcı “bende çalışıyor” davranışları yaratabilir; çünkü bazı ziyaretçiler IPv6 üzerinden, diğerleri IPv4 üzerinden bağlanacaktır. Hostunuz IPv6 hedefi vermediyse yanlış AAAA kaydını kaldırmak tutarsız hataları genellikle düzeltir.

CNAME kaydı bir alt alanı başka bir host adına yönlendirir (çoğunlukla www için). Host arka planda değişebilecek bir isimli uç noktaya işaret etmenizi istediğinde kullanışlıdır.

TXT kaydı doğrulama ve challenge için kullanılır (bazı SSL doğrulamaları dahil). Yaygın hatalar yanlış isimde TXT oluşturmak (apex vs _acme-challenge vs bir alt alan), fazladan boşluk eklemek veya yanlış değeri yapıştırmaktır.

İlerlemeden önce çakışmalara bakın. En çok sorun çıkaranlar şunlardır:

• Aynı isimde başka kayıt türleri varken CNAME kullanmak
• Sadece bir tane olmasını istediğiniz yerde aynı isim için birden fazla A veya AAAA kaydı
• www veya root domain için bırakılmış eski kayıtlar
• Yanlış hostnamede oluşturulmuş TXT kayıtları

Adım 3: nameserver'ları doğrulayın ki doğru yerde düzenleme yapıyor olun

Birçok “özel alan adı çalışmıyor” vakası aslında kayıt değerleriyle ilgili değildir. Kayıt yanlış sağlayıcıda eklenmiş olabilir. Domaininiz Provider A'nın nameserver'larını kullanıyorsa, Provider B panelinde kayıtları değiştirmek hiçbir şey yapmaz; görünüşte doğru olsa bile.

Yetkili nameserver'ları doğrulayın

Domaininizin gerçekten hangi nameserver'ları kullandığını kontrol edin. Bunu genellikle registrarınızın domain ayarlarında “Nameservers” bölümünde görürsünüz. İkinci bir görüş için bilgisayarınızdan DNS'e sorabilirsiniz:

dig NS example.com

Bu komutun döndürdüğü nameserver'lar yetkili olanlardır.

Kısa bir akıl sağlığı kontrolü:

• DNS sağlayıcınız size ns1... ve ns2... gibi nameserver'lar verdiyse, bu tam değerler registrar'da görünmelidir.
• Yakın zamanda DNS sağlayıcısını değiştirdiyseniz, değişikliğin tamamlandığını doğrulayın ve daha fazla kayıt düzenlemeden önce geçişin tamamlanmasını bekleyin.
• Bir platform “önerilen DNS kayıtları” gösteriyorsa, bunlar genellikle kılavuzluktur. Yine de kayıtları yetkili DNS sağlayıcısında eklemeniz gerekir.

“Güncelledim ama hiçbir şey değişmedi” neden olur

Yanlış sağlayıcıda kayıtları güncellerseniz, genellikle birbirini tutmayan iki kontrol paneli görürsünüz. Sadece yetkili nameserver'lar önemlidir.

Ayrıca registrar üzerinde nameserver değiştirdikten sonra gecikmelere dikkat edin. Geçiş penceresi boyunca test ettiğiniz yere bağlı olarak sonuçlar tutarsız görünebilir. Nameserver'lar hâlâ değişiyorsa, nameserver seti stabil olana kadar kayıt düzenlemelerini erteleyin, sonra devam edin.

Adım 4: işe yarayan yayılma ve önbellek kontrolleri

“Yayılma” tek bir anahtar değildir. ISP, mobil operatör, genel çözücüler ve cihazlarınız dahil bir dizi DNS önbelleğinin güncellenmesidir. Bu yüzden domaininiz bir iş arkadaşınızda çalışırken sizde çalışmayabilir.

TTL (time to live) önbelleklerin bir cevabı ne kadar süre saklayabileceğini söyler. Eski TTL 1 saatse, bazı kişiler neredeyse bir saate kadar eski değeri görmeye devam eder. Değişiklikten önce TTL'i düşürmek ancak önceden yapılmışsa fayda sağlar.

Önbelleme gecikmelerini gerçek hatalardan ayırmak için birkaç hızlı kontrol yapın:

• Ev veya ofis Wi‑Fi'da, sonra mobil veride test edin
• Farklı bir ağda birinden denemesini isteyin
• Önbelleğe alınmış yönlendirmeleri elemek için gizli pencere kullanın
• Cihazınızı yeniden başlatın veya yerel DNS önbelleğini temizleyin (nasıl yapılacağını biliyorsanız)
• Tam host adını tekrar kontrol edin (root vs www)

Eğer kontrol ettiğiniz her yerde kayıt yanlışsa (yanlış IP, eksik www, eski CNAME), düzeltin. Kayıtlar çoğu yerde doğru görünüyorsa ama bir ağ eski değeri göstermeye devam ediyorsa, genellikle önbellek gecikmesidir.

Adım 5: SSL zamanlaması ve neden “biraz bekle” bazen doğru

SSL sertifikaları genellikle şu temel yüzden başarısız olur: sertifika sağlayıcısı, DNS doğru şekilde hedefe işaret edene kadar domaini doğrulayamaz.

Normal sıra basittir:

1. Doğru DNS kayıtlarını ayarlayın.
2. Birkaç yerden doğru çözüldüğünden emin olun.
3. Gerekli doğrulamayı tamamlayın (genellikle bir TXT kaydı).
4. Sertifika verilmesini bekleyin.

Kolay kaçırılan ortak engeller vardır. Yanlış bir A veya CNAME hedefi doğrulama kontrollerini yanlış sunucuya gönderir. Eski bir AAAA kaydı bazı ziyaretçilerin çalışan A kaydınızı geçersiz kılmasına neden olabilir, bu yüzden HTTPS yalnızca onlar için başarısız olur. Gerekli bir TXT kaydının eksik olması platformun sertifika vermesini engelleyebilir.

Belirtileri kullanarak “hala veriliyor” ile “yanlış yapılandırılmış”ı ayırın:

• Hâlâ veriliyor: HTTP çalışabilir, ama HTTPS geçici bir varsayılan sertifika veya “henüz geçerli değil” tarzı bir mesaj gösterir.
• Yanlış yapılandırılmış: farklı bir web sitesi görürsünüz, ISP park sayfası çıkar veya DNS sorgusu başarısız olur (NXDOMAIN).

Beklerken, kayıtları sürekli değiştirmeyin. Her değişiklik saati sıfırlar ve farklı ağların farklı cevaplar görmesine neden olabilir. Doğru kayıtları bir kez ayarlayın, sonra sertifika verene kadar çözümlemeyi ve doğrulamayı tekrar kontrol edin.

Koder.ai gibi bir platform kullanıyorsanız, en güvenli akış aynıdır: DNS'in beklenen hedefe işaret ettiğini doğrulayın, varsa yanlış AAAA kayıtlarını kaldırın ve DNS stabil olduktan sonra SSL için zaman verin.

Her adımı nasıl doğrularsınız (tahmine dayanmadan)

İyi sorun giderme genellikle karşılaştırmaktır: gördüğünüz ile beklediğiniz. “Telefonumda yükleniyor”a güvenmeyin; tekrarlanabilir kontroller kullanın.

DNS yanıtlarını beklenen hedefle karşılaştırın

Bir DNS sorgu aracı (ör. nslookup veya dig) kullanın ve dönen değerin beklediğinizle eşleştiğini doğrulayın (A veya AAAA için bir IP, CNAME için bir host adı, TXT için bir token).

# Apex (root) domain
dig example.com A

dig example.com AAAA

# www subdomain
dig www.example.com CNAME

# TXT (often used for verification)
dig example.com TXT

Kullanıyor olabileceğiniz iki ismi de kontrol edin: apex (example.com) ve www (www.example.com). Bunlardan birinin doğru olup diğerinin eski bir yere işaret etmesi sık rastlanan bir durumdur.

Tarayıcı davranışını kontrol edin (HTTP, HTTPS ve yönlendirmeler)

Hem http:// hem de https:// ile apex ve www adreslerini açın. Bir net “ana” domain ve bir temiz yönlendirme istiyorsunuz.

• Bir kanonik domain seçin (apex veya www) ve diğerini ona yönlendirin.
• Ping-pong yönlendirmelerinden kaçının (A B'ye, sonra B tekrar A'ya yönlendiriyor).
• HTTP çalışıyor ama HTTPS başarısızsa, SSL hâlâ veriliyor veya DNS beklenmeyen bir yere işaret ediyor demektir.

Sonuçlar ağa göre farklılık gösteriyorsa, büyük olasılıkla önbellek veya yayılma görüyorsunuzdur. Küçük bir günlük tutun: neyi değiştirdiniz, nerede değiştirdiniz, zaman ve ne gözlemlediniz.

Saatleri boşa harcatan yaygın hatalar

Çoğu DNS ve SSL problemi gizem değildir. Kontrol ettiğiniz yanlış şeyi kontrol etmeye devam etmek veya çok sık değişiklik yapmak işleri uzatır.

En yaygın zaman kaybı, iki farklı yerde DNS düzenlemektir. Bu genellikle nameserver değiştirdikten sonra olur: kayıtları registrar'da güncellersiniz ama DNS aslında başka yerde barındırılır (veya tersi). Bir panel doğru görünürken herkese açık sonuç değişmez.

Bir diğer klasik hata, sağlayıcınızın desteklemediği root domain'e CNAME koymaya çalışmaktır. ALIAS veya ANAME tarzı bir kayıt gerekiyorsa DNS sağlayıcınız bunları sunuyor olabilir.

IPv6 da baş ağrısı yaratabilir. Eski bir AAAA kaydını bırakmak bazı ziyaretçileri yanlış sunucuya gönderirken diğerleri IPv4 ile doğru hedefe gider.

“İhtimale karşı” kayıtlarla dikkatli olun. Birden fazla A kaydı, yanlış hedef varsa istemeden yük dengeleme gibi davranabilir, özellikle bir özel domaini barındırılan bir uygulamaya işaret ediyorsanız.

Son bir kural: saati yeniden başlatmayı bırakın.

• Kayıtları her birkaç dakikada bir değiştirmeyin.
• Eski ve yeni hedefleri aynı anda karıştırmayın.
• Sonuçları değerlendirmeden önce önbelleklerin yerleşmesini bekleyin.

Küçük, sakin değişiklikler sürekli müdahaleden daha etkilidir.

Gerçekçi bir örnek: www çalışıyor ama root domain çalışmıyor

Yeni bir uygulama başlattınız ve hem example.com hem de www.example.com kurdunuz. Birkaç dakika sonra www.example.com sorunsuz açılıyor, ancak root domain DNS hatası gösteriyor, eski bir site yükleniyor veya HTTPS beklemede kalıyor. Bu desen yaygındır ve genellikle küçük bir sebepten olur.

Sıkıcı soruyla başlayın: doğru yerde DNS düzenliyor musunuz? Domaininiz bir firmada kayıtlı ama DNS başka bir firmada barındırılıyorsa, kayıtları sürekli değiştirmek hiçbir faaliyeti kamuya yansıtmaz. Önce nameserver'ları kontrol edin, sonra bu nameserver'ların işaret ettiği sağlayıcının DNS panelini açın.

Sonra iki hostu karşılaştırın. www tipik olarak bir CNAME'dir. Root domain daha zordur: birçok sağlayıcı apex'e CNAME koymaya izin vermez, bu yüzden genellikle bir IP'ye A kaydı veya sağlayıcı destekliyorsa ALIAS/ANAME tarzı kayıt gerekir.

Uygulamada işe yarayan bir karar yolu:

• Nameserver'lar yanlış veya beklenmedik mi? Önce bunu düzeltin.
• Nameserver'lar doğru ama example.com kaydı yok (veya başka yere işaret ediyor)? Apex kaydını düzeltin.
• Kayıtlar doğru görünmesine rağmen davranış cihaz veya ağa göre farklı mı? Yayılmayı ve önbellekleri bekleyin.
• DNS doğru çözülüyor ama HTTPS başarısız mı? SSL, tutarlı DNS'e bağlı olarak bekliyor olabilir.

Doğru son durum sıkıcıdır: hem example.com hem www.example.com aynı uygulamaya gider, biri kanoniktir (diğerinden yönlendirme olur) ve HTTPS geçerlidir.

5 dakikada çalıştırabileceğiniz hızlı kontrol listesi

Bir domain kurulumu başarısız olduğunda, çoğu çözüm birkaç hızlı kontrolden gelir. Başka bir şey yapmadan önce bunları çalıştırın.

• DNS'i doğru yerde düzenlediğinizden emin olun (panelinizi domainin yetkili nameserver'larıyla eşleştirin).
• Hostname ve hedefin tam eşleştiğini doğrulayın (alt alan eksik değil, fazladan nokta yok). Kayıt tipinizi (A, AAAA, CNAME, TXT) hostun beklediğiyle karşılaştırın.
• Çakışmaları kaldırın (aynı isimde CNAME + diğer kayıtlar veya artık ihtiyaç duymadığınız eski A/AAAA kayıtları).
• İki farklı bakış noktasından kontrol edin (mobil veri ve Wi‑Fi). Biri çalışıp diğeri çalışmıyorsa genellikle önbellekleme veya yayılmadır.
• TTL'e saygı gösterin. Eğer TTL 300 saniyeyse, yargılamadan önce 5–10 dakika bekleyin. TTL 3600 ise, saate yakın bir bekleme bekleyin.

DNS açıkça doğruysa, sonra SSL'i kontrol edin. Birçok platform sertifikayı domain tutarlı şekilde doğru hedefe işaret edene kadar vermez. Çok erken kontrol ederseniz normal bir gecikmeyi gerçek bir hata sanabilirsiniz.

Koder.ai üzerinde özel bir alan ekliyorsanız, domain kurulum ekranını beklenen hedef için referans alın, sonra DNS yayılana kadar durup SSL'i yeniden kontrol edin.

Sonraki adımlar: her lansman için domain kurulumunu tekrarlanabilir hale getirin

DNS ve SSL hatalarını tekrarlamamanın en hızlı yolu her proje için kısa bir “domain kurulum notu” tutmaktır. Bu, bir dahaki lansmanda kopyalayabileceğiniz yeniden kullanılabilir bir çalışma talimatıdır.

Basit bir domain kurulum notu şablonu

Bunu proje dokümanlarınızda tutun ve DNS'e dokunmadan önce doldurun:

• Domainler ve host adları (root, www ve varsa alt alanlar)
• Beklenen kayıt tipleri ve hedefler (A, CNAME, TXT) ve bunların nereden geldiği
• DNS'in nerede düzenlendiği (hangi sağlayıcı) ve aktif nameserver'lar
• SSL beklentileri (kim veriyor, "hazır" görünümü neye benziyor)
• Çalıştıracağınız doğrulama adımları (araç ve beklenen sonuç)

Lansman sırasında bir kişiyi DNS sorumlusu yapın. DNS en sık iki kişinin aynı anda farklı şeyleri “düzeltmeye” çalışmasıyla bozulur (ör. biri nameserver'ı değiştirirken diğer kişi kayıtları düzenler).

Hosting tarafında güvenli geri dönüşler planlayın. Platformunuz snapshot veya rollback destekliyorsa yönlendirmeyi değiştirmeden önce bir snapshot alın ki bir değişiklik üretimi bozarsa hızlıca eski duruma dönebilesiniz. Koder.ai üzerinde çalışıyorsanız, Planning Mode'u kullanarak domain adımlarını yazıp sırayla uygulayabilir ve bir değişiklik üretimi bozarsa geri alabilirsiniz.

Ne zaman yükseltmelisiniz (ve kime)

DNS'in doğru olduğunu doğruladıysanız ve hâlâ hatalar görüyorsanız tahmin etmeyi bırakın ve kanıtla yükseltin:

• Registrar nameserver'ların kilitli olduğunu gösteriyor veya değiştiremiyorsunuz
• DNS düzenlemeleri beklenen TTL penceresinden sonra hâlâ görünmüyor
• DNS doğru çözüldükten sonra SSL uzun süre başarısız oluyor (dakikalar değil saatler)
• Kaldıramadığınız çakışan kayıtlar var (sağlayıcı arayüz hatası veya split DNS)

Yükseltirken hostname, beklenen kayıtlar, mevcut çözücü sonuçları ve zaman damgalarını ekleyin. Bu, yavaş bir gidip gelmeyi hızlı bir çözüme çevirir.