Microsoft AZ-700: Azure DNS ve Ad Çözümlemesi — Çalışma kılavuzu

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure Network Engineer AZ-700 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Azure DNS: genel (public) bölgeler, özel (private) bölgeler ve ödünleşimler

Azure, sanal ağ düzlemiyle sıkı bir şekilde entegre edilmiş hem genel (public) DNS barındırma hem de özel (private) DNS çözümlemesi sunar ve bunlar arasında seçim yapmak kapsam, kontrol, maliyet ve operasyonel ek yüke bağlıdır. Genel (Public) Azure DNS bölgeleri (Azure DNS’te barındırılır), internet’e yönelik adlar için uygundur ve küresel anycast uç noktalarından, öngörülebilir API tabanlı yönetimden ve sorgu başına ölçeklenmeden yararlanır. Özel (Private) DNS bölgeleri, yalnızca bağlantılı VNet’ler içindeki özel IP adreslerine çözümlenen bölge adları oluşturmanıza olanak tanır; Azure içi ad çözümlemesi için DNS VM’leri çalıştırma ve bakımını yapma ihtiyacını ortadan kaldırır ve belirli PaaS özel uç noktalarıyla entegre edildiğinde otomatik kayıt yönetimini destekler. Temel ödünleşim kontroldür: özel DNS sunucuları (Windows DNS, BIND), VM/yönetim ek yükü ve dayanıklılık sorumluluğu maliyeti karşılığında mutlak esneklik (koşullu iletme, gelişmiş ilkeler ve AD entegreli SRV/CNAME davranışı) sağlar. Performans seçimleri gecikme süresi ve maliyet karşılaştırmasına dayanır: yönetilen Azure DNS hizmetleri bakımı azaltır ve genel (public) sorgular için küresel çözümleme hızı sağlarken, hub’da yerleşik DNS ileticileri veya çözümleyici cihazları hibrit performansı artırabilir ve ilkeleri uygulayabilir ancak işlem ve kullanılabilirlik maliyeti ekler. Yaygın tuzaklar arasında, çözümleme gerektiren her VNet’e bir Private DNS bölgesini bağlamayı unutmak, şirket içinden (on-prem) Azure’a adları taşırken yetki devirlerini (delegation) geçirmeyi başaramamak ve açık DNS kayıtları veya iletme olmadan otomatik genel-özel ayrık ufuk (split-horizon) davranışı beklemek yer alır.

Azure DNS (Public): küresel anycast, yönetilen API, bölge/sorgu başına faturalandırma.
Private DNS zones: VNet kapsamlı çözümleme, desteklenen PaaS için otomatik özel kayıt oluşturma.
App Gateway WAF_v2: modern WAF özellikleri ve v2 ölçeklendirme modeli için önerilir.
Azure Firewall (Standard/Policy): merkezi DNS proxy seçeneği; maliyet ekler ancak ilkeyi merkezileştirir.
Özel DNS (VM tabanlı): maksimum kontrol, daha yüksek operasyon ve kullanılabilirlik maliyetleri.

Özel (Private) DNS bölgeleri, özel uç nokta kayıtları ve adlandırma stratejileri

Genel olarak barındırılan hizmetleri özel uç noktalara dönüştürdüğünüzde veya sunucuları Azure’a geçirdiğinizde, DNS koordinasyon noktası haline gelir. Özel uç noktalar, istemcilerin kullanmasını istediğiniz genel (public) FQDN ile eşleşmesi gereken özel DNS bölgelerine NIC düzeyinde A kayıtları kaydeder; doğru desen, genel ad alanını (örneğin, contoso.com) yansıtan özel bölgeler oluşturmak veya hizmete özgü privatelink bölgeleri (platform hizmetleri için) kullanmak ve ardından ya otomatik kaydı etkinleştirmek ya da FQDN’yi uç noktanın özel IP’sine eşleyen manuel A/CNAME kayıtları oluşturmaktır. Kapsam önemlidir: özel bir bölgeyi tek bir VNet’e bağlamak, çözümlemeyi o VNet ile sınırlar; hub-and-spoke tasarımları, bölgenin tüm spoke’lara bağlanmasını veya spoke’lardan bir hub çözümleyiciye DNS iletme kullanılmasını gerektirir. Tipik bir geçiş tuzağı, Azure istemcileri özel bir IP’ye çözümlenirken genel (public) DNS’in eski şirket içi (on-prem) IP’yi göstermeye devam etmesidir; ayrık beyin (split-brain) karışıklığını önlemek için, temiz geçiş adımları planlayın—genel kayıtları yalnızca özel DNS ve iletme doğrulandıktan sonra güncelleyin veya aynı ad için açık bir özel bölge ile ayrık ufuk (split-horizon) adlandırması kullanın. Sertifikalar ve ana bilgisayar (host) başlıkları uyumlu olmalıdır: Application Gateway’in özel bir arka uca (backend) uçtan uca TLS gerçekleştirmesini bekliyorsanız, arka uç sertifikasının CN/SAN’ının, ağ geçidinin Host başlığı olarak gönderdiği ana bilgisayar adıyla (hostname) eşleştiğinden emin olun; aksi takdirde arka uç TLS başarısız olur.

Azure Private Resolver ve hibrit ad çözümleme desenleri

Azure Private Resolver, DNS VM’lerine sahip olmadan Azure VNet’leri ile şirket içi (on-premises) ağlar arasında yönetilen, ölçeklenebilir DNS iletmesini sağlar. Tasarım desenleri tipik olarak çözümleyici (resolver) uç noktalarını bir hub VNet’e yerleştirir: gelen (inbound) uç noktalar, Azure özel bölgeleri için şirket içinden (VPN/ExpressRoute aracılığıyla) sorguları alırken, giden (outbound) uç noktalar Azure sorgularını yalnızca dahili adlar için şirket içi DNS sunucularına iletir. Çözümleyici kural kümeleri, belirli ad alanları için koşullu iletmeyi (örneğin, contoso.internal → şirket içi DNS IP’leri) tanımlar ve VNet’lerle ilişkilendirilebilir; küresel kurumsal dağıtımlar için kural yönetimini hub’da merkezileştirir ve trafiği spoke’lardan hub çözümleyiciye eşler (peer) veya yönlendirirsiniz. Performans ve maliyet ödünleşimleri arasında, dayanıklılık ve gecikme süresi için bölgeler arasında birden çok gelen uç nokta sağlamak (maliyet ekler) veya eşleme (peering) ile tek bölgeli çözümleyici uç noktalarını kabul etmek ancak daha yüksek bölgeler arası gecikme süresini göze almak yer alır. Yaygın tuzaklar: şirket içi koşullu ileticileri çözümleyicinin gelen IP’lerini gösterecek şekilde güncellememek, çözümleyici uç noktalarına giden DNS TCP/UDP 53’ü engelleyen ağ güvenlik grubu (NSG) kurallarını yanlış yapılandırmak ve Azure tarafından sağlanan DNS’in (168.63.129.16) şirket içine iletim yapacağını varsaymak—koşullu iletme için açık çözümleyici yapılandırması gereklidir.

DNS portları: Tipik çözümleme ve bölge aktarımları için 53 UDP ve 53 TCP’ye izin verilmelidir.
Çözümleyici (Resolver) uç noktaları: hub VNet’lerde dağıtın; NSG ve güvenlik duvarının gelen DNS’e izin verdiğinden emin olun.

Özel DNS sunucuları, DNS proxy’leme ve operasyonel tuzaklar

Özel DNS sunucuları (Windows DNS etki alanı denetleyicileri veya Linux BIND), Active Directory entegrasyonu, karmaşık koşullu yönlendirme veya gelişmiş DNS ilkeleri gerektiğinde hala mantıklıdır; ancak yama yönetimi, HA kümelemesi, yedekleme ve ölçeklendirme gibi operasyonel sorumluluklar getirirler. Operasyonel yükü azaltan alternatifler, Azure içi çözümleme için Azure Private DNS bölgeleri ve yönlendirme ilkelerini merkezileştirmek için Azure Private Resolver veya Azure Firewall DNS proxy’dir. DNS proxy’leri (Azure Firewall DNS proxy özelliği veya üçüncü taraf NVA’lar), DNS’i yakalayıp seçili çözümleyicilere yönlendirebilir; bu da ilke yönetimini ve günlük kaydını basitleştirir ancak tek hata noktaları ve ek gecikme ekleyebilir. Önemli tasarım kararları arasında bir hub’da VM tabanlı yönlendiriciler kullanmak (daha düşük maliyet, daha yüksek bakım) ile Azure Private Resolver (yönetilen, daha iyi ölçeklenebilirlik) arasında seçim yapmak, gecikme/dayanıklılık için bölgeler arasında kaç tane çözümleyici uç noktası dağıtılacağı ve otomatik private endpoint DNS kaydının etkinleştirilip etkinleştirilmeyeceği yer alır. Mühendislerin sık yaptığı hatalar, DNS çözümlemesi için yalnızca VNet peering’e güvenmek (peering, Private DNS bölgelerini otomatik olarak paylaşmaz), Private Endpoint’e DNS kayıtlarını otomatik olarak kaydetme iznini vermeyi unutmak ve bir ağ geçidi üzerinden uçtan uca TLS uygularken sertifika zincirlerini doğrulamayı ihmal etmektir. Tüm bunlar, üretim ortamında ad çözümlemesini veya güvenli bağlantıları bozar.

Pratik Problem: Kullanım Senaryosu

Senaryo: Fabrikam Inc., çok bölgeli bir hub-and-spoke Azure ağı işletmektedir. East US bölgesindeki hub, bir Azure Firewall (Standard) içerir ve bir Traffic Manager profili, internet kullanıcılarını iki bölgedeki Application Gateway WAF_v2 örneklerine yönlendirir. İki App Service örneği, www.fabrikam.com’u barındırır ve her biri şirket içinden (on-prem) taşınmış olup kendi bölgesel spoke’larında private endpoint’lere sahiptir.

Zorluk: Şirket içi (on-prem) istemciler ve Azure spoke’ları, geçişten sonra www.fabrikam.com’u App Service private endpoint’lerine çözümleyebilmelidir. Application Gateway, uçtan uca TLS’yi etkinleştirmek için host başlıklarını korumalı ve DNS çözümlemesi bölgeler arasında dayanıklı olmalıdır.

Önerilen Yaklaşım:

Hub’da fabrikam.com adında bir Azure Private DNS bölgesi dağıtın ve bunu hem bölgesel spoke VNet’lerine hem de hub VNet’ine bağlayın; www.fabrikam.com için private endpoint IP’lerine işaret eden A kayıtları ekleyin (veya App Service private endpoint’leri için otomatik kaydı etkinleştirin).
Hub’da Azure Private Resolver gelen (inbound) uç noktaları dağıtın (gerekirse dayanıklılık için bölge başına bir tane) ve şirket içi (on-prem) koşullu yönlendiricileri, fabrikam.com sorgularını çözümleyici gelen IP’lerine yönlendirecek şekilde yapılandırın.
Application Gateway WAF_v2 HTTP ayarlarını 443 numaralı bağlantı noktasında HTTPS kullanacak şekilde yapılandırın, arka uç (backend) host başlığını www.fabrikam.com olarak ayarlayın ve arka uç sağlık yoklamalarının (health probe) sertifika CN/SAN’ı ile eşleşen bir host başlığıyla HTTPS kullandığından emin olun.
Şirket içinden (on-prem) ve spoke’lardan DNS sorguları çalıştırarak özel IP’lerin döndüğünden emin olun ve sertifika CN/SAN’ını ve yoklama (probe) başarısını kontrol ederek Application Gateway uçtan uca TLS’yi doğrulayın.

Gerekçe: Özel DNS ve çözümleyici işlevselliğini hub’da merkezileştirmek, tek bir doğruluk kaynağı sağlar ve hibrit koşullu yönlendirmeyi basitleştirir; özel bölgeyi tüm VNet’lere bağlamak ve ağ geçidinin doğru host başlığını kullanmasını sağlamak, uçtan uca TLS için sertifika doğrulamasını korur ve operasyonel yönetilebilirlik, performans ve dayanıklılık arasında bir denge kurar.

← Hibrit Ağ · Tüm alanlar · Ağ Güvenliği →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →