API ve Mikroservisler için Subdomain Yapılandırması
Microservice mimarisine geçen takımlar için subdomain yapısı kısa sürede zorunlu bir tercih hâline gelir: api.orneksite.com, auth.orneksite.com, static.orneksite.com, ws.orneksite.com. Her biri alt domain kararıdır. Her servis kendi adresini ister, kendi sertifikasını gerektirir ve ana domain ile arasındaki ilişkiyi net biçimde tanımlamak şarttır. Tek sunucuda path tabanlı yönlendirme (/api, /auth) yerine subdomain kullanmak, izolasyon, bağımsız ölçekleme ve sorumluluk netliği açısından avantaj taşır.
Her subdomain yalnızca bir DNS kaydından ibaret değildir. SSL sertifikasının kapsamı, CORS politikası ve cookie domain ayarları ayrı ayrı ele alınmadan kurulan mimari, geliştirme ortamında çalışır görünür; üretimde sessizce kırılır. Sertifika tarafında yetkili CA listesi CAA kaydıyla kısıtlanır. Bu kırılmalar çoğunlukla tarayıcı konsolunda belirir, kök neden ise genellikle DNS veya sertifika tarafındadır.
Aşağıdaki başlıklarda microservice subdomain yapılandırmasının DNS, SSL ve CORS boyutlarını somut kayıt örnekleriyle inceliyoruz. Her başlık, hangi durumda hangi yaklaşımın işe yaradığını gösteriyor; genel geçer önerilerin ötesine geçiyor.
Subdomain Mimarisine Karar Verirken
Subdomain sayısı artıkça yönetim yükü de artar. api.orneksite.com/v1/, api.orneksite.com/auth/ şeklinde path ile çözmek teknik olarak mümkündür; yanlış da değildir. Subdomain tercihini haklı kılan durumlar belirgindir: servisler farklı sunucularda veya farklı bulut sağlayıcılarda çalışıyor; CDN kuralları servis bazında ayrışıyor; güvenlik sınırları servis düzeyinde çizilmek isteniyor; farklı ekipler farklı servislerin DNS ve SSL yönetimini bağımsız yürütüyor.
Tek sunucuda çalışan küçük bir monolitin path'lerini ayrı subdomain'e taşımak ise çoğu durumda gereksizdir. Ekstra DNS kaydı, ekstra sertifika ve ekstra CORS kuralı getirir; net bir kazanım sağlamaz. Küçük projelerde subdomain karar sürecini atlayıp path mimarisinde kalmak daha az bakım gerektirir.
Karar verildikten sonra subdomain adlandırması tutarlı olmalıdır. api., auth., static. gibi kısa ve işlevsel isimler tercih edilir. api-prod., api-v2. gibi ortam veya versiyon bilgisini subdomain'e taşımak, DNS yönetimini gereksiz yere karmaşıklaştırır; bu tür ayrımlar için path veya başlık tabanlı versiyonlama daha sürdürülebilirdir.
DNS Kayıtları: A, CNAME ve TTL Tercihleriniz
Her subdomain için iki temel seçenek vardır: A kaydı veya CNAME kaydı. A kaydı, subdomain'i doğrudan bir IP adresine bağlar. Sunucu IP'si değişmeyecekse ve ara katman yoksa tercih edilir; TTL değişim penceresini belirler ve çözümleme tek adımda tamamlanır. CNAME kaydı ise subdomain'i başka bir hostname'e yönlendirir; sarkan kayıt takeover riskini açar. Yük dengeleyici veya bulut sağlayıcısı kendi IP'sini yönetiyorsa siz yalnızca CNAME'i güncel tutarsınız, IP değişimlerini takip etmeniz gerekmez.
; api subdomaini için A kaydı
api 300 IN A 203.0.113.10
; auth subdomaini için CNAME (yük dengeleyici üzerinden)
auth 300 IN CNAME auth-lb.orneksite.internal.
; static subdomaini için CDN CNAME
static 3600 IN CNAME xxxxxx.cdnprovider.example.
TTL seçimi bu noktada kritiktir. Aktif geliştirme sürecinde veya yakın zamanda değişiklik planlandığında 300 saniye makuldür; propagasyon süresini kısaltır. Kararlı üretim ortamında static. gibi az değişen servisler için 3600 saniye veya daha uzun TTL, DNS çözümleme yükünü düşürür. static. subdomaininin TTL'ini düşük tutmak genellikle gereksizdir: CDN içeriği cache'ler, kaynak değiştiğinde DNS kaydına dokunmanız gerekmez.
CNAME kullanırken bir sınıra dikkat etmek gerekir: zone apex (örneğin orneksite.com) için CNAME kullanılamaz. Apex için A kaydı veya destekleyen sağlayıcılarda ALIAS/ANAME kaydı gerekir. Subdomain'lerde bu kısıtlama geçerli değildir.
Wildcard Sertifika mı, SAN Sertifika mı?
Subdomain sayısı ikiden fazlaya çıkınca sertifika yönetimi ağırlaşır. İki yaygın çözüm bulunur ve ikisinin de belirgin farklılıkları vardır.
Wildcard sertifika (*.orneksite.com), aynı seviyedeki tüm subdomain'leri kapsar: api., auth., static., ws. hepsi tek sertifikaya girer. Let's Encrypt ile wildcard almak için DNS-01 challenge gerekir; HTTP-01 challenge wildcard desteklemez. Bu, DNS sağlayıcınızın API erişimine sahip olmanızı ya da elle TXT kaydı eklemenizi zorunlu kılar. Wildcard tek seviyeyi kapsar: api.orneksite.com kapsanır, v2.api.orneksite.com kapsanmaz.
SAN (Subject Alternative Name) sertifikası ise her subdomain'i açıkça listeler: api.orneksite.com, auth.orneksite.com, static.orneksite.com. Yeni subdomain eklendiğinde sertifikayı yeniden oluşturmanız gerekir. Az sayıda ve kararlı subdomain varsa bu yaklaşım daha net denetim sağlar; hangi subdomain'lerin kapsandığı sertifikada açıkça görülür.
Let's Encrypt ile wildcard sertifika almak için certbot certonly --manual --preferred-challenges dns -d "*.orneksite.com" komutunu kullanabilirsiniz. DNS-01 challenge, sertifika otoritesinin belirttiği TXT değerini _acme-challenge.orneksite.com kaydına eklemenizi gerektirir. Bu değer doğrulandıktan sonra sertifika üretilir. Otomatik yenileme için DNS sağlayıcınızın API desteği olmalıdır.
cert-manager (Kubernetes) veya Caddy gibi sertifika otomasyon araçları kullananlar için wildcard sertifika tercih edilebilir; yeni subdomain eklenince sertifikayı elle güncelleme gerekliliği ortadan kalkar. Elle yönetilen ortamlarda SAN listesi daha şeffaf bir kayıt tutar.
CORS Yapılandırması: Subdomain'ler Arası İstek Yönetimi
Tarayıcı güvenlik modeli, app.orneksite.com'dan api.orneksite.com'a yapılan isteği farklı origin olarak değerlendirir. Subdomain'ler aynı ana domaini paylaşsa da ayrı origin sayılırlar. api. servisi, hangi origin'lerden gelen istekleri kabul edeceğini açıkça bildirmelidir.
Access-Control-Allow-Origin: https://app.orneksite.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Allow-Credentials: true kullanıldığında Allow-Origin değeri * olamaz; kesin bir origin belirtilmek zorundadır. Birden fazla subdomain'den istek geliyorsa, örneğin hem app. hem de admin., gelen Origin başlığını izin verilenlerle karşılaştıran ve koşula göre başlık döndüren bir yapı gerekir; statik tek bir değer yetmez.
Preflight isteği (OPTIONS) ayrıca ele alınmalıdır. Sunucu preflight'a 200 veya 204 dönmezse tarayıcı asıl isteği göndermez. Nginx üzerinde şu şekilde yapılandırılabilir:
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://app.orneksite.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
add_header 'Content-Length' '0';
return 204;
}
Access-Control-Allow-Origin: * ile Access-Control-Allow-Credentials: true birlikte kullanılamaz. Bu kombinasyonu kullanan servisler çoğu modern tarayıcıda CORS hatasına düşer ve istek engellenir. Kimlik doğrulama gerektiren endpoint'lerde kesin origin değeri zorunludur.
auth. Subdomaini ve Cookie Domain Sınırları
Cookie domain ayarı, subdomain mimarisinde sessizce hata üreten ayrıntılardan biridir. auth.orneksite.com subdomaini oturum token'larını veya refresh token'larını yönetiyorsa, cookie'nin hangi subdomain'lere görünür olduğu kasıtlı bir karar gerektir.
Cookie'yi yalnızca auth.orneksite.com'a kilitlerseniz, app.orneksite.com bu cookie'yi okuyamaz. Domain=.orneksite.com olarak ayarlarsanız tüm subdomain'ler bu cookie'ye erişebilir; bu, hassas token'lar için geniş kapsamlı bir izin anlamına gelir. Güvenli yaklaşım şudur: hassas token'ları HttpOnly; Secure; SameSite=Strict nitelikleriyle yalnızca auth. subdomainine kilitlemek, paylaşılması gereken oturum bilgisini ise uygulama katmanında aktarmak. Authorization başlığı veya refresh flow bu iş için uygundur; cookie sızdırılmaz.
SameSite=None; Secure kombinasyonu cross-site cookie için gereklidir: örneğin app.orneksite.com üzerindeki bir form auth.orneksite.com'a POST gönderiyorsa. Ancak bu kombinasyon CSRF riskini yeniden gündeme taşır ve ayrıca CSRF token mekanizması gerektirebilir. Yani tek bir nitelik değişikliği başka bir güvenlik katmanını zorunlu kılabilir.
static. Subdomaini ve CDN Entegrasyonu
Statik varlıklar (JavaScript, CSS, görsel) için ayrı bir subdomain kullanmak, CDN cache kurallarını ana uygulamadan bağımsız yapılandırmanızı sağlar. static.orneksite.com için CNAME kaydı, CDN sağlayıcısının verdiği hostname'e yönlendirilir.
static 3600 IN CNAME xxxxxx.cdnprovider.example.
CDN tarafında static.orneksite.com için TLS sertifikası da kurulmalıdır; aksi hâlde tarayıcı mixed content veya sertifika hatası üretir. Çoğu CDN sağlayıcı, custom domain için sertifikayı otomatik devreye alır; bu özelliği etkinleştirmeyi unutmayın. Cache-Control başlıklarını static. için agresif tutabilirsiniz: dosya adına versiyon hash'i eklediğinizde, örneğin main.a3f7c2.js, eski dosyanın önbellekte kalması sorun yaratmaz, çünkü yeni derleme yeni isim getirir.
static. için CORS ayarı da gerekebilir: app.orneksite.com üzerinden static.orneksite.com/font.woff2 isteği, font yüklemelerinde CORS denetimine tabidir. Hassas veri içermeyen font ve benzeri kaynak türleri için CDN'de Access-Control-Allow-Origin: * genellikle kabul edilebilir bir tercihtir.
Farklı sağlayıcılardaki DNS panellerinde subdomain yönetimi için arayüzler değişir. DigitalOcean ortamındaki adımlar için DigitalOcean DNS ile subdomain yönetimi, Google Cloud altyapısı için ise Google Cloud DNS zone yönetimi yazıları başvurulabilecek kaynaklardır.
DNS Propagasyonu ve Kesintisiz Geçiş
Yeni subdomain eklemek ile mevcut kaydı değiştirmek farklı riskler taşır. Yeni subdomain DNS'e eklendikten sonra çözümleyicilerin bunu öğrenmesi TTL süresine bağlıdır. Yaygın public resolver'lar 5-15 dakika içinde güncellenir; bazı ISS çözümleyicileri eski değeri daha uzun süre cache'te tutabilir.
Mevcut bir subdomain'i farklı sunucuya taşıyorsanız sıra önemlidir: önce yeni sunucuyu hazırlayın ve erişilebilir olduğunu doğrulayın, DNS kaydını güncelleyin, propagasyon süresince her iki sunucuyu da aktif tutun, eski sunucuyu geçiş tamamlanmadan kapatmayın. TTL'i değiştirmeden önce kısaltmamak, bazı kullanıcıların eski IP'ye saatler boyunca bağlanmasına yol açar; bu sürede her iki sunucunun aynı yanıtı vermesi gerekir.
Subdomain geçişlerinde DNS kaydını değiştirmeden en az 48 saat önce TTL'i kısaltın; 300 saniye iyi bir başlangıç değeridir. Geçiş tamamlandıktan ve yeni değer yayıldıktan sonra TTL'i tekrar uzatabilirsiniz.
Azure altyapısında subdomain yapılandırması için Azure DNS ile domain yönetimi yazısı Microsoft'a özgü adımları kapsamaktadır. Vercel ve Netlify gibi edge dağıtım platformlarında subdomain doğrulama sürecinde karşılaşılan sorunlar ise ayrı bir dikkat gerektiriyor; bu konuyu Vercel ve Netlify custom domain sorunları yazısı ele almaktadır.
api., auth. ve static. subdomain'lerinin her biri DNS kaydından fazlasını gerektirir: SSL kapsamı, CORS politikası ve cookie sınırları ayrı ayrı tasarlanmazsa mimari teoride temiz, pratikte kırık olur. Bu kararları ilk kurulumda net almak, sonradan çıkacak hata ayıklama sürecini ciddi ölçüde kısaltır. Yanlış cookie domain'i veya eksik CORS başlığı, oturum sorunlarına uzanan ve izini sürmesi saatler alan hatalara dönüşebilir.
Her subdomain için küçük bir kontrol listesi tutmak işi kolaylaştırır: DNS kaydı ekli mi, SSL sertifikası bu subdomain'i kapsıyor mu, CORS allowed-origins listesine eklendi mi, cookie domain kasıtlı seçildi mi. Bu dört soruyu kurarken yanıtlamak, üretim sonrası çıkan sorunların büyük bölümünü oluşmadan önler.
Microservice sayısı büyüdükçe subdomain yönetimi de karmaşıklaşır; farklı ekiplerin farklı servislere baktığı ortamlarda bu kararları belgelemek kritik bir pratik hâline gelir. Domain ve DNS kararlarınızı merkezi bir yerde tutma yaklaşımları için domain portföyü yönetimi yazısı fikir sunabilir.