Rozpoznawanie nazw dla zasobów w sieciach wirtualnych platformy Azure

  • Artykuł

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Platforma Azure może służyć do hostowania rozwiązań IaaS, PaaS i hybrydowych. Aby ułatwić komunikację między maszynami wirtualnymi i innymi zasobami wdrożonym w sieci wirtualnej, może być konieczne umożliwienie im komunikowania się ze sobą. Użycie łatwo zapamiętanych i niezmieniających się nazw upraszcza proces komunikacji, a nie poleganie na adresach IP.

Gdy zasoby wdrożone w sieciach wirtualnych muszą rozpoznawać nazwy domen na wewnętrzne adresy IP, mogą użyć jednej z czterech metod:

Używany typ rozpoznawania nazw zależy od tego, w jaki sposób zasoby muszą komunikować się ze sobą. W poniższej tabeli przedstawiono scenariusze i odpowiednie rozwiązania do rozpoznawania nazw:

Uwaga

Strefy prywatne usługi Azure DNS są preferowanym rozwiązaniem i zapewnia elastyczność zarządzania strefami i rekordami DNS. Aby uzyskać więcej informacji, zobacz Using Azure DNS for private domains (Korzystanie z usługi Azure DNS na potrzeby domen prywatnych).

Uwaga

Jeśli używasz usługi Azure Provided DNS, odpowiedni sufiks DNS zostanie automatycznie zastosowany do maszyn wirtualnych. W przypadku wszystkich innych opcji należy użyć w pełni kwalifikowanych nazw domen (FQDN) lub ręcznie zastosować odpowiedni sufiks DNS do maszyn wirtualnych.

Scenariusz Rozwiązanie Sufiks DNS
Rozpoznawanie nazw między maszynami wirtualnymi znajdującymi się w tej samej sieci wirtualnej lub wystąpieniach ról usług Azure Cloud Services w tej samej usłudze w chmurze. Prywatne strefy usługi Azure DNS lub rozpoznawanie nazw udostępnianych przez platformę Azure Nazwa hosta lub nazwa FQDN
Rozpoznawanie nazw między maszynami wirtualnymi w różnych sieciach wirtualnych lub wystąpieniach ról w różnych usługach w chmurze. Prywatne strefy usługi Azure DNS, usługa Azure DNS Private Resolver lub zarządzane przez klienta serwery DNS przekazujące zapytania między sieciami wirtualnymi do rozpoznawania przez platformę Azure (serwer proxy DNS). Zobacz Rozpoznawanie nazw przy użyciu własnego serwera DNS. Tylko nazwa FQDN
Rozpoznawanie nazw z usługi aplikacja systemu Azure Service (aplikacja internetowa, funkcja lub bot) przy użyciu integracji sieci wirtualnej z wystąpieniami ról lub maszynami wirtualnymi w tej samej sieci wirtualnej. Prywatny rozpoznawanie nazw usługi Azure DNS lub serwery DNS zarządzane przez klienta przesyłają zapytania między sieciami wirtualnymi do rozpoznawania przez platformę Azure (serwer proxy DNS). Zobacz Rozpoznawanie nazw przy użyciu własnego serwera DNS. Tylko nazwa FQDN
Rozpoznawanie nazw z usługi App Service Web Apps do maszyn wirtualnych w tej samej sieci wirtualnej. Prywatny rozpoznawanie nazw usługi Azure DNS lub serwery DNS zarządzane przez klienta przesyłają zapytania między sieciami wirtualnymi do rozpoznawania przez platformę Azure (serwer proxy DNS). Zobacz Rozpoznawanie nazw przy użyciu własnego serwera DNS. Tylko nazwa FQDN
Rozpoznawanie nazw z usługi App Service Web Apps w jednej sieci wirtualnej do maszyn wirtualnych w innej sieci wirtualnej. Prywatny rozpoznawanie nazw usługi Azure DNS lub serwery DNS zarządzane przez klienta przesyłają zapytania między sieciami wirtualnymi do rozpoznawania przez platformę Azure (serwer proxy DNS). Zobacz Rozpoznawanie nazw przy użyciu własnego serwera DNS. Tylko nazwa FQDN
Rozpoznawanie lokalnych nazw komputerów i usług z maszyn wirtualnych lub wystąpień ról na platformie Azure. Prywatny program rozpoznawania nazw DNS platformy Azure lub serwery DNS zarządzane przez klienta (lokalny kontroler domeny, lokalny kontroler domeny tylko do odczytu lub pomocniczy serwer DNS synchronizowany przy użyciu transferów stref, na przykład). Zobacz Rozpoznawanie nazw przy użyciu własnego serwera DNS. Tylko nazwa FQDN
Rozpoznawanie nazw hostów platformy Azure z komputerów lokalnych. Przekazywanie zapytań do serwera proxy DNS zarządzanego przez klienta w odpowiedniej sieci wirtualnej, serwer proxy przekazuje zapytania do platformy Azure w celu rozwiązania problemu. Zobacz Rozpoznawanie nazw przy użyciu własnego serwera DNS. Tylko nazwa FQDN
Zwrotna usługa DNS dla wewnętrznych adresów IP. Prywatne strefy usługi Azure DNS, rozpoznawanie nazw zapewniane przez platformę Azure, prywatny rozpoznawanie nazw usługi Azure DNS lub rozpoznawanie nazw przy użyciu własnego serwera DNS. Nie dotyczy
Rozpoznawanie nazw między maszynami wirtualnymi lub wystąpieniami ról znajdującymi się w różnych usługach w chmurze, a nie w sieci wirtualnej. Nie dotyczy. Połączenie ivity między maszynami wirtualnymi i wystąpieniami ról w różnych usługach w chmurze nie jest obsługiwana poza siecią wirtualną. Nie dotyczy

Rozpoznawanie nazw udostępnianych przez platformę Azure

Dostępne na platformie Azure rozpoznawanie nazw zapewnia tylko podstawowe funkcje autorytatywne dns. Platforma Azure zarządza nazwami i rekordami strefy DNS, jeśli używasz usługi DNS dostarczonej przez platformę Azure. Nie można kontrolować nazw stref DNS ani cyklu życia rekordów DNS. Jeśli potrzebujesz w pełni funkcjonalnego rozwiązania DNS dla sieci wirtualnych, możesz użyć stref prywatnych usługi Azure DNS z zarządzanymi przez klienta serwerami DNS lub prywatnym programem Rozpoznawanie nazw DNS platformy Azure.

Oprócz rozpoznawania publicznych nazw DNS platforma Azure udostępnia wewnętrzne rozpoznawanie nazw dla maszyn wirtualnych i wystąpień ról, które znajdują się w tej samej sieci wirtualnej lub usłudze w chmurze. Maszyny wirtualne i wystąpienia w usłudze w chmurze mają ten sam sufiks DNS, więc sama nazwa hosta jest wystarczająca. Jednak w sieciach wirtualnych wdrożonych przy użyciu klasycznego modelu wdrażania różne usługi w chmurze mają różne sufiksy DNS. W takiej sytuacji potrzebna jest nazwa FQDN do rozpoznawania nazw między różnymi usługami w chmurze. W sieciach wirtualnych wdrożonych przy użyciu modelu wdrażania usługi Azure Resource Manager sufiks DNS jest spójny we wszystkich maszynach wirtualnych w sieci wirtualnej, więc nazwa FQDN nie jest wymagana. Nazwy DNS można przypisać do maszyn wirtualnych i interfejsów sieciowych. Mimo że rozpoznawanie nazw zapewnianych przez platformę Azure nie wymaga żadnej konfiguracji, nie jest to odpowiedni wybór dla wszystkich scenariuszy wdrażania, jak opisano w poprzedniej tabeli.

Uwaga

W przypadku korzystania z ról internetowych i procesów roboczych usług w chmurze można również uzyskać dostęp do wewnętrznych adresów IP wystąpień ról przy użyciu interfejsu API REST usługi Azure Service Management. Aby uzyskać więcej informacji, zobacz Dokumentację interfejsu API REST usługi Service Management. Adres jest oparty na nazwie roli i numerze wystąpienia.

Funkcje

Rozpoznawanie nazw udostępnianych przez platformę Azure obejmuje następujące funkcje:

  • Łatwość użytkowania. Nie jest wymagana żadna konfiguracja.

  • Wysoka dostępność. Nie musisz tworzyć klastrów własnych serwerów DNS i zarządzać nimi.

  • Możesz użyć usługi z własnymi serwerami DNS, aby rozpoznać nazwy hostów lokalnych i platformy Azure.

  • Rozpoznawanie nazw między maszynami wirtualnymi i wystąpieniami ról w ramach tej samej usługi w chmurze można używać bez konieczności używania nazwy FQDN.

  • Rozpoznawanie nazw między maszynami wirtualnymi w sieciach wirtualnych korzystających z modelu wdrażania usługi Azure Resource Manager można używać bez konieczności używania nazwy FQDN. Sieci wirtualne w klasycznym modelu wdrażania wymagają nazwy FQDN podczas rozpoznawania nazw w różnych usługach w chmurze.

  • Możesz użyć nazw hostów, które najlepiej opisują wdrożenia, zamiast pracować z automatycznie wygenerowanymi nazwami.

Kwestie wymagające rozważenia

Punkty, które należy wziąć pod uwagę podczas korzystania z rozpoznawania nazw udostępnianych przez platformę Azure:

  • Nie można zmodyfikować sufiksu DNS utworzonego na platformie Azure.

  • Wyszukiwanie DNS jest ograniczone do sieci wirtualnej. Nazw DNS utworzonych dla jednej sieci wirtualnej nie można rozpoznać z innych sieci wirtualnych.

  • Nie można ręcznie zarejestrować własnych rekordów.

  • Usługi WINS i NetBIOS nie są obsługiwane. Maszyny wirtualne nie są widoczne w Eksploratorze Windows.

  • Nazwy hostów muszą być zgodne z systemem DNS. Nazwy muszą używać tylko wartości 0-9, a-z i "-" i nie mogą zaczynać się ani kończyć ciągiem "-".

  • Ruch zapytań DNS jest ograniczany dla każdej maszyny wirtualnej. Ograniczanie przepustowości nie powinno mieć wpływu na większość aplikacji. Jeśli zaobserwowano ograniczanie żądań, upewnij się, że buforowanie po stronie klienta jest włączone. Aby uzyskać więcej informacji, zobacz Konfiguracja klienta DNS.

  • Użyj innej nazwy dla każdej maszyny wirtualnej w sieci wirtualnej, aby uniknąć problemów z rozpoznawaniem nazw DNS.

  • Tylko maszyny wirtualne w pierwszych 180 usługach w chmurze są rejestrowane dla każdej sieci wirtualnej w klasycznym modelu wdrażania. Ten limit nie dotyczy sieci wirtualnych w usłudze Azure Resource Manager.

  • Adres IP usługi Azure DNS to 168.63.129.16. Ten adres jest statycznym adresem IP i nie zmienia się.

Zagadnienia dotyczące odwrotnego systemu DNS

Odwrotny system DNS dla maszyn wirtualnych jest obsługiwany we wszystkich sieciach wirtualnych opartych na usłudze Azure Resource Manager. Rekordy odwrotnego systemu DNS zarządzanego przez platformę Azure (PTR) formularza [vmname].internal.cloudapp.net są automatycznie dodawane do po uruchomieniu maszyny wirtualnej i usuwane po zatrzymaniu maszyny wirtualnej (cofnięto przydział). Zobacz poniższy przykład:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

Internal.cloudapp.net odwrotna strefa DNS jest zarządzana platformą Azure i nie można jej bezpośrednio wyświetlać ani edytować. Wyszukiwanie do przodu w nazwie FQDN formularza [vmname].internal.cloudapp.net jest rozpoznawane jako adres IP przypisany do maszyny wirtualnej.

Jeśli strefa prywatna usługi Azure DNS jest połączona z siecią wirtualną za pomocą linkusieci wirtualnej, a funkcja automatycznego wyrejestrowania jest włączona w tym linku, a następnie odwrotne zapytania DNS zwracają dwa rekordy. Jeden rekord ma postać [vmname].[ privatednszonename] i drugi to formularz [vmname].internal.cloudapp.net. Zobacz poniższy przykład:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

Gdy są zwracane dwa rekordy PTR, jak pokazano wcześniej, wyszukiwanie do przodu każdej nazwy FQDN zwraca adres IP maszyny wirtualnej.

Wyszukiwanie wsteczne DNS jest ograniczone do danej sieci wirtualnej, nawet jeśli jest ona równorzędna z innymi sieciami wirtualnymi. Odwrotne zapytania DNS dla adresów IP maszyn wirtualnych znajdujących się w równorzędnych sieciach wirtualnych zwracają NXDOMAIN.

Uwaga

Odwrotne rekordy DNS (PTR) nie są przechowywane w prywatnej strefie DNS. Odwrotne rekordy DNS są przechowywane w odwrotnej strefie DNS (in-addr.arpa). Domyślna odwrotna strefa DNS skojarzona z siecią wirtualną nie jest widoczna ani edytowalna.

Funkcję reverse DNS można wyłączyć w sieci wirtualnej, tworząc własną strefę wyszukiwania wstecznego przy użyciu stref prywatnych usługi Azure DNS, a następnie łącząc tę strefę z siecią wirtualną. Jeśli na przykład przestrzeń adresowa IP sieci wirtualnej to 10.20.0.0/16, możesz utworzyć pustą prywatną strefę DNS 20.10.in-addr.arpa i połączyć ją z siecią wirtualną. Ta strefa zastępuje domyślne strefy wyszukiwania wstecznego dla sieci wirtualnej. Ta strefa jest pusta. Odwrotny system DNS zwraca NXDOMAIN , chyba że ręcznie utworzysz te wpisy.

Automatyczne rejestrowanie rekordów PTR nie jest obsługiwane. Jeśli chcesz utworzyć wpisy, wprowadź je ręcznie. Należy wyłączyć automatyczne wyrejestrowanie w sieci wirtualnej, jeśli jest ona włączona dla innych stref. To ograniczenie jest spowodowane ograniczeniami , które zezwalają na połączenie tylko jednej strefy prywatnej, jeśli włączono funkcję automatycznego wyrejestrowania. Zobacz przewodnik Szybki start dotyczący prywatnego systemu DNS, aby uzyskać szczegółowe informacje na temat tworzenia prywatnej strefy DNS i łączenia jej z siecią wirtualną.

Uwaga

Ponieważ strefy prywatne usługi Azure DNS są globalne, można utworzyć wsteczne wyszukiwanie DNS obejmujące wiele sieci wirtualnych. W tym celu utwórz strefę prywatną usługi Azure DNS na potrzeby wyszukiwania wstecznego (strefy in-addr.arpa) i połącz ją z sieciami wirtualnymi. Musisz ręcznie zarządzać zwrotnymi rekordami DNS dla maszyn wirtualnych.

Konfiguracja klienta DNS

W tej sekcji opisano buforowanie po stronie klienta i ponawianie prób po stronie klienta.

Buforowanie po stronie klienta

Nie każde zapytanie DNS musi być wysyłane przez sieć. Buforowanie po stronie klienta pomaga zmniejszyć opóźnienia i zwiększyć odporność na blips sieci, rozwiązując cykliczne zapytania DNS z lokalnej pamięci podręcznej. Rekordy DNS zawierają mechanizm czasu wygaśnięcia (TTL), który umożliwia pamięci podręcznej przechowywanie rekordu tak długo, jak to możliwe bez wpływu na świeżość rekordu. W związku z tym buforowanie po stronie klienta jest odpowiednie w większości sytuacji.

Domyślny klient DNS systemu Windows ma wbudowaną pamięć podręczną DNS. Niektóre dystrybucje systemu Linux domyślnie nie obejmują buforowania. Jeśli okaże się, że nie ma jeszcze lokalnej pamięci podręcznej, dodaj pamięć podręczną DNS do każdej maszyny wirtualnej z systemem Linux.

Dostępnych jest wiele różnych pakietów buforowania DNS (takich jak dnsmasq). Poniżej przedstawiono sposób instalowania systemu dnsmasq w najbardziej typowych dystrybucjach:

RHEL/CentOS (używa networkmanager):

  1. Zainstaluj pakiet dnsmasq za pomocą następującego polecenia:

    sudo yum install dnsmasq

  2. Włącz usługę dnsmasq za pomocą następującego polecenia:

    systemctl enable dnsmasq.service

  3. Uruchom usługę dnsmasq za pomocą następującego polecenia:

    systemctl start dnsmasq.service

  4. Użyj edytora tekstów, aby dodać prepend domain-name-servers 127.0.0.1; plik do pliku /etc/dhclient-eth0.conf:

  5. Użyj następującego polecenia, aby ponownie uruchomić usługę sieciową:

    service network restart

Uwaga

Pakiet dnsmasq jest tylko jedną z wielu pamięci podręcznych DNS dostępnych dla systemu Linux. Przed użyciem sprawdź jego przydatności do konkretnych potrzeb i sprawdź, czy nie zainstalowano żadnej innej pamięci podręcznej.

Ponawianie prób po stronie klienta

Dns jest przede wszystkim protokołem UDP. Ponieważ protokół UDP nie gwarantuje dostarczania komunikatów, logika ponawiania jest obsługiwana w samym protokole DNS. Każdy klient DNS (system operacyjny) może mieć inną logikę ponawiania prób, w zależności od preferencji twórcy:

  • Systemy operacyjne Windows ponawiają próbę po jednej sekundzie, a następnie ponownie po kolejnych dwóch sekundach, czterech sekundach i kolejnych czterech sekundach.
  • Domyślna konfiguracja systemu Linux ponawia próbę po pięciu sekundach. Zalecamy zmianę specyfikacji ponawiania prób na pięć razy w odstępach jednej sekundy.

Sprawdź bieżące ustawienia na maszynie wirtualnej z systemem Linux przy użyciu polecenia cat /etc/resolv.conf. Przyjrzyj się wierszowi opcji , na przykład:

options timeout:1 attempts:5

Plik resolv.conf jest generowany automatycznie i nie powinien być edytowany. Konkretne kroki dodawania wiersza opcji różnią się w zależności od rozkładu:

RHEL/CentOS (używa networkmanager):

  1. Użyj edytora tekstów, aby dodać wiersz RES_OPTIONS="options timeout:1 attempts:5" do pliku /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Użyj następującego polecenia, aby ponownie uruchomić usługę NetworkManager:

    systemctl restart NetworkManager.service

Rozpoznawanie nazw używające własnego serwera DNS

W tej sekcji opisano maszyny wirtualne, wystąpienia ról i aplikacje internetowe.

Uwaga

Usługa Rozpoznawanie prywatne usługi Azure DNS zastępuje konieczność używania serwerów DNS opartych na maszynie wirtualnej w sieci wirtualnej. Poniższa sekcja jest dostępna, jeśli chcesz użyć rozwiązania DNS opartego na maszynie wirtualnej, jednak istnieje wiele korzyści związanych z używaniem usługi Azure DNS Private Resolver, w tym redukcji kosztów, wbudowanej wysokiej dostępności, skalowalności i elastyczności.

Maszyny wirtualne i wystąpienia ról

Twoje potrzeby dotyczące rozpoznawania nazw mogą wykraczać poza funkcje udostępniane przez platformę Azure. Na przykład może być konieczne użycie domen usługi Microsoft Windows Server Active Directory, rozpoznawanie nazw DNS między sieciami wirtualnymi. Aby uwzględnić te scenariusze, platforma Azure umożliwia korzystanie z własnych serwerów DNS.

Serwery DNS w sieci wirtualnej mogą przekazywać zapytania DNS do rekursywnych rozpoznawania nazw na platformie Azure. Ta procedura umożliwia rozpoznawanie nazw hostów w tej sieci wirtualnej. Na przykład kontroler domeny (DC) uruchomiony na platformie Azure może odpowiadać na zapytania DNS dotyczące swoich domen i przekazywać wszystkie inne zapytania do platformy Azure. Przekazywanie zapytań umożliwia maszynom wirtualnym wyświetlanie zarówno zasobów lokalnych (za pośrednictwem kontrolera domeny) jak i udostępnionych przez platformę Azure nazw hostów (za pośrednictwem usługi przesyłania dalej). Dostęp do programów rozpoznawania cyklicznego na platformie Azure jest zapewniany za pośrednictwem wirtualnego adresu IP 168.63.129.16.

Ważne

Jeśli usługa VPN Gateway jest używana w tej konfiguracji wraz z niestandardowymi adresami IP serwera DNS w sieci wirtualnej, należy również dodać adres IP usługi Azure DNS (168.63.129.16) na liście, a także zachować niedysponowaną usługę.

Przekazywanie DNS umożliwia również rozpoznawanie nazw DNS między sieciami wirtualnymi i umożliwia maszynom lokalnym rozpoznawanie nazw hostów udostępnianych przez platformę Azure. Aby rozpoznać nazwę hosta maszyny wirtualnej, maszyna wirtualna serwera DNS musi znajdować się w tej samej sieci wirtualnej i być skonfigurowana do przekazywania zapytań dotyczących nazw hostów do platformy Azure. Ponieważ sufiks DNS różni się w każdej sieci wirtualnej, można użyć reguł przekazywania warunkowego do wysyłania zapytań DNS do właściwej sieci wirtualnej do rozpoznawania. Na poniższej ilustracji przedstawiono dwie sieci wirtualne i sieć lokalną wykonującą rozpoznawanie nazw DNS między sieciami wirtualnymi przy użyciu tej metody. Przykładowy usług przesyłania dalej DNS jest dostępny w galerii szablonów Szybkiego startu platformy Azure i usłudze GitHub.

Uwaga

Wystąpienie roli może wykonywać rozpoznawanie nazw maszyn wirtualnych w tej samej sieci wirtualnej. Robi to przy użyciu nazwy FQDN, która składa się z nazwy hosta maszyny wirtualnej i internal.cloudapp.net sufiks DNS. Jednak w tym przypadku rozpoznawanie nazw kończy się pomyślnie tylko wtedy, gdy wystąpienie roli ma nazwę maszyny wirtualnej zdefiniowaną w pliku Schemat roli (plik cscfg). <Role name="<role-name>" vmName="<vm-name>">

Wystąpienia ról, które muszą wykonywać rozpoznawanie nazw maszyn wirtualnych w innej sieci wirtualnej (FQDN przy użyciu sufiksu internal.cloudapp.net ), muszą to zrobić przy użyciu metody opisanej w tej sekcji (niestandardowe serwery DNS przekazujące między dwiema sieciami wirtualnymi).

Diagram systemu DNS między sieciami wirtualnymi

W przypadku korzystania z rozpoznawania nazw udostępnianych przez platformę Azure protokół DHCP (Dynamic Host Configuration Protocol) udostępnia wewnętrzny sufiks DNS (internal.cloudapp.net) do każdej maszyny wirtualnej. Ten sufiks umożliwia rozpoznawanie nazw hostów, ponieważ rekordy nazw hostów znajdują się w strefie internal.cloudapp.net . Jeśli używasz własnego rozwiązania do rozpoznawania nazw, ten sufiks nie jest dostarczany do maszyn wirtualnych, ponieważ ingeruje w inne architektury DNS (takie jak scenariusze przyłączone do domeny). Zamiast tego platforma Azure udostępnia symbol zastępczy niefunkcjonujący (reddog.microsoft.com).

W razie potrzeby można określić wewnętrzny sufiks DNS przy użyciu programu PowerShell lub interfejsu API:

Jeśli przekazywanie zapytań do platformy Azure nie odpowiada Twoim potrzebom, podaj własne rozwiązanie DNS lub wdróż prywatny program rozpoznawania nazw DNS platformy Azure.

Jeśli udostępniasz własne rozwiązanie DNS, musi:

  • Podaj na przykład odpowiednie rozpoznawanie nazw hostów za pośrednictwem sieci DDNS. Jeśli używasz sieci DDNS, może być konieczne wyłączenie oczyszczania rekordów DNS. Dzierżawy DHCP platformy Azure są długie, a oczyszczanie może przedwcześnie usuwać rekordy DNS.

  • Podaj odpowiednią rekursywną rozdzielczość, aby umożliwić rozpoznawanie nazw domen zewnętrznych.

  • Być dostępny (TCP i UDP na porcie 53) od klientów, których obsługuje, i mieć dostęp do Internetu.

  • Aby ograniczyć zagrożenia stwarzane przez agentów zewnętrznych, należy zabezpieczyć się przed dostępem z Internetu.

Uwaga

  • Aby uzyskać najlepszą wydajność, jeśli używasz maszyn wirtualnych platformy Azure jako serwerów DNS, protokół IPv6 powinien być wyłączony.
  • Sieciowe grupy zabezpieczeń działają jako zapory dla punktów końcowych programu rozpoznawania nazw DNS. Należy zmodyfikować lub zastąpić reguły zabezpieczeń sieciowej grupy zabezpieczeń, aby zezwolić na dostęp do portu UDP 53 (i opcjonalnie port TCP 53) do punktów końcowych odbiornika DNS. Po ustawieniu niestandardowych serwerów DNS w sieci ruch przez port 53 spowoduje obejście sieciowych grup zabezpieczeń podsieci.

Ważne

Jeśli używasz serwerów DNS systemu Windows jako niestandardowych serwerów DNS przekazujących żądania DNS do serwerów USŁUGI Azure DNS, upewnij się, że zwiększasz wartość limitu czasu przekazywania więcej niż 4 sekundy, aby umożliwić serwerom DNS platformy Azure rekursywne wykonywanie odpowiednich operacji rekursji.

Aby uzyskać więcej informacji na temat tego problemu, zobacz Usługi przesyłania dalej i warunkowe usługi przesyłania dalej limity czasu rozwiązywania.

To zalecenie może również dotyczyć innych platform serwera DNS z wartością limitu czasu przekazywania 3 sekund lub mniej.

Nie można tego zrobić, może spowodować rozpoznawanie rekordów strefy Prywatna strefa DNS z publicznymi adresami IP.

Aplikacje internetowe

Załóżmy, że musisz wykonać rozpoznawanie nazw z poziomu aplikacji internetowej utworzonej przy użyciu usługi App Service połączonej z siecią wirtualną do maszyn wirtualnych w tej samej sieci wirtualnej. Oprócz skonfigurowania niestandardowego serwera DNS z usługą przesyłania dalej DNS, który przekazuje zapytania do platformy Azure (wirtualny adres IP 168.63.129.16), wykonaj następujące kroki:

Włącz integrację sieci wirtualnej dla aplikacji internetowej, jeśli jeszcze tego nie zrobiono, zgodnie z opisem w temacie Integrowanie aplikacji z siecią wirtualną.

Jeśli musisz wykonać rozpoznawanie nazw z aplikacji internetowej połączonej z siecią wirtualną (utworzoną przy użyciu usługi App Service) do maszyn wirtualnych w innej sieci wirtualnej, która nie jest połączona z tą samą strefą prywatną, użyj niestandardowych serwerów DNS lub prywatnych funkcji rozpoznawania nazw Azure DNS w obu sieciach wirtualnych.

Aby użyć niestandardowych serwerów DNS:

  • Skonfiguruj serwer DNS w docelowej sieci wirtualnej na maszynie wirtualnej, która może również przekazywać zapytania do rekursywnego rozpoznawania nazw na platformie Azure (wirtualny adres IP 168.63.129.16). Przykładowy usług przesyłania dalej DNS jest dostępny w galerii szablonów Szybkiego startu platformy Azure i usłudze GitHub.

  • Skonfiguruj usługę przesyłania dalej DNS w źródłowej sieci wirtualnej na maszynie wirtualnej. Skonfiguruj ten moduł przesyłania dalej DNS, aby przekazywać zapytania do serwera DNS w docelowej sieci wirtualnej.

  • Skonfiguruj źródłowy serwer DNS w ustawieniach źródłowej sieci wirtualnej.

  • Włącz integrację sieci wirtualnej dla aplikacji internetowej, aby połączyć się ze źródłową siecią wirtualną, postępując zgodnie z instrukcjami w temacie Integracja aplikacji z siecią wirtualną.

Aby użyć prywatnego rozpoznawania nazw dns platformy Azure, zobacz Linki zestawu reguł.

Określanie serwerów DNS

Jeśli używasz własnych serwerów DNS, platforma Azure umożliwia określenie wielu serwerów DNS na sieć wirtualną. Można również określić wiele serwerów DNS dla każdego interfejsu sieciowego (w przypadku usługi Azure Resource Manager) lub dla usługi w chmurze (w przypadku klasycznego modelu wdrażania). Serwery DNS określone dla interfejsu sieciowego lub usługi w chmurze mają pierwszeństwo przed serwerami DNS określonymi dla sieci wirtualnej.

Uwaga

Właściwości połączenia sieciowego, takie jak adresy IP serwera DNS, nie powinny być edytowane bezpośrednio na maszynach wirtualnych. Jest to spowodowane tym, że mogą zostać wymazane podczas naprawy usługi, gdy adapter sieci wirtualnej zostanie zastąpiony. Dotyczy to zarówno maszyn wirtualnych z systemami Windows, jak i Linux.

W przypadku korzystania z modelu wdrażania usługi Azure Resource Manager można określić serwery DNS dla sieci wirtualnej i interfejsu sieciowego. Aby uzyskać szczegółowe informacje, zobacz Zarządzanie siecią wirtualną i Zarządzanie interfejsem sieciowym.

Uwaga

Jeśli zdecydujesz się na niestandardowy serwer DNS dla sieci wirtualnej, musisz określić co najmniej jeden adres IP serwera DNS; W przeciwnym razie sieć wirtualna zignoruje konfigurację i zamiast tego użyje usługi DNS dostarczonej przez platformę Azure.

Uwaga

Jeśli zmienisz ustawienia DNS dla sieci wirtualnej lub maszyny wirtualnej, która jest już wdrożona, aby nowe ustawienia DNS zaczęły obowiązywać, należy przeprowadzić odnawianie dzierżawy DHCP na wszystkich maszynach wirtualnych, których dotyczy problem w sieci wirtualnej. W przypadku maszyn wirtualnych z systemem operacyjnym Windows można to zrobić, wpisując ipconfig /renew bezpośrednio na maszynie wirtualnej. Kroki różnią się w zależności od systemu operacyjnego. Zapoznaj się z odpowiednią dokumentacją dla danego typu systemu operacyjnego.

Następne kroki

Model wdrażania usługi Azure Resource Manager: