Site açılmıyor, tarayıcı ERR_NAME_NOT_RESOLVED veriyor, ama sunucu SSH ile yanıt veriyor ve curl -I http://127.0.0.1 da 200 döndürüyor. Yani sorun web sunucusunda değil; alan adı ile sunucu arasında bir yerde kayboldunuz. Bu neredeyse her zaman DNS panelindeki bir kaydın yanlış olduğu ya da doğru olduğu ama henüz yayılmadığı anlamına gelir. Bu iki durumun farkı beş dakikada anlaşılabilir, nereye bakacağınızı bilmeniz şartıyla.
Herhangi bir değişiklikten önce mevcut durumu panelden değil, dışarıdan görün. Panel sizin kaydettiğinizi gösterir; çözümleyiciler ise internette gerçekten yayılmış olanı gösterir. TTL yüksek olduğunda bu ikisi saatlerce birbirinden farklı olur.
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +trace example.comEğer 1.1.1.1 ve 8.8.8.8 yanıtları aynı değilse, yayılımın ortasındasınız ve beklemekten başka yapacak bir şey yok. İkisi de aynı yanlış IP'yi veriyorsa, kayıt hatalıdır. NXDOMAIN alıyorsanız, kayıt hiç yok ya da yanlış zone'a kaydedilmiş. Kökten authoritative'e kadar tüm zinciri görmek için DNS kayıtları sorgulama aracını da kullanabilirsiniz; aynı çıktıyı okunabilir şekilde gösterir.
Hangi kaydı değiştirmelisiniz
Kafa karışıklıklarının çoğu, dört kayıt türünün birbirine benzemesi ama işlerinin tamamen farklı olmasından başlar.
| Tür | İşi | Örnek değer |
|---|---|---|
A | Adı IPv4'e bağlar | example.com. 3600 IN A 185.10.20.30 |
AAAA | Aynı işi IPv6 için yapar | example.com. 3600 IN AAAA 2a01::1 |
CNAME | Adı başka bir ada bağlar | www 3600 IN CNAME example.com. |
MX | E-posta hedefini belirler | example.com. 3600 IN MX 10 mail.example.com. |
Çoğu kişiyi yere seren nokta: CNAME alan adı kökünde (@) izin verilmez. Panel izin verse bile, bazı çözümleyiciler onu yok sayar, bazıları ise tüm zone'u geçersiz görür. Kök için her zaman A koyun. Eğer bir sağlayıcı "düzleştirilmiş CNAME" veya ALIAS diyorsa, o nihai yanıtta A'ya dönüştürülen özel bir kayıttır, gerçek CNAME değil.
Alt alan adları için durum tersidir: CNAME daha iyi bir seçimdir çünkü hedef sunucunun IP'si değişirse panele dokunmanıza gerek kalmaz. Sadece şunu unutmayın: CNAME ile aynı addaki başka bir kayıt bir arada bulunamaz. mail'i CNAME yaptıysanız, aynı ada aynı zamanda MX koyamazsınız.
TTL nasıl seçilir
TTL'nin birimi saniyedir ve çözümleyicilerin yanıtı ne kadar süre önbelleğe alabileceğini söyler. Panelde gördüğünüz sayı genellikle 300 ile 86400 arasındadır. En kısa seçenek her zaman doğru değildir; her TTL düşüşü, ad sunucularınıza daha fazla sorgu ve üzerlerinde daha fazla yük demektir.
- Canlı ve istikrarlı site: 3600 ila 86400. Daha azının hiçbir faydası yok.
- Planlı taşınmadan önce: 24 ila 48 saat önce 300'e düşürün, sabitlendikten sonra geri alın.
- Dinamik kayıtlar veya DDNS: 60 ila 300, yoksa IP değişir ve kullanıcı hâlâ eski adresi görür.
- SPF ve DKIM gibi e-posta kayıtları: Dokunmayın. E-posta değişiklikleri web'den daha yavaş oturur ve alıcıların kendi önbellekleri vardır.
Az söylenen gerçek bir kısıt: TTL'yi siz belirlersiniz, ama çözümleyiciler ona uymak zorunda değildir. Bazı yerel ISP'ler bildirilen TTL'nin birkaç katı kadar önbelleğe alır. TTL'yi 300 yaptıysanız ve yarım saat sonra hâlâ eski IP'yi görüyorsanız, muhtemelen sorun sizde değil. Bu davranışın ayrıntılarını DNS yayılımı nedir ve neden zaman alır yazısında sayısal örneklerle açıkladım.
Canlı sitede güvenli kayıt değişikliği sırası
İşte çoğu arıza burada olur. İşin sırası, işin kendisinden daha önemlidir.
- Mevcut kaydın TTL'sini 300'e düşürün ve eski önbelleklerin süresi dolana kadar en az bir tam TTL bekleyin.
- Yeni hedefi alan adından bağımsız test edin:
curl -I --resolve example.com:443:185.10.20.40 https://example.com. Burada SSL hatası verirse, henüz hazır değilsiniz. - Kaydı düzenleyin, silip yeniden oluşturmayın. Silip yeniden oluşturmak, adın hiç çözümlenmediği bir pencere yaratır.
dig +short A example.com @1.1.1.1ile yeni IP'nin geldiğini doğrulayın.- 24 saat stabil kaldıktan sonra TTL'yi önceki değerine döndürün.
Eğer yeni sunucuya taşınma söz konusuysa ve SSL de işin içindeyse, kayıt ve sertifika düzeninin sırasını Alan adını sanal sunucuya bağlama yazısında adım adım yazdım; yaygın hata, sertifikayı kayıt değişikliğinden önce düzenlemek ve değişiklikten sonra alan adının o sertifikaya sahip olmayan bir sunucuya ulaşmasıdır.
Burada hata yapıyorlar
Ticket'larda gördüğüm en yaygın hata şu: kullanıcı A kaydını doğru şekilde değiştiriyor, ama eski bir paylaşımlı hosting'e işaret eden ayrı bir CNAME olan www kaydını unutuyor. Site example.com ile açılıyor, www.example.com ile eski sürümü gösteriyor. Belirtisi şu: kullanıcı "site değişti ama bazıları hâlâ eskisini görüyor" diyor ve sorun aslında önbellek değil. Herhangi bir taşınmadan önce kayıtların tam listesini alın:
dig +noall +answer example.com ANY
dig +short CNAME www.example.comİkinci hata: yalnızca bir alt alan adına ihtiyacınız varken *'ı wildcard olarak koymak. Sonuç, yazım hatalı her adın da sitenize ulaşması ve tarama botlarının alan adınıza binlerce sahte alt alan adı kaydetmesidir. Gerçekten dinamik alt alan adına ihtiyacınız varsa, doğru yöntemi Wildcard kaydı ve dinamik alt alan adı yönetimi yazısında açıkladım.
E-posta kayıtlarına ayrı bakın
A kaydını değiştirmenin e-postaya etkisi yoktur, ama MX'i değiştirmek tüm yazışmayı durdurur. MX üzerinde herhangi bir değişiklikten önce şu komutun çıktısını kaydedin:
dig +short MX example.com
dig +short TXT example.comTXT kaydı genellikle SPF içerir ve buradaki yaygın bir hata, tek bir dizede 255 karakter sınırını aşmaktır. Uzun bir SPF'niz varsa, onu birkaç dizeye bölmeniz gerekir; bazı paneller bunu otomatik yapar, bazıları yapmaz ve sonuç, SPF'nizin sessizce geçersiz olması ve e-postaların spam'e gitmesidir. Belirtisi de net değildir: gönderim başarılı, teslimat değil.
Alan adınız .ir ise, fazladan bir katmanınız daha var: ad sunucusu değişiklikleri ve bazı düzenlemeler yalnızca panelden değil, IRNIC tarafından uygulanır. Bu iki yolun farkını ir alan adı kayıt ve yönetim rehberi yazısında ayırdım, çünkü bu alan adlarında iş sırası farklıdır ve hata birkaç gün gecikme yaratır.
Hiçbiri işe yaramadığında
Kayıt doğruysa, TTL geçtiyse ve hâlâ çözümlenmiyorsa, sorun neredeyse her zaman şu üçünden biridir: alan adı panelindeki ad sunucuları gerçek zone ad sunucularına işaret etmiyor, zone yanlış ad sunucusunda oluşturulmuş ya da alan adının süresi dolmuş ve clientHold durumunda. Üçüncü durumu whois example.com | grep -i status ile görün. clientHold görürseniz, DNS'te hiçbir değişiklik kurtarmaz; önce yenilenmesi gerekir. Bu durumların tam kontrol sırasını Pratik DNS sorun giderme rehberi yazısında yazdım ve ticket açmadan önce aynı sırayı bir kez uygulamanızı öneririm.
Hosting hakkında bir not: site paylaşımlı hosting'deyse, genellikle sağlayıcının ad sunucularını ayarlarsınız ve kayıtları onların panelinden yönetirsiniz; bu durumda bazı kayıtlar için eliniz bağlıdır. Linux hosting'de bu kayıtlar aynı panelden düzenlenebilir ve çoğu site için yeterlidir. SRV gibi sıra dışı kayıtlara veya zone üzerinde tam kontrole ihtiyacınız varsa, özel ad sunuculu sanal sunucu daha doğru bir seçimdir.
Herhangi bir değişiklikten önce şunu yapın: dig +noall +answer example.com ANY çıktısını bir yere kaydedin. Site düştüğünde, önceki duruma sahip olmak beş dakika ile beş saat arasındaki farktır.
Sıkça sorulan sorular
A kaydını değiştirdikten sonra site neden hâlâ eski IP'yi gösteriyor?
Çünkü çözümleyiciler önceki yanıtı TTL bitene kadar önbelleğe almıştır. Değişiklikten önce TTL'yi düşürmediyseniz, bu durum 24 saate kadar sürebilir. dig +short A example.com @8.8.8.8 ve @1.1.1.1 ile kontrol edin; biri yeni biri eskiyse, sadece beklemelisiniz.
Koyabileceğim en düşük TTL nedir?
Çoğu panel en az 60 saniyeyi kabul eder, bazıları 300 saniyeye kadar sınırlar. 60 saniyeden azının pratikte faydası yoktur çünkü çözümleyiciler ona uymak zorunda değildir ve yalnızca ad sunucunuzdaki sorgu yükünü artırır.
CNAME kaydını alan adı köküne koyabilir miyim?
Hayır. DNS standardı kökte CNAME'e izin vermez çünkü zorunlu NS ve SOA kayıtlarıyla çakışır. Kök için A kullanın. Bir sağlayıcının ALIAS veya düzleştirilmiş CNAME adında bir seçeneği varsa, o nihai yanıtta A'ya dönüştürülen özel bir kayıttır.
MX kaydını değiştirmenin önceki e-postalara etkisi nedir?
Daha önce teslim edilmiş e-postalar olduğu gibi kalır. Ancak yayılım aralığında yolda olan e-postalar eski sunucuya ulaşıp orada reddedilebilir. Eski sunucuyu kapattıysanız, birkaç saat e-posta kaybedilir; MX'i değiştirmeden önce eski sunucunun hâlâ yanıt verdiğinden emin olun.