Alan Adı ve Hosting Sahipliği Rehberi: WHOIS’ten Fatura Ünvanına Mülkiyeti Doğru Kurmak

Alan adı ve hosting sahipliğini yanlış kurmanın gerçek bedeli

DCHost tarafında yıllardır gördüğümüz en can sıkıcı vakalar, performans sorunları değil; yanlış kurgulanmış alan adı ve hosting sahipliği yüzünden siteyi, e‑postayı hatta markanın ana domain’ini kaybetme noktasına gelen işletmeler. Teknik olarak her şey yolunda olsa bile, WHOIS’te yanlış kişi, faturada yanlış ünvan, yanlış panelde yanlış yetkilendirme derken kontrol yavaş yavaş elinizden kayabiliyor.

Bir proje planlama toplantısında sunucu mimarisini, yedeklemeyi, ölçeklenmeyi konuşurken çoğu zaman en kritik soruyu en sona bırakıyoruz: “Bu alan adı ve hosting hukuken kimin?” Çoğu işletmede net bir cevap yok. Domain ajansın üzerinde, hosting başka bir firmanın hesabında, yönetim erişimleri eski bir çalışanda, fatura ise tamamen alakasız bir şahıs firması adına kesilmiş olabiliyor.

Bu rehberde; alan adı ve hosting sahipliğini başından itibaren doğru kurmanız için adım adım ilerleyeceğiz. WHOIS kaydının ne anlama geldiğini, fatura ünvanının hukuki etkisini, ajans–müşteri ilişkilerinde ideal modeli, çalışan değişimlerinde erişim devrini ve şirket birleşme/ayrılmalarında nelere dikkat etmeniz gerektiğini konuşacağız. Amacımız, projeleriniz büyüdükçe sizi geriden vurmayan, şeffaf ve denetlenebilir bir mülkiyet yapısı kurmanıza yardımcı olmak.

Alan adı sahipliği: WHOIS kaydını gerçekten doğru okumak

Birçok kişi için WHOIS kaydı, “domain’i nereden almışız ona bakarım” seviyesinde kalıyor. Oysa WHOIS, alan adının hukuki ve teknik sahipliğini tarif eden çok katmanlı bir yapı.

WHOIS alanları: registrant, admin, tech ve billing rollerinin anlamı

Alan adınız için WHOIS kaydında tipik olarak şu roller bulunur:

• Registrant (Domain Holder / Sahip): Alan adının hukuki sahibi. İhtilaf, UDRP süreci, mahkeme, marka davası gibi durumlarda bakılan ilk kayıt budur.
• Admin Contact (Yönetici kişi): Genelde idari kararları veren, transfer onayı gibi kritik işlemleri yapabilen kişi/e‑posta.
• Tech Contact (Teknik kişi): DNS değişiklikleri, nameserver ayarları gibi teknik süreçlerde iletişim kişisi olarak kullanılır.
• Billing Contact (Faturalama): Ödeme, yenileme hatırlatmaları ve borç bildirimlerinin gittiği kişi/e‑posta.

Birçok işletmede bu roller ya tek bir kişide toplanıyor ya da tamamen karışık durumda: Registrant eski ortağın şahıs şirketi, admin ajansın info adresi, tech ise vaktiyle projeyi yapan freelancer’ın kişisel maili. Buradan çıkacak karışıklığın boyutunu tahmin etmek zor değil.

GDPR/KVKK sonrasında WHOIS ne kadar işe yarıyor?

Avrupa’daki GDPR ve Türkiye’deki KVKK sebebiyle birçok uzantıda WHOIS çıktılarında kişisel bilgiler maskeleniyor. Bu yüzden bazı yöneticiler “Zaten WHOIS gizli, çok da önemli değil” yanılgısına düşüyor.

Gerçekte olan şu:

• Kayıt operatörünün (registrar) veritabanında tam bilgileriniz yine tutuluyor.
• Uyuşmazlık, mahkeme, resmi yazışma gibi durumlarda bu bilgiler referans alınıyor.
• WHOIS’te maske olsa bile, panelinizdeki registrant bilgileri ileride hakkınızı ispat etmeniz için hayati.

Bu konuyu daha derinlemesine ele aldığımız WHOIS gizliliği, GDPR ve KVKK dengesini anlattığımız ayrıntılı rehber de mutlaka okunmalı.

Şirketler için ideal WHOIS mimarisi

Kurumsal bir yapıda hedefimiz; alan adının gerçek sahibi olan tüzel kişiliği netleştirmek ve kişiler değişse bile sürekliliği garanti altına almak olmalı. Pratik bir model:

• Registrant: Şirketin ticari unvanı (örneğin “Örnek Teknoloji A.Ş.”), vergi numarası ve resmi adres.
• Admin Contact: Kurumsal bir rol e‑postası (ör: [email protected]) ve yanında alan adı yönetiminden sorumlu pozisyon (IT yöneticisi, dijital pazarlama müdürü…).
• Tech Contact: IT ekibi veya DCHost üzerindeki teknik iletişim adresiniz.
• Billing Contact: [email protected] gibi yenileme maillerinin kaybolmayacağı kurumsal bir adres.

Burada kritik nokta; kişisel Gmail/Hotmail adresleri yerine şirket kontrolünde, rol bazlı e‑postalar kullanmak. Böylece çalışan ayrıldığında mail kutusu kapansa bile [email protected] erişimi kurumsal olarak yönetilmeye devam eder.

Ajans–müşteri ilişkilerinde domain kimin üstünde olmalı?

Ajanslar açısından en sık gördüğümüz hata, “müşteriyi uğraştırmayalım” diye tüm alan adlarını ajansın kendi adına kaydetmek. Bu kısa vadede işleri hızlandırsa da orta–uzun vadede bombaya dönüşüyor:

• Müşteri ajans değiştirmek istediğinde alan adını devralmak zorlaşıyor.
• Ajansın kapanması/iflası durumunda domain’e erişim kaybı yaşanabiliyor.
• Faturalama, marka tescili ve hukuki sahiplik birbirine karışıyor.

İdeal model şu:

• Alan adı sahibi (registrant): Her zaman son müşteri (marka/şirket) olmalı.
• Ajans; admin veya tech contact olarak eklenebilir, ayrıca domain paneline yetkili kullanıcı olarak tanımlanabilir.
• Ajans kendi içinde Reseller veya VPS altyapısı kullanıyorsa bile, hesap içinde açılan her domain için registrant müşterinin unvanı olarak girilmeli.

Bu modeli ayrıntılı anlattığımız ajanslar için DNS ve alan adı erişimi yönetimi kontrol listesi ajans tarafında çalışan herkes için iyi bir referans.

Fatura ünvanı, sözleşme ve gerçek mülkiyet ilişkisi

WHOIS tarafı bir ayak, fatura ve sözleşme tarafı ise diğer ayak. Birçok ihtilafta “Fatura kimin üzerine kesilmiş?” sorusu, en az WHOIS kadar belirleyici oluyor.

Alan adı ve hosting faturasında hangi ünvan geçmeli?

Temel prensip: Masrafı çeken kimse, mülkiyet de onundur varsayımını boşa çıkaracak bir durum istemiyoruz. Bunun için:

• Alan adı ve hosting; mümkünse son müşterinin ticari unvanı üzerine faturalandırılmalı.
• Ajans hizmet bedelini ayrıca kendi faturasıyla kesmeli (tasarım, yönetim, danışmanlık vb.).
• Şahıs şirketi ile kurumsal şirket ayrımında, ileride şirket ünvanı değişse bile ilişkilendirilebilecek açıklamalar fatura notlarında yer almalı.

Eğer domain’in WHOIS registrant kısmı “Ajans A.Ş.”, fatura ise “Müşteri B Ltd. Şti.” adına kesilmişse; olası bir anlaşmazlıkta her iki taraf da hak iddia edebilir. Bu gri alanları en baştan temizlemek çok daha sağlıklı.

Ajans, danışman veya çalışan üzerinden alınan domain’lerin riskleri

Gerçek vakalardan sıkça gördüğümüz riskli durumlar:

• Domain, projeyi yapan freelance yazılımcının kişisel hesabında kalıyor.
• Startup’ın alan adı başlangıçta kuruculardan birinin kendi adına, sonra şirket kurulduğunda devri hiç yapılmıyor.
• IT çalışanı şirket kartını kullanarak kendi hesabına domain/hosting alıyor, işten ayrıldığında erişim tamamen onun üzerinde kalıyor.

Bu durumlarda; marka büyüdükçe alan adının hukuki ve ticari değeri artıyor ve kişilerle şirket arasında gerilim oluşuyor. Çözüm:

1. Mevcut domain’ler için durum tespiti yapın (WHOIS, fatura, panel erişimleri).
2. Şirket adına alınmamış domain’ler için devir sözleşmesi ve faturalı satış ile resmiyet kazandırın.
3. Yeni alınacak tüm domain ve hostinglerde kurumsal satın alma prosedürü uygulayın (onay, ödeme, kayıt, dokümantasyon).

Marka tescili, alan adı ve fatura üçgenini hizalamak

Marka tesciliniz (Türk Patent vb.), alan adınız ve fatura ünvanınız uyumlu olursa, olası bir uyuşmazlıkta eliniz çok güçlenir. Özellikle jenerik ve değerli domain’ler için bu kritik.

• Marka tescili hangi şirket/kişi adına ise alan adının registrant alanını da aynı şekilde güncelleyin.
• Faturanın da yine aynı tüzel kişilik adına kesildiğinden emin olun.
• Bu üçlü (marka – domain – fatura) uyumluysa, üçüncü bir tarafın hak iddia etmesi çok zorlaşır.

Marka ve domain ihtilaflarının hukuki boyutuna ilgi duyuyorsanız, marka tescili ve alan adı ihtilaflarını hukuken ele aldığımız yazı da iyi bir tamamlayıcı olacaktır.

Hosting sahipliği: panel, sunucu ve erişim mimarisini netleştirmek

Alan adının kime ait olduğu kadar, hosting ve sunucu altyapısının kontrolü de önemli. Çoğu işletmede şu karışıklığı görüyoruz: Domain bir yerde, DNS başka yerde, hosting üçüncü firmada, e‑posta ise tamamen dördüncü bir altyapıda.

Domain paneli, hosting paneli, DNS ve sunucu: kim neye sahip?

Önce kavramları netleştirelim:

• Alan adı (domain): “firma.com” gibi adresin kendisi.
• DNS: Alan adını IP adreslerine çeviren kayıtlar (A, AAAA, MX, CNAME vb.).
• Hosting: Web sitenizin ve/veya e‑postanızın barındığı alan (paylaşımlı hosting, VPS, dedicated, colocation vb.).
• Kontrol panelleri: Domain paneli, cPanel/DirectAdmin/Plesk gibi hosting panelleri ve sunucu yönetim arabirimleri.

Bu ayrımı detaylı anlattığımız domain ve hosting arasındaki farkı adım adım anlattığımız yazı, özellikle teknik olmayan yöneticiler için iyi bir referans.

Sahiplik açısından bakınca:

• Domain paneli: Alan adının gerçekten kime ait olduğunu ve kimlerin transfer/dns değişikliği yapabileceğini belirler.
• Hosting paneli: Web sitesi dosyaları, veritabanları, e‑posta hesapları ve SSL gibi kritik ayarların yapıldığı yer.
• VPS/Dedicated/Colocation: İşletim sistemi, güvenlik duvarı, güncellemeler ve tüm servisler üzerinde tam yetki.

Prensip olarak, şirket varlığının bir parçası olan her kritik erişim (domain paneli, ana hosting hesabı, ana sunucu) şirket adına açılmış olmalı ve bireysel hesaplara mecbur kalmadıkça bağımlı olunmamalı.

Erişim paylaşırken mülkiyeti riske atmamak

Pratikte ajanslar, freelancer’lar, yazılımcılar ve sistem yöneticileriyle çalışmak zorundasınız. Bu kişilerle erişim paylaşırken şu modele dikkat edin:

• Domain ve hosting hesabı, şirketiniz adına DCHost’ta açılmış olsun.
• Mümkünse ana hesap şifresini vermek yerine, alt kullanıcı veya yetki bazlı erişim sağlayın (örneğin sadece DNS veya sadece FTP gibi).
• Tüm kritik panellerde iki faktörlü kimlik doğrulama (2FA) aktif olsun.
• Çalışma bittiğinde; yetkili kullanıcıyı kaldırın, 2FA cihazlarını sıfırlayın ve değişiklikleri kayıt altına alın.

Alan adı ve panel güvenliği tarafında ek önlemler için, alan adı güvenliği için registrar lock ve DNSSEC kullanımını anlattığımız rehbere mutlaka göz atın.

VPS, dedicated ve colocation tarafında sahiplik

Daha ileri seviyede; VPS, dedicated sunucu veya colocation gibi hizmetler kullanıyorsanız, burada da benzer prensipler geçerli:

• Sözleşme ve fatura şirketiniz adına olmalı.
• Sunucuya root/administrator erişimi şirket tarafından yönetilmeli; üçüncü kişilere kişisel hesaplarla değil yetkili erişimlerle (sudo, RDP user vb.) giriş imkanı verilmeli.
• Sunucu üzerinde çalışan tüm kritik servislerin (web, veritabanı, e‑posta) dokümantasyonu tutulmalı; “Bu servisi kim kurdu, şifresi nerede?” sorusu asla cevapsız kalmamalı.

DCHost tarafında ister paylaşımlı hosting, ister VPS/dedicated, ister colocation kullanıyor olun; sahiplik mimarisi doğru kurgulandığında, teknik ölçeklendirme adımlarını da çok daha güvenle planlayabiliyorsunuz.

Yıllardır gördüğümüz mülkiyet hatası senaryoları ve alınacak önlemler

Somutlaşması için sık karşılaştığımız birkaç senaryoyu paylaşmak faydalı olacak. Kendinizi hangi senaryoya daha yakın hissediyorsanız, önlemleri oradan başlayarak uygulayabilirsiniz.

Senaryo 1: Ajans ile yollar ayrılıyor, domain ajansın üstünde

Müşteri, ajansla çalışmayı bırakmak istiyor; ancak alan adı ajans adına kayıtlı. Ajans iyi niyetli olsa bile, domain devri için karmaşık bir bürokrasi başlıyor.

Önlem:

• Tüm mevcut domain’leri gözden geçirip registrant devrini müşteriye yapın.
• Yeni projelerde alan adını doğrudan müşteri adına DCHost üzerinden kayıt edin.
• Ajans erişimlerini admin/tech contact veya panel yetkilendirmesi üzerinden verin.

Senaryo 2: Yenileme maili eski çalışan adresine gidiyor, domain düşüyor

Şirketin alan adını ilk alan çalışan işten ayrılmış, WHOIS’te ve registrar hesabında hala onun kişisel e‑postası var. Yenileme hatırlatmaları oraya gidiyor, kimse fark etmiyor ve domain süresi doluyor.

Bu riski anlattığımız alan adı yenileme, grace ve redemption süreleri rehberi de çok kritik. Çünkü birçok uzantıda, süre dolduktan sonra geri alma maliyetleri ciddi şekilde artıyor.

Önlem:

• Tüm alan adlarınız için yetkili e‑posta adreslerini kurumsal role ([email protected]) çevirin.
• Yıllık yerine uzun dönemli (ör. 3–5 yıl) yenileme yapmayı düşünün.
• Yenileme takvimini şirket içinde ayrıca takip eden bir liste/araç kullanın.

Senaryo 3: Domain düşüyor, başkası kapıyor

Yenileme unutuluyor, grace ve redemption süreleri de geçiyor, domain tamamen düşüyor ve başka biri tarafından tescil ediliyor. Özellikle jenerik, kısa ve yüksek trafikli domain’lerde bu durum geri dönülemez bir kayıp anlamına geliyor.

Alan adı yaşam döngüsünü ve düşen domain süreçlerini detaylı anlattığımız alan adı yaşam döngüsü ve düşen domain yakalama rehberini de mutlaka okuyun.

Önlem:

• Tüm kritik domain’lerde otomatik yenileme ve güncel kredi kartı/ödeme metodu tanımlayın.
• DCHost panelinizden domainlerinizi tek ekranda görüp tarihlerini düzenli kontrol edin.
• Kritik marka alan adlarınız için defansif ek kayıtlar (.com, .com.tr, .net vb.) düşünün.

Senaryo 4: Domain bir kayıt firmasında, DNS başka yerde, kimse nereden başlayacağını bilmiyor

Şirket içinde “DNS’e kim bakıyor?” sorusuna net bir cevap yok. Domain bir yerden alınmış, DNS Cloud X’te, hosting başka bir sunucuda. Her sorun çıktığında herkes birbirine pas atıyor.

Önlem:

• Tüm alan adları için tek bir envanter dosyası hazırlayın: Nereden alınmış, DNS nerede, hosting nerede, kim yetkili?
• Yeni alınacak alan adları için mümkün olduğunca aynı sağlayıcı ve aynı DNS/hosting mimarisini tercih edin.
• Başka bir kayıt firmasındaki domain’i DCHost’a taşımak isterseniz, EPP kodu, DNS ve e‑postayı kesintisiz taşıma rehberimiz size adım adım yol gösterir.

Alan adı ve hosting sahipliği için pratik kontrol listesi

Kendi yapınızı hızlıca taramak için aşağıdaki listeyi kullanabilirsiniz:

• Tüm domain’ler için WHOIS’te registrant kısmı gerçekten şirket/son müşteri mi?
• Admin, tech ve billing e‑postaları kurumsal rol adresleri mi, yoksa kişisel mailler mi?
• Alan adı ve hosting faturaları şirket/son müşteri adına mı kesiliyor?
• Domain paneline kimler erişebiliyor? Erişimler kayıt altında mı, 2FA açık mı?
• cPanel/DirectAdmin/Plesk veya sunucu panellerine erişen tüm kişilerin güncel listesi var mı?
• Yıllık yenileme takviminiz, sorumlu kişi ve yedek sorumlu tanımlı mı?
• Ajans, freelancer veya dış ekiplerle çalışıyorsanız, erişim yetkileri iş bitince gözden geçiriliyor mu?

DCHost ile sağlıklı domain ve hosting sahipliği yapısı kurmak

Sağlıklı bir sahiplik yapısı kurmak teknikten çok organizasyonel bir konu gibi görünse de, doğru hosting ve domain altyapısı bu işi inanılmaz kolaylaştırıyor. DCHost olarak hem alan adı kaydı hem de paylaşımlı hosting, VPS, dedicated ve colocation hizmetlerini aynı çatı altında sunarken, şu prensiplerle çalışıyoruz:

• Hesabınız şirket/marka adına açılır, domain’leriniz doğrudan bu tüzel kişilik altında tutulur.
• Ajans veya danışmanlarla çalışıyorsanız, erişim yetkilerini güvenli ve izlenebilir şekilde kurgulamanız için size yol gösteririz.
• Kritik domain’lerinizde registrar lock, 2FA, güvenli DNS ve düzenli yenileme gibi önlemleri kurmanıza yardımcı oluruz.
• VPS/dedicated veya colocation kullandığınızda, sahiplik ve erişim hiyerarşisini nasıl tasarlamanız gerektiğini birlikte dokümante ederiz.

Alan adı, DNS, hosting ve sunucu mimariniz ne kadar büyürse büyüsün, sahiplik yapınız net ve şeffaf ise hiçbir kişi veya ajansa bağımlı kalmadan yolunuza devam edebilirsiniz. Bu rehberi bir başlangıç noktası olarak görüp, şirket içinde kısa bir envanter çalışması yapmanızı öneririm. Eksik ve riskli gördüğünüz alanları not alın; DCHost ekibi olarak, isterseniz bunları birlikte gözden geçirip hem teknik hem hukuki açıdan daha sağlam bir yapıya kavuşmanız için yanınızda oluruz.