Plesk panelde alan adı ve DNS yönetimi: kayıtlar, TTL ve geri alma

Plesk panelde alan adı ve DNS yönetimi, bir alan adının hangi sunucuya çözümleneceğini, hangi posta kutusuna mail teslim edeceğini ve değişikliğin ne kadar sürede yayılacağını kontrol eder. İşin kritik noktası, Plesk’te yaptığınız her düzenlemenin hemen herkesi etkilememesidir; yalnızca Plesk’in yetkili DNS sunucusu olduğu durumda dış dünyaya yansır. Bu yüzden önce nameserver yetkisini, sonra kayıt türlerini, ardından TTL değerini netleştirmek gerekir. Web sitesi taşırken genelde A ve AAAA kayıtları ile CNAME, mail akışında MX ve TXT kayıtları, doğrulama tarafında ise TXT ve bazen SRV kayıtları öne çıkar. En güvenli başlangıç, değişmeden önce mevcut zone’u not etmek, mümkünse dışa aktarmak ve her değişiklikten sonra dig, nslookup ya da host ile sonucu kontrol etmektir. Yanlış kayıt, siteyi kapatabilir ya da maili durdurabilir; doğru sıra bunu önler.

Plesk panelde alan adı ve DNS yönetimi nerede başlar?

Önce alan adının yetkili DNS’inin gerçekten Plesk’te olup olmadığını kontrol edin. Plesk tarafında Websites & Domains altında alan adını açıp DNS Settings ekranına gittiğinizde gördüğünüz kayıtlar, ancak o zone’un yetkili olduğu durumda kamu DNS sonucunu belirler. Alan adı kayıt kuruluşunda başka nameserver’lara işaret ediyorsa, Plesk’te kayıt düzenlemek yalnızca yerel kopyayı değiştirir. Bu ayrımı netleştirmeden yapılan çalışma, en sık görülen hata kaynağıdır. Yeni alan adı eklerken DNS service açık bırakılırsa Plesk zone’u oluşturur; harici DNS kullanacaksanız aynı kayıtları sağlayıcı tarafında da tutarlı hale getirmelisiniz.

1. Alan adının registrar kayıtlarında hangi nameserver’lara baktığını kontrol edin.
2. Plesk’te aynı alan adı için DNS Settings ekranını açın.
3. Zone içinde A, AAAA, MX ve TXT gibi kayıtların hangi hedefe gittiğini doğrulayın.
4. Değişiklik yapmadan önce mevcut değerleri not alın veya zone’u dışa aktarın.
5. Canlıya almadan önce tek bir kayıtla test edip sonucu ölçün.

DNS kayıt türleri: hangi kayıt neyi değiştirir?

Alan adı ve mail akışı çoğu zaman birkaç temel kayıtla yönetilir. Web sunucusunu, posta teslimini ve doğrulamayı aynı tabloda görmek karar vermeyi kolaylaştırır.

MX kaydı mail teslimini yönetir; A ve AAAA ise o MX’in işaret ettiği host adının çözümlenmesini sağlar. Bu nedenle yalnız MX’i düzeltmek bazen yetmez. MX hedefi ad olarak yazılmışsa, o adın da doğru IP’ye gitmesi gerekir. TXT tarafında SPF kaydı, hangi sunucuların bu alan adı adına mail gönderebileceğini söyler. Mail servisini Plesk dışına taşıdıysanız SPF ve DKIM’i de yeni sağlayıcının kuralına göre uyarlamazsanız, teslim edilebilirlik düşebilir.

Mail yönlendirme DNS’i nasıl etkiler?

Plesk içindeki mail yönlendirme, çoğu durumda postanın önce sizin sunucunuza gelmesini gerektirir. Yani MX kaydı Plesk sunucusunu gösteriyorsa, gelen mail sunucuda karşılanır ve ardından yönlendirme kuralına göre başka adrese iletilir. MX başka bir sağlayıcıya taşınmışsa, Plesk’teki yönlendirme kuralı devreye girmez; mail zaten o sunucuya hiç uğramaz. Bu fark, “mail neden gelmiyor?” sorusunun en sık sebebidir.

Yönlendirme ile gerçek posta kutusu arasında önemli bir fark vardır. Yönlendirme hafif bir çözümdür ama bazı alıcılar iletilen postada SPF veya benzeri denetimlerden dolayı daha sıkı davranabilir. Özellikle dış sağlayıcıya yönlenen adreslerde, gelen postanın orijinal zarf bilgisi ile sizin alan adınızın DNS kayıtları uyumsuz kalabilir. Kritik işler için, yalnız yönlendirme yerine doğrudan posta kutusu taşımak çoğu zaman daha öngörülebilir sonuç verir. Bu karar, kullanım senaryosuna göre verilmelidir; her alan adında aynı model doğru olmaz.

TTL’i ne zaman düşürmeli, ne zaman yükseltmeli?

TTL, bir DNS kaydının resolver önbelleğinde ne kadar tutulacağını belirler. Değişiklikten hemen sonra eski kaydın görünmesi çoğu zaman hata değil, önbellek davranışıdır. Taşıma, IP değişimi ya da MX geçişi planlıyorsanız TTL’i geçici olarak düşürmek yararlı olur. İşlem tamamlandıktan sonra eski ya da daha rahat bir seviyeye yükseltmek, gereksiz sorgu yükünü azaltır.

TTL’i çok düşük tutmak her zaman iyi fikir değildir. Özellikle trafiği yüksek alan adlarında resolver sorguları artar ve bu da gereksiz maliyet yaratabilir. En mantıklı kullanım, değişiklikten önce kısa süreli düşürmek, değişiklikten sonra stabil seviyeye dönmektir. TTL değişikliğinin etkisini anında değil, en uzun eski önbellek süresi bittikten sonra görmeyi beklersiniz.

Plesk içinde düzenleme yaparken izlenecek akış

1. Mevcut durumu kaydedin. A, AAAA, CNAME, MX, TXT ve NS kayıtlarını not alın.
2. Yetki sınırını doğrulayın. DNS Plesk’te değilse değişikliği orada yapın.
3. Önce kritik kayıtları değiştirin. Mail taşınıyorsa MX ve ilgili TXT değerleri önce güncellenir.
4. Sonra web kayıtlarını düzenleyin. A/AAAA ve gerekiyorsa www için CNAME ayarlayın.
5. TTL’i planlı kullanın. Geçiş öncesi düşürün, geçişten sonra yükseltin.
6. Kaydedip dışarıdan test edin. Aynı makineden değil, başka bir resolver’dan da bakın.

Birden çok alan adı yönetiyorsanız DNS Template de işinizi kolaylaştırır. Yeni domain ekledikçe aynı temel kayıtların oluşmasını istiyorsanız, şablonu dikkatle düzenleyin; ama önce tek bir alan adı üzerinde test edin. Şablon değişikliği bütün yeni zone’lara yansıyacağı için, burada yapılan hata da toplu olur.

Doğrulama komutları ve beklenen sonuç

Panelde gördüğünüz kayıt ile internetten görünen kayıt aynı mı, bunu terminalden kontrol edin. Aşağıdaki komutlar, alan adının hangi IP’ye, hangi mail sunucusuna ve hangi metin kayıtlarına çözümlendiğini gösterir. Örneklerde example.com kullanıldı; kendi alan adınızla değiştirin.

dig +short A example.com dig +short AAAA example.com dig +short MX example.com dig +short TXT example.com nslookup -type=mx example.com host -t ns example.com

Beklemeniz gereken durum şudur: A kaydı doğru IP’yi göstermelidir, AAAA yalnız IPv6 kullanıyorsanız görünmelidir, MX hedefi planladığınız posta sunucusuna dönmelidir ve TXT kayıtlarında SPF veya doğrulama değeri eksik olmamalıdır. nslookup -type=mx ile görünen sonuç ile dig +short MX çıktısı arasında uyumsuzluk varsa, önbellek ya da farklı resolver kullanımı söz konusu olabilir. Şüphe varsa sorguyu yetkili nameserver’a doğrudan yönlendirin; böylece kamu resolver cache’ini değil, zone’un gerçek durumunu görürsünüz.

dig @ns1.ornekad.com example.com MX dig @ns1.ornekad.com example.com TXT

Yetkili nameserver yerine kendi sağlayıcınızın gerçek NS adını veya IP’sini kullanın. Bu test, panelde kaydettiğiniz değerin zone’a yazılıp yazılmadığını doğrular. Kamu resolver sonucu farklıysa panik yapmayın; önce TTL süresini ve önbellek etkisini kontrol edin.

Geri alma planı: eski kayda nasıl dönersiniz?

DNS değişikliği geri alınacaksa, en hızlı yol yeni kaydı silmek değil, eski değerleri geri koymaktır. Kayıt silmek yerine önceki A, MX, TXT veya CNAME değerlerini aynı isim altında yeniden tanımlayın. Böylece zone yapısı korunur ve tahmin edilebilir bir dönüş olur. Plesk yetkili DNS değilse bu dönüşü aynı panelde yapmak yeterli olmaz; registrar ya da dış DNS sağlayıcısında da aynı geri almayı uygulamanız gerekir.

1. Değişiklikten önce not ettiğiniz eski değerleri açın.
2. Önce maili etkileyen MX ve ilgili TXT kayıtlarını eski hale getirin.
3. Sonra web tarafındaki A/AAAA ve gerekiyorsa CNAME kayıtlarını geri alın.
4. TTL’i çok düşürdüyseniz, sabit hale döndükten sonra normal seviyeye çıkarın.
5. Aynı kontrol komutlarıyla eski IP, MX ve TXT değerlerini tekrar doğrulayın.

Geri alma sırasında en önemli karar noktası şudur: önce hangi hizmet bozulduysa onu eski haline getirin. Site açılmıyorsa A/AAAA, mail gelmiyorsa MX ve TXT ilk sıradadır. Alan adının yönü registrar düzeyinde değişmişse, DNS geri dönüşünü yalnız Plesk’te yaparak zaman kaybetmeyin; yetki kimdeyse işlem orada tamamlanmalıdır.

En çok sorun çıkaran yanlış kurulumlar

• Alan adı nameserver’ları Plesk’e dönmediği halde zone’u Plesk’te düzenlemek.
• MX kaydını düzeltip onun işaret ettiği host adının A veya AAAA kaydını unutmak.
• www kaydını değiştirip kök alan adını aynı bırakmak.
• Mail sağlayıcısı değişmişken SPF TXT kaydını güncellememek.
• TTL’i geçişten sonra da düşük tutup gereksiz sorgu yükü yaratmak.
• Eski kayıtları silmeden önce not almamak ve geri dönüşü zorlaştırmak.

Bu kuralların ortak noktası, DNS’in tek bir ekran değil, birbirine bağlı kayıtlar zinciri olmasıdır. Plesk panelde alan adı ve DNS yönetimi, yalnız kayıt eklemek değil, hangi kaydın diğerini etkilediğini görmek demektir. Küçük bir test, doğru nameserver doğrulaması ve temiz bir geri alma planı çoğu kesintiyi başlamadan bitirir.