Microsoft AZ-700: Azure DNS i rozwiązywanie nazw — Przewodnik do nauki

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

Część Microsoft Azure Network Engineer AZ-700 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Azure DNS: strefy publiczne, strefy prywatne i kompromisy

Azure oferuje zarówno publiczny hosting DNS, jak i prywatne rozpoznawanie nazw DNS, ściśle zintegrowane z płaszczyzną sieci wirtualnej, a wybór między nimi jest kwestią zakresu, kontroli, kosztów i narzutu operacyjnego. Publiczne strefy Azure DNS (hostowane w usłudze Azure DNS) są odpowiednie dla nazw dostępnych z internetu i korzystają z globalnych punktów końcowych anycast, przewidywalnego zarządzania przez API oraz skalowalności w zależności od liczby zapytań. Prywatne strefy DNS pozwalają na autorytatywną obsługę nazw stref, które są rozpoznawane wyłącznie na prywatne adresy IP wewnątrz połączonych sieci VNet; eliminują one potrzebę uruchamiania i utrzymywania maszyn wirtualnych z DNS na potrzeby rozpoznawania nazw wewnątrz Azure i wspierają automatyczne zarządzanie rekordami po zintegrowaniu z niektórymi prywatnymi punktami końcowymi PaaS. Głównym kompromisem jest kontrola: niestandardowe serwery DNS (Windows DNS, BIND) dają absolutną elastyczność — przekierowywanie warunkowe, zaawansowane polityki i zachowanie rekordów SRV/CNAME zintegrowane z AD — kosztem narzutu związanego z maszynami wirtualnymi/zarządzaniem i odpowiedzialnością za odporność. Wybory dotyczące wydajności sprowadzają się do dylematu opóźnienie a koszt: zarządzane usługi Azure DNS redukują koszty utrzymania i zapewniają globalną szybkość rozpoznawania dla zapytań publicznych, podczas gdy forwardery DNS lub urządzenia rozpoznające nazwy rezydujące w hubie mogą poprawić wydajność hybrydową i wymuszać polityki, ale zwiększają koszty zasobów obliczeniowych i dostępności. Częste pułapki to zapominanie o połączeniu strefy Private DNS z każdą siecią VNet, która potrzebuje rozpoznawania nazw, niepowodzenie w migracji delegacji podczas przenoszenia nazw ze środowiska lokalnego do Azure oraz oczekiwanie automatycznego zachowania typu split-horizon (public-to-private) bez jawnych rekordów DNS lub przekierowywania.

Azure DNS (Public): globalny anycast, zarządzane API, rozliczanie za strefę/zapytanie.
Private DNS zones: rozpoznawanie nazw w zakresie VNet, automatyczne tworzenie rekordów prywatnych dla wspieranych usług PaaS.
App Gateway WAF_v2: zalecany dla nowoczesnych funkcji WAF i modelu skalowania v2.
Azure Firewall (Standard/Policy): opcja centralnego proxy DNS; zwiększa koszt, ale centralizuje polityki.
Niestandardowy DNS (na maszynach wirtualnych): maksymalna kontrola, wyższe koszty operacyjne i dostępności.

Prywatne strefy DNS, rekordy prywatnych punktów końcowych i strategie nazewnictwa

Gdy konwertujesz publicznie hostowane usługi na prywatne punkty końcowe lub migrujesz serwery do Azure, DNS staje się punktem koordynacji. Prywatne punkty końcowe rejestrują rekordy A na poziomie karty sieciowej (NIC) w prywatnych strefach DNS, które muszą odpowiadać publicznej nazwie FQDN, jakiej mają używać klienci; prawidłowym wzorcem jest tworzenie prywatnych stref, które odzwierciedlają publiczną przestrzeń nazw (na przykład contoso.com) lub używanie specyficznych dla usługi stref privatelink (dla usług platformy), a następnie włączenie automatycznej rejestracji lub ręczne utworzenie rekordów A/CNAME mapujących FQDN na prywatny adres IP punktu końcowego. Zakres ma znaczenie: połączenie prywatnej strefy z jedną siecią VNet ogranicza rozpoznawanie nazw do tej sieci; architektury hub-and-spoke wymagają połączenia strefy ze wszystkimi sieciami spoke lub użycia przekierowywania DNS ze spoke’ów do resolwera w hubie. Typową pułapką migracyjną jest pozostawienie publicznego DNS wskazującego na stary adres IP w środowisku lokalnym, podczas gdy klienci w Azure rozpoznają nazwę na prywatny adres IP; aby uniknąć problemów typu split-brain, należy zaplanować czyste kroki przełączenia — zaktualizować publiczne rekordy dopiero po zweryfikowaniu prywatnego DNS i przekierowywania lub użyć nazewnictwa split-horizon z jawną strefą prywatną dla tej samej nazwy. Certyfikaty i nagłówki hosta muszą być zgodne: jeśli oczekujesz, że Application Gateway będzie realizować szyfrowanie TLS end-to-end do prywatnego backendu, upewnij się, że CN/SAN certyfikatu backendu odpowiada nazwie hosta, którą brama wysyła w nagłówku Host; w przeciwnym razie szyfrowanie TLS z backendem zakończy się niepowodzeniem.

Azure Private Resolver i wzorce hybrydowego rozpoznawania nazw

Azure Private Resolver umożliwia zarządzane, skalowalne przekierowywanie DNS pomiędzy sieciami VNet w Azure a sieciami lokalnymi bez konieczności posiadania maszyn wirtualnych z serwerami DNS. Wzorce projektowe zazwyczaj umieszczają punkty końcowe resolwera w sieci VNet typu hub: przychodzące punkty końcowe odbierają zapytania ze środowiska lokalnego (przez VPN/ExpressRoute) dotyczące prywatnych stref Azure, podczas gdy wychodzące punkty końcowe przekierowują zapytania z Azure do lokalnych serwerów DNS dla nazw wyłącznie wewnętrznych. Zestawy reguł resolwera definiują przekierowywanie warunkowe dla określonych przestrzeni nazw (na przykład contoso.internal → adresy IP lokalnych serwerów DNS) i mogą być powiązane z sieciami VNet; w przypadku globalnych wdrożeń korporacyjnych centralizuje się zarządzanie regułami w hubie i stosuje peering lub routing ruchu ze spoke’ów do resolwera w hubie. Kompromisy między wydajnością a kosztem obejmują udostępnienie wielu przychodzących punktów końcowych w różnych regionach w celu zapewnienia odporności i niskich opóźnień (co zwiększa koszt) lub akceptację punktów końcowych resolwera w jednym regionie z peeringiem, ale z wyższym opóźnieniem międzyregionalnym. Częste pułapki: brak aktualizacji warunkowych forwarderów w środowisku lokalnym, aby wskazywały na adresy IP przychodzących punktów końcowych resolwera, błędna konfiguracja reguł sieciowych grup zabezpieczeń (NSG), które blokują ruch DNS TCP/UDP na porcie 53 do punktów końcowych resolwera, oraz założenie, że DNS dostarczany przez Azure (168.63.129.16) będzie przekierowywał zapytania do środowiska lokalnego — do przekierowywania warunkowego wymagana jest jawna konfiguracja resolwera.

Porty DNS: porty 53 UDP i 53 TCP muszą być dozwolone dla typowego rozpoznawania nazw i transferów stref.
Punkty końcowe resolwera: wdrażaj w sieciach VNet typu hub; upewnij się, że NSG i zapora sieciowa zezwalają na przychodzący ruch DNS.

Niestandardowe serwery DNS, proxy DNS i pułapki operacyjne

Niestandardowe serwery DNS (kontrolery domeny Windows DNS lub BIND na Linuksie) wciąż mają sens, gdy wymagana jest integracja z Active Directory, złożone warunkowe przesyłanie dalej lub zaawansowane zasady DNS; wprowadzają one jednak obowiązki operacyjne — instalowanie poprawek, klastrowanie w celu zapewnienia wysokiej dostępności (HA), tworzenie kopii zapasowych i skalowanie. Alternatywy, które redukują obciążenie operacyjne, to strefy Azure Private DNS do rozpoznawania nazw wewnątrz Azure oraz Azure Private Resolver lub proxy DNS w Azure Firewall do centralizacji zasad przesyłania dalej. Proxy DNS (funkcja proxy DNS w Azure Firewall lub urządzenia NVA firm trzecich) mogą przechwytywać i przekazywać zapytania DNS do wybranych resolverów, co upraszcza zasady i logowanie, ale może wprowadzać pojedyncze punkty awarii i dodatkowe opóźnienia. Kluczowe decyzje projektowe obejmują wybór między serwerami przekazującymi opartymi na maszynach wirtualnych w hubie (niższy koszt, więcej konserwacji) a Azure Private Resolver (usługa zarządzana, lepsza skalowalność), liczbę punktów końcowych resolvera do wdrożenia w różnych regionach w celu zapewnienia niskich opóźnień i odporności na awarie, oraz czy włączyć automatyczną rejestrację DNS dla prywatnych punktów końcowych. Częste błędy inżynierów to poleganie wyłącznie na VNet peering w kwestii rozpoznawania nazw DNS (peering nie udostępnia automatycznie stref Private DNS), zapominanie o nadaniu uprawnień prywatnemu punktowi końcowemu do automatycznej rejestracji rekordów DNS oraz zaniedbywanie walidacji łańcuchów certyfikatów podczas implementacji szyfrowania TLS end-to-end przez bramę — wszystko to prowadzi do awarii rozpoznawania nazw lub bezpiecznych połączeń w środowisku produkcyjnym.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Fabrikam Inc. zarządza wieloregionową siecią Azure w architekturze hub-and-spoke. Hub w regionie East US zawiera Azure Firewall (Standard), a profil Traffic Manager kieruje użytkowników internetowych do instancji Application Gateway WAF_v2 w dwóch regionach. Dwie instancje App Service hostują www.fabrikam.com, każda przeniesiona ze środowiska lokalnego (on-prem) z prywatnymi punktami końcowymi w swoich regionalnych szprychach.

Wyzwanie: Klienci lokalni (on-prem) i szprychy w Azure muszą rozpoznawać nazwę www.fabrikam.com na prywatne punkty końcowe App Service po migracji, Application Gateway musi zachowywać nagłówki hosta, aby umożliwić szyfrowanie TLS end-to-end, a rozpoznawanie nazw DNS musi być odporne na awarie między regionami.

Zalecane podejście:

Wdróż strefę Azure Private DNS o nazwie fabrikam.com w hubie i połącz ją z sieciami VNet w obu regionalnych szprychach oraz z siecią VNet huba; dodaj rekordy A dla www.fabrikam.com wskazujące na adresy IP prywatnych punktów końcowych (lub włącz automatyczną rejestrację dla prywatnych punktów końcowych App Service).
Wdróż punkty końcowe dla ruchu przychodzącego Azure Private Resolver w hubie (po jednym na region dla zapewnienia odporności, jeśli to konieczne) i skonfiguruj lokalne warunkowe serwery przesyłania dalej, aby przekazywały zapytania o fabrikam.com na adresy IP przychodzących punktów końcowych resolvera.
Skonfiguruj ustawienia HTTP w Application Gateway WAF_v2, aby używać protokołu HTTPS na porcie 443, ustaw nagłówek hosta zaplecza na www.fabrikam.com i upewnij się, że sondy kondycji zaplecza używają HTTPS z nagłówkiem hosta pasującym do CN/SAN certyfikatu.
Zweryfikuj, wykonując zapytania DNS ze środowiska lokalnego i ze szprych, aby upewnić się, że zwracają prywatne adresy IP, oraz sprawdź szyfrowanie TLS end-to-end w Application Gateway, kontrolując CN/SAN certyfikatu i pomyślność sond.

Uzasadnienie: Centralizacja funkcji prywatnego DNS i resolvera w hubie zapewnia jedyne źródło prawdy i upraszcza hybrydowe warunkowe przesyłanie dalej; połączenie strefy prywatnej ze wszystkimi sieciami VNet i zapewnienie, że brama używa prawidłowego nagłówka hosta, zachowuje walidację certyfikatu dla szyfrowania TLS end-to-end, równoważąc zarządzalność operacyjną, wydajność i odporność na awarie.

← Sieci hybrydowe · Wszystkie domeny · Bezpieczeństwo sieciowe →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →