Udostępnij za pośrednictwem

Omówienie systemów nazw domen w usłudze Azure NetApp Files

  • Artykuł

Usługa Azure NetApp Files obsługuje korzystanie z zintegrowanych serwerów DNS usługi Active Directory lub autonomicznych serwerów DNS i wymaga niezawodnego dostępu do usług systemu nazw domen (DNS) i aktualnych rekordów DNS. Niska łączność sieciowa między usługą Azure NetApp Files i serwerami DNS może spowodować przerwy w dostępie klienta lub przekroczenie limitu czasu klienta. Niekompletne lub nieprawidłowe rekordy DNS dla usług domena usługi Active Directory Services (AD DS) lub Azure NetApp Files mogą powodować przerwy w dostępie klienta lub przekroczenia limitu czasu klienta.

Usługa DNS jest krytycznym składnikiem dostępu do danych w usłudze Azure NetApp Files. Dostęp do protokołu plików za pośrednictwem protokołu SMB, NFSV4.1 Kerberos, LDAP i Odnajdywanie lokacji usługi Active Directory powoduje znaczne wykorzystanie systemu DNS na potrzeby ich operacji. Użycie nazwy hosta centralnie znajdującej się w systemie DNS upraszcza dostęp do woluminu i chroni przed scenariuszami, gdy zmienia się adres IP. Zamiast administrator musi poinformować użytkowników o nowym adresie IP, użytkownicy mogą nadal korzystać z przyjaznej dla użytkownika nazwy hosta.

Serwery DNS są konfigurowane w ramach połączeń usługi Active Directory. Można dodać podstawowy i pomocniczy serwer, a także nazwę DNS usługi Active Directory.

Uwaga

Najlepszym rozwiązaniem jest skonfigurowanie więcej niż jednego serwera DNS pod kątem nadmiarowości.

Zrzut ekranu przedstawiający ustawienia DNS.

Informacje o serwerach DNS

Usługa Azure NetApp Files wymaga połączenia z usługą Active Directory dla funkcji protokołu Kerberos protokołu SMB i NFSv4.1. Usługa Active Directory wymaga systemu DNS w celu zapewnienia odpowiedniej funkcjonalności. W większości przypadków wdrożenia usługi Active Directory są instalowane z serwerami DNS zintegrowanymi z kontrolerami domeny. Ta konfiguracja jest najlepszym rozwiązaniem firmy Microsoft zarówno w celu ułatwienia użycia, jak i zapewnienia, że wszystkie wymagane rekordy DNS są tworzone dla usług domenowych.

Diagram konfiguracji usługi AD DNS.

W niektórych przypadkach zewnętrzne serwery DNS (takie jak BIND) mogą być używane zamiast (lub oprócz) hostowanych usług DNS usługi Active Directory. Jest to nazywane rozłączną przestrzenią nazw.

Diagram konfiguracji powiązania zewnętrznego.

Usługa Azure NetApp Files obsługuje korzystanie zarówno ze zintegrowanych, jak i zewnętrznych serwerów DNS, ale w przypadku korzystania z zewnętrznych serwerów DNS bez integracji z usługą Active Directory należy upewnić się, że niezbędne rekordy usługi (SRV) są dodawane do systemu DNS w celu zapewnienia prawidłowej funkcjonalności i nadmiarowości usług. Niska łączność sieciowa między usługą Azure NetApp Files i serwerami DNS może spowodować przerwy w dostępie klienta lub przekroczenie limitu czasu klienta. Niekompletne lub nieprawidłowe rekordy DNS dla usług AD DS lub Azure NetApp Files mogą powodować przerwy w dostępie klienta lub przekroczenia limitu czasu klienta.

Aby uzyskać listę rekordów SRV używanych przez usługę, zobacz Rekordy DNS w usłudze Azure NetApp Files . Zapoznaj się również z wytycznymi dotyczącymi systemu DNS z usługą Active Directory i integracją usług AD DS z istniejącą infrastrukturą DNS.

Integracja usługi Azure DNS z usługą Azure NetApp Files

Azure DNS to hostowana usługa zarządzania systemem DNS i rozpoznawania nazw na platformie Microsoft Azure. Służy do tworzenia publicznych lub prywatnych nazw DNS dla innych aplikacji i usług wdrażanych na platformie Azure — w tym usługi Azure NetApp Files. Wdrażanie systemu DNS na platformie Azure uniemożliwia wysyłanie żądań DNS (przez port 53) bezpośrednio między usługą Azure NetApp Files i lokalną usługą DNS i/lub domeną usługi Active Directory. Ponadto usługa Azure DNS może służyć do tworzenia usług przesyłania dalej warunkowego (przy użyciu narzędzia rozpoznawania Prywatna strefa DNS azure), które mogą służyć do wysyłania żądań DNS z usługi Azure NetApp Files do określonych serwerów DNS za pomocą prywatnych serwerów DNS hostowanych na platformie Azure, które można określić do użycia w połączeniu usługi Active Directory.

Diagram konfiguracji usługi Azure DNS.

Aby uzyskać informacje na temat korzystania z usługi Azure DNS:

Używanie adresów IP modułu równoważenia obciążenia z usługą DNS w usłudze Azure NetApp Files

Urządzenie modułu równoważenia obciążenia to sposób użycia pojedynczego adresu IP do obsługi wielu adresów IP w zapleczu. Zapewnia to bezpieczeństwo dzięki zaciemnianiu, a także korzyści z wydajności i nadmiarowości w środowiskach przedsiębiorstwa.

Diagram konfiguracji modułu równoważenia obciążenia.

Moduł równoważenia obciążenia DNS może obsługiwać żądania i wysyłać je do wielu serwerów DNS wyznaczonych w puli. Platforma Microsoft Azure udostępnia natywne usługi równoważenia obciążenia dla wielu przypadków użycia.

Usługa Azure NetApp Files obsługuje korzystanie z modułów równoważenia obciążenia DNS, pod warunkiem, że podają adres IP jako punkt końcowy i że adres IP może komunikować się za pośrednictwem portu 53 do sieci usługi Azure NetApp Files. Na przykład usługa Azure Traffic Manager zapewnia równoważenie obciążenia DNS w warstwie 7, ale zapewnia tylko nazwę hosta frontonu do użycia. Połączenia usługi Active Directory usługi Azure NetApp Files zezwalają tylko na określenie adresów IP dla serwerów DNS.

Typy rekordów DNS w usłudze Azure NetApp Files

Usługa Azure NetApp Files korzysta z różnych typów rekordów DNS na potrzeby dostępu do usług plików.

Typ rekordu DNS Definicja
A/AAAAA Rekordy DNS A to rekordy adresów, które wskazują adres IPv4 dla nazwy hosta. Rekordy usługi AAAA wskazują adres IPv6 dla nazwy hosta. Usługa Azure NetApp Files używa rekordów A/AAAAA w następujący sposób:
  • Maskowanie adresów IP za przyjaznymi dla użytkownika nazwami hostów
  • Żądania jednostki usługi Kerberos
  • Zapytania domeny głównej
Rekordy wskaźnika (PTR) Rekord PTR mapuje adres IP na nazwę hosta za pomocą strefy wyszukiwania wstecznego. Rekordy PTR są używane głównie wtedy, gdy adres IP jest określony dla instalacji/udziału w usłudze Azure NetApp Files. Użycie adresu IP w żądaniach instalacji/udostępniania może mieć wpływ na użytą metodę uwierzytelniania. Aby uzyskać więcej informacji, zobacz Adresy IP na potrzeby dostępu za pomocą protokołu Kerberos.
Rekordy usługi (SRV) Rekordy SRV służą do określania, które hosty i porty są używane dla określonej usługi, takiej jak LDAP, NFS, CIFS, Kerberos itp. Rekordy SRV w usłudze Azure NetApp Files są intensywnie wykorzystywane do zabezpieczeń usługi plików (np. Kerberos), odnajdywania lokacji w usłudze Active Directory, zapytań serwera LDAP i nie tylko. Ważne jest, aby sprawdzić istnienie tych rekordów pod kątem prawidłowej funkcjonalności usług Azure NetApp Files.

Rekordy SRV można wykonywać przy użyciu poleceń nslookup lub dig . Przykłady można znaleźć w temacie Using and for DNS queries (Używanie i nslookupdig dla zapytań DNS).
Nazwy kanoniczne (CNAME) Rekord CNAME to sposób zapewnienia aliasów DNS dla rekordów A/AAAAA. Rekordy CNAME są opcjonalne, ale mogą być przydatne, aby zmniejszyć złożoność rekordów nazw hostów udostępnianych przez usługę Azure NetApp Files. Aby uzyskać więcej informacji, zobacz aliasy DNS i rekordy nazw kanonicznych.
Jednolity identyfikator zasobu (URI) Rekord identyfikatora URI to sposób mapowania nazw hostów/adresów IP dla usług na identyfikatory URI. Identyfikatory URI są prezentowane w formacie takim jak: service://fqdn.contoso.com.

Usługa Azure NetApp Files korzysta z zapytań dotyczących rekordów identyfikatorów URI tylko podczas wykonywania wyszukiwania protokołu Kerberos KDC dla żądań Kerberos systemu plików NFS. Rekordy identyfikatora URI nie są domyślnie tworzone we wdrożeniach DNS usługi Active Directory. W związku z tym żądania odnośników identyfikatora URI zwykle kończą się niepowodzeniem i wracają do odnośników rekordów SRV.

Rekordy usługi (SRV) używane z usługą Azure NetApp Files

Usługa Azure NetApp Files korzysta z następujących rekordów SRV:

  • NFS Kerberos*
    • _kerberos-master._tcp. CONTOSO.COM (port 88)*
    • _kerberos-master._tcp. CONTOSO.COM (port 88)*
  • Odnajdywanie lokacji SMB/Active Directory**
    • _kerberos.CONTOSO.COM (port 88)
    • _kerberos._tcp. CONTOSO.COM (port 88)
    • _kerberos._tcp.dc_msdcs. CONTOSO.COM (port 88)
    • _kpasswd._tcp.dc._msdcs. CONTOSO.COM (port 464)
    • _kpasswd._tcp. CONTOSO.COM (port 464)
    • _kerberos._tcp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (port 88)
    • _kerberos._tcp. {inne nazwy witryn}._sites.dc._msdcs. CONTOSO.COM (port 88)
    • _kerberos.udp.CONTOSO.COM (port 88)
    • _kerberos._udp.dc_msdcs. CONTOSO.COM (port 88)
    • _kpasswd._udp.dc._msdcs. CONTOSO.COM (port 464)
    • _kpasswd._udp. CONTOSO.COM (port 464)
    • _kerberos._udp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (port 88)
    • _kerberos._udp. {inne nazwy witryn}._sites.dc._msdcs. CONTOSO.COM (port 88)
  • LDAP**
    • _ldap.CONTOSO.COM (port 389)
    • _ldap._tcp. CONTOSO.COM (port 389)
    • _ldap._udp. CONTOSO.COM (port 389)

* System DNS usługi Active Directory domyślnie nie tworzy tych rekordów SRV. Zdecydowanie zaleca się utworzenie ich w przypadku korzystania z protokołu Kerberos systemu plików NFS.

** System DNS usługi Active Directory domyślnie tworzy te rekordy SRV.

Aby uzyskać więcej informacji na temat korzystania z rekordów SRV w usłudze Azure NetApp Files, zobacz:

Uwaga

Aby uzyskać odpowiednie odnajdywanie i nadmiarowość centrum dystrybucji kluczy w protokole Kerberos systemu plików NFS, należy utworzyć rekordy identyfikatorów URI i/lub rekordy SRV kerberos-master.

Dynamiczny system DNS

Woluminy usługi Azure NetApp Files zapewniają pojedynczy adres IP dla woluminu, który jest następnie dodawany do systemu DNS automatycznie za pośrednictwem dynamicznej usługi DNS (DDNS) (jeśli dynamiczny system DNS jest obsługiwany na serwerze DNS). Nazwy hostów (a nie adresy IP) są używane dla ścieżek instalacji woluminów w określonych konfiguracjach. Używanie nazw hostów w ścieżkach instalacji wymaga systemu DNS w celu zapewnienia odpowiedniej funkcjonalności:

  • Woluminy SMB
  • NFSv4.1 Kerberos
  • Woluminy używające dwóch protokołów

NFSv4.1 Kerberos:

Zrzut ekranu przedstawiający ścieżkę instalacji NFSv4.1.

SMB

Zrzut ekranu przedstawiający ścieżkę instalacji protokołu SMB.

Protokół podwójny

Zrzut ekranu przedstawiający ścieżkę instalacji dwóch protokołów.

Adres IP jest używany dla ścieżki instalacji, gdy wolumin usługi Azure NetApp File nie wymaga systemu DNS, takiego jak NFSv3 lub NFSv4.1 bez protokołu Kerberos.

NFSv3

Zrzut ekranu przedstawiający ścieżkę instalacji systemu plików NFS3.

Kwestie wymagające rozważenia

W usłudze Azure NetApp Files dynamiczne aktualizacje DNS wysyłają dwa różne żądania do skonfigurowanego serwera DNS: jeden dla ptR i jeden dla tworzenia/aktualizowania rekordu A/AAAA.

  • Woluminy usługi Azure NetApp Files utworzone za pomocą nazw hostów automatycznie powiadamiają serwer DNS o utworzeniu rekordu A/AAAA. Dzieje się tak natychmiast po zakończeniu tworzenia woluminu.

  • Jeśli rekord A/AAAA DNS jest już obecny dla kombinacji adresu IP/nazwy hosta, nie są tworzone żadne nowe rekordy.

  • Jeśli rekord A/AAAA DNS jest obecny dla tej samej nazwy hosta z innym adresem IP, zostanie utworzony drugi rekord A/AAAAA o tej samej nazwie.

  • W przypadku woluminów usługi Azure NetApp Files utworzonych bez nazw hostów (takich jak woluminy NFSv3) dynamiczny system DNS nie tworzy rekordów DNS, ponieważ w usłudze nie ma przypisanej nazwy hosta. Rekordy muszą być tworzone ręcznie.

  • Jeśli istnieje strefa wyszukiwania wstecznego dla podsieci IP interfejsu, serwer DNS tworzy również rekord PTR. Jeśli wymagana strefa wyszukiwania wstecznego nie istnieje, nie można automatycznie utworzyć rekordu PTR. Rekord PTR należy utworzyć ręcznie.

  • Jeśli wpis DNS utworzony przez dynamiczny system DNS zostanie usunięty na serwerze DNS, zostanie utworzony ponownie w ciągu 24 godzin przez nową dynamiczną aktualizację DNS z usługi Azure NetApp Files.

  • Bezpieczne sieci DDNS są włączane podczas tworzenia woluminów protokołu SMB lub podwójnych. Woluminy NFS nie włączają bezpiecznej sieci DDNS, ale włączają sieci DDNS. Jeśli bezpieczne nazwy DDNS są wyłączone na serwerze DNS lub uwierzytelnianie Kerberos kończy się niepowodzeniem, aktualizacje DDNS nie działają.

    Dynamiczny typ DNS Port
    Standardowa DNS UDP 53
    Bezpieczny system DNS TCP 53

  • Usługa Azure NetApp Files obsługuje bezpieczne sieci DDNS tylko z serwerami DNS usługi Microsoft Active Directory.

Dynamiczne szczegóły wpisu DNS

Gdy usługa Azure NetApp Files tworzy rekord A/AAAA DNS za pośrednictwem dynamicznego systemu DNS, używane są następujące konfiguracje:

  • Skojarzone pole rekordu PTR jest zaznaczone: jeśli istnieją strefy wyszukiwania wstecznego dla podsieci, rekordy A/AAAAA automatycznie tworzą rekordy PTR bez interwencji administratora.
  • Pole "Usuń ten rekord, gdy stanie się nieaktualne", jest zaznaczone: gdy rekord DNS stanie się "nieaktualny", dns usuwa rekord, pod warunkiem, że oczyszczanie systemu DNS zostało włączone.
  • Rekord DNS "czas wygaśnięcia (TTL)" jest ustawiony na jeden dzień (24 godziny): ustawienie czasu wygaśnięcia można zmodyfikować przez administratora DNS zgodnie z potrzebami. Czas wygaśnięcia w rekordzie DNS określa czas, przez jaki wpis DNS istnieje w pamięci podręcznej DNS klienta.

Uwaga

Aby wyświetlić znaczniki czasu i czas wygaśnięcia (TTL), gdy rekord DNS został utworzony w systemie Windows Active Directory DNS, przejdź do menu Widok Menedżera DNS, a następnie wybierz pozycję Zaawansowane. W tym miejscu wybierz wpis rekordu A/AAAAA i wyświetl właściwości.

Zrzut ekranu przedstawiający znaczniki czasu DNS.

Jak działa standardowy dynamiczny system DNS w usłudze Azure NetApp Files

Usługa Azure NetApp Files wykonuje cztery podstawowe kroki tworzenia dynamicznych aktualizacji DNS na skonfigurowanych serwerach DNS. Standardowe aktualizacje dynamicznego systemu DNS (DDNS) przechodzą przez port UDP 53.

  • Wykonywane jest zapytanie DNS SOA dla adresu IP interfejsu woluminu usługi Azure NetApp Files.
  • Jest wykonywana aktualizacja DDNS dla ptR. Jeśli ptR nie istnieje, zostanie utworzony.
  • Zapytanie o rozpoczęcie urzędu DNS (SOA) jest tworzone dla w pełni kwalifikowanej nazwy domeny (FQDN) woluminu usługi Azure NetApp Files.
  • Wykonywana jest aktualizacja DDNS dla rekordu A/AAAAA. Jeśli rekord nie istnieje, zostanie utworzony.

Dynamiczny system DNS za pośrednictwem przechwytywania pakietów

Przechwytywanie pakietów może być przydatne w rozwiązywaniu problemów z usługą, które mogą nie mieć dostępnego rejestrowania do analizy. Rozwiń ten widok, aby uzyskać szczegółowe informacje na temat przechwytywania pakietów.

  1. Wykonywane jest zapytanie DNS SOA dla adresu IP interfejsu woluminu usługi Azure NetApp Files.

    143 x.x.x.y	x.x.x.x	DNS	86	Standard query 0x77c8 SOA y.x.x.x.in-addr.arpa

144 x.x.x.x	x.x.x.y	DNS	229	Standard query response 0x77c8 No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

  2. Jest wykonywana aktualizacja DDNS dla ptR. Jeśli ptR nie istnieje, zostanie utworzony.

    145 x.x.x.y	x.x.x.x	DNS	121	Dynamic update 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local

146 x.x.x.x	x.x.x.y	DNS	121	Dynamic update response 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local

  3. Zapytanie o rozpoczęcie urzędu DNS (SOA) jest tworzone dla w pełni kwalifikowanej nazwy domeny (FQDN) woluminu usługi Azure NetApp Files.

    147 x.x.x.y	x.x.x.x	DNS	81	Standard query 0xcfab SOA ANF1234.anf.local

148 x.x.x.x	x.x.x.y	DNS	214	Standard query response 0xcfab No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

  4. Wykonywana jest aktualizacja DDNS dla rekordu A/AAAAA. Jeśli rekord nie istnieje, zostanie utworzony.

    149 x.x.x.y	x.x.x.x	DNS	97	Dynamic update 0x83b2 SOA anf.local A x.x.x.y

150 x.x.x.x	x.x.x.y	DNS	97	Dynamic update response 0x83b2 SOA anf.local A x.x.x.y

Jak działa bezpieczna sieć DDNS w usłudze Azure NetApp Files

Po włączeniu bezpiecznego systemu DNS usługa Azure NetApp Files negocjuje z serwerem DNS uwierzytelnianie za pośrednictwem usługi GSS przy użyciu uwierzytelniania transakcji klucza tajnego dla systemu DNS, zapewniając, że żądane aktualizacje pochodzą z wiarygodnego źródła. Poniżej przedstawiono kroki używane podczas tego procesu. Aktualizacje secure DDNS przechodzą przez port TCP 53.

  • Wykonywane jest zapytanie DNS SOA dla adresu IP interfejsu woluminu usługi Azure NetApp Files.
  • Bilet usługi Kerberos jest wymieniany dla usługi DNS na serwerze DNS.
  • Bilet jest następnie używany w zapytaniu DNS dla klucza transakcji (TKEY) z usługi Azure NetApp Files do serwera DNS, który jest przekazywany przy użyciu GSS-TSIG (podpis transakcji) do uwierzytelniania.
  • Po pomyślnym uwierzytelnieniu bezpieczna dynamiczna aktualizacja DNS jest wysyłana przy użyciu klucza TKEY w celu utworzenia ptR jest wysyłana przy użyciu usługi GSS-TSIG. Jeśli rekord jeszcze nie istnieje, zostanie utworzony.
  • Zapytanie SOA DNS jest wysyłane dla w pełni kwalifikowanej nazwy domeny (FQDN) woluminu usługi Azure NetApp Files i odpowiada na.
  • Nowy identyfikator TKEY jest wymieniany między serwerem DNS a usługą Azure NetApp Files.
  • Bezpieczna dynamiczna aktualizacja DNS jest wysyłana przy użyciu klucza TKEY w celu utworzenia rekordu A/AAAA dla nazwy FQDN. Jeśli rekord już istnieje z tym samym adresem IP, nie zostaną wprowadzone żadne zmiany.

Dynamiczny system DNS za pośrednictwem przechwytywania pakietów

Przechwytywanie pakietów może być przydatne w rozwiązywaniu problemów z usługą, które mogą nie mieć dostępnego rejestrowania do analizy. Rozwiń ten widok, aby uzyskać szczegółowe informacje na temat przechwytywania pakietów.

  1. Wykonywane jest zapytanie DNS SOA dla adresu IP interfejsu woluminu usługi Azure NetApp Files.

    1135 x.x.x.y 	x.x.x.x	DNS	86	Standard query 0xd29a SOA y.x.x.x.in-addr.arpa

1136 x.x.x.x	x.x.x.y	DNS	229	Standard query response 0xd29a No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

  2. Bilet usługi Kerberos jest wymieniany dla usługi DNS na serwerze DNS.

    1141 x.x.x.y	x.x.x.x	KRB5	406	TGS-REQ
•	SNameString: DNS
•	SNameString: dc1.anf.local

1143 x.x.x.x	x.x.x.y	KRB5	1824	TGS-REP

  3. Bilet jest następnie używany w zapytaniu DNS dla klucza transakcji (TKEY) z usługi Azure NetApp Files do serwera DNS, który jest przekazywany przy użyciu GSS-TSIG (podpis transakcji) do uwierzytelniania.

        1152 x.x.x.y	x.x.x.x	DNS	191	Standard query 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY
•	Name: 1492998148.sig-dc1.anf.local
•	Type: TKEY (249) (Transaction Key)
•	Algorithm name: gss-tsig

1154 x.x.x.x	x.x.x.y	DNS	481	Standard query response 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY TSIG

  4. Po pomyślnym uwierzytelnieniu bezpieczna dynamiczna aktualizacja DNS jest wysyłana przy użyciu klucza TKEY w celu utworzenia ptR jest wysyłana przy użyciu usługi GSS-TSIG. Jeśli rekord jeszcze nie istnieje, zostanie utworzony.

    1155 x.x.x.y	x.x.x.x	DNS	240	Dynamic update 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG
•	Zone
o	x.x.x.in-addr.arpa: type SOA, class IN
o	y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local
•	Type: PTR (12) (domain name PoinTeR)
o	Additional records
o	1492998148.sig-dc1.anf.local: type TSIG, class ANY

1156 x.x.x.x	x.x.x.y	DNS	240	Dynamic update response 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG
•	Updates
o	y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local
o	Type: PTR (12) (domain name PoinTeR)

  5. Zapytanie SOA DNS jest wysyłane dla w pełni kwalifikowanej nazwy domeny (FQDN) woluminu usługi Azure NetApp Files i odpowiada na.

    1162 x.x.x.y	x.x.x.x	DNS	81	Standard query 0xe872 SOA ANF1234.anf.local

1163 x.x.x.x	x.x.x.y	DNS	214	Standard query response 0xe872 No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

  6. Nowy identyfikator TKEY jest wymieniany między serwerem DNS a usługą Azure NetApp Files.

    1165 x.x.x.y	x.x.x.x	DNS	191	Standard query 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY

1167 x.x.x.x	x.x.x.y	DNS	481	Standard query response 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY TSIG

  7. Bezpieczna dynamiczna aktualizacja DNS jest wysyłana przy użyciu klucza TKEY w celu utworzenia rekordu A/AAAA dla nazwy FQDN. Jeśli rekord już istnieje z tym samym adresem IP, nie zostaną wprowadzone żadne zmiany.

        1168 x.x.x.y	x.x.x.x	DNS	216	Dynamic update 0x014a SOA anf.local A x.x.x.y TSIG
•	Zone
o	anf.local: type SOA, class IN
•	Updates
o	ANF1234.anf.local: type A, class IN, addr x.x.x.y
o	Type: A (1) (Host Address)
o	Address: x.x.x.y
•	Additional records
o	1260534462.sig-dc1.anf.local: type TSIG, class ANY

1170 x.x.x.x	x.x.x.y	DNS	216	Dynamic update response 0x014a SOA anf.local A x.x.x.y TSIG
•	Updates
o	ANF1234.anf.local: type A, class IN, addr x.x.x.y
o	Type: A (1) (Host Address)

Buforowanie DNS

Aby zmniejszyć obciążenie serwerów DNS, klienci DNS korzystają z pojęć buforowania do przechowywania poprzednich zapytań w pamięci, aby powtarzać żądania dla nazwy hosta, adresu IP lub usługi są przechowywane lokalnie przez okres zdefiniowany przez czas wygaśnięcia rekordu DNS.

Usługa Azure NetApp Files korzysta z pamięci podręcznych DNS, takich jak każdy inny standardowy klient DNS. Gdy usługa żąda rekordu DNS, ten rekord ma zdefiniowany czas wygaśnięcia. Domyślnie wpisy DNS usługi Active Directory mają czas wygaśnięcia 600 sekund (10 minut), chyba że określono inaczej. Jeśli rekord DNS jest aktualizowany i znajduje się w pamięci podręcznej usługi Azure NetApp Files, a czas wygaśnięcia wynosi 10 minut, nowy rekord nie zostanie zaktualizowany w usłudze Azure NetApp Files, dopóki pamięć podręczna nie zostanie przeczyszczone po przekroczeniu limitu czasu. Obecnie nie ma możliwości ręcznego przeczyszczania tej pamięci podręcznej. Jeśli wymagany jest niższy czas wygaśnięcia, wprowadź zmianę z serwera DNS.

W przypadku korzystania z zewnętrznych serwerów DNS (takich jak BIND) domyślne wartości limitu czasu mogą się różnić. W przypadku niezdefiniowanego czasu wygaśnięcia rekordu DNS bind wynosi 604 800 sekund (siedem dni), zbyt długo w przypadku efektywnego buforowania DNS. W związku z tym podczas ręcznego tworzenia rekordów DNS ważne jest ręczne ustawienie czasu wygaśnięcia rekordu na rozsądną wartość. Użycie domyślnej wartości 10 minut firmy Microsoft jest zalecane w przypadku połączenia wydajności i niezawodności wyszukiwania DNS.

Możesz ręcznie wykonać zapytanie dotyczące czasu wygaśnięcia rekordu DNS przy użyciu poleceń nslookup lub dig . Przykłady można znaleźć w temacie Using and for DNS queries (Używanie i nslookupdig dla zapytań DNS).

Oczyszczanie/oczyszczanie rekordów DNS

Większość serwerów DNS udostępnia metody oczyszczania i czyszczenia wygasłych rekordów. Oczyszczanie pomaga zapobiegać nieaktywnym rekordom zaśmiecania serwerów DNS i tworzenia scenariuszy, w których istnieją zduplikowane rekordy A/AAAA i/lub PTR, co może powodować nieprzewidywalne wyniki dla woluminów usługi Azure NetApp Files.

Jeśli wiele rekordów PTR dla tego samego punktu adresu IP do różnych nazw hostów, żądania Protokołu Kerberos mogą zakończyć się niepowodzeniem, ponieważ niepoprawna nazwa SPN jest pobierana podczas wyszukiwania DNS. System DNS nie rozpoznaje, który rekord PTR należy do której nazwy hosta; Zamiast tego wyszukiwanie wsteczne wykonuje wyszukiwanie okrężne za pośrednictwem każdego rekordu A/AAAAA dla każdego nowego wyszukiwania.

Na przykład:

C:\> nslookup x.x.x.x
Server:  contoso.com
Address:  x.x.x.x

Name:    ANF-1234.contoso.com
Address:  x.x.x.x

C:\> nslookup x.x.x.x
Server:  contoso.com
Address:  x.x.x.x

Name:    ANF-5678.contoso.com
Address:  x.x.x.x

Aliasy DNS i rekordy nazwy kanonicznej (CNAME)

Usługa Azure NetApp Files tworzy nazwę hosta DNS dla woluminu, który został skonfigurowany dla protokołu, który wymaga systemu DNS dla odpowiednich funkcji, takich jak SMB, podwójny protokół lub NFSv4.1 z protokołem Kerberos. Utworzona nazwa używa formatu serwera SMB (konta komputera) jako prefiksu podczas tworzenia połączenia usługi Active Directory dla konta usługi NetApp; Dodano dodatkowe znaki alfanumeryczne, aby wiele wpisów woluminu na tym samym koncie usługi NetApp miało unikatowe nazwy. W większości przypadków wiele woluminów, które wymagają nazw hostów i istnieją na tym samym koncie usługi NetApp, próbuje użyć tych samych nazw hostów/adresów IP. Jeśli na przykład nazwa serwera SMB jest SMB-West.contoso.com, wpisy nazwy hosta są zgodne z formatem SMB-West-XXXX.contoso.com.

W niektórych przypadkach nazwa używana przez usługę Azure NetApp Files może nie być wystarczająco przyjazna dla użytkowników końcowych, a administratorzy mogą chcieć zachować bardziej znane nazwy DNS używane podczas migracji danych z magazynu lokalnego do usługi Azure NetApp Files (tj. jeśli oryginalna nazwa DNS została datalake.contoso.com, użytkownicy końcowi mogą nadal używać tej nazwy).

Usługa Azure NetApp Files nie zezwala natywnie na specyfikację używanych nazw hostów DNS. Jeśli potrzebujesz alternatywnej nazwy DNS z tą samą funkcjonalnością, należy użyć aliasu DNS/nazwy kanonicznej (CNAME).

Użycie rekordu CNAME (zamiast dodatkowego rekordu A/AAAA), który wskazuje rekord A/AAAA woluminu usługi Azure NetApp Files, korzysta z tej samej nazwy SPN co serwer SMB, aby umożliwić dostęp kerberos zarówno dla rekordu A/AAAA, jak i rekordu CNAME. Rozważmy przykład rekordU A/AAAA SMB-West-XXXX.contoso.com. Rekord CNAME datalake.contoso.com jest skonfigurowany tak, aby wskazywał z powrotem na rekord A/AAAA SMB-West-XXXX.contoso.com. Żądania protokołu Kerberos protokołu Kerberos protokołu SMB lub NFS wysyłane do datalake.contoso.com użyj nazwy SPN protokołu Kerberos dla protokołu SMB-West-XXXX, aby zapewnić dostęp do woluminu.

Używanie polecenia nslookup i kopanie zapytań DNS

Serwery DNS mogą być ręcznie odpytywane przy użyciu narzędzi DNS, takich jak nslookup (klienci z systemami Windows i Linux) i dig (klienci z systemem Linux). Korzystanie z tych narzędzi jest przydatne w scenariuszach, w tym próby zweryfikowania funkcjonalności usług, testowania nazwy hosta/rozpoznawania adresów IP, wyszukiwania istniejących/nieaktualnych rekordów DNS, sprawdzania konfiguracji serwera, weryfikowania czasu wygaśnięcia. Możesz również użyć narzędzia do rozwiązywania problemów z połączeniem platformy Azure, aby rozwiązać dodatkowe problemy.

Polecenia nslookup i dig można uruchamiać z połączenia zdalnego z maszyną wirtualną (np. z usługi Bastion) lub bezpośrednio do maszyny wirtualnej za pośrednictwem opcji uruchom polecenie na samej maszynie wirtualnej.

nslookup z systemem Windows

Możesz uruchomić polecenie nslookup , aby zebrać podstawowe informacje o adresie IP bez żadnych opcji:

C:\>nslookup anf.local
Server:  dns.anf.local
Address:  x.x.x.a

Name:    anf.local
Addresses:  x.x.x.x
            x.x.x.y

Aby wysłać zapytanie tylko o informacje o czas wygaśnięcia rekordu, użyj -query=hinfo opcji polecenia .

C:\>nslookup -query=hinfo anf.local
Server:  dns.anf.local
Address:  x.x.x.a

anf.local
        primary name server = dns.anf.local
        responsible mail addr = root.dns.anf.local
        serial  = 7
        refresh = 604800 (7 days)
        retry   = 86400 (1 day)
        expire  = 2419200 (28 days)
        default TTL = 604800 (7 days)

Za -debug pomocą tej opcji można również zebrać bardziej szczegółowe informacje o rekordzie DNS.

C:\>nslookup -debug anf.local
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        x.x.x.x.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  x.x.x.x.in-addr.arpa
        name = dns.anf.local
        ttl = 604800 (7 days)

------------
Server:  dns.anf.local
Address:  x.x.x.a

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        anf.local.ANF.LOCAL, type = A, class = IN
    AUTHORITY RECORDS:
    ->  anf.local
        ttl = 604800 (7 days)
        primary name server = dns.anf.local
        responsible mail addr = root.dns.anf.local
        serial  = 7
        refresh = 604800 (7 days)
        retry   = 86400 (1 day)
        expire  = 2419200 (28 days)
        default TTL = 604800 (7 days)

kopanie z systemem Linux

# dig anf.local

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> anf.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12196
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;anf.local.                     IN      A

;; ANSWER SECTION:
anf.local.              604800  IN      A       x.x.x.x
anf.local.              604800  IN      A       x.x.x.y

;; Query time: 0 msec
;; SERVER: 10.193.67.250#53(10.193.67.250)
;; WHEN: Thu Aug 29 15:27:47 EDT 2024
;; MSG SIZE  rcvd: 70

Najlepsze rozwiązania dotyczące systemu DNS w usłudze Azure NetApp Files

Upewnij się, że spełniasz następujące wymagania dotyczące konfiguracji DNS:

  • Określ więcej niż jeden serwer DNS w konfiguracji DNS na potrzeby nadmiarowości.
  • Aby uzyskać najlepsze wyniki, użyj systemu DNS zintegrowanego z usługą Active Directory i/lub zainstalowanego z usługą Active Directory.
  • Jeśli używasz autonomicznych serwerów DNS:
    • Upewnij się, że serwery DNS mają łączność sieciową z delegowana podsiecią usługi Azure NetApp Files hostująca woluminy usługi Azure NetApp Files.
    • Upewnij się, że porty sieciowe UDP 53 i TCP 53 nie są blokowane przez zapory ani sieciowe grupy zabezpieczeń.
  • Upewnij się, że rekordy SRV zarejestrowane przez usługę logowania net usług AD DS zostały utworzone na serwerach DNS, a także rekordy usługi wymienione w temacie Typy rekordów DNS w usłudze Azure NetApp Files.
  • Upewnij się, że rekordy PTR dla kontrolerów domeny usług AD DS używanych przez usługę Azure NetApp Files zostały utworzone na serwerach DNS w tej samej domenie co konfiguracja usługi Azure NetApp Files.
  • Usługa Azure NetApp Files obsługuje standardowe i bezpieczne dynamiczne aktualizacje DNS. Jeśli potrzebujesz bezpiecznych dynamicznych aktualizacji DNS, upewnij się, że bezpieczne aktualizacje są skonfigurowane na serwerach DNS.
  • Upewnij się, że dla podsieci usługi Azure NetApp Files utworzono strefę wyszukiwania wstecznego, aby umożliwić dynamicznemu systemowi DNS tworzenie rekordów PTR oprócz rekordu A/AAAA.
  • Jeśli alias DNS jest wymagany, użyj rekordu CNAME. Wskaż rekord CNAME rekordowi A/AAAAA dla usługi Azure NetApp Files.
  • Jeśli nie używasz dynamicznych aktualizacji DNS, musisz ręcznie utworzyć rekord A i rekord PTR dla kont komputerów usług AD DS utworzonych w jednostce organizacyjnej usług AD DS (określonej w połączeniu usługi Azure NetApp Files AD) w celu obsługi podpisywania LDAP usługi Azure NetApp Files, ldap za pośrednictwem protokołu TLS, SMB, dwóch protokołów lub woluminów Kerberos NFSv4.1.
  • W przypadku złożonych lub dużych topologii usług AD DS priorytetyzacja zasad DNS lub podsieci DNS może być wymagana do obsługi woluminów NFS z włączoną obsługą protokołu LDAP.
  • Jeśli funkcja oczyszczania DNS jest włączona (gdzie nieaktualne wpisy DNS są automatycznie czyszczone na podstawie sygnatury czasowej/wieku), a dynamiczny system DNS został użyty do utworzenia rekordów DNS dla woluminu usługi Azure NetApp Files, proces scavenger może przypadkowo oczyścić rekordy dla woluminu. To oczyszczanie może prowadzić do awarii usługi dla zapytań opartych na nazwach. Dopóki ten problem nie zostanie rozwiązany, należy ręcznie utworzyć wpisy DNS A/AAAA i PTR dla woluminu usługi Azure NetApp Files, jeśli jest włączone oczyszczanie DNS.

Następne kroki