DNS Geçiş Kontrolü
Yetki devrini değiştirmeden önce mevcut ve yeni ad sunucularınızın verdiği yanıtları kayıt kayıt karşılaştırın.
İlgili araçlar
- DNS SorgulamaDNS kayıtlarını türe göre sorgulayın; IP adresleri için ters (PTR) sorgular dahil.
- Alan Adı SağlığıDNS, e-posta kimlik doğrulaması, TLS, güvenlik başlıkları ve yönlendirmeler için tek kontrol; her alan için bir not ve tam rapor.
- E-posta GüvenliğiBir alan adı için SPF, DKIM, DMARC, MTA-STS, TLS-RPT ve BIMI'yi kontrol edin ve bunları düzeltecek kayıtları alın.
- MX ve SMTPBir alan adının e-posta sunucularını kontrol edin; SMTP bağlantılarını, STARTTLS'i ve açık aktarımı test edin.
Bu araç hakkında
DNS Geçiş Kontrolü, iki ad sunucusu kümesine aynı soruları sorar ve yanıtları yan yana koyar. Alan adını, bugün kullandığı ad sunucularını ve yetkisini devretmek üzere olduğunuz sunucuları siz verirsiniz; XGM de her iki kümeyi A, AAAA, CNAME, MX, TXT, NS, SOA, SRV ve CAA için doğrudan sorgular - yenilerin yetkisi henüz devredilmemiştir, adlarıyla sorulmaları gerekmesinin bütün nedeni de budur. Her tür bir sonuç alır: aynı, farklı, yeni tarafta eksik, yeni tarafta fazladan veya yanıtsız. Karşılaştırma metne göre değil anlama göre yapılır; bu yüzden farklı bir sıralama fark sayılmaz, MX önceliğe ve ana bilgisayara göre, TXT ise birleştirilmiş dizelere göre karşılaştırılır ve TTL değişikliği içerik değişikliğinden ayrı raporlanır, çünkü sağlayıcı değiştirmek TTL değerlerini haklı olarak değiştirir. Reddedilen veya zaman aşımına uğrayan bir sorgu yanıtsız olarak raporlanır, asla eksik olarak değil - sunucu yalnızca yanıt vermemişken size bir kaydın olmadığını söylemek, bir geçişin e-posta kaybetmesinin yoludur. Ortaya çıkan şey, geçiş yapmadan önce düzeltilmesi gerekenlerin kısa bir listesi ve karşılaştırmanın tamamını içeren bir CSV dosyasıdır.
Bir alan adını yeni bir DNS barındırmasına taşımak bir devretme değişikliğidir: kayıt kuruluşundaki NS kayıtları yeni takımı gösterdiği anda her yanıt yeni bölgeden gelir. Eski bölgenin yanıtladığı, yeninin yanıtlamadığı her şey öylece var olmaktan çıkar; en sık kaybolan kayıtlar da panelde kimsenin kurmadığı olanlardır - bir TXT doğrulaması, bir alt alan adı CNAME'i, bir CAA kaydı, bir telefon sistemi için SRV girdisi.
Bu araç her iki takımı da doğrudan sorgular; bu yüzden geçişten önce çalışır ve bugün neyin devredildiğine bağlı değildir. Başarısız olan bir sorgu, boş bir taraf olarak değil, başarısızlık olarak bildirilir. Taşındığınız bölgeyi tek başına kontrol etmek için DNS Sorgulama'yı, özellikle e-posta kayıtları için E-posta Güvenliği'ni kullanın.
Nasıl kullanılır
- Alan adını ve bugün kullandığı ad sunucularını girin - emin değilseniz Alan Adı Sağlığı veya DNS Sorgulama araçları bunu size söyler.
- Taşınmak üzere olduğunuz ad sunucularını, yeni sağlayıcınızın size verdiği hâliyle girin.
- Kontrolü çalıştırın ve önce düzeltme listesini okuyun: devretme değiştiği anda eksik ya da yanlış olacak kayıtlar onlardır.
- Yeni sağlayıcıdaki yeni bölgeyi düzeltin, kontrolü yeniden çalıştırın ve yalnızca liste boşaldığında geçiş yapın.
- Geçişten sonra TTL değerlerini eski hâline döndürün ve e-postanın ve TLS'in hâlâ çözümlendiğini doğrulamak için Alan Adı Sağlığı aracını yeniden çalıştırın.
SSS
Yeni ad sunucularını neden kendim yazmak zorundayım?
Çünkü yetkileri henüz devredilmedi. Kayıt kuruluşunuzdaki ad sunucularını değiştirene kadar internet, alan adınıza gelen her sorguyu hâlâ eskilerine gönderir; bu yüzden yeni sağlayıcının ne yanıtlayacağını görmenin tek yolu ona doğrudan adıyla sormaktır. Bu kontrolü çalıştırmaya değmesinin nedeni de budur: iki yanıtı karşılaştırabileceğiniz tek an, geçişin yeni yanıtı tek yanıt hâline getirmesinden önceki andır.
Yeni taraf bir kayıt türü için hiçbir şey göstermiyor. Eksik mi?
Yalnızca satırda eksik yazıyorsa. Sorguyu reddeden veya zamanında yanıt vermeyen bir ad sunucusu, nedeniyle birlikte yanıtlanmadı olarak bildirilir ve özet, karşılaştırmanın eksik olduğunu söyler - çünkü sunucu sadece yanıt veremediği hâlde bir kaydın yok sayılması, geçişten sonra e-postayı kaybettiren hatanın ta kendisidir. Boş bir satırdan bir anlam çıkarmadan önce ad sunucusu adının doğru olduğunu ve bölgenin yeni sağlayıcıda oluşturulduğunu kontrol edin.
Farklı bir TTL önemli mi?
Genellikle hayır; zaten bu yüzden ayrı gösterilir. Yeni bir sağlayıcının kendi varsayılanları vardır ve kayıtların kendisi değişmemiştir. TTL'ler asıl geçişin çevresinde önem kazanır: taşınmadan bir iki gün önce eski tarafta düşürün ki bir hata saatler yerine dakikalar içinde yayılıp geçsin; yeni bölge kendini kanıtladıktan sonra da tekrar yükseltin.
Peki SOA seri numarası?
Yeni taraftaki değer eskisinden düşük olduğunda kendi bulgusunu alır. Hemen bir şey bozulmaz, ancak eski bölgeyi zaten elinde tutan ikincil bir sunucu yenisini bir güncelleme olarak kabul etmeyi reddeder ve bu uyuşmazlık daha sonra iki sunucunun aynı ad için farklı yanıt vermesi olarak ortaya çıkar. Geçiş yapmadan önce yeni taraftaki seri numarasını eskisinin üzerine çıkarın.
Bu, taşımam gereken her şeyi kapsıyor mu?
Bölgeyi kapsar. DNS'in dışında kalan şeyleri bilmez: kayıt kuruluşundaki transfer kilitleri ve yetki kodları, taşımadan önce geri çekilip sonra yeniden eklenmesi gereken DNSSEC anahtarları, alan adının kendi içindeki ad sunucuları için glue kayıtları ve e-posta yönlendirmesi ya da CDN sertifikaları gibi sağlayıcı tarafındaki her türlü yapılandırma. Kayıt karşılaştırması, makineyle denetlenebilen kısımdır ve insanların genellikle yanlış yaptığı kısım da odur.