Multi‑Tenant SaaS Uygulamalarında Müşteri Alan Adı Yönetimi: DNS, SSL ve Yönlendirme Mimarisi

Multi‑Tenant SaaS’te Müşteri Alan Adı Neden Bu Kadar Önemli?

Multi‑tenant bir SaaS ürünü geliştirirken bir noktada şu talep mutlaka gelir: “Uygulama adresi firma.adiniz.com değil, kendi alan adımız üzerinden çalışsın; örneğin panel.musteri.com.” İlk bakışta sadece basit bir CNAME kaydı gibi görünen bu konu, ölçek büyüdükçe DNS, SSL otomasyonu, yönlendirme ve gözlemlenebilirlik tarafında ciddi bir mimari karara dönüşüyor. DCHost tarafında onlarca SaaS müşterisinin bu eşiğe geldiğine, gecikmiş mimari kararlar yüzünden günler süren refactor ve taşıma operasyonları yaşadığına defalarca şahit olduk.

Bu yazıda, multi‑tenant SaaS uygulamalarında müşteri alan adı (custom domain) yönetimini baştan sona, operasyonel gerçeklerle birlikte ele alacağız. DNS kayıt tasarımından ACME tabanlı SSL otomasyonuna, tek IP üzerinde yüzlerce tenant’ı SNI ile barındırmaktan, yönlendirme ve 301 mimarisine kadar adım adım ilerleyeceğiz. Amacımız, ilk günden doğru temeli kurup; ileride “bu mimariyi yıkmadan ölçekleyemiyoruz” cümlesini duymayacağınız bir yapı kurmanıza yardımcı olmak. Yazı boyunca, DCHost altyapısında sık kullandığımız pratiklerden ve sahada karşılaştığımız tipik tuzaklardan da bahsedeceğiz.

Multi‑Tenant SaaS’te Domain Mimarisi: Subdomain, Path ve Custom Domain

Önce temel terminolojiyi netleştirelim. Çoğu SaaS ürünü, en az üç domain stratejisinden birini kullanır:

• Subdomain tabanlı: musteri1.uygulama.com, musteri2.uygulama.com
• Path tabanlı: uygulama.com/musteri1, uygulama.com/musteri2
• Custom domain tabanlı: panel.musteri.com, app.musteri2.com.tr

Subdomain ve path mimarileri kendi içinde yeterince konu, fakat bu yazının odağı custom domain, yani müşterinin kendi alan adını kullandığı senaryolar. Bu modelin tipik kazanımları:

• Marka uyumu: Kullanıcılar, üçüncü parti bir SaaS yerine doğrudan kendi markaları üzerinden giriş yapar.
• SEO ve analitik: Bazı B2B/B2C SaaS senaryolarında, müşterinin son kullanıcıya açtığı sayfalar doğrudan kendi alan adından indekslenir.
• Güven algısı: Özellikle finans, hukuk, sağlık sektörlerinde “kendi alan adım” koşulu neredeyse standarttır.

Bizim tarafta gördüğümüz en kritik nokta şu: Multi‑tenant veritabanı mimarinizi ne kadar güzel kurarsanız kurun, domain, SSL ve yönlendirme mimarisini doğru tasarlamazsanız büyüdükçe yönetimi işkenceye dönüşür. Bu yüzden, veritabanı tarafını tasarlarken mutlaka eş zamanlı olarak ağ ve sertifika mimarisini de planlamak gerekir. Eğer multi‑tenant veritabanı stratejisini hâlâ netleştirmediyseniz, önce multi‑tenant veritabanı ve hosting rehberi yazımıza da göz atmanızı öneririz.

DNS Tarafı: Müşteriden Ne İstemeli, Siz Ne Yönetmelisiniz?

Temel DNS Modelleri

Müşterinin kendi alan adını SaaS uygulamanıza yönlendirmesi için genelde iki pratik model kullanılır:

1. CNAME ile yönlendirme (en yaygın model)
2. A/AAAA ile doğrudan IP’ye yönlendirme (daha az tercih edilen, ama bazı durumlarda gerekli)

CNAME modelinde müşteriden genelde şu kaydı girmesini istersiniz:

panel.musteri.com.  CNAME  custom.your-saas.com.

Bu durumda custom.your-saas.com adresinin A/AAAA kayıtları sizin kontrolünüzdedir ve arka tarafta IP değiştirmeniz gerektiğinde müşterilere dokunmadan, sadece kendi DNS kayıtlarınızda güncelleme yaparsınız. Ölçekleme, taşıma ve felaket kurtarma senaryolarında bu, büyük avantajdır.

A/AAAA modelinde ise müşteri doğrudan IP’ye yönlendirir:

panel.musteri.com.  A     203.0.113.10
panel.musteri.com.  AAAA  2001:db8::10

Bu model, özellikle kök (apex) alan adında CNAME kullanamamaktan veya bazı eski DNS sağlayıcı kısıtlarından dolayı tercih edilebilir. Dezavantajı, IP değişikliği gerektiğinde tüm müşterileri tek tek bilgilendirmeniz ve güncelleme yapmalarını beklemenizdir.

Apex (Kök) Alan Adı Sorunu

Birçok müşteri app.musteri.com yerine doğrudan musteri.com adresini kullanmak ister. DNS standartları gereği apex (kök) düzeyinde CNAME kullanmak problemlidir, bu yüzden bazı sağlayıcılar özel çözümler (ALIAS, ANAME, flattening vb.) sunar. Ancak siz SaaS sağlayıcısı olarak:

• Müşteriye subdomain kullanmasını önerebilir (bizim sahada en stabil gördüğümüz model),
• Ya da apex için A/AAAA, alt alanlar için CNAME kombinasyonu kullanmasını tarif edebilirsiniz.

Hem yayılım sürelerini hem de değişiklik senaryolarını doğru planlamak için DNS TTL değerlerini doğru ayarlama rehberi ile birlikte bu konuyu masaya yatırmanızı öneririz.

Alan Adı Sahipliğini Doğrulama: TXT mi HTTP mi?

Custom domain ekleme sürecinde iki farklı doğrulama deseni sık kullanılır:

• TXT doğrulaması: Müşteriden _verify.musteri.com veya doğrudan panel.musteri.com için rastgele bir token içeren TXT kaydı eklemesini istersiniz.
• HTTP doğrulaması: Müşterinin DNS’i sizin IP’nize yönlendirir, siz de belirli bir path altında (ör. /.well-known/your-saas-verify.txt) token üretip doğrularsınız.

Biz sahada TXT modelini daha esnek buluyoruz, çünkü HTTP doğrulaması için önce yönlendirme, sonra doğrulama, sonra SSL alma gibi adımlar arasında “tavuk-yumurta” döngüleri oluşabiliyor. TXT ile önce alan adının gerçekten müşteriye ait olduğunu doğrulayıp, ardından yönlendirme ve SSL süreçlerini güvenle tetikleyebilirsiniz.

DNS TTL Stratejisi

Custom domain tarafında en sık yapılan hata, tüm kayıtların TTL değerlerini rastgele seçmek. Önerdiğimiz pratik yaklaşım:

• Doğrulama ve ilk kurulum sürecinde daha düşük TTL (300–600 sn) kullanın.
• Kurulum stabilleştikten sonra orta seviye TTL (1800–3600 sn) ile hem cache verimliliğini hem de esnekliği dengeleyin.
• Çok bölgeli, Anycast veya aktif‑aktif mimarilerde TTL’leri, failover senaryolarınızı da düşünerek belirleyin.

TTL konusu, sıfır kesinti taşıma senaryolarında da kritik. Bu konuyu derinlemesine ele aldığımız zero‑downtime taşıma için TTL stratejileri yazısındaki teknik detayları, SaaS custom domain mimarinize birebir uygulayabilirsiniz.

SSL/TLS Mimarisi: Otomasyonsuz SaaS, Uzun Vadede Yürümez

Temel Sertifika Modelleri

Multi‑tenant SaaS’te yüzlerce, hatta binlerce müşteri alan adını güvenli (HTTPS) olarak sunmanız gerekir. Bu noktada üç temel SSL modeliyle karşılaşırsınız:

• Tekil sertifikalar: Her custom domain için ayrı bir DV sertifika.
• Wildcard sertifikalar: Sizin alan adlarınız için (*.app.uygulama.com) kullanışlı, ama müşterinin kendi alan adı için genelde uygun değil.
• SAN (Multi‑Domain) sertifikalar: Bir sertifikada birden fazla FQDN, ama büyük SaaS’ler için yönetimi zor, limitli ve pahalı bir model.

Müşteri alan adları için pratik ve ölçeklenebilir yaklaşım, her domain için otomatik DV sertifika üretimi ve yenilemesidir. Burada oyunun kurallarını ACME protokolü belirler.

ACME, HTTP‑01 ve DNS‑01: Multi‑Tenant İçin Hangisi?

ACME istemcileri (certbot, acme.sh vb.) sertifika doğrulamasını tipik olarak iki challenge türüyle yapar:

• HTTP‑01: Belirli bir URL altında dosya/yanıt sunarsınız; CA bu URL’yi çağırarak kontrol eder.
• DNS‑01: Belirli bir TXT kaydını DNS’e eklersiniz; CA DNS üzerinden doğrular.

Subdomain ağırlıklı mimarilerde HTTP‑01 pratik olabilir, ancak custom domain + çok kiracılı yapılarda DNS‑01 uzun vadede çok daha esnek ve güvenlidir. DNS‑01 ile:

• Henüz trafik almayan, sadece doğrulama aşamasındaki domainler için bile sertifika üretebilirsiniz.
• Edge/CDN katmanında özel routing kurmanıza gerek kalmadan, arka planda DNS API’leriyle otomasyonu çözebilirsiniz.
• Wildcard sertifikalar dahil geniş bir senaryoyu destekleyebilirsiniz.

Bu konuyu pratik örneklerle detaylandırdığımız SaaS’te özel alan adları ve otomatik SSL yazısındaki akışı, burada anlattığımız multi‑tenant mimarinin tamamlayıcı parçası olarak düşünebilirsiniz.

Let’s Encrypt ve Wildcard / Çoklu Domain Senaryoları

Bir noktadan sonra şu soru mutlaka gelir: “Let’s Encrypt rate limit’lerine takılmadan yüzlerce custom domain için nasıl sertifika üreteceğim?” Burada yapabileceğiniz optimizasyonlar:

• Gerektiği yerde wildcard kullanmak (kendi alan adlarınız için),
• Müşteri alan adlarında sertifika yenileme pencerelerini rastgele dağıtmak (hepsini aynı gün/saate yığmamak),
• ACME istemcinizi yeniden deneme ve yedek CA desteğiyle tasarlamak.

Let’s Encrypt’in DNS‑01 ile wildcard otomasyonu ve rate limit stratejilerini adım adım anlattığımız Let’s Encrypt wildcard SSL otomasyonu rehberi ve Let’s Encrypt rate limit’lerine takılmadan çok alan adında SSL kullanma stratejileri, SaaS senaryolarında birebir işinize yarayacak.

Tek IP Üzerinde Yüzlerce Müşteri Alan Adı: SNI’nin Gücü

Modern tarayıcılar ve istemciler, SNI (Server Name Indication) desteğine sahip olduğu için, aynı IP/port üzerinde yüzlerce farklı alan adı için ayrı SSL sertifikaları sunabilirsiniz. Web sunucusu (Nginx, Caddy, Apache veya bir L7 load balancer) TLS handshake esnasında gelen alan adını görür ve ilgili sertifikayı seçer.

Bu sayede DCHost tarafında tek bir güçlü VPS veya dedicated sunucu üzerinde:

• Ortak IP: 203.0.113.10
• Yüzlerce panel.musteri.com, app.musteri2.net vb. domain
• Her biri için ayrı sertifika ve ayrı tenant routingi

mimarisi kurmak son derece mümkün ve sağlıklıdır. Kritik olan, sertifika deposunu ve konfigürasyonunu otomatik yönetmek, manuel dosya kopyalamayı tamamen hayatınızdan çıkarmaktır.

Sertifika Süre Sonu ve İzleme

Custom domain sayısı arttıkça, sertifika süre sonu takip etmek manuel olarak imkânsız hâle gelir. Burada üç katmanlı bir yaklaşım öneriyoruz:

• Kontrol paneli/DB tarafı: Her domain için sertifika bitiş tarihini saklayıp, yenileme pencerelerini (ör. T‑30 gün) sistematik olarak planlamak.
• ACME istemcisi log’ları: Başarısız challenge, rate limit veya DNS hatalarını merkezi loglama ile izlemek.
• Dış izleme: Dışarıdan bakan bir izleme aracıyla sertifika süresi ve HTTPS durumunu takip etmek.

Bu noktada, onlarca alan adı için süre sonu izleme ve otomasyon ihtiyacını detaylandırdığımız SSL sertifika süre sonu izleme stratejisi yazısındaki pratikleri SaaS mimarinize entegre etmenizi özellikle tavsiye ederiz.

Yönlendirme ve Uygulama Katmanı: Host Header ile Tenant Seçimi

Edge Katmanı: Reverse Proxy veya Load Balancer

DNS ve SSL tarafını çözdünüz; sıra geldi isteği doğru tenant’a yönlendirmeye. Tipik akış şöyle çalışır:

1. Kullanıcı https://panel.musteri.com adresine gider.
2. DNS, isteği sizin edge IP’nize yönlendirir.
3. Edge (Nginx, HAProxy, Caddy, vb.) doğru sertifikayı seçerek TLS’i sonlandırır.
4. Host header (panel.musteri.com) uygulama sunucusuna veya multi‑tenant API’ye iletilir.
5. Uygulama, bu host bilgisini kullanarak hangi tenant’ın context’inde çalışacağını belirler.

Buradaki kritik tasarım kararı: tenant seçimini domain üzerinden mi, path üzerinden mi, yoksa JWT/oturum bilgisi üzerinden mi yapacağınız. Custom domain senaryosunda genellikle şu pattern kullanılır:

• Veritabanında domains tablosu (veya benzeri) tutulur.
• Her kayıt, domain → tenant_id eşleşmesini içerir.
• Request başlangıcında Host header okunur, bu tablo üzerinden tenant bulunur ve request lifecycle boyunca bu context taşınır.

301, Canonical ve HTTP → HTTPS Yönlendirmeleri

Custom domain kullanan SaaS’lerde yönlendirme hataları SEO, güvenlik ve kullanıcı deneyimi açısından ciddi sorunlar yaratabiliyor. Önerdiğimiz temel kurallar:

• Tüm HTTP istekleri için kalıcı 301 yönlendirme ile HTTPS’e geçin.
• www / çıplak alan adı kararı müşteriye ait olsa da, siz bu tercihe saygı duyup diğer varyantı 301 ile canonical domaine yönlendirin.
• Uygulama içinde canonical meta etiketlerini ve base URL ayarlarını müşterinin domainine göre dinamik belirleyin.

HTTP’den HTTPS’ye geçişte 301, HSTS ve canonical ayarlarını detaylı ele aldığımız HTTPS geçiş rehberi, burada inşa edeceğiniz custom domain mimarisinin de SEO ve güven tarafını sağlamlaştırmanıza yardımcı olacaktır.

Çok Bölgeli ve Çok Sunuculu Senaryolar

Custom domain sayısı ve trafik arttığında, tek sunucudan çoklu sunucu/çok bölgeli mimariye geçiş gündeme gelir. Bu durumda:

• DNS tarafında GeoDNS veya ağırlıklı yönlendirme ile kullanıcıyı en yakın edge’e çekebilirsiniz.
• Edge katmanında aynı sertifika ve domain mapping konfigürasyonunu tüm bölgelere kopyalamanız gerekir.
• Veritabanı tarafında replikasyon veya aktif‑aktif mimarilerle tenant verisini senkron tutmalısınız.

Bu konuyu geniş perspektiften ele aldığımız çok bölgeli mimariler ve felaket dayanıklılığı yazısındaki DNS ve veritabanı stratejilerini, SaaS custom domain yapınıza uygulayarak küresel ölçekte kesintisiz bir mimari kurgulayabilirsiniz.

Tenant Yaşam Döngüsü: Domain Ekleme, Doğrulama, SSL ve Cutover

1. Adım: Müşteriden Domain Bilgisi Almak

Panel tarafında genelde şu akışı tasarlıyoruz:

1. Müşteri panelde “Özel alan adı ekle” butonuna tıklar.
2. app.musteri.com veya subdomain.musteri.com.tr gibi istediği adresi girer.
3. Sistem, bu domaini tenant ile ilişkilendirir ve doğrulama için gerekli DNS/TXT kayıtlarını gösterir.

Bu aşamada mümkün olduğunca net ve kopyalanabilir yönergeler vermek, destek taleplerini ciddi oranda azaltır.

2. Adım: DNS Doğrulaması ve Otomatik Kontrol

Müşteriye gösterdiğiniz TXT veya CNAME kaydını periyodik olarak kontrol eden bir arka plan işi (queue/job/cron) çalıştırmak idealdir. DCHost müşterilerinin büyük kısmı burada:

• Her 5–10 dakikada DNS lookup yapan bir job,
• Belirli bir süre içinde (ör. 48–72 saat) doğrulanmayan domainleri pasif duruma alma,
• Başarılı doğrulamada otomatik SSL sürecini tetikleme

gibi bir akış kullanıyor. Zamanlayıcılar tarafında sağlıklı bir kurgu için, Linux crontab en iyi uygulamalar rehberindeki pratikleri arka plan işlerinizde de uygulamanızı öneririz.

3. Adım: Sertifika Üretimi

DNS doğrulaması başarıyla sonuçlandığında ACME istemcisini tetikleyip sertifikayı üretirsiniz. Burada dikkat edilmesi gerekenler:

• Her domain için sertifika ve private key’i güvenli şekilde saklamak (diskte şifreleme, yetki sınırlı klasörler).
• Web sunucusu veya reverse proxy konfigürasyonunu yeniden yüklemek (reload) ama bağlantıları kesmeden.
• Sertifika yenilemelerini, trafiğin daha düşük olduğu saatlerde planlamak.

Güvenlik perspektifinden baktığımızda, sertifika ve anahtar yönetimini, genel gizli anahtar yönetimi stratejinizle uyumlu kurgulamak uzun vadede avantaj sağlayacaktır.

4. Adım: Cutover ve Sağlık Kontrolleri

Domain doğrulandı, sertifika hazır; şimdi sıra gerçek trafiği SaaS uygulamanıza yönlendirmeye geldi. Burada önerdiğimiz yaklaşım:

• Önce sağlık kontrolü (health check) yapan bir endpoint üzerinden yeni domainde 200/OK alındığını doğrulayın.
• Ardından müşteriye “DNS değişikliğinizi tamamlayabilirsiniz” mesajını verin.
• DNS geçişi sırasında hem eski hem yeni domaini bir süre paralel olarak destekleyin (301 yönlendirme ile).

Bu sayede, müşterinin DNS’i gecikmeli de güncellense, uygulama tarafında kontrollü bir geçiş döneminiz olur ve son kullanıcılar minimum sorunla karşılaşır.

Operasyonel Gerçekler: Loglar, İzleme, Güvenlik

Loglama ve Gözlemlenebilirlik

Custom domain trafiğini yönetirken gözden kaçan noktalardan biri, hangi tenant’ın hangi domain üzerinden ne kadar trafik aldığı bilgisini log’larda doğru yakalamak. Önerilerimiz:

• Reverse proxy log’larında Host header ve tenant_id bilgilerini birlikte tutun.
• SSL handshake ve sertifika hatalarını ayrı log’larda toplamanız, hatalı domain/sertifika kombinasyonlarını hızlıca tespit etmenizi sağlar.
• 404/5xx oranlarını tenant ve domain bazında takip edin; bu, hem müşteri deneyimi hem de debug süreçlerinde hayat kurtarır.

Sunucu log’larını doğru okumak ve 4xx–5xx hatalarını teşhis etmek için hazırladığımız Apache ve Nginx log teşhis rehberi, custom domain trafiğini analiz ederken de doğrudan işinize yarayacaktır.

Güvenlik ve İzolasyon

Multi‑tenant SaaS’te custom domain desteği verirken şu güvenlik başlıklarını da hesaba katmalısınız:

• Subdomain takeover riskleri: Boşta kalan CNAME hedefleri, yanlış yapılandırılmış CDN/edge kayıtları.
• HSTS ve güvenlik başlıkları: Her tenant’ın domaininde doğru HSTS, CSP, X‑Frame‑Options vb. başlıkları sunmak.
• Rate limiting: Tek bir tenant veya domain üzerinden gelen saldırgan trafiğin diğer tenant’ları etkilemesini engellemek.

Boşta kalan DNS kayıtları ve alt alan adı ele geçirme risklerini anlattığımız subdomain takeover rehberi ve HTTP güvenlik başlıkları rehberi, SaaS ürününüzü çok kiracılı ortamda daha güvenli hâle getirmenize yardımcı olacaktır.

Bu Mimariyi DCHost Üzerinde Nasıl Kurabilirsiniz?

İş multi‑tenant SaaS olunca, “Hangi sunucu türüyle başlamalıyım?” sorusunu doğal olarak çok duyuyoruz. DCHost tarafında sahada gördüğümüz tipik yol haritası şöyle:

• Erken aşama / MVP: Tek güçlü VPS üzerinde uygulama, veritabanı, reverse proxy ve ACME otomasyonunu birlikte çalıştırmak.
• Ürün/pazar uyumu sonrası: Uygulama ve veritabanını ayrı VPS’lere ayırmak; reverse proxy ve SSL katmanını öne alıp çoklu uygulama sunucusuna yönlendirmek.
• İleri aşama: Yüksek trafikli tenant’lar için ayrı node’lar, arka planda replikasyon ve çok bölgeli DNS ile aktif‑aktif/aktif‑pasif mimariler.

Bu geçişleri planlarken, küçük SaaS uygulamaları için en doğru hosting mimarisi yazısındaki tek VPS → çoklu VPS → daha gelişmiş mimari geçiş yol haritasını referans alabilirsiniz. DCHost olarak; domain, DNS, VPS, dedicated sunucu ve gerekirse colocation tarafında bu mimariyi uçtan uca kurarken yanınızda oluyoruz.

Özet ve Son Söz: Custom Domain’i Sonraya Bırakmayın

Multi‑tenant SaaS ürün geliştirirken feature listesinde “müşteri kendi alan adını bağlayabilsin” maddesi çoğu zaman “ileriki sürümlerde gelir” diye erteleniyor. Ancak gerçek dünya deneyimi bize şunu gösterdi: Eğer ilk günden DNS, SSL/TLS ve yönlendirme mimarisini multi‑tenant ve custom domain gözlüğüyle tasarlamazsanız, ürününüz büyüdükçe bu eksik mimari sizi yavaşlatıyor. Domain sahipliği doğrulaması, DNS TTL stratejileri, ACME tabanlı otomatik sertifika yönetimi, SNI ile tek IP üzerinde çoklu domain, 301‑HSTS‑canonical kurguları ve sağlam log/izleme mimarisi bir araya geldiğinde, gerçekten ölçeklenebilir bir SaaS altyapınız oluyor.

Eğer şu an elinizde çalışan bir SaaS ürünü var ve custom domain desteğini yeni yeni düşünmeye başladıysanız, panik yapmaya gerek yok; ama bir mimari tasarım oturumu yapmanın zamanı gelmiş demektir. DCHost ekibi olarak, bu yazıda anlattığımız desenleri günlük işimizde uyguluyor; DNS, SSL ve routing tarafında sürdürülebilir, otomasyona dayalı yapılar kuruyoruz. Kendi SaaS projeniz için benzer bir mimariyi nereden başlatmanız gerektiğini netleştirmek isterseniz, mevcut sunucu/domin durumunuzu birlikte analiz edip size özel bir yol haritası çıkarabiliriz. Custom domain’i sonradan eklenen bir özellik değil, mimari tasarımın ilk vatandaşı olarak düşünmek hem sizi hem de müşterilerinizi uzun vadede ciddi anlamda rahatlatacaktır.