Grundlegendes zu DNS in Azure NetApp Files
Azure NetApp Files unterstützt die Verwendung von integrierten DNS- oder eigenständigen DNS-Servern von Active Directory und erfordert einen zuverlässigen Zugriff auf DNS-Dienste und aktuelle DNS-Einträge. Schlechte Netzwerkkonnektivität zwischen Azure NetApp Files und DNS-Servern kann zu Unterbrechungen des Clientzugriffs oder Clienttimeouts führen. Unvollständige oder falsche DNS-Einträge für Active Directory Domain Services (AD DS) oder Azure NetApp Files können zu Unterbrechungen des Clientzugriffs oder Clienttimeouts führen.
Der DNS-Dienst ist eine wichtige Komponente des Datenzugriffs in Azure NetApp Files. Der Dateiprotokollzugriff über SMB, NFSV4.1 Kerberos, LDAP und Active Directory-Standortermittlung nutzen DNS umfassend für ihre Vorgänge. Die Verwendung eines Hostnamens, der sich zentral in DNS befindet, vereinfacht den Zugriff auf ein Volume und schützt vor Szenarien, wenn sich eine IP-Adresse ändert. Benutzende können weiterhin den benutzerfreundlichen Hostnamen verwenden und müssen nicht vom Admin über eine neue IP-Adresse informiert werden.
DNS-Server werden unter Active Directory-Verbindungen konfiguriert. Ein primärer und sekundärer Server sowie der Active Directory-DNS-Name können hinzugefügt werden.
Hinweis
Konfigurieren Sie als bewährte Methode mehrere DNS-Server für Redundanz.
Informationen zu DNS-Servern
Azure NetApp Files erfordert eine Active Directory-Verbindung für SMB- und NFSv4.1 Kerberos-Funktionen. Active Directory erfordert DNS, um eine ordnungsgemäße Funktionalität zu gewährleisten. In den meisten Fällen werden Active Directory-Bereitstellungen mit DNS-Servern installiert, die in die Domänencontroller integriert sind. Bei dieser Konfiguration handelt es sich um eine bewährte Methode von Microsoft für die einfache Verwendung. Außerdem soll sichergestellt werden, dass alle erforderlichen DNS-Einträge für Domänendienste erstellt werden.
In einigen Fällen können externe DNS-Server (z. B. BIND) anstelle von (oder zusätzlich zu) von Active Directory gehosteten DNS-Diensten verwendet werden. Dies wird als separater Namespace bezeichnet.
Azure NetApp Files unterstützt die Verwendung von integrierten und externen DNS-Servern. Bei Verwendung externer DNS-Server ohne Active Directory-Integration ist es jedoch wichtig, sicherzustellen, dass die erforderlichen Diensteinträge (SRV) zum DNS hinzugefügt werden, um ordnungsgemäße Funktionalität und Redundanz von Diensten zu gewährleisten. Schlechte Netzwerkkonnektivität zwischen Azure NetApp Files und DNS-Servern kann zu Unterbrechungen des Clientzugriffs oder Clienttimeouts führen. Unvollständige oder falsche DNS-Einträge für AD DS oder Azure NetApp Files können zu Unterbrechungen des Clientzugriffs oder Clienttimeouts führen.
Eine Liste der SRV-Einträge, die der Dienst verwendet, finden Sie unter DNS-Einträge in Azure NetApp Files. Lesen Sie außerdem die Informationen unter Richtlinien für DNS mit Active Directory und Integrieren von AD DS in eine vorhandene DNS-Infrastruktur.
Azure DNS-Integration in Azure NetApp Files
Azure DNS ist ein gehosteter Dienst für die DNS-Verwaltung und -Namensauflösung in Microsoft Azure. Er kann verwendet werden, um öffentliche oder private DNS-Namen für andere Anwendungen und Dienste zu erstellen, die Sie in Azure bereitstellen, einschließlich Azure NetApp Files. Das Bereitstellen von DNS in Azure verhindert, dass DNS-Anforderungen (über Port 53) direkt zwischen Azure NetApp Files und lokalem DNS und/oder einer Active Directory-Domäne gesendet werden müssen. Darüber hinaus kann Azure DNS verwendet werden, um bedingte Weiterleitungen (mit dem Azure-Konfliktlöser für privates DNS) zu erstellen, mit denen DNS-Anforderungen von Azure NetApp Files über in Azure gehostete private DNS-Server an bestimmte DNS-Server gesendet werden können, die für die Verwendung in der Active Directory-Verbindung angegeben werden können.
Informationen zur Verwendung von Azure DNS:
- Funktionsweise von Azure DNS mit anderen Azure-Diensten
- Schnellstart: Erstellen einer Azure DNS-Zone und eines DNS-Eintrags mit dem Azure-Portal
- Schnellstart: Erstellen einer privaten Azure DNS-Zone im Azure-Portal
- Schnellstart: Erstellen einer Azure DNS Private Resolver-Instanz über das Azure-Portal
Verwenden von IP-Adressen für den Lastenausgleich mit DNS in Azure NetApp Files
Ein Lastenausgleichsgerät ist eine Möglichkeit, um eine einzelne IP-Adresse für die Behandlung mehrerer IP-Adressen im Back-End zu verwenden. Dies bietet Sicherheit durch Obfuskation sowie Leistungs- und Redundanzvorteile für Unternehmensumgebungen.
Ein DNS-Lastenausgleich kann Anforderungen behandeln und an mehrere DNS-Server senden, die in einem Pool festgelegt sind. Microsoft Azure bietet native Lastenausgleichsdienste für mehrere Anwendungsfälle.
Azure NetApp Files unterstützt die Verwendung von DNS-Lastenausgleichsmodulen, sofern sie eine IP-Adresse als Endpunkt bereitstellen und diese IP-Adresse über Port 53 mit den Azure NetApp Files-Netzwerken kommunizieren kann. Azure Traffic Manager stellt beispielsweise den DNS-Lastenausgleich auf Schicht 7 bereit, bietet jedoch nur einen Front-End-Hostnamen für die Verwendung. Active Directory-Verbindungen für Azure NetApp Files lassen nur die Angabe von IP-Adressen für DNS-Server zu.
Typen von DNS-Einträgen in Azure NetApp Files
Azure NetApp Files verwendet verschiedene Typen von DNS-Einträgen für den Zugriff auf Dateidienste.
| DNS-Eintragstyp | Definition |
|---|---|
| A/AAAA | DNS-A-Einträge sind Adresseinträge, die die IPv4-Adresse für einen Hostnamen angeben. AAAA-Einträge geben die IPv6-Adresse für einen Hostnamen an. Azure NetApp Files verwendet A/AAAA-Einträge auf folgende Weise:
|
| Zeigereinträge (PTR) | Ein PTR-Eintrag ordnet eine IP-Adresse mithilfe einer Reverse-Lookupzone einem Hostnamen zu. PTR-Einträge werden in erster Linie verwendet, wenn eine IP-Adresse für eine Einbindung/Freigabe in Azure NetApp Files angegeben wird. Die Verwendung einer IP-Adresse in Einbindungs-/Freigabeanforderungen kann sich auf die verwendete Authentifizierungsmethode auswirken. Weitere Informationen finden Sie unter IP-Adressen für den Zugriff mit Kerberos. |
| Diensteinträge (SRV) |
SRV-Einträge werden verwendet, um anzugeben, welche Hosts und Ports für einen bestimmten Dienst verwendet werden, z. B. LDAP, NFS, CIFS, Kerberos usw. SRV-Einträge in Azure NetApp Files werden im hohen Maße für die Dateidienstsicherheit (z. B. Kerberos), die Standortermittlung in Active Directory, LDAP-Serverabfragen und vieles mehr genutzt. Es ist wichtig, zu überprüfen, ob diese Datensätze vorhanden sind, um die ordnungsgemäße Funktionalität von Azure NetApp Files-Diensten zu gewährleisten. SRV-Einträge können mithilfe des Befehls nslookup oder dig abgefragt werden. Beispiele finden Sie unter Verwenden von nslookup und dig für DNS-Abfragen. |
| Kanonischer Namenseintrag (CNAME) | Ein CNAME-Eintrag ist eine Möglichkeit, DNS-Aliase für A/AAAA-Einträge bereitzustellen. CNAME-Einträge sind optional, können aber hilfreich sein, um die Komplexität der Hostnameneinträge zu verringern, die von Azure NetApp Files bereitgestellt werden. Weitere Informationen finden Sie unter DNS-Aliase und CNAME-Einträge. |
| Uniform Resource Identifier (URI) | Ein URI-Eintrag ist eine Möglichkeit zum Zuordnen von Hostnamen/IP-Adressen für Dienste zu URIs. URIs werden in einem Format wie „Dienst://fqdn.contoso.com“ angegeben. Azure NetApp Files verwendet Abfragen für URI-Datensätze nur, wenn Kerberos-KDC-Suchvorgänge für NFS-Kerberos-Anforderungen ausgeführt werden. URI-Einträge werden standardmäßig nicht in Active Directory-DNS-Bereitstellungen erstellt. Daher sind URI-Suchanforderungen in der Regel nicht erfolgreich und greifen auf SRV-Eintragssuchvorgänge zurück. |
Diensteinträge (SRV), die mit Azure NetApp Files verwendet werden
Azure NetApp Files verwendet die folgenden SRV-Einträge:
-
NFS Kerberos*
- _kerberos-master._tcp.CONTOSO.COM (Port 88)*
- _kerberos-master._tcp.CONTOSO.COM (Port 88)*
-
SMB/Active Directory site discovery**
- _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.{andere Sitenamen}._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.{andere Sitenamen}._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)
* Active Directory-DNS erstellt diese SRV-Einträge nicht standardmäßig. Es wird dringend empfohlen, sie zu erstellen, wenn NFS Kerberos verwendet wird.
* Active Directory-DNS erstellt diese SRV-Einträge standardmäßig.
Weitere Informationen dazu, wie Azure NetApp Files SRV-Einträge verwendet, finden Sie hier:
- Grundlegendes zur Verwendung des Lightweight Directory Access-Protokolls in Azure NetApp Files
- Informationen zu Kerberos in Azure NetApp Files
Hinweis
Für die ordnungsgemäße Ermittlung und Redundanz von Schlüsselverteilungscentern in NFS Kerberos müssen URI-Einträge und/oder kerberos-master-SRV-Einträge erstellt werden.
Dynamisches DNS
Azure NetApp Files-Volumes stellen eine einzelne IP-Adresse für ein Volume bereit, das dann automatisch über dynamisches DNS (DDNS) zum DNS hinzugefügt wird (sofern dynamisches DNS auf dem DNS-Server unterstützt wird). Hostnamen (anstelle von IP-Adressen) werden für Volumebereitstellungspfade in bestimmten Konfigurationen verwendet. Die Verwendung von Hostnamen in Bereitstellungspfaden erfordert DNS für die ordnungsgemäße Funktionalität:
- SMB-Volumes
- NFSv4.1 Kerberos
- Dual-Protokoll-Volumes
NFSv4.1 Kerberos:
SMB
Dual-Protokoll
Eine IP-Adresse wird für den Bereitstellungspfad verwendet, wenn für ein Azure NetApp File-Volume kein DNS erforderlich ist, z. B. NFSv3 oder NFSv4.1 ohne Kerberos.
NFSv3
Überlegungen
In Azure NetApp Files senden Updates für dynamisches DNS zwei unterschiedliche Anforderungen an den konfigurierten DNS-Server: eine für die Erstellung/Aktualisierung eines PTR-Eintrags und eine für die Erstellung/Aktualisierung eines A/AAAA-Eintrags.
Mit Hostnamen erstellte Azure NetApp Files-Volumes benachrichtigen automatisch den DNS-Server, um einen A/AAAA-Eintrag zu erstellen. Dies geschieht unmittelbar nach Abschluss der Volumeerstellung.
Wenn bereits ein DNS-A/AAAA-Eintrag für die Kombination aus IP-Adresse/Hostname vorhanden ist, werden keine neuen Einträge erstellt.
Wenn ein DNS-A/AAAA-Eintrag für denselben Hostnamen mit einer anderen IP-Adresse vorhanden ist, wird ein zweiter A/AAAA-Eintrag mit demselben Namen erstellt.
Für Azure NetApp Files-Volumes, die ohne Hostnamen erstellt wurden (z. B. NFSv3-Volumes), erstellt dynamisches DNS nicht die DNS-Einträge, da dem Dienst kein Hostname zugewiesen ist. Die Einträge müssen manuell erstellt werden.
Wenn eine Reverse-Lookupzone für das IP-Subnetz der Schnittstelle vorhanden ist, erstellt der DNS-Server auch einen PTR-Eintrag. Wenn die erforderliche Reverse-Lookupzone nicht vorhanden ist, kann ein PTR-Eintrag nicht automatisch erstellt werden. Sie müssen den PTR-Eintrag manuell erstellen.
Wenn ein von dynamischem DNS erstellter DNS-Eintrag auf dem DNS-Server gelöscht wird, wird er innerhalb von 24 Stunden durch ein neues dynamisches DNS-Update aus Azure NetApp Files neu erstellt.
Sicheres DDNS wird aktiviert, wenn SMB- oder Dual-Protokoll-Volumes erstellt werden. NFS-Volumes aktivieren kein sicheres DDNS, aber DDNS. Wenn sicheres DDNS auf dem DNS-Server deaktiviert ist oder bei der Kerberos-Authentifizierung ein Fehler auftritt, funktionieren DDNS-Updates nicht.
Typ des dynamischen DNS Port Standard-DNS UDP 53 Sicheres DNS TCP 53 Azure NetApp Files unterstützt sicheres DDNS nur mit Microsoft Active Directory-DNS-Servern.
Eintragsdetails zu dynamischem DNS
Wenn Azure NetApp Files einen DNS A/AAAA-Eintrag über dynamisches DNS erstellt, werden die folgenden Konfigurationen verwendet:
- Ein zugeordnetes PTR-Datensatzfeld ist aktiviert: Wenn Reverse-Lookup-Zonen für das Subnetz vorhanden sind, erstellen A/AAAA-Einträge automatisch PTR-Datensätze ohne Administratoreingriff.
- Das Kästchen „Diesen Datensatz löschen, wenn er veraltet ist“, ist aktiviert: Wenn der DNS-Eintrag „veraltet“ ist, löscht DNS den Eintrag, sofern der Aufräumvorgang aktiviert wurde.
- Die TTL des DNS-Eintrags ist auf einen Tag (24 Stunden) festgelegt: Die TTL-Einstellung kann vom DNS-Admin bei Bedarf geändert werden. Die TTL für einen DNS-Eintrag bestimmt, wie lange ein DNS-Eintrag im DNS-Cache eines Clients vorhanden ist.
Hinweis
Um Zeitstempel und die Gültigkeitsdauer (Time to Live, TTL) der Erstellung eines DNS-Eintrags in Windows Active Directory-DNS anzuzeigen, navigieren Sie zum Menü „Ansicht“ des DNS-Managers, und wählen Sie dann „Erweitert“ aus. Wählen Sie dort den A/AAAA-Eintrag aus, und zeigen Sie die Eigenschaften an.
Funktionsweise von dynamischem Standard-DNS in Azure NetApp Files
Azure NetApp Files folgt vier grundlegenden Schritten zum Erstellen von Updates für dynamisches DNS für die konfigurierten DNS-Server. Standardmäßige DDNS-Updates (Dynamisches DNS) durchlaufen UDP-Port 53.
- Eine SOA-DNS-Abfrage für die IP-Adresse der Azure NetApp Files-Volumeschnittstelle wird ausgeführt.
- Ein DDNS-Update für den PTR wird ausgeführt. Wenn der PTR nicht vorhanden ist, wird er erstellt.
- Für den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Azure NetApp Files-Volumes wird eine DNS-SOA-Abfrage (Start Of Authority, Autoritätsursprung) erstellt.
- Ein DDNS-Update für den A/AAAA-Eintrag wird ausgeführt. Wenn der Eintrag nicht vorhanden ist, wird er erstellt.
Dynamisches DNS über Paketerfassung
Paketerfassungen können bei der Behandlung von Dienstproblemen hilfreich sein, für die möglicherweise keine Protokollierung zur Analyse zur Verfügung steht. Erweitern Sie diese Ansicht, um detaillierte Informationen zu den Paketerfassungen anzuzeigen.
Eine SOA-DNS-Abfrage für die IP-Adresse der Azure NetApp Files-Volumeschnittstelle wird ausgeführt.
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:1111Ein DDNS-Update für den PTR wird ausgeführt. Wenn der PTR nicht vorhanden ist, wird er erstellt.
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.localFür den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Azure NetApp Files-Volumes wird eine DNS-SOA-Abfrage (Start Of Authority, Autoritätsursprung) erstellt.
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:1111Ein DDNS-Update für den A/AAAA-Eintrag wird ausgeführt. Wenn der Eintrag nicht vorhanden ist, wird er erstellt.
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
Funktionsweise von DDNS in Azure NetApp Files
Wenn sicheres DNS aktiviert ist, verhandelt Azure NetApp Files mit dem DNS-Server, um sich über GSS mithilfe der Authentifizierung mit Transaktion geheimer Schlüssel für DNS zu authentifizieren, und stellt sicher, dass die angeforderten Updates aus einer legitimen Quelle stammen. Im Folgenden werden die Schritte für diesen Prozess gezeigt. Updates für sicheres DDNS durchlaufen TCP-Port 53.
- Eine SOA-DNS-Abfrage für die IP-Adresse der Azure NetApp Files-Volumeschnittstelle wird ausgeführt.
- Ein Kerberos-Dienstticket wird für den DNS-Dienst auf dem DNS-Server ausgetauscht.
- Das Ticket wird dann in einer DNS-Abfrage für einen Transaktionsschlüssel (TKEY) von Azure NetApp Files an den DNS-Server verwendet, der mithilfe von GSS-TSIG (Transaktionssignatur) zur Authentifizierung übergeben wird.
- Nach der erfolgreichen Authentifizierung wird ein Update für sicheres dynamisches DNS mithilfe des TKEY gesendet, um den PTR zu erstellen, der mithilfe von GSS-TSIG gesendet wird. Wenn der Eintrag nicht bereits vorhanden ist, wird er erstellt.
- Für den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Azure NetApp Files-Volumes wird eine DNS-SOA-Abfrage gesendet, und es wird darauf geantwortet.
- Eine neue TKEY-ID wird zwischen dem DNS-Server und Azure NetApp Files ausgetauscht.
- Ein Update für sicheres dynamisches DNS wird mithilfe des TKEY gesendet, um den A/AAAA-Eintrag für den FQDN zu erstellen. Wenn der Eintrag bereits mit derselben IP-Adresse vorhanden ist, werden keine Änderungen vorgenommen.
Dynamisches DNS über Paketerfassung
Paketerfassungen können bei der Behandlung von Dienstproblemen hilfreich sein, für die möglicherweise keine Protokollierung zur Analyse zur Verfügung steht. Erweitern Sie diese Ansicht, um detaillierte Informationen zu den Paketerfassungen anzuzeigen.
Eine SOA-DNS-Abfrage für die IP-Adresse der Azure NetApp Files-Volumeschnittstelle wird ausgeführt.
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:1111Ein Kerberos-Dienstticket wird für den DNS-Dienst auf dem DNS-Server ausgetauscht.
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-REPDas Ticket wird dann in einer DNS-Abfrage für einen Transaktionsschlüssel (TKEY) von Azure NetApp Files an den DNS-Server verwendet, der mithilfe von GSS-TSIG (Transaktionssignatur) zur Authentifizierung übergeben wird.
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 TSIGNach der erfolgreichen Authentifizierung wird ein Update für sicheres dynamisches DNS mithilfe des TKEY gesendet, um den PTR zu erstellen, der mithilfe von GSS-TSIG gesendet wird. Wenn der Eintrag nicht bereits vorhanden ist, wird er erstellt.
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)Für den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Azure NetApp Files-Volumes wird eine DNS-SOA-Abfrage gesendet, und es wird darauf geantwortet.
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:1111Eine neue TKEY-ID wird zwischen dem DNS-Server und Azure NetApp Files ausgetauscht.
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 TSIGEin Update für sicheres dynamisches DNS wird mithilfe des TKEY gesendet, um den A/AAAA-Eintrag für den FQDN zu erstellen. Wenn der Eintrag bereits mit derselben IP-Adresse vorhanden ist, werden keine Änderungen vorgenommen.
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)
DNS-Zwischenspeicherung
Um die Last auf DNS-Servern zu reduzieren, verwenden DNS-Clients Zwischenspeicherungskonzepte zum Speichern früherer Abfragen im Arbeitsspeicher, sodass wiederholte Anforderungen für einen Hostnamen, eine IP oder einen Dienst lokal für den Zeitraum aufbewahrt werden, der durch die TTL des DNS-Eintrags definiert wird.
Azure NetApp Files verwendet DNS-Caches wie jeden anderen Standard-DNS-Client. Wenn der Dienst einen DNS-Eintrag anfordert, ist für diesen Eintrag eine TTL definiert. Standardmäßig verfügen Active Directory-DNS-Einträge über eine TTL von 600 Sekunden (10 Minuten), sofern nicht anders angegeben. Wenn ein DNS-Eintrag aktualisiert und im Azure NetApp Files-Cache gespeichert wird und die TTL 10 Minuten beträgt, wird der neue Eintrag in Azure NetApp Files erst aktualisiert, wenn der Cache nach dem Timeoutwert gelöscht wird. Es gibt derzeit keine Möglichkeit, diesen Cache manuell zu bereinigen. Wenn eine kürzere TTL gewünscht wird, nehmen Sie die Änderung auf dem DNS-Server vor.
Bei Verwendung externer DNS-Server (z. B. BIND) können sich die Standardtimeoutwerte unterscheiden. Wenn keine TTL definiert wird, beträgt die TTL eines BIND-DNS-Eintrags 604.800 Sekunden (sieben Tage). Dies ist zu lang für die effektive DNS-Zwischenspeicherung. Daher ist es wichtig, beim manuellen Erstellen von DNS-Einträgen die TTL für den Eintrag manuell auf einen angemessenen Wert festzulegen. Es wird empfohlen, den Microsoft-Standardwert von 10 Minuten zu verwenden, um eine optimale Mischung aus Leistung und Zuverlässigkeit für DNS-Lookups zu erreichen.
Sie können die TTL eines DNS-Eintrags manuell mithilfe des Befehls nslookup oder dig abfragen. Beispiele finden Sie unter Verwenden von nslookup und dig für DNS-Abfragen.
Löschen/Aufräumen von DNS-Einträgen
Die meisten DNS-Server stellen Methoden zum Löschen und Aufräumen abgelaufener Einträge bereit. Die Bereinigung verhindert, dass veraltete Einträge DNS-Server überladen und zu Szenarien führen, in denen doppelte A/AAAA- und/oder PTR-Einträge vorhanden sind, was zu unvorhersehbaren Ergebnissen für Azure NetApp Files-Volumes führen kann.
Wenn mehrere PTR-Einträge für denselben IP-Adresspunkt auf unterschiedliche Hostnamen verweisen, können Kerberos-Anforderungen fehlschlagen, da während der DNS-Lookup-Vorgänge der falsche SPN abgerufen wird. DNS erkennt nicht, welcher PTR-Eintrag zu welchem Hostnamen gehört. Stattdessen führen Reverse-Lookup-Vorgänge eine Roundrobinsuche durch jeden A/AAAA-Eintrag für jeden neuen Lookup durch.
Beispiel:
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
DNS-Aliase und kanonische Namenseinträge (CNAME-Einträge)
Azure NetApp Files erstellt einen DNS-Hostnamen für ein Volume, das für ein Protokoll konfiguriert wurde, das DNS für die ordnungsgemäße Funktionalität benötigt, z. B. SMB, duales Protokoll oder NFSv4.1 mit Kerberos. Der erstellte Name verwendet das Format des SMB-Servers (Computerkonto) als Präfix beim Erstellen der Active Directory-Verbindung für das NetApp-Konto. Zusätzliche alphanumerische Zeichen werden hinzugefügt, sodass mehrere Volumeeinträge im gleichen NetApp-Konto eindeutige Namen haben. In den meisten Fällen versuchen mehrere Volumes, die Hostnamen erfordern und in demselben NetApp-Konto vorhanden sind, dieselben Hostnamen/IP-Adressen zu verwenden. Wenn beispielsweise der SMB-Servername SMB-West.contoso.com lautet, folgen Hostnameneinträgen dem Format von SMB-West-XXXX.contoso.com.
In einigen Fällen ist der von Azure NetApp Files verwendete Name möglicherweise nicht benutzerfreundlich genug, um ihn Endbenutzenden zu übergeben, oder Administrierende möchten möglicherweise vertrautere DNS-Namen beibehalten, die verwendet werden, wenn Daten aus dem lokalen Speicher zu Azure NetApp Files migriert wurden (d. h., wenn der ursprüngliche DNS-Name „datalake.contoso.com“ war, möchten Endbenutzende diesen Namen möglicherweise weiterhin verwenden).
Azure NetApp Files lässt die Spezifikation der verwendeten DNS-Hostnamen nicht nativ zu. Wenn Sie einen alternativen DNS-Namen mit derselben Funktionalität benötigen, sollten Sie einen DNS-Alias/kanonischen Namen (CNAME) verwenden.
Die Verwendung eines CNAME-Eintrags (anstelle eines zusätzlichen A/AAAA-Eintrags), der auf den A/AAAA-Eintrag des Azure NetApp Files-Volumes verweist, nutzt denselben SPN wie der SMB-Server, um den Kerberos-Zugriff sowohl für den A/AAAA-Eintrag als auch für CNAME zu ermöglichen. Betrachten Sie das Beispiel eines A/AAAA-Eintrags von SMB-West-XXXX.contoso.com. Der CNAME-Eintrag von datalake.contoso.com ist so konfiguriert, dass er auf den A/AAAA-Eintrag von SMB-West-XXXX.contoso.com verweist. SMB- oder NFS-Kerberos-Anforderungen an datalake.contoso.com verwenden den Kerberos-SPN für SMB-West-XXXX, um Zugriff auf das Volume zu ermöglichen.
Verwenden von „nslookup“ und „dig“ für DNS-Abfragen
DNS-Server können manuell mit DNS-Tools wie nslookup (Windows- und Linux-Clients) und dig (Linux-Clients) abgefragt werden. Die Verwendung dieser Tools ist in bestimmten Szenarien hilfreich, etwa beim Versuch, die Funktionalität von Diensten zu überprüfen, beim Testen von Hostname/IP-Auflösung, beim Suchen nach vorhandenen/veralteten DNS-Einträgen sowie beim Überprüfen der Serverkonfiguration und der TTL. Zusätzliche Problemlösungsschritte finden Sie auch in der Azure-Verbindungsproblembehandlung.
Die Befehle nslookup und dig können über eine Remoteverbindung mit dem virtuellen Computer (z. B. über Bastion) oder direkt über die Option „Befehl ausführen“ auf der VM selbst ausgeführt werden.
nslookup mit Windows
Sie können nslookup ausführen, um grundlegende IP-Adressinformationen ohne Optionen zu sammeln:
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
Um nur TTL-Informationen für den Eintrag abzufragen, verwenden Sie die Befehlsoption -query=hinfo.
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)
Die Option -debug kann auch verwendet werden, um detailliertere Informationen zum DNS-Eintrag zu sammeln.
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)
dig mit 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
Bewährte DNS-Methoden in Azure NetApp Files
Stellen Sie sicher, dass Sie die folgenden DNS-Konfigurationsanforderungen erfüllen:
- Geben Sie für Redundanz mehr als einen DNS-Server in der DNS-Konfiguration an.
- Um optimale Ergebnisse zu erzielen, verwenden Sie DNS, das in Active Directory integriert und/oder in Active Directory installiert ist.
- Wenn Sie eigenständige DNS-Server verwenden:
- Stellen Sie sicher, dass DNS-Server Netzwerkkonnektivität mit dem delegierten Azure NetApp Files-Subnetz haben, das die Azure NetApp Files Volumes hostet.
- Stellen Sie sicher, dass Netzwerkports UDP 53 und TCP 53 nicht durch Firewalls oder Netzwerksicherheitsgruppen blockiert werden.
- Stellen Sie sicher, dass die vom AD DS-Netzwerkanmeldungsdienst registrierten SRV-Einträge auf den DNS-Servern erstellt wurden. Außerdem müssen die unter Typen von DNS-Einträgen in Azure NetApp Filesaufgeführten Diensteinträge erstellt worden sein.
- Stellen Sie sicher, dass die PTR-Einträge für die AD DS-Domänencontroller, die von Azure NetApp Files verwendet werden, auf den DNS-Servern in derselben Domäne wie Ihre Azure NetApp Files-Konfiguration erstellt wurden.
- Azure NetApp Files unterstützt standardmäßige und sichere dynamische DNS-Updates. Wenn Sie sichere dynamische DNS-Updates benötigen, stellen Sie sicher, dass sichere Updates auf den DNS-Servern konfiguriert sind.
- Stellen Sie sicher, dass eine Reverse-Lookupzone für das Azure NetApp Files-Subnetz erstellt wurde, damit dynamisches DNS zusätzlich zum A/AAAA-Eintrag PTR-Einträge erstellen kann.
- Wenn ein DNS-Alias erforderlich ist, verwenden Sie einen CNAME-Eintrag. Verweisen Sie den CNAME-Eintrag auf die A/AAAA-Einträge für Azure NetApp Files.
- Wenn Sie Updates für dynamisches DNS nicht verwenden, müssen Sie manuell einen A-Eintrag und einen PTR-Eintrag für die AD DS-Computerkonten erstellen, die in der AD DS-Organisationseinheit (angegeben in der Azure NetApp Files-AD-Verbindung) erstellt wurden, um Azure NetApp Files-LDAP-Signatur, LDAP über TLS, SMB, Dual-Protokoll oder Kerberos NFSv4.1-Volumes zu unterstützen.
- Für komplexe oder große AD DS-Topologien können DNS-Richtlinien oder DNS-Subnetzpriorisierung erforderlich sein, um LDAP-aktivierte NFS-Volumes zu unterstützen.
- Wenn der DNS-Aufräumvorgang aktiviert ist (wobei veraltete DNS-Einträge basierend auf Zeitstempel/Alter automatisch gelöscht werden) und dynamisches DNS zum Erstellen der DNS-Einträge für das Azure NetApp Files-Volume verwendet wurde, kann es vorkommen, dass die Einträge für das Volume versehentlich durch den Aufräumvorgang gelöscht werden. Diese Bereinigung kann zu einem Dienstausfall für namenbasierte Abfragen führen. Bis dieses Problem behoben ist, erstellen Sie manuell A/AAAA- und PTR-DNS-Einträge für das Azure NetApp Files-Volume, wenn der DNS-Aufräumvorgang aktiviert ist.