DNS

Jedes Gerät erhält einen DNS-Namen unter der internen Domain der Organisation, abgeleitet aus seinem Hostnamen. Der Agent betreibt einen lokalen Resolver, der Anfragen nach diesen Namen beantwortet; so funktioniert ssh build-server auf jedem Rechner im Netzwerk, ohne dass jemand eine Hosts-Datei pflegt.

Nicht abgedeckt sind damit die Namen hinter Ihren Netzen - Ihre Active-Directory-Domain, eine interne Zone, das private DNS eines Cloud-Anbieters. Dafür gibt es DNS-Server.

Ein DNS-Server-Eintrag besagt: Frage diese Server nach diesen Domains, auf den Geräten dieser Gruppen. Sie legen ihn unter DNS → DNS servers → Add DNS server an. Diese Schaltfläche öffnet zuerst Choose a DNS server, mit je einer Karte für mehrere bekannte öffentliche Resolver und einer für Custom DNS. Die Karte eines öffentlichen Resolvers trägt dessen Adressen für Sie ein; für die Resolver in Ihrem eigenen Netz wählen Sie Custom DNS.

Das folgende Formular hat drei Schritte; mit Continue gelangen Sie jeweils zum nächsten:

• DNS server: IP und Port von bis zu drei Servern (Add another IP), der Port fast immer 53. Applies to nennt die Gruppen, deren Geräte diesen DNS-Server nutzen; mindestens eine Gruppe ist nötig. Enable DNS server schaltet den Eintrag ab, ohne ihn zu löschen.
• Domains: die Match Domains, für die diese Server antworten, etwa corp.example.com, hinzugefügt mit Add Domain. Ohne Match Domain ist der DNS-Server primär: Er beantwortet jede Anfrage dieser Geräte, auch die nach öffentlichen Namen. Mark match domains as search domains nimmt die Match Domains in die Suchliste des Geräts auf, sodass fileserver den Host fileserver.corp.example.com findet; der Schalter ist nur verfügbar, wenn es Match Domains gibt.
• Name: ein DNS Name mit höchstens 40 Zeichen und eine optionale Beschreibung. Add DNS server speichert den Eintrag.

Um einen Eintrag später zu ändern, öffnen Sie ihn aus der Liste: Dieselben drei Teile erscheinen als die Reiter DNS server, Domains und Name & Description, und Save Changes speichert sie. In der API liegt dasselbe Objekt unter /api/dns/servers; der Schalter für Suchdomänen heißt dort search_domains_enabled.

Resolve wildcard domains (Organisationsmenü → Organization settings) ist standardmäßig an. Damit schickt ein Gerät seine DNS-Anfragen für eine domain-Ressource oder eine Domains-Route an das Routing-Gerät, das sie innerhalb des Netzwerks auflöst, wo die Antwort korrekt ist. Erst dadurch funktioniert ein Platzhalter wie *.internal.example.com. Ist die Einstellung aus, löst jedes Gerät die Namen jede Minute selbst auf; das funktioniert für einfache Namen, aber nie für einen Platzhalter. In der API heißt die Einstellung routing_device_dns_resolution_enabled.

Gerätenamen liegen unter der internen Domain der Organisation. Für eine eigene setzen Sie Internal domain (Organisationsmenü → Organization settings, in der API dns_domain) etwa auf corp.example.com, und aus build-server wird build-server.corp.example.com. Wählen Sie eine Domain, die Sie kontrollieren und nicht im öffentlichen DNS verwenden - ein Name, der innerhalb und außerhalb von SXAccess aufgelöst wird, beschert Ihnen nur unnötige Fehlersuche.

Manche Geräte müssen ihre bisherige DNS-Konfiguration behalten. Dafür gibt es zwei Wege:

• DNS → Settings → Disable DNS management for these groups: Wählen Sie Add group, wählen Sie die Gruppen aus und speichern Sie mit Save Changes. Geräte in diesen Gruppen erhalten überhaupt keine DNS-Konfiguration von SXAccess - keine DNS-Server, nicht einmal Gerätenamen. Sie lösen Namen so auf, wie ihr Betriebssystem es bereits tut.
• --disable-dns lässt die DNS-Einstellungen eines einzelnen Geräts unangetastet. Auf einem verbundenen Gerät setzen Sie die Option mit sxaccess stop && sxaccess start --disable-dns. Führen Sie es als eine Zeile aus: Eine Verbindung über SXAccess, etwa eine SSH-Sitzung zu dieser Maschine, bricht ab, bis start fertig ist. In einer Sitzung über sxaccess shell klappt das nicht: Beim Stoppen schließt der Agent diese Sitzung und beendet den Befehl. Nutzen Sie dafür die Konsole oder eine OpenSSH-Sitzung.

Der Agent stellt die DNS-Konfiguration des Rechners auf einen eigenen Resolver um. Dieser beantwortet Anfragen nach Gerätenamen, schickt Anfragen für die Domains Ihrer DNS-Server an diese Server und reicht alles andere an die Resolver weiter, die der Rechner bereits hatte. Unter Linux arbeitet der Agent mit dem, was der Host nutzt - systemd-resolved, NetworkManager, resolvconf oder eine einfache /etc/resolv.conf; unter macOS mit den DNS-Einstellungen des Systems.

Der Resolver braucht eine Adresse, auf der er lauscht. Der Agent nimmt die erste dieser Möglichkeiten, die frei ist:

1. Port 53 auf der Overlay-Adresse des Geräts (nicht unter macOS), auf 127.0.0.1 oder auf 127.0.0.153, in dieser Reihenfolge.
2. Unter Linux, wenn Port 53 überall belegt ist, ein anderer Port auf der Overlay-Adresse. Ein kleines Kernel-Programm leitet die Anfragen an Port 53 dorthin um, sodass es für den Host weiterhin wie Port 53 aussieht.
3. Port 5053 auf einer dieser Adressen.

Nur der letzte Fall kann Probleme machen. systemd-resolved und macOS können Anfragen an einen anderen Port als 53 schicken. NetworkManager, resolvconf und eine einfache /etc/resolv.conf können das nicht: Sie geben nur eine Adresse an und fragen daher immer an Port 53. Auf einem Host, der eines davon nutzt, protokolliert der Agent eine Warnung mit einem Link auf diesen Abschnitt, und das Gerät dient nicht mehr als primärer Resolver: Primäre DNS-Server gelten auf ihm nicht mehr. Machen Sie Port 53 frei - meist, indem Sie einen anderen lokalen DNS-Dienst stoppen oder umkonfigurieren - und verbinden Sie das Gerät mit sxaccess stop && sxaccess start neu. Führen Sie es als eine Zeile aus: Eine Verbindung über SXAccess, etwa eine SSH-Sitzung zu dieser Maschine, bricht ab, bis start fertig ist. In einer Sitzung über sxaccess shell klappt das nicht: Beim Stoppen schließt der Agent diese Sitzung und beendet den Befehl. Nutzen Sie dafür die Konsole oder eine OpenSSH-Sitzung.

Die Option --dns-resolver-address von sxaccess start legt Adresse und Port stattdessen fest. Sie ist für den Support gedacht: Nutzen Sie sie, wenn der Support Sie darum bittet, und wählen Sie Port 53, damit die oben beschriebene Warnung nicht auftreten kann. Solange das Gerät verbunden ist, übernimmt sxaccess start keine Einstellungen; beide Blöcke unten führen deshalb zuerst sxaccess stop aus, in derselben Zeile wie start. Führen Sie es als eine Zeile aus: Eine Verbindung über SXAccess, etwa eine SSH-Sitzung zu dieser Maschine, bricht ab, bis start fertig ist. In einer Sitzung über sxaccess shell klappt das nicht: Beim Stoppen schließt der Agent diese Sitzung und beendet den Befehl. Nutzen Sie dafür die Konsole oder eine OpenSSH-Sitzung.

1. Gehört das Gerät zu einer Gruppe unter Applies to? Ein DNS-Server erreicht nur die dort aufgeführten Gruppen, und nur, solange Enable DNS server an ist.
2. Ist die DNS-Verwaltung für das Gerät aus? Eine Gruppe unter Disable DNS management for these groups oder --disable-dns auf dem Gerät schaltet all das ab.
3. Sind die DNS-Server erreichbar? sxaccess info -d zeigt für jeden, ob er erreichbar ist. Das Gerät braucht eine Route zu ihnen und eine Zugriffsregel, die UDP 53 erlaubt.
4. Hat der Agent Port 53 bekommen? Wenn er die unter Der lokale Resolver beschriebene Warnung protokolliert hat, nicht.
5. Verwaltet etwas anderes den Resolver? Unter Linux zeigt resolvectl status, welcher Server für welche Domain zuständig ist. Ein VPN-Client oder eine Container-Laufzeit kann resolv.conf überschrieben haben.
6. Ist der Name vollständig? Ein kurzer Name wird vor dem Senden mit den Suchdomänen des Geräts ergänzt; fileserver wird also nur dann zu fileserver.corp.example.com, wenn diese Zone zu den Suchdomänen gehört. Lösen Sie den vollständigen Namen auf, um das auszuschließen.