Kısa cevap: DNS kayıtları, alan adınızla ilgili soruların cevaplarını tutan bir liste gibi çalışır. A kaydı “bu adresin sitesi hangi sunucuda”, MX kaydı “bu adrese gelen e-posta nereye gidecek”, TXT kaydı da “bu alan adı adına kim konuşabilir” sorusunu yanıtlar. Site ile e-posta ayrı kayıtlarla yönetildiği için birini taşımak diğerini bozmaz – yeter ki doğru satıra dokunun.
DNS tam olarak ne yapıyor
İnsanlar adres yazar, bilgisayarlar numara kullanır. Tarayıcıya bir alan adı yazdığınızda cihazınız önce o adın hangi numaraya karşılık geldiğini sorar. Bu soruyu cevaplayan sisteme DNS deniyor. Cevap, alan adınızın DNS bölgesinde (zone) duran kayıtlardan gelir.
Burada çoğu işletmenin kaçırdığı nokta şudur: alan adını satın aldığınız yer ile kayıtları yöneten yer aynı olmak zorunda değildir. Alan adı bir kayıt kuruluşunda durur, kayıtlar ise isim sunucularının (nameserver) gösterdiği yerde tutulur. Panelde kayıtları göremiyorsanız genellikle sebebi budur: kayıtlar başka bir yerde yönetiliyordur.
Her kaydın üç parçası vardır: adı (hangi ad için geçerli), türü (hangi soruya cevap veriyor) ve değeri (cevabın kendisi). Dördüncü bir alan olarak TTL, bu cevabın ne kadar süre önbellekte tutulacağını saniye olarak söyler. TTL'nin önemini aşağıda ayrıca ele alıyoruz, çünkü taşınmalarda yaşanan sıkıntıların büyük kısmı ondan çıkar.
Kayıt türleri ve hangisinin ne zaman kullanıldığı
Aşağıdaki tablo günlük işte karşınıza çıkan türleri toplar. Pratikte bir işletmenin ömür boyu dokunacağı kayıt sayısı beşi geçmez.
| Tür | Cevapladığı soru | Ne zaman dokunursunuz |
|---|---|---|
| A | Bu ad hangi IPv4 adresinde? | Siteyi başka sunucuya taşırken |
| AAAA | Bu ad hangi IPv6 adresinde? | Sunucu IPv6 veriyorsa, A ile birlikte |
| CNAME | Bu ad hangi başka ADA bağlı? | Alt ad bir hizmete yönlenirken |
| MX | Gelen e-posta hangi sunucuya? | E-posta sağlayıcısını değiştirirken |
| TXT | Serbest metin: doğrulama ve yetki | SPF, DKIM, DMARC ve mülk doğrulaması |
| SRV | Bu servis hangi sunucu ve PORT üzerinden? | Toplantı ve mesajlaşma servisleri isterse |
| NS | Bu alan adının kayıtlarını kim tutuyor? | DNS yönetimini başka yere alırken |
| CAA | Bu alan adına kim sertifika kesebilir? | Sertifika otoritesini kısıtlamak isterseniz |
| PTR | Bu IP hangi ada ait? (ters çözümleme) | Nadiren; genelde IP sahibi yönetir |
Tabloda iki satır özel dikkat ister. MX kayıtlarının bir öncelik sayısı vardır ve küçük sayı önce denenir; yani “1” birincil, “10” yedek anlamına gelir. CNAME ise kök kayıtta kullanılamaz: standart gereği @ satırına CNAME yazılmaz. Sağlayıcılar bunu ALIAS ya da ANAME adı verdikleri kendi çözümleriyle aşar; paneliniz böyle bir tür sunuyorsa kök adresi bir hizmete bağlamak için onu kullanın.
Adım adım: bir kaydı güvenle değiştirmek
Sıralama önemlidir. Aşağıdaki akış, değişikliğin kesinti üretmesini büyük ölçüde engeller.
- Kayıtların nerede yönetildiğini bulun. Alan adı panelinde NS satırlarına bakın. Oradaki isim sunucuları hostinginize mi, Cloudflare gibi bir servise mi, yoksa kayıt kuruluşunun kendi DNS'ine mi ait? Kayıtları o panelde düzenleyeceksiniz.
- Mevcut durumun ekran görüntüsünü alın. Tüm kayıtları değiştirmeden önce kaydedin. Geri dönmek gerektiğinde eski değeri hatırlamaya çalışmak en pahalı kayıptır.
- TTL'yi düşürün ve bekleyin. Değiştireceğiniz kaydın TTL değerini 300 saniyeye indirin, sonra en az eski TTL kadar bekleyin. Bu adım atlanırsa yeni değer bazı ziyaretçilere saatlerce ulaşmaz.
- Yalnızca ilgili satırı değiştirin. Siteyi taşıyorsanız A ve AAAA kayıtlarına dokunun; MX ve e-posta ile ilgili TXT kayıtlarını OLDUĞU GİBİ bırakın. Bu ikisini karıştırmak, “site taşındı, mailler kayboldu” şikâyetinin birinci sebebidir.
- Kaydı dışarıdan doğrulayın. Kendi bilgisayarınız eski cevabı önbellekte tutuyor olabilir. Bir DNS sorgulama aracından ya da mobil veriyle açtığınız bir tarayıcıdan kontrol edin.
- Yayılma tamamlandıktan sonra TTL'yi geri yükseltin. 3600 saniye çoğu kayıt için makul bir değerdir. Sürekli 300'de bırakmak gereksiz sorgu üretir.
Gerçek bir bölge nasıl görünür
Aşağıdaki örnekte alan adı ornekfirma.com ve IP değerleri YER TUTUCUDUR – kendi hostinginizin verdiği adresi yazmanız gerekir. Yapının kendisi gerçektir.
; site @ 3600 A (hostinginizin IPv4 adresi) www 3600 CNAME ornekfirma.com. ; e-posta teslimi (Google Workspace, 2023 sonrası tek kayıt) @ 3600 MX 1 smtp.google.com. ; e-posta kimlik doğrulama @ 3600 TXT "v=spf1 include:_spf.google.com ~all" google._domainkey 3600 TXT "v=DKIM1; k=rsa; p=(genel anahtar)" _dmarc 3600 TXT "v=DMARC1; p=none; rua=mailto:dmarc@ornekfirma.com" ; sertifika otoritesi kısıtlaması (isteğe bağlı) @ 3600 CAA 0 issue "letsencrypt.org"
Dikkat edin: tek bir alan adında site, e-posta teslimi ve e-posta kimlik doğrulaması üç ayrı katmanda duruyor. Bu ayrım bir karmaşa değil, kolaylıktır; site sağlayıcınızı değiştirirken e-postaya hiç dokunmadan ilerleyebilirsiniz.
Yaygın hatalar
- Aynı alan adına iki ayrı SPF kaydı yazmak. Bir alan adında yalnızca bir SPF politikası olabilir. İki kayıt gören alıcı sunucular politikayı geçersiz sayar ve e-postalarınız doğrulamayı kaybeder. Tüm izinler tek TXT satırında birleştirilir.
- Kök kayda CNAME yazmaya çalışmak. Panel kabul etse bile e-posta dahil diğer kayıtlar beklenmedik biçimde bozulabilir. Kök için A/AAAA ya da sağlayıcınızın ALIAS türünü kullanın.
- Hosting değiştirirken isim sunucularını değiştirip kayıtları taşımamak. NS değişince kayıtlar yeni sağlayıcının bölgesinden okunur. Oraya MX kayıtlarınızı yazmadıysanız e-posta anında durur.
- TTL'yi düşürmeden geçiş yapmak. Eski TTL bir günse, değişikliğin bazı ziyaretçilere ulaşması bir gün sürer. Bu süre boyunca kimi kullanıcı eski sunucuyu, kimi yeniyi görür.
- Kaydın sonundaki noktayı atlamak. Bazı panellerde hedef adın sonuna nokta konmazsa alan adınız sona eklenir ve değer
smtp.google.com.ornekfirma.comgibi anlamsız bir hâle gelir. - SPF kaydını MX sanmak. MX gelen postanın nereye gideceğini söyler, SPF giden postayı kimin gönderebileceğini. İkisi ayrı iştir; birini kurup diğerini atlamak yarım bir kurulumdur.
Ne zaman uzmana bırakmalı
Tek bir A kaydını değiştirmek için kimseye ihtiyacınız yok. Ama şu üç durumda bir hata doğrudan iş kaybına dönüşür: aynı anda hem site hem e-posta taşınıyorsa, alan adı üzerinde çalışan birden fazla hizmet varsa (site, e-posta, bir ödeme sağlayıcısı, bir doğrulama kaydı), ya da geçmişte kimin hangi kaydı neden eklediği bilinmiyorsa. Böyle bir bölgeyi temizlemek, kayıtları tek tek eşleştirip hangisinin hâlâ kullanıldığını ölçmeyi gerektirir.
Bu işi biz web sitesi ve e-ticaret çalışmalarının bir parçası olarak yapıyoruz; mevcut yapının genel bir fotoğrafını çıkarmak isterseniz teknik denetim sayfasına bakabilir ya da iletişim sayfasından yazabilirsiniz.
Devamını okumak için
Siteyi yeni bir sunucuya alacaksanız alan adını başka bir hosting'e taşıma yazısı sırayı anlatıyor. Alan adının kendisini başka bir kayıt kuruluşuna almak istiyorsanız EPP kodu ve 60 gün kuralı yazısına, www ile kökü tekilleştirmek için www mi, www'suz mu yazısına bakın. E-posta tarafına geçmek için başlangıç noktası kurumsal e-posta kurulumu. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.