Ajanslar İçin DNS ve Alan Adı Erişimi Yönetimi

Ajanslar İçin DNS ve Alan Adı Erişimi Neden Kritik Bir Konu?

Bir ajans olarak onlarca hatta yüzlerce müşterinin web sitesi, e-posta altyapısı ve kampanya landing sayfalarından sorumlu olduğunuzda, teknik olarak en kırılgan noktalardan biri DNS ve alan adı erişimi oluyor. Kreatif süreçler, içerik üretimi ve performans raporları ön planda olduğu için, DNS genellikle “son dakikada dokunulan” bir alan olarak kalıyor. Ancak yanlış yapılandırılmış bir DNS kaydı, süresi geçen bir alan adı ya da kaybolmuş bir giriş bilgisi; büyük kampanyaların yayına girememesine, e-posta trafiğinin durmasına ve markanın gözünde ajansın güvenilirliğinin ciddi şekilde zedelenmesine yol açabiliyor.

Biz DCHost olarak ajanslardan en çok şu tür hikâyeleri duyuyoruz: “Eski müşteri temsilcisi ayrıldı, alan adı şifresi onda kalmıştı”, “Müşteri kendi alan adını bir yerde almış ama nerede olduğunu kimse bilmiyor”, “Eski ajans DNS kayıtlarını karışık bırakmış, dokunmaya korkuyoruz.” Tüm bu sorunların ortak noktası, standartlaştırılmamış erişim modeli ve yetersiz dokümantasyon. Bu yazıda, özellikle ajanslar için DNS ve alan adı erişimini nasıl güvenli, tekrar edilebilir ve denetlenebilir hale getirebileceğinizi; müşteri hesaplarına nasıl güvenli yetki vereceğinizi ve tüm süreci nasıl belgelendirmeniz gerektiğini adım adım anlatacağız.

Amacımız, bir kere kurduktan sonra yeni her müşteri için kopyalayabileceğiniz, ajans ölçeğiniz büyüdükçe de bozulmadan çalışmaya devam eden pratik bir model ortaya koymak. Böylece hem teknik ekipleriniz rahat eder hem de müşteri gözünde “altyapısını bilen, dokunmaya cesaret eden ajans” konumuna yerleşirsiniz.

Alan Adı ve DNS Erişim Modelleri: Temel Stratejiyi Doğru Kurmak

Öncelikle ajansların tipik olarak karşısına çıkan üç ana erişim modelini netleştirelim. Her bir modelin avantajları ve riskleri farklı; doğru strateji genellikle bu modellerin kontrollü bir kombinasyonu oluyor.

1) Müşterinin Alan Adı Hesabına Doğrudan Giriş (Klasik, Riskli Yol)

En yaygın senaryo şu: Müşteri, alan adını yıllar önce bir yerden almıştır; kullanıcı adı ve şifreyi ajansa gönderir; ajans DNS kayıtlarını düzenler ve sonra o bilgiler e-posta arşivlerinin bir yerinde kaybolur. Bu modelin bazı avantajları olsa da (hemen iş yapabilme, ek hesap açma derdi olmaması), ajans ölçeği büyüdükçe ciddi riskler oluşur:

• Şifre paylaşımı: Ajans içinde birden fazla kişi aynı kullanıcı adı/şifre ile giriş yapar. Kimin ne zaman ne yaptığı takip edilemez.
• Çıkış süreçleri: Ekipten ayrılan bir çalışan, müşterinin alan adı hesabına erişmeye devam edebilir.
• Denetlenebilirlik yok: Hangi gün hangi DNS kaydı kim tarafından değiştirildi, izlemek zordur.
• Güven kırılması riski: Müşteri, alan adının “tamamen ajansın elinde” olduğunu düşünür ve bu, güven ilişkisini zedeleyebilir.

Bu model, küçük ölçekli ve kısa süreli projelerde işleri hızlı başlatmak için işe yarayabilir; ancak orta ve büyük ajanslarda sürdürülebilir değildir.

2) Ajans Hesabında Alan Adı Barındırma (Merkezi Ama Sahiplik Riskli)

İkinci modelde ajans, alan adını kendi hesabından satın alır veya transfer eder; tüm yönetim ajansın hesabındadır. Müşteri adına yeni domain açmak, DNS’i yapılandırmak, sertifika almak gibi işlemler ajans için oldukça rahattır. Ancak burada da kritik iki soru ortaya çıkar:

• Fatura ve mülkiyet: Alan adı kimin adına kayıtlı? Müşteri mi, ajans mı? Mukavelelerde bu net mi?
• Ajans–müşteri ilişkisi sona erdiğinde: alan adı transfer süreci nasıl işleyecek, ücretleri kim ödeyecek, ne kadar sürede devredilecek?

Bu model, özellikle uzun soluklu müşterilerde ve ajansın “altyapı partneri” olarak konumlandığı ilişkilerde mantıklı olabilir. Ancak mutlaka sözleşme ve süreç tarafı sağlamlaştırılmalıdır. Örneğin, alan adının mülkiyetinin her zaman müşteriye ait olduğunu, ajansın sadece teknik yönetim hakkına sahip olduğunu açıkça belirten maddeler kullanılabilir.

3) Karma Model: Müşteri Hesabında Sahiplik, Ajans Tarafında DNS Yönetimi

Bizim ajanslar için en sağlıklı bulduğumuz model genellikle şu:

• Alan adı, müşterinin kendi hesabında ve kendi fatura bilgileriyle kayıtlı olur.
• Nameserver’lar, ajansın yönettiği DNS altyapısına (DCHost DNS veya ajansın tercih ettiği profesyonel DNS çözümü) yönlendirilir.
• Ajans, sadece DNS yönetim katmanına erişir; alan adının mülkiyetine değil.

Böylece:

• Müşteri, alan adının sahibi olmaya devam eder.
• Ajans, DNS kayıtları üzerinde hızlı ve esnek çalışır (yeni sunucuya geçiş, e-posta servis değişimi, kampanya alt alan adları vb.).
• Erişim seviyesi net ayrılmış olur: “Mülkiyet” müşteride, “operasyonel yönetim” ajans tarafındadır.

Bu modelin nameserver stratejisi, TTL ayarları ve yedeklilik tarafını daha derinlemesine anlamak için, ad sunucusu seçimi ve stratejilerini anlattığımız rehbere mutlaka göz atmanızı öneririz.

Güvenli Erişim Tasarımı: Kim, Neye, Ne Kadar Süreyle Ulaşabilmeli?

Modeli seçtikten sonra, ikinci kritik adım erişim rollerini ve minimum yetki prensibini (least privilege) doğru kurmaktır. Temel hedef: Kim ne yapıyorsa, sadece ona yetecek kadar yetki sahibi olsun.

Ajans İçindeki Roller ve Yetki Seviyeleri

Tipik bir dijital ajans yapısını düşünelim: Hesap yöneticileri, proje yöneticileri, geliştiriciler, sistem yöneticileri, içerik editörleri, kampanya uzmanları… Tüm bu kişiler aynı DNS veya alan adı hesabına tam yetkili erişirse, uzun vadede insan hatası kaçınılmaz hale gelir. Sağlıklı bir model şöyle olabilir:

• DNS Yöneticisi / DevOps: Tüm DNS kayıtlarını okuma/yazma; nameserver değişikliği, zone oluşturma, yedek alma gibi kritik yetkiler.
• Geliştirici / Teknik Ekip: Belirli alan adlarında A, AAAA, CNAME, TXT gibi kayıtları güncelleme; ancak domain transferi veya nameserver değiştirme yetkisi olmaması.
• Hesap Yöneticisi / Proje Yöneticisi: Sadece okuma ve durum görüntüleme; müşteriye raporlama için.
• Stajyer / Junior Personel: Sadece test ortamları için sınırlı yetkiler; canlı alan adlarına erişim yok.

Bu ayrımı desteklemek için kullandığınız DNS ve hosting altyapısında alt kullanıcı, rol bazlı yetki ve loglama özellikleri olup olmadığını mutlaka değerlendirin. DCHost tarafında, ajans müşterilerimizle birlikte bu yetki modelini planlayarak; hangi ekip üyesinin hangi panellere hangi seviyede erişmesi gerektiğini birlikte kurguluyoruz.

Müşteri Hesabına Erişim: Şifre Değil, Yetki İstemek

Modern güvenlik yaklaşımı, “müşteriden kullanıcı adı/şifre istemek” yerine; alt kullanıcı veya yetkilendirme mekanizmaları üzerinden erişim almayı önerir. Örneğin:

• Müşteriden, panelinde “teknik kullanıcı” veya “ajans kullanıcısı” oluşturarak size ayrı bir kullanıcı tanımlamasını istemek.
• Bu kullanıcıya, sadece gerekli olan modüllere (DNS yönetimi, nameserver değişimi vb.) yetki verilmesini sağlamak.
• İki faktörlü doğrulamayı (2FA) müşterinin kendi ana hesabında bırakmak; ajans hesabında ise gerekirse ajans içi SSO veya şifre kasası (password manager) kullanmak.

Bu sayede şifreler e-posta veya WhatsApp üzerinden dolaşmaz, müşteri hesabı üzerindeki tam kontrol müşteride kalır, ajans sadece gerçekten ihtiyaç duyduğu alanlara erişir.

DNS Panelini Ajans Tarafına Taşımak: Nameserver Değişimi

Karma modelde sık yaptığımız şeylerden biri de şu: Müşteriye ait alan adı, müşterinin registrar hesabında kalır; ancak nameserver kayıtları, ajansın yönetebildiği DNS altyapısına yönlendirilir. Örneğin:

• Alan adının NS kayıtları, DCHost üzerindeki DNS sunucularına yönlendirilir.
• DNS kayıtlarının (A, AAAA, MX, TXT, CNAME, SRV, CAA vb.) tamamı, ajansın erişebildiği tek bir merkezden yönetilir.
• Yeni sunucuya geçiş veya e-posta altyapısı değişikliği gerektiğinde, her seferinde müşteriden panel bilgisi istemek zorunda kalınmaz.

DNS kayıt türleri ve hangi kaydın ne işe yaradığını anlamak için; ajans ekiplerinizi mutlaka DNS kayıtlarını A’dan Z’ye anlattığımız rehber ile eğitmeyi düşünebilirsiniz. DNS temelleri sağlam olan ekipler, değişiklikleri hem daha hızlı hem de daha güvenli uygular.

Dokümantasyon: Ajansın Hayatını Kurtaran Görünmez Katman

Güvenli erişim sadece doğru yetki vermekle bitmiyor; en az onun kadar önemli olan şey, tüm alan adları ve DNS değişiklikleri için sistematik bir dokümantasyon tutmak. İyi dokümantasyonun pratikte sağladığı faydalar:

• Yeni bir ekip üyesi geldiğinde, müşterinin alan adı altyapısını anlamak için günlerce e-posta arşivini taramak zorunda kalmaz.
• Gece bir kesinti yaşandığında, “kim neyi bozdu” tartışması yerine, değişiklik loguna bakıp doğrudan geri dönüş yapılabilir.
• Müşteri tarafındaki IT ekibi değiştiğinde bile, ajansın elinde teknik gerçekliği gösteren güncel bir kayıt bulunur.

Asgari Düzeyde Olması Gereken Doküman Seti

Ajansınız için pratik, ama güçlü bir dokümantasyon seti şöyle olabilir:

• Alan Adı Envanteri: Her müşteri için aşağıdaki bilgileri içeren bir tablo:
  • Alan adı
  • Registrar (kayıt kuruluşu) adı
  • Domain kimin adına kayıtlı (şirket unvanı)
  • Nameserver’lar
  • DNS’in nerede yönetildiği (DCHost paneli, başka bir DNS servisi vb.)
  • SSL sertifika durumu ve yenileme tarihleri
  • Alan adı bitiş tarihi ve yenileme sorumlusu
• Erişim Matrisi: Hangi müşteri için hangi panellere kimlerin erişimi olduğunu gösteren bir çizelge (kişiye özel hesaplar, rol ve yetki seviyesi).
• Değişiklik Logu: Her DNS değişikliği için tarih, yapan kişi, yapılan işlem, önceki ve yeni değer, gerekçe ve varsa ilgili ticket numarasını içeren kayıt.
• Runbook’lar: “Yeni site yayına alma”, “Sunucu taşıma”, “E-posta altyapısını değiştirme” gibi sık yaptığınız işler için adım adım prosedürler.

Alan adı envanteri ve portföyü büyüyen ajanslar için, bu süreci nasıl ölçekleyebileceğinizi alan adı portföy yönetimi rehberimizde detaylı anlattık. Oradaki prensipleri ajans ölçeğine uyarlayarak, 20–30 müşteriden sonra bile kontrolü kaybetmeyen bir yapı kurabilirsiniz.

Dokümantasyonu Nerede Tutmalı? (Not: Sadece Excel Yetmez)

İlk adımda bir tablo (Google Sheets, Excel, Notion vb.) ile başlamak doğal; ancak bir noktadan sonra merkezi ve denetlenebilir bir sisteme ihtiyaç duyarsınız. Önerdiğimiz yaklaşım:

• Alan adı envanteri ve erişim matrisi gibi “statik” bilgileri, herkesin güncelleyebildiği ama değişiklik geçmişinin tutulduğu bir ortamda saklamak.
• DNS değişiklik loglarını, ajans içi ticket sistemi veya proje yönetim aracı üzerinden takip etmek (her DNS değişikliğinin karşılığında bir görev/ticket olsun).
• Kritik zone dosyalarının (DNS yapılandırmalarının) düzenli arşivlerini alıp, mümkünse versiyon kontrollü bir depoda (Git repo vb.) saklamak.

Böylece hem değişikliklerin izini sürebilir hem de gerektiğinde “rollback” (geri alma) yapabilirsiniz. DNSSEC, Registrar Lock, Whois gizliliği ve 2FA gibi güvenlik ayarlarının da düzenli aralıklarla gözden geçirilmesi için, bir kontrol listesi hazırlamakta fayda var. Bunun için alan adı güvenliği rehberimizdeki checklisti ajans süreçlerinize entegre edebilirsiniz.

Operasyonel Süreçler: Onboarding, Değişiklik Yönetimi ve Offboarding

Teknik modeli ve dokümantasyonu belirledikten sonra, hepsini bir araya getiren şey operasyonel süreçler oluyor. Özellikle ajanslar için üç kritik süreç var: Yeni müşteri kazanımı (onboarding), devam eden değişiklikler ve ilişki sonlandığında ayrılma (offboarding).

Yeni Müşteri Onboarding: İlk Gün Yapılması Gerekenler

Yeni bir müşteriyle çalışmaya başladığınızda, daha ilk haftada şu adımları atmanız işleri yıllarca kolaylaştırır:

1. Alan Adı Durum Analizi: Müşterinin hangi alan adlarına sahip olduğunu, hangi TLD’lerde (örneğin .com, .com.tr, .io vb.) yayın yaptığını netleştirin. Gerekirse, marka koruması için ek domain önerilerini de içeren küçük bir rapor hazırlayın.
2. Registrar ve DNS Haritası: Her domain’in nerede kayıtlı olduğunu, DNS’ini kimin yönettiğini, nameserver’ların ne olduğunu çıkarın.
3. Erişim Modelini Kararlaştırın: Müşteriyle birlikte, yukarıda anlattığımız üç modelden hangisinin seçileceğine karar verin (müşteri hesabına yetki, ajans hesabında domain, karma model).
4. Yetki Talebi: Şifre istemek yerine, müşteriden ajans için ayrı kullanıcı oluşturmasını ve gerekli yetkileri tanımlamasını isteyin.
5. Envanter ve Dokümantasyon Kaydı: Tüm bu bilgileri ajansınızın alan adı envanterine işleyin; erişim matrisi ve güvenlik checklist’lerini doldurun.

Bu süreci standart bir “onboarding formu” ile desteklemek, hem teknik ekiplerin yükünü hafifletir hem de müşteri gözünde ajansınızın kurumsallığını güçlendirir.

DNS Değişiklik Yönetimi: Her Değişiklik Küçük Bir Projedir

DNS tarafında yapılan her değişiklik, ne kadar küçük görünürse görünsün, canlı trafiği etkileyebilir. Bu yüzden ajans içinde küçük ama etkili bir değişiklik yönetimi süreci kurgulamak gerekir:

• Her değişiklik için ticket/görev açılması (kim istedi, neden istedi, hedef tarih nedir?).
• Değişiklikten önce ilgili kayıtların eski değerlerinin not edilmesi (gerekirse ekran görüntüsü veya zone export).
• Özellikle IP veya MX değişikliklerinde, TTL stratejisi belirlenmesi (önce TTL düşür, sonra değişiklik yap, sonra tekrar yükselt gibi). Bu konuda sıfır kesintiyle DNS taşıma için TTL rehberimiz size pratik bir oyun planı sunuyor.
• Değişiklik sonrası temel kontrollerin yapılması: DNS lookup, HTTP/HTTPS erişimi, e-posta testleri vb.
• Tüm adımların değişiklik loguna işlenmesi.

Bu yaklaşım, özellikle yoğun kampanya dönemlerinde (Black Friday, lansman haftaları, TV reklamı öncesi) hayat kurtarır. Planlı DNS değişiklikleri sayesinde, yayında “sürpriz” yaşama ihtimaliniz ciddi oranda azalır.

Offboarding: Müşteri Ayrılırken Köprüleri Yakmamak

Ajans–müşteri ilişkisi sonsuza kadar sürmeyebilir; önemli olan ilişkiden nasıl çıktığınız. DNS ve alan adı tarafında temiz bir offboarding süreci, markanızın itibarını korur:

• Müşteriyle, alan adlarının durumunu (mülkiyet, yenileme tarihleri, nameserver’lar) netleştiren kısa bir rapor paylaşın.
• Eğer alan adları ajans hesabınızda ise, transfer sürecini (EPP kodu, transfer kilidi kaldırma vb.) planlı ve dokümante şekilde yürütün. Bu konuda alan adı transfer rehberimizdeki adımları takip edebilirsiniz.
• Müşterinin DNS yönetimi başka bir ajansa veya kendi IT ekibine devredilecekse, mevcut zone dosyalarının export’unu ve kısa bir teknik notu (hangi kayıt ne işe yarıyor) teslim edin.
• Ajans içi erişimleri kapatın: İlgili tüm alt kullanıcıları, API anahtarlarını ve SSH anahtarlarını iptal ettiğinizden emin olun.

Bu yaklaşım, müşteriden ayrılırken bile “bu ajans işini düzgün yapıyor” algısını güçlendirir ve gelecekte farklı bir projede yolların yeniden kesişmesinin önünü açar.

DCHost ile DNS ve Alan Adı Altyapısını Merkezi ve Güvenli Yönetmek

Ajanslar için en büyük zorluklardan biri, altyapının çok parçalı hale gelmesidir: Bazı siteler paylaşımlı hosting’te, bazıları VPS’te, bazıları özel sunucuda; DNS kimi zaman registrar’da, kimi zaman farklı bir servis sağlayıcıda. Biz DCHost olarak ajanslarla çalışırken mümkün olduğunca merkezî, ama esnek bir mimari kurmaya odaklanıyoruz.

Örneğin:

• Kritik müşteriler için performans ve izolasyon ihtiyacına göre VPS veya dedicated sunucu çözümleriyle birlikte, tüm DNS kayıtlarını tek bir noktadan yöneteceğiniz bir yapı tasarlıyoruz.
• Daha küçük hacimli projeler için, paylaşımlı hosting ve reseller hosting altyapısını kullanarak, ajansın tüm sitelerini tek panelden izlemesini sağlıyoruz.
• Yüksek trafik veya özel güvenlik gereksinimi olan projelerde, colocation ve özel ağ tasarımlarıyla DNS–sunucu–CDN zincirini baştan sona planlıyoruz.

Bu mimarinin en önemli parçası, DNS erişim ve dokümantasyon modelinin baştan beraber kurgulanması. Ajans ekiplerinizle yaptığımız teknik planlama toplantılarında, hangi sitenin hangi sunucuda, hangi alan adının hangi nameserver’da, hangi kayıtların hangi ortama işaret ettiğini netleştiriyoruz. Özellikle çok bölgeli, çok dilli ve çok alan adlı yapılarda; çok dilli kurumsal siteler için domain ve hosting mimarisi rehberimizde paylaştığımız prensipleri uygulayarak karışıklığı en baştan engelliyoruz.

Ajansların iç süreçleri iyi olduğunda, üstüne kurulan altyapı da çok daha sürdürülebilir hale geliyor. Teknik tarafta biz DCHost olarak, siz de iç süreç ve dokümantasyon tarafında üzerine düşeni yaptığınızda; DNS ve alan adı erişimi, “kriz anında panik olunan” bir konu olmaktan çıkıp, kontrolünüz altında, tahmin edilebilir bir alana dönüşüyor.

Sonuç ve Yol Haritası: Ajansınız İçin Uygulanabilir Bir Model Kurun

DNS ve alan adı yönetimi, ajansların çoğunda “en sıkıntı çıkan ama en az konuşulan” başlıklardan biri. Müşteri tarafındaki dağınık hesaplar, ekip içi şifre paylaşımları, dokümante edilmemiş değişiklikler ve plansız offboarding süreçleri bir araya geldiğinde; küçük bir DNS kaydı değişikliği bile gecenizi gündüzünüze katabiliyor.

Bu yazıda anlattığımız çerçeveyi özetlersek:

• Önce erişim modelinizi seçin: Müşteri hesabına doğrudan girmek yerine, mümkün olduğunca yetki bazlı, rol ayrımlı bir yapı kurun.
• Alan adlarının mülkiyetini müşteride bırakıp, DNS yönetimini ajans tarafında topladığınız karma modeli gözden geçirin.
• Tüm alan adları ve DNS kayıtları için envanter, erişim matrisi ve değişiklik logu tutmayı ajans kültürünüzün parçası haline getirin.
• Onboarding, değişiklik yönetimi ve offboarding süreçlerini yazılı hale getirip, her yeni müşteri ve her yeni ekip üyesi için tekrar tekrar kullanın.
• Güvenlik tarafında DNSSEC, registrar lock, 2FA ve TTL stratejisi gibi konuları checklist’lerinize ekleyin.

Eğer ajansınız için “DNS ve alan adı tarafını baştan aşağı toparlayalım, merkezi ve ölçeklenebilir bir altyapı kuralım” diyorsanız; DCHost ekibi olarak sizinle teknik bir keşif toplantısı yapmaktan memnuniyet duyarız. Birlikte hem hosting (paylaşımlı, VPS, dedicated, colocation) altyapınızı hem de DNS erişim ve dokümantasyon modelinizi gözden geçirip; ajansınıza yıllarca rahat ettirecek bir yol haritası çıkarabiliriz. Böylece bir sonraki büyük kampanyada, aklınız kreatifte ve sonuçlarda olur; altyapı tarafı sessizce, sorunsuzca çalışmaya devam eder.