Alan Adının Ad Sunucuları Nasıl Değiştirilir?

Sesli Dinle — Makale

Alan adının ad sunucularını değiştirmek, DNS içindeki yetki devrini yeni yetkili sunuculara yöneltir. Yetki devri, üst bölgenin çocuk alan adı için yayımladığı NS kayıt kümesidir. Kayıt kuruluşu, paneldeki yeni listeyi ilgili üst düzey alanın kayıt operatörüne iletir; operatör üst bölgedeki yetki devrini günceller.

Ad sunucusu adı, IP adresi değildir; adres kaydıyla çözümlenen tam bir sunucu adıdır. Değişiklik DNS bölgesindeki web, e-posta ve doğrulama kayıtlarını kendiliğinden kopyalamaz. Alan adı kaydı, kayıt sahibi, yenileme tarihi ve hosting hesabı da yalnız bu işlemle değişmez.

Güvenli sıra; yeni DNS bölgesini eksiksiz hazırlamak, yeni sunucuların yetkili yanıtını sınamak, DNS güvenlik zincirini planlamak, kayıt kuruluşundaki listeyi güncellemek ve hem üst bölgeyi hem gerçek hizmetleri doğrulamaktır. Yeni sonuç kararlı hale gelene kadar eski DNS hizmeti açık tutulmalıdır.

Ad Sunucusu Değişikliğinde Tam Olarak Ne Değişir?

Recursive resolver (özyinelemeli DNS çözümleyicisi), yanıtı önbelleğinden verebilir veya DNS sorgularıyla edinebilir. Yetkili sunuculara doğrudan sorgu gönderdiğinde bildiği en yakın yetki devrinden başlar; gerektiğinde kök ve üst düzey alan sunucularına başvurur. Üst bölgedeki NS kayıtları, sorgunun çocuk bölge hakkında yanıt verecek yetkili sunuculara gönderilmesini sağlar. Yeni liste öğrenildiğinde sorgular yeni sunucu kümesine yönelir; önbellekteki eski liste bir süre kullanılabilir.

Çocuk DNS bölgesinin tepesinde de NS kayıtları bulunur. Üst bölgedeki yetki devri ile çocuk bölgedeki bu kayıtların aynı geçerli sunucu kümesini göstermesi beklenir. Yalnız çocuk bölgedeki NS satırlarını değiştirmek, kayıt kuruluşu üzerinden yayımlanan üst bölge yetki devrini değiştirmez.

Bir sunucunun alan adı için cevap vermesi de tek başına yeterli değildir. Sunucu bölgeyi yerel bilgisiyle sunmalı ve yanıtı yetkili olarak işaretlemelidir. Üst bölgenin sunucuyu göstermesi, sunucunun gerçekten hazırlanmış olduğunu kanıtlamaz.

Ad Sunucusu, DNS Kaydı, Alan Adı Transferi ve Hosting Farkı Nedir?

Bir proje bu işlemlerin birkaçını birlikte içerebilir; yine de her adımın etkisi ayrıdır. Örneğin site yeni sunucuya taşınırken yalnız web adres kayıtları değiştirilebilir veya DNS yönetimi de yeni DNS sağlayıcısına geçirilerek ad sunucuları değiştirilebilir. Alan adı transferinde ad sunucuları korunmuş olsa bile eski kayıt kuruluşunun DNS hizmetini sürdürüp sürdürmediği ayrıca kontrol edilmelidir.

Yeni DNS Bölgesi Geçişten Önce Nasıl Hazırlanır?

Önce mevcut bölgenin tam envanterini çıkarın. IPv4 adresini taşıyan A, IPv6 adresini taşıyan AAAA, MX, TXT ve CNAME kayıtlarını işlevleriyle birlikte karşılaştırın. Yalnız ana siteyi kopyalamak e-posta, alt alan, doğrulama veya üçüncü taraf hizmetlerini bozabilir.

Bölgenin SOA (Start of Authority) kaydı ve NS kayıtları yeni DNS sağlayıcısının düzenine göre oluşur; bunları eski DNS sağlayıcısından olduğu gibi kopyalamayın. Buna karşılık web, e-posta, alan sahipliği doğrulaması ve TLS sertifika işlemleri için kullanılan kayıtların yeni bölgede bulunması gerekir.

• Alan adı tepesi, www ve kullanılan bütün alt alanların hedeflerini karşılaştırın.
• E-posta sunucularını gösteren MX kayıtlarını ve e-posta doğrulaması için kullanılan TXT kayıtlarını eksiksiz aktarın.
• Hizmet doğrulaması, sertifika üretimi ve üçüncü taraf uygulamalar için kullanılan kayıtları not edin.
• Bilinçli olarak değiştirilecek hedefleri eski değerlerle karıştırmayın; geçiş planında ayrı işaretleyin.
• Yeni sağlayıcının içe aktarma sonucunu ham bölge verisiyle ve gerçek sorguyla kontrol edin.

Bir DNS kaydındaki TTL, kaydın normalde önbellekte ne kadar tutulabileceğini belirtir. Planlı hedef değişikliklerinde TTL değerini önceden azaltmak yardımcı olabilir; önceden saklanmış yanıtların kalan süreleri ise bu işlemle kısalmaz. Çocuk bölgedeki bu ayar, üst bölgenin NS kayıtlarının veya ad sunucusunun adresini bildiren glue kayıtlarının TTL değerlerini kontrol etmez.

Yeni Yetkili Ad Sunucuları Nasıl Sınanır?

Yetki devrini değiştirmeden önce yeni DNS sağlayıcısının verdiği her ad sunucusunu doğrudan sorgulayın. Her sunucu alan adı için yetkili cevap vermeli, aynı temel NS ve SOA verisini sunmalı ve beklenen hizmet kayıtlarını taşımalıdır. Sunucular arasındaki kopyalama gecikmesi geçici olabilir; kayıt yapılmadan önce tutarlı duruma gelmesini bekleyin.

Yetkili DNS hizmeti, UDP ve TCP üzerinden 53 numaralı portta erişilebilir olmalıdır. Yalnız bir ağdan alınan tek olumlu sonuç genel erişilebilirliği kanıtlamaz. Sağlayıcının sunduğu bütün sunucu adlarını kullanın; kendi tahmininizle listeyi azaltmayın veya ek sunucu üretmeyin.

Sunucu adının hedefi bir CNAME takma adı olmamalıdır. NS hedefi doğrudan adres kayıtlarıyla çözümlenmelidir. Yeni sunucunun normal web sayfası açması ya da ping isteğine cevap vermesi DNS için yetkili ve erişilebilir olduğunu göstermez; doğrulama DNS sorgusuyla yapılmalıdır.

Alan Adının Kendi Altındaki Ad Sunucularında Glue Kaydı Neden Gerekir?

ornekalanadi.example alanı için ns1.ornekalanadi.example kullanılırsa recursive resolver, sunucu adresini öğrenmek için yönelmesi gereken bölgeye henüz ulaşamamış olur. Bu döngüyü kırmak amacıyla üst bölgede yayımlanan A veya AAAA adres kaydına glue kaydı denir; glue ayrı bir DNS kayıt türü değildir.

Glue kaydı, ad sunucusunun IPv4 veya IPv6 adresini üst bölgedeki yönlendirme yanıtına ekler. Yalnız çocuk DNS bölgesine aynı ad için A ya da AAAA kaydı yazmak yeterli değildir. Kayıt kuruluşunda çocuk ad sunucusu, kayıtlı sunucu, sunucu nesnesi veya kişisel ad sunucusu adıyla sunulan ayrı işlem üzerinden üst bölgeye adres bildirilmelidir.

Ad sunucusu başka bir bağımsız alan adındaysa adresi normalde o alanın yetkili DNS bölgesinden çözülür; her NS hedefi için glue kaydı üretmek gerekmez. Alan adının kendi altındaki sunucunun adresi değişirse hem üst bölgedeki glue kaydı hem yetkili A veya AAAA kaydı uyumlu güncellenmelidir. Önbellekteki eski adresler yenilenene kadar eski sunucu adresinde de DNS hizmeti sürdürülmelidir.

DNSSEC Etkinken Ad Sunucusu Geçişi Nasıl Planlanır?

DNSSEC, çocuk bölgedeki DNSKEY kaydını üst bölgedeki DS (Delegation Signer) kaydıyla bağlar. Üst bölgede eski anahtara ait DS kalırken yeni DNS sağlayıcısı bu DS ile doğrulanamayan bir anahtar veya imzasız bölge sunarsa DNSSEC doğrulaması yapan recursive resolver güven zincirini kuramaz ve SERVFAIL döndürebilir.

Bu nedenle DNSSEC etkin bir alan için tek, evrensel bir tıklama sırası yoktur. Eski ve yeni DNS sağlayıcısının anahtar aktarımı, birden fazla imzalayıcıyla çalışma veya koordineli DS güncellemesi gibi geçiş yöntemlerinden hangilerini desteklediği belirlenmelidir. Uyumlu geçiş mümkünse en az bir geçerli doğrulama yolu korunarak anahtar ve DS kayıtları birlikte planlanır. Bekleme süreleri yalnız DS için değil, önbellekteki DNSKEY ve imzalı bölge verileri için de hesaba katılır.

DNS sağlayıcıları doğrulama zincirini koruyan bir geçişi desteklemiyorsa önce üst bölgedeki DS kaydı kaldırılıp önbelleklerdeki eski DS kayıtlarının sürelerinin dolması beklenebilir. Eski bölgenin imzalanması, bu bekleme tamamlanmadan kapatılmamalıdır; ardından yetki devri geçici olarak DNSSEC doğrulaması olmadan taşınabilir. Bu seçenek doğrulama korumasını geçici olarak kaldırır ve DNS sağlayıcılarının belgelenmiş geçiş sırasına göre uygulanmalıdır. Yetki devri ve ilgili önbellek geçişi tamamlanıp yeni bölge bütün yeni sunucularda imzalı yanıt vermeye hazır olduğunda yeni DS kaydı yayımlanır; DNSKEY, imzalar ve doğrulama sonucu recursive resolver üzerinden sınanır.

Kayıt Kuruluşunda Ad Sunucuları Nasıl Değiştirilir?

1. Kayıt kuruluşu hesabına güvenli biçimde giriş yapın ve doğru alan adını seçin.
2. Ad Sunucuları, DNS Sunucuları veya İngilizce arayüzlerde nameserver olarak gösterilen yetki devri bölümünü açın.
3. Kayıt kuruluşunun varsayılan ad sunucuları yerine özel ad sunucusu seçeneği gerekiyorsa etkinleştirin.
4. Yeni DNS sağlayıcısının verdiği tam nitelikli alan adlarını (FQDN) eksiksiz girin. Panel istemedikçe IP adresini bu alanlara yazmayın.
5. Bütün sunucu adlarını, yinelenen satırları ve yazım hatalarını kontrol edin; ardından tek kayıt işlemi yapın.
6. Hesap parolası, çok faktörlü doğrulama veya e-posta onayı istenirse işlemi yetkili kanaldan tamamlayın.
7. Değişiklik zamanını, eski listeyi ve yeni listeyi kaydedin; panelin kayıttan sonra gösterdiği değerleri yeniden okuyun.

Tam sunucu adının protokol gösteriminde son nokta kökü belirtir; birçok kayıt kuruluşu paneli bu noktayı kendisi ekler veya girişte kabul etmez. Panelin istediği biçimi izleyin ve sonuçtaki gerçek üst bölge kaydını ayrıca sorgulayın. Büyük ve küçük harf DNS açısından aynı adı gösterse de sağlayıcının verdiği yazımı korumak karşılaştırmayı kolaylaştırır.

Yeni Ad Sunucuları ve Hizmetler Nasıl Doğrulanır?

1. Üst bölge: Alan adının üst bölgesinden dönen NS kayıt kümesinin yeni liste olduğunu doğrulayın.
2. Her yetkili sunucu: Her yeni sunucuyu ayrı sorgulayın; NS ve SOA yanıtlarının yetkili, erişilebilir ve tutarlı olduğunu kontrol edin.
3. Üst-alt uyumu: Üst bölgedeki liste ile çocuk bölgenin tepesindeki NS kayıtlarını karşılaştırın.
4. Glue kaydı: Alan adının kendi altındaki ad sunucuları varsa üst bölgede yayımlanan adresleri çocuk bölgedeki A ve AAAA kayıtlarıyla karşılaştırın.
5. Hizmet kayıtları: Web, e-posta, alt alanlar, doğrulama ve sertifika işlemlerinin kullandığı cevapları yeni sunuculardan okuyun.
6. DNSSEC: Etkinse DS ve DNSKEY ilişkisini, imzaları ve doğrulama yapan recursive resolver sonucunu kontrol edin.
7. Hizmetlerin çalışması: Siteyi, e-posta alımını ve gönderimini, uygulamaların kullandığı hizmetleri gerçek işlemlerle sınayın; yalnız ana sayfanın açılmasıyla yetinmeyin.

Farklı herkese açık recursive resolver hizmetlerinden sonuç almak önbellek geçişini gözlemlemeye yardımcı olur; fakat yetkili doğrulamanın yerini tutmaz. Önce üst bölge ve yeni sunucuların gerçek verisini, sonra önbellekli kullanıcı görünümünü karşılaştırın.

Ad Sunucusu Değişikliği Ne Kadar Sürede Yayılır?

“DNS yayılımı” tek merkezden bütün internete dosya gönderilen bir işlem değildir. Kayıt kuruluşunun ilettiği değişiklik üst bölgeye işlenir; recursive resolver ise daha önce önbelleğe aldığı NS, adres ve hizmet kayıtlarını normalde kalan TTL süreleri boyunca kullanabilir. Bu nedenle bazı sorgular bir süre eski, bazıları yeni sunucu kümesine gidebilir.

Sabit bir “24 saat” veya “48 saat” garantisi yoktur. Kayıt kuruluşunun işlem süresi, üst bölgedeki TTL değerleri, önceden önbelleğe alınmış cevaplar ve istemci davranışı farklıdır. Çocuk bölgedeki TTL değerini düşürmek, üst düzey alanın kayıt operatörünün yönettiği NS kayıtlarının TTL değerini otomatik olarak kısaltmaz.

Geçiş penceresinde eski ve yeni bölgeler gerekli kayıtlar için aynı cevapları verirse karışık kullanım çoğunlukla kesinti oluşturmaz. Bu yüzden eski DNS sağlayıcısındaki hizmeti yalnız birkaç tarayıcıda yeni site görüldüğü için kapatmayın; yetkili liste, herkese açık recursive resolver sonuçları ve temel hizmetler kararlı hale gelene kadar iki DNS hizmetini de açık tutun.

Geri Alma İşlemi Nasıl Hazırlanır?

Değişiklikten önce eski ad sunucusu listesini, bölge dışa aktarımını, DNSSEC durumunu ve glue kayıtlarındaki adresleri kaydedin. Geri alma gerektiğinde kayıt kuruluşuna önceki liste yeniden yazılabilir; ancak bu da üst bölge güncellemesi ve önbellek sürelerine tabi olduğundan anlık sonuç vermez.

Sorunun kaynağı yeni bölgede tek bir eksik kayıtsa, yetki devrini tekrar değiştirmek yerine yeni yetkili bölgede kaydı düzeltmek daha hızlı olabilir ve yeni bir yetki devri bekleyişini önleyebilir. Yeni sunucular hiç yetkili değilse, üst-alt NS listesi bozuksa veya DNSSEC zinciri güvenli biçimde düzeltilemiyorsa geri alma daha uygun olabilir.

Geri alma sonrasında yalnız panel değerini değil, üst bölge yetki devrini, eski sunucuların yetkili yanıtını, glue kayıtlarındaki adresleri ve DNSSEC zincirini yeniden doğrulayın. Sorun kaydı, zaman çizelgesi ve alınan cevaplar korunursa sonraki deneme kontrollü yapılabilir.