Multi-Tenant (Çoklu Kiracı) Sistemlerde Wildcard DNS Yönlendirmeleri

Bir SaaS uygulamasında yeni müşteri açıldığında her defasında DNS paneline girip yeni kayıt oluşturmak zorunda kaldığınızı düşünün. On tenant için yönetilebilir görünen bu süreç, binlerce tenant olduğunda ciddi bir operasyon yüküne dönüşür. İşte Multi-Tenant (Çoklu Kiracı) Sistemlerde Wildcard DNS Yönlendirmeleri tam bu noktada devreye girer.

Bu rehberde tenant subdomain yapısından wildcard DNS kayıtlarına, TLS sertifikalarından reverse proxy yönlendirmesine, veri izolasyonundan custom domain yönetimine kadar üretim ortamında ihtiyaç duyacağınız mimari parçaları birlikte ele alacağız. Amacımız yalnızca DNS kaydı eklemeyi anlatmak değil. Sağlam bir SaaS altyapısında DNS, routing, güvenlik ve tenant kimliğinin nasıl birlikte çalışması gerektiğini netleştirmek.

Özellikle multi-tenant sistemlerde wildcard DNS nasıl yapılandırılır, SaaS uygulamalarında wildcard subdomain ve DNS yönlendirmesi nasıl yapılır ve wildcard DNS ile tenant subdomain routing ve SSL sertifika yönetimi nasıl planlanır sorularına uygulama odaklı yanıtlar bulacaksınız.

Multi-Tenant Sistem Nedir?

Multi-tenant mimari, aynı uygulamanın birden fazla müşteri veya kuruma hizmet verdiği yapıdır. Her müşteri aynı yazılım altyapısını kullanabilir ancak verileri, yetkileri ve çalışma bağlamı birbirinden ayrılır.

Tenant (Kiracı) Nedir?

Tenant, uygulama içindeki bağımsız müşteri alanını ifade eder. Bir şirket, ekip, kurum veya abonelik hesabı tenant olabilir.

Tek Uygulamanın Birden Fazla Kuruma Hizmet Vermesi

Tek kod tabanı ve ortak servisler üzerinden yüzlerce kuruma hizmet vermek SaaS modelinin önemli avantajlarından biridir. Buradaki kritik nokta her isteğin doğru tenant bağlamında çalıştırılmasıdır.

Shared Infrastructure ve Tenant Isolation

Altyapı ortak olabilir. Buna rağmen tenant verileri, cache alanları, session bilgileri ve yetkilendirme kuralları birbirinden ayrılmalıdır.

Multi-Tenancy ile Multi-Instance Arasındaki Fark

Multi-tenancy modelinde tenant'lar çoğunlukla aynı çalışan uygulamayı paylaşır. Multi-instance modelinde ise her müşteri için ayrı uygulama instance'ı veya deployment oluşturulabilir.

SaaS Sistemlerinde Tenant Kimliği Neden Gereklidir?

Bir isteğin hangi müşteriye ait olduğunu bilmeden doğru veritabanı sorgusu, yetki kontrolü veya cache erişimi yapılamaz. Bu yüzden tenant kimliği request yaşam döngüsünün temel parçalarından biridir.

Tenant Nasıl Tanımlanır?

Tenant kimliği URL, header, token veya domain üzerinden belirlenebilir. Seçim, ürünün kullanıcı deneyimi ve güvenlik modeline göre yapılmalıdır.

Subdomain-Based Tenant Identification

En yaygın modellerden biridir. Hostname içindeki subdomain bölümü tenant slug olarak kullanılır.

acme.example.com

Burada acme tenant slug olabilir. Uygulama hostname'i okuyup registry üzerinden ilgili tenant kaydını bulur.

globex.example.com

Aynı uygulama globex değerini farklı tenant kimliğiyle eşleştirir. DNS tarafında iki tenant için ayrı kayıt gerekmeyebilir.

Path-Based Identification

Tenant kimliği URL yolunun ilk bölümünden çıkarılabilir. DNS açısından daha basittir fakat white-label ihtiyaçlarında daha sınırlı olabilir.

example.com/acme

Bu yapıda acme path içinden alınır. Hostname bütün tenant'lar için aynıdır.

Header-Based Identification

API sistemlerinde tenant kimliği özel bir header üzerinden taşınabilir. Ancak istemciden gelen tenant değerine tek başına güvenilmemelidir.

JWT / Token-Based Identification

Tenant ID erişim token'ındaki güvenilir claim üzerinden bulunabilir. Yine de sunucu tarafında kullanıcının tenant üyeliği doğrulanmalıdır.

Custom Domain-Based Identification

portal.customer.com gibi domainler doğrudan tenant registry içindeki hostname kaydıyla eşleştirilebilir.

Hangi Model Ne Zaman Kullanılmalı?

B2B SaaS uygulamalarında subdomain yaklaşımı güçlü bir başlangıçtır. API yoğun sistemlerde token desteği eklenebilir. White-label ürünlerde ise custom domain eşlemesi çoğu zaman gerekir.

Neden Tenant Başına Subdomain Kullanılır?

Marka Algısı

Tenant'a özel URL, müşterinin ürünü kendi çalışma alanı gibi algılamasına yardımcı olur.

Kullanıcıya Ayrı Alan Hissi Vermek

acme.example.com adresi, example.com/acme yapısına göre daha bağımsız bir çalışma alanı hissi verebilir.

Tenant'ı URL'den Doğrudan Tanımlamak

Hostname parse edilerek tenant kimliği request'in ilk aşamalarında belirlenebilir.

White-Labeling

Subdomain modeli daha sonra custom domain desteğine geçiş için düzenli bir temel sunar.

Tenant Bazlı Trafik Yönetimi

Reverse proxy veya edge katmanı hostname üzerinden tenant bazlı routing kararı verebilir.

Gelecekte Tenant Bazlı Altyapı Ayırma Esnekliği

Kurumsal bir tenant ileride dedicated cluster'a taşınsa bile kullanıcı aynı hostname'i kullanmaya devam edebilir.

Wildcard DNS Nedir?

Wildcard DNS, belirli bir domain altında açıkça tanımlanmamış alt alan adlarını tek bir DNS kaydı üzerinden karşılayabilmenizi sağlar.

Normal DNS Kaydı Nasıl Çalışır?

Normal bir A veya CNAME kaydı belirli hostname için oluşturulur. Örneğin api.example.com yalnızca o isim için geçerlidir.

Wildcard Kaydındaki \* Ne Anlama Gelir?

* işareti eşleşen alt alan adları için genel bir kural ifade eder.

\*.example.com Örneği

Bu kayıt sayesinde acme.example.com ve globex.example.com gibi pek çok tenant hostname'i aynı hedefe çözülebilir.

Wildcard A Kaydı

Wildcard A kaydı alt alan adlarını bir IPv4 adresine yönlendirir.

Wildcard AAAA Kaydı

AAAA kaydı aynı işlemi IPv6 hedefi için yapar.

Wildcard CNAME Kaydı

Wildcard CNAME, tenant subdomainlerini CDN veya başka bir canonical hostname'e yönlendirmek için kullanılabilir.

DNS Wildcard'ın Sağladığı Temel Avantaj

Her tenant için ayrı DNS kaydı oluşturma zorunluluğunu ortadan kaldırır. Routing kararını DNS'ten uygulama, proxy veya edge katmanına taşırsınız.

Wildcard DNS Olmadan Tenant Onboarding Nasıl Çalışır?

Her Tenant İçin Ayrı DNS Kaydı Oluşturmak

Yeni müşteri geldiğinde acme.example.com gibi ayrı kayıt açılması gerekir.

DNS Provider API Kullanmak

Süreç API ile otomatikleştirilebilir ancak yine de her tenant için DNS değişikliği yapılır.

Propagation Beklemek

Yeni kaydın recursive resolver cache'lerine yayılması zaman alabilir.

Tenant Sayısı Arttıkça Oluşan Operasyonel Maliyet

Binlerce tenant olduğunda DNS kayıt yaşam döngüsünü yönetmek gereksiz bir iş yüküne dönüşebilir.

Wildcard DNS ile Tenant Onboarding Nasıl Değişir?

Bir Kez Wildcard DNS Oluşturmak

Örneğin *.example.com kaydı bir kez oluşturulur.

Yeni Tenant İçin DNS Kaydı Açmamak

Yeni tenant geldiğinde DNS tarafında yeni kayıt eklenmez.

Tenant Registry'ye Kayıt Eklemek

Uygulamanın tenant registry tablosuna slug, hostname ve tenant ID bilgileri eklenir.

İlk Request'te Tenant'ı Çözmek

Kullanıcının ilk isteğinde hostname registry üzerinde aranır ve tenant context oluşturulur.

Zero-Touch Tenant Provisioning

Bu model otomatik tenant onboarding için güçlü bir temeldir. Kullanıcı tenant oluşturur ve birkaç uygulama işlemi sonrasında subdomain kullanılabilir hale gelir.

Wildcard DNS Request Akışı Nasıl Çalışır?

Kullanıcı acme.example.com Adresini Açar

Tarayıcı önce hostname için DNS çözümlemesi başlatır.

Recursive DNS Resolver Devreye Girer

Kullanıcının resolver servisi cached kayıt yoksa authoritative DNS'e ulaşır.

Authoritative DNS Wildcard Kaydını Döndürür

Explicit kayıt bulunmadığında wildcard kuralı eşleşebilir.

İstek CDN / WAF / Load Balancer'a Ulaşır

DNS sonucundaki hedefe bağlantı kurulur ve HTTP isteği edge veya load balancer katmanına gelir.

TLS Handshake Gerçekleşir

HTTPS kullanılıyorsa sunucu ilgili hostname için geçerli sertifika sunmalıdır.

Reverse Proxy Hostname'i Koruyarak Backend'e İletir

Backend tenant çözümlemesi yapacaksa orijinal host bilgisinin güvenilir biçimde aktarılması gerekir.

Tenant Resolver Hostname'i Tenant ID'ye Dönüştürür

acme.example.com registry sorgusuyla ilgili tenant ID'ye eşlenir.

Uygulama Tenant Context'i Oluşturur

Bu context daha sonra authorization, database, cache ve logging katmanlarında kullanılmalıdır.

Wildcard DNS ve Explicit DNS Kayıtları Nasıl Birlikte Çalışır?

Exact Record'ın Wildcard'dan Öncelikli Olması

Belirli hostname için açık kayıt varsa DNS çözümlemesinde wildcard yerine exact kayıt kullanılır.

api.example.com İçin Ayrı Kayıt

API trafiğini farklı altyapıya göndermek istiyorsanız explicit kayıt oluşturabilirsiniz.

www\.example.com İçin Ayrı Kayıt

www.example.com pazarlama sitesi gibi farklı bir hedefe yönlendirilebilir.

Tenant Trafiğinin Wildcard'a Düşmesi

Explicit olarak tanımlanmamış tenant isimleri wildcard üzerinden ortak giriş noktasına ulaşır.

Reserved Subdomain'leri Ayrı Yönetmek

Sistem servisleri tenant slug olarak kullanılmamalıdır.

Reserved Subdomain Listesi Oluşturmak

www

Web sitesi için ayrılabilir.

api

API endpointleri için ayrılabilir.

admin

Merkezi yönetim paneli için kullanılabilir.

auth

Kimlik doğrulama servisine ayrılabilir.

mail

E-posta altyapısıyla karışmaması için rezerve edilmesi mantıklıdır.

cdn

Statik içerik veya medya dağıtım katmanı için ayrılabilir.

status

Sistem durum sayfası için kullanılabilir.

support

Destek portalına ayrılabilir.

Tenant'ların Sistem Subdomain'lerini Alamamasını Sağlamak

Slug oluşturma aşamasında reserved word kontrolü yapılmalıdır. Bu doğrulama yalnızca frontend'de değil backend'de de uygulanmalıdır.

Wildcard DNS Tenant'ın Var Olduğu Anlamına Gelir mi?

Hayır. Wildcard DNS yalnızca hostname'i bir hedefe çözer. Tenant'ın gerçekten mevcut olup olmadığını uygulama belirler.

DNS ile Tenant Registry Arasındaki Fark

DNS ağ yönlendirmesiyle ilgilenir. Tenant registry ise uygulama kimliği ve durum bilgisi taşır.

Rastgele Subdomain'lerin de Origin'e Ulaşabilmesi

rastgele123.example.com wildcard nedeniyle origin'e gelebilir. Bu hostun gerçek tenant olduğu anlamına gelmez.

Hostname Allowlist

Geçerli hostname listesi tenant registry veya güvenilir metadata katmanından kontrol edilmelidir.

Tenant Registry Lookup

Her hostname geçerli tenant kaydıyla eşleştirilmelidir.

Unknown Hostname Davranışı

Bilinmeyen hostlar açık bir politika ile reddedilmelidir.

404

Kaynak bulunamadı yanıtı sade bir tercihtir.

421 Misdirected Request

İstek yanlış hedefe gelmişse HTTP 421 semantik olarak uygun olabilir.

Kontrollü Landing Page

İsterseniz bilinmeyen tenant için genel ve veri göstermeyen bir açıklama sayfası sunabilirsiniz.

Bilinmeyen Host'u Default Tenant'a Yönlendirmeme

Bu yaklaşım yanlış tenant verisinin görüntülenmesine kadar uzanabilecek güvenlik problemleri doğurabilir.

Tenant Registry Nasıl Tasarlanmalı?

Tenant ID

İç sistemlerde kullanılan değişmez kimlik olmalıdır.

Tenant Slug

Subdomain üretiminde kullanılabilecek okunabilir değerdir.

Primary Hostname

Tenant'ın tercih edilen platform hostname'i tutulabilir.

Custom Domain

Tenant'a ait doğrulanmış özel domainler ayrı kayıtlar halinde saklanabilir.

Status

Tenant'ın yaşam döngüsü açık biçimde modellenmelidir.

Pending

Kurulum aşamasındaki tenant.

Active

Trafik almaya hazır tenant.

Suspended

Geçici olarak erişimi durdurulmuş tenant.

Deleted

Silinmiş tenant kaydı.

Certificate Status

Özellikle custom domain kullanılıyorsa sertifika hazırlık durumu takip edilmelidir.

Routing Target

Tenant'ın hangi origin veya cluster'a gönderileceğini belirler.

Region

Multi-region yapılarda tenant'ın ana bölgesi burada tutulabilir.

Plan / Tier

Routing, limit veya altyapı izolasyonu kararlarında kullanılabilir.

Tenant Slug Tasarımı

Slug Benzersizliği

Aynı root domain altında iki aktif tenant aynı slug değerini kullanmamalıdır.

Büyük/Küçük Harf Normalizasyonu

Hostname değerlerini küçük harfe normalize etmek karşılaştırmaları sadeleştirir.

Maksimum Uzunluk

DNS label sınırlarını ve ürün kullanıcı deneyimini dikkate alan makul bir sınır koyun.

Geçerli Karakterler

Basit slug politikası için harf, rakam ve izin verilen kısa ayraçlar tercih edilebilir.

Unicode ve Internationalized Domain Names

Uluslararası domain desteğinde kullanıcı girdisi ile gerçek DNS gösterimi arasında dönüşüm yapılması gerekir.

Punycode

IDN değerleri DNS katmanında Punycode formuna dönüşebilir. Registry karşılaştırmalarında normalize edilmiş değer kullanılmalıdır.

Homograph Riskleri

Görsel olarak benzer karakterler kötüye kullanılabilir. Kullanıcıya gösterilen isimlerle gerçek hostname arasında güvenli kontrol gerekir.

Reserved Word Kontrolü

api, admin ve auth gibi isimlerin tenant slug olarak alınmasını engelleyin.

Hostname'den Tenant Nasıl Çözülür?

Host Header'ı Okumak

Uygulama proxy tarafından doğrulanmış host bilgisini alır.

Port Bilgisini Ayırmak

Development veya özel port kullanılan ortamlarda hostname ile port birbirinden ayrılmalıdır.

Hostname'i Normalize Etmek

Küçük harfe dönüştürme ve gereksiz son nokta temizliği gibi işlemler uygulanabilir.

Root Domain'i Doğrulamak

Hostname'in beklenen platform domainine ait olup olmadığı kontrol edilir.

Subdomain Bölümünü Çıkarmak

Örneğin acme.example.com içinden acme bölümü alınır.

Tenant Registry Lookup

Slug üzerinden tenant aranır ve yalnızca izin verilen durumdaki kayıt kabul edilir.

Tenant Context Oluşturmak

Tenant ID, region ve plan gibi veriler request scope içine eklenebilir.

Host Header'a Güvenilebilir mi?

Doğrudan güvenilmemelidir. Host bilgisi istemci girdisinin bir parçasıdır ve doğrulama gerektirir.

Host Header Injection

Kontrol edilmeyen host değeri şifre sıfırlama linklerinden cache davranışına kadar çeşitli sorunlara yol açabilir.

Beklenmeyen Hostname'leri Reddetmek

Registry'de veya güvenilir allowlist içinde bulunmayan hostlara servis vermeyin.

Trusted Host Listesi

Platform domainleri ve doğrulanmış custom domainler güvenilir listede tutulabilir.

Reverse Proxy Tarafında Host Validation

İlk kontrolü edge veya proxy katmanında yapmak gereksiz trafiği backend'e ulaşmadan kesebilir.

Application Tarafında İkinci Doğrulama

Proxy kontrolü uygulama seviyesindeki tenant doğrulamasının yerine geçmemelidir.

Absolute URL Üretirken Host Header Kullanmanın Riskleri

Kontrolsüz hostname ile password reset veya OAuth callback URL üretmek saldırı yüzeyini büyütebilir.

Tenant Resolution Nerede Yapılmalı?

CDN / Edge Katmanında

Düşük gecikme ve bölgesel origin seçimi gereken yapılarda avantajlıdır.

Reverse Proxy'de

Basit hostname tabanlı routing için pratik bir çözümdür.

API Gateway'de

API odaklı platformlarda tenant resolution merkezi gateway politikalarının parçası olabilir.

Application Middleware'de

Tenant context'in uygulama kodunda kolay erişilebilir olması açısından yaygın yöntemdir.

Framework Katmanında

Request lifecycle ile sıkı entegrasyon gerekiyorsa framework middleware veya guard yapıları kullanılabilir.

Hybrid Tenant Resolution

Edge routing ve application validation birlikte uygulanabilir.

Hangi Yaklaşım Ne Zaman Mantıklıdır?

Küçük sistemlerde application middleware yeterli olabilir. Çok bölgeli SaaS mimarisinde edge çözümleme ve backend doğrulamasını birlikte kullanmak daha kontrollü sonuç verir.

Edge-Based Tenant Routing

Hostname'i Edge'de Parse Etmek

İstek origin'e gitmeden tenant slug ayrıştırılabilir.

Edge KV / Registry Lookup

Tenant mapping düşük gecikmeli edge veri katmanında tutulabilir.

Tenant Metadata

Region, plan ve routing target gibi bilgiler edge kararlarında kullanılabilir.

Tenant Bazlı Origin Seçmek

Standart tenant ortak cluster'a, enterprise tenant ayrı origin'e gönderilebilir.

Bölgesel Routing

Tenant'ın home region bilgisine göre trafik uygun bölgeye yönlendirilebilir.

Edge Cache ile Tenant Mapping Hızlandırmak

Registry sonuçları kontrollü TTL ile cache'lenebilir. Durum değişikliklerinde invalidation süreci düşünülmelidir.

Reverse Proxy ile Wildcard Subdomain Routing

Nginx

Wildcard server name ve proxy kurallarıyla hostname tabanlı routing yapılabilir.

Caddy

Dinamik TLS ve reverse proxy senaryolarında kullanılabilecek seçeneklerden biridir.

Traefik

Container ve Kubernetes ortamlarında host tabanlı routing kuralları oluşturabilir.

HAProxy

Host header ve ACL kuralları üzerinden farklı backend hedefleri seçilebilir.

Host-Based Routing

Routing kararı HTTP hostname değerine göre verilir.

Host Header'ı Backend'e Taşımak

Backend tenant çözümlemesi yapıyorsa doğrulanmış host bilgisinin korunması gerekir.

Tek Backend'e Routing

Tüm tenant trafiği ortak application cluster'a gönderilebilir.

Tenant Bazlı Farklı Backend'e Routing

Registry veya edge metadata kullanılarak belirli tenant farklı altyapıya taşınabilir.

Nginx ile Wildcard Hostname Mantığı

Wildcard server\_name

Wildcard hostname kuralı platform alt alan adlarını aynı server bloğunda karşılayabilir.

HTTP → HTTPS Redirect

HTTP trafiği kontrollü biçimde HTTPS'e yönlendirilmelidir.

Reverse Proxy

Doğrulanan trafik application backend'e aktarılır.

Forwarded Headers

Proto, client IP ve host bilgileri yalnızca güvenilen proxy zinciri üzerinden işlenmelidir.

Hostname Validation

Wildcard server name kullanmak her hostname'i tenant olarak kabul etmeniz gerektiği anlamına gelmez.

Default Server Güvenliği

Beklenmeyen hostname'ler için veri göstermeyen güvenli bir default server davranışı tanımlayın.

Kubernetes Ortamında Wildcard Tenant Routing

Ingress

Wildcard host kuralları ingress kaynaklarıyla tanımlanabilir.

Kubernetes Gateway API

Daha esnek routing politikaları için Gateway API modeli değerlendirilebilir.

Wildcard Hostname

Tenant hostları ortak ingress giriş noktasında karşılanabilir.

Ingress Controller

Controller TLS termination ve backend yönlendirmesini üstlenebilir.

Tenant Resolver Service

Hostname tenant ID'ye uygulama içindeki merkezi bir resolver ile çevrilebilir.

Tek Deployment / Çok Tenant

Çoğu SaaS sistemi ortak deployment üzerinden birçok tenant'a hizmet verebilir.

Tenant Bazlı Namespace veya Workload Routing

Yüksek izolasyon isteyen müşteriler belirli namespace veya workload kümelerine yönlendirilebilir.

CDN Üzerinde Wildcard Routing

Wildcard DNS → CDN

Wildcard DNS hedefi CDN giriş noktasına yönlendirilebilir.

TLS Termination

HTTPS bağlantısı edge üzerinde sonlandırılabilir.

WAF

Host validation, rate limiting ve saldırı filtreleme kuralları edge katmanında uygulanabilir.

Edge Rewrite

İstekler hostname veya tenant metadata temelinde yeniden yönlendirilebilir.

Hostname-Based Cache

Tenantlar arası içerik karışmasını önlemek için hostname cache anahtarının parçası olmalıdır.

Origin Selection

Tenant veya region bilgisine göre farklı origin seçilebilir.

Tenant Metadata'yı Edge'e Taşımak

Multi-tenant uygulamalarda DNS Cloudflare reverse proxy ve tenant izolasyonu düşünülürken tenant metadata'nın edge'e hangi güven modeliyle taşındığı ayrıca tasarlanmalıdır.

Wildcard DNS ile Wildcard SSL Aynı Şey midir?

Hayır. DNS ve TLS birbirinden ayrı katmanlardır.

DNS Wildcard'ın Görevi

Hostname'i IP veya başka bir DNS hedefine çözer.

TLS Wildcard'ın Görevi

Belirli subdomain kapsamı için HTTPS kimlik doğrulaması sağlar.

İki Katmanın Birbirinden Bağımsız Çalışması

DNS doğru çalışırken sertifika kapsamı hatalı olabilir.

DNS Çalıştığı Halde TLS'in Başarısız Olabileceği Senaryolar

app.acme.example.com DNS ile çözülebilir fakat yalnızca *.example.com sertifikası bu iki seviyeli hostname'i kapsamaz.

Wildcard TLS Sertifikası Hangi Alanları Kapsar?

\*.example.com

Genellikle root domainin tek seviye altındaki hostname'leri kapsar.

acme.example.com

Wildcard kapsamına girer.

globex.example.com

Wildcard kapsamına girer.

Apex Domain'in Kapsanmaması

example.com

*.example.com sertifikası apex alan adını kendiliğinden kapsamaz.

Çok Seviyeli Subdomain'in Kapsanmaması

app.acme.example.com

Tek seviyeli wildcard sertifikası bu hostname'i kapsamaz.

Apex + Wildcard'ı Aynı Sertifikaya Eklemek

Sertifika SAN listesinde hem example.com hem *.example.com bulunabilir.

Wildcard Sertifika Nasıl Alınır?

ACME

ACME protokolü sertifika issuance ve renewal süreçlerini otomatikleştirmek için kullanılır.

DNS-01 Challenge

Wildcard sertifikalarda domain kontrolünün DNS üzerinden kanıtlanmasını sağlar.

\_acme-challenge

Doğrulama için ilgili TXT kayıtları bu isim altında oluşturulur.

DNS Ownership Verification

Certificate Authority gerekli TXT değerini görerek domain kontrolünü doğrular.

Sertifika Oluşturma

Doğrulama başarılı olunca sertifika üretilir ve ilgili edge veya proxy katmanına yüklenir.

Otomatik Renewal

Üretim ortamında sertifika yenileme manuel bir iş olmamalıdır.

DNS-01 Neden Wildcard Sertifikalarda Önemlidir?

HTTP-01'in Wildcard Sertifika Üretememesi

Wildcard issuance için DNS tabanlı kontrol gerekir.

DNS TXT Record ile Domain Kontrolü

DNS-01 challenge sırasında geçici TXT kaydı oluşturulur.

DNS Provider API Entegrasyonu

Otomatik renewal için DNS kayıtlarının API aracılığıyla yönetilmesi faydalıdır.

Renewal Otomasyonu

Sertifika süresi yaklaşmadan challenge, doğrulama ve dağıtım işlemleri otomatik yürütülmelidir.

DNS Propagation Problemleri

TXT kaydının authoritative DNS üzerinde görünmesi ile recursive cache davranışı arasında gecikme olabilir.

DNS API Credential'larını Nasıl Güvenli Yönetmeliyiz?

Root API Key Kullanmamak

Zone değişikliği için tüm hesabı kontrol eden anahtar vermek gereksiz risk oluşturur.

Minimum Yetkili API Token

Token yalnızca gereken DNS işlemlerini yapabilmelidir.

Yalnızca Gerekli Zone'a Yetki

Mümkünse credential tek zone ile sınırlandırılmalıdır.

Secret Manager

Credential değerlerini kaynak kodda veya düz environment dosyalarında bırakmak yerine güvenli secret altyapısı kullanın.

Credential Rotation

Anahtarlar periyodik olarak yenilenmeli ve eski değerler iptal edilmelidir.

Audit Logging

DNS değişikliklerinin kim tarafından veya hangi servis tarafından yapıldığı izlenebilmelidir.

Tek Wildcard Sertifika mı, Tenant Başına Sertifika mı?

Tek Wildcard Sertifikanın Avantajları

Platform subdomainleri için operasyon oldukça basitleşir.

Blast Radius

Tek private key'in ele geçirilmesi çok sayıda tenant hostname'ini etkileyebilir.

Private Key Güvenliği

Wildcard private key merkezi ve güçlü korunan altyapıda tutulmalıdır.

Tenant Başına Sertifika

Her hostname için ayrı sertifika kullanmak izolasyonu artırabilir ancak yönetim maliyeti yükselir.

Sertifika Yönetim Maliyeti

Binlerce sertifikanın issuance, renewal ve deployment süreci ayrı izleme gerektirir.

Custom Domain Gereksinimleri

Müşteriye ait domainler wildcard platform sertifikanız tarafından kapsanmaz.

Hybrid Sertifika Stratejisi

Platform subdomainleri için wildcard, custom domainler için hostname bazlı sertifikalar dengeli bir modeldir.

Custom Domain ile Wildcard Subdomain Arasındaki Fark

acme.platform.com

Domain platform sahibinin kontrolündedir.

app.acme.com

Domain tenant veya müşterinin kontrolündedir.

Domain'in Kimin Kontrolünde Olduğu

Bu ayrım DNS doğrulama ve lifecycle süreçlerini doğrudan etkiler.

DNS Yapılandırmasının Kimin Tarafından Yapıldığı

Platform subdomaininde işlemi siz yönetirsiniz. Custom domainde müşteri DNS ayarı yapmak zorundadır.

TLS Sertifikasının Kapsamı

Platform wildcard sertifikası müşteri domainini kapsamaz.

Tenant Resolution Farkı

Custom domainlerde slug parse etmek yerine exact hostname registry eşlemesi yapmak daha güvenlidir.

Tenant'a Custom Domain Desteği Nasıl Verilir?

Tenant Custom Domain Girer

Kullanıcı yönetim ekranından kullanmak istediği hostname'i tanımlar.

Domain Normalize Edilir

Hostname küçük harfe dönüştürülür ve güvenli format kontrolü yapılır.

Ownership Verification Başlatılır

Domain sahibinin gerçekten ilgili tenant olduğu doğrulanmadan trafik aktif edilmemelidir.

CNAME / TXT Talimatı Üretilir

Kullanıcıya DNS panelinde oluşturacağı kayıt gösterilir.

DNS Doğrulanır

Uygulama beklenen doğrulama kaydını kontrol eder.

TLS Sertifikası Oluşturulur

Ownership başarılı olduğunda sertifika provisioning başlatılır.

Hostname → Tenant Mapping Aktifleştirilir

Sertifika hazır olduktan sonra hostname registry üzerinde aktif hale getirilebilir.

Custom Domain Ownership Nasıl Doğrulanır?

TXT Verification

Rastgele verification token TXT kaydıyla yayınlatılabilir.

CNAME Verification

Müşteri kontrollü hostname'i sizin doğrulama adresinize CNAME yapabilir.

HTTP Verification

Bazı senaryolarda belirli bir HTTP path üzerinden token doğrulaması uygulanabilir.

Verification Token

Token tahmin edilemez ve tenant ile ilişkilendirilmiş olmalıdır.

Domain'i Doğrulamadan Trafiğe Açmamak

Aksi halde başka bir müşteriye ait hostname'in yanlış tenant'a bağlanması mümkün olabilir.

Domain Ownership Değişikliklerini Yeniden Doğrulamak

Uzun süreli custom domain kullanımında ownership durumu periyodik olarak kontrol edilebilir.

Custom Domain'de Apex ve Subdomain Farkı

www\.customer.com

Subdomain olduğu için CNAME kullanımı genellikle daha kolaydır.

app.customer.com

SaaS custom domain onboarding için sık kullanılan yapıdır.

customer.com

Apex domain, DNS provider özelliklerine bağlı olarak farklı yaklaşım gerektirebilir.

CNAME'in Apex Sınırlamaları

Klasik DNS kurallarında apex üzerinde CNAME kullanımı sorunlu olabilir.

ALIAS / ANAME

Bazı DNS servisleri apex için CNAME benzeri özel kayıt modelleri sunar.

CNAME Flattening

Bazı altyapılar CNAME davranışını apex üzerinde çözüp A veya AAAA sonucu sunabilir.

Kullanıcı Onboarding'ine Etkisi

Custom domain yönergeleriniz müşterinin kullandığı DNS altyapısına göre açık ve alternatifli olmalıdır.

On-Demand TLS

İlk Request'te Sertifika Üretmek

Bazı sistemler ilk geçerli istekte sertifika provisioning başlatabilir.

Bilinmeyen Hostname İçin Sertifika Üretmeme

Her gelen hostname için otomatik sertifika istemek kötüye kullanım riskidir.

Domain Allowlist

Yalnızca önceden doğrulanmış domainler sertifika alabilmelidir.

Certificate Authority Rate Limits

Yoğun onboarding dönemlerinde issuance limitleri hesaba katılmalıdır.

Certificate Provisioning Queue

Provisioning işlemlerini kontrollü queue üzerinden yürütmek hataları ve tekrar denemeleri yönetmeyi kolaylaştırır.

Pre-Provisioning vs On-Demand

Kurumsal ürünlerde domain doğrulandıktan sonra sertifikayı önceden hazırlamak daha öngörülebilir kullanıcı deneyimi sunabilir.

Tenant Onboarding State Machine

Tenant Created

Tenant temel kaydı oluşturulur.

Slug Reserved

Slug başka tenant tarafından kullanılamayacak şekilde rezerve edilir.

DNS Ready

Platform wildcard kullanıyorsa bu aşama doğrudan hazır olabilir. Custom domain için doğrulama gerekebilir.

Certificate Ready

HTTPS sertifikası başarıyla hazırlanmıştır.

Application Provisioned

Gerekli veri veya konfigürasyon kayıtları tamamlanmıştır.

Active

Tenant kullanıcı trafiğine açılır.

Suspended

Erişim kontrollü olarak durdurulur.

Deleted

Tenant yaşam döngüsü kapatılır ve güvenli temizleme işlemleri başlatılır.

Zero-Touch Tenant Onboarding

Tenant Kaydı

Kullanıcı veya yönetim sistemi tenant oluşturur.

Otomatik Slug Üretimi

Uygun ve benzersiz slug otomatik üretilebilir.

Wildcard DNS Sayesinde DNS İşlemi Gerekmemesi

Platform subdomaini için ayrıca DNS kaydı açılmaz.

Tenant Registry Güncelleme

Slug ve hostname tenant ID ile eşleştirilir.

İlk Request'in Çalışması

Registry aktif olduğunda hostname ilk istekte çözülebilir.

Tenant Oluştururken Deployment Yapmamak

Shared SaaS modelinde yeni tenant için ayrı deployment gerektirmemesi ölçeklenebilirliği ciddi biçimde kolaylaştırır.

Tenant Silindiğinde Subdomain Ne Olmalı?

DNS'in Wildcard Nedeniyle Çalışmaya Devam Etmesi

Tenant silinse bile hostname DNS üzerinden origin'e çözülebilir.

Tenant Registry'den Silme

Aktif tenant mapping kaldırılmalıdır.

Tombstone Record

Silinen tenant için geçici tombstone kaydı tutmak eski istekleri kontrollü yönetmeye yardımcı olabilir.

Slug'ın Yeniden Kullanılması

Hemen yeniden kullanım eski linkler ve tokenlar nedeniyle riskli olabilir.

Eski Session ve Token'ların İptali

Tenant kapatıldığında aktif yetkilendirme materyalleri geçersiz hale getirilmelidir.

Cache Temizliği

Tenant'a ait CDN, Redis ve application cache içerikleri temizlenmelidir.

Custom Domain'i Serbest Bırakmak

Mapping ve sertifika lifecycle işlemleri kontrollü biçimde sonlandırılmalıdır.

Tenant Slug Yeniden Kullanımı Güvenli midir?

Eski URL'ler

Eski bağlantılar yeni tenant'a ulaşabilir.

Browser Cache

Tarayıcı önbelleğinde eski kaynaklar kalabilir.

Search Engine Cache

Arama motorları eski sayfaları bir süre daha gösterebilir.

Eski OAuth Bağlantıları

Callback veya state akışlarında eski tenant referansları bulunabilir.

Webhook'lar

Dış servisler eski tenant URL'lerine webhook göndermeye devam edebilir.

Slug Reuse Cooldown

Silinen slug için belirli bekleme süresi uygulamak güvenliği artırır.

Kritik Slug'ları Kalıcı Olarak Rezerve Etmek

Sistem adları veya geçmişte hassas kullanım görmüş slug değerleri tekrar dağıtılmayabilir.

Authentication Wildcard Subdomain'lerde Nasıl Tasarlanmalı?

Tenant Başına Login

Her tenant kendi subdomaini üzerinden login akışını başlatabilir.

Merkezi Authentication Domain

auth.example.com

Kimlik doğrulama merkezi bir hostname altında tutulabilir.

Tenant Context'i Auth Akışında Korumak

Kullanıcının hangi tenant'tan login başlattığı sunucu tarafında doğrulanmış state ile taşınmalıdır.

Login Sonrası Doğru Tenant'a Dönmek

Redirect hedefi allowlist üzerinden seçilmeli, istemcinin verdiği rastgele URL doğrudan kullanılmamalıdır.

Tenant Üyeliğini Sunucu Tarafında Doğrulamak

Kullanıcının kimliğinin doğrulanması ilgili tenant'a erişebileceği anlamına gelmez.

OAuth ve OIDC Redirect URI Problemi

Tenant Başına Farklı Callback URL

Her tenant subdomainini ayrı redirect URI yapmak yönetimi zorlaştırabilir.

Wildcard Redirect URI'ya Güvenmeme

OAuth sağlayıcılarında exact redirect URI kontrolü güvenlik açısından tercih edilmelidir.

Exact Redirect URI Matching

Önceden kayıtlı callback adresi kullanılmalıdır.

Merkezi Callback Endpoint

auth.example.com/callback gibi merkezi bir adres tenant sayısından bağımsız çalışabilir.

State Parametresinde Güvenli Tenant Context

State değeri imzalı veya sunucu tarafındaki oturumla ilişkilendirilmiş olmalıdır.

Open Redirect Oluşturmamak

Login sonrası dönüş adresi allowlist dışında olmamalıdır.

Cookie Yönetimi ve Tenant İzolasyonu

Host-Only Cookie

Cookie yalnızca oluşturulduğu hostname'e gönderilir ve tenant izolasyonu açısından güçlü bir varsayılan olabilir.

Domain Cookie

Domain kapsamı verilirse cookie birden fazla subdomaine taşınabilir.

.example.com Cookie Kapsamı

Bu kadar geniş kapsam gerekli değilse kullanılmamalıdır.

Tenant'lar Arasında Session Sızıntısı Riski

Geniş domain cookie yanlış tasarımda tenantlar arası oturum karışmasına sebep olabilir.

Secure

Session cookie'leri HTTPS üzerinden gönderilmelidir.

HttpOnly

JavaScript erişimi gerekmeyen session cookie'lerinde HttpOnly kullanılması önemlidir.

SameSite

Authentication akışına uygun SameSite politikası seçilmelidir.

Session'ı Tenant ID'ye Bağlamak

Sunucu tarafında session içindeki tenant kimliği aktif request tenant'ıyla karşılaştırılmalıdır.

Subdomain'ler Aynı Origin midir?

Origin Kavramı

Web origin, scheme, host ve port birleşimiyle tanımlanır.

Scheme

HTTP ve HTTPS farklı origin kabul edilir.

Host

Hostname değişirse origin değişir.

Port

Port farkı da origin ayrımı yaratabilir.

a.example.com ile b.example.com Arasındaki Origin Farkı

Bu iki adres farklı host değerlerine sahip olduğu için farklı originlerdir.

Same-Origin Policy'nin Etkisi

Tarayıcı erişim kuralları subdomainler arasında otomatik güven varsaymaz.

CORS Multi-Tenant Subdomain'lerde Nasıl Yönetilir?

Access-Control-Allow-Origin

İzin verilen origin açık biçimde belirlenmelidir.

Dinamik Origin Allowlist

Tenant registry üzerinden doğrulanan subdomain ve custom domainler dinamik allowlist'e alınabilir.

\* ile Credential Kullanımının Sorunları

Credential kullanan cross-origin isteklerde kontrolsüz wildcard yaklaşımı uygun değildir.

Tenant Domain'ini Doğrulamak

Origin değeri yalnızca string suffix kontrolüyle değil güvenilir hostname doğrulamasıyla incelenmelidir.

Custom Domain'leri Allowlist'e Eklemek

Yalnızca ownership doğrulaması tamamlanmış domainler kabul edilmelidir.

Origin Reflection Güvenlik Riski

İstemciden gelen Origin değerini kontrol etmeden response'a yansıtmak güvenlik açığı oluşturabilir.

CSRF Koruması

SameSite Cookie'lere Tek Başına Güvenmemek

Uygulamanın akışına göre ek CSRF kontrolleri gerekebilir.

CSRF Token

State-changing istekler sunucu tarafından doğrulanan token gerektirebilir.

Origin Validation

Beklenen origin listesiyle karşılaştırma yapılabilir.

Referer Validation

Uygun senaryolarda ek savunma katmanı olarak kullanılabilir.

Tenant Context ile CSRF Token'ı İlişkilendirmek

Bir tenant için üretilen token'ın başka tenant bağlamında geçerli olmaması tercih edilir.

Tenant Subdomain'i Yetkilendirme Sağlar mı?

Hayır. URL yalnızca tenant adayını bulmanıza yardım eder. Yetkilendirme ayrıca yapılmalıdır.

URL'nin Kimlik Olmaması

Kullanıcının bir subdomaini yazabilmesi o tenant'a erişme hakkı olduğu anlamına gelmez.

Kullanıcının Tenant Üyeliğini Kontrol Etmek

Her korumalı istekte üyelik ve rol bilgisi doğrulanmalıdır.

Tenant-Aware RBAC

Rol kontrolleri tenant bağlamını da içermelidir.

Cross-Tenant Authorization

Tenant A kullanıcısı Tenant B kaynaklarına erişememelidir.

IDOR / BOLA Riskleri

Kaynak ID'sini değiştirerek başka tenant verisine erişim özellikle API'lerde test edilmelidir.

DNS ile Authorization'ı Karıştırmamak

DNS çözümlemesi hiçbir zaman yetkilendirme mekanizması değildir.

Tenant Veri İzolasyonu

Shared Database + Shared Schema

Veriler ortak tabloda tutulur ve her satır tenant ID ile ilişkilendirilir.

Shared Database + Separate Schema

Tenantlar ayrı schema kullanabilir.

Database per Tenant

Yüksek izolasyon gereken müşteriler için ayrı veritabanı düşünülebilir.

Tenant ID Enforcement

Her veri erişimi tenant kimliğiyle sınırlandırılmalıdır.

Row-Level Security

Veritabanı seviyesinde tenant filtrelemesine ek güvenlik katmanı sağlar.

Defense in Depth

Uygulama filtresi, database policy ve authorization kontrolünü birlikte kullanmak tek noktaya bağımlılığı azaltır.

Tenant Context'in Veri Katmanına Taşınması

Request Scope

Tenant context request yaşam döngüsüne bağlanabilir.

ORM Global Filter

ORM sorgularına tenant koşulu otomatik eklenebilir.

Database Session Context

Tenant kimliği database session seviyesinde de taşınabilir.

Repository Layer

Repository metotları tenant context olmadan çalışmayacak şekilde tasarlanabilir.

Tenant Context Eksikse Fail-Closed Davranmak

Tenant bulunamadığında filtresiz sorgu çalıştırmak yerine işlem reddedilmelidir.

Background Job'larda Tenant Context

HTTP request dışında çalışan job'lar da tenant ID taşımalıdır.

Cache İzolasyonu

Tenant ID'siz Cache Key Kullanmanın Riski

Aynı resource ID farklı tenantlarda bulunuyorsa içerikler birbirine karışabilir.

tenant:{id}\:resource:{key}

Tenant kimliğini cache key'e dahil etmek temel bir izolasyon yaklaşımıdır.

CDN Cache Key

Hostname veya normalize edilmiş tenant kimliği cache key'in parçası olmalıdır.

Reverse Proxy Cache

Proxy cache yapılandırması tenant sınırlarını gözetmelidir.

Redis Namespace

Key prefix ile tenant bazlı mantıksal ayrım uygulanabilir.

Custom Domain ve Subdomain'in Aynı Tenant Cache'ini Kullanması

İki hostname aynı tenant'a bağlıysa içerik cache'i ortak kullanılabilir ancak canonical ve authorization kuralları korunmalıdır.

CDN Cache Poisoning ve Cross-Tenant Veri Sızıntısı

Hostname'in Cache Key'e Dahil Edilmesi

Host yoksa farklı tenantlar aynı cache nesnesine düşebilir.

Authorization Header

Kullanıcıya özel yanıtların cache davranışı authorization durumunu hesaba katmalıdır.

Cookie

Session veya kişiselleştirme cookie'leri bulunan response'lar public cache için dikkatle ele alınmalıdır.

Vary

Gerekli header farklılıkları doğru Vary politikalarıyla yönetilebilir.

Private Response'ları Cache'lememek

Kullanıcıya özel veri yanlışlıkla ortak cache'e yazılmamalıdır.

Tenant-Aware Purge

Cache temizliği yalnızca ilgili tenant kapsamını hedefleyebilmelidir.

Dosya ve Object Storage İzolasyonu

Tenant Prefix

Object key'lerde tenant ID prefix kullanılması erişim kontrolünü kolaylaştırır.

Ayrı Bucket

Yüksek izolasyon gerektiren tenantlar için ayrı bucket düşünülebilir.

Signed URL

Dosya erişimi kısa süreli imzalı URL ile sınırlandırılabilir.

Tenant-Based Authorization

Dosya isteği geldiğinde object'in tenant sahipliği doğrulanmalıdır.

CDN Path

Tenant ID veya güvenli asset key CDN yolunun parçası olabilir.

Cross-Tenant Object Access Testleri

Bir tenant'ın başka tenant object key'ini kullanarak erişim sağlayamadığı otomatik testlerle doğrulanmalıdır.

Queue ve Background Job İzolasyonu

Job Payload'a Tenant ID Eklemek

Worker hangi tenant bağlamında çalışacağını açıkça bilmelidir.

Worker'da Tenant Context Oluşturmak

Job başlamadan tenant durumu ve kimliği doğrulanmalıdır.

Tenant-Specific Queue

Yüksek hacimli veya premium müşteriler ayrı queue kullanabilir.

Shared Queue

Çoğu tenant ortak queue içinde çalışabilir.

Noisy Neighbor Problemi

Tek tenant'ın yoğun job üretmesi diğer tenantların gecikmesini artırabilir.

Tenant Context Kaybolursa Job'ı Çalıştırmamak

Tenant kimliği olmayan job fail-closed davranışıyla durdurulmalıdır.

WebSocket ve Realtime Bağlantılarda Tenant Routing

Hostname'den Tenant Çözme

WebSocket upgrade isteğinde de hostname doğrulanmalıdır.

WebSocket Authentication

Bağlantı kurulurken kullanıcı kimliği ve tenant üyeliği kontrol edilir.

Tenant-Specific Channel

Channel veya room isimleri tenant ID ile ayrılmalıdır.

Cross-Tenant Broadcast Riskleri

Global broadcast yanlış kullanılırsa bir tenant verisi diğerine gidebilir.

Sticky Session Gereksinimleri

Kullanılan realtime mimarisine göre bağlantı sürekliliği için sticky routing gerekebilir.

Wildcard DNS ve SEO

Search Engine'lerin Subdomain'leri Nasıl Algıladığı

Subdomainler ayrı web alanları gibi değerlendirmeye açık olduğundan içerik ve index stratejisi tenant bazında düşünülmelidir.

Her Tenant'ın Bağımsız İçerik Alanı Olması

Public tenant sayfaları özgün içerik sunuyorsa ayrı subdomain yapısı mantıklı olabilir.

Duplicate Content

Aynı içeriği platform subdomaini ve custom domainde göstermek çoğaltılmış URL sorununa yol açabilir.

Canonical URL

Arama motoruna tercih edilen URL açık biçimde belirtilmelidir.

Custom Domain ile Platform Subdomain'in Aynı İçeriği Sunması

İki hostname aktif kalacaksa canonical veya redirect politikası belirlenmelidir.

Canonical Domain Seçmek

Tenant'ın tercih ettiği domain primary hostname olarak registry içinde tutulabilir.

Tenant Subdomain ile Custom Domain Aynı Anda Açık Olmalı mı?

İki URL'nin Aynı İçeriği Sunması

Kullanıcı deneyimi ve SEO açısından gereksiz çift URL oluşabilir.

Canonical

İki URL açık kalıyorsa preferred domain canonical olarak gösterilebilir.

Redirect

Daha net yaklaşım, platform subdomaininden doğrulanmış custom domaine yönlendirmektir.

Tenant'ın Preferred Domain Ayarı

Registry tenant başına primary hostname tutabilir.

SEO ve Analytics Tutarlılığı

Tek preferred domain, trafik raporlarının ve arama görünürlüğünün daha düzenli ölçülmesini sağlar.

Sitemap Yönetimi

Tenant Bazlı Sitemap

Public tenant kendi sitemap dosyasını üretebilir.

Custom Domain Sitemap

Preferred domain custom domain ise sitemap URL'leri de onu kullanmalıdır.

Merkezi Sitemap Index

Platform yapısına bağlı olarak public tenant sitemap'leri merkezi index altında listelenebilir.

Robots.txt

Tenant'ın index politikası hostname bazında belirlenebilir.

Private Tenant'ların Indexlenmesini Engellemek

Private uygulama sayfalarında yalnızca robots talimatlarına güvenmek yerine authentication da zorunlu olmalıdır.

Tenant Analytics

Hostname → Tenant ID

Analytics event üretmeden önce hostname güvenilir tenant ID'ye çevrilmelidir.

Tenant Bazlı Trafik

Request ve event sayıları tenant boyutunda raporlanabilir.

Custom Domain Trafiği

Custom domain üzerinden gelen kullanım ayrıca izlenebilir.

Subdomain Trafiği

Platform hostname trafiğiyle custom domain trafiği karşılaştırılabilir.

Tenant Kimliğini Analytics Event'ine Eklemek

Dahili tenant ID kullanmak domain değişikliklerinden daha az etkilenir.

Kişisel Veri ve Gizlilik

Analytics eventlerine gereksiz kullanıcı verisi eklememek ve geçerli gizlilik kurallarına uymak önemlidir.

Observability

Loglara Tenant ID Eklemek

Bir hatanın hangi tenant'ı etkilediğini hızlı bulmayı sağlar.

Hostname

Hostname loglarda tenant ID ile birlikte tutulabilir.

Request ID

Tek isteğin servisler arası izlenmesini kolaylaştırır.

Trace ID

Dağıtık sistemlerde request zincirini takip etmeye yardımcı olur.

Tenant Bazlı Error Rate

Sorunun genel mi yoksa tek müşteriye özgü mü olduğunu gösterebilir.

Tenant Bazlı Latency

Belirli region veya routing target problemlerini tespit etmeyi kolaylaştırır.

Unknown Hostname Oranı

Bot taraması veya yanlış DNS yapılandırması için değerli bir sinyal olabilir.

Wildcard DNS İçin Güvenlik Monitoring'i

Rastgele Subdomain Taramaları

Wildcard nedeniyle çok sayıda rastgele hostname origin'e ulaşabilir.

Bot Trafiği

Rate limit ve WAF kuralları bilinmeyen host trafiğini azaltabilir.

Bilinmeyen Hostname Request'leri

Ayrı metric ve log kategorisi altında takip edilmelidir.

Host Header Saldırıları

Beklenmeyen host formatları ve yüksek hata oranları alarm sinyali olarak kullanılabilir.

Rate Limiting

IP, hostname ve tenant kombinasyonunda kontrollü limitler uygulanabilir.

WAF

Edge güvenlik kuralları bilinen saldırı kalıplarını origin'e ulaşmadan engelleyebilir.

Subdomain Takeover Nedir?

Dangling DNS Record

DNS kaydı artık sahip olmadığınız harici bir hedefe işaret ediyorsa risk oluşabilir.

Silinmiş Harici Servise İşaret Eden CNAME

Hedef isim başka biri tarafından yeniden alınabiliyorsa subdomain kötüye kullanılabilir.

Wildcard DNS ile İlişkisi

Wildcard tek başına takeover oluşturmaz. Asıl risk kontrolsüz veya sahipsiz hedeflerdir.

Custom Domain Lifecycle

Müşteri ayrıldığında hostname mapping ve sertifika kayıtları kapatılmalıdır.

Kullanılmayan DNS Kayıtlarını Temizlemek

Eski explicit kayıtlar düzenli olarak gözden geçirilmelidir.

Ownership Monitoring

Custom domain sahipliği değişmişse sistem bunu fark edebilmelidir.

Wildcard DNS Güvenlik Açığı mıdır?

Wildcard'ın Tek Başına Güvenlik Açığı Olmaması

Wildcard DNS geçerli bir altyapı tekniğidir.

Attack Surface'in Genişlemesi

Rastgele hostname'ler altyapınıza ulaşabildiği için unknown host davranışı önem kazanır.

Unknown Host Handling

Bilinmeyen tenantlar hızlı ve veri göstermeden reddedilmelidir.

Host Validation

Hostname registry ile doğrulanmalıdır.

Tenant Authorization

Doğru hostname bile kullanıcıya otomatik erişim hakkı vermez.

WAF ve Rate Limit

Edge katmanı gereksiz trafiği azaltabilir.

DNS Rebinding ve Hostname Tabanlı Güvenlik Varsayımları

DNS Sonucuna Tek Başına Güvenmemek

Bir hostname'in belirli IP'ye çözülmesi güvenilir tenant kimliği olduğu anlamına gelmez.

Host Validation

Uygulama yalnızca beklenen hostname'leri kabul etmelidir.

Origin Kontrolleri

Browser tarafındaki güven varsayımları origin seviyesinde doğrulanmalıdır.

Internal Service'lerin Public Hostname Üzerinden Açılmaması

İç servisler ayrı ağ politikaları ve erişim kontrolleriyle korunmalıdır.

SSRF Savunmaları

Uygulamanın kullanıcı tarafından verilen URL'lere istek yaptığı yerlerde private network hedefleri ayrıca engellenmelidir.

DNS TTL Nasıl Seçilmelidir?

Düşük TTL

Hedef değişikliklerinin daha hızlı görülmesini sağlar ancak DNS sorgu sayısını artırabilir.

Yüksek TTL

Cache verimliliğini artırır fakat migration ve failover değişikliklerini yavaşlatabilir.

DNS Query Maliyeti

Yüksek trafik alan sistemlerde resolver sorgu davranışı maliyete etki edebilir.

Failover Süresi

TTL, DNS tabanlı failover'ın ne kadar hızlı algılanabileceğini etkiler.

Migration Senaryoları

Büyük altyapı değişikliklerinden önce TTL geçici olarak düşürülebilir.

TTL Değişikliklerini Migration'dan Önce Planlamak

Eski yüksek TTL kaydı cache'te kaldıysa son anda yapılan değişikliğin hemen etkili olmasını beklemeyin.

DNS Propagation Gerçekte Nasıl Çalışır?

Authoritative DNS

Alan adınızın resmi DNS cevaplarını üretir.

Recursive Resolver Cache

Resolver cevapları TTL süresince önbellekte tutabilir.

TTL

Kaydın ne kadar süre cache'lenebileceğini tanımlar.

Negative Caching

Olmayan kayıtlar da belirli süre önbelleğe alınabilir.

NXDOMAIN Cache

Custom domain kurulmadan önce yapılan başarısız sorgu sonradan oluşturulan kaydın görülmesini geciktirebilir.

Tenant Custom Domain Onboarding'ine Etkisi

Kullanıcıya DNS doğrulamasının hemen tamamlanmayabileceği açık biçimde gösterilmelidir.

Yüksek Erişilebilir Wildcard DNS Mimarisi

Managed Authoritative DNS

Yüksek erişilebilir DNS servisi tek fiziksel noktaya bağımlılığı azaltır.

Birden Fazla Edge / Load Balancer

Trafik birden fazla sağlıklı giriş noktasına dağıtılabilir.

Health-Based Routing

Sağlık durumuna göre DNS veya edge routing politikaları uygulanabilir.

Regional Routing

Kullanıcı veya tenant bölgesine uygun edge seçilebilir.

Failover

Origin arızasında alternatif backend hedefi devreye alınabilir.

DNS'in Tek Başına Anlık Failover Sağlamamasının Nedenleri

Recursive cache ve TTL nedeniyle DNS değişikliği tüm kullanıcılar için aynı anda görülmeyebilir.

Multi-Region Tenant Routing

Tenant'ın Home Region Bilgisi

Tenant registry hangi region'ın temel veri bölgesi olduğunu tutabilir.

Hostname → Tenant → Region Mapping

Hostname önce tenant'a, tenant da region'a çevrilir.

Edge'de Region Resolution

Bu mapping edge'e taşındığında trafik origin'e ulaşmadan bölgesel seçim yapılabilir.

Geo Routing

Kullanıcı lokasyonuna göre routing yapılabilir ancak data residency kurallarıyla çelişmemelidir.

Data Residency

Kurumsal müşteriler verilerinin belirli coğrafi bölgede kalmasını isteyebilir.

Cross-Region Failover

Failover politikası veri tutarlılığı ve mevzuat şartları hesaba katılarak tasarlanmalıdır.

Enterprise Tenant'ı Ayrı Altyapıya Taşımak

Aynı Subdomain'i Korumak

Kullanıcının URL'si değişmek zorunda değildir.

Tenant Registry'deki Origin'i Değiştirmek

Routing target yeni cluster adresine güncellenebilir.

Shared Cluster → Dedicated Cluster

Kurumsal tenant ortak sistemden ayrılmış altyapıya taşınabilir.

DNS Değişikliği Yapmadan Routing Değiştirmek

Wildcard DNS ortak edge'e işaret ediyorsa değişiklik routing katmanında yapılabilir.

Premium Tenant Isolation

Bu model yüksek güvenlik veya performans beklentisi olan tenantlara ayrı kaynak vermeyi kolaylaştırır.

Wildcard DNS'in Ölçeklenebilirlik Avantajı

10 Tenant

Manuel DNS yönetimi mümkün görünebilir.

1.000 Tenant

Tenant başına kayıt modeli operasyonel yük oluşturmaya başlar.

100.000 Tenant

Wildcard yaklaşımı DNS kaydı sayısını tenant sayısından büyük ölçüde bağımsız hale getirir.

Tenant Başına DNS Record Yönetiminin Ortadan Kalkması

Onboarding sürecindeki DNS API çağrıları ve propagation beklemeleri azalır.

Routing Kararının Uygulama veya Edge Katmanına Taşınması

Asıl kontrol tenant registry ve routing servislerine geçer.

Wildcard DNS'in Dezavantajları

Unknown Hostname'lerin Origin'e Ulaşması

Hostname validation zorunlu hale gelir.

Merkezi Sertifika Blast Radius

Tek wildcard private key çok sayıda tenantı etkileyebilir.

Authentication Karmaşıklığı

Subdomainler login, callback ve session tasarımında ek kararlar gerektirir.

Cookie ve CORS Karmaşıklığı

Tarayıcı güvenlik sınırları doğru anlaşılmazsa tenantlar arası veri sızıntısı riski doğabilir.

Custom Domain'lerin Ayrı Yönetilmesi

Platform wildcard kaydı müşteriye ait domainleri çözmez.

Debugging Zorlukları

DNS, TLS, edge, proxy ve application katmanlarının her biri ayrı hata noktası olabilir.

Subdomain mi Path mi?

DNS Karmaşıklığı

Path modeli DNS açısından daha basittir. Subdomain modeli wildcard DNS veya tenant kayıtları gerektirir.

TLS

Subdomain modelinde wildcard veya hostname sertifika stratejisi gerekir.

White-Labeling

Subdomain yaklaşımı custom domain modeline daha doğal geçiş sunar.

Authentication

Subdomain yapısı merkezi auth domaini ve callback tasarımını gündeme getirir.

Cookie Yönetimi

Path modelinde tek host nedeniyle cookie yönetimi daha sade olabilir.

SEO

Public tenant içerikleri için subdomain ve path seçeneklerinin index etkisi ayrı değerlendirilmelidir.

Local Development

Subdomain modeli local DNS ve HTTPS kurulumunda ek çalışma gerektirebilir.

Custom Domain'e Geçiş

Hostname tabanlı tenant resolution kullanan sistemlerde custom domain eklemek daha doğal olabilir.

Karar Matrisi

B2B white-label SaaS için subdomain güçlü bir tercihken, basit yönetim paneli uygulamalarında path yeterli olabilir.

Local Development'ta Wildcard Subdomain

localhost Alt Alanları

Modern geliştirme ortamlarında tenant.localhost benzeri hostlar test edilebilir.

/etc/hosts Sınırlamaları

Hosts dosyası gerçek wildcard kayıtları için uygun değildir ve her isim ayrı tanımlanabilir.

Local DNS Resolver

Wildcard geliştirme domainleri için yerel resolver kurulabilir.

\*.localhost

Framework ve tarayıcı davranışı kontrol edilerek tenant resolution testlerinde kullanılabilir.

Local Reverse Proxy

Production benzeri host routing yerel proxy üzerinden simüle edilebilir.

Local HTTPS

Cookie ve secure context problemlerini erken görmek için yerel HTTPS ortamı faydalıdır.

Production ile Aynı Tenant Resolution Kodunu Test Etmek

Development ortamının hostname parse davranışı production ile mümkün olduğunca aynı olmalıdır.

Preview ve Staging Ortamlarında Tenant Domainleri

tenant.staging.example.com

Staging tenantları production domaininden ayrı tutulabilir.

Ayrı Wildcard Certificate

Staging wildcard sertifikası production private key'inden bağımsız tutulmalıdır.

Production Tenant Registry'yi Kopyalamamak

Gerçek müşteri hostnamelerini test ortamına taşımak yanlış trafik ve veri riski yaratabilir.

Test Tenant'ları

Staging için özel tenant kayıtları oluşturun.

Ortamlar Arasında Cookie İzolasyonu

Domain ve cookie kapsamlarının production ile staging arasında çakışmaması gerekir.

CI/CD İçinde DNS ve TLS Testleri

Wildcard DNS Resolution Testi

Test hostname'inin doğru edge hedefine çözüldüğü doğrulanabilir.

Certificate SAN Testi

Sertifika kapsamındaki hostname'ler otomatik kontrol edilebilir.

Certificate Expiration Testi

Sertifikanın kalan geçerlilik süresi deployment veya monitoring aşamasında ölçülebilir.

Unknown Tenant Testi

Rastgele hostname'in hiçbir tenant verisi göstermediği test edilmelidir.

Known Tenant Testi

Geçerli hostname'in doğru tenant ID'ye çözüldüğü doğrulanmalıdır.

Custom Domain Testi

Ownership, TLS ve tenant mapping zinciri otomatik test edilebilir.

Host Header Security Testi

Manipüle edilmiş host değerlerinin reddedildiği test edilmelidir.

Wildcard Sertifika Renewal Monitoring

Expiration Metric

Kalan sertifika süresi metric olarak izlenebilir.

Renewal Failure Alert

Yenileme başarısız olduğunda ekip otomatik uyarı almalıdır.

DNS-01 Failure

Challenge kaydının oluşturulamaması ayrı hata nedeni olarak görünmelidir.

DNS Provider API Failure

Credential veya API erişim sorunları izlenmelidir.

Certificate Deployment Failure

Yeni sertifika üretildiği halde edge'e yüklenememesi ayrıca yakalanmalıdır.

Sertifika Süresi Dolmadan Alarm

Alarm eşiği son güne bırakılmamalıdır.

DNS Configuration as Code

Terraform

DNS kayıtları deklaratif altyapı tanımlarında yönetilebilir.

Pulumi

Programlama dili tabanlı infrastructure as code yaklaşımı kullanılabilir.

DNS Zone'u Versiyonlamak

Değişikliklerin geçmişi kaynak kontrol sisteminde tutulabilir.

Pull Request Review

DNS değişiklikleri production'a gitmeden ekip kontrolünden geçebilir.

Drift Detection

Manuel değişikliklerin beklenen yapılandırmadan sapması tespit edilebilir.

Manuel DNS Değişikliklerini Azaltmak

Kurallar kodlaştıkça yanlış kayıt oluşturma ihtimali azalır.

Tenant Routing Configuration as Code

Hostname Registry

Tenant hostname kayıtları kontrollü veri modeliyle yönetilebilir.

Edge Routing Rules

Routing politikaları sürümlenebilir konfigürasyondan üretilebilir.

Reverse Proxy Config

Proxy kuralları deployment pipeline içinde doğrulanabilir.

Policy Validation

Reserved hostname veya hatalı origin gibi durumlar production öncesinde yakalanabilir.

Deployment Öncesi Test

Routing değişiklikleri staging ortamında bilinen tenant senaryolarıyla sınanmalıdır.

Rollback

Hatalı routing güncellemesi hızlı biçimde önceki sürüme döndürülebilmelidir.

Wildcard DNS Mimarisi İçin Test Senaryoları

Geçerli Tenant

Doğru tenant context ve doğru içerik dönmelidir.

Geçersiz Tenant

404, 421 veya tanımlanan güvenli yanıt dönmelidir.

Suspended Tenant

Uygulama veriye erişimi kapatmalı ve kontrollü durum sayfası gösterebilir.

Silinmiş Tenant

Eski tenant verisi hiçbir şekilde sunulmamalıdır.

Reserved Subdomain

Sistem hostname'i tenant resolution'a düşmemelidir.

Apex Domain

Platform ana domaininin routing davranışı ayrı test edilmelidir.

Çok Seviyeli Subdomain

Beklenmiyorsa reddedilmeli, TLS kapsamı da ayrıca doğrulanmalıdır.

Custom Domain

Doğru tenant mapping ve sertifika kontrol edilmelidir.

Sertifikası Bekleyen Domain

Trafik hazır olmayan domain üzerinden aktif tenant içeriğine açılmamalıdır.

Cross-Tenant Security Testleri

Tenant A Kullanıcısıyla Tenant B Subdomain'ine Gitmek

Yetki kontrolü erişimi engellemelidir.

Tenant ID Manipülasyonu

Request parametresindeki tenant ID değiştirilerek başka müşteriye erişilememelidir.

Host Header Değiştirme

Manipüle edilmiş hostname tenant context'i yanlış oluşturmamalıdır.

Cache Poisoning

Bir tenant response'u başka tenant cache'inde görünmemelidir.

Cookie Sharing

Session cookie kapsamları tenantlar arası beklenmeyen erişime yol açmamalıdır.

CORS Bypass

Yetkisiz origin dinamik allowlist'i geçememelidir.

Object ID Manipülasyonu

Başka tenant'a ait kaynak ID'si kullanıldığında erişim reddedilmelidir.

Gerçek Dünya Örneği: B2B SaaS

Ana Domain

example.com

Kurumsal site veya ürün tanıtım alanı olarak kullanılabilir.

Authentication

auth.example.com

Merkezi login ve callback akışları burada çalışabilir.

Tenant A

acme.example.com

Acme tenant'ı ortak uygulamaya bağlanır.

Tenant B

globex.example.com

Globex aynı uygulamayı kullanır ancak ayrı tenant context ile çalışır.

Wildcard DNS

\*.example.com

Tenant subdomain trafiğini ortak giriş noktasına taşır.

CDN / WAF

TLS, rate limit ve hostname filtreleri ilk katmanda uygulanır.

Reverse Proxy

İstek doğru application cluster'a aktarılır.

Tenant Resolver

Hostname tenant ID'ye çevrilir.

Tenant Registry

Slug, status, region ve routing metadata burada tutulur.

Shared Application

Tenantlar aynı kod tabanı üzerinden hizmet alır.

Tenant-Aware Database

Her sorgu tenant ID sınırıyla çalışır.

Backend tarafında NestJS ve TypeScript kullanılan kurumsal uygulamalarda request scope, guard ve middleware gibi yapıların tenant context taşımada nasıl değerlendirilebileceğine ilişkin ek okuma için https://www.diyarbakiryazilim.com.tr/posts/kurumsal-projelerde-nest-js-ve-typescript-kullaniminin-avantajlari adresindeki içeriği inceleyebilirsiniz.

Gerçek Dünya Örneği: White-Label SaaS + Custom Domain

Platform Subdomain

acme.platform.com

Tenant ilk günden platform hostname'i üzerinden çalışabilir.

Customer Domain

portal.acme.com

Müşteri daha sonra kendi domainini bağlayabilir.

Domain Verification

TXT veya CNAME kaydıyla ownership doğrulanır.

Certificate Provisioning

Doğrulamanın ardından ilgili hostname için TLS sertifikası oluşturulur.

Preferred Domain

Tenant custom domaini primary hostname olarak seçebilir.

Canonical Redirect

Platform subdomaini custom domaine yönlendirilebilir.

Aynı Tenant ID'ye İki Hostname Mapping

İki hostname registry üzerinde aynı tenant ID'ye bağlanabilir ancak preferred domain politikası açık olmalıdır.

Gerçek Dünya Örneği: Enterprise Tenant'ı Dedicated Cluster'a Taşımak

Başlangıçta Shared Cluster

Tenant başlangıçta standart SaaS altyapısını kullanır.

Tenant Routing Registry

Hostname ve tenant ID ortak routing target'a bağlıdır.

Enterprise Tenant İçin Yeni Origin

Yeni dedicated cluster hazırlanır.

Routing Target Güncelleme

Tenant registry yeni origin değerine geçirilir.

DNS Değişmeden Geçiş

Wildcard DNS aynı edge'e işaret ettiği için müşteri tarafında DNS değişikliği gerekmez.

Rollback

Sorun yaşanırsa routing target eski cluster'a geri döndürülebilir.

Multi-Tenant Wildcard DNS Maliyetleri

DNS Query Maliyeti

DNS sorgu hacmi ve sağlayıcı fiyatlandırması izlenmelidir.

CDN

Edge request, bandwidth ve WAF özellikleri maliyete eklenebilir.

TLS Sertifika Yönetimi

Wildcard sertifikanın otomasyonu operasyon maliyetini düşürür.

Custom Domain Sertifikaları

Tenant sayısı ve custom domain kullanım oranı arttıkça certificate lifecycle yönetimi daha önemli hale gelir.

Edge Routing

KV lookup, edge function ve request hesaplama ücretleri değerlendirilebilir.

Observability

Tenant bazlı log ve trace hacmi büyüyebilir.

Tenant Başına DNS Record Modeliyle Karşılaştırma

Wildcard modeli çoğu SaaS sisteminde tenant başına kayıt yönetimini azaltarak operasyon tarafında belirgin avantaj sağlar.

Wildcard DNS Kullanımında Sık Yapılan Hatalar

Wildcard DNS'i Tenant Registry Sanmak

DNS cevabı tenant'ın varlığını doğrulamaz.

Her Hostname'i Geçerli Tenant Kabul Etmek

Hostname mutlaka registry lookup işleminden geçmelidir.

Wildcard DNS ile Wildcard TLS'i Aynı Şey Sanmak

İki yapı farklı katmanlarda çalışır.

Apex Domain'in Wildcard Sertifikaya Dahil Olduğunu Sanmak

*.example.com tek başına example.com adresini kapsamaz.

Çok Seviyeli Subdomain'lerin Wildcard Sertifikayla Korunduğunu Sanmak

app.acme.example.com için ayrı kapsam gerekir.

Host Header'ı Doğrulamadan Kullanmak

Tenant resolution ve absolute URL üretiminde güvenlik problemi doğurabilir.

Cookie'leri Tüm Subdomain'lere Gereksiz Açmak

Session sınırlarını gereksiz genişletir.

Cache Key'e Tenant Kimliğini Eklememek

Cross-tenant veri sızıntısına yol açabilir.

OAuth Redirect URI'larda Wildcard'a Güvenmek

Merkezi ve exact callback yaklaşımı genellikle daha güvenlidir.

Custom Domain Ownership Doğrulaması Yapmamak

Domainin yanlış tenant'a bağlanmasına neden olabilir.

Bilinmeyen Tenant'ı Default Tenant'a Yönlendirmek

Fail-closed davranış yerine veri sızıntısına açık bir varsayım oluşturur.

Production İçin Wildcard DNS Kontrol Listesi

Wildcard DNS Kaydı Oluşturuldu mu?

Tenant subdomainlerinin ortak giriş noktasına çözüldüğünü test edin.

Apex Domain Ayrı Yapılandırıldı mı?

Apex routing ve TLS kapsamı ayrı kontrol edilmelidir.

Reserved Subdomain'ler Belirlendi mi?

Sistem hostname'lerini slug tahsisinden çıkarın.

Wildcard TLS Sertifikası Doğru Kapsama Sahip mi?

Tek seviyeli hostname ve apex kapsamlarını doğrulayın.

Otomatik Renewal Var mı?

Sertifika yenileme sürecini manuel operasyona bırakmayın.

Tenant Registry Var mı?

DNS'ten bağımsız güvenilir tenant kaynağı bulunmalıdır.

Unknown Hostname Reddediliyor mu?

Rastgele hostname'lerde tenant verisi dönmemelidir.

Host Validation Uygulanıyor mu?

Proxy ve uygulama seviyesinde doğrulama kullanın.

Tenant Context Veri Katmanına Taşınıyor mu?

Her sorgunun tenant sınırı olduğundan emin olun.

Cache Tenant-Aware mı?

Cache key tasarımını tenant ID ve hostname açısından kontrol edin.

Session Tenant'a Bağlı mı?

Session içindeki tenant üyeliği request tenant'ıyla doğrulanmalıdır.

Custom Domain Ownership Doğrulanıyor mu?

Doğrulanmamış domaini aktif etmeyin.

Cross-Tenant Güvenlik Testleri Var mı?

Tenant A kimliğiyle Tenant B kaynaklarına erişim denemelerini otomatik test paketine ekleyin.

Open Source ile Wildcard DNS ve Multi-Tenant Mimarisi Öğrenmek

Nginx

Hostname routing ve reverse proxy davranışını öğrenmek için iyi bir çalışma alanıdır.

Caddy

TLS otomasyonu ve host tabanlı proxy davranışını gözlemlemek için kullanılabilir.

Traefik

Dinamik container routing yapılarını anlamaya yardımcı olur.

Kubernetes Gateway API

Modern cluster routing kavramlarını incelemek için değerlidir.

Let's Encrypt ve ACME

DNS-01, sertifika issuance ve renewal sürecini pratik etmek için temel konulardandır.

Açık Kaynak Multi-Tenancy Projelerini İncelemek

Gerçek kod üzerinde tenant context'in nasıl taşındığını görmek teoriyi daha anlaşılır hale getirir.

Open Source ve İşbirliği ile Tenant Routing Yetkinliği Kazanmak

Kendi küçük SaaS projenizi geliştirip açık kaynak katkılarıyla routing, authentication ve isolation kararlarını test etmek çok güçlü bir öğrenme yöntemidir.

Diyarbakır Yazılım Topluluğu tarafından geliştirilen veya paylaşılan proje çalışmalarını görmek isterseniz https://www.diyarbakiryazilim.com.tr/projects adresine göz atabilirsiniz.

Multi-Tenant Sistem Geliştirmek İçin Hangi Konuları Öğrenmek Gerekir?

DNS Temelleri

A, AAAA, CNAME, TXT, TTL ve authoritative DNS mantığını anlayın.

HTTP ve TLS

Host, origin, headers, HTTPS ve sertifika kapsamı temel konulardır.

Reverse Proxy

Request'in edge'den uygulamaya nasıl taşındığını öğrenin.

Authentication ve Authorization

Kullanıcı kimliği ile tenant üyeliğinin farklı kavramlar olduğunu kavrayın.

Database Isolation

Tenant ID enforcement ve row-level güvenlik yöntemlerini öğrenin.

Cache

Tenant-aware cache key tasarımı cross-tenant güvenlik açısından kritiktir.

Cloud ve Containers

Routing, deployment ve ölçekleme kararlarını anlamayı kolaylaştırır.

Observability

Log, metric ve trace sistemlerinde tenant kimliği taşıyabilmelisiniz.

Web Security

CORS, CSRF, host injection, SSRF, IDOR ve session güvenliği multi-tenant ürünlerde özellikle önemlidir.

Sık Sorulan Sorular

Wildcard DNS Nedir?

Wildcard DNS, açıkça tanımlanmayan belirli alt alan adlarını ortak DNS hedefiyle eşleştiren kayıttır.

Multi-Tenant Sistemlerde Wildcard DNS Neden Kullanılır?

Tenant başına ayrı DNS kaydı oluşturmadan dinamik subdomain kullanımını mümkün kıldığı için tercih edilir.

\*.example.com Kaydı Ne İşe Yarar?

Uygun explicit kayıt bulunmadığında eşleşen tek seviyeli alt alan adlarını belirlenen DNS hedefine çözer.

Her Tenant İçin Ayrı DNS Kaydı Gerekir mi?

Platform subdomainlerinde wildcard DNS kullanıyorsanız genellikle gerekmez. Tenant registry kaydı yeterli olabilir.

Wildcard DNS ile Wildcard SSL Aynı Şey midir?

Hayır. Wildcard DNS isim çözümleme, wildcard TLS sertifikası ise HTTPS kimlik doğrulaması içindir.

\*.example.com Sertifikası example.com Alanını Kapsar mı?

Hayır. Apex domain sertifikaya ayrıca eklenmelidir.

Wildcard Sertifika Çok Seviyeli Subdomain'leri Kapsar mı?

Tek wildcard seviyesi app.acme.example.com gibi daha derin hostname'leri kapsamaz.

Let's Encrypt ile Wildcard Sertifika Nasıl Alınır?

ACME istemcisi ve DNS-01 challenge kullanılarak domain ownership doğrulanır, ardından wildcard sertifika oluşturulur.

Wildcard Sertifika İçin DNS-01 Zorunlu mudur?

ACME tabanlı wildcard issuance sürecinde DNS-01 kullanılır.

Nginx Wildcard Subdomain'leri Nasıl Yönlendirir?

Wildcard server name ile gelen hostları karşılayabilir, ardından proxy kurallarıyla backend'e yönlendirebilir.

Tenant Hostname'den Nasıl Tespit Edilir?

Hostname normalize edilir, root domain doğrulanır ve tenant slug veya exact hostname tenant registry üzerinde aranır.

Bilinmeyen Bir Subdomain Açılırsa Ne Olmalıdır?

Tenant bulunamazsa 404, 421 veya güvenli bir bilgilendirme sayfası dönmelidir. Default tenant gösterilmemelidir.

Tenant Başına Custom Domain Verilebilir mi?

Evet. Ownership verification, TLS provisioning ve hostname mapping süreçleri doğru tasarlanırsa her tenant kendi domainini kullanabilir.

Wildcard DNS SEO'yu Etkiler mi?

DNS kaydının kendisinden çok subdomain içerik yapısı, canonical URL, redirect ve index politikaları SEO açısından önemlidir.

Tenant Başına Subdomain mi Path mi Daha İyidir?

White-label ve custom domain hedefleyen B2B SaaS sistemlerinde subdomain genellikle daha esnektir. Daha basit ürünlerde path modeli yeterli olabilir.

Wildcard Subdomain'lerde OAuth Nasıl Yönetilir?

Tenant başına wildcard callback yerine merkezi callback endpoint ve güvenilir state tabanlı tenant context yaklaşımı tercih edilebilir.

Wildcard DNS Güvenlik Açığı Oluşturur mu?

Tek başına oluşturmaz. Risk, bilinmeyen hostname'leri doğrulamadan kabul etmek ve tenant authorization kontrollerini eksik bırakmaktır.

Multi-Tenant Sistemler İçin En İyi Programlama Dili Hangisidir?

Tek bir doğru dil yoktur. Tenant context, authorization, database isolation ve observability prensiplerini doğru uygulayabildiğiniz teknoloji daha önemlidir.

Yazılımcı Olmak İçin DNS ve Multi-Tenancy Ne Zaman Öğrenilmelidir?

HTTP ve backend temelleri oturduktan sonra DNS ve multi-tenancy çalışmak oldukça faydalıdır. Özellikle SaaS geliştirmek isteyenler bu konuları erken öğrenmelidir.

Open Source ve İşbirliği Multi-Tenant Mimari Yetkinliğini Nasıl Geliştirir?

Gerçek projelerde routing kararlarını, tenant veri modelini ve güvenlik kontrollerini inceleyerek teorik bilgiyi üretim yaklaşımına dönüştürmenize yardımcı olur.

Diyarbakır Yazılım Topluluğu Gibi Yerel Topluluklarda DNS ve SaaS Mimarisi Nasıl Pratik Edilebilir?

Küçük bir demo SaaS geliştirip wildcard subdomain, tenant registry, authentication ve database isolation katmanlarını birlikte kurabilirsiniz. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz.

Sonuç: Wildcard DNS Yalnızca Trafiği Yönlendirir, Tenant İzolasyonunu Uygulama Sağlar

Multi-Tenant (Çoklu Kiracı) Sistemlerde Wildcard DNS Yönlendirmeleri, SaaS tenant onboarding sürecini ciddi biçimde sadeleştirebilir. Ancak güçlü bir mimari yalnızca *.example.com kaydı eklemekten oluşmaz. DNS, TLS, tenant registry, authentication, authorization, cache ve veri erişimi birlikte tasarlanmalıdır.

DNS ile Tenant Kimliğini Birbirinden Ayırın

DNS hostname'i origin'e ulaştırır. Tenant'ın gerçekten var olup olmadığını registry belirler.

Wildcard DNS ve Wildcard TLS Kapsamlarını Karıştırmayın

DNS çözümlemesi ile sertifika kapsamı birbirinden bağımsızdır.

Hostname'i Mutlaka Tenant Registry ile Doğrulayın

Wildcard nedeniyle gelen rastgele hostları aktif tenant olarak kabul etmeyin.

Tenant Context'i Veri, Cache, Queue ve Session Katmanlarına Taşıyın

Gerçek izolasyon routing noktasında bitmez. Tenant ID uygulamanın tüm veri ve işlem katmanlarında korunmalıdır.

Authentication Akışlarını Subdomain Mimarisiyle Birlikte Tasarlayın

Cookie kapsamı, OAuth callback, tenant membership ve redirect kontrollerini aynı mimari kararın parçaları olarak değerlendirin.

Custom Domain'i Ayrı Bir Domain Lifecycle Problemi Olarak Ele Alın

Ownership verification, sertifika provisioning, primary hostname ve domain kaldırma işlemlerinin her biri ayrı state gerektirir.

DNS, TLS ve Routing Otomasyonunu Tenant Onboarding'in Bir Parçası Yapın

İyi tasarlanmış SaaS altyapısında yeni tenant oluşturmak DNS panelinde manuel işlem başlatmaz. Registry, routing ve gerekli sertifika süreçleri kontrollü otomasyonla ilerler.

Kurumsal multi-tenant DNS ve SaaS altyapı entegrasyon hizmeti veya wildcard DNS ve SaaS altyapı danışmanlığı yakınımda şeklinde araştırma yapıyorsanız, yalnızca DNS kaydına değil tenant izolasyonu, authentication, custom domain, TLS ve gözlemlenebilirlik katmanlarının birlikte ele alındığı bir yaklaşım arayın. Multi-Tenant (Çoklu Kiracı) Sistemlerde Wildcard DNS Yönlendirmeleri konusunda bilgi paylaşımı, teknik topluluk çalışmaları ve proje geliştirme süreçleri için Diyarbakır Yazılım Topluluğu'nu https://www.diyarbakiryazilim.com.tr adresinden ziyaret edebilirsiniz.

Multi-Tenant Sistemlerde Wildcard DNS Hakkında Ek Sorular

Multi-Tenant sistemlerde Wildcard DNS nedir ve kiracı bazlı alt alan adı yönlendirmesi nasıl çalışır?

Wildcard DNS, tenant adına göre ayrı kayıt açmadan çok sayıda subdomaini ortak edge veya reverse proxy hedefine yönlendirir. İstek geldiğinde hostname uygulama tarafından tenant registry ile eşleştirilir ve doğru tenant context oluşturulur.

Wildcard DNS kaydı ile her kiracı için dinamik subdomain nasıl oluşturulur?

*.example.com benzeri wildcard kayıt bir kez tanımlanır. Yeni tenant oluşturulduğunda yalnızca benzersiz slug ve hostname tenant registry içine eklenir. Böylece yeni DNS kaydı açmadan tenant.example.com kullanılabilir.

Multi-Tenant uygulamalarda Wildcard DNS ile SSL/TLS sertifikaları nasıl yönetilir?

Platformun tek seviyeli subdomainleri için wildcard TLS sertifikası kullanılabilir. Sertifika ACME ve DNS-01 ile otomatik yenilenebilir. Müşteriye ait custom domainler ise ayrıca doğrulanmalı ve kendi hostname sertifikalarıyla yönetilmelidir.

Wildcard DNS kullanırken tenant izolasyonu, güvenlik ve özel domain yönlendirmeleri nasıl sağlanır?

Hostname tenant registry ile doğrulanmalı, kullanıcı üyeliği sunucu tarafında kontrol edilmeli ve tenant ID database, cache, session, queue ve storage katmanlarına taşınmalıdır. Custom domainler yalnızca ownership doğrulaması ve TLS hazırlığı tamamlandıktan sonra aktif edilmelidir.

Yakınımda Multi-Tenant sistemler ve Wildcard DNS yönlendirmeleri konusunda danışmanlık veren yazılım firması nasıl bulabilirim?

Değerlendirme yaparken yalnızca wildcard DNS kurulumunu değil SaaS tenant isolation, custom domain lifecycle, TLS otomasyonu, reverse proxy, authentication ve cross-tenant güvenlik testlerini birlikte ele alan teknik yaklaşımı arayın. Diyarbakır'da yazılım ekosistemi, ortak çalışma ve teknik paylaşım hakkında bilgi almak için Diyarbakır Yazılım Topluluğu'na https://www.diyarbakiryazilim.com.tr üzerinden ulaşabilirsiniz.