Alt Alan Adını NS Kaydıyla Ayrı DNS’e Devretmek

Geliştirme ekibinizin bir alt alanı yönetmesi gerekiyor ama ana sitenizin ve e-postanızın DNS ayarlarına erişim vermek istemiyorsunuz. Yalnızca ilgili alt alanı devretmek, ekibin kendi kayıtlarını yönetmesini sağlarken ana alanın kontrolünü sizde tutar. Bu işlem uygulamanızı başka sunucuya taşımaz; kayıtların nerede ve kim tarafından yönetileceğini değiştirir.

Örnek senaryoda example.com mevcut DNS hizmetinde kalacak, dev.example.com ise ikinci bir hizmette yönetilecek. Önce yeni bölgeyi hazırlayacak, ardından üst bölgedeki NS kayıtlarıyla yetkiyi devredeceksiniz. Son adımda dig adlı DNS sorgulama aracıyla doğru sunucuların yanıt verdiğini kontrol edeceksiniz. Böylece paneldeki kayıtların yanı sıra devrin DNS üzerinden çalıştığını da doğrulayabileceksiniz.

Alt alan adı DNS delegasyonu neyi değiştirir?

Alt alan adı DNS delegasyonu, yani alt alanın DNS yönetim yetkisinin devri, ana alan adınızın yönetimini taşımadan belirli bir alt alanın kayıtlarını başka bir DNS hizmetine bırakmanızı sağlar. Değişen, web sitesinin bulunduğu sunucu değil, o alt alanın kayıtları için hangi DNS sunucularının yetkili olduğudur. Böylece ilgili ekip, kendisine ayrılan kayıtları sizin ana DNS panelinize girmeden yönetebilir.

NS kaydı neden A veya CNAME yerine kullanılır?

DNS, alan adlarını IP adresleri gibi bağlantı bilgileriyle eşleştiren sistemdir. Her kayıt türünün görevi farklıdır: yalnızca uygulamayı başka bir sunucuya bağlamak istiyorsanız yetki devri gerekmeyebilir. Kayıt yönetimini de ayırmak istiyorsanız yetkili ad sunucularını belirten NS kaydı kullanılır.

A veya CNAME kaydı eklemek, karşı tarafa DNS yönetim yetkisi vermez. NS ile yetki devrinde ise alt alanın kayıtları yeni yetkili sunuculardan öğrenilir. Bu işlem tek başına dosyaları, veritabanını veya uygulamayı taşımaz; uygulamanız aynı sunucuda çalışmaya devam edebilir.

Üst bölge nerede biter, alt bölge nerede başlar?

DNS bölgesi, DNS ağacında birlikte yönetilen bir kayıt alanıdır. Örnek senaryoda example.com mevcut DNS hizmetinde kalırken dev.example.com ikinci hizmette ayrı bir bölge olur. Ana alanı içeren bölgeye üst bölge, devredilen bölgeye alt bölge diyeceğiz.

Üst bölgedeki dev.example.com NS kayıtları, sizin adınıza DNS sorgularını yapan çözümleyiciye yanıtı hangi alt bölge sunucularından alacağını gösterir. dev.example.com ve www.dev.example.com gibi onun altındaki adların kayıtları artık alt bölgede yönetilir. example.com, www.example.com ve diğer kardeş alt alanlar bu devrin dışında kalır.

Bu sınır, kayıtları hangi panelde düzenleyeceğinizi de belirler. Devirden sonra üst bölgeye www.dev.example.com için sıradan bir kayıt eklemek, alt bölgedeki kaydı değiştirmez ve normal DNS çözümlemesinde o adın yanıt kaynağı olmaz. Bu nedenle ekiplerin hangi kayıtları hangi DNS hizmetinde yöneteceğini açıkça belirleyin.

Yetki devri sizin ihtiyacınıza uygun mu?

Geliştirme ekibinin kendisine ayrılan dalda yeni alt alanlar açması, doğrulama kayıtları eklemesi veya hizmet hedeflerini bağımsız değiştirmesi gerekiyorsa delegasyon uygundur. Yalnızca tek bir sitenin adresini başka sunucuya bağlayacaksanız mevcut bölgede A ya da CNAME kaydı kullanmak daha sade olabilir. Karar ölçütü, uygulamanın nerede çalıştığından çok DNS kayıtlarını kimin bağımsız yönetmesi gerektiğidir.

Örnek ortamı ve yeni DNS bölgesini hazırlayın

Erişimleri ve mevcut kayıtları hazırlayın

Örnek senaryoda iki yönetilen DNS hizmetinin de alt bölge barındırmayı desteklediğini varsayıyoruz. Üst bölgenin yetkili sunucuları ns1.parent.example ve ns2.parent.example, alt bölgenin yeni yetkilileri ns1.child.example ve ns2.child.example olsun. Bunlar temsili adlardır; işlemlerde sağlayıcılarınızın verdiği gerçek sunucu adlarını kullanın. Ana anlatım, DNS yanıtlarını imzalarla doğrulayan DNSSEC mekanizmasının kullanılmadığı ve ad sunucuları devredilen alt alanın dışında bulunan bir alt bölge içindir.

Mevcut hizmette example.com kayıtlarını düzenleme, yeni hizmette ise bölge oluşturma yetkiniz olmalı. Önce mevcut panelin bölge yönetimi ekranından kayıtları dışa aktarın. Dışa aktarma seçeneği yoksa kayıt adlarını, türlerini, değerlerini ve TTL değerlerini, yani önbellekte tutulma sürelerini kaydedin. Bu döküm, geri dönüş gerekirse eski kayıtları yeniden kurmanızı sağlar. Özellikle dev.example.com ve altındaki A, AAAA, CNAME, MX, TXT ve diğer kayıtları ayırın; yalnızca web kaydını taşımak, posta veya hizmet doğrulama kayıtlarının eksik kalmasına neden olabilir.

Mevcut panelin kayıt düzenleme ekranında taşınacak kayıtların TTL değerini, hizmet destekliyorsa 300 saniyeye indirin. Bu, değişiklikten sonra alınan yanıtların önbellekte daha kısa tutulmasını sağlar. Ancak daha önce önbelleğe alınan yanıtlar eski TTL boyunca kullanılabilir; yetki devrine geçmeden önce eski sürenin dolmasını bekleyin. Bu hazırlık aşamasında hiçbir kaydı silmeyin.

Alt bölgeyi oluşturup kayıtları ekleyin

Yeni hizmette temsili DNS > Zones > Add zone yolunu, yani bölge ekleme ekranını açın. Arayüz adları sağlayıcıya göre değişebilir. Bölge adı alanına dev.example.com yazıp yetkili DNS bölgesi olarak oluşturun. Sağlayıcının bu bölgeye atadığı iki NS adını kaydedin; üst bölgeye yetki devri kayıtlarını eklerken bu adları kullanacaksınız.

Records > Add record, yani kayıt ekleme ekranında aşağıdaki örnek kayıtları ekleyin. Name kayıt adını, Type kayıt türünü, Value/Target ise değeri veya hedefi belirtir. @ burada bölgenin kökü olan dev.example.com anlamına gelir. İlk kayıt kök adı uygulamanın IP adresine bağlar; ikinci kayıt www adını aynı hedefe yöneltir.

192.0.2.80 dokümantasyon için ayrılmış bir örnek adrestir; bunun yerine gerçek uygulama IP adresinizi kullanın. Hedefin sonundaki nokta tam DNS adını belirtir; bazı paneller bunu kendisi ekler. Kaydettikten sonra kayıt listesinde bölge adının yanlışlıkla hedefe ikinci kez eklenmediğini kontrol edin. Dökümünüzdeki diğer kayıtları da yeni bölgeye göre adlandırın: üst bölgedeki api.dev kaydı burada api olur. Böylece kaydın tam adı değişmeden kalır.

Devirden önce iki yetkili sunucuyu sorgulayın

Sağlayıcının oluşturduğu SOA kaydı, bölgenin yönetim ve sürüm bilgilerini taşır; NS kayıtları ise atanan yetkilileri göstermelidir. Bu kayıtları tahmini değerlerle değiştirmek yerine doğrudan sunuculardan sorgulayın. Komutları Ubuntu terminalinde, paket kurmak için sudo yetkisi olan bir kullanıcıyla çalıştırın. Önce DNS sorgulama aracı dig için paketi kurun; ardından sorgulardaki temsili sunucu ve alan adlarını kendi değerlerinizle değiştirin. Sorgular başka sunuculara başvurulmadan yanıtlanacağı için her yetkilinin yeni bölgeyi yayımlayıp yayımlamadığını görebilirsiniz:

sudo apt update
sudo apt install dnsutils
for ns in ns1.child.example ns2.child.example; do
  dig @"$ns" dev.example.com SOA +norecurse
  dig @"$ns" dev.example.com NS +norecurse
  dig @"$ns" dev.example.com A +norecurse
  dig @"$ns" www.dev.example.com CNAME +norecurse
done

Her iki sunucunun yanıtında status: NOERROR, bayraklarda yetkili yanıtı belirten aa ve sorguladığınız kayıtların beklenen değerlerini görmelisiniz. NS kayıtları sağlayıcının atadığı sunucularla eşleşmeli; SOA bilgileri de sağlayıcının bölge ayarlarıyla tutarlı olmalıdır. Yanıt gelmezse önce panelde bölgenin yayımlandığını ve sorguda doğru sunucu adını kullandığınızı kontrol edin. Yanlış hedefi veya yayımlama sorununu düzelttikten sonra aynı sorguları tekrarlayın. İki sunucudan da doğru yanıt almadan üst bölgede devri başlatmayın; mevcut trafik bu aşamada eski DNS kayıtlarını kullanmaya devam eder.

Üst bölgeye NS kayıtlarını ekleyerek yetkiyi devredin

Yeni alt bölge iki yetkili sunucudan da doğru yanıt veriyorsa mevcut DNS hizmetindeki example.com bölgesine geçebilirsiniz. Buraya ekleyeceğiniz iki NS kaydı yalnızca dev.example.com ve altındaki adların yönetimini devreder. Alan adı kayıt firmasındaki Nameserver (yetkili ad sunucusu) ayarını değiştirmeyin; ana alanın yetkilileri ns1.parent.example ve ns2.parent.example olarak kalır.

Çakışan kayıtları ayırın

Mevcut panelde DNS > Zones yolundan example.com bölgesini açın. Records (kayıtlar) ekranında dev ve altında kalan adları filtreleyin. Devir öncesinde aldığınız kayıt dökümüyle yeni alt bölgeyi karşılaştırın. Taşınmamış bir MX veya TXT kaydı varsa önce yeni bölgeye ekleyin; devirden sonra bu kayıtlar da yeni yetkililerden sorgulanacaktır.

dev adında CNAME varsa aynı adda NS kayıtları bulunamaz. Eski hedefin yeni alt bölgede uygun kayıtlarla karşılandığını kontrol ettikten sonra, NS eklemeden hemen önce bu CNAME kaydını kaldırın. Alt bölgenin kökünde SOA ve NS kayıtları bulunduğu için buraya CNAME koyamazsınız. Bu örnekte kök adresi A kaydı karşılar.

Üst bölgedeki eski dev A/AAAA kayıtları ve www.dev gibi alt kayıtlar devirden sonra yanıt kaynağı olmaz. Geri dönüşte kullanmak üzere dökümlerini saklayın ve bunları NS ekleme işlemiyle aynı değişiklik aralığında kaldırın. Panel toplu yayımlamayı destekliyorsa silme ve ekleme işlemlerini birlikte yayımlayarak arada kayıtların eksik kaldığı bir süre oluşmasını önleyin. Diğer alt alanların kayıtlarına dokunmayın.

İki NS kaydını kaydedin

Aynı üst bölgede Records > Add record (kayıt ekleme) ekranını açın ve aşağıdaki kayıtları ayrı ayrı ekleyin. Name alanı kayıt adını, Type kayıt türünü, Value/Target ise hedefi belirtir. Hedef alanına IP adresi değil, yeni sağlayıcının atadığı ad sunucusu adını yazın. Geçiş sırasında önbellekte tutulma süresini kısa tutmak için TTL alanında, hizmet destekliyorsa, tabloda gösterilen 300 saniyeyi kullanın.

Temsili hedefleri gerçek sunucu adlarıyla değiştirin. Panel tam kayıt adı istiyorsa dev.example.com yazın; @ kullanmayın, çünkü bu ekranda ana alanı belirtir. Kaydettikten sonra kayıt listesinde iki kaydın da dev.example.com adına ait olduğunu ve hedeflerin alt bölgedeki NS kümesiyle eşleştiğini kontrol edin. Bu kontrol panelde doğru kayıtların bulunduğunu gösterir; kayıtların DNS üzerinden yayımlandığını sonraki bölümde sorgulayacağız.

Gerekirse eski yönetime dönün

Geri dönüş için üst bölgedeki bu iki NS kaydını kaldırıp dökümdeki eski kayıtları geri yükleyin; mümkünse değişiklikleri birlikte yayımlayın. Ardından üst yetkili sunucuları doğrudan sorgulayın: alt sunuculara yönlendirme yerine eski kayıtların yanıtlandığını görmelisiniz.

Delegasyonu önbelleğinde tutan çözümleyiciler bir süre yeni yetkililere gitmeye devam edebilir. Bu yüzden geri dönüşte alt bölgeyi hemen silmeyin; önbellekteki NS kayıtlarının TTL süresi dolana kadar gerekli kayıtları yanıtlar durumda tutun. Bu süreyi değerlendirirken yalnızca üst bölgeye eklediğiniz NS kayıtlarının değil, alt bölgenin yayımladığı NS kayıtlarının TTL değerini de dikkate alın.

Delegasyonu dig ile doğrulayın ve hataları ayırın

Üst yönlendirmeyi ve alt yetkilileri karşılaştırın

Önce üst bölgenin sorguları yeni yetkililere yönlendirdiğini kontrol edin. Ubuntu terminalinde aşağıdaki sorguları gerçek sunucu ve alan adlarınızla çalıştırın. +norecurse, sunucunun başka sunuculara başvurmadan yanıt vermesini ister; böylece doğrudan o sunucunun yayımladığı bilgiyi görürsünüz.

for ns in ns1.parent.example ns2.parent.example; do
  dig @"$ns" dev.example.com A +norecurse
done

Bu örnekte iki üst yetkilide de beklenen yanıt referral, yani alt yetkililere yönlendirmedir: status: NOERROR, boş ANSWER bölümü ve AUTHORITY bölümünde iki alt NS kaydı görünür. Bu yönlendirmede yetkili yanıtı belirten aa bayrağı beklenmez. Sunuculardan biri hâlâ eski A kaydını veriyorsa üst hizmetin yetkilileri aynı değişikliği henüz yayımlamıyor demektir. Panelde değişikliklerin yayımlandığını kontrol edip iki sunucuyu yeniden sorgulayın.

Üst yönlendirme doğruysa sıradaki kontrol, alt yetkililerin bölgeyi ve uygulama kayıtlarını aynı şekilde sunmasıdır. Aşağıdaki sorguları yine Ubuntu terminalinde, gerçek adlarınızla çalıştırın.

for ns in ns1.child.example ns2.child.example; do
  dig @"$ns" dev.example.com SOA +norecurse
  dig @"$ns" dev.example.com NS +norecurse
  dig @"$ns" dev.example.com A +norecurse
  dig @"$ns" www.dev.example.com CNAME +norecurse
done

Alt sunucuların ilgili yanıtlarında NOERROR ve aa ile birlikte SOA, aynı NS kümesi ve örnekteki A/CNAME değerlerini görmelisiniz. SOA içindeki serial bölge sürümünü belirtir. Sunucular arasında sürüm veya kayıt farkı kalıyorsa yeni sağlayıcının panelindeki yayımlama durumunu kontrol edin; yayımlama tamamlanınca sorguları tekrarlayın. SOA kaydındaki ana sunucu alanı tek bir ad içerir; iki NS hedefinin listelendiği yer NS kayıtlarıdır.

Önbelleği gerçek yayın hatasından ayırın

dig +trace dev.example.com A
dig dev.example.com A

Bu iki komutu aynı terminalde gerçek alan adınızla çalıştırın. İlk komut kökten başlayarak yetki zincirini izler; üst bölgeden alt NS sunucularına geçip beklenen A kaydına ulaşmalıdır. İkinci komut bilgisayarınızın kullandığı çözümleyiciyi, yani sizin adınıza sorgu yapan DNS hizmetini kullanır. İki yanıtı karşılaştırmak, yetkililerin yayımladığı bilgiyle önbellekteki bilgiyi ayırmanızı sağlar.

Temsili .example sunucuları internette çalışmaz. Ayrıca ağınız dış DNS sorgularını engelliyorsa +trace kesilebilir; bu tek başına delegasyon hatası değildir. Böyle bir durumda sorguyu dış DNS erişimine izin verilen başka bir ağdan tekrarlayın.

• Eski IP: Doğrudan yetkililer beklenen adresi veriyorsa çözümleyici yanıtındaki TTL’yi, yani kalan önbellek süresini inceleyin. Önceki TTL dolana kadar bekleyip aynı sorguyu tekrarlayın. Yalnızca önbellek farkı nedeniyle kayıtları yeniden değiştirmek gerekmez.
• SERVFAIL: Çözümleyici sorguyu başarıyla tamamlayamamıştır. Önce iki alt sunucuyu doğrudan sorgulayın. Biri REFUSED veriyorsa atanan NS adını ve bölgenin yayımlandığını kontrol edin. Yanlış NS hedefi veya yayımlama sorunu bulursanız yalnızca o sorunu düzeltin; ardından hem doğrudan sorguyu hem çözümleyici sorgusunu yineleyin. Zaman aşımında sunucunun erişilebilirliğini sağlayıcıyla inceleyin.
• NXDOMAIN: Sorgulanan adın bulunmadığını belirtir. Alt yetkili de aynı yanıtı veriyorsa yeni bölgenin Records (kayıtlar) ekranında eksik veya iki kez uzatılmış kayıt adını düzeltip doğrudan sorguyu tekrarlayın. Yetkili doğru yanıt veriyorsa çözümleyicide eski olumsuz yanıt tutuluyor olabilir; bunun önbellek süresi SOA bilgilerine bağlıdır. Yetkili alt sunucudan gelen NOERROR ile boş yanıt ise adın değil, istenen kayıt türünün yokluğu olabilir.

Glue ve DNSSEC gereken durumlar

Örnekte NS adları devredilen bölgenin dışındadır; bu delegasyon için üst bölgeye glue, yani ad sunucusuna ilk erişimi sağlayan yardımcı IP kaydı eklemek gerekmez. Hedef ns1.dev.example.com olsaydı ad sunucusunun adresini öğrenmek için yine aynı sunucuya ulaşmak gerekirdi. Bu döngüyü kırmak için üst hizmette bu adın glue A/AAAA kaydı, alt bölgede de karşılık gelen adres kaydı bulunmalıdır. Böyle bir kurulumda önce üst DNS sağlayıcınızın glue kaydını hangi ekrandan kabul ettiğini öğrenin.

DNSSEC, DNS yanıtlarının kaynağını ve bütünlüğünü dijital imzalarla doğrulamayı sağlayan mekanizmadır. Ana örnekte alt bölge imzasızdır; üst bölgede bu alt bölgeye ait DS, yani imza güven bağlantısı kaydı bulunmamalıdır. Üst bölgenin kendisinin imzalı olması, alt bölgenin de mutlaka imzalı olmasını gerektirmez.

İki alt yetkili doğru yanıt verdiği hâlde DNSSEC doğrulaması yapan çözümleyici SERVFAIL üretiyorsa üst yetkilide dig @ns1.parent.example dev.example.com DS +norecurse ile DS varlığını kontrol edin; komutta gerçek sunucu ve alan adınızı kullanın. Eski DS veya geçersiz alt bölge imzaları bu hataya yol açabilir. DS’yi gelişigüzel silmek yerine mevcut DS değerini ve imzalama durumunu kaydedin, sağlayıcının anahtar geçişi ya da imzayı kapatma sırasını izleyin. Geri dönüşün de DS ile alt bölgedeki anahtarların uyumunu koruması gerekir. İşlemden sonra DNSSEC doğrulaması yapan çözümleyicide yeniden sorgulayın; beklenen kaydın SERVFAIL olmadan dönmesi gerekir.

Sık Sorulan Sorular

Alt alanı devretmek için alan adı transferi gerekir mi?

Hayır. Alan adı transferi, alan adının kayıtlı olduğu firmayı değiştirmektir; alt alan adı DNS delegasyonu ise yalnızca belirli bir alt alanın ve onun altındaki adların DNS yönetimini ayırır. example.com aynı kayıt firmasında ve mevcut DNS hizmetinde kalabilir. Alt ekibe alan adı kayıt hesabınızı veya transfer için kullanılan EPP yetkilendirme kodunu vermeniz gerekmez.

NS kayıtlarını ekleyince SSL sertifikası otomatik gelir mi?

Hayır. DNS delegasyonu, HTTPS bağlantısını güvenli hâle getirmek için kullanılan TLS sertifikasını, yaygın adıyla SSL sertifikasını oluşturmaz. dev.example.com için sertifikayı web sunucusunda veya uygulamayı yayımlayan hizmette ayrıca ayarlamanız gerekir. Hizmet otomatik sertifika sağlıyorsa bu, delegasyonun değil o hizmetin özelliğidir.

Sertifikanın hangi adları kapsadığını da kontrol edin: *.example.com sertifikası dev.example.com adını kapsar, ancak www.dev.example.com adını kapsamaz. DNS kayıtları üzerinden alan adı doğrulaması kullanıyorsanız sertifika aracına yalnızca gerekli alt bölgeye erişen kimlik bilgileri verin.

Ana alan adının e-postası etkilenir mi?

example.com için posta sunucularını belirleyen MX kayıtları ve ilgili diğer kayıtlar değişmiyorsa normalde etkilenmez. Ancak ana alanın MX hedefi mail.dev.example.com gibi devredilen dalın içindeyse bu hedefin adres kayıtları artık alt bölgeden yanıtlanır. Taşıma sırasında eksik bırakılan bir kayıt, ana alanın posta teslimini de bozabilir.

Bu nedenle yalnızca kayıtların bulunduğu yere değil, hedeflerine de bakın. Ana alanın posta ayarları devredilen dala başvuruyorsa önceki bölümdeki doğrudan sorgu yöntemini kullanarak ilgili hedeflerin A ve varsa AAAA kayıtlarını iki yeni yetkiliden sorgulayın; beklenen posta sunucusu adreslerini görmelisiniz. kullanici@dev.example.com adresleri kullanılacaksa bu alt alanın posta kayıtları da yeni alt bölgede yönetilir.

Alt ekibin yetkisini yalnızca bu bölgeyle nasıl sınırlarım?

Yeni DNS hizmetinin kullanıcı ve rol ayarlarında ekibe yalnızca dev.example.com bölgesi için kayıt düzenleme izni verin; ana hesap parolasını paylaşmayın. Otomasyonun DNS hizmetine bağlanmasını sağlayan API erişim anahtarlarını da aynı bölgeyle sınırlandırın. Sağlayıcı bölge bazında yetki sunmuyorsa alt bölge için ayrı bir hesap kullanın. DNS erişim yetkilerini sınırlandırma yaklaşımını hem kullanıcı hesaplarına hem otomasyon anahtarlarına uygulayın.

Bu ekip, devredilen dalın kayıtlarını değiştirebilir ve DNS doğrulamasıyla o dal için sertifika alınmasını sağlayabilir. Bu yüzden verdiğiniz yetki, yalnızca site adresini değiştirmekle sınırlı değildir. Üst bölgedeki NS kayıtlarının kontrolünü sizde tutun. Ekip veya hizmet değiştiğinde boşta kalan DNS kayıtları bırakmamak için delegasyonun kaldırılmasını veya yeni yetkililere taşınmasını da erişim kapatma planına ekleyin.

Devir sonrası kontrol listesi

Alt alan adı DNS delegasyonunu yalnızca site açıldığı için tamamlanmış saymayın. Aşağıdaki listeyle DNS yanıtlarını, uygulamanın çalışmasını ve yönetim sorumluluğunu birlikte kontrol edin. Sorgularda temsili adlar yerine kendi alanınızı ve sağlayıcınızın verdiği sunucu adlarını kullanın.

• İki alt yetkili de doğru yanıt veriyor: Ubuntu terminalinde önceki bölümdeki doğrudan SOA, NS ve adres sorgularını her iki sunucu için çalıştırın. Yanıtlarda yetkili yanıtı belirten aa bayrağını, aynı NS kümesini ve beklenen uygulama adreslerini görmelisiniz. Üst bölgenin iki yetkili sunucusu da aynı alt NS hedeflerine yönlendirmelidir; yalnızca bir sunucudan doğru yanıt almak yeterli değildir.
• Uygulamaya gerçek adlarıyla erişiliyor: Tarayıcıda örnekteki dev.example.com ve kullanılıyorsa www.dev.example.com yerine kendi adreslerinizi HTTPS üzerinden açın. Beklenen sitenin geldiğini, sertifikanın ziyaret ettiğiniz adı kapsadığını ve giriş gibi temel bir işlemin çalıştığını kontrol edin. DNS doğru çözüldüğü hâlde yanlış site açılıyorsa NS kayıtlarını değiştirmek yerine web sunucusunun bu alan adını hangi siteyle eşleştirdiğini inceleyin.
• DNSSEC durumu planla uyumlu: Bu imzasız örnekte üst bölgede dev.example.com için DS kaydı bulunmamalıdır. İmzalı bir kurulum kullanıyorsanız DS kaydının alt bölgenin imzalama anahtarlarıyla eşleştiğini ve DNSSEC doğrulaması yapan çözümleyicide sorgunun başarılı olduğunu kontrol edin. Doğrudan yetkili sunucudan doğru kayıtları almak, tek başına imza zincirinin sağlam olduğunu göstermez.
• Kayıtların sorumlusu ve düzenleme yeri belli: Yönetim notunuza üst bölgedeki yetki devri kayıtlarından kimin, alt bölgedeki uygulama ve doğrulama kayıtlarından kimin sorumlu olduğunu yazın. Her kayıt grubunun hangi DNS panelinde düzenleneceğini de belirtin. Yeni DNS hizmetinin kullanıcı ve erişim anahtarı listesini gözden geçirin; alt ekibin izinlerinin yalnızca devredilen bölgeyle sınırlı olduğunu kontrol edin.
• Geri dönüş için gereken bilgiler erişilebilir: Devir öncesi kayıt dökümünü, eski TTL değerlerini ve değişiklik listesini saklayın. Geri dönüşte üst bölgedeki NS kayıtları kaldırılırken hangi eski kayıtların geri ekleneceği açık olsun. Önbellekte tutulan yetki devri kayıtlarının süresi dolmadan yeni alt bölgeyi silmeyin; geri dönüş boyunca hem eski kayıtlar hem de yeni alt bölge gerekli yanıtları vermeye devam etsin.

Bir sonraki adım, izleme ve müdahale sorumlularını belirlemektir. İki alt yetkili sunucunun DNS yanıtlarını ve uygulamanın HTTPS erişimini kimin izleyeceğini, uyarıların kime gideceğini ve acil durumda üst bölgedeki yetki devri NS kayıtlarını kimin değiştirebileceğini kaydedin. Böylece sonraki ekip veya sağlayıcı değişiminde hangi ayarın nerede yapılacağı ve gerektiğinde kimin müdahale edeceği belli olur.