Alan adı ve site devri: registrar, DNS ve sözleşme kontrol listesi

Devir kapsamını sözleşmede tek bir dilde yazın

Satılık dijital varlık süreçlerinde çoğu zaman “siteyi aldım” denilen şey tek bir paket olarak düşünülür; gerçekte ise alan adı (domain), yayın dizini olan dosya ve yapılandırma, kullanıcı veya iş verisi ile bunları taşıyan hosting ve yan hizmetler farklı satıcı hesaplarına dağılmış olabilir. Sözleşmede teslim kalemlerinin her biri ayrı maddede listelenmezse sonra “domain neden dahil olmadı” veya “veritabanını vermediler” tartışması üretilir. Bunu önlemek için teslim dokümanında somut çıktılar belirlenmelidir: registrar paneline erişim, transfer kilidi ve auth kodunun üretilmesi, DNS yönetiminin hangi kullanıcı veya iş ortağına geçeceği, üretim için kullanılan gizli anahtarların (API token, CI imzası) nasıl teslim ve rotasyonunun planlandığı yazılmalıdır.

Çoğu ticari yazılımda üçüncü taraf bileşenler (CDN, güvenlik duvarı, e-posta sağlayıcısı, analitik) ayrı sözleşmelerle bağlanır ve devir sonrasında alıcı kendi kurumsal uyum süreçleri gereği yeniden değerlendirmek zorunda kalabilir. Satıcı, bu bağlantılı hizmetlerin hangi tarihte kapatılıp kim tarafından devralınacağı konusunda net bir tablo vermezse teslim sırasında hizmet erişimi körükleme riski çıkar; bu da SLA veya kampanya tarihleriyle çakışabildiğinden zarar doğurabilir.

WHOIS ekranındaki görünüm, sahipliğin doğrulanması için başlangıç noktasıdır fakat güvenilir tek kaynak değildir; gizlilik hizmetleri, önbellek süreleri veya geç tarih güncellenmiş kayıtlar yanılgı oluşturur. Bunun için alıcı makul doğrulama adımlarını sırayla uygular: registrant adresinin faturalama kanıtıyla tutarlı olması, geçmiş faturaları ve oturum açma sırasında gösterilen profil ile eşleşmesi ve mümkünse düşük riskli doğrulama (geçici DNS kaydı oluşturtma ya da subdomain testi). Satıcı açısından bu adımların “makul teslim sürecinin parçası” olduğu önceden kabul görürse gereksiz gerginlik azalır.

Transfer kodu, kilidi ve onay zaman çizelgesi

Auth kodu bazı bölgelerde EPP kodu adıyla anılır; üretilir üretilmez süre ile sınırlı olabilir ve posta kutusunun yanlış veya bloklu olması devreyi sıfırdan başlatmana yol açar. Süre yaklaştığında kodu ilk denemede tüketen hatalı format veya seçilen yanlış registrar senaryosu da sık görülür. Bu yüzden takvim iki katmanlı planlanır: ilk kod için “başarı” hedefi ile değerlendirme tarihi ikinci kod üretimi ve transfer isteği tekrarı için zaman bırakır.

Alan adı transferi sırasında değişen politika gereği ek doğrulama adımları olabilir: bazı uzantılar belge talep edebilir; kurumsal alıcılar ise marka uyarıları ve dolandırıcılığı önleme birimleriyle paralel olarak transfer ister. Satıcı, bu ara adımları gizlememeli; teslim tarihini “sırf imaj” için yakın göstermek yerine güvenilir aralıkta tutmak daha profesyoneldir.

Registrar tarafına özgü araçların (premium domain, çıkış koruması) etkin olması transferi bloke eder. Satıcı, satıştan önce bu araçların kapatılıp kapatılamayacağı ve gerekiyorsa süre bağlı ücret politikalarının nasıl olduğu hususunu açıklamalıdır. Alıcı, riskli uzantılar için yedek olarak mevcut uçlar üzerinden en azından geçici yönlendirme ve bakım yapısı tasarlar.

DNS, TTL ve yayılım güvenilirliği

Birden fazla nameserver arasında zaman uyumsuzluğu ve TTL önbellekleri nedeniyle “doğru kayıtlar yüklendi” hissine kapılsa bile kullanıcılar eski IPv4 veya eski CDN uçlarına düşebilir. Bu yüzden değişiklik sırasında kademeli yaklaşım uygulanır: önce kısıtlı yüzeye test, sonra daha geniş trafik. Kritik dönüşümler (ödeme, giriş) için hata yakalama ve geri çevirme planı önceden belirlenir.

Mail taşıması MX değişiminde kesinti riski oluşturur; üstünlük süreleri beklenmezse teslim sırasında e-postanın bir kısmı eski kutuda kalır bir kısmı yenide oluşumu geciken kayıtta zıplamaya düşebilir. Bu nedenle plana SPF, DKIM ve DMARC hizalarında hangi sırayla geçiş yapılacağı, geçiş sonrasında hangi gün için izleme eşikleri konulacağı eklenmelidir.

E-posta, analitik ve çerez onayı uyumu

Site devri sırasında birçok ekip yalnızca “arka uç teslim ettik” çıktısı verirken ön yüz ölçüm etiketlerini unutur; bu ise mevcut pazarlama onaylarının yanlış yorumlanması ve çerez bantlarının yanlış yönde çalışması ile uyum sorununu tetikleyebilir. Alıcı, tag yöneticisi ve sunucu taraflı izleme bağlantılarını envanter yapıp gerekiyorsa yeni politikalarla sıfırlar; satıcı eski araçların kapatılış tarihlerini bildirmelidir.

Şirket içi raporların ve özelleştirilmiş panellerin veri çıkış işleri sıkça kritik sırları içerir; bu sırları paylaşımın amacı teslim tarihinden sonra bile sınırlı olmalıdır. Erişimin süresinin otomatik olarak dolması ve gerektiğinde yeniden imzalama yaklaşımı risk dağılımına yardım eder.

Alan adından bağımsız varlıklar ve marka riski

Domain devri sırasında alan üzerinde yayın görünümü hakikaten doğru bile olsa ticari bir unvan için başka hak sahibinin ihtiyatlı iknası gündeme gelebilir. Satış öncesi dönem içinde bu tür hukuki bildirimi veya uyuşmazlığı satıcı açısından doğru beyan etmek zarar güvencesi oluşturmaz mı oluşturmaz bilemeyeceği için bile “bilinen riskler” olarak listelenmelidir; gizlemenin bedeli sonradan ağır gelebilir.

Alan adından farklı mobil uygulama mağazası hesapları, sosyal medya kutlamaları veya harici kampanya araçları aynı anda devredilmek istendiğinde farklı doğrulama akışları gerektirdiğinden tarih sırasına göre ayrılır ve her biri teslim paketinde küçük parçalar olarak tanımlanır.

Alan adına bağlı yapılmış ama ticari olarak ayrışır lisansların (yüksek çözünürlüklü kitaplıklar veya ticari bileşen setleri) süresinin devredilebilmesi kritik olduğundan, lisans sözleşmesinde üçüncü kişiye devrine izin var mı sorusunun cevabı araştırılmalıdır. Devir yasak ise eşdeğer yedekleme kodu yerleştirmek gerekebilir; bu doğrudan fiyat görüşünü etkileyen iş kalemini oluşturur.

Kapanış teslim paketi ve arşiv doğrulanması

El sıkışılır sıkışılmaz tüm sırları vermek isteyen heyecanı ve aksine her şeyi son ana bıraktıran temkin iki uç yanlışı da önlenebilir kontrol tablosuna göre yaklaşım gerektirir. Tablodaki sıra genelde şöyle özelleştirilir: önce şeffaf doğrulama ve kısmen okunur erişim, sonra kritik sırlara ve süresiz yetkilere geçiş, en sonda tarih işlenmiş olarak arşive kapanış. Böyle yapılmış bir çerçeve hem dolandırıcılığı zorlaştırır hem profesyonelliği yükseltir.

Teslim arşivleri (yedek sıkıştırması, yapı çizimi, sırlı değişken listesi şifreli klasör iki parçalı gibi örneklerle) tarih işaretleriyle saklanır; alıcı ileriki denetimde “ne geldiği” hususunu ispat etmek için bu arşivi korur.

Satıcı teslim ettikten sonra destek bağlılığı sınırsız ise gerçek dünyada sık sık çıkmaza girer; sınırlı süre için makul yan destek yazılı taahhütlere bağlanır. Süre dolunca bildirilen kanallardan iletişim kesilir ve alıcı kendi üçüncü tarafından devam etmeyi planlar.

Uzun vadeli izleme ve yeniden denetim

Devrettikten sonra haftalık olarak nameserver doğrulanması ve önemli uçların (giriş, ödeme) erişimi raporları geçilir; özellikle eski CDN veya güvenlik eklentilerinin tesadüfen kendi IP aralığında yaşamaya devam ettiği karmaşık yapılarda yanlış yönlendirme geç bile farkedilebilir. Bu yüzden ilk 90 günde sık daha sonra seyrekleşen gözden geçirme takvimi oluşturmak doğru bir yaklaşımdır.

Alan adına bağlı yapılmış harici bildirimler (Google Search Console, Bing Webmaster) veya doğrulanmış kurumsal e-postalar eski doğrulama süreleriyle uyumsuz kalabilir ve bu da sıralama ve teslim garantilerini etkiler. Alıcı, bu bildirimi yeniden alırken sıra ve kanıtlama adımlarını planlamalıdır; satıcı geçiş sonrasında gerekliyse kimlik doğrulama sırasına yardım etme konusunda önceden sınırlarını bildirmeli.

Çok fazla teslim çıktısını paralel zamanlayıcılar için hazırlamak zor ise bu metni satıcı veya alıcı dışından bağımsız bir moderatörle paylaşıp adımların tarafsız doğrulanmasını istemek tarafları koruyabilir. Bu yaklaşım özellikle yüksek rakamlı süreçlerde pratiktir ve platform dışı tam ödeme riskini dengelemenin araçlarından biridir.

Sık hatırlar ve uygulanabilir kontrol listesi

Pratik sahada sık sık yaşanan tuzakların başında registrar panelinde doğru hesapta olunmayı düşünmeden bağlantılı e-postanın eski kutuda kalması gelir; bu da doğrulama mesajında ve yenilemede sık sık sıkışma üretir. Bir diğeri, transfer kilidinin yanlış arayüzde kapatılıp sanki güvenliği açılmış gibi yapılmasıdır; yüz yüze veya görüntülü doğrulanmayan kritik kutucukların sonradan çıktığı süreçlerde geri dönmek pahalı olur.

Yayınlanabilir teslim sırasında önerilen sıra tipik olarak şöyledir: sözleşme imzası veya en azından maddelerin kilidi, ardından alan doğrulanabilir doğrulukta veya paralel doğrulanabilir teslim araçları, DNS ve ana uç tesliminden önce sırları kademeli açmak, teslim çıktılarının tarih işaretlemesi ve yazılı teslim bildirimi, en sonda ise destek bağlılığı sınırlarının yazılı kapatılması. Bu sıranın özelleştirilmiş hâllerini her proje gerektirdiği süre için tabloya bağlamanın faydası büyük olur çünkü her iki taraf da “bir sonraki adım” meselesinden kaçamaz.

Uyum ve ölçüm tarafında çerez bildirimi, üçüncü parti etiketler ve sunucu taraflı kayıtların devri çoğu zaman yazılı teslim taslağına sonradan eklenmiş gibi yaşanır ve bu yüzden KVKK veya yurtdışı denetimi konu olan siteler için risk artar; bu kısmı daha önce yazmak satıcı açısından da “bir şey gizliyor” izlenimini düşürür. Yedek kod ve depo çıkışı aynı sırayla alıcıyla paylaşıldığından emin olun; çünkü domain erişimi oldu halde doğru dalların çıkmaması çok uzun araştırma süreci gerektiren anlaşmazlıkları tetikliyor.

Son olarak, zamanlanmış bildirimi ve uyarıcıları doğru kişisel veya iş hesaplarına bağlamanın unutulduğu sık sık yaşanır; eski güvenilir telefonların devre dışı kalması yüzünden uzantının süresinin dolması gibi zararların önüne geçildiğinden emin olun. Bu metin hukuki bir danışma belgesi değildir; ancak teslim sırasında açık yazılı süreç yürütmeyi profesyonelliğin gereği olarak kullanmak anlaşmazlık olasılığını küçültür.

Çok bölgeli ekipler kullanılıyorsa sahip “tek kişilik” doğrulanma yerine yazılı atanmış yetkililer belirlemek gereksiz tekrarı azaltır. Belge çıktılarının sıra tarihi teslim sırasında tutulunca alıcı ilerisi için “elimizde böyle yazılmıştı” noktasını daha kolay doğrular. Satıcı taraflı geç tarih bildirilmiş riskler daha sonra daha sert şekilde sorgulanabildiği için erken çıplak yazımı her iki tarafın da çıkarına olur.

Staging ve gerçek üretim yan yana yaşarken sırları karışık teslim etmek üretimi bozabileceği gibi sırları deşifreye yaklaştığı için de gereksizdir; bu yüzden hangi sırrın hangi ortamda yaşayacağı ayrılır ve rotasyon listesi tarih sıralı oluşturulur. Küçük hataları çabuk yakalamak için devir sonrası ilk haftanın “kayıt ve tepki günlükleri” çıktılarını paylaşımı da birçok teslim çıktılarını bir araya getirdiğinden faydası doğar.

Uzun vadeli bakım bağlılığı sınırlanınca sık sık çıkan yanlış beklenti, “aynı anda her şeye destek çıkılması” hissiydi; teslim bildirilen kapsamlar daha az şikâyet çıkarır. Son cümleyi doğrudan teslim sırasına yazdığınızda hem alıcı uçların sahipliği netleşmiş olur hem de satıcı taraf daha az “hayalet talep” duyar.

Alan adına bağlı sertifikalar otomatik olarak yenilenip yenilenemediği, hangi araçların hangi sırayla sıfırdan oluşturulacağı özellikle çok subdomain taşıdığını söyleyen yazılımlarda yüksek sıçrama üretiyor çünkü bir alt alan doğrulanmayı beklerken bütün geçerlilik tarihleri sıkışabiliyor; bu yüzden takvim tarih çıktılarını teslim sırasına doğrudan koymak faydadır.

Kapanış sırasında ekran çıktılarını paylaşımı ve sıra sıra kaydı tutmuş olmak, “bir adım doğrulanamadığında” daha az hararetli süreç yürütür; doğrulanamaz adımla birlikte dış uzman seçmesi gerekiyorsa tarih sırasına göre daha da erken bildirilir hâle getirin. Bu yaklaşım transfer ve DNS adımlarının birbirine sık sık yaklaşımını da daha okunabilir kılar.