Domain ve Hosting Nasıl Bağlanır? Nameserver ve DNS Ayarları Rehberi

Taşıma öncesi ilk görüşmelerde en sık karşıma çıkan tablo şu: alan adı yıllar önce bir firmadan alınmış, hosting başka bir firmada, e-posta da geçen yıl Microsoft 365’e taşınmış. Şimdi site yeni sunucuya geçecek ve kimse “DNS’te şu an ne var?” sorusuna net cevap veremiyor. Bu yazıyı o masadaki kişiler için yazdım: hangi panelde, hangi alana, ne yazacağınızı ve neyi bozmamanız gerektiğini adım adım anlatıyorum.

Bağlama işinin özü tek cümledir: internetteki herkes alan adınızı sorduğunda doğru sunucunun IP adresini alabilmelidir. Bu cevabı hangi sunucunun vereceğini nameserver kayıtları, cevabın kendisini A, CNAME, MX gibi DNS kayıtları belirler. Aşağıdaki iki yol aynı sonuca farklı yerden dokunur.

Üçüncü bir yol daha var: nameserver’ları Cloudflare gibi bir DNS sağlayıcısına verip hostingi oradan A kaydıyla göstermek. Teknik olarak bu da bir nameserver değişikliğidir; yani Yol 1’in riskleri (eksik MX, unutulan TXT) aynen geçerlidir. Avantajı, DNS’in hosting firmasından bağımsız hâle gelmesidir; hosting değiştirdiğinizde yalnız bir A kaydını güncellersiniz.

Alan adı, hosting ve DNS üç ayrı hizmettir ve çoğu zaman üç ayrı firmada durur. Karışıklığın büyük kısmı bunların tek bir “site” paketi gibi düşünülmesinden doğar. Alan adı bir kayıttır; hosting dosyalarınızın çalıştığı sunucudur; DNS ise ikisini birbirine bağlayan, “bu ad hangi adreste?” sorusunu cevaplayan dağıtık bir rehber sistemidir.

Bir ziyaretçi tarayıcıya ornek.com.tr yazdığında bilgisayarı önce bir çözümleyiciye (resolver) sorar. Bu genellikle internet servis sağlayıcınızın DNS sunucusu ya da 8.8.8.8, 1.1.1.1 gibi açık bir çözümleyicidir. Çözümleyici cevabı bilmiyorsa sırayla kök sunuculara, oradan .tr sunucularına gider; .tr ona “bu alan adının yetkili sunucuları şunlar” der. Son durak yetkili DNS sunucusudur; IP adresini o verir. Çözümleyici cevabı TTL süresi boyunca önbelleğinde tutar ve aynı soruyu soran herkese oradan cevap verir.

Kayıt kuruluşu (registrar)

Alan adını satın aldığınız ve yenilediğiniz firma. Nameserver ayarı bu firmanın panelinde yapılır.

Kayıt otoritesi (registry)

Uzantının ana veritabanını tutan kurum: .com için Verisign, .tr için BTK bünyesindeki TRABİS. Kayıt kuruluşu sizin adınıza buraya yazar.

Nameserver (yetkili DNS)

Alan adınızın kayıtlarını (A, MX, TXT…) barındıran ve soruları son noktada cevaplayan sunucu. Hosting firmasının, Cloudflare’in veya kayıt kuruluşunun olabilir.

DNS bölgesi (zone)

Bir alan adına ait kayıtların tamamı. Nameserver değişince bölge de başka bir sunucuya taşınmış olur.

Çözümleyici (resolver)

Ziyaretçinin sorusunu zincir boyunca takip eden ve cevabı TTL süresince önbellekte tutan sunucu.

Hosting (web sunucusu)

Site dosyalarının ve veritabanının çalıştığı makine. DNS’in gösterdiği IP adresi bu sunucuya aittir.

Bu ayrımın pratik sonucu şu: hosting değiştirmek için alan adını transfer etmeniz gerekmez. Alan adı aynı firmada kalır, yalnız DNS’in gösterdiği adres değişir. Hosting, VPS ve bulut arasındaki farklara hosting, VPS, bulut ve dedicated sunucu farkı yazımızda ayrıca değindik.

İki yöntem de çalışır; asıl soru, değişikliğin neleri sürükleyeceğidir. Nameserver değiştirdiğinizde bölgenin tamamı yeni sunucuya geçer. Eski bölgede bulunan ama yenisine eklenmeyen her kayıt o anda yok olur. A kaydı yönteminde ise yalnız değiştirdiğiniz satır değişir.

Nameserver’a hiç dokunulmaması gereken durumlar da var: DNS’i Cloudflare’de, kendi BT ekibinde veya bir kurumsal DNS hizmetinde yönetilen şirketler; birden çok alt alan adının farklı servislere (B2B portalı, ERP web servisi, VPN) dağıldığı yapılar. Bu durumlarda yalnız web sunucusunu gösteren A kaydını değiştirip geri kalan her şeyi olduğu gibi bırakmak hem daha güvenli hem de geri alınması kolay bir yoldur.

Kayıt kuruluşlarının panelleri farklı görünse de akış aynıdır. Menü adları genelde “Alan Adlarım → Yönet → DNS / Nameserver Yönetimi” biçimindedir. Aşağıdaki sıra, e-postayı ve doğrulama kayıtlarını kaybetmeden ilerlemek için kurduğumuz sıradır.

1. 1Mevcut bölgenin dökümünü alınEski DNS sağlayıcısından bölge dışa aktarımı (zone export) isteyin ya da panelin ekran görüntüsünü alın. Alt alan adları dışarıdan listelenemez; bu yüzden döküm, tahmin yürütmekten daha güvenlidir.
2. 2Yeni nameserver adlarını öğreninHosting firmanızın karşılama e-postasında veya destek ekibinde ns1.… ve ns2.… adları bulunur. İkisini de yazacaksınız; kayıt kuruluşları ve kayıt otoriteleri genellikle en az iki nameserver ister.
3. 3Yeni bölgeyi önceden doldurunPlesk’te alan adının DNS ayarları sayfasında MX, SPF, DKIM, DMARC, Microsoft/Google doğrulama TXT’leri ve alt alan adlarının bulunduğunu kontrol edin. Eksik satırları nameserver değişmeden önce ekleyin.
4. 4DNSSEC açıksa önce DS kaydını kaldırınAlan adında DNSSEC etkinse kayıt kuruluşu panelindeki DS kaydı eski sağlayıcının anahtarını gösterir. Bu kayıt kalırsa yeni bölge doğrulanamaz ve çözümleyiciler SERVFAIL döner. DS kaydını kaldırın ve önbelleklerden düşmesini bekleyin: .com’da DS kaydının TTL’sini 86.400 saniye (1 gün) ölçtük; bir gün beklemek güvenli taraftır.
5. 5Nameserver alanlarını değiştirinEski nameserver satırlarını silin, yenilerini yazın ve kaydedin. Panel “işleminiz alındı” dediğinde kayıt otoritesine gönderilmiştir; görünür olması birkaç dakika sürebilir. Bazı uzantılarda kayıt otoritesi, yeni nameserver’ların alan adı için cevap verip vermediğini değişiklikten önce denetler; 3. adımı atlamamanın bir nedeni de bu.
6. 6Eski bölgeyi silmeyin, doğrulayınBazı çözümleyiciler eski nameserver’ları delegasyon süresi boyunca sormaya devam eder. Eski bölge o sürede kapanırsa bu ziyaretçiler hiç cevap alamaz. Değişikliği dig NS ornek.com.tr +trace ile uçtan uca izleyin.

# Mevcut kayıtları kaydetmek için (alt alan adlarını ayrıca ekleyin)
for t in A AAAA CNAME MX TXT NS CAA; do
  echo "== $t"; dig +short $t ornek.com.tr
done
dig +short CNAME www.ornek.com.tr
dig +short TXT _dmarc.ornek.com.tr
dig +short CNAME autodiscover.ornek.com.tr

# Delegasyonu kayıt otoritesinden doğrudan sorun
dig NS ornek.com.tr +trace

Bir DNS bölgesi satırlardan oluşur. Her satırın bir adı (hangi adres için), bir türü (ne tür bilgi), bir değeri ve bir TTL’si (önbellekte kaç saniye tutulacağı) vardır. Panellerde ad alanına @ yazmak alan adının kendisi, yani apex (kök) anlamına gelir; www ya da b2b yazmak alt alan adı oluşturur. Bazı paneller adı tam yazmanızı (www.ornek.com.tr), bazıları yalnız ön eki (www) bekler; aynı satırı iki kez eklemenin en yaygın nedeni budur.

TXT kayıtları sitenin çalışmasını etkilemez ama birçok servisin “bu alan adı gerçekten sizin mi?” sorusunun cevabıdır. Search Console alan adı mülkü google-site-verification=… değerini, Microsoft 365 alan adı eklerken MS=ms… değerini ister. Bu satırlar silinirse servis bir gün doğrulamayı yeniden denediğinde alan adı “doğrulanmamış” durumuna düşebilir. Bir bölgeyi taşımadan önce ilk baktığım yer bu satırlar oluyor: kimse ne işe yaradıklarını hatırlamadığı için en kolay unutulanlar onlar.

CAA kaydı ise sessiz bir güvenlik katmanıdır: 0 issue "letsencrypt.org" yazdığınızda yalnız Let’s Encrypt bu alan adına sertifika verebilir. Sonradan ücretli bir OV/EV sertifika alırsanız onu veren otoriteyi de aynı kayda eklemeniz gerekir; aksi hâlde sipariş doğrulamada takılır.

; ornek.com.tr bölgesi (BIND biçimi, örnek değerler)
$ORIGIN ornek.com.tr.
$TTL 3600
@             300  IN  A      203.0.113.10
www           300  IN  CNAME  ornek.com.tr.
b2b           300  IN  A      203.0.113.20
@                  IN  MX     0 ornek-com-tr.mail.protection.outlook.com.
autodiscover       IN  CNAME  autodiscover.outlook.com.
@                  IN  TXT    "MS=ms00000000"
@                  IN  TXT    "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ~all"
_dmarc             IN  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@ornek.com.tr; fo=1"
@                  IN  CAA    0 issue "letsencrypt.org"

Örnekteki IP’ler belgelendirme için ayrılmış 203.0.113.0/24 bloğundandır; kendi sunucu IP’nizi yazın. Microsoft 365 hedefi ve MS= değeri her kiracıda farklıdır.

A kaydı doğrudan bir IP adresi verir. CNAME ise “bu adın cevabı şu başka adın cevabıyla aynıdır” der; çözümleyici hedef adı ayrıca sorar ve IP’yi oradan alır. Pratikte www için CNAME tercih edilir: sunucu IP’si değiştiğinde yalnız apex’teki A kaydını güncellersiniz, www kendiliğinden takip eder.

• 1.Apex’te A / AAAA@ için IP veren kayıt kullanın; sağlayıcı ana bilgisayar adı veriyorsa ALIAS / flattening.
• 2.www için CNAMEwww → ornek.com.tr. IP değişikliğinde tek satır güncellenir.
• 3.CNAME yalnız başınaCNAME olan adda MX, TXT veya başka kayıt bulunmaz.
• 4.MX ve NS CNAME’e işaret etmezMX hedefi bir A kaydı olan ad olmalıdır; takma ada işaret eden MX bazı sunucularda reddedilir.

CNAME’in katı bir kuralı var: CNAME bulunan bir adda başka hiçbir kayıt bulunamaz. Alan adının kökünde (@) ise her zaman NS ve SOA, çoğu zaman da MX ve TXT bulunur. Bu yüzden apex’e CNAME yazılamaz; yazan paneller ya hata verir ya da kaydı sessizce bozar. Hosting firmanız size bir IP değil de bir ana bilgisayar adı (ör. site-123.platform.example) verdiyse apex için sağlayıcınızın ALIAS / ANAME desteğine veya Cloudflare’in CNAME flattening özelliğine bakın; bu özellikler adı arka planda IP’ye çevirip apex’e A kaydı gibi sunar.

Bir uyarı daha: CNAME zinciri her halkada ek bir sorgu demektir. www → site.ajans.example → lb.platform.example → IP gibi üç halkalı bir zincir çalışır, ama ilk ziyarette çözümlemeyi uzatır ve halkalardan birinin sahibi kaydı değiştirdiğinde siteniz habersiz başka yere gidebilir. Mümkün olduğunca kısa tutun.

ornek.com.tr ve www.ornek.com.tr DNS açısından iki ayrı addır. İkisinin de çalışması için ikisine de kayıt gerekir: apex’te A kaydı, www’da apex’e CNAME. Ama iki adın aynı içeriği ayrı ayrı sunması arama motorları açısından iki kopya site demektir. Bu yüzden birini kanonik (asıl) adres seçip diğerini ona kalıcı 301 yönlendirmesiyle göndermek gerekir.

Önemli olan şu ayrım: yönlendirme DNS’te yapılmaz, web sunucusunda yapılır. DNS yalnız iki adın da aynı sunucuya ulaşmasını sağlar; “www’suzu www’ya gönder” kuralı sunucunun işidir. Plesk’te bunu alan adının Hosting Ayarları sayfasındaki “Tercih edilen alan adı” seçeneğiyle tek tıkla, SEO açısından güvenli 301 olarak açabilirsiniz. Sertifikanın da iki adı birden kapsaması gerekir; yoksa yönlendirmeden önce “Bağlantınız gizli değil” uyarısı görünür.

HSTS (tarayıcıya “bu siteye yalnız HTTPS ile gel” diyen başlık) kullanıyorsanız dikkat: includeSubDomains ile uzun süreli HSTS açtıktan sonra HTTPS’i olmayan bir alt alan adı tarayıcıda açılmaz hâle gelir. HSTS’yi, tüm alt alan adlarının sertifikasından emin olduktan sonra kısa bir süreyle başlatıp uzatın. Taşımaya özgü 301 kurallarını ve yönlendirme haritasını SEO kaybetmeden site taşıma rehberimizde ayrıntılı anlattık; burada tekrar etmiyorum.

Aşağıdaki planlayıcı, alan adınız ve kullandığınız servisler için girmeniz gereken kayıtları tablo hâlinde çıkarır, bağlama yöntemine göre adım listesini yazar ve sık yapılan hataları uyarı olarak gösterir. Tüm hesaplama tarayıcınızda yapılır; girdiğiniz alan adı, IP veya e-posta adresi hiçbir yere gönderilmez.

Sağlayıcıya özgü değerler (Microsoft 365 MX hedefi, DKIM anahtarları, doğrulama kodları) her hesapta farklıdır. Planlayıcı bunları yer tutucu olarak işaretler; gerçek değeri ilgili yönetim panelinden kopyalamanız gerekir. Uyarılar genel kurallardır; özel bir yapınız varsa (birden çok e-posta sağlayıcısı, karma Exchange) teknik ekibinizle birlikte değerlendirin.

; ornek.com.tr — DNS Kayıt Planlayıcı çıktısı
; ';' ile başlayan satırlar yer tutucudur: değeri sağlayıcı panelinden alın.
$ORIGIN ornek.com.tr.
$TTL 3600
@                     300   IN  A      203.0.113.10
www                   300   IN  CNAME  ornek.com.tr.
; @                     3600  IN  MX     0 ornek-com-tr.mail.protection.outlook.com.
autodiscover          3600  IN  CNAME  autodiscover.outlook.com.
; @                     3600  IN  TXT    "MS=msXXXXXXXX"
; selector1._domainkey  3600  IN  CNAME  <M365 Defender panelindeki selector1 hedefi>
; selector2._domainkey  3600  IN  CNAME  <M365 Defender panelindeki selector2 hedefi>
@                     3600  IN  TXT    "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ~all"
_dmarc                3600  IN  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@ornek.com.tr; fo=1"
@                     3600  IN  CAA    0 issue "letsencrypt.org"

Tablodaki sütunlar ne anlatıyor?

Tür / Ad / Değer

Panelinizdeki alanlarla birebir aynı sırada. @ alan adının kendisidir; bazı paneller bu alanı boş bırakmanızı ister.

TTL

Geçiş modunda web kayıtları 300 sn, diğerleri 3600 sn. Geçiş bitince web kayıtlarını da 3600’e çıkarın.

Öncelik

Yalnız MX için anlamlıdır; küçük sayı önce denenir.

Cloudflare bulutu

Turuncu (proxy açık) yalnız web kayıtları içindir; e-posta sunucusunu gösteren kayıtlar gri (DNS only) kalmalıdır.

Bağlama sonrası en sık gelen iki şikâyet “mail gelmiyor” ve “gönderdiğimiz mailler spam’e düşüyor”dur. Birincisi neredeyse her zaman MX’le, ikincisi SPF, DKIM ve DMARC üçlüsüyle ilgilidir. Bu bölüm teslim edilebilirliğin tamamını değil, bağlarken e-postayı korumak için doğru girilmesi gereken dört kaydı anlatıyor.

DMARC’ı üç adımda sıkılaştırın

1. p=none1. aşamaİlk 2–4 haftaHiçbir ileti engellenmez; yalnız rapor toplanır. Hangi servislerin sizin adınıza gönderdiğini burada görürsünüz.
2. p=quarantine2. aşamaRaporlar temizlendikten sonraDoğrulanamayan iletiler spam klasörüne gider. İsterseniz pct= ile önce bir yüzdeye uygulayın.
3. p=reject3. aşamaTüm meşru kaynaklar uyumluysaSahte gönderimler reddedilir. Hiç e-posta göndermeyen alan adlarında doğrudan bu politikayla başlanabilir.

Bu kayıtlar artık isteğe bağlı değil. Gmail, 1 Şubat 2024’ten bu yana kendisine e-posta gönderen herkesten en az SPF veya DKIM, geçerli ileri ve ters DNS (PTR) kaydı, TLS bağlantısı ve Postmaster Tools’ta %0,3’ün altında bir spam oranı bekliyor. Günde 5.000’den fazla ileti gönderenler için çıta daha yüksek: SPF ve DKIM’in ikisi birden, en az p=none politikalı bir DMARC kaydı, “Kimden” alanıyla uyum ve pazarlama iletilerinde tek tıkla abonelikten çıkma. Yahoo da aynı ay toplu göndericiler için benzer kuralları devreye aldı.

Microsoft 5 Mayıs 2025’te Outlook.com, Hotmail ve Live adreslerine 5.000’den fazla ileti gönderen alan adları için aynı yöne gitti: SPF ve DKIM geçmeli, en az p=none politikalı ve uyumlu bir DMARC kaydı bulunmalı. Koşulu sağlamayan iletiler 550 5.7.515 hatasıyla geri dönüyor. Bir KOBİ bu hacme hiç ulaşmayabilir; yine de kimlik doğrulaması eksik bir alan adından giden teklif veya fatura e-postası küçük hacimde de spam klasörüne düşebiliyor.

W3 web hosting paketlerindeki kurumsal e-postada SPF, DKIM ve DMARC kayıtları otomatik oluşturulur; alan adınız bizim nameserver’larımızdaysa ek bir şey girmeniz gerekmez, DNS’iniz başka yerdeyse panelin ürettiği değerleri oraya kopyalarsınız. Microsoft 365 mi Google Workspace mi sorusu için Microsoft 365 Business Basic, Standard ve Premium karşılaştırması yazımıza, lisanslar için lisans satış sayfamıza bakabilirsiniz. Site formlarından gelen bildirimlerin hiç ulaşmaması ayrı bir konu; onu form gelmiyorsa bakılacak yerler yazısında ele alıyoruz.

“DNS yayılması” deyimi yanıltıcıdır; ortada bir yerden bir yere dağıtılan bir şey yok. Değişikliği yaptığınız anda yetkili sunucunuz yeni cevabı verir. Bekleme, dünyadaki çözümleyicilerin eski cevabı önbelleklerinde TTL süresi dolana kadar tutmasından kaynaklanır. Eski kaydın TTL’si 86.400 saniyeyse (1 gün), değişiklikten bir dakika önce sorgu yapmış bir çözümleyici eski IP’yi bir gün daha verebilir.

Buradan çıkan kural basit: TTL’yi değişiklikten önce düşürün, en az eski TTL kadar bekleyin, sonra değiştirin. TTL’si 3600 olan bir A kaydını bir gün önceden 300’e indirirseniz, değişiklik günü çoğu ziyaretçi beş dakika içinde yeni sunucuya geçer. Değişiklik anında TTL’yi düşürmek ise işe yaramaz; eski değeri önbelleğe almış çözümleyiciler eski TTL’yi uygulamaya devam eder.

Nameserver değişikliğinde tablo farklıdır. Çözümleyiciler hangi nameserver’a soracaklarını üst bölgeden (.com, .com.tr) öğrenir ve bu bilginin TTL’sini kayıt otoritesi belirler. Bu süreyi sizin ayarınız kısaltamaz. Kayıt daha önce hiç yoksa (yeni alan adı, yeni alt alan adı) bir de negatif önbellek devreye girer: “böyle bir kayıt yok” cevabı da bir süre saklanır. Bu yüzden yeni alt alan adını oluşturmadan önce test için sorgulamamak, beklemeyi kısaltır.

Genel gözlem: süreler çözümleyicinin davranışına bağlıdır. Bazı çözümleyiciler çok kısa TTL’leri kendi alt sınırlarına yükseltir, bazıları da çok uzun TTL’leri bir günle sınırlar.

DNS Yayılma Süresi Tahmincisi

Aşağıdaki tahminci, değişiklik türüne, uzantıya ve TTL geçmişinize göre “çoğu ziyaretçi” ve “en kötü durum” pencerelerini hesaplar. Delegasyon süreleri Ekim 2026’da kayıt otoritelerinin sunucularından ölçtüğümüz değerlerdir; diğer uzantılar için varsayım kullanılır.

Yayılmayı nasıl kontrol ederim?

Yayılmayı tahmin etmek yerine ölçün. Aşağıdaki komutlar Linux ve macOS terminalinde, nslookup satırları Windows’ta da çalışır. Farklı ülkelerdeki çözümleyicileri tek ekranda görmek için dnschecker.org veya whatsmydns.net gibi siteler pratiktir.

# Belirli bir çözümleyiciye sorun (+short yalnız cevabı yazar)
dig @8.8.8.8 ornek.com.tr A +short
dig @1.1.1.1 www.ornek.com.tr +short

# Yetkili sunucunun gerçek cevabı (önbelleksiz)
dig @ns1.yeni-hosting.example ornek.com.tr A +norec

# Kalan TTL'yi görün (ikinci sütun)
dig @8.8.8.8 ornek.com.tr A +noall +answer

# Windows
nslookup ornek.com.tr 8.8.8.8
ipconfig /flushdns

# macOS yerel önbelleği temizleme
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome'un kendi önbelleği: chrome://net-internals/#dns → Clear host cache

Hosting panellerinin çoğu ücretsiz Let’s Encrypt sertifikasını tek tıkla kurar; Plesk’te yol alan adının SSL/TLS Sertifikaları sayfasındaki Let’s Encrypt seçeneğidir. Ama bu tıklama, DNS yeni sunucuyu göstermeden önce yapılırsa başarısız olur. Let’s Encrypt’in en yaygın doğrulama yöntemi olan HTTP-01, alan adınıza /.well-known/acme-challenge/… adresinden bir dosya ister. İstek DNS’in gösterdiği sunucuya gider; o sunucu hâlâ eski hostingse dosya orada yoktur ve doğrulama düşer.

Doğru sıra şudur: DNS’i değiştirin, dig @8.8.8.8 ile yeni IP’yi gördüğünüzü doğrulayın, sonra sertifikayı hem apex hem de www için birlikte isteyin. Joker (wildcard, *.ornek.com.tr) sertifika istiyorsanız HTTP-01 kullanılamaz; DNS-01 doğrulaması gerekir, yani sağlayıcı sizden _acme-challenge adına bir TXT kaydı ister. DNS’iniz hosting panelindeyse bu otomatik yapılır, başka yerdeyse elle eklersiniz.

Kesintisiz geçiş istiyorsanız sertifikayı DNS’ten önce de hazırlayabilirsiniz: eski sunucudaki geçerli sertifikayı yeni sunucuya kopyalamak ya da DNS-01 ile önceden doğrulamak. İkinci yol daha temizdir; IP değiştiği dakika yeni sunucu HTTPS’e hazır olur ve ilk ziyaretçiler sertifika uyarısı görmez.

DV, OV, EV ve joker sertifika arasındaki farklar, hangisine ne zaman ihtiyaç olduğu SSL sertifikası nedir? DV, OV, EV ve wildcard farkı yazımızın konusu. Kurumsal doğrulamalı ücretli sertifika gerekiyorsa lisans satış ekibimiz tedarik ediyor.

Destek taleplerinde gördüğümüz hataların çoğu birkaç kalıba oturuyor. Tarayıcının ya da e-posta sunucusunun verdiği mesajdan geriye doğru gitmek, “DNS’te bir sorun var” diye bütün ayarları karıştırmaktan çok daha hızlıdır.

1. 01DNS_PROBE_FINISHED_NXDOMAINNedenAlan adı için hiç kayıt bulunamıyor: nameserver’lar yeni bölgeyi göstermiyor, bölgede @ A kaydı yok ya da alan adının süresi dolmuş.Çözümdig NS alanadi +trace ile delegasyonu, ardından yetkili sunucudaki A kaydını kontrol edin. Kayıt kuruluşu panelinde alan adının durumuna bakın.
2. 02Eski site açılmaya devam ediyorNedenSizin çözümleyiciniz veya tarayıcınız eski IP’yi önbellekte tutuyor ya da bölgede eski IP’li ikinci bir A satırı kalmış.Çözümdig @8.8.8.8 ile kontrol edin, yerel önbelleği temizleyin, bölgede aynı ada ait yinelenen A kaydı arayın. Hosts dosyasında unutulmuş bir satır da olabilir.
3. 03ERR_TOO_MANY_REDIRECTSNedenEn tipik neden: Cloudflare SSL modu Flexible iken sunucu HTTP’yi HTTPS’e yönlendiriyor; Cloudflare de sunucuya hep HTTP ile gidiyor ve döngü oluşuyor.ÇözümSunucuya geçerli sertifika kurun, Cloudflare’de SSL/TLS modunu Full (strict) yapın. www kuralının iki yönde birden tanımlanmadığını kontrol edin.
4. 04“Bağlantınız gizli değil” (NET::ERR_CERT_COMMON_NAME_INVALID)NedenSertifika ziyaret edilen adı kapsamıyor: çoğunlukla yalnız apex için alınmış, www dışarıda kalmış ya da sertifika hâlâ eski sunucunun.ÇözümSertifikayı iki adı birlikte kapsayacak şekilde yeniden alın; DNS yeni sunucuyu gösterdikten sonra deneyin.
5. 05E-postalar gelmiyorNedenNameserver değişti ama MX yeni bölgeye eklenmedi, ya da Cloudflare’de mail sunucusunu gösteren A kaydı proxy’de (turuncu) kaldı.Çözümdig MX alanadi +short ile hedefi doğrulayın; mail kayıtlarını gri buluta alın; eski sunucuda biriken iletileri yeni kutulara taşıyın.
6. 06Mailler spam’e düşüyor, SPF “permerror”NedenAlan adında iki ayrı SPF kaydı var ya da include’lar 10 DNS sorgusu sınırını aşıyor.ÇözümSPF’leri tek satırda birleştirin, kullanılmayan servisleri çıkarın; DKIM ve DMARC’ı da tamamlayın.
7. 07SERVFAIL, bazı ağlarda hiç açılmıyorNedenDNSSEC açık bir alan adında nameserver değişti ama kayıt kuruluşundaki eski DS kaydı kaldı; doğrulama yapan çözümleyiciler cevabı reddediyor.ÇözümDS kaydını kaldırın ya da yeni sağlayıcının anahtarıyla güncelleyin. Doğrulama yapmayan çözümleyicilerde çalışması sorunu gizler.
8. 08Nameserver değişikliği kabul edilmiyorNedenKendi alan adınız altındaki nameserver’ları (ns1.alanadi) kullanıyorsunuz ama glue kaydı yok veya IP’ler yanlış. Bir başka olasılık: kayıt otoritesi yeni nameserver’ların alan adı için cevap vermesini bekliyor, oysa bölge yeni sunucuda henüz açılmamış.ÇözümGlue gerekiyorsa kayıt kuruluşu panelinde alt nameserver kayıtlarını ad ve IP ile oluşturun. Değilse önce bölgeyi yeni sunucuda açın, dig @ns1.yeni-hosting.example alanadi SOA cevap verince nameserver alanına yazın.
9. 09Alan adı askıda veya süresi dolmuşNedenYenileme yapılmamış, iletişim bilgisi doğrulaması bekliyor ya da kayıt kuruluşu alan adını beklemeye almış.ÇözümKayıt kuruluşu panelinde durum alanına bakın, yenilemeyi ve doğrulama e-postasını tamamlayın. Bu durumda DNS ayarı ne olursa olsun site açılmaz.

Site açılıyor ama yavaşsa sorun büyük ihtimalle DNS’te değil; sunucu yanıt süresine, önbelleğe ve sayfa ağırlığına bakmak gerekir. Bu teşhisi web sitesi yavaş açılıyor: sorun hostingte mi, sitede mi? yazısında adım adım anlatıyoruz. Taşımadan sonra sitede tanımadığınız yönlendirmeler veya dosyalar görüyorsanız web sitesi hacklendi, ne yapmalı? rehberine geçin.

Bu yazıdaki hataların neredeyse hepsinin ortak kökü aynı: kimse alan adının DNS’inde ne olduğunu ve neden orada olduğunu yazmamış. Bir yıl önce bir ajansın eklediği TXT kaydı, muhasebenin e-fatura servisi için açılmış bir alt alan adı, BT’nin VPN için verdiği bir SRV kaydı… Taşıma günü bunların hepsi “bu ne, silebilir miyiz?” sorusuna dönüşür.

Önerim, alan adı başına tek sayfalık bir DNS envanteri tutmak. Planlayıcının BIND çıktısı iyi bir başlangıçtır; her satırın yanına sahibini ve amacını eklemek yeterli. Kayıt kuruluşu panelinin ve DNS panelinin kimin hesabında olduğunu da aynı sayfaya yazın; ajans değişikliğinde ya da çalışan ayrıldığında en çok aranan bilgi budur.

İlk sitesini kuran işletmeler için alan adı, hosting ve e-postayı baştan doğru kurgulamak sonradan düzeltmekten çok daha ucuzdur; bu konuda ilk web sitesini kuran KOBİ’ler için web tasarım sayfamızda nasıl çalıştığımızı anlattık. Siteyi yenileyen şirketlerde ise DNS geçişi yayın gününün bir parçası; web sitesi yenileyen şirketler için web tasarım sürecimizde bu adımı birlikte planlıyoruz. Paket seçimi ve gerçek maliyet için hosting fiyatları rehberimize göz atabilirsiniz.