Google Search Console bir TXT kaydı istedi, siz de panele girip eklediniz. Ya da bir yazılımcı "blog alt alan adını şu IP'ye çevirir misiniz" dedi, A kaydını yazdınız. Panel yeşil bir bildirim gösterdi: "Kayıt başarıyla eklendi." Otuz saat sonra doğrulama sayfasına döndünüz ve aynı cevabı aldınız: kayıt bulunamadı. Aradığınız her Türkçe kaynak size aynı cümleyi kuruyor — "DNS propagasyonu 24-48 saat sürer, biraz daha bekleyin."
Bu cümle bir vakada doğrudur, dokuz vakada zaman kaybıdır. Propagasyon gerçek bir olgudur ama tek bir durumu açıklar: kayıt yetkili sunucuda gerçekten yayında ve bazı çözümleyiciler eski cevabı hâlâ önbellekte tutuyordur. Kayıt hiç yayınlanmadıysa beklemek hiçbir şeyi değiştirmez; 48 saat sonra da aynı ekrana bakıyor olursunuz. Bu iki dünyayı birbirinden ayıran tek bir test var ve o testi yapmadan atılan her adım tahmindir.
Bu yazıda önce o testi yapıyoruz. Sonra kaydın neden yayınlanmadığını açıklayan on somut nedeni sırayla eliyoruz: kaydı yanlış panele girmek, ana alan adı için @ yerine alan adını yazmak, değerin sonundaki noktayı unutmak, aynı isimde CNAME çakışması, silinmeyen eski kayıt, wildcard gölgesi, Cloudflare'in turuncu bulutu, bozulmuş TXT değeri, negatif önbellek ve sağlayıcının ayrı yayınlama adımı. Her maddenin sonunda o maddeyi kesin olarak doğrulayan ya da eleyen tek satırlık bir komut var.
Bekleyeyim mi? Önce Yetkili Nameserver'a Doğrudan Sorun#
Normal bir DNS sorgusu (dig ornek.com) size çözümleyicinin önbelleğindeki cevabı verir. O cevap eski olabilir, bu yüzden hiçbir şey kanıtlamaz. Kaydın yayında olup olmadığını öğrenmenin tek yolu, aradaki önbellekleri atlayıp alan adının yetkili nameserver'ına doğrudan sormaktır.
İki adım:
# 1) Alan adının yetkili sunucularını öğren
dig +short NS ornek.com
# 2) Eklediğin kaydı doğrudan o sunuculardan birine sor
dig @ns1.saglayiciniz.com +noall +answer TXT ornek.com
dig @ns1.saglayiciniz.com +noall +answer A blog.ornek.com
Sonucu şöyle okuyun:
| Yetkili sunucudaki cevap | Anlamı | Ne yapmalısınız |
|---|---|---|
| Kayıt doğru değerle dönüyor | Kayıt yayında, sorun önbellekte | Bekleyin; TTL kadar sürer |
| Kayıt hiç dönmüyor (boş cevap) | Kayıt hiç yayınlanmamış | Aşağıdaki listeye geçin, beklemenin faydası yok |
| Kayıt dönüyor ama değer farklı | Yanlış değer yazılmış veya eski kayıt duruyor | 3, 4 ve 6. maddelere bakın |
SERVFAIL / sunucuya ulaşılamıyor | Yetkili sunucu yanıt vermiyor veya DNSSEC hatası | Sağlayıcıya bildirin |
Bu tabloda ikinci satıra düştüyseniz — ki en yaygın durum budur — geri kalan yazı sizin için. Birinci satıra düştüyseniz sorununuz gerçekten önbellek; DNS propagasyonu yazısı o durumu ayrıntılı ele alıyor. Sorgu sözdiziminde takılırsanız dig ve nslookup ile DNS sorgulama rehberi elinizin altında olsun.
1. Kayıt Yanlış Panelde Duruyor#
Uzak ara en sık neden bu. Alan adını A firmasından aldınız, hostingi B firmasından, arada bir de Cloudflare hesabı var. Üçünün de panelinde "DNS Yönetimi" başlıklı bir ekran var ve üçü de kaydınızı memnuniyetle kabul edip kaydediyor. Ama dünya cevabı yalnızca NS kayıtlarının işaret ettiği sunuculardan alır. Diğer iki paneldeki kayıtlar dosyada durur, ekranda görünür, hiçbir yere ulaşmaz. Üstelik hata da vermez — sessizce orada bekler.
# Yetki kimde? Dönen isimler hangi firmaya aitse kayıt oraya girilir.
dig +short NS ornek.com
Dönen değer ns1.cloudflare.com gibiyse hosting panelindeki Zone Editor tamamen etkisizdir; ns1.hostingfirmasi.com gibiyse alan adı firmasının DNS ekranı etkisizdir. Bu ayrımın kurumsal panellerdeki karşılıkları için DNS kayıtları hangi panelden değiştirilir yazısına bakın.
Bir ince ayrıntı daha: alan adının TLD tarafındaki delegasyonu ile zone içindeki NS kayıtları farklı olabilir. Kayıt firmasında nameserver'ı değiştirdiniz ama zone içindeki NS kayıtları eski kaldıysa bazı çözümleyiciler eski sunucuya gider. İkisini karşılaştırın:
# Zone'un kendi NS kayıtları
dig +short NS ornek.com
# TLD'nin delegasyonu (üst otoritenin ne dediği)
dig +noall +authority NS ornek.com @a.gtld-servers.net
2. Ana Alan Adı İçin @ mi, Boş mu? ornek.com.ornek.com Tuzağı#
Panellerdeki "Ad", "Host", "Name" alanı neredeyse her zaman zone'a görelidir. Yani oraya blog yazarsanız kayıt blog.ornek.com olur. Ana alan adının kendisi için kayıt açarken ornek.com yazmak da aynı mantıkla işler ve ornek.com.ornek.com diye var olmayan bir isim üretir. Panel bunu hata olarak görmez; teknik olarak geçerli bir alt alan adıdır.
Ana alan adı için doğru değer sağlayıcıya göre @, boş bırakmak ya da tam nitelikli ornek.com. (sondaki nokta ile) olur. Hangisinin geçerli olduğunu tahmin etmek yerine ölçün:
# Bu komut bir cevap dönüyorsa hatayı bulmuşsunuzdur
dig +short A ornek.com.ornek.com
Aynı hata alt alan adlarında da olur: blog yerine blog.ornek.com yazınca kayıt blog.ornek.com.ornek.com olarak açılır. Kural basit — panelde alan adının kendisini bir daha yazmayın.
3. Değerin Sonundaki Nokta Unutulmuş#
Bu tuzak, ad alanının değil değer alanının hikâyesidir ve özellikle CNAME, MX, NS, SRV ve PTR kayıtlarında karşınıza çıkar. Ham zone sözdizimini kabul eden panellerde (cPanel'in gelişmiş editörü, BIND, bazı kayıt firmalarının "raw" modu) sonunda nokta olmayan bir değer göreli kabul edilir ve sonuna zone adı eklenir.
; YANLIŞ — sonuna zone eklenir, hedef ghs.google.com.ornek.com. olur
www 3600 IN CNAME ghs.google.com
; DOĞRU — mutlak isim, sondaki nokta zorunlu
www 3600 IN CNAME ghs.google.com.
Aynı şey MX için de geçerlidir: 10 mail.saglayici.com yazarsanız hedef mail.saglayici.com.ornek.com. olur ve o isim çözümlenmediği için tüm postalar geri döner. Grafik panellerin çoğu noktayı kendisi ekler, ham editörler eklemez. Hangi tarafta olduğunuzu dönen cevaba bakarak anlarsınız:
# Dönen hedefin sonuna zone adınız eklenmişse nokta unutulmuş demektir
dig +short CNAME www.ornek.com
dig +short MX ornek.com
4. Aynı İsimde CNAME Varsa Diğer Kayıtlar Çalışmaz#
DNS standardı nettir: bir isimde CNAME kaydı varsa o isimde başka veri bulunamaz. www için bir CNAME tanımlıyken aynı www adına TXT, A veya MX eklemeye çalışırsanız sonuç sağlayıcıya göre değişir — kimi panel kaydı reddeder, kimi kabul edip yayınlamaz, kimi de yayınlar ama çözümleyiciler CNAME'i görüp diğerini yok sayar. Belirti hep aynıdır: kayıt panelde durur, dışarıdan görünmez.
Aynı kuralın ana alan adındaki hâli daha da sinsidir. Ana alan adında zaten SOA ve NS kayıtları bulunmak zorundadır, dolayısıyla oraya CNAME hiçbir koşulda konulamaz. "Ana alan adını Netlify'a CNAME ile bağlayın" tarifini uygulamaya çalışıp başarısız olmanızın nedeni budur; sağlayıcınızın ALIAS, ANAME ya da "CNAME flattening" özelliğini kullanmanız gerekir. Ayrımın ayrıntısı için CNAME kaydı nedir yazısına bakabilirsiniz.
# Bu isimde CNAME var mı? Varsa oraya başka kayıt eklenemez.
dig +short CNAME www.ornek.com
5. Eski Kayıt Silinmemiş: İki Cevap, Yarı Yarıya Doğru#
Yeni kaydı eklediniz ama eskisini silmediniz. Şimdi aynı isimde iki A kaydı var. DNS bunu hata saymaz; iki adresi de döner ve çözümleyiciler ikisi arasında dönüşümlü davranır. Sonuç: ziyaretçilerin yarısı yeni sunucuyu, yarısı eskisini görür. Siz test ettiğinizde bazen çalışır, bazen çalışmaz — ve bunu propagasyona bağlarsınız.
Aynı senaryo MX'te postaların bir kısmının eski sunucuya düşmesine, TXT'te ise daha kötüsüne yol açar: alan adında iki ayrı SPF kaydı bulunması standarda göre kalıcı hatadır (permerror) ve alıcı taraf ikisini de yok sayabilir.
# Beklediğinizden fazla satır dönüyorsa eski kayıt duruyordur
dig +short A ornek.com
dig +short MX ornek.com
dig +short TXT ornek.com | grep -c 'v=spf1'
Son komut 1 dışında bir sayı dönerse SPF tarafında sorun var demektir.
6. Wildcard Kaydı Özel Kaydınızı Gölgeliyor mu?#
Zone'unuzda *.ornek.com şeklinde bir wildcard varsa mantık çoğu kişinin beklediğinin tersine işler. Wildcard, sorulan isimde hiçbir kayıt yoksa devreye girer. O isimde tek bir kayıt bile varsa — üstelik farklı bir tipte olsa bile — wildcard artık o isim için çalışmaz.
Pratikteki hâli şudur: blog.ornek.com için sadece bir TXT kaydı eklediniz. Artık blog adı zone'da "var" sayılır, dolayısıyla blog.ornek.com için A sorgusu wildcard'a düşmez, boş döner ve site açılmaz. Eklediğiniz TXT hiçbir şeyi bozmuş gibi görünmez ama alt alan adını yayından kaldırmıştır. Davranışın tam kuralı için wildcard DNS kaydı yazısına bakın.
# Wildcard çalışıyor mu? (var olmayan rastgele bir isim sorun)
dig +short A rastgele12345.ornek.com
# Özel isim boş dönüyorsa gölgeleme vardır
dig +short A blog.ornek.com
7. Cloudflare Turuncu Bulut: A Kaydı Doğru, Dünya Başka IP Görüyor#
Cloudflare'de bir A veya CNAME kaydının yanındaki bulut turuncuysa o kayıt proxy modundadır. Yetkili cevap artık sizin girdiğiniz IP değil, Cloudflare'in anycast adresidir (104.x.x.x, 172.67.x.x gibi). Kaydınız panelde doğrudur, dig ile sorduğunuzda başka bir şey döner ve karşı taraf "A kaydını bizim IP'mize yönlendirin" talebinin yerine getirilmediğini söyler.
Bu, doğrulama isteyen servislerde (SSL sağlayıcıları, bazı SaaS panelleri), HTTP dışı servislerde (SSH, oyun sunucusu, veritabanı) ve özellikle mail hostname'lerinde sorun çıkarır. MX kaydının işaret ettiği host asla proxy'lenmemelidir — Cloudflare 25 numaralı portu proxy'lemez, posta teslimi kırılır. Çözüm kaydı gri buluta (DNS only) almaktır.
# Dönen IP Cloudflare aralığındaysa kayıt proxy modundadır
dig +short A ornek.com
Kaydın yanındaki bulut simgesine tıklayarak modu değiştirdikten sonra aynı sorguyu tekrarlayın; artık kendi IP'nizi görmelisiniz.
8. TXT Değeri Bozulmuş: Tırnak, Satır Bölme ve Kopyalama Artıkları#
TXT kayıtları elle kopyalanan uzun metinler olduğu için en çok bozulan kayıt tipidir. Sık görülen dört bozulma:
- Panelin tırnağı kendisi eklemesi. Değeri tırnak içinde yapıştırdınız, panel de dışına bir çift daha ekledi. Sonuç
""v=spf1 ...""olur ve hiçbir doğrulayıcı okumaz. - Kopyalarken satır sonu girmesi. Sağlayıcının panelinden Word'e, oradan DNS paneline geçen değerlerde araya görünmez satır sonu veya sekme karakteri girer.
- Akıllı tırnak. Metin editöründen geçen değerde düz tırnak (
") yerine tipografik tırnak (") bulunur. - 255 karakter sınırı. Tek bir TXT dizesi en fazla 255 karakter olabilir. Uzun DKIM anahtarları birden fazla parçaya bölünüp aynı kayıt içinde ardışık dizeler hâlinde yazılmalıdır; ayrı ayrı kayıtlar açmak yanlıştır.
# Değeri karakter karakter görün: kaç dize var, tırnaklar nerede?
dig +short TXT ornek.com
dig +short TXT selector1._domainkey.ornek.com
Çıktıda değerin "..." "..." biçiminde iki parça hâlinde görünmesi normaldir; doğrulayıcılar bu parçaları birleştirir. Aynı isimde birbirinden bağımsız iki ayrı satır dönüyorsa sorun oradadır.
9. TTL Beklentisi Yanlış ve Negatif Önbellek Devrede#
Buradaki en can sıkıcı ayrıntı şu: kaydı eklemeden önce sorgu yaptıysanız, o anda dönen "böyle bir kayıt yok" cevabı da önbelleğe alınmıştır. Buna negatif önbellekleme denir ve süresi kaydın kendi TTL'i değil, zone'un SOA kaydındaki son alandır. Bazı sağlayıcılarda bu değer 300 saniyedir, bazılarında 86400. Yani "önce kontrol ettim, yoktu; sonra ekledim, hâlâ yok" cümlesindeki ilk kontrol, sorunun kendisidir.
# SOA'nın son alanı negatif önbellek süresidir (saniye)
dig +short SOA ornek.com
İkinci beklenti hatası ters yöndedir: TTL'i 60 saniyeye çekmek geçmişi silmez. TTL değişikliği yalnızca bundan sonraki sorgular için geçerlidir; eski TTL ile önbelleğe alınmış cevap, eski süresi dolana kadar orada durur. Bu yüzden TTL düşürme işlemi bir taşımadan en az eski TTL kadar önce yapılır. Değerin nasıl seçileceği için TTL nedir yazısına bakabilirsiniz.
10. Sağlayıcı Değişikliği Yayınlamamış: SOA Serial Kontrolü#
Bazı panellerde "Kaydet" ile "Yayınla" ayrı iki adımdır. Plesk'te değişikliklerin altında ayrı bir onay düğmesi bulunur, bazı kurumsal DNS panellerinde bekleyen değişiklikler kuyruğa girer, kendi BIND sunucunuzu yönetiyorsanız zone dosyasını düzenlemek yetmez — serial numarasını artırıp sunucuyu yeniden yüklemeniz gerekir. İkincil (secondary) nameserver'lar da değişikliği ancak serial arttığında çeker.
Bunu ölçmenin yolu SOA serial numarasıdır: kaydı ekledikten sonra serial artmamışsa değişiklik yayınlanmamış demektir.
# Kayıt eklemeden önce ve sonra çalıştırıp serial'i karşılaştırın
dig +short SOA ornek.com | awk '{print $3}'
# Kendi sunucunuzu yönetiyorsanız
named-checkzone ornek.com /var/named/ornek.com.db
rndc reload ornek.com
Nameserver'ların Hepsi Aynı Cevabı Veriyor mu?#
Bir alan adının genellikle iki ya da daha fazla yetkili sunucusu olur ve çözümleyiciler bunlar arasından rastgele birini seçer. İkincil sunucular zone'u henüz çekmediyse cevaplar farklılaşır: sorgu bazen doğru cevabı verir, bazen vermez. "Bende çalışıyor, müşteride çalışmıyor" tablosunun klasik nedeni budur ve tek tek her sunucuya sormadan görülmez.
# Tüm yetkili sunucuları aynı soruyla sırayla sorgula
for ns in $(dig +short NS ornek.com); do
printf '%-28s %s\n' "$ns" "$(dig +short @"$ns" A blog.ornek.com | tr '\n' ' ')"
done
Çıktıdaki satırlardan biri boşsa ya da farklı bir değer içeriyorsa sorun sizin kaydınızda değil, sağlayıcının zone aktarımındadır; destek kaydı açarken bu çıktıyı ekleyin.
Belirti → Sebep → Doğrulama Komutu#
| Belirti | Muhtemel sebep | Tek satırlık doğrulama |
|---|---|---|
| Yetkili sunucuda kayıt hiç yok | Yanlış panel | dig +short NS ornek.com |
| Kayıt var ama isim tuhaf | @ yerine alan adı yazılmış | dig +short A ornek.com.ornek.com |
| CNAME/MX hedefi çözümlenmiyor | Sondaki nokta unutulmuş | dig +short CNAME www.ornek.com |
| Aynı isimde eklenen kayıt görünmüyor | CNAME çakışması | dig +short CNAME www.ornek.com |
| Bazen eski, bazen yeni sunucu | Eski kayıt silinmemiş | dig +short A ornek.com |
| Alt alan adı hiç açılmıyor | Wildcard gölgelenmiş | dig +short A blog.ornek.com |
| Dönen IP sizin IP'niz değil | Cloudflare proxy açık | dig +short A ornek.com |
| Doğrulama kodu okunamıyor | TXT bozulmuş veya çift | dig +short TXT ornek.com |
| "Önce kontrol ettim yoktu" | Negatif önbellek | dig +short SOA ornek.com |
| Panelde var, sunucuda yok | Yayınlama adımı atlanmış | dig +short SOA ornek.com |
| Sorgu bazen boş dönüyor | İkincil NS senkron değil | for ns in $(dig +short NS ornek.com); ... |
Sıkça Sorulan Sorular#
Kaydı ekledim, kaç saat beklemem gerçekten gerekiyor?#
Beklemeniz gereken süre, kaydın yetkili sunucuda yayında olup olmamasına göre değişir. dig @yetkili-sunucu sorgusu kaydı döndürüyorsa yalnızca çözümleyicilerin önbelleği kadar, yani kaydın TTL değeri kadar beklersiniz; 300 saniyelik bir TTL'de bu beş dakikadır. Yetkili sunucu kaydı döndürmüyorsa beklemek hiçbir işe yaramaz, çünkü ortada yayılacak bir kayıt yoktur.
Panelde kaydı görüyorum ama dig hiçbir şey döndürmüyor, bu nasıl olur?#
Panelde görünmek, kaydın o panelin veritabanında durduğu anlamına gelir; yayında olduğu anlamına gelmez. En sık iki neden vardır: alan adının nameserver'ları o panele ait değildir, dolayısıyla kimse o kaydı sormaz; ya da panel değişikliği henüz yayınlamamıştır. İlkini dig +short NS, ikincisini SOA serial numarasının artıp artmadığına bakarak ayırt edersiniz.
@ mi yazmalıyım, boş mu bırakmalıyım, alan adını mı?#
Sağlayıcıya göre değişir ama alan adının kendisini yazmak neredeyse her zaman yanlıştır. Çoğu panelde ana alan adı için @ kullanılır, bazılarında alan boş bırakılır, ham zone sözdizimi kabul eden editörlerde sonunda nokta olan tam isim yazılır. Hangisini kullandığınızı sınamanın en hızlı yolu, ornek.com.ornek.com gibi çift adı sorgulamaktır; cevap dönüyorsa yanlış biçimi seçmişsiniz demektir.
TTL'i 60 saniyeye çekersem değişiklik hemen mi görünür?#
Hayır. Yeni TTL yalnızca bundan sonra yapılacak sorgular için geçerlidir. Bir çözümleyici eski cevabı 14400 saniyelik TTL ile önbelleğe aldıysa, siz TTL'i 60'a çekseniz bile o çözümleyici dört saat boyunca eski cevabı vermeye devam eder. Bu yüzden TTL düşürme işlemi, planlanan değişiklikten en az eski TTL süresi kadar önce yapılmalıdır.
Aynı isimde hem CNAME hem TXT kaydı tutabilir miyim?#
Hayır. DNS standardı, CNAME bulunan bir isimde başka veri bulunmasına izin vermez. Kimi panel bunu engeller, kimi kabul eder ama kayıt asla beklendiği gibi çalışmaz. Aynı isimde iki farklı kayıt tipine ihtiyacınız varsa CNAME yerine A kaydı kullanmanız gerekir. Ana alan adında ise CNAME hiçbir koşulda kullanılamaz; sağlayıcınızın ALIAS ya da ANAME özelliğine bakın.
Kaydı silip yeniden eklemek işe yarar mı?#
Genellikle hayır, çünkü sorun kaydın içeriğinde değil bulunduğu yerdedir. Silip yeniden eklemek yalnızca değeri yanlış yapıştırdıysanız işe yarar. Öncesinde bu yazıdaki on maddeyi sırayla eleyin; özellikle nameserver kontrolünü yapmadan kaydı yeniden yazmak, aynı hatayı ikinci kez yapmaktan başka bir şey olmaz.