Azure DNS ile Domain Yönetimi: Microsoft Ekosistemi İçin Rehber

Azure DNS, Microsoft Azure altyapısı üzerinde çalışan, zone yönetimini ve kayıt güncellemelerini Azure Resource Manager'a entegre eden bir DNS hizmetidir. Domain'lerinizi Azure portalı, Azure CLI veya REST API üzerinden yönetebilir; diğer Azure kaynaklarıyla aynı kimlik ve erişim denetimi mekanizmalarını kullanabilirsiniz. Tescil hizmeti sunmaz; var olan domain'lerinizi Azure nameserver'larına delege etmenizi sağlar.

Microsoft ekosisteminde çalışan bir altyapı için bu entegrasyon tek bir kontrol düzlemi sunar. Azure Virtual Machines, App Services, Azure Kubernetes Service gibi bileşenlerin DNS yapılandırmaları aynı portal üzerinden yönetilince operasyonel yük azalır. Ancak bu kolaylık bağımlılıkla birlikte gelir; tüm DNS altyapınızı tek bir bulut sağlayıcısına kilitlemek anlamına da gelebilir.

Yalnızca Azure kullanan organizasyonlar için bu bağımlılık kabul edilebilir bir ödünleşimdir. Çok bulutlu veya hibrit ortamlarda çalışıyorsanız bağımsız bir DNS sağlayıcısı daha fazla esneklik sunabilir. Kararı verirken yalnızca bugünkü altyapıya değil, ilerleyen dönemde platform çeşitlendirme ihtimaline de bakmak faydalıdır.

Mimari ve anycast altyapısı

Azure DNS her public zone için dört nameserver atar. Bu nameserver'lar ns1-01.azure-dns.com, ns2-01.azure-dns.net, ns3-01.azure-dns.org ve ns4-01.azure-dns.info şeklinde farklı üst düzey domain'ler altında dağıtılır. Farklı TLD'lere yayılmış bu yapı, tek bir TLD'de yaşanacak sorunun tüm çözümlemeyi etkilemesini engeller. Zone başına atanan nameserver'lar sabittir; siz seçemezsiniz, her yeni zone farklı bir set alabilir.

Altyapısı anycast yönlendirme üzerine kuruludur. Sorgular Microsoft'un küresel ağ düğümlerine dağıtılır; kullanıcı hangi coğrafyada olursa olsun en yakın düğüm yanıt verir. Küresel kullanıcı tabanı olan servisler için sorgu gecikmesini düşürür. Dağıtık mimarisi, tek bir noktada yoğunlaşmadığı için DDoS yüklerine karşı da görece dayanıklılık sağlar.

Ücretlendirme zone başına ve sorgu başına olmak üzere iki eksende yapılır. Her zone aylık sabit bir ücrete tabidir; belirli sorgu eşiğini geçince ek ücret uygulanır. Küçük ölçekli altyapılar için bu maliyet ihmal edilebilirdir. Yüz binlerce kayıt barındıran veya yüksek sorgu hacmi üreten büyük portföylerde maliyet hesaplamasını önceden yapmak gerekir; beklenmedik fatura sürprizleri bu ölçekte gerçekleşebilir.

Zone oluşturma ve kayıt yönetimi

Public zone açmak için Azure portalında DNS Zones bölümüne girip kaynak grubu seçilir, zone adı tanımlanır. Zone oluşturulunca Azure otomatik olarak dört nameserver atar. Bu nameserver'ları registrar paneline yazarak delegasyonu tamamlarsınız. Azure zone içeriklerini yönetir; tescil işlemini yapmaz, dolayısıyla domain'in hâlâ bir registrar'da kayıtlı olması gerekir.

Azure DNS'te kayıtlar "record set" olarak gruplandırılır. Aynı ada sahip birden fazla A kaydı tek bir record set içinde tutulur; tüm girişler aynı TTL değerini paylaşır. Bu yapı yönetimi basitleştirir, ancak aynı hostname altındaki kayıtlara bağımsız TTL tanımlama esnekliğini ortadan kaldırır. Farklı yaşam döngülerine sahip kayıtları birbirinden ayırt etmek zorundaysanız farklı hostname'ler kullanmak kaçınılmaz olur.

Alias kayıtları, Azure DNS'e özgü bir özelliktir. A, AAAA ve CNAME kayıtlarının doğrudan Azure Public IP adresine, Traffic Manager profiline veya CDN endpoint'ine işaret etmesini sağlar. Apex domain'de standart CNAME kullanılamaz; bu, ALIAS/ANAME kaydının çözmeye çalıştığı kısıttır; CNAME flattening mantığıyla benzer sonucu Azure ekosistemi içinde yerel olarak sağlayan alias kayıtları bu kısıtı çözer. Ancak bu özellik yalnızca Azure kaynakları için çalışır; harici bir endpoint'e alias yapılamaz.

CLI ile kayıt yönetiminde az network dns record-set komut ailesi kullanılır. Bir TTL değişikliği için önce mevcut record set'i okuyup ardından güncellemek gerekir; aksi hâlde mevcut kayıtların üstüne yazılma riski doğar. CI/CD pipeline'larına DNS güncelleme adımı eklerken bu sıralama önem taşır; otomasyon hatası üretim zone'unu bozabilir.

Zone dosyası aktarımı BIND formatında desteklenir. az network dns zone import komutuyla mevcut zone dosyasını Azure'a aktarabilirsiniz. Aktarım öncesinde dosyayı doğrulayıp eksik veya hatalı kayıtları temizlemek, geçiş sonrası sorunları en aza indirir.

Private DNS zones: dahili ağlar ve hibrit senaryolar

Azure Private DNS, sanal ağlar içindeki kaynakların birbirini özel ad alanı üzerinden bulmasını sağlar. Public internet'e açık olmayan bu zone'lar, şirket içi ağlarla kurulan VPN veya ExpressRoute bağlantılarında da kullanılabilir. Dahili servisler için ayrı bir naming convention belirleyip bunu public DNS'ten tamamen izole tutmak mümkündür; kurumsal tarafta aynı ayrım private DNS yapılandırmasında kurulur.

Private zone'lar sanal ağlara "virtual network link" eklenerek bağlanır. Autoregistration seçeneği etkinleştirilirse Virtual Machines oluşturulduğunda ve silindiğinde DNS kayıtları otomatik güncellenir. Dinamik altyapıda bu otomasyon değer taşır; ancak VM adlarının öngörülebilir ve çakışmayan biçimde tanımlandığı ortamlarda daha güvenli çalışır. Rastgele isimlendirilmiş VM'ler autoregistration'ı kaotik hâle getirebilir.

Split-horizon DNS senaryosunda private zone, aynı domain adını farklı IP adresleriyle çözümler: dahili kullanıcılar internal IP'yi, dış kullanıcılar public IP'yi alır. Azure bu konfigürasyonu destekler; iç ve dış zone'ları ayrı ayrı yönetmek gerekir. İki zone arasındaki senkronizasyonu Azure otomatik sağlamaz; kayıt değişikliklerini her iki tarafa da elle veya otomasyon aracılığıyla uygulamak zorunlu olur.

Private DNS zone'ların önemli bir kısıtı, sanal ağ başına bağlanabilecek zone sayısı ile tek bir zone'a bağlanabilecek sanal ağ sayısının belirli limitlerle sınırlı olmasıdır. Geniş çaplı hub-spoke mimarisinde bu limitlere erken ulaşılabilir; Azure belgelerindeki güncel limit tablolarını mimari tasarım aşamasında incelemek yerinde olur.

Erişim denetimi ve rol tabanlı yetkilendirme

Azure DNS kayıtlarına erişim, Azure Role-Based Access Control (RBAC) ile yönetilir. DNS Zone Contributor rolü zone içindeki kayıtları oluşturma ve silme yetkisi verir; ancak zone'u silme yetkisi içermez. Zone silme yetkisi için DNS Zone Contributor üstünde Owner veya Contributor rolü gereklidir. Farklı ekiplerin aynı zone üzerinde çalışması gerektiğinde bu ayrımı doğru yapılandırmak zone kazalarını önler.

Belirli record set'lere kısıtlı erişim verilmek istendiğinde özel rol tanımı gerekir. Örneğin yalnızca TXT kayıtlarını okuyup yazabilecek bir rol, yerleşik rollerin dışına çıkarak elle oluşturulur. Domain sahipliği doğrulama süreçlerinde veya e-posta güvenlik kayıtları için farklı ekiplere sınırlı yetki tanımlamak bu yöntemle mümkün olur.

Yönetim düzlemi ve veri düzlemi burada örtüşür. Azure DNS'te zone ve kayıt yönetimi management plane üzerinden gerçekleşir; yani Azure Active Directory kimlik bilgileriyle denetlenir. Bu merkezi kimlik doğrulama, DNS değişikliklerini denetleme günlüğüyle izlemeyi kolaylaştırır. Kim hangi kaydı ne zaman değiştirdi sorusu Activity Log üzerinden yanıtlanabilir.

DNS geçişi: Azure'a taşırken veya Azure'dan çıkarken

Mevcut zone'u başka bir sağlayıcıdan Azure'a taşımanın en güvenli yolu TTL değerlerini önce düşürmektir. Zone'u aktarmadan birkaç gün önce A, CNAME ve MX gibi kritik kayıtların TTL'ini 300 saniyeye veya daha kısa bir değere indirirseniz nameserver değişikliği sonrasında eski önbelleklerin etkisi kısa sürede solar. Web sitesi taşıma sırasındaki DNS geçiş planı, bu hazırlık aşamasını adım adım ele alır.

Azure'a geçiş sırasında her iki sağlayıcıda da zone aynı anda aktif tutulmamalıdır; yetki çakışması beklenmedik çözümleme sonuçları doğurabilir. Nameserver'ları Azure'a güncelledikten sonra eski sağlayıcıdaki zone'u aktif bırakın, ancak kayıt değişikliklerini artık yalnızca Azure tarafında yapın. Propagasyon tamamlanınca eski zone'u kapatabilirsiniz.

E-posta kayıtları geçiş sırasında özel dikkat gerektirir. MX kaydının yanlış veya eksik geçirilmesi posta teslimini doğrudan bozar. Mail sunucusu taşırken DNS kesintisini önleme başlığında anlatılan paralel çalışma ve doğrulama yöntemi, DNS geçişi sırasında MX kayıtlarının devamlılığını korumak için de uygulanabilir.

Azure'dan çıkış da benzer disiplin ister. Hedef sağlayıcıda zone hazırlanır, kayıtlar aktarılır, TTL düşürülür; ardından nameserver'lar güncellenir. Azure portalında zone'u silmek, nameserver delegasyonu kaldırılmadan yapılırsa eski nameserver'lara gelen sorgular boş yanıt döndürür. Sıralama önemlidir: önce delegasyon güncellenir, sonra Azure zone'u silinir.

Sınırlar ve doğru kullanım durumu

Azure DNS yalnızca public ve private zone barındırır; domain tescili sunmaz. Domain'inizi Azure üzerinden tescil ettirmek istiyorsanız App Service Domain hizmetini değerlendirmeniz gerekir; bu hizmet arka planda bir registrar kullanır. DNS yönetimi ile tescil farklı kavramlardır ve Azure'da farklı hizmetlerle karşılanır.

Trafik yönlendirme özellikleri sınırlıdır. Coğrafi yönlendirme, ağırlıklı round-robin veya latency tabanlı yönlendirme için Traffic Manager kullanmak gerekir. Azure DNS bu yönlendirme mantığını kendi içinde taşımaz. Gelişmiş trafik yönetimi ihtiyaçları olan servisler için DNS ve Traffic Manager'ı birlikte yapılandırmak kaçınılmaz olur.

Çok bulutlu mimari planlayanlar için alias kayıtlarının yalnızca Azure kaynaklarına işaret edebildiğini peşinen bilmek gerekir; başka bulut sağlayıcılarının servislerine bu yöntemle ulaşılamaz. Standart A ve CNAME kayıtları çalışır, ancak alias avantajlarından yararlanılamaz. Azure'a özgü özelliklere gerçekten bağımlı olup olmak istemediğinizi bu noktayı göz önünde bulundurarak değerlendirin.

Azure DNS, Microsoft ekosistemi içinde kalan altyapılar için dengeli bir seçimdir. Entegrasyon kolaylığı, RBAC desteği ve anycast altyapısı somut avantajlar sunar; tescilden bağımsız çalışması ve alias kısıtı ise önceden bilinmesi gereken sınırlardır. Altyapınızı büyük ölçüde Azure üzerinde çalıştırıyorsanız DNS yönetimini de aynı platformda konsolide etmek operasyonel karmaşıklığı azaltır.

Geçiş veya büyüme planlarınız platformu çeşitlendirmeyi içeriyorsa DNS sağlayıcınızı bağımsız tutmak uzun vadeli esneklik sağlar. Mevcut altyapıyı değiştirmeden önce zone dışa aktarımını test etmek, ileride oluşabilecek taşıma maliyetini baştan görmenize yardımcı olur.