Udostępnij za pośrednictwem

Rozpoznawanie nazw dla zasobów w sieciach wirtualnych platformy Azure

  • Artykuł

Platformy Azure można używać do hostowania infrastruktury jako usługi (IaaS), platformy jako usługi (PaaS) i rozwiązań 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.

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

Uwaga

Jeśli używasz usługi DNS dostarczonej przez platformę Azure, 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. Strefy Prywatna strefa DNS platformy Azure 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. Strefy Prywatna strefa DNS platformy Azure, usługa Azure DNS Private Resolver lub serwery DNS zarządzane przez klienta 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 (aplikacji internetowej, funkcji lub bota) 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 aplikacji internetowych usługi App Service 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 aplikacji internetowych usługi App Service 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. Strefy Prywatna strefa DNS platformy Azure, rozpoznawanie nazw udostępnianych przez platformę Azure, prywatne 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. Łączność 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

Rozpoznawanie nazw udostępnianych przez platformę Azure 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 usługi Azure Prywatna strefa DNS z serwerami DNS zarządzanymi przez klienta 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 na 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 udostępnianych przez platformę Azure nie wymaga żadnej konfiguracji, nie jest to odpowiedni wybór dla wszystkich scenariuszy wdrażania, zgodnie z opisem w poprzedniej tabeli.

Uwaga

W przypadku korzystania z ról internetowych i procesów roboczych usług Azure Cloud Services 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:

  • Nie trzeba konfigurować żadnych elementów.
  • Nie musisz tworzyć klastrów własnych serwerów DNS i zarządzać nimi z powodu wysokiej dostępności.
  • Możesz użyć usługi z własnymi serwerami DNS, aby rozpoznać zarówno lokalne, jak i nazwy hostów 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 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

W przypadku korzystania z rozpoznawania nazw udostępnianych przez platformę Azure należy wziąć pod uwagę następujące kwestie:

  • 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.
  • Rejestracja ręczna własnych rekordów nie jest dozwolona.
  • 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 od 0 do 9, od a do z i łącznika (-). Nazwy nie mogą rozpoczynać się ani kończyć łącznikiem.
  • Ruch zapytań DNS jest ograniczany dla każdej maszyny wirtualnej. Ograniczanie przepustowości nie powinno mieć wpływu na większość aplikacji. Jeśli obserwujesz ograniczanie żądań, upewnij się, że buforowanie po stronie klienta jest włączone. Aby uzyskać więcej informacji, zobacz Konfiguracja klienta DNS.
  • Aby uniknąć problemów z rozpoznawaniem nazw DNS, należy użyć innej nazwy dla każdej maszyny wirtualnej w sieci wirtualnej.
  • 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 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 Resource Manager. Zwrotny system DNS zarządzany przez platformę Azure, znany również jako wskaźnik (PTR), rekordy formularza \[vmname\].internal.cloudapp.net są automatycznie dodawane do systemu DNS podczas uruchamiania maszyny wirtualnej. Są one 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

Odwrotna internal.cloudapp.net strefa DNS jest zarządzana przez 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 usługi Azure Prywatna strefa DNS jest połączona z siecią wirtualną za pomocą łącza sieci wirtualnej, a funkcja automatycznego wyrejestrowania jest włączona w tym linku, odwrotne zapytania DNS zwracają dwa rekordy. Jeden rekord ma postać \[vmname\].[privatednszonename] , a drugi ma postać \[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 zostaną zwrócone dwa rekordy PTR, jak pokazano wcześniej, wyszukiwanie do przodu nazwy FQDN zwraca adres IP maszyny wirtualnej.

Wsteczne wyszukiwanie DNS jest ograniczone do określonej sieci wirtualnej, nawet jeśli jest ona równorzędna z innymi sieciami wirtualnymi. Odwrotne zapytania DNS dotyczące adresów IP maszyn wirtualnych znajdujących się w równorzędnych sieciach wirtualnych zwracają wartość NXDOMAIN.

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. Utwórz własną strefę wyszukiwania wstecznego przy użyciu stref Prywatna strefa DNS platformy Azure. Następnie połącz 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ę 20.10.in-addr.arpa DNS 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 wartość 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. Aby uzyskać informacje na temat tworzenia prywatnej strefy DNS i łączenia jej z siecią wirtualną, zobacz przewodnik Szybki start dotyczący usługi Azure Prywatna strefa DNS.

Uwaga

Ponieważ strefy prywatne usługi Azure DNS są globalne, można utworzyć wsteczne wyszukiwanie DNS obejmujące wiele sieci wirtualnych. Musisz utworzyć strefę usługi Azure Prywatna strefa DNS dla wyszukiwania wstecznego (in-addr.arpastrefy), a następnie połączyć ją z sieciami wirtualnymi. Musisz ręcznie zarządzać odwrotnymi 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 blipy sieci przez rozpoznawanie cyklicznych zapytań DNS z lokalnej pamięci podręcznej. Rekordy DNS zawierają mechanizm czasu wygaśnięcia, który umożliwia pamięci podręcznej przechowywanie rekordu tak długo, jak to możliwe bez wpływu na świeżość rekordu. 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 dnsmasq w najbardziej typowych dystrybucjach:

RHEL (używa programu NetworkManager)

  1. dnsmasq Zainstaluj pakiet 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; element do /etc/dhclient-eth0.confelementu :

  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 użyteczność pod kątem konkretnych potrzeb i sprawdź, czy nie zainstalowano żadnej innej pamięci podręcznej.

Ponawianie prób po stronie klienta

DNS to przede wszystkim protokół UDP (User Datagram Protocol). 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. Spójrz na options wiersz, na przykład:

options timeout:1 attempts:5

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

RHEL (używa programu 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. Wiele korzyści z używania usługi Azure DNS Private Resolver obejmuje obniżenie kosztów, wbudowaną wysoką dostępność, skalowalność i elastyczność.

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 Active Directory systemu Windows Server do rozpoznawania nazw DNS między sieciami wirtualnymi. Aby uwzględnić te scenariusze, możesz użyć własnych serwerów DNS.

Serwery DNS w sieci wirtualnej mogą przekazywać zapytania DNS do rekursywnych rozpoznawania nazw na platformie Azure. Korzystając z tej procedury, można rozpoznać nazwy 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 Azure VPN Gateway jest używana w tej konfiguracji wraz z niestandardowymi adresami IP serwera DNS w sieci wirtualnej, adres IP usługi Azure DNS (168.63.129.16) musi zostać dodany na liście, aby zachować niezdysponowaną 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ń o nazwę hosta 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.

Dwie sieci wirtualne i sieć lokalna używają tej metody do rozpoznawania nazw DNS między sieciami wirtualnymi, jak pokazano na poniższym diagramie. 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. Używa ona nazwy FQDN, która składa się z nazwy hosta maszyny wirtualnej i sufiksu internal.cloudapp.net DNS. W takim 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ą używać metody opisanej w tej sekcji (niestandardowe serwery DNS przekazujące między dwiema sieciami wirtualnymi).

Diagram przedstawiający system 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) dla każdej maszyny wirtualnej. Ten sufiks umożliwia rozpoznawanie nazwy hosta, ponieważ rekordy nazwy hosta znajdują się w internal.cloudapp.net strefie. 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.

W przypadku sieci wirtualnych w modelach wdrażania usługi Resource Manager sufiks jest dostępny za pośrednictwem interfejsu sieciowego interfejsu API REST, polecenia cmdlet Get-AzNetworkInterface programu PowerShell i polecenia az network nic show interfejsu wiersza polecenia platformy Azure.

Jeśli przekazywanie zapytań do platformy Azure nie odpowiada Twoim potrzebom, podaj własne rozwiązanie DNS lub wdróż usługę Azure DNS Private Resolver.

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

  • Podaj odpowiednią rozdzielczość nazwy hosta, na przykład za pośrednictwem dynamicznej nazwy DNS (DDNS). Jeśli używasz usługi 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 usunąć 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.
  • Należy zabezpieczyć się przed dostępem z Internetu, aby ograniczyć zagrożenia stwarzane przez agentów zewnętrznych.

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. Zmodyfikuj lub przesłoń 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 pomija sieciowe grupy 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ększysz wartość limitu czasu przekazywania ponad cztery sekundy, aby umożliwić serwerom DNS platformy Azure 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ściami limitu czasu przekazywania w ciągu trzech 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:

  • Jeśli jeszcze tego nie zrobiono, włącz integrację sieci wirtualnej dla aplikacji internetowej 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 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óry 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 Integrowanie aplikacji z siecią wirtualną.

Aby użyć usługi Rozpoznawanie prywatne usługi Azure DNS, zobacz Linki zestawu reguł.

Określanie serwerów DNS

W przypadku korzystania z własnych serwerów DNS można określić wiele serwerów DNS na sieć wirtualną. Można również określić wiele serwerów DNS na interfejs sieciowy (dla usługi Resource Manager) lub dla usługi w chmurze (dla 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. Mogą zostać wymazane podczas naprawy usługi, gdy adapter sieci wirtualnej zostanie zastąpiony. Ta ostrożność dotyczy zarówno maszyn wirtualnych z systemami Windows, jak i Linux.

W przypadku korzystania z modelu wdrażania przy użyciu usługi Resource Manager można określić serwery DNS dla sieci wirtualnej i interfejsu sieciowego. Aby uzyskać więcej informacji, zobacz Zarządzanie siecią wirtualną i Zarządzanie interfejsem sieciowym.

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 ignoruje konfigurację i używa zamiast tego 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 wprowadź bezpośrednio ipconfig /renew na maszynie wirtualnej. Kroki różnią się w zależności od systemu operacyjnego. Zapoznaj się z odpowiednią dokumentacją dla danego typu systemu operacyjnego.

Powiązana zawartość

Model wdrażania usługi Azure Resource Manager: