Udostępnij przez

Prywatne punkty końcowe rozpoznawania i zestawy reguł usługi Azure DNS

Z tego artykułu dowiesz się o składnikach usługi Azure DNS Private Resolver. Omówiono przychodzące punkty końcowe, wychodzące punkty końcowe i zestawy reguł przesyłania dalej DNS. Opisano właściwości i ustawienia tych składników, a przykłady służą do ich używania.

Architektura usługi Azure DNS Private Resolver została podsumowana na poniższej ilustracji. W tej przykładowej sieci, resolver DNS jest wdrażany w sieci wirtualnej centrum, który współdziała z siecią wirtualną szprychą.

Diagram przedstawiający architekturę prywatnego resolwera

Rysunek 1: Przykładowa sieć typu hub and spoke z resolverem DNS

  • pl-PL: Linki zestawów reguł są aprowizowane w zestawie reguł przesyłania dalej DNS zarówno do VNets piasty, jak i szprych, umożliwiając zasobom w obu VNets rozpoznawanie niestandardowych przestrzeni nazw DNS przy użyciu reguł przesyłania dalej DNS.
  • Prywatna strefa DNS jest również wdrażana i połączona z siecią centralną VNet, umożliwiając zasobom w tej sieci rozpoznawanie rekordów w strefie.
  • Sieć węzła VNet rozpoznaje rekordy w strefie prywatnej, używając reguły przekazywania DNS, która przekazuje zapytania dotyczące strefy prywatnej do przychodzącego adresu VIP punktu końcowego w sieci wirtualnej centrum VNet.
  • Na rysunku pokazano również sieć lokalną połączoną z usługą ExpressRoute, z serwerami DNS skonfigurowanymi do przekazywania zapytań dla prywatnej strefy Azure do VIP punktu końcowego dla ruchu przychodzącego. Aby uzyskać więcej informacji na temat włączania hybrydowego rozpoznawania nazw DNS przy użyciu prywatnego rozpoznawania nazw DNS platformy Azure, zobacz Rozwiązywanie problemów z platformą Azure i domenami lokalnymi.

Uwaga

Połączenie peeringowe pokazane na diagramie nie jest wymagane do rozwiązywania nazw. Sieci wirtualne połączone z zestawem reguł przekazywania DNS używają tych reguł przy rozwiązywaniu nazw, niezależnie od tego, czy powiązany VNet jest połączony z VNetem zestawu reguł.

Punkty końcowe wejściowe

Jak sugeruje nazwa, przychodzące punkty końcowe wchodzą do platformy Azure. Przychodzące punkty końcowe zapewniają adres IP do przekazywania zapytań DNS z lokalizacji lokalnych i innych poza siecią wirtualną. Zapytania DNS wysyłane do przychodzącego punktu końcowego są rozwiązywane przy użyciu usługi Azure DNS. Prywatne strefy DNS, które są połączone z siecią wirtualną, w której został udostępniony punkt końcowy przychodzącego ruchu, są rozwiązywane przez ten punkt końcowy.

Adres IP skojarzony z przychodzącym punktem końcowym jest zawsze częścią prywatnej przestrzeni adresowej sieci wirtualnej, w której wdrożono prywatny program rozpoznawania. Żadne inne zasoby nie mogą istnieć w tej samej podsieci z przychodzącym punktem końcowym.

Statyczne i dynamiczne adresy IP punktów końcowych

Adres IP przypisany do przychodzącego punktu końcowego może być statyczny lub dynamiczny. Jeśli wybierzesz statyczny, nie możesz wybrać zastrzeżonego adresu IP w podsieci. Jeśli wybierzesz dynamiczny adres IP, zostanie przypisany piąty dostępny adres IP w podsieci. Na przykład 10.10.0.4 jest piątym adresem IP w podsieci 10.10.0.0/28 (.0, .1, .2, .3, .4). Jeśli przychodzący punkt końcowy zostanie zrekonfigurowany, ten adres IP może się zmienić, ale zwykle ponownie jest używany 5. adres IP w podsieci. Dynamiczny adres IP nie zmienia się, chyba że przychodzący punkt końcowy zostanie ponownie aprowizowany. W poniższym przykładzie określono statyczny adres IP:


Zrzut ekranu przedstawiający sposób wybierania statycznego adresu IP.

W poniższym przykładzie pokazano aprowizowanie przychodzącego punktu końcowego z wirtualnym adresem IP (VIP) 10.10.0.4 wewnątrz podsieci snet-E-inbound w sieci wirtualnej z przestrzenią adresową 10.10.0.0/16.

Zrzut ekranu pokazujący przychodzące punkty końcowe.

Zewnętrzne punkty końcowe

Punkty końcowe wychodzą z platformy Azure i mogą być połączone z zestawami reguł przekazywania DNS.

Wychodzące punkty końcowe są również częścią przestrzeni adresowej wirtualnej sieci prywatnej, w której wdrożono prywatny rozwiązywacz. Wychodzący punkt końcowy jest skojarzony z podsiecią, ale nie jest przypisany adres IP w taki sposób, jak przychodzący punkt końcowy. Żadne inne zasoby nie mogą istnieć w tej samej podsieci z punktem końcowym wyjściowym. Poniższy zrzut ekranu przedstawia punkt końcowy wychodzący wewnątrz podsieci snet-E-outbound.

Wyświetlanie wychodzących punktów końcowych

Zestawy regułów przekazywania DNS

Zestawy reguł przesyłania dalej DNS umożliwiają określenie co najmniej jednego niestandardowego serwera DNS w celu odpowiadania na zapytania dotyczące określonych przestrzeni nazw DNS. Poszczególne reguły w zestawie reguł określają sposób rozpoznawania tych nazw DNS. Zestawy reguł mogą być również połączone z co najmniej jedną siecią wirtualną, umożliwiając zasobom w sieciach wirtualnych używanie skonfigurowanych reguł przesyłania dalej.

Zestawy reguł mają następujące skojarzenia:

  • Pojedynczy zestaw reguł może być skojarzony z maksymalnie 2 punktami końcowymi wychodzącymi należącymi do tego samego prywatnego serwera DNS. Nie można go skojarzyć z 2 punktami końcowymi w dwóch różnych instancjach prywatnego resolvera DNS.
  • Zestaw reguł może mieć do 1000 reguł przekazywania DNS.
  • Zestaw reguł może być połączony z maksymalnie 500 sieciami wirtualnymi w tym samym regionie.

Nie można połączyć zestawu reguł z siecią wirtualną w innym regionie. Aby uzyskać więcej informacji na temat zestawu reguł i innych limitów prywatnego rozpoznawania nazw, zobacz Jakie są limity użycia dla usługi Azure DNS?.

Po połączeniu zestawu reguł z siecią wirtualną zasoby w tej sieci wirtualnej używają reguł przesyłania dalej DNS włączone w zestawie reguł. Połączone sieci wirtualne nie muszą być połączone równorzędnie z siecią wirtualną, w której znajduje się punkt końcowy ruchu wychodzącego, ale można je tak skonfigurować. Ta konfiguracja jest powszechna w układzie piasty i szprych. W tym scenariuszu typu "hub and spoke", wirtualna sieć "spoke" nie musi być połączona z prywatną strefą DNS, aby móc rozwiązywać rekordy zasobów w tej strefie. W takim przypadku reguła przekazywania dla strefy prywatnej wysyła zapytania do przychodzącego punktu końcowego centrum sieci wirtualnej. Na przykład: azure.contoso.com do 10.10.0.4.

Poniższy zrzut ekranu przedstawia zestaw reguł przesyłania dalej DNS połączony z siecią wirtualną typu "spoke": myeastspoke.

Wyświetl łącza zestawu reguł

Linki sieci wirtualnych dla zestawów reguł przekazywania DNS umożliwiają zasobom w innych sieciach wirtualnych korzystanie z reguł przekazywania podczas rozwiązywania nazw DNS. Sieć wirtualna z prywatnym resolverem musi być również połączona z każdą prywatną strefą DNS, dla której istnieją reguły.

Na przykład zasoby w sieci wirtualnej myeastspoke mogą rozpoznawać rekordy w prywatnej strefie azure.contoso.com DNS, jeśli:

  • Zestaw reguł dostarczony w myeastvnet został powiązany z myeastspoke
  • Reguła zestawu reguł jest skonfigurowana i włączona w połączonym zestawie reguł w celu rozwiązania azure.contoso.com przy użyciu przychodzącego punktu końcowego w myeastvnet

Uwaga

Możesz również połączyć zestaw reguł z siecią wirtualną w innej subskrypcji platformy Azure. Jednak określona grupa zasobów musi znajdować się w tym samym regionie co prywatny program rozpoznawania nazw.

Reguły

Reguły przesyłania dalej DNS (reguły zestawu reguł) mają następujące właściwości:

Nieruchomość opis
Nazwa reguły Nazwa twojej reguły. Nazwa musi zaczynać się literą i może zawierać tylko litery, cyfry, podkreślenia i kreski.
Nazwa domeny Przestrzeń nazw DNS zakończona kropką, w której ma zastosowanie reguła. Przestrzeń nazw musi mieć zero etykiet (dla symbolu wieloznacznego) lub od 1 do 34 etykiet. Na przykład contoso.com. ma dwie etykiety.1
Docelowy adres IP:Port Miejsce docelowe przekazywania. Co najmniej jeden adres IP i porty serwerów DNS używanych do rozpoznawania zapytań DNS w określonej przestrzeni nazw.
Stan reguły Stan reguły: Włączone lub wyłączone. Jeśli reguła jest wyłączona, jest ona ignorowana.

Obsługiwane są nazwy domen z jednąetykietą.

Jeśli dopasuje się wiele reguł, zostanie użyty najdłuższy pasujący prefiks.

Jeśli na przykład masz następujące reguły:

Nazwa reguły Nazwa domeny Docelowy adres IP:Port Stan reguły
Contoso contoso.com. 10.100.0.2:53 Włączona
AzurePrivate azure.contoso.com. 10.10.0.4:53 Włączona
Symbole wieloznaczne . 10.100.0.2:53 Włączona

Zapytanie dla secure.store.azure.contoso.com pasuje do reguły AzurePrivate dla azure.contoso.com oraz do reguły Contoso dla contoso.com, ale reguła AzurePrivate ma pierwszeństwo, ponieważ prefiks azure.contoso jest dłuższy niż contoso.

Ważne

Jeśli reguła znajduje się w zestawie reguł, który ma jako docelowy prywatny punkt końcowy resolvera przychodzącego, nie należy łączyć zestawu reguł z siecią wirtualną, w której znajduje się ten prywatny punkt końcowy. Ta konfiguracja może powodować pętle rozpoznawania nazw DNS. Na przykład: W poprzednim scenariuszu nie należy dodawać do myeastvnet linku do zestawu reguł, ponieważ przychodzący punkt końcowy w 10.10.0.4 jest skonfigurowany w myeastvnet i jest obecna reguła, która rozwiązuje azure.contoso.com przy użyciu przychodzącego punktu końcowego. Ta konfiguracja prowadzi do przekazywania zapytań DNS w sieci myeastvnet dla azure.contoso.com z powrotem do myeastvnet, co powoduje pętlę. Linki zestawu reguł mają na celu umożliwienie sieciom wirtualnym, które nie mogą prawidłowo rozpoznać nazwy DNS, do rozpoznania nazwy poprzez przekazywanie żądań.

Reguły przedstawione w tym artykule to przykłady reguł, których można użyć w określonych scenariuszach. Użyte przykłady nie są wymagane. Zachowaj ostrożność podczas testowania reguł przekazywania.

Jeśli w zestawie reguł dołączysz regułę z symbolami wieloznacznymi, upewnij się, że docelowa usługa DNS może rozpoznać publiczne nazwy DNS. Niektóre usługi platformy Azure mają zależności od rozpoznawania nazw publicznych.

Przetwarzanie reguł

  • Jeśli dla reguły wprowadzono wiele serwerów DNS jako miejsce docelowe, zostanie użyty pierwszy wprowadzony adres IP, chyba że nie odpowie. Jeśli pierwszy serwer DNS nie odpowiada, następny serwer DNS na liście jest używany do następnej próby. Algorytm wykładniczego odstępu jest używany do określania, czy docelowy adres IP jest responsywny.
  • Niektóre domeny są ignorowane podczas używania reguły wieloznacznych na potrzeby rozpoznawania nazw DNS, ponieważ są one zarezerwowane dla usług platformy Azure. Zobacz Konfiguracja strefy DNS usług platformy Azure, aby uzyskać listę domen zarezerwowanych. Nazwy DNS z dwiema etykietami wymienione w tym artykule (na przykład: windows.net, azure.com, azure.net, windowsazure.us) są zarezerwowane dla usług platformy Azure.

Ważne

  • Nie można wprowadzić adresu IP usługi Azure DNS 168.63.129.16 jako docelowego adresu IP reguły. Próba dodania tego adresu IP powoduje wyświetlenie błędu: Wyjątek podczas dodawania żądania reguły.
  • Nie używaj przychodzącego adresu IP punktu końcowego prywatnego rozpoznawania nazw jako miejsca docelowego przekazywania dla stref, które nie są połączone z siecią wirtualną, w której aprowizowany jest prywatny program rozpoznawania nazw.

Opcje projektowania

Sposób, w jaki wdrażasz zestawy reguł przekazywania i przychodzące punkty końcowe w architekturze typu hub and spoke, w dużej mierze zależy od projektu Twojej sieci. Dwie opcje konfiguracji zostały krótko omówione w poniższych sekcjach. Aby uzyskać bardziej szczegółowe omówienie z przykładami konfiguracji, zobacz Architektura prywatnego resolvera.

Połączenie zestawu reguł przekazywania z siecią wirtualną VNet umożliwia przekazywanie DNS w tej sieci VNet. Jeśli na przykład zestaw reguł zawiera regułę do przekazywania zapytań do przychodzącego punktu końcowego prywatnego resolvera, tego typu reguła może służyć do umożliwienia rozpoznawania stref prywatnych powiązanych z siecią VNet przychodzącego punktu końcowego. Ta konfiguracja może być używana, gdy sieć wirtualna typu Hub jest połączona ze strefą prywatną i chcesz umożliwić rozwiązywanie strefy prywatnej w sieciach wirtualnych typu Spoke, które nie są połączone ze strefą prywatną. W tym scenariuszu rozwiązywanie DNS strefy prywatnej jest przeprowadzane przez przychodzący punkt końcowy w sieci VNet koncentratora.

Scenariusz projektowania linków do zbioru reguł najlepiej nadaje się do rozproszonej architektury DNS, w której ruch sieciowy jest rozłożony w sieci platformy Azure i może być unikatowy w niektórych lokalizacjach. W tym projekcie można kontrolować rozwiązywanie DNS we wszystkich sieciach wirtualnych powiązanych z zestawem reguł, modyfikując jeden zestaw reguł.

Uwaga

Jeśli używasz opcji linkowania zestawu reguł i istnieje reguła przekazywania, której miejscem docelowym jest wejściowy punkt końcowy, nie łącz zestawu reguł przesyłania dalej z siecią wirtualną centrum. Połączenie tego typu zestawu reguł z tą samą siecią VNet, w której wdrażany jest przychodzący punkt końcowy, może spowodować pętlę rozpoznawania nazw DNS.

Przychodzące punkty końcowe jako niestandardowy DNS

Przychodzące punkty końcowe mogą przetwarzać przychodzące zapytania DNS i można je skonfigurować jako niestandardowy system DNS dla sieci wirtualnej. Ta konfiguracja może zastąpić wystąpienia, w których używasz własnego serwera DNS jako niestandardowego systemu DNS w sieci wirtualnej.

Niestandardowy scenariusz projektowania DNS najlepiej nadaje się do scentralizowanej architektury DNS, w której rozpoznawanie nazw DNS i przepływ ruchu sieciowego jest głównie do koncentratora VNetu i jest kontrolowany z centralnej lokalizacji.

Aby rozwiązać prywatną strefę DNS z sieci wirtualnej w topologii szprychowej przy użyciu tej metody, sieć wirtualna, w której istnieje przychodzący punkt końcowy, musi być połączona ze strefą prywatną. Sieć wirtualna centralna może być (opcjonalnie) połączona z zestawem reguł przekazywania. Jeśli zestaw reguł jest połączony z centrum, cały ruch DNS wysyłany do przychodzącego punktu końcowego jest przetwarzany przez zestaw reguł.

Następne kroki

  • Last updated on