Alt Alan Adını Farklı Sunucuda Barındırma (blog, shop, mail)

Kurumsal siteniz paylaşımlı hosting hesabında çalışıyor ve gayet iyi durumda. Ama blog tarafında ağır bir WordPress kurulumu var, görsel işleyecek, önbellek katmanı isteyecek; onu bir VDS'e almaya karar verdiniz. Ya da müşteri paneliniz Node.js ile yazıldı, paylaşımlı hostinge sığmıyor. Belki de e-postaları kendi mail sunucunuza taşıyorsunuz. Üçünde de aynı soru karşınıza çıkıyor: blog.siteniz.com ana siteden tamamen farklı bir makinede nasıl yayınlanır?

Bu noktada çoğu kişi cPanel'de "Subdomains" ekranını açar, alt alan adını oluşturur ve sonra hedef sunucunun IP'sini nereye yazacağını arar. Oysa o ekran çoğu senaryoda hiç gerekmez, hatta bazı durumlarda kurduğunuz yapıyı bozar. Çünkü alt alan adını başka bir sunucuda yayınlamak tek bir işlem değil, birbirinden bağımsız iki iştir: DNS tarafında adın doğru IP'yi göstermesi ve hedef sunucunun o adı kendi üzerine alması.

Aşağıda bu iki işi ayrı ayrı, hangi panelde ne yapılacağı netleşecek şekilde ele alıyoruz. Ana sitenin barındığı yere hiç dokunmadan; A kaydı ile CNAME arasındaki kararı hangi kritere göre vereceğinizi, hedef sunucuda Apache/Nginx tarafında hangi satırın eklendiğini, alt alan adı için ayrı bir SSL sertifikasının nasıl çıkarıldığını ve mail.siteniz.com gibi özel bir vakada ek olarak nelerin gerektiğini göreceksiniz.

Alt Alan Adı Farklı Sunucuda Olduğunda Ne Değişir#

Alan adınız tek bir DNS bölgesidir (zone). siteniz.com, www.siteniz.com, blog.siteniz.com ve mail.siteniz.com aynı bölgenin içindeki farklı kayıtlardır. Bu kayıtların her biri bağımsız olarak istediği IP'yi gösterebilir. Yani ana siteniz 185.10.20.30 üzerinde dururken blog kaydı 91.40.50.60'a bakabilir; DNS açısından bunda hiçbir olağan dışılık yoktur.

Alt alan adının farklı bir sunucuda olması durumunda değişen tek şey şudur: ziyaretçinin isteği artık ana hosting hesabınıza hiç uğramaz. Tarayıcı blog.siteniz.com için DNS'e sorar, 91.40.50.60 cevabını alır ve doğrudan o makineye bağlanır. Ana sunucunuz bu trafiği görmez, loglarında yer almaz, kaynak limitlerini tüketmez. Bu, yükü ayırmak istediğinizde tam olarak istediğiniz davranıştır.

Ancak bağlantı hedefe ulaştığında ikinci bir kapı vardır. HTTP isteği, bağlandığı IP'ye ek olarak bir de Host: blog.siteniz.com başlığı taşır. Hedef sunucu bu başlığı tanımıyorsa isteği kendi varsayılan sitesine yönlendirir — sonuç genelde "Apache2 Default Page", "Welcome to nginx!" veya o sunucuda barınan bambaşka bir müşterinin sitesidir. DNS doğru, sunucu hazır değildir. Alt alan adı kurulumlarının en sık takıldığı yer burasıdır.

Özetle iki ayaklı bir iş yapıyorsunuz:

Ana Hosting Hesabınızda Subdomain Oluşturmanız Gerekmez#

Bu, konunun en çok kafa karıştıran kısmı. cPanel'deki "Subdomains", Plesk'teki "Add Subdomain" ekranları tek bir işe yaramaz; iki iş birden yapar: sunucuda bir belge kökü (klasör) açar ve o hesabın DNS bölgesine kendi IP'sini gösteren bir A kaydı ekler.

Alt alan adı başka bir sunucuda duracaksa bu iki işin de anlamı yoktur:

• Ana sunucudaki klasöre hiçbir zaman istek gelmeyecektir, boş durur.
• Eklenen A kaydı ana sunucunun IP'sini gösterir. Alan adınızın nameserver'ları hosting firmanızdaysa bu kayıt sizin elle girmek istediğiniz harici IP'yi ezer ya da onunla çakışır.

Uygulamada gördüğümüz klasik döngü şudur: kullanıcı önce cPanel'den subdomain oluşturur, sonra Zone Editor'a girip A kaydını hedef IP ile değiştirir, ardından cPanel'de başka bir ayar yapıldığında (SSL yenilemesi, hesap taşıma, DNS senkronizasyonu) kayıt sessizce eski hâline döner ve blog bir sabah ana siteyi göstermeye başlar.

Doğru yaklaşım: ana hosting hesabında hiçbir şey oluşturmayın. Sadece yetkili DNS panelinde ilgili kaydı ekleyin. Alt alan adı kavramının temelleri ve tek sunuculu senaryolar için subdomain nedir yazısına bakabilirsiniz; burada ilgilendiğimiz durum yalnızca dağıtık kurulum.

İki istisna vardır. Birincisi, alan adının nameserver'ları hosting hesabınızda değilse (örneğin Cloudflare'deyse) cPanel'in yerel bölgesi zaten kimse tarafından okunmaz; subdomain oluşturmak zararsız ama yine de gereksizdir. İkincisi, hedef sunucu cPanel çalıştırıyorsa orada bir tanım yapmanız gerekir — ama o "subdomain" olarak değil, aşağıda anlatıldığı gibi addon domain olarak eklenir.

DNS Kaydı Hangi Panelde Tanımlanır?#

Kaydı yanlış panele yazmak, bu işte harcanan zamanın büyük kısmını açıklar. Belirleyici olan tek şey alan adının NS kayıtlarıdır: hangi nameserver'lar yetkiliyse, DNS düzenlemesi orada yapılır. Kayıt firmanızın panelinde bir "DNS Yönetimi" sekmesi olması, o panelin dinlendiği anlamına gelmez.

Önce yetkiyi doğrulayın:

# Alan adının yetkili nameserver'ları
dig NS siteniz.com +short

# Kaydın gerçekte hangi IP'yi döndürdüğü (halka açık cevap)
dig blog.siteniz.com A +short @1.1.1.1

# Doğrudan yetkili sunucuya sorup önbelleği devre dışı bırakma
dig blog.siteniz.com A @ns1.hostingfirmasi.com +short

Windows kullanıyorsanız nslookup -type=NS siteniz.com aynı bilgiyi verir. Çıkan sonuca göre panel şöyle belirlenir:

Yetki zincirini ve panel seçimini daha ayrıntılı ele alan DNS kayıtları hangi panelden değiştirilir yazısı, birden fazla panelin aynı anda dolu göründüğü karışık durumlar için iyi bir tamamlayıcıdır.

A Kaydı mı CNAME mi? Karar Tablosu#

Doğru paneli bulduktan sonra tek bir karar kalır: kaydı A olarak mı yoksa CNAME olarak mı gireceksiniz? Kural basittir — elinizde bir IP adresi varsa A, bir alan adı varsa CNAME.

Kendi VDS'inize, dedicated sunucunuza ya da sabit IP'li bir bulut makinesine yönlendiriyorsanız A kaydı doğru seçimdir:

blog     3600  IN  A     91.40.50.60
shop     3600  IN  A     91.40.50.61

Buna karşılık hedef servis size IP değil bir hostname veriyorsa (yönetilen platformlar, yük dengeleyiciler, nesne depolama uçları, bazı CDN'ler) CNAME kullanmalısınız. Bu servislerin IP'leri sizin haberiniz olmadan değişir; A kaydı yazarsanız bir gün servis IP'yi taşır ve siteniz kapanır.

shop     3600  IN  CNAME  magaza-uc-nokta.saglayici.net.

Karar verirken şu tablo işinizi görür:

İki tuzağa özellikle dikkat edin. Birincisi, bir isimde CNAME varsa aynı isimde başka kayıt bulunamaz. blog için CNAME tanımladıysanız aynı isme TXT veya MX ekleyemezsiniz; panel "conflict" hatası verir. İkincisi, CNAME bir zincir kurar: blog → hedef → hedefin A kaydı. Bu ek bir çözümleme adımı demektir ve zincirin ucundaki sağlayıcı yavaşsa ilk açılış gecikir. Kayıt tiplerinin davranış farkları için CNAME kaydı nedir ve A kaydı nedir yazıları ayrıntılı karşılaştırma sunuyor.

TTL değerini geçiş öncesinde 300 saniyeye indirin. Böylece hedefte bir sorun çıkarsa kaydı geri almanız saatler değil dakikalar sürer; işler oturduktan sonra 3600'e yükseltebilirsiniz.

Hedef Sunucuda Alan Adını Tanıtmak#

DNS artık doğru makineyi gösteriyor. Şimdi o makinenin blog.siteniz.com adını kendi üzerine alması gerekiyor. Hedef sunucunun tipine göre yapılacak iş değişir.

Kontrol paneli olmayan bir sunucuda (Nginx)#

server {
    listen 80;
    listen [::]:80;
    server_name blog.siteniz.com;

    root /var/www/blog;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

Dosyayı /etc/nginx/sites-available/blog.siteniz.com olarak kaydedip etkinleştirin:

ln -s /etc/nginx/sites-available/blog.siteniz.com /etc/nginx/sites-enabled/
nginx -t          # yapılandırmayı doğrula
systemctl reload nginx

Apache kullanan bir sunucuda#

<VirtualHost *:80>
    ServerName blog.siteniz.com
    DocumentRoot /var/www/blog

    <Directory /var/www/blog>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/blog-error.log
    CustomLog ${APACHE_LOG_DIR}/blog-access.log combined
</VirtualHost>

a2ensite blog.siteniz.com.conf
apachectl configtest
systemctl reload apache2

Hedef sunucu cPanel/Plesk çalıştırıyorsa#

Burada dikkat edilecek nokta terminolojidir. Hedef sunucudaki hesabın ana alan adı siteniz.com değildir, dolayısıyla blog.siteniz.com'u "Subdomain" olarak ekleyemezsiniz — o menü yalnızca hesabın kendi ana alan adı altında alt alan adı açar. Doğru yol, blog.siteniz.com adresini Addon Domain (Plesk'te "Ek Alan Adı") olarak eklemektir. Panel bunu bağımsız bir site gibi ele alır, kendi belge kökünü ve sanal host tanımını oluşturur. Bu dört domain tipi arasındaki farkı addon ve parked domain farkı yazısında bulabilirsiniz.

cPanel addon domain eklerken alan adının o sunucuya yönlendiğini doğrulamak isteyebilir; DNS kaydını önce girip birkaç dakika beklemek bu kontrolü geçmenizi kolaylaştırır.

Tanımın çalıştığını DNS'i beklemeden test etme#

Kayıt daha yayılmadan hedef sunucunun hazır olup olmadığını görebilirsiniz. curl, sizin adınıza sahte bir çözümleme yapabilir:

# HTTP tarafı: isteği doğrudan hedef IP'ye at, Host başlığını elle ver
curl -I --resolve blog.siteniz.com:80:91.40.50.60 http://blog.siteniz.com/

# HTTPS tarafı (sertifika kurulduktan sonra)
curl -I --resolve blog.siteniz.com:443:91.40.50.60 https://blog.siteniz.com/

Dönen yanıt 200 veya beklediğiniz bir yönlendirme ise sunucu tarafı tamamdır; geriye sadece DNS'in yayılmasını beklemek kalır.

Alt Alan Adı İçin Ayrı SSL Sertifikası#

Ana sitenizdeki sertifika alt alan adınızı kapsamaz. siteniz.com ve www.siteniz.com için düzenlenmiş bir sertifika blog.siteniz.com isteğine sunulduğunda tarayıcı NET::ERR_CERT_COMMON_NAME_INVALID uyarısı verir. Üstelik sertifika ana sunucuda duruyor, ziyaretçi ise başka makineye bağlanıyor — o dosyayı taşımanın da anlamı yok.

Çözüm, sertifikayı hedef sunucuda ayrıca çıkarmaktır. İyi haber şu: DNS kaydı zaten hedefi gösterdiği için Let's Encrypt'in HTTP-01 doğrulaması sorunsuz çalışır. Doğrulama sunucusu http://blog.siteniz.com/.well-known/acme-challenge/... adresini istediğinde bu istek doğrudan hedef makineye düşer.

# Nginx üzerinde
certbot --nginx -d blog.siteniz.com

# Apache üzerinde
certbot --apache -d blog.siteniz.com

# Otomatik yenilemenin çalıştığını kuru çalıştırmayla doğrulayın
certbot renew --dry-run

Hedef sunucu cPanel çalıştırıyorsa AutoSSL addon domain'i genelde kendiliğinden kapsar; "SSL/TLS Status" ekranından elle tetikleyebilirsiniz. Ücretsiz sertifika süreçlerinin tamamı için Let's Encrypt ücretsiz SSL yazısına bakın.

Üç özel durum:

1. Çok sayıda alt alan adınız varsa her biri için ayrı sertifika yerine wildcard SSL düşünebilirsiniz. Ancak wildcard sertifika DNS-01 doğrulaması ister, yani sertifikayı çıkaran makinenin DNS bölgenize kayıt yazabilmesi gerekir.
2. Cloudflare proxy açıksa ziyaretçi ile Cloudflare arasındaki bacak zaten şifrelidir, ama SSL modunu Full (strict) yapıp hedef sunucuda da geçerli bir sertifika bulundurun. "Flexible" modda Cloudflare ile sunucunuz arasındaki trafik şifresizdir ve WordPress gibi uygulamalarda yönlendirme döngüsü üretir.
3. HTTP-01 başarısız oluyorsa genellikle 80. port kapalıdır ya da bir güvenlik duvarı .well-known isteğini engelliyordur. Doğrulamadan önce 80/443 portlarının hedefte açık olduğundan emin olun.

mail.siteniz.com'u Ayrı Bir Sunucuya Taşımak#

E-posta tarafı, web tarafından bir kural fazlasıyla ayrılır: hangi sunucunun posta kabul edeceğini A kaydı değil MX kaydı belirler. mail.siteniz.com için A kaydı açmak yalnızca o ismi bir IP'ye bağlar; gelen postanın oraya gitmesini sağlamaz.

Doğru kombinasyon şudur:

; Mail sunucusunun adı bir IP'ye bağlanır
mail          3600  IN  A     91.40.50.70

; Alan adına gelen posta bu isme yönlendirilir
siteniz.com.  3600  IN  MX    10 mail.siteniz.com.

; Gönderim yetkisi verilen IP güncellenir
siteniz.com.  3600  IN  TXT   "v=spf1 ip4:91.40.50.70 -all"

Sırasıyla dikkat edilecekler:

• MX hedefi asla CNAME olmamalıdır. Standart bunu yasaklar ve bazı gönderici sunucular postayı reddeder. mail her zaman A (ve varsa AAAA) kaydı olsun.
• PTR (rDNS) kaydı hedef sunucunun sağlayıcısında ayarlanır, DNS panelinizde değil. IP'nin sahibi kimse ters kaydı o düzenler. PTR eksikse gönderdiğiniz postalar büyük ihtimalle spam klasörüne düşer.
• SPF kaydını güncellemeyi unutmayın. Eski hosting IP'si SPF'de kalırsa ve yeni IP eklenmezse gönderimleriniz doğrulamayı geçemez.
• Ana sitenin hosting hesabında yerel mail yönlendirmesini kapatın. cPanel'de "Email Routing" ayarı "Local Mail Exchanger"da kalırsa sunucu, MX kaydına bakmadan postayı kendi içinde teslim etmeye çalışır ve mesajlar eski kutuya düşer. Ayarı "Remote Mail Exchanger" yapın.
• Webmail ve otomatik yapılandırma için webmail.siteniz.com ve gerekiyorsa autodiscover / autoconfig kayıtlarını da yeni sunucuya yönlendirin.

MX önceliklerinin nasıl çalıştığı ve birden fazla mail sunucusu tanımlamak için MX kaydı nedir yazısı ayrıntılı örnekler içeriyor.

Belirti, Sebep ve Çözüm Tablosu#

Kurulum sonrası karşılaşılan hataların neredeyse tamamı altı başlıkta toplanır:

Değişikliğin ne kadar sürede her yerden görüneceği eski kaydın TTL değerine bağlıdır; bekleme sürelerini ve kontrol yöntemlerini DNS propagasyon süresi yazısında bulabilirsiniz. Kontrol ederken tarayıcı yerine dig veya curl kullanın: tarayıcılar kendi DNS önbelleklerini tutar ve size güncel olmayan bir sonuç gösterip boşuna zaman kaybettirir.

Sıkça Sorulan Sorular#

Alt alan adını başka sunucuya taşımak ana siteyi etkiler mi?#

Hayır. Alt alan adı bölgedeki bağımsız bir kayıttır; onun IP'sini değiştirmek siteniz.com ve www.siteniz.com kayıtlarına dokunmaz. Ana siteniz kesintisiz çalışmaya devam eder. Tek risk, düzenleme sırasında yanlışlıkla kök kaydı değiştirmektir; bu yüzden değişiklik öncesi mevcut bölgenin bir ekran görüntüsünü almak iyi bir alışkanlıktır.

Hosting hesabımda subdomain açmadan DNS kaydı çalışır mı?#

Evet, çalışır. DNS çözümlemesi tamamen nameserver'ların cevabına bağlıdır; ana hosting hesabınızdaki klasör yapısının bununla ilgisi yoktur. Ana sunucuda subdomain açmak yalnızca aynı sunucuda barındıracaksanız gereklidir. Farklı sunucu senaryosunda o adım gereksiz olduğu gibi, panelin ürettiği otomatik A kaydı sizin kaydınızla çakışabilir.

A kaydı yerine yönlendirme (redirect) kullansam olmaz mı?#

Olmaz, çünkü ikisi farklı şeydir. Yönlendirme, ziyaretçinin adres çubuğundaki adresi değiştirir ve tarayıcıyı başka bir URL'ye gönderir; kullanıcı blog.siteniz.com yerine hedef adresi görür. A veya CNAME kaydı ise adresi korur, sadece arkadaki sunucuyu değiştirir. Markanızın alan adı altında kalmak istiyorsanız DNS kaydı kullanmalısınız.

Birden fazla alt alan adını aynı hedefe yönlendirebilir miyim?#

Evet. Her biri için ayrı A kaydı girebilir ya da hepsini tek bir isme CNAME ile bağlayabilirsiniz. Alternatif olarak * (wildcard) A kaydı tanımlayıp tanımlanmamış bütün alt alan adlarını tek hedefe gönderebilirsiniz. Wildcard kullanırken hedef sunucuda her isim için sanal host bulunmadığından, tanımsız adların varsayılan siteye düşeceğini hesaba katın.

Alt alan adı için ayrı SSL almak zorunda mıyım?#

Ayrı sunucuda barındırıyorsanız evet. Sertifika, isteği karşılayan makinede bulunmak zorundadır ve mevcut sertifikanız yalnızca kapsadığı adlar için geçerlidir. Hedef sunucuda Let's Encrypt ile ücretsiz olarak çıkarabilirsiniz; DNS zaten hedefi gösterdiği için HTTP doğrulaması sorunsuz tamamlanır. Çok sayıda alt alan adı varsa wildcard sertifika daha pratik olabilir.

Değişiklikten sonra alt alan adı neden hâlâ eski sunucuyu açıyor?#

Büyük olasılıkla eski kaydın TTL süresi dolmamıştır ve çözücüler önbellekteki cevabı vermeye devam etmektedir. dig blog.siteniz.com @1.1.1.1 +short ile halka açık cevabı, dig blog.siteniz.com @ns1.saglayiciniz.com +short ile yetkili cevabı karşılaştırın. İkisi farklıysa beklemeniz yeterlidir; ikisi de eskiyse kaydı yanlış panele yazmışsınız demektir.