Informationen zum IP-Adressmanagement

Das LUIS setzt die Standard-Lösung Infoblox DDI als zentrale Infrastruktur für DNS / DHCP / IP-Adressmanagement ein. Es handelt sich hierbei um eine mandantenfähige, integrierte Umgebung, die über ein Web-Frontend erreichbar ist.

Teilweise gibt es in dezentralen Einrichtungen der Universität DNS-Server. Auch wenn wir den Betrieb eigener resolving DNS-Server (DNS-Caches) nicht empfehlen, so sollten diese mindestens nicht selbst rekursiv im Internet die Namen auflösen, sondern unsere DNS-Server als Forwarder benutzen. Falls Ihre Einrichtung einen eigenen DNS-Server betreibt, so sollten Sie kurzfristig die Umstellung auf Forwarding durchführen (und danach in Ruhe überlegen, ob der Betrieb eines eigenen DNS-Servers notwendig ist, was auf der Seite "Dezentrale DNS-Server in Instituten" diskutiert und beschrieben wird).

Auf dieser Webseite wird die Umstellung auf Forwarding-Only für verschiedene DNS-Server beschrieben. Aktuell Februar 2016: Diese Umstellung ist aus Sicherheitsgründen kurzfristig durchzuführen.

ISC-Bind ist ein unter Unix- und Linux-Systemen recht häufig eingesetzter autoritativer und rekursiver DNS-Server. Weder ältere Versionen als 9.9 noch die Vorabversion 10 sind aktuell durch den Hersteller ISC supportet, so dass nur 9.9er- und 9.10er-Versionen im Einsatz sein sollten (Stand 2/2016). Bei auflösenden (resolving) Konfigurationen sind in der Konfigurationsdatei folgende Optionen zu setzen:
  options {
    ...
    forward only;
    forwarders { 130.75.1.32; 130.75.1.40; };
    ...
  }

Bei einem Debian-System ist die passende Konfigurationsdatei /etc/bind/named.conf.options. Nach der Änderung muss diese noch aktiviert werden, z.B. durch rndc reconfig oder mittels service bind9 restart.

Windows-Domain-Controller sind fast immer gleichzeitig auch DNS-Server für die (Windows-)Domäne. Zwar soll der Resolving-DNS-Server möglichst nicht von Clients benutzt werden, normalerweise ist er aber konfiguriert und wird vom Server selbst benutzt (Details vgl. "DNS in Windows-Active-Directory-Domänen"). In jedem Falle ist der Windows-DNS-Server, falls er als Resolver und nicht als rein autoritativer DNS-Server konfiguriert ist, auf das reine Forwarden an die zentralen DNS-Server einzustellen:

• (ggf. über den Server-Manager auf dem Domain-Controller) den DNS-Manager aufrufen,
• den DNS-Server auswählen uns (z.B. über die rechte Maustaste) die Eigenschaften bearbeiten,
• es öffnet sich dann ein Fenster "Eigenschaften von ..." mit Karteireitern, dort die Kartei "Weitereitungen" auswählen,
• die zentralen DNS-Server 130.75.1.32 und 130.75.1.40 hinzufügen,
• die Verwendung der Stammhinweise durch Wegnehmen des Häkchens deaktivieren
• und, wenn die Einstellungen wie im Bild unten sind, die Einstellungen übernehmen & OK.

In den Organisationseinheiten der Universität werden neben den zentralen Nameservern des Rechenzentrums z.T. eigene DNS-Server betrieben. Ob das sinnvoll ist und wie die Server zu betreiben sind, hängt von der Art des DNS-Servers ab:

• DNS in einer Windows-Domäne: Dieses ist ein besonderer Fall eines autoritativen, der DNS-Server wird meist implizit mit der AD-Domäne auf dem Domain-Controller eingerichtet.
• Rekursiver DNS-Server: Für Clients werden beliebige Namen auf IP-Adressen aufgelöst, diese Server werden in den Netzwerkeinstellungen von Clients als DNS-Server eingetragen.
• Autoritativer DNS-Server: Der Server liefert für Clients im Internet die Zuordnung zwischen DNS-Namen und IP-Adressen für eine gewisse Domain (z.B. rrzn.uni-hannover.de) und einen gewissen IP-Bereich (z.B. 130.75.5.0/24) aus.

Je nach Art des DNS-Servers beachten Sie (als Administrator des Servers) bitte die Hinweise in den folgenden Abschnitten.

Sie sollten nicht die offizielle Sub-Domäne Ihrer Einrichtung als AD-Domäne verwenden, sondern stattdessen auf eine passende mit .intern ausweichen:
z.B. nicht rrzn.uni-hannover.de. sondern rrzn.intern.
Für diese auf .intern endenden Domänen tragen wir auf Antrag des Administrators eine Delegierung in unsere DNS-Server dns1. und dns2.uni-hannover.de ein.

Details zu der Benennung von Domänen und Rechnern sowie dem Setup für die Namensauflösung entnehmen Sie bitte der separaten Seite DNS unter Windows.

Den Betrieb eigener DNS-Caches (rekursiver DNS-Server) können wird nicht empfehlen. Die DNS-Server dns1. und dns2.uni-hannover.de sind performant ausgestattet, der Backbone bietet genügend Übertragungskapazitäten (Anfang 2016 werden die Server zudem um ein IP-Failover und auf eine 10GE-Anbindung erweitert).

Darüber hinaus macht ein dezentraler DNS-Cache Probleme für Intrusion-Detection-Maßnahmen an den zentralen DNS-Servern, da ggf. die dezentralen Caches und nicht die dahinter liegenden Clients als infiziert erscheinen (bei Kaskadierung) oder Infektionen nicht mehr festgestellt werden können (bei direkter Auflösung). Es ist aufgrund vieler DoS-Vorfälle geplant, auch rausgehende DNS-Zugriffe deutlich einzuschränken (stattdessen Nutzung der dedizierten "Proxies" dns1 & dns2).

Wenn schon ein eigener DNS-Cache betrieben wird, so sollte er nicht selbst rekursiv "resolven", sondern ausschließlich durch Weiterleitung an die zentralen DNS-Server dns1 & dns2 ("forward only") auflösen. Die nötigen Einstellungen können der separaten Webseite "DNS-Server mit Forward" entnommen werden.

Derzeit gibt es noch einige wenige dezentrale DNS-Server, die autoritativ für Unterzonen der uni-hannover.de zuständig sind. Neue DNS-Server werden nicht mehr zugelassen, das Rechenzentrum nimmt keine neuen Delegierungen mehr vor.

Nachteile dezentraler DNS-Server sind:

• in der Vergangenheit häufiger beteiligt an DoS-Attacken
• Änderungen von für Dienste notwendigen Eintragungen können nicht zentral und dadurch teils nicht schnell vorgenommen werden (MX und Autoconfig-Einträge für Mail, andere SRV-Einträge).
• Im SOA angegebene Hostmaster müssen gut erreichbar sein.

Da es gerade in letzter Zeit vermehrt Sicherheitsprobleme mit den DNS-Servern gab, ist geplant DNS-Zugriffe von Außen an der Gateway-Firewall einzuschränken. In diesem Zuge ist die Umstellung existierender dezentraler DNS-Server auf sogenannte "Hidden-Master" notwendig.

Hidden-Master bedeutet, dass die dezentralen Server nicht mehr nach außen im DNS als autoritative Nameserver sichtbar sind. Die sichtbaren sind dann die zentralen des Rechenzentrums, die aber die DNS-Einträge vom Hidden-Master-Server aus der Einrichtung beziehen.

Um diese Einstellung zu erreicht, sind in der DNS-Zone folgende Einstellungen nötig:

• Im SOA-Eintrag muss ns1.uni-hannover.de als Primärer DNS-Server stehen.
• Die NS-Einträge dürfen nur auf ns1.uni-hannover.de und ns2.uni-hannover.de verweisen.

In der Konfiguration des DNS-Servers (also z.B. named.conf bei Bind) sind folgende Vorkehrungen notwendig:

• Den Nameservern des Rechenzentrums ist der Zonentransfer zu gestattet:
  • den rekursiven: 130.75.1.0/24 (mindestens 130.75.1.28, .29, .32, .40)
  • den autoritativen: 130.75.2.3 und 130.75.6.3
  • dem internen IPAM-System 130.75.4.162
• Der Nameserver im Institut muss den Rechenzentrums-Servern ein "Notify" schicken:
  • sowohl 130.75.2.3 und 130.75.6.3
  • als auch 130.75.1.32 und 130.75.1.40