Alan adı yönetimi dört işten oluşur: adın yenilenmesi, kayıt şirketindeki iletişim ve ödeme bilgilerinin güncel tutulması, DNS kayıtlarının doğru çalışması ve adın başka bir kayıt şirketine taşınabilmesi için gereken kilit ile kodun korunması. Biri aksarsa site, e-posta ve arama görünürlüğü aynı anda etkilenebilir. Sitenizin adını bir kayıt şirketinden kiralıyor ve bu işleri bir tasarımcıya ya da ajansa bırakmış durumdaysanız, hangi işin hangi panelde yapıldığını bilmek her şeyden önce gelir. Bir alan adı uyuşmazlığı yaşıyorsanız kayıt şirketinizin kurallarına ve yetkili kuruma başvurun; uyuşmazlık süreçleri bu konunun dışındadır.
Üç rol: kayıt sahibi, kayıt şirketi ve kayıt otoritesi
Bir alan adının arkasında üç taraf bulunur. Kayıt sahibi, adı kendi adına kiralayan sizsiniz. Kayıt şirketi, adı sizin adınıza uzantının kayıtlarını tutan kuruluşa ileten ve müşteri panelini sunan firmadır. Kayıt otoritesi ise uzantının (.com, .net gibi) kayıtlarını tutan kuruluştur. Bu ayrım, yönetim sırasında kime başvuracağınızı belirler. Yenileme, iletişim bilgisi ve transfer işlemlerinde muhatabınız kayıt şirketidir; kayıt otoritesine doğrudan başvurmazsınız.
ICANN, kayıt sahiplerinin hak ve yükümlülüklerini Registrants' Benefits and Responsibilities (yeni sekmede açılır) sayfasında listeler. Sayfaya göre kaydınız ICANN akredite bir kayıt şirketiyle yapılan bir Kayıt Sözleşmesi kapsamında olmalıdır, bu sözleşmeyi istediğiniz zaman inceleyip bir kopyasını saklayabilirsiniz ve alan adının kaydından ve kullanımından yalnızca siz sorumlusunuz. Sayfa ayrıca kayıt şirketlerinin yanıltıcı bildirimlerle ya da gizli ücretlerle yönlendirme yapmamasını bekler.
Hesabın sahibi kim olmalı
Bir ajansa ya da web tasarımcısına alan adı aldırdıysanız, kayıt sahibi alanında kimin adının yazdığına bakın. Uygulama önerisi: adı işletmenin kendi adına ve işletmenin kontrol ettiği bir e-posta adresine bağlayın. Kişisel bir e-posta adresi kapanırsa yenileme uyarıları ve transfer onayları da boşa gider.
Kime hangi iş sorulur
Üç rolü bir telefon rehberi gibi düşünün. Tablo: Rol, görevi ve ne zaman muhatap olacağınız.
| Rol | Görevi | Ne zaman muhatap olursunuz |
|---|---|---|
| Kayıt sahibi (siz) | Adı kiralar, bilgileri doğru ve güncel tutar | Her yenilemede ve her bilgi değişikliğinde |
| Kayıt şirketi | Kaydı sizin adınıza iletir, paneli ve desteği sunar | Yenileme, geri yükleme, kilit ve kod işlerinde |
| Kayıt otoritesi | Uzantının kayıtlarını tutar | Doğrudan muhatap olmazsınız, kayıt şirketiniz sizin adınıza yazışır |
Uygulama önerisi: bu üç satırı belgeleme sayfanıza ekleyin ve kayıt şirketinizin destek kanalını (e-posta ya da form) not edin. Acil durumda kime yazacağınızı aramak değerli zamanı alır.
Uzantı ve marka adı kararları yönetimden önce verilir
Hangi uzantıyı seçeceğinizi tartışan .com.tr mi .com mu yazısı ile adın aramalarda başka markalarla çakışmasını inceleyen marka adı seçimi yazısı, buradaki yönetim işlerinden önce verilen kararları anlatır. Yönetim, ad seçildikten ve kaydedildikten sonra başlar. Ülke uzantılarının kendi kayıt kuralları olabilir ve bunlar bu konunun dışındadır; uzantınızın resmi belgelerine ve kayıt şirketinizin sözleşmesine bakın.
Yönetim dediğimiz işler ve kimin sorumlu olduğu
Dağınık görünen işler dört başlığa iner. Tablo: Yönetim işleri, yapıldıkları yer ve aksama sonucu.
| İş | Yapıldığı yer | Aksarsa ne olur |
|---|---|---|
| Yenileme ve ödeme | Kayıt şirketi paneli | Ad süre sonuna girer, site ve e-posta etkilenebilir |
| İletişim bilgisi | Kayıt şirketi paneli | Uyarılar ve doğrulama mesajları ulaşmaz |
| DNS kayıtları | Kayıt şirketi ya da DNS barındıran hizmet | Site veya e-posta yanlış adrese gider |
| Transfer kilidi ve kod | Kayıt şirketi paneli | Taşıma yapılamaz ya da istenmeyen taşıma riski doğar |
Dikkat çeken nokta, DNS kayıtlarının her zaman alan adını aldığınız yerde yönetilmeyebilmesidir. Barındırma şirketiniz ya da ayrı bir DNS hizmeti kayıtları tutuyorsa, kayıt şirketinde yalnızca hangi ad sunucularının kullanılacağı yazılıdır. Bir değişikliği yanlış panelde yapmak etkisiz kalır. İlk yönetim görevi, kayıtların hangi panelde tutulduğunu öğrenmektir.
ICANN sayfasının kayıt sahibine yüklediği sorumluluklar
Aynı ICANN sayfasında sorumluluklar da sayılır. Her biri günlük yönetime karşılık gelir.
- Kayıt şirketinin yayımladığı şartlara, ilgili kayıt şirketi, kayıt otoritesi ve ICANN politikalarına uymak.
- Kayıt şirketinin güncel Kayıt Sözleşmesini ve onda yapılan değişiklikleri gözden geçirmek.
- WHOIS gibi dizinlerde yayımlanan bilgileri doğru vermek ve bu bilgiler değiştiğinde zamanında güncellemek.
- Kayıt şirketinin sorularına on beş gün içinde yanıt vermek.
- Kayıt şirketindeki hesap bilgilerini güncel tutmak. Otomatik yenilemeyi seçtiyseniz ödeme bilgilerini de güncel tutmak.
Listedeki on beş günlük yanıt süresi, yönetimi bir ihmal alanı olmaktan çıkarır: kayıt şirketinden gelen bir doğrulama sorusu, kayıtlı adresiniz okunmadığı için yanıtsız kalırsa yükümlülük sizin tarafınızda aksamış olur. Sayfada süre sonu aşamalarının ayrıntısı yoktur; o ayrıntı kayıt şirketinizin kendi belgelerinde bulunur.
Yenileme ve ödeme bilgileri
Otomatik yenileme, ödeme bilgisi geçerli olduğu sürece işe yarar. Son kullanma tarihi geçmiş ya da kapatılmış bir kartla yenileme başarısız olur ve bunu kimse fark etmeyebilir. Kayıt şirketinden gelen hatırlatma e-postaları da kayıtlı adrese gider; adres artık okunmuyorsa uyarı kaybolur.
Sürenin dolduğu günden sonra ne olduğu kayıt şirketine ve uzantıya göre değişir. Başkasının bırakmış olduğu adı satın almanın risklerini süresi dolmuş alan adlarının backlink risklerini anlatan yazıda bulabilirsiniz. Burada anlatılan ise kendi adınızı kaçırmanın sonucudur: adı edinecek taraf başkası olabilir.
Yenileme için üç emniyet katmanı
- Otomatik yenilemeyi açın ve ödeme yöntemini yılda bir kez kontrol edin.
- Hatırlatmaların gideceği e-posta adresini iki kişinin okuyabildiği bir adres yapın.
- Süre sonundan önce bir kontrol tarihi koyun. Süre sonu tarihini kayıt şirketi panelinden okuyun, tahmin etmeyin.
Yenileme başarısız olduğunda ilk adımlar
Uygulama önerisi: ödeme hatası ya da süre sonu uyarısı gördüğünüz gün şu sırayı izleyin. Önce kayıt şirketi panelinde alan adının durumunu ve süre sonu tarihini okuyun. Sonra ödeme yöntemini güncelleyip yenilemeyi elle başlatın. Yenileme işlendiyse yeni süre sonu tarihini panelden teyit edin. İşlenmediyse destek ekibine alan adını ve hata mesajını yazın. Bu sırada sitenizin ve e-postanızın çalışıp çalışmadığını ayrıca denemeyi unutmayın; panelde ad etkin görünse bile DNS tarafında bir sorun bulunabilir.
Süre sonu ve geri alma aşamalarına genel bakış
Alan adı yenilenmezse bir anda herkesin alabileceği hale gelmez; kayıt sistemlerinde kullanılan EPP protokolü için yazılmış RFC 3915 (yeni sekmede açılır) belirli aşamalar tanımlar. Belge bu aşamaların sürelerini sabitlemez. Süre, kayıt otoritesinin işletme politikasına bırakılır. Bir kaynakta okuduğunuz gün sayısı bu nedenle sizin uzantınız ve kayıt şirketiniz için geçerli olmayabilir. Tablo: RFC 3915 durum değerleri ve anlamları.
| Durum | RFC 3915'e göre anlamı |
|---|---|
| addPeriod | Alan adının ilk kaydından sonra tanınan dönem. Kayıt şirketi bu dönemde silerse kayıt otoritesi kayıt bedelini kayıt şirketine iade eder |
| autoRenewPeriod | Kayıt süresi dolup kayıt otoritesi adı otomatik yenilediğinde başlar. Bu dönemde silme yenileme bedelinin iadesine yol açar |
| renewPeriod | Kayıt şirketi adı açıkça yeniledikten sonraki dönem |
| transferPeriod | Adın yeni bir kayıt şirketine başarıyla taşınmasından sonraki dönem |
| redemptionPeriod | Silme komutu işlendikten sonra, kalıcı silinmeden önce; ad geri yüklenebilir ve silme iptal edilebilir |
| pendingRestore | Geri alma döneminde başlatılan geri yükleme işleminin sürdüğü durum |
| pendingDelete | Geri alma dönemi bittikten sonra adın temizleme sürecinde olduğu durum |
Geri yükleme isteğini yalnızca adın kayıt şirketi gönderebilir. Siz kayıt şirketinizden talep edersiniz; kayıt şirketi kayıt otoritesine geri yükleme isteği ve ardından bir rapor iletir. Geri alma dönemi geri yükleme olmadan biterse ad kalıcı silinme aşamasına geçer, temizlendikten sonra yeniden kaydedilebilir hale gelir. Yönetim açısından sonuç şudur: süre sonunun ilk günlerinde müdahale etmek, ilerleyen aşamalarda müdahale etmekten daha kolay olur, çünkü sonraki aşamalarda işlemi yalnızca kayıt şirketiniz yürütebilir ve ek ücret söz konusu olabilir. Ücretlerin ve sürelerin nasıl işlediği kayıt şirketinizin sözleşmesinde yazar.
Transfer kilidi ve yetkilendirme kodu
Alan adını başka bir kayıt şirketine taşımak istediğinizde iki şey devreye girer: kilit ve yetkilendirme kodu. ICANN Transfer Policy (yeni sekmede açılır) sayfasına göre kayıt şirketi, alan adı sahibine kendi yetkilendirme kodunu üretme ve ClientTransferProhibited durumunu kaldırma imkanı sunmuyorsa, ilk talepten itibaren beş takvim günü içinde kodu vermek zorundadır. Kilit yönetimini kayıt şirketinin panelinde kendiniz yapabiliyorsanız bu beş günü beklemenize gerek kalmaz.
Politika, kayıt şirketinin transferi reddedebileceği durumları da sayar: sahtecilik kanıtı, alan adı sahibinin ya da yönetim kişisinin kimliği konusunda makul bir uyuşmazlık, önceki kayıt dönemi için ödeme yapılmaması, yetkili transfer kişisinin açık itirazı, alan adının oluşturulmasından sonraki altmış gün içinde talep edilmesi ve önceki bir transferden sonraki altmış gün içinde talep edilmesi. Ayrıca devam eden UDRP ya da URS işlemleri, mahkeme kararları, TDRP uyuşmazlıkları ve kayıt sahibi değişikliğinden sonraki altmış günlük kilit için reddetme zorunluluğu getirilir. ICANN sayfası güncellenmiş bir sürümün de yayımlandığını belirtir; uygulamadan önce güncel metne bakın.
Taşıma sırasında alan adının DNS ayarlarını korumak için hosting değişikliğinde DNS geçişini anlatan yazıdaki mantık yol gösterir.
Kayıt sahibi değişikliğinden sonraki altmış gün
ICANN politikasına göre kayıt sahibinin adında, kuruluşunda ya da e-posta adresinde esaslı bir değişiklik yapıldığında kayıt şirketi hem yeni hem önceki kayıt sahibinden güvenli bir yolla onay alır ve her ikisine bildirim gönderir; değişiklik, onayların alınmasından sonra bir gün içinde işleme konur. Değişiklikten sonra altmış günlük bir transfer kilidi uygulanır. Kayıt şirketi kayıt sahibine bu kilitten önceden vazgeçme seçeneği tanıyabilir, ancak bu tercih kayıt sahibi değişikliği talebinden önce yapılmalıdır. Politika, önceki kayıt sahibine kayıt sahibi değişikliğinden önce kayıt şirketleri arası transferi talep etmesini önerir; böylece kilit tetiklenmez. Ajanstan işletmeye ya da bir sahipten diğerine devir planlıyorsanız bu sıra önemlidir.
Kod ve kilidin saklanması
Kod, adınızın kontrolünü devretmeye yarayan bir anahtardır. E-posta yazışmasında, ortak bir dokümanda ya da ekran görüntüsünde bırakmayın. İşiniz bitince kilidin yeniden açık olduğunu panelden doğrulayın.
DNS: adı adrese bağlayan katman
MDN sözlüğünde (yeni sekmede açılır) DNS, alan adlarının ve bunlarla ilişkili kaynakların (IP adresleri gibi) listesini tutan hiyerarşik ve merkezsiz bir adlandırma sistemi olarak tanımlanır. En belirgin görevi, insanın okuyabileceği adı sayısal bir IP adresine çevirmektir; bu eşlemeye DNS sorgusu denir. Tarayıcı önce bu eşlemeyi yapabilmelidir. DNS yanlışsa sunucu sağlam çalışsa bile ziyaretçi siteye ulaşamaz. Günlük yönetimde dört kaydın rolünü bilmek yeterlidir.
Tablo: Dört kayıt türünün rolü ve yönetimde dikkat edilecek nokta.
| Kayıt | Rol | Yönetimde dikkat edilecek nokta |
|---|---|---|
| A | Adı bir IP adresine bağlar | Hosting değişince adres güncellenir |
| CNAME | Bir adı başka bir adın takma adı yapar | Hedef ad doğru olmalı |
| MX | E-posta sunucusunu gösterir | Yanlışlıkla silinirse e-posta ulaşmaz |
| TXT | Doğrulama ve gönderici bilgisi taşır | Silinen doğrulama kaydı mülk doğrulamasını bozabilir |
Ad sunucusu ile DNS kaydı aynı şey değildir
Ad sunucuları, alan adınızın kayıtlarının tutulduğu sunuculardır; kayıt şirketinde yalnızca bu sunucuların adları yazılır. A, MX ve TXT gibi kayıtlar ise o sunucularda durur. Ad sunucusunu değiştirmek, bütün kayıt listesini başka bir yere devretmek demektir. Kayıtları yeni yerde yeniden girmediyseniz site ve e-posta yönlenmesi kaybolur. Uygulama önerisi: ad sunucusu değişikliğini ayrı bir iş olarak planlayın, kayıt listesini önceden alın ve değişiklikten sonra site, e-posta ve doğrulama kayıtlarını tek tek deneyin.
Barındırma değiştirirken DNS önbelleği ve TTL
Google'ın Site moves without URL changes (yeni sekmede açılır) sayfası, DNS ayarlarının internet servis sağlayıcıları tarafından belirlenen TTL (Time to Live) değerine göre önbelleğe alındığını yazar. Sayfa, yeni ayarların daha çabuk ulaşması için TTL'yi taşımadan en az bir hafta önce temkinli bir değere, örneğin birkaç saate çekmeyi önerir. Taşımanın, kayıtları yeni barındırma sağlayıcısına yönlendirmekle başladığı; eski sunucunun ise ona gelen trafik sıfıra inene kadar kapatılmaması gerektiği de yazılıdır. Taşımadan hemen sonra Googlebot tarama hızında geçici bir düşüş görülmesinin normal olduğu, ardından birkaç gün içinde istikrarlı bir artış beklendiği belirtilir. Google belgelerindeki öneriler değişebilir; uygulamadan önce güncel sayfaya bakın.
Sahiplik doğrulaması ve DNS kaydı
Search Console'da alan adı mülkünü kullanıyorsanız doğrulama DNS üzerinden yapılır. Google'ın Verify your site ownership (yeni sekmede açılır) sayfası, doğrulanmış kalmak için DNS kaydını doğrulama başarılı olsa bile sağlayıcınızdan silmemenizi söyler. Doğrulama artık teyit edilemezse bildirim alırsınız; sorun giderilmezse o mülk üzerindeki izinler belirli bir ek süre sonunda sona erer. Elle eklenen bir DNS kaydının sağlayıcı tarafından yayına alınması iki üç günü bulabilir. DNS temizliği yaparken bilinmeyen TXT kayıtlarını körlemesine silmeyin. Alan adı mülkü ile URL öneki mülkü arasındaki fark için Search Console mülk türü yazısına bakın.
Karar kuralı: tek çatı mı, ayrı hesaplar mı
Alan adı, barındırma ve e-posta aynı şirketteyse yönetim kolaydır ama tek bir hesap tüm işi taşır. Üçü ayrı şirketlerdeyse her hesabın kurtarma yolu ayrı yönetilmelidir. Uygulama önerisi: alan adı kaydını hosting şirketinizden bağımsız bir yerde tutmak, hosting sorun çıkardığında adın kontrolünü elinizde bırakır. Küçük bir ekip ayrı hesapları takip edemeyecekse tek çatı daha güvenli olabilir. Her iki durumda da kayıt sahibi bilgisi işletme adına olmalı ve en az iki kişinin kurtarma yolu bulunmalıdır. Tablo: Duruma göre öneri.
| Durum | Öneri |
|---|---|
| Bir kişi hepsini yönetiyor | Tek çatı, ama ikinci bir yönetici ekleyin |
| Hosting ajansta, alan adı sizde | DNS değişikliklerini yazılı isteyin, kayıt listesini saklayın |
| Alan adı ajansın hesabında | Hesap devri ya da erişim talep edin |
| Hosting değişimi yakın | TTL değerini düşürün, kayıtları dışa aktarın |
Örnek senaryo: üç odalı bir pansiyon
Örnek senaryo: Bir pansiyon sahibi, sitesini ve rezervasyon formunu bir tasarımcıya yaptırıyor. Alan adı tasarımcının kişisel hesabında kayıtlı. Bir yıl sonra tasarımcının e-posta adresi kapanıyor ve yenileme hatırlatmaları kimseye ulaşmıyor. Pansiyon sahibi panele girmeye çalıştığında hesabın başkasına ait olduğunu fark ediyor.
Çözüm sırası şöyledir. Önce tasarımcıyla iletişim kurulup hesap erişimi ya da alan adının işletmenin hesabına devri istenir. Sonra kayıt sahibi bilgisi işletme adıyla güncellenir; bu değişiklik altmış günlük transfer kilidini tetikleyebileceği için kayıt şirketine önceden sorulur. Ardından otomatik yenileme açılır ve hatırlatmalar iki kişiye gider. Son adımda DNS kayıtlarının listesi alınıp bir dosyaya kaydedilir; ileride bir hata olursa kayıtlar yeniden kurulabilir.
Senaryodan çıkan ders
Sorun teknik değil, sahiplik ve iletişim kaynaklıdır. Rezervasyon formu çalışıyor olsa bile hesap erişimi kaybedilmişse tek bir yenileme kaçırması siteyi ve işletmenin e-postasını durdurabilir.
Yıllık bakım takvimi
Takvim işi parçalara böler. Tarihleri kendi süre sonunuza göre ayarlayın. Tablo: Yıllık alan adı bakım takvimi.
| Zaman | Kontrol |
|---|---|
| Süre sonundan yaklaşık iki ay önce | Ödeme yöntemini ve otomatik yenilemeyi doğrulayın |
| Süre sonundan bir ay önce | Hatırlatma e-postalarının ulaştığını panelden teyit edin |
| Yenilemeden sonra | Yeni süre sonu tarihini panelden okuyun |
| Altı ayda bir | İletişim bilgilerini, kilit durumunu ve DNS kayıt listesini gözden geçirin |
| Hosting ya da e-posta sağlayıcısı değişmeden önce | TTL değerini düşürün, kayıtları dışa aktarın |
Uygulama önerisi: yenileme ve ödeme için iki ayrı görev açın. Ödeme başarılı olsa bile yenilemenin gerçekten işlendiğini panelde görmek ayrı bir kontroldür.
Belirtiden nedene: bir şey ters gittiğinde
Alan adı kaynaklı sorunlar benzer belirtilerle ortaya çıkar, ama nedenleri farklı katmanlardadır. Doğru katmana hızlı gitmek, panelde yanlış ayar yapıp durumu kötüleştirmenizi önler.
Site açılmıyor
Önce adın hâlâ sizin hesabınızda ve geçerli olduğunu panelden doğrulayın. Süre sonu geçmişse ilk iş yenileme ya da geri yükleme seçeneklerini kayıt şirketinden sormaktır. Süre sorunsuzsa DNS kaydına bakın: A kaydı doğru IP adresini gösteriyor mu, ad sunucuları beklediğiniz sağlayıcıya mı ait? Bu iki soru yanıtlandıktan sonra sorun barındırma tarafındaysa hosting şirketinize gidin. Sırayı karıştırmak, barındırma şirketiyle saatlerce yazışıp asıl nedenin süre sonu olduğunu geç fark etmek demektir.
E-posta gelmiyor ya da gönderilemiyor
MX kayıtları e-posta sunucusunu gösterir. Bir DNS temizliği sırasında yanlışlıkla silinmişse ya da ad sunucuları değiştirilirken yeni sağlayıcıda kayıtlar yeniden girilmediyse e-posta ulaşmaz. İş e-postası alan adına bağlıysa, alan adı sorunu aynı zamanda iletişim sorunudur. Bu nedenle ad sunucularını değiştirmeden önce mevcut tüm kayıtların, yalnızca web sitesine ait olanların değil, bir listesini almak gerekir.
Panele giremiyorsunuz
Kayıt şirketi hesabının şifresi ya da e-posta adresi elinizde yoksa kurtarma için kayıt şirketinin kimlik doğrulama sürecini izlemeniz gerekir. Bu süreç şirketten şirkete değişir ve ayrıntısı o şirketin belgelerindedir. Uygulama önerisi: hesaba iki yönetici ekleyin ve kurtarma bilgilerini yılda bir kez deneyin.
Kayıtta beklenmedik bir değişiklik var
DNS kayıtlarında sizin yapmadığınız bir değişiklik görürseniz önce kayıt listesini aldığınız eski dosyayla karşılaştırın. Değişiklik ekipten birinin ya da ajansın işiyse yazılı gerekçesini isteyin. Kimse yapmadıysa hesap şifresini değiştirin, iki aşamalı doğrulamayı açın ve kayıt şirketinin destek ekibine bildirin. Transfer kilidi kapanmış, yetkilendirme kodu istenmiş ya da kayıt sahibi bilgisi değişmişse bu daha ciddi bir işarettir; önce hesabı ve kilidi güvenceye alın. Tablo: Belirti, ilk bakılacak yer ve ikinci adım.
| Belirti | İlk bakılacak yer | İkinci adım |
|---|---|---|
| Site açılmıyor | Süre sonu ve alan adı durumu | A kaydı ve ad sunucuları |
| E-posta gelmiyor | MX kayıtları | Ad sunucusu değişikliği oldu mu |
| Search Console doğrulaması düştü | TXT ya da CNAME doğrulama kaydı | Kayıt silinmiş mi, yanlış panelde mi |
| Taşıma başlamıyor | Transfer kilidi | Yetkilendirme kodu ve kayıt sahibi değişikliği |
| Uyarı e-postaları gelmiyor | Kayıtlı iletişim adresi | Spam klasörü ve alan adı filtreleri |
Hizmet sağlayıcıyla yazışırken
Destek ekibine yazarken alan adını, etkilenen hizmeti (site, e-posta ya da ikisi), sorunun başladığı tarihi ve yapılmış son değişikliği belirtin. Bu dört bilgi, ilk yanıtın genel bir şablon yerine sorunu çözen bir yönlendirme olma ihtimalini artırır. Ekran görüntüsü gönderirken yetkilendirme kodu, ödeme bilgisi ve şifre görünmesin.
Belgeleme ve devir teslim
Yönetimi sürdürülebilir kılan şey, tek bir kişinin hafızası yerine kâğıda dökülmüş bilgidir. Küçük bir işletme için bir sayfa yeterlidir. Sayfada şunlar bulunmalıdır: kayıt şirketinin adı ve giriş adresi, hesap sahibinin ve ikinci yöneticinin adı, süre sonu tarihi, ad sunucularının listesi, her DNS kaydının ne işe yaradığı, silinmemesi gereken doğrulama kayıtları ve en son kontrol tarihi. DNS'te bir şey değiştiğinde tarih ve gerekçeyle birlikte eklenir.
İşi bir ajansa, yeni bir çalışana ya da bir satın alıcıya devrederken bu sayfayı teslim edin. Teslim sırasında kayıt sahibi bilgisinin değişmesi gerekiyorsa, ICANN politikasındaki kayıt sahibi değişikliği sonrası altmış günlük kilit kuralını hatırlayın ve kayıt şirketinizin işleyişini önceden sorun.
Değişiklik günlüğü nasıl tutulur
Günlük basit bir tablo olabilir. Her satır bir değişikliği kaydeder ve geriye dönüş kolaylaşır. Tablo: Örnek günlük sütunları.
| Tarih | Kim yaptı | Ne değişti | Neden | Sonraki kontrol |
|---|---|---|---|---|
| Değişiklik günü | Ad ve rol | Kayıt türü, eski ve yeni değer | Gerekçe | Site, e-posta ve doğrulama denemesi |
Günlüğü kayıt listesinin yanında saklayın. Kayıt şirketinden gelen bildirimleri de aynı yere ekleyin; ileride bir itiraz ya da devir olursa tarihli kanıt elinizde olur.
İki göz kuralı
Uygulama önerisi: DNS ya da ad sunucusu değişikliklerini, e-postayı ve siteyi etkileyebileceği için, iki kişiyle yapın. Biri değişikliği uygular, diğeri öncesi ve sonrası kayıt listesini karşılaştırır. Küçük bir ekipte bu iki kişi tasarımcı ile işletme sahibi olabilir.
Sağlayıcı değişikliği öncesi dışa aktarım
Ad sunucularını bir DNS hizmetinden diğerine taşımadan önce mevcut bölge dosyasını ya da kayıt listesini dışa aktarın. Kayıt türü, ad, değer ve TTL sütunlarıyla bir tablo hazırlayın. Yeni sağlayıcıya girdikten sonra aynı tabloyu referans alarak tek tek karşılaştırın. Aksi halde unutulan bir MX ya da TXT kaydı günler sonra fark edilir.
Kontrol listesi
- Kayıt sahibi alanında işletmenin adı yazıyor.
- Hatırlatmalar iki kişinin okuduğu bir adrese gidiyor.
- Otomatik yenileme açık ve ödeme yöntemi güncel.
- Süre sonu tarihi panelden okundu ve takvimde.
- Transfer kilidi açık, yetkilendirme kodu güvende.
- DNS kayıtlarının hangi panelde tutulduğu biliniyor ve kayıtlar dışa aktarıldı.
- Silinmemesi gereken doğrulama kayıtlarının listesi var.
- Hosting değişikliği planlanıyorsa TTL düşürüldü.
Listeyi yılda bir kez, süre sonu tarihinden önce baştan sona okuyun. Tek bir madde bile işaretlenemiyorsa, onu kimin ne zamana kadar kapatacağını aynı not dosyasına yazın. Maddesi eksik kalan liste, ancak bir sorun çıktığında fark edilen bir boşluğu gösterir.
Sık Sorulan Sorular
Alan adını kayıt şirketinden mi, hosting şirketinden mi almalıyım?
Her ikisi de mümkündür. Önemli olan, kayıt sahibi bilgisinin işletme adına olması ve yenileme uyarılarının sizin okuduğunuz bir adrese gitmesidir. Ayrı tutmak hosting sorunlarında esneklik sağlar, tek çatı ise takibi kolaylaştırır.
Otomatik yenileme açıksa ayrıca bir şey yapmam gerekir mi?
Evet. ICANN sayfası, otomatik yenilemeyi seçtiyseniz ödeme bilgilerinizin güncel kalması gerektiğini yazar. Yenilemenin gerçekten işlendiğini panelden süre sonu tarihine bakarak teyit edin.
İletişim bilgilerimi neden güncel tutmalıyım?
ICANN sayfası, WHOIS gibi dizinlerde yayımlanan bilgileri doğru vermenizi ve değişince güncellemenizi, kayıt şirketinin sorularına on beş gün içinde yanıt vermenizi sorumluluk olarak yazar. Uyarılar ve doğrulamalar da bu adreslere gelir.
DNS kaydını nerede değiştireceğimi nasıl anlarım?
Kayıt şirketi panelinde alan adının hangi ad sunucularını kullandığına bakın. Ad sunucuları barındırma şirketinize aitse kayıtları orada, kayıt şirketinize aitse kayıt şirketi panelinde değiştirirsiniz.
Transfer kilidi neden önemli?
Kilit açıkken adın başka bir kayıt şirketine taşınması engellenir. Taşıma yapmayacağınız sürece kilidi açık tutmak istenmeyen taşıma riskini azaltır. Politikanın ayrıntıları için ICANN sayfasına ve kayıt şirketinizin yönergesine bakın.
Yenileme için kaç gün süre var?
RFC 3915 aşama sürelerini belirlemez, her kayıt otoritesinin işletme politikasına bırakır. Süre kayıt şirketine ve uzantıya göre değişir; kendi panelinizdeki ve sözleşmenizdeki kuralı okuyun.
Alan adı yönetimi SEO'yu etkiler mi?
Site erişilemez olursa, DNS yanlış olursa ya da doğrulama kayıtları silinirse ziyaretçi erişimi ve Search Console mülk doğrulaması etkilenebilir. Bu bir sıralama vaadi değil, erişilebilirlik koşuludur.
Sonuç
Alan adı yönetimi; rolleri tanımak, yenilemeyi güvenceye almak, DNS kayıtlarının nerede tutulduğunu bilmek ve transfer kilidi ile kodu korumak demektir. Bunların hiçbiri bir kerelik iş değildir; yıllık bir takvime bağlandığında sürpriz olmaktan çıkar. Kayıt sahibi ve iletişim bilgilerini işletme adına çevirmek, hatırlatmaları iki kişiye yönlendirmek ve DNS kayıtlarını dışa aktarmak en hızlı üç iyileştirmedir. Süre sonu, transfer ve DNS ayrıntıları kayıt şirketinize ve uzantıya göre değişir.
Alan adınız hazırsa ve içerik yayınlamaya geçmek istiyorsanız, tanıtım yazısı hizmetimizle sitenizi bağlam içinde tanıtan yazılar yayımlatabilirsiniz.
Yorum Yaz
Yorum yapabilmek için giriş yapmalısınız. Giriş Yap