17 Ara 2025·7 dk
Web uygulamaları için özel alan adı kurulumu: DNS, SSL ve geçiş
Web uygulamaları için özel alan adı kurulumu: net DNS kayıt adımları, SSL çıkarma, yönlendirmeler ve kesinti/çerez sorunlarını önleyen düşük riskli geçiş planı.
Web uygulamaları için özel alan adı kurulumu: net DNS kayıt adımları, SSL çıkarma, yönlendirmeler ve kesinti/çerez sorunlarını önleyen düşük riskli geçiş planı.
Özel bir alan adı sadece daha güzel bir URL’den ibaret değildir. Platform adresinden (örneğin Koder.ai alt alanında barınan bir uygulama) kendi alan adınıza geçtiğiniz an, tarayıcılar ve ağlar onu farklı bir site olarak değerlendirir. Bu, yönlendirme, güvenlik ve kullanıcı oturumlarının davranışı üzerinde etkili olur.
Özel alana geçince hemen değişen birkaç şey:
www mü yoksa apex alan adında mı konumlanacağını siz belirlersiniz; ayrıca HTTP→HTTPS kurallarının tutarlı olması gerekir.old-platform.example için verilen bir giriş çerezi otomatik olarak app.yourdomain.com üzerinde çalışmaz.Kısa kesintiler genellikle zamanlamadan kaynaklanır. DNS trafik göndermeye yeni hosta başladığında SSL sertifikası hazır olmayabilir ve tarayıcı uyarıları çıkabilir. Ya da tam tersi: SSL hazırdır ama birçok kullanıcı eski yerde kalır çünkü DNS önbelleği süresi henüz dolmamıştır.
Yönlendirmeler oturumları ince bir şekilde bozabilir. Host adı değiştiren bir yönlendirme (apex’den www’e veya tam tersi) farklı host için ayarlanmış çerezleri düşürebilir. Kimlik sağlayıcıları, callback URL hâlâ eski domaini gösteriyorsa başarısız olabilir.
Düşük riskli bir geçiş, overlap (örtüşme) planlamak demektir: eski URL’yi çalışır tutun, yeni domaini paralel olarak ayağa alın, trafiği öngörülebilir bir anda değiştirin ve rollback’i DNS’i geri çevirmek kadar basit yapın.
Herhangi bir şeye dokunmadan önce kullanıcıların hangi isimleri yazacağını ve hangi isimlerin sessizce yönlendirilmesi gerektiğini tam olarak not edin. "Neden yarısı çalışıyor?" anlarının çoğu ekibin tek doğru ana bilgisayarda anlaşmamasından kaynaklanır.
Büyük tercihten başlayın: öncelikli host apex (example.com) mi yoksa www (www.example.com) mı olacak. İkisi de çalışabilir, ama birini seçin ve diğerini yönlendirme olarak ele alın. Bu, çerezler açısından da önemlidir: uygulamanın tek bir tutarlı hostta olması oturumları kolaylaştırır.
Sonra hangi alt alanlara (subdomain) şimdi ihtiyaç duyduğunuzu ve hangilerinin sonra eklenebileceğini belirleyin. Yaygın bir desen app.example.com web uygulaması, api.example.com API’ler içindir; admin.example.com veya assets.example.com sonra eklenir. Bir platformda (örneğin Koder.ai) özel alan adı kuruyorsanız, bu seçimler doğrudan sertifika doğrulaması ve DNS hedeflemesine yansır.
Birçok kişi alan adını bir kayıt kuruluşundan satın alır, ama DNS başka bir yerde barınıyor olabilir. Bugün kayıtların nerede düzenlendiğini, kimin erişimi olduğunu ve herhangi bir otomasyonun (şirket IT’si, ajans veya yönetilen DNS sağlayıcısı) değişiklikleri yönetip yönetmediğini doğrulayın. Giriş yapıp mevcut kayıtları göremiyorsanız, önce bunu düzeltin.
Ayrıca alan adını kullanan şeyleri denetleyin. E‑posta klasik tuzaktır: kayıtları silerek veya üzerine yazarak posta teslimini bozabilirsiniz.
İlerlemeye başlamadan önce bu kararları yazılı hale getirin:
www) ve yönlendirme yönüEğer pazarlama zaten example.com üzerinde e‑posta çalıştırıyorsa, posta ile ilgili kayıtları değiştirmeyin; sadece uygulama için gerekenleri ekleyin.
Özel alan adı taşınmasında riskin çoğu uygulamanın kendisinden gelmez. Yanlış bir DNS değişikliği trafiği hiç bir yere gönderebilir, e‑postayı bozabilir veya SSL doğrulamasının başarısız olmasına neden olabilir.
Bir A kaydı bir ismi bir IP adresine işaret eder. Basitçe: “insanları bu sunucuya gönder.” Sağlayıcınız sabit bir IP veriyorsa apex (example.com) için yaygındır.
Bir CNAME kaydı bir ismi başka bir isme işaret eder. Basitçe: “bu ismi o hostun taklidi olarak ele al.” Genelde www.example.com’un bir platform ana bilgisayar adına işaret etmesi için kullanılır.
Birçok DNS sağlayıcısı apex için ALIAS/ANAME sunar. CNAME gibi davranır ama example.com için çalışır. Sağlayıcınız destekliyorsa, hedef değiştiğinde IP’leri elle yönetmek yerine daha kolay olur.
Basit bir zihinsel model:
Sıkça TXT kayıtları alan sahipliğini kanıtlamak (platform doğrulaması) veya SSL sertifikası doğrulaması için kullanılır (bazı CA’lar doğrulama için TXT token ister). TXT ayrıca e‑posta politikası için (ör. SPF) kullanılır. Mevcut SPF TXT’yi yanlışlıkla silmek veya değiştirmek posta teslimini bozabilir.
TTL diğer sistemlerin DNS cevabınızı ne kadar süreyle önbelleğe alacağını kontrol eder. Bir gün önce, değiştireceğiniz kayıtların TTL’sini düşürün (genelde 300–600 saniye). Her şey stabil olduktan sonra tekrar yükseltin.
Düzenlemeden önce bölge dosyasını dışa aktarın veya ekran görüntüsü alın. Değiştireceğiniz her kaydı, eski değeri, yeni değeri ve TTL ile yazın. Bir şey ters giderse rollback, önceki değerleri geri yüklemektir.
Bu, alan adınızda zaten MX, DKIM veya diğer TXT kayıtları olduğunda en çok önem taşıyan kısımdır.
SSL (kilit simgesi) tarayıcı ile uygulamanız arasındaki trafiği şifreler. Modern tarayıcılar ve birçok API HTTPS bekler. HTTPS yoksa uyarılar, engellenen istekler olabilir ve servis worker’lar, konum gibi bazı özellikler çalışmayabilir.
Sertifika çıkarmak için CA sizin alanı kontrol ettiğinizi doğrulamalıdır. Yaygın doğrulama yöntemleri HTTP doğrulaması ve DNS TXT doğrulamasıdır:
DNS doğrulaması, özellikle CDN kullanıyorsanız veya uygulamanız yeni domain üzerinde henüz erişilebilir değilse genellikle kolaydır.
Sertifikanın nerede çıkarıldığı kurulumunuza bağlıdır. Bazı ekipler sertifikaları doğrudan kendi sunucularında çıkarır, bazıları CDN seviyesinde yapar, bazı platformlar ise özel alan adı sırasında yönetir (örneğin Koder.ai domain kurulumu sırasında sertifikayı yönetebilir). Önemli olan, yenilemeler dahil sertifika yaşam döngüsünün kimin sorumluluğunda olduğunu bilmektir.
Sertifika çıkarma her zaman anlık değildir. DNS yayılması, doğrulama kontrolleri ve hız limitleri süreci yavaşlatabilir. Yeniden denemeler için plan yapın ve son dakikaya bırakmayın.
Pratik bir zamanlama planı:
Sertifika kullanıcıların erişeceği her host adını kapsamalıdır. SAN listesini (Subject Alternative Names) kontrol edin. Uygulamanız hem example.com hem de www.example.com üzerinde erişilebilir olacaksa, sertifika her ikisini de içermelidir.
Wildcard (ör. *.example.com) birçok alt alanı kapsayabilir, ancak apex (example.com)’i kapsamaz.
Somut örnek: sadece www.example.com için sertifika çıkarırsanız, kullanıcılar example.com yazdıklarında uyarı görürler, ta ki apex için geçerli bir sertifika veya uygun bir yönlendirme katmanı sağlanana kadar.
Yönlendirmeler basit görünür, ama alan adı problemlerinin çoğu burada ortaya çıkar: döngüler, karışık içerik ve kullanıcıların oturumlarının kaybolması. Bir kanonik host seçin ve ona sadık kalın: ya www.example.com ya da example.com (apex). Diğer giriş noktası kanonik hosta yönlendirilmelidir ki çerezler, oturumlar ve SEO sinyalleri tutarlı olsun.
Güvenli varsayılanlar:
http:// → https:// 301 yönlendirmesiHTTP→HTTPS için, kullanıcıları ileri geri döndüren kurallardan kaçının. Döngüleri önlemenin en kolay yolu kararı isteğin gerçekten ne olduğuna göre almaktır. Uygulamanız bir proxy veya CDN arkasındaysa, iletilen başlıkları (forwarded headers) dikkate alacak şekilde yapılandırın; aksi halde uygulama her isteği HTTP sanıp sürekli yönlendirme yapabilir.
Taşınma sürecinde eski yolları açık tutun. Yolları değiştiriyorsanız (ör. /login → /sign-in), bu yollar için özel yönlendirmeler ekleyin. Genel bir yönlendirmeye ana sayfaya bırakmak yer işaretlerini ve paylaşılan bağlantıları kırar.
HSTS’yi başlangıçta etkinleştirmeyin. Çok erken etkinleştirirseniz ve daha sonra doğrulama veya hata ayıklama için HTTP servis etmeniz gerekirse, tarayıcılar reddedebilir. HTTPS kararlı hale gelip alt alan kapsamını doğrulayana kadar bekleyin.
Yönlendirmeleri herkes etkilemeden test etmek için geçici bir test hostname kullanın, birkaç gerçek derin bağlantı deneyin (kimlik sayfaları dahil) ve her yönlendirme adımını ve nihai hedefi gösteren komut satırı istekleri çalıştırın.
Güvenli bir geçiş büyük ölçüde zamanlamadır. Yeni domaininizi hazır ve test edilmiş hâlde tutmak istersiniz; gerçek kullanıcılar oraya yönlendirilmeden önce ve DNS değişiklikleri hızlı yayılacak şekilde planlanmalı.
Değiştireceğiniz kayıtların TTL’sini mümkünse bir gün önce düşürün ve eski TTL penceresinin dolmasını bekleyin. Sonra, sağlayıcınızda özel alan adını ekleyin ve gereken doğrulamaları tamamlayın. Koder.ai gibi bir platform kullanıyorsanız, platforma önce alan adını ekleyin ki sahiplik doğrulansın ve yönlendirme hazırlanabilsin.
Sertifikayı erken çıkarın. Sertifikalar dakikalar sürebilir veya daha uzun; geçiş sırasında bu gecikmeyi yaşamak istemezsiniz.
Alan adı herkese açılmadan önce özel bir test yapın: kendi makinenizde geçici bir host girdisi kullanarak yeni uç noktayı HTTPS ile yükleyip doğru sertifikayı doğrulayın.
Hızlı müdahale edebilmek için kademeli bir yaklaşım kullanın:
Gerçek bir DNS düzeyinde canary yapamıyorsanız, yine de www’ü önce değiştirerek aşama uygulayabilirsiniz ve apex’i güven gelene kadar dokunmazsınız.
Hangi kayıtları ve hangi değerleri geri alacağınızı yazın ve kimin yapacağını belirleyin. Rollback genelde DNS’i eski hâline getirmektir.
Eski kurulumun hâlâ geçerli (eski domain üzerindeki SSL dahil) olduğundan emin olun ki kullanıcılar temiz bir şekilde geri dönebilsin.
Alan adı değişikliği sadece DNS değişikliği değildir. Birçok uygulama için "oturum açık" kalmak çerezlere bağlıdır ve tarayıcılar çerezleri belirli bir ana bilgisayara bağlar. Bir ana bilgisayardan diğerine geçerseniz tarayıcı eski çerezleri göndermeyi keser ve uygulamanız herkesin çıkış yaptığı izlenimine kapılabilir.
Çerez ayarları genellikle suçludur:
app.old.com için ayarlanmış bir çerez app.new.com’a gönderilmez. .example.com için ayarlanmış bir çerez app.example.com ve www.example.com arasında çalışabilir./api) web UI onu göremeyebilir.Lax birçok durumda yeterli olur, ama bazı SSO veya ödeme yönlendirmeleri None + Secure gerektirebilir.Riskleri azaltmak için kısa bir geçiş planlayın: her iki domain de çalışır durumda olsun. Eski hostname yanıt vermeye devam etsin ve dikkatli yönlendirmelerle yeni domainde oturumların yenilenmesine izin verin. Mümkünse paylaşılan bir oturum deposu kullanın ki kullanıcı hangi hostname’e gelirse gelsin tanınsın.
SSO veya OAuth kullanıyorsanız, cutover’dan önce callback URL’leri, allowed origins ve "audience"/redirect URI allowlist’lerini güncelleyin. Aksi halde kimlik sağlayıcıda giriş başarılı olsa bile uygulamaya dönerken başarısız olabilir.
İlk bozulan akışları test edin: kayıt (e‑posta doğrulama), giriş/çıkış, şifre sıfırlama, ödeme dönüşü ve çoklu sekme oturumları.
Örnek: www.example.com’u example.com’a yönlendiriyorsanız çerezlerin .example.com için ayarlandığından veya tek bir host kullanıldığından emin olun; aksi halde kullanıcılar hostlar arasında gidip gelirken oturum kaybedebilir.
Çoğu domain problemi "esrarengiz internet sorunları" değildir. DNS, sertifikalar ve yönlendirme kuralları arasındaki küçük uyumsuzluklardır ve gerçek kullanıcılar siteye erişince ortaya çıkar.
Kolay bir tuzak apex domainidir (example.com). Birçok DNS sağlayıcısı apex’te gerçek bir CNAME’e izin vermez. Apex’e CNAME zorlamaya çalışırsanız, bu sessizce başarısız olabilir, tutarsız çözülür veya sadece bazı ağlarda bozulur. DNS sunucunuzun desteklediğini (A/AAAA veya ALIAS/ANAME tarzı) kullanın.
Bir diğer sık neden: SSL hazır olmadan DNS’i değiştirmek. Kullanıcılar yeni hedefe gelir ve sertifika eksik veya yalnızca bazı hostları kapsadığı için tarayıcı engeller. Pratikte genelde sertifikanın hem example.com hem de www.example.com’u kapsamasını istersiniz, hatta birini diğerine yönlendirecekseniz bile.
Açık nedenlerden bazıları:
www → apex sonra apex → www) veya bir yerde HTTP’yi zorlayıp diğer yerde HTTPS’ihttp:// ile sabit olarak kodlanmış varlıkları göndererek karışık içeriğe sebep olmakHızlı bir kontrol: Her iki hostname’i (www ve apex) HTTPS ile açın, giriş yapın, yenileyin ve adres çubuğunun asla HTTP’ye dönmediğini doğrulayın.
Eğer bunu Koder.ai gibi bir platformda yapıyorsanız, özel alan adlarının bağlandığını ve SSL’in verildiğini doğrulamadan üretim DNS’ine dokunmayın; kötü bir yönlendirme veya kayıt değişikliği uzun süre kalıcı olmasın diye rollback seçeneğiniz hazır olsun.
Sakin bir geçiş büyük ölçüde hazırlık işidir. Amaç basit: kullanıcılar giriş yapmaya devam etmeli, çerezler çalışmalı ve bir şey ters giderse hızlıca geri alabilmelisiniz.
Bunları eski domain’e trafik giderken yapın. Mümkünse bir gün verin ki DNS değişiklikleri yerleşsin.
www, api vb.) belgeleyin ve SSL doğrulama yöntemini seçin (DNS veya HTTP).www→apex (veya tersi) ve tek kanonik host.DNS’i çevirdiğinizde ilk saati bir olay tatbikatı gibi ele alın. Gerçek kullanıcı akışlarını izleyin, sadece durum panellerine bakmayın.
Koder.ai (veya başka bir platform) özel alan adlarını ve SSL’i sizin için hallediyor olsa bile checklist yine geçerlidir. Sorunların çoğu DNS ve yönlendirmelerden gelir, uygulama kodundan değil.
Uygulamanız myapp.koder.ai gibi geçici bir platform adresinde çalışıyor. Her şey düzgün ama müşterilerinizin example.com kullanmasını istiyorsunuz; www.example.com apex’e yönlensin ve her şey HTTPS’e zorlanmış olsun.
Basit bir DNS planı riski düşük tutar. Hiçbir şeyi değiştirmeden önce mevcut çalışan durumu not edin (platform destekliyorsa bir snapshot alın) ve DNS TTL’yi değişiklikten bir gün önce kısa bir değere düşürün.
Mevcut platform URL’sini dokunmadan yeni kayıtları ekleyin:
example.com: sağlayıcınızın verdiği barındırma hedefini işaret eden A/ALIAS kaydıwww.example.com: ya example.com’a CNAME ya da sağlayıcının önerdiği platform hedefine CNAME (sağlayıcıya bağlı)myapp.koder.ai olduğu gibi kalsın ki daima bilinen bir yedek olsunDNS yerleşince her iki hostname (example.com ve www.example.com) için sertifika talep edin. Sertifika verilene kadar trafiği değiştirmeyin; aksi halde kullanıcılar tarayıcı uyarılarıyla karşılaşır.
Net kesim takvimi ve kontrol noktaları:
example.com’u test edin (ana sayfa, statik varlıklar, API çağrıları)www→apex)Taşınmadan sonra çerez davranışını doğrulayın. Giriş yapın, yenileyin ve hem www hem de apex’te oturumun devam ettiğini kontrol edin. Oturumlar bozuluyorsa genelde çerez domain’i veya SameSite ayarı eski hostu varsayıyordur.
Geçiş başarılı olsa bile iş bitmiş sayılmaz. Alan adı taşımalarının çoğu sonra başarısız olur çünkü kimse yavaşça sürüklenen öğeleri izlemez: sertifika yenilemesi, aceleyle yapılan bir DNS değişikliği veya bir yönlendirme değişikliği oturum akışlarını bozabilir.
Sürdürürsünüz diye küçük bir izleme rutini kurun. Kurumsal bir araç gerekmez ama güvenilir birkaç sinyal olmalı: ana sayfa, giriş ve en az bir kimlikli sayfa için erişilebilirlik kontrolleri; sertifika bitiş uyarıları (ör. 30 gün ve 7 gün kala); hata oranı takibi (sadece çalışma zamanı değil, 4xx/5xx patlamalarını izleyin); ve ara sıra yönlendirme doğrulaması (HTTP→HTTPS ve tercih edilen host’un kazandığını doğrulama).
Her şeyden emin olunca DNS TTL değerlerini tekrar yükseltin. Düşük TTL değişiklik sürecinde faydalıdır ama uzun vadede sorgu yükünü artırır ve küçük hataların etkisini büyütür. Normal bir TTL, değişiklik sıklığınıza göre 1–4 saat arasında seçilir.
Son olarak, durumu hâlâ taze iken nihai hâli belgeleyin: hangi kayıtların olduğunu (tip, isim, değer, TTL), desteklenen hostları, kesin yönlendirme kurallarını, sertifikaların nerede çıkarıldığını, neleri kapsadığını (apex, www, alt alanlar) ve yenilemeleri kimin yönettiğini not alın.
Bir platform üzerinde oluşturup dağıtıyorsanız, alan adlarının birinci sınıf özellik olarak ele alınması ve rollback’in kolay olması işleri gelecekte daha az stresli kılar. Koder.ai’da özel alan adları snapshot ve rollback ile yan yana durduğunda, sonraki alan adı veya yönlendirme değişikliklerini geri almak daha kolay olabilir.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.