--- title: VServer Services: NS Switch konfigurieren canonical: https://webhosting-verstehen.de/vserver-services-ns-switch-konfigurieren/ author: Webhosting-Verstehen Redaktion published: 2026-09-25 updated: 2026-09-07 language: de category: Virtual Private Server (VPS) description: Der Artikel erklärt die Prüfung und Änderung von NS-Switch-Einträgen je SVM, zulässige Quellenfolgen sowie deren Auswirkungen auf Host-, Benutzer-, Gruppen- und Namensauflösung. source: Provimedia GmbH --- # VServer Services: NS Switch konfigurieren > **Autor:** Webhosting-Verstehen Redaktion | **Veröffentlicht:** 2026-09-25 | **Aktualisiert:** 2026-09-07 **Zusammenfassung:** Der Artikel erklärt die Prüfung und Änderung von NS-Switch-Einträgen je SVM, zulässige Quellenfolgen sowie deren Auswirkungen auf Host-, Benutzer-, Gruppen- und Namensauflösung. --- ## Voraussetzungen und zulässige NS-Switch-Datenbanken Für die Änderung des NS Switch benötigen Sie eine Administratorsitzung auf dem Cluster oder der betroffenen SVM. Der Eintrag gilt immer für genau einen Vserver. Prüfen Sie daher vor der Änderung den Namen der SVM und arbeiten Sie nicht versehentlich im falschen Mandanten. Die Auswahl der Datenbank bestimmt, welche Informationen ONTAP über externe Dienste suchen darf. Zulässig sind: - **hosts** für Hostnamen und IP-Adressen. Erlaubt sind *files* und *dns*. - **group** für Gruppen. Erlaubt sind *files*, *nis* und *ldap*. - **passwd** für Benutzer. Erlaubt sind *files*, *nis* und *ldap*. - **netgroup** für Netgroups. Erlaubt sind *files*, *nis* und *ldap*. - **namemap** für Benutzerzuordnungen. Erlaubt sind *files* und *ldap*. Die Kombination muss zur jeweiligen Datenbank passen. Ein Eintrag wie *dns* bei *passwd* oder *nis* bei *hosts* ist nicht zulässig. Besondere Vorsicht gilt für **passwd** und **group**. Fehlt dort *files*, müssen die für ONTAP benötigten lokalen Standardkonten und Gruppen in LDAP oder NIS vorhanden sein. Andernfalls können Zugriffe, Zuordnungen oder Verwaltungsfunktionen scheitern, obwohl der externe Dienst erreichbar ist. Stimmen Sie die Identitäten und Gruppen daher vor der Umstellung mit dem Verzeichnis ab. Die vollständige Liste hängt vom eingesetzten ONTAP-Release und den aktivierten Funktionen ab und sollte gegen die NetApp-Dokumentation der verwendeten Version geprüft werden. Die spätere Änderung verwendet den Vserver-Namen, die Datenbank und eine gültige Quellenfolge. Mehrere Quellen werden mit Kommas getrennt; ihre Reihenfolge ist bewusst zu wählen. Eine externe Quelle allein ist nur dann sinnvoll, wenn Ausfallsicherheit und vollständige Einträge bereits geprüft sind. ## Aktuelle NS-Switch-Einträge mit `show` prüfen Prüfen Sie die bestehende NS-Switch-Tabelle, bevor Sie einen Eintrag ändern. So erkennen Sie die aktuelle Konfiguration und vermeiden eine Änderung am falschen Vserver. Für die vollständige Übersicht verwenden Sie: *cluster1::> vserver services name-service ns-switch show* Eine gezielte Prüfung ist meist übersichtlicher. Mit **-vserver** begrenzen Sie die Ausgabe auf eine SVM: *cluster1::> vserver services name-service ns-switch show -vserver vs0* Zusätzlich können Sie nach einer Datenbank filtern: *cluster1::> vserver services name-service ns-switch show -vserver vs0 -database hosts* Mit **-fields** lassen sich ausgewählte Spalten anzeigen: *cluster1::> vserver services name-service ns-switch show -fields vserver,database,sources* Benötigen Sie die vollständigen Details jedes Eintrags, verwenden Sie **-instance**: *cluster1::> vserver services name-service ns-switch show -instance* Achten Sie bei der Ausgabe besonders auf: - den richtigen Vserver, - einen vorhandenen Eintrag für die gewünschte Datenbank, - die beabsichtigte Quellenfolge. Eine mehrzeilig dargestellte Quellenliste gehört weiterhin zu einem Eintrag. Die Zeilenumbrüche in der CLI-Ausgabe bedeuten also nicht, dass mehrere getrennte Konfigurationen vorliegen. Mit **-sources** können Sie nach einer bestimmten Quellenfolge filtern; die Prüfung von Vserver und Datenbank ersetzt das jedoch nicht. ## Quellen und Abfragereihenfolge je Datenbank festlegen Die Quellenfolge sollte zum Datenfluss der jeweiligen Datenbank passen. Eine lokale Quelle eignet sich als schnelle erste Prüfung, ein Verzeichnisdienst für zentral verwaltete Identitäten. Maßgeblich sind ein klares Verhalten bei Treffern und Fehlern sowie eine erreichbare Dienstumgebung. Ordnen Sie die maßgebliche Quelle an die erste Stelle. Weitere Quellen dienen als Ergänzung oder Ausweichweg. Eine langsame oder nicht erreichbare Quelle an erster Stelle kann Anmeldungen und SMB-Vorgänge spürbar verzögern. Für **hosts** ist eine kurze Kette üblich. Mit *files,dns* prüft ONTAP zuerst lokale Einträge und fragt danach DNS ab. Umgekehrt eignet sich *dns,files*, wenn DNS die führende Datenbasis sein soll. Bei **passwd**, **group** und **netgroup** sollte die zentrale Quelle nach vorne, wenn LDAP oder NIS die verbindlichen Daten enthält. Eine Folge wie *ldap,nis* trennt die primäre Verzeichnisabfrage von der Ausweichquelle. Die Reihenfolge sollte in allen drei Datenbanken zusammenpassen; sonst können Benutzer und Gruppen aus unterschiedlichen Diensten stammen. Für **namemap** kommen nur *files* und *ldap* infrage. Nutzen Sie *files,ldap*, wenn lokale Zuordnungen Vorrang haben, oder *ldap,files*, wenn das zentrale Verzeichnis Priorität erhält. Das ist relevant, wenn derselbe Name in beiden Quellen vorkommt. Die gewünschte Folge tragen Sie mit dem Änderungsbefehl ein. Beispiel für eine zentrale LDAP-Abfrage mit NIS als Reserve: *cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database group -sources ldap,nis* Verwenden Sie keine Quelle, die für die gewählte Datenbank nicht zugelassen ist. Prüfen Sie außerdem, ob die Namensauflösung zwischen SVM und Dienstnetz funktioniert. Eine formal korrekte Reihenfolge hilft wenig, wenn DNS, LDAP oder NIS wegen Routing, Firewall oder Zertifikaten nicht erreichbar ist. ## Syntax von `vserver services name-service ns-switch modify` Mit **vserver services name-service ns-switch modify** ändern Sie einen vorhandenen NS-Switch-Eintrag für einen bestimmten Vserver. Der Befehl passt die Quellenfolge an; er richtet weder LDAP, NIS noch DNS selbst ein. Die Grundsyntax lautet: *cluster1::> vserver services name-service ns-switch modify -vserver -database [-sources ]* Der Parameter **-vserver** bestimmt das Ziel. Verwenden Sie den exakten Namen der Daten- oder Admin-SVM. Mit **-database** wählen Sie den zu ändernden Eintrag. **-sources** ist optional. Fehlt der Parameter, bleibt die bisherige Quellenfolge unverändert. Mehrere Quellen werden ohne Leerzeichen durch Kommas getrennt. Schreibweisen wie *ldap, nis* sollten Sie vermeiden, weil die ONTAP-CLI den Wert dann nicht wie beabsichtigt verarbeitet. Ein vollständiger Aufruf für die Hostdatenbank sieht so aus: *cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources files,dns* Für eine Passwortdatenbank mit LDAP und NIS lautet der Aufruf beispielsweise: *cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources ldap,nis* Verwenden Sie pro Aufruf genau eine Datenbank. Sollen mehrere Einträge geändert werden, führen Sie den Befehl für jede Datenbank separat aus. Dadurch bleibt im Änderungsprotokoll klar erkennbar, welche Konfiguration angepasst wurde. - **-vserver**: Ziel-Vserver - **-database**: NS-Switch-Datenbank - **-sources**: neue Quellenfolge, durch Kommas getrennt Für die Ausführung benötigen Sie ausreichende Administratorrechte. Ein syntaktisch korrekter Aufruf kann trotzdem auf die falsche SVM zeigen. Prüfen Sie den Zielnamen deshalb vor dem Absenden nochmals sorgfältig. ## Host-Auflösung mit `files` und `dns` konfigurieren Für die Datenbank **hosts** können Sie lokale Einträge und DNS miteinander kombinieren. Die Einstellung wirkt sich auf ONTAP-interne Hostabfragen der jeweiligen SVM aus. Sie ersetzt weder die DNS-Serverkonfiguration noch die Namensauflösung auf Clients. Eine typische Kombination lautet: *cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources files,dns* ONTAP berücksichtigt zuerst die lokale Quelle und greift anschließend auf DNS zurück. Diese Reihenfolge passt etwa für wenige feste Infrastrukturadressen, während reguläre Hosts aus DNS stammen. Soll DNS die alleinige Quelle sein, verwenden Sie: *cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources dns* Das vereinfacht die Konfiguration, erhöht aber die Abhängigkeit von erreichbaren DNS-Servern und einer korrekten DNS-Zone. Achten Sie auf passende A- und gegebenenfalls PTR-Einträge. Für Verbindungen genügt meist der A-Eintrag; Protokolle und Prüfungen können zusätzlich eine umgekehrte Auflösung erwarten. Nach der Änderung kontrollieren Sie die gespeicherte Quellenfolge: *cluster1::> vserver services name-service ns-switch show -vserver vs0 -database hosts* Bleibt eine Auflösung aus, prüfen Sie: - Ist die SVM über ihre Daten-LIFs zum DNS-Dienst geroutet? - Erlauben Firewalls DNS-Anfragen über UDP und bei Bedarf TCP auf Port 53? - Antwortet der zuständige DNS-Server für den abgefragten Namen? - Verweist der Name auf die erwartete IP-Adresse? Ein lokaler Treffer kann einen fehlerhaften DNS-Eintrag verdecken. Für Tests sollten Sie daher Namen verwenden, die nicht gleichzeitig in beiden Quellen mit unterschiedlichen Adressen vorkommen. ## Benutzer-, Gruppen- und Netgroup-Quellen mit LDAP oder NIS konfigurieren Für zentrale Benutzer-, Gruppen- und Netgroup-Abfragen setzen Sie die jeweilige Datenbank auf *ldap* oder *nis*. LDAP ist meist bei hierarchischen Verzeichnisstrukturen üblich, NIS eher in älteren UNIX-Umgebungen. Eine LDAP-basierte Konfiguration für Benutzer, Gruppen und Netgroups kann so aussehen: **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources ldap** **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database group -sources ldap** **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database netgroup -sources ldap** Für NIS lautet der entsprechende Aufbau: **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources nis** **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database group -sources nis** **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database netgroup -sources nis** Ein gemischter Betrieb ist möglich. Beispielsweise kann LDAP Benutzer liefern, während NIS Gruppen bereitstellt. Stimmen Benutzername, numerische ID und Gruppenzugehörigkeit nicht überein, entstehen schwer erkennbare Berechtigungsfehler. Prüfen Sie vor der Aktivierung: - ob der externe Dienst aus der SVM erreichbar ist, - ob Suchbasis und relevante Attribute zum ONTAP-Namensdienstprofil passen, - ob identische Namen in LDAP und NIS unterschiedliche IDs besitzen, - ob Netgroup-Mitglieder im erwarteten Format vorliegen, - ob Gruppenmitgliedschaften auch bei verschachtelten Gruppen korrekt geliefert werden. Verwenden Sie für eine Ausweichquelle etwa *ldap,nis*. Das ist nur sinnvoll, wenn beide Dienste denselben Identitätsbestand abbilden. Sonst kann ein Ausfall des primären Dienstes zu einem anderen Benutzer- oder Gruppenbild führen. ## Namemap zwischen lokalen Dateien und LDAP einrichten Die Datenbank **namemap** steuert die Zuordnung zwischen Windows- und UNIX-Benutzernamen. Sie ist wichtig, wenn SMB-Zugriffe auf Dateien treffen, deren Berechtigungen mit UNIX-Identitäten arbeiten. Für diese Datenbank sind nur *files* und *ldap* zulässig. Verwenden Sie lokale Zuordnungen, wenn wenige feste Regeln benötigt werden: **cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database namemap -sources files** LDAP als zentrale Quelle konfigurieren Sie so: **cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database namemap -sources ldap** Eine Kombination erlaubt lokale Ausnahmen mit LDAP als Reserve: **cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database namemap -sources files,ldap** Wählen Sie dagegen *ldap,files*, wenn die zentrale Zuordnung Vorrang haben soll. Treffen beide Quellen denselben Namen, kann die Reihenfolge bestimmen, welche Identität ONTAP verwendet. Vor der Umstellung müssen die LDAP-Zuordnungen zum verwendeten Namensschema passen. Prüfen Sie insbesondere: - ob Windows- und UNIX-Namen eindeutig zusammengehören, - ob die erwarteten LDAP-Attribute gefüllt sind, - ob Groß- und Kleinschreibung konsistent behandelt wird, - ob Domänen- oder Bereichsangaben im Mapping berücksichtigt werden, - ob keine widersprüchlichen lokalen und zentralen Regeln existieren. Ändern Sie die Quellenfolge nicht mit einer **passwd**- oder **group**-Konfiguration. Für Benutzerzuordnungen ist ausschließlich die Datenbank **namemap** vorgesehen. Nach der Änderung sollten Sie einen SMB-Zugriff mit einem Testkonto ausführen und prüfen, ob die erwartete UNIX-Identität verwendet wird. ## Standardbenutzer und -gruppen bei externer Auflösung berücksichtigen Wenn **passwd** oder **group** ohne *files* arbeitet, müssen zentrale Dienste auch die für ONTAP relevanten Systemidentitäten liefern. Fehlt ein benötigter Eintrag, können SMB-Anmeldung, Besitzauflösung oder Gruppenprüfungen scheitern. Der Dienst ist dann zwar erreichbar, die Antwort bleibt aber unvollständig. Prüfen Sie im externen Verzeichnis mindestens die folgenden Benutzerkonten: - **root** - **nobody** - **pcuser** - **sshd** - **daemon** - **operator** - **bin** - **www** - **admin** - **autosupport** Zusätzlich sollten die benötigten Systemgruppen vorhanden sein. Dazu zählen unter anderem **wheel**, **daemon**, **sys**, **tty**, **operator**, **staff**, **sshd**, **www**, **nogroup** und **nobody**. Achten Sie nicht nur auf den Namen. Auch die numerische Benutzer- oder Gruppen-ID muss konsistent sein. Liefert LDAP für denselben Namen eine andere ID als ein früher verwendetes lokales System, können Besitzangaben und Zugriffsrechte einer anderen Identität zugeordnet werden. Kontrollieren Sie außerdem: - eindeutige Einträge ohne doppelte Namen, - passende Primärgruppen für technische Konten, - erreichbare Suchbasen und korrekte Filter, - die Rückgabe aller benötigten Attribute, - die Auflösung von Benutzer- und Gruppennamen aus der betroffenen SVM. Führen Sie die Umstellung zunächst mit einem Wartungs- oder Testfenster durch. Nach der Änderung testen Sie einen SMB-Zugriff, die Anzeige von Besitzerinformationen und eine Gruppenberechtigung. Bleibt ein Systemkonto im externen Dienst verborgen, hilft auch eine korrekte NS-Switch-Reihenfolge nicht weiter. ## Beispiel: Nur DNS für Hosts verwenden Wenn die SVM Hostnamen ausschließlich über DNS auflösen soll, setzen Sie für die Datenbank **hosts** nur die Quelle *dns*. Dadurch entfallen lokale Fallback-Einträge. Verwenden Sie für den Vserver *vs0* folgenden Befehl: **cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources dns** Der Aufruf ändert ausschließlich den Eintrag für die Hostdatenbank dieser SVM. Benutzer, Gruppen, Netgroups und Namemap-Zuordnungen bleiben unberührt. Vor der Umstellung müssen die DNS-Daten vollständig sein. Prüfen Sie insbesondere die Namen von LDAP-Servern, NIS-Servern, SMB-Partnern und Managementsystemen, die ONTAP über diese SVM erreichen muss. Fehlt ein erforderlicher A- oder AAAA-Eintrag, kann der Zugriff trotz funktionierender IP-Verbindung scheitern. Kontrollieren Sie nach dem Ändern den gespeicherten Eintrag: **cluster1::> vserver services name-service ns-switch show -vserver vs0 -database hosts** In der Ausgabe muss bei **Source Order** ausschließlich *dns* stehen. Testen Sie danach einen Namen aus der produktiven DNS-Zone und einen absichtlich nicht vorhandenen Namen. - Prüfen Sie die DNS-Server und Suchdomänen der SVM. - Stellen Sie die Erreichbarkeit über das Routing der SVM sicher. - Erlauben Sie DNS-Verkehr über UDP sowie bei großen Antworten auch über TCP auf Port 53. - Kontrollieren Sie bei Bedarf die IPv4- und IPv6-Auflösung getrennt. Nutzen Sie diese Einstellung nur, wenn DNS als verbindliche Quelle vorgesehen ist. Bei Wartungsarbeiten am DNS-Dienst gibt es keinen lokalen Ersatz. ## Beispiel: LDAP vor NIS für Passwörter abfragen Mit **ldap,nis** legen Sie LDAP als erste Quelle und NIS als Ausweichquelle für die Passwortdatenbank fest: **cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources ldap,nis** Ein erfolgreicher Treffer aus LDAP beendet die Suche. NIS wird nur berücksichtigt, wenn LDAP keinen passenden Eintrag liefert oder nicht verwendet werden kann. Die Konfiguration setzt voraus, dass beide Dienste denselben Identitätsbestand abbilden. Prüfen Sie deshalb, ob Benutzername, numerische Benutzer-ID, Primärgruppe und relevante Attribute in LDAP und NIS zusammenpassen. Da *files* nicht enthalten ist, müssen die erforderlichen Standardkonten in LDAP oder NIS verfügbar sein. Dazu gehören beispielsweise **root**, **nobody**, **pcuser**, **sshd** und **autosupport**. Prüfen Sie nach der Änderung den gespeicherten Eintrag: **cluster1::> vserver services name-service ns-switch show -vserver vs1 -database passwd** Testen Sie anschließend mindestens einen LDAP-Benutzer und einen Benutzer, der nur in NIS vorhanden ist. Ein identischer Testname in beiden Diensten ist dafür ungeeignet, weil er die Ausweichlogik verdecken kann. - LDAP-Eintrag vorhanden: LDAP liefert das Ergebnis. - LDAP ohne passenden Treffer: ONTAP versucht NIS. - LDAP nicht erreichbar: NIS kann als Reserve dienen. - Kein Treffer in beiden Quellen: Die Benutzerauflösung bleibt erfolglos. Für eine vollständige zentrale Identitätsverwaltung sollten Sie die zugehörige Datenbank **group** mit einer konsistenten Quellenfolge planen. Nur so passen Benutzer- und Gruppenauflösung dauerhaft zusammen. ## Änderung prüfen und typische Fehler vermeiden Nach jeder Änderung prüfen Sie nicht nur die gespeicherte Quellenfolge, sondern auch das Verhalten der betroffenen SVM. Eine korrekte Anzeige beweist lediglich, dass der Eintrag übernommen wurde. Führen Sie zunächst eine gezielte Kontrolle aus: **cluster1::> vserver services name-service ns-switch show -vserver vs1 -database passwd -instance** Vergleichen Sie Vserver, Datenbank und vollständige Reihenfolge mit dem Änderungsauftrag. Prüfen Sie außerdem, ob nicht versehentlich ein anderer Eintrag mit ähnlichem Namen angepasst wurde. Testen Sie danach einen realistischen Anwendungsfall. Bei **passwd** und **group** gehört dazu ein Benutzer mit bekannter Identität und eine Gruppe mit erwarteter Mitgliedschaft. Bei **hosts** testen Sie einen vorhandenen Namen sowie eine bewusst ungültige Anfrage. Für **namemap** eignet sich ein SMB-Zugriff mit einem Konto, dessen Windows- und UNIX-Zuordnung bekannt ist. Typische Fehler lassen sich meist einer dieser Ursachen zuordnen: - **Falscher Vserver:** Die Änderung wurde auf einer anderen SVM vorgenommen als der produktive Zugriff. - **Unpassende Datenbank:** Eine Hostauflösung wird geprüft, obwohl nur **passwd** geändert wurde. - **Veraltete Dienstantwort:** Ein Verzeichnisdienst liefert zwischengespeicherte oder noch nicht replizierte Daten. - **Unterschiedliche IDs:** Derselbe Name besitzt in mehreren Quellen verschiedene numerische IDs. - **Unvollständiger Fallback:** Die Reservequelle enthält den gesuchten Benutzer oder die Gruppe nicht. - **Fehlerhafte Dienstbindung:** LDAP oder NIS ist erreichbar, liefert aber wegen Filter, Suchbasis oder Berechtigung kein passendes Ergebnis. Vermeiden Sie schnelle Gegenänderungen. Sichern Sie zuerst die aktuelle Ausgabe und notieren Sie Zeitpunkt, Vserver, Datenbank sowie die verwendete Quellenfolge. Bei Störungen grenzen Sie die Ursache schrittweise ein: zuerst Konfiguration, dann Netzwerkpfad, danach Dienstantwort und zuletzt die Identitätsdaten. ## Fazit: NS-Switch gezielt ändern und anschließend kontrollieren Eine belastbare NS-Switch-Konfiguration entsteht nicht durch möglichst viele Quellen, sondern durch eine klar begründete Zuordnung pro Datenbank. Setzen Sie mit **vserver services name-service ns-switch modify** nur die tatsächlich benötigte Reihenfolge und halten Sie die Änderung im Betriebshandbuch fest. Für den Abschluss zählen drei Ergebnisse: Der richtige Vserver wurde geändert, die gewählte Quelle liefert die erwarteten Daten, und ein definierter Rückweg ist bekannt. Planen Sie deshalb einen Rückfall auf die zuvor dokumentierte Quellenfolge. Ändern Sie bei einer Störung nur den betroffenen Datenbankeintrag und beobachten Sie anschließend die produktiven SMB- oder Verwaltungsfunktionen. - Änderungsgrund und betroffene SVM dokumentieren. - Vorherige und neue Quellenfolge gegenüberstellen. - Erwartetes Verhalten für Treffer, Nichttreffer und Dienstausfall festlegen. - Nach der Änderung einen fachlich passenden Zugriff prüfen. - Die Konfiguration bei Änderungen an LDAP, NIS oder DNS erneut bewerten. Damit wird der NS Switch zu einer kontrollierbaren Betriebsregel statt zu einer versteckten Fehlerquelle. Kleine, gezielte Änderungen lassen sich prüfen, zurücknehmen und später eindeutig erklären. ## Nützliche Links zum Thema - [ONTAP lokale Tiers Storage-VMs (SVMs) zuweisen - NetApp Docs](https://docs.netapp.com/de-de/ontap/disks-aggregates/assign-aggregates-svms-task.html) - [Erstellen Sie ONTAP SVMs für den NFS-Datenzugriff - NetApp Docs](https://docs.netapp.com/de-de/ontap/nfs-config/create-svms-data-access-task.html) --- *Dieser Artikel wurde ursprünglich veröffentlicht auf [webhosting-verstehen.de](https://webhosting-verstehen.de/vserver-services-ns-switch-konfigurieren/)* *© 2026 Provimedia GmbH*