DNS Kayıt Türleri: A, CNAME, MX ve TXT Ne İşe Yarar?

DNS kayıtları, alan adınızın hangi sunucuya, hangi e-posta sunucusuna ve hangi doğrulama bilgisine bağlı olduğunu söyleyen satırlardır. A kaydı adı bir IP adresine bağlar, CNAME bir adı başka bir adın takma adı yapar, MX e-postanın hangi sunucuya gideceğini gösterir, TXT ise Search Console doğrulaması gibi işlerde metin taşır. DNS panelini ilk kez açan bir site, blog ya da e-ticaret sahibiyseniz, her kaydın görevini bilmek yanlış satırı silip siteyi ya da e-postayı durdurma riskini azaltır. Alan adı kaydı, yenileme ve transfer süreçleri bu konunun dışındadır.

DNS kaydı nedir ve TTL ne anlama gelir

MDN sözlüğü (yeni sekmede açılır) DNS'i, alan adlarının ve onlarla ilişkili kaynakların (IP adresleri gibi) listesini tutan hiyerarşik ve merkezsiz bir adlandırma sistemi olarak tanımlar. En belirgin görevi insanın okuyabileceği adı sayısal bir IP adresine çevirmektir; bu eşlemeye DNS sorgusu denir. Kayıtların yapısı ise alan adı sisteminin temel belgesi olan RFC 1034 (yeni sekmede açılır) ile tanımlıdır.

RFC 1034'ün 3.6 bölümüne göre her kaynak kaydı beş parçadan oluşur. Tablo: Bir DNS kaydının beş alanı.

Panel etiketleri sağlayıcıya göre değişir; arayüzü Türkçe kullanıyorsanız etiket adları farklı görünebilir. TTL için RFC 1034 şunu söyler: bu alan, bir kaydın önbellekte ne kadar tutulabileceğine getirilen zaman sınırıdır; sıfır TTL önbelleğe almayı yasaklar ve değer, verinin kaynaklandığı bölgenin yöneticisi tarafından belirlenir. Yani TTL'yi siz ya da DNS barındıran hizmet belirler ve değiştirdiğinizde eski değeri önbelleğinde tutan çözümleyiciler süre dolana kadar eski cevabı verebilir.

Bir kaydı okumayı öğrenmek

Örnek bir satırı sütunlarına bölerek okuyun: kaydın hangi ada ait olduğu, hangi türde olduğu, ne kadar süre önbellekte kalabileceği ve neye işaret ettiği. Bu dört bilgiyi yüksek sesle söyleyebiliyorsanız o kaydı güvenle düzenleyebilirsiniz. Söyleyemiyorsanız, silmeden önce kaydın neye hizmet ettiğini sağlayıcıdan ya da kaydı ekleyen kişiden öğrenin.

Panele ilk girişte yapılacaklar

DNS panelini ilk kez açtığınızda hiçbir şeyi değiştirmeden başlayın. Önce kayıt listesinin tamamını görün, gerekirse sayfa sayfa kaydırın ve tümünü bir dosyaya kopyalayın ya da ekran görüntüsü alın. Sonra her satırın yanına kısa bir not yazın: bu kayıt site için, e-posta için, doğrulama için ya da bilinmiyor. Bilinmeyen satırları listeleyin ve sağlayıcınıza ya da siteyi kuran kişiye sorun. İlk beş dakikanın amacı düzenlemek değil, haritayı çıkarmaktır; çünkü harita olmadan yapılan her değişiklik tahmine dayanır.

Ad sunucusu, bölge ve çözümleyici

Kayıtlar, ad sunucularında tutulur. RFC 1034'e göre NS kaydı bir alanın yetkili ad sunucusunu gösterir ve NS kayıtları yalnızca bir bölgenin üst düğümünde bulunur. Belge her bölgenin en az iki sunucuda bulunmasını şart koşar. Çözümleyici ise uygulamalarla ad sunucuları arasında köprü kuran programdır ve yanıtları TTL süresince önbellekte tutar.

Bu bilgiyi günlük kullanıma çevirelim. Alan adını kayıt şirketinden almış, sitesini başka bir şirkette barındırıyor olabilirsiniz. Kayıtlarınız hangi ad sunucularında tutuluyorsa, düzenleme paneli o sunucuları işleten şirkettir. Kayıt şirketinde değiştirdiğiniz bir A kaydı, ad sunucuları barındırma şirketinde ise hiçbir şeyi değiştirmez. Alan adı yönetimi, ad sunucularının nerede olduğunu bilmekle başlar.

Panel etiketleri sözlüğü

Sağlayıcılar aynı alanlara farklı adlar verir. Arayüzü Türkçe kullanıyorsanız etiket adları farklı görünebilir. Tablo: Panelde karşılaşabileceğiniz etiketler ve karşılığı.

A kaydı: adı bir IP adresine bağlar

RFC 1034'te A kaydı, internet sınıfı için 32 bitlik bir IP adresi taşıyan kayıttır. Sitenizin ana adresini barındırma sunucusunun adresine bağlayan kayıt budur. Barındırma şirketini değiştirdiğinizde güncellenmesi gereken ilk kayıtlardan biri A kaydıdır; yeni şirket size yeni bir IP adresi verir ve siz eski adresin yerine yazarsınız. Bu kayıt yalnızca 32 bitlik adres taşır; IPv6 adresleri bu konunun dışındadır.

A kaydının günlük hayattaki karşılığı

Bir mağazanın sokak adresi gibi düşünün: ad değişmez ama binanın bulunduğu yer değişirse tabela yeni adresi göstermelidir. A kaydı tabeladır; taşınma gününde güncellenmezse müşteriler eski adrese gider. TTL bu yüzden önemlidir: yüksek TTL ile yayınlanmış bir kayıt, değişiklikten sonra bir süre eski adresi göstermeye devam edebilir.

CNAME kaydı: bir adı başka bir adın takma adı yapar

RFC 1034 CNAME kaydını, sahibi olan adı bir takma ad olarak tanımlayan kayıt biçiminde anlatır. Çözümleyici, sorguyu CNAME'in gösterdiği ad üzerinden yeniden başlatır. Belge CNAME zincirlerinin izlenmesini, döngülerin hata sayılmasını ve kayıtların takma ada değil asıl ada işaret etmesini önerir. En önemli kural şudur: bir düğümde CNAME varsa orada başka veri bulunmamalıdır. Bu kural, aynı ada hem CNAME hem MX kaydı koymanın sorun çıkaracağı anlamına gelir.

Uygulama önerisi: www gibi alt adlar için CNAME kullanmak, hosting sağlayıcısı size bir ad verdiğinde pratiktir; ana alan adının kendisi (apex) için ise aynı ada MX gibi başka kayıtlar da gerekeceğinden, sağlayıcınızın talimatına bakın. Her sağlayıcı bu kısıtı farklı çözer.

Zincir ve döngü

Bir CNAME başka bir CNAME'e işaret edebilir. RFC 1034 çözümleyicilerin zincirleri izlemesini, döngüleri ise hata saymasını söyler. Uygulamada zinciri kısa tutmak hata ayıklamayı kolaylaştırır. Siz de bir takma adın başka bir takma ada işaret etmesini, gerekmedikçe kurmayın. İki ad birbirine işaret ederse döngü oluşur ve ad çözülmez.

A ile CNAME arasında seçim

İki kayıt benzer iş görür ama farklı varsayımlara dayanır. Tablo: A ve CNAME'in karşılaştırması.

Karar kuralı

Sağlayıcınız size bir IP adresi verdiyse A, bir alan adı verdiyse CNAME kullanın. Verilen değeri değiştirmeyin; kopyalarken fazladan boşluk, nokta ya da protokol öneki eklememeye dikkat edin.

MX kaydı: e-postanın gideceği sunucuyu belirler

RFC 1034'e göre MX kaydı alan adı için bir posta değişim sunucusunu belirtir ve veri kısmı bir tercih sayısı ile bir sunucu adından oluşur; tercih sayısı ne kadar düşükse sunucu o kadar tercih edilir. Yani birden çok MX kaydı olabilir ve sıra bu sayılarla belirlenir. Alan adınızla e-posta kullanıyorsanız (info@siteniz.com gibi), MX kayıtları e-posta sağlayıcınızın verdiği sunuculara işaret etmelidir.

MX kaydında dikkat edilecek noktalar

• MX kaydı bir IP adresine değil, bir sunucu adına işaret eder.
• Sağlayıcınızın verdiği tercih sayılarını ve sunucu adlarını aynen girin.
• Eski sağlayıcının MX kayıtlarını, yenisi çalıştığını doğrulamadan silmeyin.
• Ad sunucusunu değiştirirken MX kayıtlarını da yeni yere taşıyın.

E-posta gönderici yetkisi için kullanılan SPF kaydının nasıl yazıldığını SPF kaydı rehberinde bulabilirsiniz. DKIM ve benzeri ayrıntılar da orada yer alır.

İki e-posta sağlayıcısı arasında geçiş

Uygulama önerisi: e-posta sağlayıcısını değiştiriyorsanız yeni sağlayıcının MX kayıtlarını, tercih sayısı eski sağlayıcınınkinden daha yüksek (yani daha az tercih edilen) olacak şekilde önce yeni sistemde hazır duruma getirin ve alıcı kutuların çalıştığını doğrulayın. Ardından eski sağlayıcının kayıtlarını silmeden önce tercih sırasını değiştirin. Geçişin tamamlandığını doğruladıktan sonra eski kayıtları kaldırın. RFC 1034, tercih sayısı düşük olanın daha çok tercih edildiğini yazar; sıra bu mantıkla yönetilir. Sağlayıcınızın kendi geçiş yönergesi bunun yerini alır.

Yazım hataları

DNS kayıtlarında küçük yazım hataları büyük kesintiye yol açabilir. Değeri kopyalarken başa ya da sona boşluk eklenmediğini, bir sunucu adının sonuna panelin gerektirdiği noktanın konup konmadığını ve IP adresinde bir sayı eksikliği olmadığını kontrol edin. Panel bir değeri otomatik olarak alan adınıza eklemiş olabilir; kayıt listesini kaydettikten sonra tam halini okuyun.

TXT kaydı ve Search Console doğrulaması

Google'ın Verify your site ownership (yeni sekmede açılır) sayfasına göre alan adı mülkü yalnızca alan adı sağlayıcısı yöntemiyle, yani bir TXT ya da CNAME kaydı ekleyerek doğrulanabilir. Bazı sağlayıcılar kaydı otomatik ekleyebilir; aksi halde DNS sağlayıcınızda elle eklersiniz. Sayfa, doğrulanmış kalmak için kaydı sağlayıcıdan silmemenizi söyler. Elle eklenen bir DNS kaydının sağlayıcı tarafından yayına alınması iki üç günü bulabilir; doğrulama başarısız olursa bir iki gün bekleyip yeniden deneyin.

TXT kayıtları başka işler için de kullanılır. Panelinizde tanımadığınız TXT kayıtları görürseniz silmeyin: bunlar farklı hizmetlerin doğrulama ya da gönderici bilgileri olabilir. Önce kimin eklediğini öğrenin. Alan adı mülkü ile URL öneki mülkü arasındaki farkı Search Console mülk türü yazısında bulabilirsiniz.

Doğrulama kaydını nasıl korursunuz

1. Kaydı eklediğiniz tarihi ve amacı bir tabloya yazın.
2. DNS temizliği yaparken "Search Console" gibi bir not alanı yoksa değeri bir dosyada saklayın.
3. Sağlayıcı değiştirirken bu kaydı yeni yere ilk gün taşıyın.
4. Doğrulama düşerse Search Console'daki bildirimi okuyun ve kaydın yerinde olup olmadığına bakın.

Küçük bir sitenin kayıtları birlikte nasıl çalışır

Kayıtlar tek tek değil, bir bütün olarak çalışır. Basit bir site için örnek bir kayıt seti şöyle kurulabilir. Tablo: Örnek kayıt seti ve her satırın görevi. Değerler yer tutucudur; kendi sağlayıcınızın verdiği değerleri kullanın.

Bu seti kendi panelinizdekiyle karşılaştırın. Her satırın karşılığını bulamıyorsanız, eksik ya da fazla kayıtların nedenini öğrenin. Eksik bir satır bir hizmeti sessizce durdurabilir; fazla bir satır ise eski bir sağlayıcının artığı olabilir.

Alt ad kayıtları ve üçüncü taraf hizmetler

Bir hizmet (örneğin bir rezervasyon ya da mağaza servisi) sizden alt ad için kayıt isteyebilir. Hizmetin kendi yönergesi hangi kaydı istediğini belirler: bir CNAME ya da A kaydı ve bir doğrulama TXT'i istenebilir. Hizmeti bıraktığınızda bu kayıtları da silmeyi unutmayın; hedefi artık sahibi olmadığınız bir ada işaret eden kayıt, bakımsız bir kayıt olarak kalır. Uygulama önerisi: her alt ad kaydının yanına hangi hizmete ait olduğunu ve kimin onayladığını not edin.

Ad sunucusunu değiştirmeden önce

Ad sunucusu değiştirmek, bütün kayıt listesinin başka bir yerde yeniden kurulması demektir. Önce yeni yerde bütün kayıtları girin, sonra ad sunucusunu değiştirin. Eski ad sunucuları sorgulara cevap vermeye devam ederken yeni yerin çalıştığını doğrulayın. RFC 1034, her bölgenin en az iki sunucuda bulunmasını şart koşar; yeni DNS hizmetinizin iki ad sunucusu verdiğini kontrol edin.

Değişikliğin yayılması ve TTL ile bekleme

DNS değişikliği anında her yerde görünmez. 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 TTL değerine göre önbelleğe alındığını yazar. Sayfa, taşımadan en az bir hafta önce TTL'yi temkinli bir değere, örneğin birkaç saate çekmeyi önerir. Taşımanın DNS kayıtlarını yeni barındırma sağlayıcısına yönlendirmekle başladığı ve eski sunucunun trafik sıfıra inene kadar açık tutulması gerektiği de yazılıdır. Barındırma değişikliğini adım adım hosting değiştirirken DNS geçişi ve TTL yazısında bulabilirsiniz. Google belgelerindeki öneriler değişebilir; uygulamadan önce güncel sayfaya bakın.

Bekleme süresi için plan

Uygulama önerisi: değişikliği sabah, destek ekiplerinin ulaşılabilir olduğu bir saatte yapın. Değişiklikten sonra TTL süresi kadar bekleyin ve farklı ağlardan (mobil veri gibi) denemeler yapın. Eski kaydı hemen silmek yerine, yeni kaydın çalıştığını doğruladıktan sonra silin.

Googlebot erişimi ve geçici engeller

Barındırma değişirken DNS kaydı yeni sunucuya çevrilir. Google'ın URL değişmeyen taşıma sayfası, bu adımdan önce geçici tarama ya da dizin engellerini kaldırmanızı söyler. Sayfa örnek olarak robots.txt içindeki bir disallow kuralını ve bir noindex etiketini verir. Aynı sayfa yeni altyapıya Googlebot'un ulaşabildiğini sınamayı (örneğin URL Denetimi aracıyla) ve güvenlik duvarının ya da DoS korumasının Googlebot'u engellemediğinden emin olmayı ister.

Taşıma sırasında hem eski hem yeni sunucunun günlüklerini izleyin, DNS değişikliğinin internet servis sağlayıcılarında yayılıp yayılmadığını denetleyin ve Search Console'da tarama ile dizinlemeyi takip edin. Sayfa, eski barındırmayı yalnızca eski sağlayıcıya gelen trafik sıfıra indiğinde kapatmanızı söyler. Uygulama önerisi: eski sağlayıcının hesap kapanış tarihini taşımadan önce öğrenin ve bu tarihi trafik koşulundan önce gelmeyecek biçimde planlayın.

TTL değerini seçmek: karar kuralı

TTL seçimi bir ödünleşmedir: düşük değer değişikliklerin daha çabuk yayılmasını sağlar, yüksek değer ise çözümleyicilerin kaydı daha uzun saklamasına izin verir. RFC 1034 değeri bölge yöneticisine bırakır. Google ise taşımadan önce temkinli bir düşük değere, örneğin birkaç saate inmeyi önerir. Tablo: Duruma göre TTL yaklaşımı.

Karar kuralı: değişiklik yakınsa önce TTL'yi düşürün ve bekleyin, sonra kaydı değiştirin; sıra tersine çevrilirse eski değer önbelleklerde uzun süre kalabilir. Sıfır TTL önbelleğe almayı yasaklar; bu uç bir değerdir ve sağlayıcınız izin vermeyebilir.

Kayıtları nasıl kontrol edersiniz

Kayıtları kontrol etmenin üç katmanı vardır: panelde yazanı okumak, dışarıdan görüneni sormak ve hizmetin gerçekten çalıştığını denemek. Tablo: Kontrol katmanları.

Uygulama önerisi: panelde yazanla dışarıdan görünen farklıysa, ad sunucusunu yanlış yerde düzenliyor olabilirsiniz ya da TTL süresi henüz dolmamış olabilir. Önce hangi ad sunucularının yetkili olduğuna bakın.

Dışarıdan sorgularda ne okunur

Dışarıdan sorgu araçları dört şeyi gösterir: sorguladığınız ad, kayıt türü, TTL ve değer. Araç size birden çok yanıt döndürürse (örneğin birden çok MX), tercih sayılarını da okuyun. Yanıtta TTL değeri geri sayar; yani ikinci sorguda daha düşük görünebilir. Bu, değerin çözümleyici önbelleğinden geldiğini gösterir. Panelde yazan değer ile sorguda görünen değer farklıysa üç ihtimali sırayla eleyin: yanlış ad sunucusunda düzenleme yapmış olabilirsiniz, TTL dolmamış olabilir ya da değişikliği kaydetmemiş olabilirsiniz. Uygulama önerisi: sorguyu hem kendi ağınızdan hem mobil veriden yapın ve sonuçları not edin.

Hataların belirtileri

Site açılmıyorsa A ya da CNAME'e, e-posta gelmiyorsa MX'e, Search Console doğrulaması düştüyse TXT ya da CNAME doğrulama kaydına bakın. Bu eşleşmeyi aklınızda tutmak teşhisi hızlandırır.

Sorun giderme sırası

Bir sorun çıktığında doğru kayda hızla gitmek için belirtiyi kayıt türüne bağlayın. Tablo: Belirti, bakılacak kayıt ve ilk kontrol.

Değişiklik talebi şablonu

DNS değişikliğini bir ajanstan ya da barındırma şirketinden istiyorsanız talebi yazılı yapın. Talepte alan adı, değişecek kayıt türü ve adı, eski ve yeni değer, istenen tarih ve saat ile gerekçe bulunsun. Yanıtta uygulanan değişikliğin kopyasını isteyin. Böylece sorun çıkarsa hangi satırın ne zaman değiştiği belli olur.

Örnek senaryo: bir çay bahçesi

Örnek senaryo: Bir çay bahçesi, masa rezervasyon formunu ve menüsünü küçük bir sitede yayımlıyor. Siteyi kuran kişi ayrılıyor ve bahçenin sahibi, barındırma şirketini değiştirmeye karar veriyor. Yeni şirket ona bir IP adresi, bir e-posta sağlayıcısı sunucu adları ve bir doğrulama değeri veriyor.

Bahçe sahibi önce DNS panelindeki kayıt listesini kaydeder: bir A kaydı, bir www CNAME'i, iki MX kaydı ve iki TXT kaydı. Ardından yeni şirketten alınan IP adresini A kaydına yazar, TTL'yi önceden birkaç saate çekmiş olduğunu doğrular, MX kayıtlarını yeni e-posta sağlayıcısına yönlendirir ve Search Console doğrulama TXT kaydının yerinde kaldığını kontrol eder. Son olarak siteyi telefondan mobil veriyle, e-postayı kendi adresine göndererek dener.

Senaryodan çıkan ders

Her kaydın bir işi vardır ve her işin bir kontrolü vardır: A için site, MX için e-posta, TXT için doğrulama. Bu üç kontrolü yapmadan değişiklik tamamlanmış sayılmaz.

Yanlış gidebilecek üç şey ve önlemi

Tablo: Senaryoda yanlış gidebilecek üç durum.

Karıştırılan noktalar

Tablo: Karıştırılan dört nokta ve doğru okuma.

Yanlış anlaşılan nokta: DNS değişikliği site taşımadır

Bir A kaydının değerini değiştirmek, sitenizin adreslerini değiştirmez. Google, URL değişmeyen taşıma sayfasını yalnızca kullanıcıya görünen URL'yi etkilemeyen geçişler için ayırır. Alan adının kendisi, protokol ya da yol yapısı değişiyorsa ayrı bir belge geçerlidir. Tablo: Değişikliğe göre bakılacak Google belgesi.

Karar kuralı: önce kullanıcıya görünen adresin değişip değişmediğini sorun. Değişmiyorsa DNS ve TTL işi yeterli çerçevedir. Değişiyorsa DNS kaydı işin yalnızca bir parçasıdır; yönlendirme, eşleme ve Search Console bildirimi ayrı belgelere aittir.

DNS değişikliğini yayınlamadan önce kontrol listesi

• Mevcut kayıt listesi dışa aktarıldı ve tarihle saklandı.
• Hangi ad sunucularının yetkili olduğu ve değişikliğin hangi panelde yapılacağı biliniyor.
• Yeni değerler sağlayıcıdan kopyalandı, fazladan boşluk ya da önek yok.
• CNAME'in bulunduğu adda başka kayıt bulunmuyor.
• MX kayıtlarının tercih sayıları sağlayıcının verdiği gibi.
• Search Console doğrulama kaydı ve tanıdığınız diğer TXT kayıtları yerinde.
• TTL, değişiklikten en az bir hafta önce düşürüldü.
• Değişiklikten sonra site, e-posta ve doğrulama için test planı hazır.
• Eski sunucu ve eski MX kayıtları, yenisi çalışana kadar yerinde duruyor.
• Değişiklik tarih, kişi ve gerekçeyle günlüğe yazıldı.

Googlebot ve izleme için ek kontroller

• robots.txt içinde geçici bir disallow kuralı kalmadı.
• Sayfalarda geçici bir noindex etiketi kalmadı.
• Güvenlik duvarı ve DoS koruması Googlebot'u engellemiyor.
• URL Denetimi aracıyla yeni sunucudaki bir sayfa denendi.
• Eski ve yeni sunucunun günlükleri izlemeye açık.
• Eski barındırma, trafik sıfıra inene kadar kapatılmayacak.

Kayıt envanteri şablonu

Her kayıt için bir satırlık envanter tutun. Tablo: Envanter sütunları.

Sık Sorulan Sorular

A kaydı ile CNAME kaydı arasındaki fark nedir?

A kaydı bir adı doğrudan IP adresine bağlar. CNAME ise bir adı başka bir adın takma adı yapar ve çözümleme o adın üzerinden yeniden başlar. RFC 1034'e göre CNAME olan bir düğümde başka veri bulunmamalıdır.

MX kaydı olmazsa ne olur?

MX kaydı alan adı için posta sunucusunu gösterir. RFC 1034 bu kaydı posta değişim sunucusunu gösteren kayıt olarak tanımlar. E-posta kullanıyorsanız sağlayıcınızın verdiği MX kayıtlarını eksiksiz girin.

TXT kaydı ne işe yarar?

Google'ın Search Console sayfasına göre alan adı mülkünü doğrulamak için TXT ya da CNAME kaydı eklenir. TXT kaydı başka işler için de kullanılır. SPF için ayrı yazıya bakın.

Search Console doğrulama kaydını silebilir miyim?

Google'ın sayfası, doğrulanmış kalmak için DNS kaydını sağlayıcınızdan silmemenizi söyler. Silerseniz doğrulama teyit edilemez ve bildirim alırsınız.

TTL değerini ne kadar tutmalıyım?

RFC 1034 TTL'yi önbellek süresi sınırı olarak tanımlar ve değeri bölgenin yöneticisine bırakır. Google, taşımadan en az bir hafta önce örneğin birkaç saate düşürmeyi önerir.

DNS değişikliği ne kadar sürede yayılır?

Değişiklik TTL süresine ve çözümleyici önbelleklerine bağlıdır. Google'ın Search Console sayfası, elle eklenen bir kaydın sağlayıcı tarafından yayına alınmasının iki üç günü bulabileceğini yazar.

Sonuç

A, CNAME, MX ve TXT kayıtları küçük görünür ama sitenin, e-postanın ve doğrulamanın dayanağıdır. Her kaydın işini bilmek, değişiklik öncesi listeyi dışa aktarmak ve her değişiklikten sonra site, e-posta ve doğrulamayı ayrı ayrı denemek en güvenli çalışma biçimidir. TTL'yi önceden düşürmek, ad sunucusunun nerede olduğunu bilmek ve tanımadığınız TXT kaydını silmemek üç temel kuraldır. Bu kuralları ekip içinde yazılı hale getirmek, DNS bilgisini tek bir kişinin hafızasından çıkarıp ortak bir belgeye taşır. Böylece ajans değiştiğinde, bir çalışan ayrıldığında ya da barındırma şirketi taşındığında kayıtların neye hizmet ettiği, hangi panelde durduğu ve en son ne zaman değiştiği tek bakışta anlaşılır. Kayıt envanterini yılda bir kez gözden geçirmek, artık kullanılmayan hizmetlerin bıraktığı kayıtları ayıklamak için de uygun bir fırsattır. Envanterde bulunmayan ve açıklanamayan her satır, bir sonraki değişiklikte sürpriz yaratabilecek bir kayıttır; bu nedenle önce açıklayın, sonra gerekiyorsa kaldırın. Panel etiketleri sağlayıcıya göre değişir; kayıtları kendi sağlayıcınızın belgeleriyle birlikte okuyun. Bir kaydı silmeden ya da değiştirmeden önce neye hizmet ettiğini öğrenmek ve eski değerini kaydetmek, geri dönüşü her zaman mümkün kılar. Bu iki alışkanlık, DNS ile çalışırken en kolay ve en ucuz sigortadır.

Sitenizin altyapısı düzene girdikten sonra içeriği tanıtmak için backlink paketlerimizi inceleyebilirsiniz.