Grundlegendes zu DNS in Azure NetApp Files

  • Artikel

Der DNS-Dienst (Domain Name Systems) ist eine wichtige Komponente des Datenzugriffs in Azure NetApp Files bei Verwendung von Dateiprotokollen, die auf Kerberos für die Authentifizierung (einschließlich SMB und NFSv4.1) angewiesen sind. Ein Hostname vereinfacht den Zugriff auf ein Volume und schützt vor Szenarien, wenn sich eine IP-Adresse ändert. Anstatt Benutzer über eine neue IP-Adresse zu informieren, können sie den Hostnamen weiterhin verwenden.

Standardmäßig verwendet die Kerberos-Authentifizierung die Name-zu-IP-Adressauflösung, um den Dienstprinzipalnamen (Service Principal Name, SPN) zu formulieren, der zum Abrufen des Kerberos-Tickets verwendet wird. Wenn beispielsweise auf eine SMB-Freigabe mit einem UNC-Pfad (Universal Naming Convention) wie \SMB.CONTOSO.COM zugegriffen wird, wird eine DNS-Anforderung für SMB.CONTOSO.COM ausgegeben, und die IP-Adresse des Azure NetApp Files-Volumes wird abgerufen. Wenn kein DNS-Eintrag vorhanden ist (oder der aktuelle Eintrag sich von den angeforderten Einträgen unterscheidet, z. B. mit Aliasen/CNAMEs), kann kein ordnungsgemäßer SPN abgerufen werden, und die Kerberos-Anforderung schlägt fehl. Daher kann der Zugriff auf das Volume nicht zulässig sein, wenn die Fallbackauthentifizierungsmethode (z. B. New Technology LAN Manager) deaktiviert ist.

NFSv4.1 Kerberos funktioniert ähnlich für den SPN-Abruf, wobei DNS-Lookup-Vorgänge für den Authentifizierungsprozess integral sind und auch für die Kerberos-Bereichsermittlung verwendet werden können.

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 AD DS oder Azure NetApp Files können zu Unterbrechungen des Clientzugriffs oder Clienttimeouts führen.

IP-Adressen für den Zugriff mit Kerberos

Wenn eine IP-Adresse in einer Zugriffsanforderung auf ein Azure NetApp Files-Volume verwendet wird, funktioniert eine Kerberos-Anforderung je nach verwendetem Protokoll unterschiedlich.

SMB

Bei Verwendung von SMB versucht eine Anforderung für eine UNC mit \x.x.x.x.x standardmäßig, NTLM für die Authentifizierung zu verwenden. In Umgebungen, in denen NTLM aus Sicherheitsgründen nicht zulässig ist, ist eine SMB-Anforderung mit einer IP-Adresse standardmäßig nicht in der Lage, Kerberos oder NTLM für die Authentifizierung zu verwenden. Daher wird der Zugriff auf das Azure NetApp Files-Volume verweigert. In späteren Windows-Versionen (ab Windows 10, Version 1507 und Windows Server 2016) können Kerberos-Clients so konfiguriert werden, dass IPv4- und IPv6-Hostnamen in SPNs für die SMB-Kommunikation unterstützt werden.

NFSv4.1

Bei der Verwendung von NFSv4.1 verwendet eine Einbindungsanforderung an eine IP-Adresse mit einer der sec=[krb5/krb5i/krb5p]-Optionen Reverse-DNS-Lookups über einen Pointer Record (PTR), um eine IP-Adresse in einen Hostnamen aufzulösen, der dann zur Formulierung des SPN für den Ticketabruf verwendet wird. Wenn Sie NFSv4.1 mit Kerberos verwenden, sollten Sie über ein A/AAAA- und PTR-Volume für das Azure NetApp Files-Volume verfügen, um Hostnamen- und IP-Adresszugriff auf Einbindungen abzudecken.

DNS-Einträge in Azure NetApp Files

Azure NetApp Files-Volumes unterstützen dynamische DNS-Updates, wenn der DNS-Server dynamische DNS unterstützt. Bei dynamischem DNS benachrichtigen Volumes, die mit Hostnamen erstellt wurden, automatisch den DNS-Server, um einen A/AAAA-Eintrag zu erstellen. Wenn eine Reverse-Lookup-Zone vorhanden ist, erstellt DNS auch einen PTR-Eintrag. Wenn die Reverse-Lookup-Zone nicht vorhanden ist, wird kein PTR-Eintrag automatisch erstellt, was bedeutet, dass Sie ihn manuell erstellen müssen.

Hostnamen (anstelle von IP-Adressen) werden für Volume-Mount-Pfade in bestimmten Konfigurationen verwendet, die alle DNS für die ordnungsgemäße Funktionalität erfordern:

  • SMB-Volumes
  • NFSv4.1 Kerberos
  • Dual-Protokoll-Volumes

Eine IP-Adresse wird verwendet, wenn für ein Azure NetApp File-Volume kein DNS erforderlich ist, z. B. NFSv3 oder NFSv4.1 ohne Kerberos. In diesen Fällen können Sie bei Bedarf manuell einen DNS-Eintrag 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.

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-Administrator 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 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.

Löschen/Aufräumen von DNS-Einträgen

Die meisten DNS-Server stellen Methoden zum Löschen/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. Zum 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 Endbenutzern zu übergeben, oder Administratoren 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 Endbenutzer 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.

Bewährte DNS-Methoden in Azure NetApp Files

Stellen Sie sicher, dass Sie die folgenden Anforderungen für die DNS-Konfigurationen erfüllen:

  • Wenn Sie eigenständige DNS-Server verwenden:
    • Stellen Sie sicher, dass DNS-Server Netzwerkkonnektivität auf das 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 NSGs blockiert werden.
  • Stellen Sie sicher, dass die SRV-Einträge, die vom AD DS Net Logon-Dienst registriert wurden, auf den DNS-Servern erstellt wurden.
  • 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.
  • Wenn Sie dynamische DNS-Updates 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 Signing, LDAP über TLS, SMB, Dualprotokoll 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.

Nächste Schritte