Standortvernetzung: Mit oder ohne DNS?


greystone

Active Member
Hallo zusammen,

ich hätte gerne mal zu meiner Sicht auf die Dinge Eure Meinung / Anmerkungen:

Ich habe hier eine Umgebung die durch folgende Merkmale gekennzeichnet ist:
  • ca. 20 Standorte
  • wenige Geräte pro Standort (Drucker, WLAN-APs, Router, 1-2 Switche)
  • Ausfallsichere Internetverbindung jeweils mit Breitband und LTE-Backup
  • Netzwerkhardware hauptsächlich auf Ubiquity/Unify-Basis (Ich kenne das Zeugs selbst nur vom Namen)
  • allgemeines IT-Know How vorhanden aber z. B. kein Linux-KnowHow
Ich möchte jetzt dafür ein Monitoring basteln. Dafür ist meine Vorstellung grundsätzlich DNS zu haben. Damit man da vernünftig DNS einsetzen kann habe ich mir gedacht:
  • An jedem Standort einen Docker-Container mit einem DNS-Secondary-Server. Das kann man auf vorhandener Hardware mitlaufen lassen. Der Primary Server läuft dann halt sonst wo.
  • DNS muss verfügbar bleiben, auch wenn die Internetverbindung ausfällt. Das dürfte mit obigem Punkt gewährleistet sein.
  • Als Hauptdomain für die internen Namen wird firma.zz verwendet. Also nicht die offizielle Domain firma.de, weil ich die Informationen, die das DNS über die interne Struktur preisgibt, nicht im Internet haben will.
  • Der entsprechende DNS-Domainname / die DNS-Suchliste wird vom DHCP-Server mitgeliefert (standortname.firma.zz)
  • Die Geräte an den Standorten heissen dann z. B. drucker1.standortname.firma.zz
  • Die Secondary-DNS-Server werden entweder als Resolver mit Forwarder benutzt oder als delegierte Zone (firma.zz) von den vor Ort befindlichen Resolvern angesprochen.
Die Vorteile von DNS sind für mich:
  • Kunden die z. B. einen Drucker einrichten, müssen sich nur den Druckernamen merken und keine IP-Adresse. Das machen die Kunden idR genau einmal und dann nie wieder.
  • Im Monitoring muss nicht mit IP-Adressen gearbeitet werden.
  • Bei der Fehlersuche muss auch nicht mit IP-Adressen gearbeitet werden, es sei denn der DNS ist ausgefallen.
Die Nachteile von DNS sind für mich bei diesem Setup:
  • Die DNS-Server sind ein zusätzlicher SPOF (single point of failure) an den Standorten. Wenn der DNS weg ist, gibt's kein Internet mehr für die Nutzer(wenn der Secondary-DNS gleichzeitig DNS-Resolver ist) oder aber die Möglichkeit zu Drucken fällt aus (Wenn die interne Firmenzone nur per DNS-Delegation angebunden ist).
  • Wenn das technische Know-How fehlt, ist zusätzliche Komplexität eher kontraproduktiv und im Fehlerfall sind einfache Störungen durch das eigene Personal möglicherweise nicht oder nicht zeitnah lösbar.
Insgesamt ist für mich der Nutzen von DNS hier scheinbar nicht besonders hoch. Aber so intuitiv (Administrator-Faulheit) würde ich selber immer DNS haben wollen.

Habt Ihr weitere Gedanken dazu? Würdet Ihr in einem solchen Szenario DNS einsetzen? Welche weiteren Gründe sprechen dafür oder dagegen?

Grüße,
greystone
 
Last edited:
Ich versuche grundsätzlich, einen funktionierenden DNS für die lokalen Adressen zu haben.
Selbst wenn es anfangs nur "zwei oder drei" IPs sind werden es erfahrungsgemäß schnell mehr und die Übersichtlichkeit leidet.

Viele Router bieten die Möglichkeit, einzelne Zonen auf bestimmte Server umzuleiten.
Mit Unify habe ich selbst auch keine weitere Erfahrung (ist wohl eher in Amerika verbreitet) aber da kann man wohl mit
set service dns forwarding options server=/firma.zz/192.168.1.2
den internen DNSMASQ dazu überreden alles unterhalb einer bestimmten Domain über einen bestimmten Server aufzulösen.

Wenn Du sowieso eine VPN-Verbindung hast ("Standortvernetzung" klingt so) kann die Auflösung durch das VPN bei einem Server in der Zentrale passieren, falls nicht nimmt man eine öffentliche IP der Firma und sorgt per DNS-Views oder TSIG dafür, daß die Abfragen nur von den Routern der betreffenden Standorte aus möglich sind.

Die normale Internetanbindung ist davon nicht betroffen, weil ja alles außer "firma.zz" weiterhin über die vom Internetprovider zugewiesenen Forwarder (oder irgendwas statisches wie z.B. 8.8.8.8) aufgelöst werden und der DNSMASQ ja auch cached.

PS: Bitte dann auch gleich 168.192.in-addr.arpa. mit auflösen und pflegen, weil es (z.B. in Traceroutes) sehr nützlich ist, auch die IPs zu Namen aufgelöst zu bekommen.

Bei Bedarf kann man auch nur "standortname.firma.zz" delegieren - oder auch "standortname.zz.firma.de".
 
Eine Idee, wie ich den DNS-SPOF auch ohne Domain-Delegation eliminiere wäre:

Ich nehme als ersten DNS-Server nehme den dedizierten Secondary-DNS (auf einem Monitoring-Host). Als zweiten den normalen Standortrouter (Resolver). Auf die Art und Weise ist bei einem Ausfall des Secondary-DNS das normale öffentliche DNS noch verfügbar und nur die speziellen internen Domains weg.

Muss ich nur darauf achten, dass ich nichts kritisches über die internen Zonen betreibe. Das Monitoring (Check-MK) cached ja die IP-Adressen der Geräte.

Ich verlinke hier gerade nochmal eine andere Forenseite, wo ich etwas zum Thema DNS-Delegation gefunden habe:
https://community.ui.com/questions/UDM-Pro-DNS-forwarding/54e3451c-1781-4d7f-8d58-9212cbea43ff
 
Last edited:
Wie schon geschrieben, mein Ansatz an der Stelle wäre dann andersherum, die internen Namen liegen unter "standortname.zz.firma.de", wobei "zz.firma.de" redundant von einer Anzahl im Rechenzentrum gehosteter Server bedient wird.

Damit muß man am Standort eigentlich gar nichts am DNS ändern und hat auch alle "komischen" Konfigurationen (der eine hat fest 8.8.8.8 auf dem Rechner eingetragen, der zweite schließt sein Handy zum Laden an und nutzt unwissentlich den Hotspot samt dessen DNS und beim dritten ist eine der inzwischen auch in Browsern um sich greifenden Lösungen mit DNS über HTTPS aktiv) erschlagen und man ist auch gegen komische Spielchen der Provider (z.B. Zwangsfilterung von DNS-Requests um Websperren oder auch nur eine "Navigationshilfe" durchzusetzen) gefeit.

Verschiedene DNS-Server (ja, das "S" ist doppelt und muß einmal abgezogen werden:cool:) mit unterschiedlichen Horizonten sind immer schlecht, da manche Betriebssysteme eben keine deterministische Reihenfolge haben und das dann zu Situationen wie "Drucken geht nur manchmal", weil eben nur jeder 2. DNS-Request den Drucker auflöst führen kann.
 
Mir ist es noch wichtig, dass DNS auch bei Ausfall der Internetverbindung zur Verfügung steht und ich weiss nicht, wie sich der Resolver der UDM da verhält.

Außerdem ist es ja eher unwahrscheinlich, dass der Resolver alle internen Records auch nur der eigenen subdomain im Cache hat.
 
Last edited:
Wenn wirklich alles Unifi ist, könntest Du mit allen Standorten an einem Controller eine zentrale Verwaltungsinstanz für alle Standorte haben. Das ist ja das Schöne an controllerbasierten Netzwerklösungen wie Unifi. Normalerweise hat man das nur bei deutlich teureren Enterpriselösungen.

Was willst Du monitoren und wieso meinst Du hierfür eine separate DNS Lösung benötigen zu müssen?
 
Ich finde das sinnvoll, grundsätzlich DNS statt IP-Adressen verwenden zu können, z. B. auch für die Konfiguration des Monitorings. Ansonsten finde ich das sinnvoll auch um automatisiert DNS als Datenbank aller vorhandenen Geräte nutzen (d. h. standardisiert abfragen) zu können.

Was zu überwachen ist:
  • Switche / Accesspoints
  • Internetverbindung
  • Drucker
  • Wahrscheinlich im Laufe der Zeit noch weitere Netzwerkgeräte
Was Unify sonst weiter so leistet, weiss ich nicht. Auch nicht was es da für ein zentrales Verwaltungstool gibt.
 
Switche, APs und die Internetverbindungen hast Du im Unifi Controller für alle Standorte, dort kannst Du in einer Oberfläche (Controller), an dem alle Standorte hängen, alle Switche und Switchports, APs und SSIDs, VLANs u.v.m. konfigurieren und monitoren. Deswegen wurde das vermutlich auch so angeschafft.

Alles über DNS kann man machen, allerdings kannst Du dann z.B. aber keine privaten LAN IP Ranges oder Namen wiederverwenden.

Steht denn die VPN Vernetzung zwischen den Standorten überhaupt schon?

Bevor Du irgend etwas machst, solltest Du Dir die Unifi Controller Oberfläche, die hoffentlich über alle Standorte gezogen wurde, ansehen.
 
Bevor Du irgend etwas machst, solltest Du Dir die Unifi Controller Oberfläche, die hoffentlich über alle Standorte gezogen wurde, ansehen.

Die Konfiguration ist jeweils nur pro Standort durchgeführt. Eine Verbindung der Geräte/Konfigurationen über Standorte hinweg gibt es derzeit nicht.

Switche, APs und die Internetverbindungen hast Du im Unifi Controller für alle Standorte, dort kannst Du in einer Oberfläche (Controller), an dem alle Standorte hängen, alle Switche und Switchports, APs und SSIDs, VLANs u.v.m. konfigurieren und monitoren. Deswegen wurde das vermutlich auch so angeschafft.

Was ich bisher so gehört habe, gibt's da jeweils 'ne hübsche Oberfläche, aber bzgl. der einzelnen Sachen die da überwacht bzw. eingestellt werden können ist das recht mager. (Ethernetfehler? Bandbreitenauslastung? Änderungen an der Port-Konfiguration(Speed, Up/Down)? Präzise Einstellung der Alarmierung?) So, wie ich das im Moment sehe, ist der Unify-Kram für die Konfiguration der eigenen Gerätewelt genial. Für Monitoring sehe ich das aber eher nicht, lasse mich aber gerne eines besseren belehren.

Alles über DNS kann man machen, allerdings kannst Du dann z.B. aber keine privaten LAN IP Ranges oder Namen wiederverwenden.

Ich verstehe nicht, das Du damit sagen möchtest. Meinst Du, wenn ich einen Switch z. B. sw01 (.standort-a.firma.zz) nenne, dann kann ich einen anderen Switch nicht nochmal sw01 (.standort-b.firma.zz) nennen?

Die Standort-IPv4-Struktur ist für alle Standorte identisch im Bereich 10.0.0.0/8. Jeder Standort hat davon ein /16-Subnetz zugewiesen bekommen.

Steht denn die VPN Vernetzung zwischen den Standorten überhaupt schon?

Nein. Das soll im Rahmen der aktuellen Arbeiten aufgesetzt werden.

Grundsätzlich bin ich ja mit dieser Frage: DNS Ja/Nein noch unentschieden. Lohnt das wirklich?
 
Last edited:
Je Standort einen DNS-Server mit mariaDB als Galera-Cluster im Master-Master-Betriebt. Ggf. noch einen Garbd um Splitheads zu vermeiden.
 
Je Standort einen DNS-Server mit mariaDB als Galera-Cluster im Master-Master-Betriebt. Ggf. noch einen Garbd um Splitheads zu vermeiden.
So komplex...?

Wenn ich den TE richtig verstehe, will er doch die Verwaltung der internen Adressen möglichst zentral und für den Fall, daß an einem der Standorte kein Internet verfügbar ist, eine lokale Auflösung.
Also warum dann nicht zwei (besser drei) redundante DNS-Server, auf denen die Zonenverwaltung läuft. An jedem Standort einen Resolver, der sich gezielt beim eigenen DNS-Netzwerk bedient. Kurze TTL und auch lokale Abfragen sind immer aktuell.

BTW:
Da weiter oben auch das Wort Monitoring gefallen ist...Wenn man sich denn sein eigenes DNS-Netzwerk aufsetzt (mindestens 3 Server in unterschiedlichen RZ), dann kann man über diese Maschinen auch gleich noch andere Sachen mit Redundanzanforderungen wie eben Monitoring, VPN, whatever drüber laufen lassen...
 
Ich habe mir die Unify jetzt genauer angeschaut. So einiges ist da schon nett. Die Übersicht der Netzwerkgeräte. Automatisch erstellte Netzwerkkarte (Switche, Geräte, Accesspoints). Die zentralisierte Konfiguration. Für das Monitoring muss da das eine oder andere an Information noch manuell und redundant nachgepflegt werden. (Z. B. Switchport-Bezeichnungen, obwohl Unify schon erkennt, welche Geräte hinter welchem Port sind. Aber damit habe ich das noch nicht im Monitoring. Da muss ich die Portbezeichnungen in der Unify-Umgebung manuell gemäß meines Schemas setzen, dass ich da entsprechende Monitoring-Regeln darauf aufsetzen kann). Bei der Alltagsadministration wird das Unify-Interface mit Sicherheit weiterhin nützlich sein. Aber so insgesamt keine Überraschungen. So in etwa das, was ich zu sehen bekommen habe, habe ich auch erwartet.

Schön auch dass das SNMPv3, das einerseits in Unify andererseits in Check-MK jeweils global definiert wurde auf Anhieb bei allen Geräten, die das unterstützen funktioniert und entsprechende Services gefunden werden.

Ich verwende jetzt PowerDNS als authoritativen Server der internen Zone, evtl. in Kombination mit dnsmasq. Aktuell ist der PowerDNS erstmal nur als einziger primärer Server per VPN erreichbar. Da kommen dann wie bisher angedacht noch die sekundären Server auf dem Monitoring-Host lokal am Standort dazu. Da ausschließlich das ebenso im Test befindliche Monitoring auf das DNS angewiesen ist, stört die fehlende Ausfallsicherheit da im Moment noch nicht.

Bzgl. der Ideen von Dir Whistler war ich bisher zu faul zum recherchieren, wie das im Einzelnen genau geht. Aber das hole ich evtl. noch nach. Es wäre schon schön, wenn man das ohne private Zonen machen könnte. Im Moment - vermutlich aufgrund mangelnden Wissens - befürchte ich noch, dass das zu kompliziert ist und vielleicht nicht umsetzbar.

Grundsätzlich ist das Monitoring mit DNS schon viel angenehmer zu konfigurieren.
 
Last edited:
Back
Top