Birden Fazla Web Sitesini Tek Sunucuda Çalıştırırken DNS Planlaması

Tek sunucu üzerinde beş farklı siteyi çalıştırmak mümkündür; web sunucusu gelen isteğin Host başlığını okur ve doğru siteyi yanıtlar. Arka planda görünmez olan kısım DNS'tir: kayıtlar hatalı yapılandırılmışsa web sunucusu ne kadar doğru kurulmuş olursa olsun istekler yanlış yere gider ya da hiç ulaşmaz.

Virtual host yapısı isim bazlı yönlendirme yapar, IP bazlı değil. Her domain'in A kaydının aynı IP'ye işaret etmesi temel erişim için yeterlidir; ancak SSL sertifikası, e-posta yönlendirmesi ve subdomain yapısı her domain için ayrı karar gerektirir. Bir domain'de yapılan yanlış MX kaydı diğerini etkilemez, ama aynı sertifika altında toplanan domainlerde yenileme hatası tüm siteleri birden çökertir.

Aynı IP'yi paylaşan domain'lerde A kaydı ortak, MX ve CAA ayrı tutulur. Wildcard sertifika yenileme hatasını tüm sitelere yayar; tekil sertifika ise her hostu izole eder ama paneli şişirir.

Temel Yapı: Her Domain Aynı IP'ye İşaret Etmeli

Evet, işaret etmeli. Tek sunucu yapısında bunun başka yolu yoktur. Bu teknik zorunluluk, tüm DNS yapısının ortak tutulacağı anlamına gelmez; tam aksine, her domain'in kendi zone'unda yönetilmesi önerilir. Site1.com için A @ → 203.0.113.10, site2.com için de A @ → 203.0.113.10 yazıldığında her iki domain aynı IP'yi gösterir, ama zone'ları birbirinden tamamen bağımsızdır.

Bu bağımsızlık kasıtlı olarak korunmalıdır. Zone'ları tek bir dosyada birleştirmek idari kolaylık sağlıyor gibi görünse de, domainleri ayrı zone dosyalarında tutmak bakım ve hata izolasyonu için daha güvenlidir. Birinin SPF kaydını güncellerken diğerini bozmak, yalnızca zone sınırları net çizilmediğinde gerçekleşir.

www subdomain'ini de ayrıca tanımlayın. Hem kök domain (@) hem de www için A kaydı gerekir; aksi hâlde www.site.com erişilemez olur. CNAME ile www → @ yönlendirmesi çalışır, ancak bazı DNS sağlayıcıları kök için CNAME kullanımına izin vermez; kısıt A kaydı seçimini zorunlu kılar. A kaydı her iki durumda güvenli seçenektir.

Zone Yönetimi: Bağımsız Tutun

Her domain için ayrı DNS zone kullanmak hem teknik hem organizasyonel nedenlerle önerilir: birinin TTL süresini değiştirmek diğerini etkilemez, nameserver değişikliği bir domain'de bağımsız test edilebilir, teknik sorun çıktığında izolasyon çok daha kolay yapılır.

Merkezi zone yaklaşımı yalnızca çok sayıda subdomainle çalışılan tek bir ana domain'de mantıklıdır. Tüm sitelerin site1.anaplatform.com, site2.anaplatform.com gibi alt domain olarak çalıştığı yapılarda tek zone yönetilebilir. Ama birbirinden bağımsız domainleri, farklı TLD'leri veya farklı müşterilere ait alanları tek zone'da tutmak hem erişim kontrolü hem de değişiklik riski açısından sorunlu bir tercihtir.

Zone başına nameserver sayısı en az 2 olmalıdır. Tek nameserver yapısı, o sunucu erişilemez olduğunda domain'in tamamen çözümlenemez hale gelmesi demektir. Çoğu DNS sağlayıcısı otomatik olarak iki nameserver sunar; özel nameserver kullandığınızda bu sayıyı kendiniz sağlamanız gerekir. Özel nameserver kurulumunda nameserver çiftinin nasıl oluşturulacağı konusunda ayrı bir yapılandırma rehberi bulabilirsiniz.

Subdomain ve CNAME: Ne Zaman Hangisi?

Her sitenin kendi subdomainleri olabilir: blog.site1.com, panel.site2.com gibi. Bu subdomainlerin aynı sunucu IP'sine işaret etmesi gerekiyorsa A kaydı en temiz çözümdür. CNAME kullanımı yalnızca bir subdomain'i başka bir host'a yönlendirdiğinizde mantıklıdır; aynı sunucu için A kaydı daha az dolaylı bir yoldur ve DNS sorgusunda bir adım daha az gerektirir.

Kök domain için CNAME hiçbir durumda kullanılmamalıdır. RFC 1034, kök domain'de CNAME kullanımını yasaklar; bazı sağlayıcılar bunu teknik olarak engeller, bazıları sessizce yok sayar. Her iki durumda da güvenilmez bir yapı ortaya çıkar. Subdomain yönetiminde CNAME'in sınırları ve alternatif yöntemler hakkında daha fazla ayrıntı bulabilirsiniz.

Wildcard subdomain (*.site1.com) tüm subdomainleri tek kayıtla aynı IP'ye yönlendiren pratik bir seçenektir; ancak bu kayıt henüz tanımlanmamış subdomainler dahil hepsini yakalar. Sunucunuzda yalnızca belirli subdomainler için virtual host tanımlıysa wildcard A kaydı beklenmedik isteklere de kapı açar. Kontrollü bir yapı için her subdomain'i ayrı A kaydıyla tanımlamak daha izlenebilir bir yaklaşımdır.

Wildcard Sertifika mı, Tekil Sertifika mı?

Wildcard sertifika. Tekil sertifika. Hangisi?

Bu karar yönettiğiniz domain ve subdomain sayısına, sertifika yenileme altyapınıza ve güvenlik gereksinimlerinize göre değişir.

Wildcard sertifika (*.site1.com) tek bir sertifika ile tüm birinci düzey subdomainleri kapsar: blog.site1.com, panel.site1.com, api.site1.com hepsi bu sertifikayla çalışır. Yeni bir subdomain eklediğinizde sertifikayı yeniden almanıza gerek kalmaz. Yönetim kolaylığı belirgindir.

Ama wildcard sertifikanın sınırları da belirgindir. İkinci düzey subdomainleri kapsamaz: staging.api.site1.com wildcard kapsamı dışında kalır. Üstelik wildcard sertifikada özel anahtar (private key) tüm subdomainler arasında paylaşılır; bir subdomain'in güvenliği ihlal edilirse aynı anahtarı kullanan tüm subdomainler etkilenir.

Tekil sertifika yalnızca tek bir domain veya subdomain'i kapsar. Her domain için ayrı sertifika yönetmek, Let's Encrypt gibi bir servis ve otomatik yenileme kurulduğunda yönetilebilir hale gelir. certbot aracının bir zamanlayıcıyla çalıştırılması sertifikaları ayrı ayrı yeniler; başarısız olan yenileme yalnızca ilgili domain'i etkiler, diğerlerini değil. Bu hata izolasyonu, çok siteli yapılarda tekil sertifika stratejisinin temel avantajıdır.

Çok siteli yapıda en yaygın karma strateji şudur: aynı sahibi olan ve birbirine bağlı alt domainler wildcard sertifikayla, birbirinden bağımsız veya farklı müşterilere ait domainler ise tekil sertifikalarla yönetilir. Bu ayrım hem güvenlik izolasyonu sağlar hem de sertifika sorunlarını tek bir noktada biriktirmez.

Let's Encrypt wildcard sertifikası için DNS-01 doğrulaması zorunludur. HTTP-01 doğrulaması wildcard sertifika vermez. DNS-01 doğrulamasında sertifika otoritesi, DNS zone'unuza geçici bir TXT kaydı eklenip eklenmediğini kontrol eder. DNS sağlayıcınızın API üzerinden otomatik TXT kaydı oluşturabilmesi bu nedenle kritik öneme sahiptir; aksi hâlde yenileme otomasyonu kurulamaz ve sertifika süresi dolduğunda tüm subdomainler etkilenir.

E-posta DNS Kayıtları: Her Domain Ayrı Yapılandırma İster

Aynı sunucuda çalışan siteler e-posta için farklı sağlayıcılar kullanabilir. Bu olasılık, MX kayıtlarının her domain için bağımsız yapılandırılmasını zorunlu kılar. Site1.com Google Workspace'e, site2.com farklı bir posta servisine, site3.com ise kendi sunucusundaki mail yapısına bağlı olabilir; bu durumda MX kayıtları hiçbir şekilde paylaşılmaz.

SPF ve DKIM kayıtları da domain başına ayrıdır. Bir domain'in SPF kaydında include:_spf.google.com yer alırken diğerinde farklı bir include değeri bulunur. DKIM selector'ları domain bazında tanımlanır; site1.com için google._domainkey.site1.com TXT kaydı ile site2.com için tanımlanan DKIM kaydı tamamen ayrı kayıtlardır, birbirini etkilemez.

Karışık yapıda en sık yapılan hata, bir domain için MX kaydı eklerken diğerinin mevcut MX kaydını silmek ya da SPF kaydını yanlış zone'a yazmaktır. E-posta teslimat sorunları gecikmeyle ortaya çıktığı için bu hata çoğu zaman fark edilmez. E-posta teslim sorunlarının DNS kaynaklı nedenleri hakkında önceden bilgi sahibi olmak, bu tür hataların bedelini düşürür.

Aynı sunucudan e-posta gönderiliyorsa sunucu IP'sinin PTR (reverse DNS) kaydının bulunması önemlidir. PTR kaydı, IP adresinden hostname'e doğru çözümleme yapar; bazı e-posta sunucuları PTR kaydı olmayan IP'lerden gelen mesajları reddeder. Bu kayıt DNS zone'unuzda değil, IP bloğunu tahsis eden sağlayıcı üzerinde tanımlanır ve hosting firmanızla ayrıca koordine edilmesi gerekir.

TTL Değerleri: Değişiklik Öncesi Planlama

TTL (Time to Live), bir DNS kaydının önbellekte ne kadar süre tutulacağını belirtir. Çok siteli yapıda TTL kararı dikkat ister, çünkü A kaydını değiştirdiğinizde propagation süresi ilgili tüm domainleri etkiler.

Sunucu taşıması veya IP değişikliği planlanıyorsa ilgili domain'in A kaydı TTL'sini değişiklikten en az 24-48 saat önce düşürün. 3600 saniyeden (1 saat) 300 saniyeye (5 dakika) indirmek, IP değişikliğinin çok daha hızlı yayılmasını sağlar. Değişiklik tamamlandıktan sonra TTL'yi tekrar normal seviyeye çıkarabilirsiniz.

Beş farklı domain için aynı anda IP değişikliği yapılıyorsa hepsinin TTL'sini önceden indirmek gerekir. Bu adım atlanırsa eski IP, dünya genelindeki DNS önbelleklerinde saatlerce kalabilir ve bazı kullanıcılar eski sunucuya ulaşmaya devam eder. Birden fazla domain yönetiminde TTL ve kayıt takibi de düzenli kontrol gerektiren bir konudur.

Düşük TTL'nin dezavantajı, DNS sorgularının daha sık yapılmasıdır. Yüksek trafikli bir domain için 60 saniyelik TTL gereksiz sorgu yükü oluşturabilir. Kararlı bir yapıda 3600-7200 saniye makul bir TTL değeridir; aktif değişiklik dönemlerinde geçici olarak düşürülebilir, dönem bitince eski seviyeye çıkarılır.

Sorun Anında Hangi Katmana Bakmalısınız?

Sorun önemlidir. Ama hangi sitenin ve hangi katmanın sorunu olduğunu hızlı belirleyebilmek daha önemlidir.

Aynı sunucuda birden fazla site çalışırken bir DNS sorunu tüm siteleri etkiler; bir web sunucusu yapılandırma hatası ise yalnızca ilgili siteyi. Bu ikisi birbirine karıştırıldığında gereksiz yere farklı yerlere bakılır ve sorun geç çözülür. DNS sorunuyla uygulama katmanı sorununu ayırt etmek doğru teşhisin başlangıç noktasıdır.

DNS sorununu anlamak için dig site1.com A ile A kaydını sorgulayabilirsiniz. Dönen değer sunucunun IP'siyle eşleşiyorsa DNS'te sorun yoktur; sorun web sunucusu yapılandırmasında veya uygulamada aranır. Dönen değer yanlış bir IP gösteriyorsa nameserver'lar ve zone dosyası incelenir. Herhangi bir değer dönmüyorsa domain'in nameserver'ları erişilemez demektir.

Wildcard sertifika kullanan yapılarda yenileme başarısız olduğunda tüm subdomainler etkilenir. Bu riski azaltmak için sertifika son kullanma tarihini izleyen basit bir kontrol kurmak değerlidir. Tekil sertifika yapısında yenileme hatası yalnızca tek siteyi etkiler; bu nedenle farklı müşterilere ya da birbirinden bağımsız projelere ait domainlerde tekil sertifika stratejisi daha güvenli hata izolasyonu sağlar.

Yeni bir domain aynı sunucuya eklendiğinde en sık atlanan adım şudur: web sunucusunda virtual host tanımlanır, ama DNS'te A kaydı eklenmez ya da geç eklenir. Domain erişilemez görünür, sorunun kaynağı DNS yerine sunucu yapılandırmasında aranır. Farklı platformlarda domain ekleme sürecinde benzer sıralama hataları yaygın bir konudur. Sıraya dikkat edin: DNS kaydını ekle, propagation'ı bekle, sonra erişimi test et.

Çok siteli yapının DNS yönetimi özünde her domain'i bağımsız bir birim olarak ele almak ve değişikliklerin yalnızca hedef domain'i etkilediğinden emin olmak demektir. Ortak IP bir zorunluluktur; ortak zone, ortak sertifika veya ortak TTL stratejisi ise yalnızca belirli koşullarda tercih edilebilecek seçeneklerdir, varsayılan değil.

Her yeni domain eklendiğinde bir kontrol listesi oluşturmak ve kayıt altına almak, zamanla büyüyen yapılarda yönetim yükünü azaltır. Hangi domain'in hangi sertifikayı, hangi e-posta sağlayıcısını ve hangi nameserver'ları kullandığı bilgisi, sorun anında hızlı yanıt vermenin temelidir.