DNS kayıt sorunlarını, yayılma gecikmelerini ve SSL zamanlamasını teşhis etmek için bu özel alan adı sorun giderme kontrol listesini kullanın; basit doğrulama adımları içerir.
“Ö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:
Çoğu zaman yanlış olan tek bir şey vardır:
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.
Ç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.
Ana kayıt türlerinin ne yaptığını şöyle özetleyebiliriz:
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.
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:
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.
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:
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.
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:
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.
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ü:
ns1... ve ns2... gibi nameserver'lar verdiyse, bu tam değerler registrar'da görünmelidir.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.
“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:
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.
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:
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:
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.
İ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.
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.
Hem http:// hem de https:// ile apex ve www adreslerini açın. Bir net “ana” domain ve bir temiz yönlendirme istiyorsunuz.
www) ve diğerini ona yönlendirin.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.
Ç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.
Küçük, sakin değişiklikler sürekli müdahaleden daha etkilidir.
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:
example.com kaydı yok (veya başka yere işaret ediyor)? Apex kaydını düzeltin.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.
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 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.
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.
Bunu proje dokümanlarınızda tutun ve DNS'e dokunmadan önce doldurun:
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.
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:
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.
Genellikle zincirin bir katmanı hatalıdır: DNS çözülmüyor, DNS yanlış hedefe işaret ediyor, sunucu/hosting sizin host adınızı tanımıyor veya HTTPS/SSL henüz tamamlanmamıştır. Önce gördüğünüz kesin hatayı ve yazdığınız tam host adını not edin (apex vs www).
example.com (apex) ve www.example.com ayrı host adlarıdır ve ayrı DNS kayıtlarına sahiptir. Sıkça görülen durum, www için doğru bir CNAME varken apex için A kaydının eksik, yanlış veya DNS sağlayıcınızın desteklemediği bir ayarın olmasıdır.
Alan adının nameserver bilgilerini kayıt kuruluşunuzda kontrol edin ve düzenlediğiniz DNS sağlayıcısıyla karşılaştırın. Yalnızca aktif nameserver'larda listelenen sağlayıcı yetkilidir; başka bir yerde kayıtları düzenlemek, internetin gördüğü sonucu değiştirmez.
Host size IPv4 adresi veriyorsa A kaydı kullanın, IPv6 adresi veriyorsa AAAA kullanın; host size başka bir host adı veriyorsa CNAME kullanın (genellikle www için). TXT kayıtları doğrulama ve challenge içindir ve tam olarak host tarafından istenen isimde oluşturulmalıdır.
Eskimiş veya yanlış bir AAAA kaydı bazı ziyaretçileri IPv6 üzerinden eski sunucuya yönlendirip diğerlerini IPv4 ile doğru hedefe gönderebilir; bu da “bende çalışıyor” karışıklığına yol açar. Hostunuz IPv6 hedefi vermediyse yanlış AAAA kaydını kaldırmak genellikle en basit çözümdür.
Genellikle hosting tarafında yalnızca bir host adı yapılandırılmıştır (sadece apex veya sadece www), ya da birbirine rakip yönlendirme kuralları vardır; bu da HTTP ve HTTPS veya apex ve www arasında geri dönüşlere neden olur. Tek bir kanonik host seçin, her iki hostu yapılandırın ve yalnızca tek bir temiz yönlendirme yolu bırakın.
Evet. DNS doğru olsa bile HTTPS zaman alabilir; sertifika sağlayıcısı domaini doğrulayana kadar sertifika verilmez. DNS doğru hedefe tutarlı şekilde işaret ettikten sonra beklemek genellikle doğru harekettir. DNS'i sürekli değiştirmek süreci tekrar başlatır.
TTL, çözücülerin bir cevabı ne kadar süreyle önbelleğe alacağını belirtir; bu yüzden bir kaydı düzelttikten sonra bazı ağlar eski değeri TTL süresi dolana kadar göstermeye devam edebilir. İki farklı ağdan (ör. Wi‑Fi ve mobil veri) test edin ve birkaç dakikada bir DNS değişikliği yapmaktan kaçının.
Tekrar üretilebilir bir kontrol kullanın: dig veya nslookup ile A/AAAA/CNAME/TXT yanıtlarının beklenen hedefle eşleştiğini doğrulayın, sonra hem apex hem de www için http:// ve https:// adreslerini test edin. Bir ağ farklı DNS cevabı gösteriyorsa bu genellikle önbelleklemedir; tüm ağlar yanlış cevap veriyorsa yapılandırma hatasıdır.
Koder.ai üzerinde, uygulamanın domain kurulum ekranını beklenen DNS hedefi için kaynak olarak kabul edin, sonra yetkili sağlayıcıda DNS'in buna tam olarak uymasını sağlayın. DNS'i değiştirdikten sonra SSL kontrolü yapmadan önce zamana bırakın ve canlı projede yönlendirme değiştiriyorsanız snapshot/rollback kullanarak geri dönmeyi planlayın.