SaaS’te Özel Alan Adları ve Otomatik SSL: DNS‑01 ile Çok Kiracılı Mimarini Nasıl Tatlı Tatlı Ölçeklersin?

Giriş: Müşterinin Domaini, Senin Uykun ve DNS‑01’in Sakinleştirici Etkisi

Geçen hafta akşamüstü kahve bardağımın dibindeki telveleri karıştırırken bir müşteriden mesaj düştü: “Kendi alan adımı bağlamak istiyorum, SSL de otomatik olsun, mümkün mü?” Bir an gülümsedim, çünkü bu soru beni yıllar önceki uykusuz gecelere götürdü. Subdomain ile uçuyoruz, her şey yolunda, derken özel alan adları işin içine girince bir anda trafiği doğru tenant’a yönlendirme, sertifika üretme ve yenileme, DNS gecikmeleri, oradan da orkestra şefliği… Hepsi sahnede yerini alıyor.

Hiç başınıza geldi mi? Müşteri domainini bağlar, siz de “beş dakika” dersiniz ama o beş dakika DNS yayılımıyla birlikte uzar gider. O gün kendi kendime “Bu iş otomatikleşmeli” demiştim. İşte bu yazıda, çok kiracılı (multi‑tenant) bir SaaS’te özel alan adlarını nasıl güvenle bağlayacağınızı, otomatik SSL’i DNS‑01 ile nasıl sorunsuz ölçekleyeceğinizi, pratikte neyin gerçekten işlediğini ve hangi küçük taktiklerin geceleri daha rahat uyumanıza yardım ettiğini adım adım anlatacağım. Biraz mutfaktaki kokulara benzeyecek; bazen hızlı, bazen kısık ateşte, ama sonunda mis gibi bir yemek çıkacak.

Özel Alan Adı Desteği Neden Zor Gelir? Çünkü Trafiğin Kime Ait Olduğunu Kanıtlamalısın

Çok kiracılı bir mimaride kendi subdomain’lerinizle hayat daha kolaydır. Yönlendirme basittir, sertifikaları toplu yönetirsiniz, tek bir wildcard ile ilerleyebilirsiniz. Özel alan adları devreye girince, film biraz değişiyor. Artık sizin kontrolünüzde olmayan DNS bölgeleri var, apex (kök) kayıtların cazibesi ve CNAME sınırlamaları var, bir de müşterinin DNS paneline erişimi ve alışkanlıkları devreye giriyor.

Mesela şöyle düşünün: Kullanıcı “shop.ornek.com”u sizin SaaS’e bağlamak istiyor. Sizin görevleriniz bir anda çoğalıyor. O hosta gelen trafiği doğru tenant’a götüreceksiniz, TLS el sıkışmasında doğru sertifikayı sunacaksınız, sertifika üretimi için alan adı sahipliğini kanıtlayacaksınız ve tüm bunları otomatik bir akışa oturtacaksınız. HTTP‑01 bazen pratik görünür ama müşteri trafiğini henüz size yönlendirmeden doğrulama yapamayabilirsiniz. İşte bu yüzden DNS‑01’in sakin bir “gel, TXT kaydını beraber ekleyelim” tavrı paha biçilmezdir.

DNS‑01 Neyi Kolaylaştırır? Wildcard, Yönlendirme Sırası ve Bağımsız Doğrulama

DNS‑01’in en güzel yanı, doğrulama için HTTP trafiğine ihtiyaç duymamasıdır. Yani müşteri henüz “CNAME” veya “A/AAAA” ile sizi işaret etmeden, sadece bir TXT kaydı ekleyerek alan adı sahipliğini kanıtlar. Bu da onboarding sürecini adım adım yönetmenizi sağlar. Önce doğrular, sonra trafiği size yönlendirir, derken siz de otomatik sertifikayı üretip sunarsınız. Üstelik wildcard ihtiyaçlarında da DNS‑01 tek anahtardır; “*.ornek.com” gibi alanlar yalnızca DNS‑01 ile doğrulanır.

Pratikte süreç şöyle akar: ACME istemciniz bir meydan okuma değeri üretir, siz de bunu müşteriye gösterir ve “şu TXT kaydını ekleyelim” dersiniz. Doğrulama geçer, sertifika üretilir, yenilemeler de aynı ray üzerinde devam eder. Burada kritik olan şey, gecikmelerle başa çıkacak kadar sabırlı ama otomasyonu bozmayacak kadar net bir akış tasarlamaktır. TXT kayıtlarının temizliği, TTL yönetimi ve idempotent istekler bu filmin görünmez kahramanlarıdır. Birazdan hepsini daha somut hale getireceğiz.

Tenant Onboarding Akışı: Küçük Adımlar, Büyük Güven

Doğrulama İçin Müşteriyi Yormayan Yol

İlk adım, alan adının gerçekten müşterinize ait olduğunu kanıtlamak. Bunu iki tatlı yöntemle yaparsınız: TXT kaydı veya temsilci bir CNAME ile doğrulama. Ben çoğu zaman TXT kaydını seviyorum, çünkü doğrudan ACME’nin beklediği anahtar‑değer yapısına oturuyor. Panelinizde kullanıcıya basit bir talimat verirsiniz, mümkünse sağlayıcıya göre özelleştirilmiş bir görsel veya kısa bir yardım metni gösterirsiniz. Müşteri kaydı ekler, siz periyodik kontrol edersiniz, doğrulama geçince ekranda yeşil bir “tamam” görür.

Yönlendirme Sırası ve Sertifika Zamanlaması

Doğrulama tamamlandıktan sonra trafik yönlendirmesini istersiniz. Burada zamanlamayı dikkatli kurmak önemli. Sertifikayı üretmek için DNS‑01’i geçtiyseniz, yönlendirmeden önce sertifikaya sahip olabilirsiniz ve kullanıcı trafiği geldiği an güvenli bir sayfa görür. Bu, ilk izlenim için güçlü bir mesajdır. Bazı durumlarda önce yönlendirme gelir, sonra sertifika üretilir; bu da kısa bir “güvenilir değil” riski doğurur. Bu yüzden “önce doğrula, sonra üret, en son yönlendir” akışı çoğu senaryoda içimi rahatlatmıştır.

TTL, Yayılım ve Daha Az Sabırsızlık

DNS dünyası sabırsızlığı sevmez. TTL’ler, önbellekler, eve dönüş yolunu uzatan aradaki sunucular… Hepsi oyunun parçası. Panelinizde kullanıcıya gerçekçi bir zaman penceresi göstermek çok işe yarar. Bazı sağlayıcılarda TXT kaydı bir dakikada görünür, bazılarında on dakika ister. Otomasyon tarafında da kontrolleri belirli aralıklarla yaparak gereksiz yoğunluğu önleyin. Yenileme dönemlerinde aynı sabrı gösterip eski TXT kayıtlarını temizlemeyi unutmayın; pano karmaşasını azaltır, bir dahaki doğrulamada sürprizleri engeller.

Sertifika Otomasyonu: Kuyruk, Geri Alma ve Rate Limit Sakinliği

ACME tarafında işi gerçekten tatlı hale getiren şey, iyi tasarlanmış bir kuyruk. Domain doğrulaması geçmiş ve üretime hazır alan adlarını sıraya koyarsınız. İstekleri toplu ama aralıklı gönderirsiniz. Bir anda yüzlerce sertifika talebi patlarsa, sağlayıcı limitleri hatırlatır. Benim yaklaşımım basit: yenileme penceresini uzun tutmak, sırayı gün içine yaymak ve hata aldığımda akıllı bir geri alma süresi uygulamak. Bu sayede ani pikler yerine sabit bir ritimde ilerlemeyi başarırsınız.

Limitler dünyasında daha ince taktikler de var. Deneme sürecini staging uç noktalarıyla yapın, gerçek sertifikaları en son aşamada üretin. Ortak adlar üzerinden SAN sertifikalarına abanmak bazen cezbedicidir ama her tenant’ın bağımsız döngüsünü sürdürmek operasyonel esneklik sağlar. Ayrıntılı önerileri merak ediyorsanız, Let’s Encrypt rate limitlerine takılmadan çok alan adında SSL üretmenin tatlı stratejileri üzerine yazdığım notlar pratik bir rehber gibi çalışır.

Trafiği Doğru Tenanta Taşımak: SNI, Host ve Hafızanın Hızı

İşin sahne önü aslında çok yalın: Kullanıcı tarayıcıya alan adını yazar, sizin edge katmanınız gelen isteğin Host başlığını ve SNI bilgisini okur, ilgili tenant’ı bulur, sertifikayı sunar ve trafiği doğru uygulamaya delice koşmadan, sakince iletir. Sahne arkası ise küçük bir koreografi ister. Sertifika nerede duracak, hangi formda saklanacak, sıcak depoya nasıl alınacak? Bu tip sorulara net cevaplar verince, performans şarkı söylemeye başlar.

Ben pratikte, sertifika zincirlerini küçük ama hızlı bir anahtarlığa yerleştirip, güncelleme geldiğinde kenardan içeri alırım. Belki bir KV deposu, belki RAM’de bir önbellek, belki dağıtık bir objeye yakın saklama. Hangisi olursa olsun, “SNI → sertifika” eşlemesinin hızlı çıkması sizi taşır. Üstüne bir de düzgün loglama ve birkaç cilalı metrik ekleyince, sorun çıktığında o meşhur “Nerede tıkandı?” sorusuna daha hızlı cevap bulursunuz.

DNS Sağlayıcı Entegrasyonları: API’ler, Abstraksiyon ve Temizlik

DNS‑01’in kalbi, kayıtları otomatik ekleyip kaldırabilmektir. Her sağlayıcının API’si farklı, her birinin zihin dünyası başka. Bu yüzden araya bir soyutlama katmanı koymak mantıklı. “Domain sağlayıcı sürücüsü” gibi düşünün; tek bir arayüz, birden çok entegrasyon. O arayüz de idempotent olsun, aynı isteği tekrar alırsa ikinci kez abartmasın, silmesi gerekeni bulsun, yoksa nazikçe çekilsin. Bu yaklaşım hataları insanların görmeyeceği kadar erken yakalar.

Güvenlik tarafında, API anahtarlarının özenle saklanması şart. Rotasyon ve erişim kısıtlamaları, üretimde içimi rahatlatan iki küçük sihir. Operasyon bittiğinde ise ortada TXT enkazı bırakmayın. Temizlik, gelecek doğrulamaları hızlandırır. Küçük bir not daha: DNSSEC kullanıyorsanız ve anahtar döndürme planlarınız varsa, ACME doğrulamalarıyla çakışmayacak bir takvim tutmak işleri kolaylaştırır. Bu konuda özet bir pusula isterseniz, DNSSEC anahtar döndürme ve DS güncelleme ipuçları işinizi görür.

Wildcard mı, Her Domain İçin Sertifika mı? Kararın İnce Tuz Ayarı

Subdomain dünyasında wildcard, tam bir huzur kaynağıdır. “*.uygulamam.com” ile pek çok tenant’ı tek seferde kapsarsınız. Ama müşterinin kendi alan adı devreye girdiğinde, her özel domain için ayrı sertifika üretmek doğal akıştır. Bu noktada uyumluluk ve hız dengesi akla gelir. Bazı istemciler ECDSA’yı sever, bazı eski sistemler RSA’dan vazgeçmez. İkisini birden sunmak, bazen beklenmedik uyumluluk hediyesi verir. Merak edenler için, Nginx ve Apache’de ECDSA + RSA ikili SSL kullanarak uyumluluk ve hız dengesini kurma üstüne not ettiğim pratikler burada da birebir çalışır.

Yenileme takvimi de bu tercihlerin gölgesinde şekillenir. Çok sayıda sertifikayı yenilerken küçük bir es verip sırayı dağıtmak, başarısız isteklerde geri alma sürelerini akıllı ayarlamak ve sakin kalmak oyunun kuralı. Tek seferde her şeyi zorlamak yerine gün içine yayılmış minik adımlar, ölçek büyüdükçe sırtınızı sıvazlar. Küçük tempoların toplamı, büyük ritimdir.

Apex (Kök) Alan Adı ve CNAME Dileği: ALIAS/ANAME ile Sarılan Bir Dünya

Apex kayıtlar çoğu zaman en çok sevilen, ama en çok nazlanan parçadır. Kökte CNAME olmaz, dersiniz ve sessizlik. Kullanıcı tam da ana domainini bağlamak istediğinde “Peki şimdi?” bakışıyla size döner. Burada ALIAS ya da ANAME gibi sağlayıcıya özel çözümler devreye girer. Bu kayıtlar, CNAME’in esnekliğini kökte yaşamaya çalışır. Sağlayıcınız destekliyorsa hayat kolaylaşır, desteklemiyorsa A/AAAA ile daha klasik bir rotaya dönersiniz.

Bu meselenin hikâyesini biraz eğlenceli bir dille anlattığım bir not var, aklınızın bir köşesinde dursun: kökte CNAME hayali ve bunu aşmanın yolları. Günün sonunda hedef net: Kullanıcının alan adını en stabil şekilde sizin uçlarınıza taşımak ve TLS’i tek bir tıkla parlatmak. Yöntem ne olursa olsun, taşınan şey güven duygusu.

Kubernetes mi, VM mi? Önemli Olan Akışın Temizliği

Altyapı tercihi ne olursa olsun, akış aynı şarkıyı söyler. Kubernetes kullanıyorsanız, ACME istemcisi olarak cert‑manager gibi araçlar işinizi çok kolaylaştırır. Onun dünyasını merak edenler için cert‑manager dokümantasyonu gayet anlaşılır. VM veya bare‑metal tercih ediyorsanız, lego, dehydrated, acme.sh gibi araçlarla aynı koreografiyi kurabilirsiniz. Buradaki kritik konu, sertifika yaşam döngüsünün uygulamadan bağımsız kalabilmesi ve başarısız adımlarda sistemin sakin bir geri dönüş yolu bulabilmesidir.

İşin protokol tarafına kısa bir selam çakalım. ACME’nin mantığını birkaç sayfada güzelce özetleyen RFC 8555 ve doğrulama yöntemlerinin ince ayarlarını anlatan Let’s Encrypt’in challenge türlerine dair dokümantasyonu, teknik arka planı anlamak için yeterli. Ama pratikte en çok kazandıran şey, sizin ekip için anlaşılır ve tekrar edilebilir bir akış yaratmak. Bir mühendis işe yeni girdiğinde beş dakika içinde nereden başlayacağını görebilirse, otomasyon gerçekten otomasyon olur.

Güvenlik ve Operasyon: Küçük Detaylar Büyük Felaketleri Önler

Sertifika anahtarları, API kimlik bilgileri, yenileme zamanları… Bunların hepsi özen ister. Gizli bilgileri sadece gerektiği kadar görünür kılmak, erişim izinlerini en düşük seviyede tutmak ve hatalı yapılandırmaları erken yakalayan sağlık kontrolleri eklemek, beni defalarca kaza şeridinden çevirmiştir. Logları sadece olumsuzluk olduğunda değil, iyi günlerde de takip edin. İyi günlerin ritmini bilirseniz, kötü günde şarkı bozulduğunda kulağınız hemen anlar.

Operasyon tarafında bir başka huzur veren alışkanlık, test ortamlarında staging sertifikalarla tam tur prova yapmak. TXT kaydı ekleniyor mu, doğrulama beklediğim gibi mi, yönlendirmeden önce sertifika hazır mı? Bu sorulara ezbere cevap verdiğinizde, üretim sahnesine çıktığınızda eliniz titremez. Küçük tatbikatlar, büyük sahnelerin sırrıdır.

Kapanış: Akış Kurulunca Gerisi Müzik

Özel alan adları ve otomatik SSL, çok kiracılı SaaS’in kalbinde güçlü bir güven şeridi çizer. DNS‑01 ile doğrulama yaptığınızda, müşterinin trafiği size akmadan sahipliği kanıtlar, siz de sertifikayı hazır bekletirsiniz. Arkada iyi tasarlanmış bir kuyruk, akıllı geri alma süreleri, temiz DNS entegrasyonları ve hızlı SNI eşlemesi olunca, en stresli geçişler bile bir sabah yürüyüşü kadar sakin geçer. Küçük ama sürekli iyileştirmelerle bu akış, her yeni tenant’ta daha da pürüzsüz hale gelir.

Pratik birkaç hatırlatma bırakıp vedalaşayım. Müşteriye net yönergeler verin, panelde sağlayıcıya göre uyarlanmış minik yardımlar koyun, TXT temizliğini ihmal etmeyin, yenilemeleri güne yayın. ECDSA + RSA ikilisiyle uyumluluğu cepleyin, apex senaryolarında ALIAS/ANAME ihtimalini erkenden konuşun ve DNSSEC takvimini doğrulama pencereleriyle çakıştırmayın. Böyle bir düzen kurulduğunda, kullanıcı “Kendi domainimi bağladım, SSL de var, ne güzel ışıl ışıl” dediğinde, siz de içinizden “evet, tam da planladığımız gibi” dersiniz. Umarım bu rehber işinize yarar; sorularınız olursa notlarınızı hazırlayın, bir sonraki yazıda yine sahnenin arkasına beraber bakarız.