Betrieb des Nameserver-Dienstes im MWN

Allgemeines

Allgemeine Informationen (was ist DNS, was ist eine Zone, wozu dienen welche DNS-Records...) gibt es bei Wikipedia:

• http://de.wikipedia.org/wiki/Domain_Name_System
  http://en.wikipedia.org/wiki/Domain_Name_System
• http://de.wikipedia.org/wiki/Resource_Record
  http://en.wikipedia.org/wiki/List_of_DNS_record_types

Domains mit Umlauten (dort ist auch ein Punycode-Konverter verlinkt):

• http://de.wikipedia.org/wiki/Punycode
  http://en.wikipedia.org/wiki/Punycode

Zusätzlich werden hier noch einige Erläuterungen im Hinblick auf den Betrieb von Nameservern gegeben. Es gibt zwei grundlegende Charakteristika für Nameserver:

1. autoritativ (bezogen auf eine Zone)
2. rekursiv auflösend (Nameserver dient als Resolver).

Ein autoritativer Nameserver ist für eine (oder mehrere) Zone(n) verantwortlich. Nur die Zoneneinträge eines autoritativen Nameservers sind bindend, alle nicht autoritativen Nameserver beziehen die Einträge für diese Zone von autoritativen Servern. Daraus folgt, dass ein autoritativer Nameserver alle Anfragen zu dieser Zone beantworten muss. Jede Zone benötigt mindestens einen autoritativen Nameserver. Fallen alle autoritativen Nameserver einer Zone aus, können Einträge aus bzw. unterhalb dieser Zone weltweit nicht mehr korrekt beantwortet werden (abgesehen von noch vorhandenen Einträgen im lokalen Resolver-Cache).

Dient ein Nameserver als Resolver, so fragt er (im Auftrag eines Clients, im Allgemeinen iterativ) alle für eine Namensauflösung benötigten autoritativen Nameserver, bis er den gesuchten Eintrag gefunden hat. Das impliziert, dass der Nameserver Anfragen an beliebige fremde Nameserver senden und deren Antworten bearbeiten muss, auch wenn diese sehr groß sind (siehe DNS-Amplification-Attack). Nahezu jeder Internetteilnehmer benötigt einen Resolver. Der Ausfall eines reinen Resolvers betrifft nur die Clients, für die er zuständig ist. Clients können bei Ausfällen auch andere zugängliche Resolver verwenden, vorausgesetzt, dass solche bekannt sind.

Löst ein Resolver Anfragen von beliebigen Clients rekursiv auf, spricht man von einem „offenen Resolver“. Offene Resolver sollten unbedingt vermieden werden, da sie für DNS-Amplification-Attacks verwendet werden können.

Tools:

dig, host und nslookup (alle enthalten in http://www.isc.org/software/bind , unter Linux je nach Distribution etwa im Paket bind-utils oder dnsutils, aber auch für andere Betriebssysteme verfügbar; nslookup ist auf vielen Systemen vorinstalliert).

Beispiel 1 fragt nach autoritativen Nameservern für „de.“ und dann nach autoritativen Nameservern für „lrz.de.“ bei einem der autoritativen Nameserver für de, jeweils ohne Rekursion:

dig de. ns +norecurse
dig lrz.de. ns @f.nic.de +norecurse

Beispiel 2 macht ein (Reverse-)Lookup für www.badw.de bzw. den zugehörigen Webserver:

nslookup www.badw.de
nslooukp 129.187.254.93

Die DNS-Server des LRZ

Das LRZ betreibt die 3 autoritativen Nameserverdienste dns1.lrz.de, dns2.lrz.bayern (früher dns2.lrz.de) und dns3.lrz.eu (früher dns3.lrz.de) sowie die zwei Resolverdienste resolver1.lrz.de und resolver2.lrz.de.

dns1, dns2, resolver1 und resolver2 sind auf 4 Standorte im MWN verteilt (LRZ in Garching, TU-Stammgelände, LMU-Stammgelände und Campus Weihenstephan, siehe Abbildung 1), und jeweils doppelt vorhanden. Diese Nameserver sind über IP-Anycast-Adressen erreichbar, DNS-Anfragen werden vom Router jeweils an den nächstliegenden Server gesendet. Fällt ein Server aus, so werden die DNS-Anfragen automatisch zu einem der anderen Server gesendet, die Route zu dem ausgefallenen Server verfällt. Damit ist der DNS-Dienst innerhalb des MWN doppelt redundant: Fällt beispielsweise einer der Server, die resolver1 bereitstellen, aus, so übernimmt automatisch der andere, fällt resolver1 komplett (d.h. beide Server) aus, so kann der Client resolver2 verwenden.

Abbildung 1: Anycast-DNS im MWN

Damit die autoritative Namensauflösung für die vom LRZ administrierten Domains auch verfügbar ist, wenn das MWN vom Internet abgeschnitten ist, liegt dns3 im Netz eines externen Kooperationspartners (zurzeit in Tschechien und Portugal).

Domains im MWN

Einige Domains aus dem MWN sind in der folgenden Tabelle aufgeführt.

Für oben nicht genannte Organisationen stehen nachfolgende Domainnamensräume zur Verfügung:

Unterhalb der oben genannten Domainnamen sind weitere Sub-Domainnamen eingerichtet bzw. können eingerichtet werden.

Beispiele für Subdomainnamen sind:

Das LRZ betreibt für das MWN drei /16 (Class-B) Netze mit folgenden Adressbereichen:

129.187 /16 - hauptsächlich für die TUM
141.84 /16 - hauptsächlich für die LMU
141.40 /16 - für den Campusbereich Weihenstephan

Somit betreibt das LRZ das Reverse-Mapping für folgende Zonen:
187.129.in-addr.arpa
84.141.in-addr.arpa
40.141.in-addr.arpa

Darunter können die Reverse-Mapping-Einträge auf Subnetzebene in eigenen Zonen verwaltet werden (siehe auch WebDNS).

Die Verwendung eigener Domainnamen ist auf einer eigenen Seite beschrieben.

Webdns - Einträge in LRZ-Nameserver über Webinterface

Der NameSurfer bietet DNS-Administratoren die Möglichkeit, ihre Domains über ein interaktives Webfrontend zu verwalten. Die Zielgruppe sind Administratoren, die ohne viel Aufwand selbst Änderungen an ihren Zonen vornehmen wollen, ohne für jeden Eintrag eine Anforderung über das Servicedesk-Portal einzugeben und die Erledigung durch das LRZ abwarten zu müssen. Die Einträge werden sofort im DNS wirksam (auf den Resolvern spätestens nach Ablauf der TTL). In der Voreinstellung werden mit Hosteinträgen automatisch Reverse-Mapping-Einträge vorgenommen.

Sie erreichen den NameSurfer unter der URL https://webdns.lrz.de. Die Online Hilfe bietet zu vielen Punkten gute Erklärungen zu deren Bedeutung und Konfigurationsmöglichkeiten. Es werden Benutzerkennungen eingetragen für Administratoren, welche:

• eigene Zonen administrieren, welche bereits auf den DNS-Servern vom LRZ verwaltet werden.
• bisher eigene DNS Server betreiben, diesen Dienst aber lieber vom LRZ betreiben lassen möchten.

Bitte beachten:

• Beim Zugriff auf das Webinterface erfolgt eine Umleitung auf 8443 (https). Sollte diese Seite nicht erreichbar sein, könnte es daran liegen, dass Ihre Firewall diesen Port blockiert.
• Das Passwort für Webdns ist das gleiche wie für die anderen LRZ-Dienste.
• Neue Zonen können nicht über das Webfrontend eingetragen werden, auch wenn ein Menupunkt Create zone existiert. Beachten Sie bitte dazu den Absatz Neue Zone anlegen.

Webdns-Berechtigung für eine Kennung anfordern:

Webdns-Berechtigung wird für TUM-Mitarbeiter über den IT-Support der TUM beantragt, alle anderen wenden sich mit folgenden Angaben an das Servicedesk-Portal:

• Name
• Institut
• E-Mail Adresse
• Telefonnummer
• Verwaltete Zone(n)
• LRZ-Kennung

Sollte diese Zone(n) auf den DNS Servern des LRZ noch nicht existieren, muss die Anlegung über das Servicedesk-Portal angefordert werden (s.u.).

Passwort ändern:

Das Webdns-Passwort ist das gleiche wie für die anderen LRZ-Dienste. Ändern kann man es über das ID-Portal (https://idportal.lrz.de/r/entry.pl).

Neuen Host anlegen:

• Sollten Sie nicht die Übersicht über Ihre Zonen sehen, klicken Sie links im Menü auf DNS.
• Klicken Sie auf die Zone, in der Sie den neuen Eintrag machen wollen. Sie sollten nun eine Übersicht der Einträge in der Zone sehen. Der 1. Eintrag ist normalerweise ein Eintrag mit dem Zonennamen und enthält den SOA-Record.
• Klicken Sie links im Menü auf Add Host.
• Geben Sie den neuen Namen und die IP-Adresse des neuen Hosts ein, setzen oder entfernen Sie gegebenenfalls das Häkchen Create reverse records automatically und klicken Sie auf OK. Ist alles in Ordnung, sehen Sie anschließend wieder die Übersicht der Einträge in der Zone inklusive des neuen Eintrages.

Existierenden Host ändern:

• Sollten Sie nicht die Übersicht über Ihre Zonen sehen, klicken Sie links im Menü auf DNS.
• Klicken Sie auf die Zone, in der Sie den neuen Eintrag machen wollen. Sie sollten nun eine Übersicht der Einträge in der Zone sehen. Der 1. Eintrag ist normalerweise ein Eintrag mit dem Zonennamen und enthält den SOA-Record.
• Klicken Sie auf den Hostnamen, den Sie ändern wollen.
• Machen Sie ihre Änderungen und klicken Sie anschließend auf OK.

Alias (CNAME) anlegen:

• Sollten Sie nicht die Übersicht über Ihre Zonen sehen, klicken Sie links im Menü auf DNS.
• Klicken Sie auf die Zone, in der Sie den neuen Eintrag machen wollen. Sie sollten nun eine Übersicht der Einträge in der Zone sehen. Der 1. Eintrag ist normalerweise ein Eintrag mit dem Zonennamen und enthält den SOA-Record.
• Klicken Sie links im Menü auf Add Alias.
• Geben Sie oben einen neuen Namen ein.
• Geben Sie unten den Namen des bereits existierenden Hosts an für den der Alias Eintrag erzeugt werden soll.
• Klicken Sie auf OK um Ihre Änderungen zu übernehmen.

Neue Zone anlegen lassen:

Achtung: Einträge über das Menü Create zone werden nicht in die aktuelle DNS-Konfiguration übernommen. Wenn Sie eine neue Zone benötigen, fordern Sie diese bitte über das Servicedesk-Portal an. Bitte fügen Sie folgende Informationen bei:

• Zonenname
• Bei LMU/TUM: Genehmigung (siehe Verwendung eigener Domainnamen)
• Institutsname
• Verantwortlicher Ansprechpartner für diese Zone mit E-Mail-Adresse, Adresse und Telefonnummer
• Bei bereits existierenden Zonen, die auf dns1, dns2, dns3 umziehen sollen: IP Adressen der DNS-Server von denen die Zone kopiert werden soll. WICHTIG: Zonentransfer muss für webdns.lrz.de freigeschaltet sein.
• Evtl. weitere erforderliche Optionen für die Zone

Sobald die Zone eingetragen ist, können Sie im Webfrontend Ihre Einträge in dieser Zone machen.

Verwaltung der Reverse-Mapping-Zonen

Wie oben schon erwähnt, ist das LRZ Anlaufstelle für das Reverse-Mapping für die Zonen bzw. Netze:
187.129.in-addr.arpa bzw. 129.187 /16
84.141.in-addr.arpa bzw. 141.84 /16
40.141.in-addr.arpa bzw. 141.40 /16

Zonen für Subnetze können auf Anforderung angelegt und über WebDNS verwaltet oder an eigene Nameserver delegiert werden. Voraussetzung dafür ist die Zustimmung des betroffenen Netzverantwortlichen.

Instituts-Nameserver / eigene Nameserver

Der Betrieb eines eigenen Nameserver ist aufwändig und mit Risiken für die DNS-Nutzer, aber auch für andere, verbunden (siehe Zusatzinformationen). Das LRZ ist bemüht, den DNS-Dienst zuverlässig und den Wünschen der Nutzer entsprechend zu betreiben. Möglicherweise können aber nicht alle gewünschten Features angeboten werden. Falls der Bedarf für eigene Nameserver besteht, finden Sie hier Hinweise und Empfehlungen zum Betrieb:

Empfehlungen zum Betrieb eigener Nameserver

Resolver:

• Anfragen nur aus dem eigenen Netz beantworten (dazu für ISC-bind in der named.conf im Abschnitt options{...} die Zeilen „recursion yes;“ und „allow-query {Netz1; Netz2;};“ einfügen)!
• Das eigene Netz gegen IP-Spoofing absichern (ist im MWN normalerweise gegeben)
• Zwei unabhängige Resolver betreiben (und beide in der Konfiguration verwenden, etwa bei DHCP)

Autoritative Nameserver:

• Rekursion unbedingt ausschalten (dazu für ISC-bind in der named.conf im Abschnitt options{..} die Zeilen „recursion no;“ und, falls die Bind-Version Response-Rate-Limiting unterstützt,

      „rate-limit {
      responses-per-second 15;
      window 5;
      };“
  

  einfügen, ggf. mit angepassten Werten)
• Ausfallsicherheit: Beim Einrichten einer neuen Zone die autoritativen LRZ-Nameserver als Secondary angeben (siehe Konfigurationsinformationen).
• Zonentransfer-ACLs pflegen
• Zonendaten aktuell halten (nicht nur Records, sondern insbesondere auch Ansprechpartner, Domain-Inhaber-Daten, admin-c etc.)
• Korrektheit der Konfiguration überwachen (fehlerhafte Konfiguration kann u.a. zu starker Lasterhöhung von Resolvern führen, d.h. die Folgen sind nicht auf den eigenen Server beschränkt)

Allgemeines:

• Administrativen Zugang sichern (starkes Passwort, sicherer Zugang, „das Übliche“...)
• DNS-Server-Software und Betriebssystem aktuell halten
• Monitoring für DNS-Server einrichten (auch „echte“ DNS-Anfragen, nicht nur Last / Ping)
• Physischen Zugang sichern
• Administrativen Zugang sichern (weitere Maßnahmen wie eigenes Management-Netz...)

Konfigurationsinformationen

Nameserverkonfiguration für Endnutzer

Die folgenden IPv4- und IPv6-Adressen werden im MWN als Resolver verwendet:

resolver1.lrz.de: 10.156.33.53
resolver2.lrz.de: 129.187.5.1

resolver1.lrz.de IPv6: 2001:4ca0::53:1
resolver2.lrz.de IPv6: 2001:4ca0::53:2

Die LRZ-Server als DNS-Slaves

Die DNS-Server des LRZ können als Slaves eines Instituts-Nameservers dienen und neben diesem als autoritativer Nameserver eingetragen werden. Dafür sind folgende Schritte notwendig:

• Das LRZ benachrichtigen: Servicedesk-Portal
• Zonentransfer auf dem Master für "transfer-to-lrz.dns.lrz.de" freischalten (Adressen siehe: "host transfer-to-lrz.dns.lrz.de")
• Gegebenenfalls die NS-Einträge in der darüber liegenden Zone anpassen (NS-Einträge für dns1.lrz.de, dns2.lrz.bayern und dns3.lrz.eu anlegen)

Eigenen Nameserver als Slave für eine Zone betreiben:

Legen Sie die Zone auf Ihrem Nameserver als Slave an und geben als Master die unter dem DNS-Eintrag "transfer-from-lrz.dns.lrz.de" aufgeführten Nameserver an.

In Ihrer Zone konfigurieren Sie einen TXT-Record mit der Adresse Ihres Nameservers:

_allow-axfr._lrzdns IN TXT "ip-adresse"

Im Moment werden als Parameter nur IPv4-Adressen akzeptiert, IPv6-Adressen, Netze in CIDR-Notation und Hostnamen kommen eventuell später.

Beispiel für die Zone "int.mb.bv.tum.de"

   _allow-axfr._lrzdns.int.mb.bv.tum.de. 86400 IN TXT "129.187.126.129"
   _allow-axfr._lrzdns.int.mb.bv.tum.de. 86400 IN TXT "129.187.126.171"

Neu eingefügte Einträge werden allerdings erst am nächsten Tag ca. 9:00 automatisch aktiv! Bitte achten Sie darauf, welchen Nameservern Sie wiederum den Zonentransfer erlauben!

Zusatzinformationen

DNS-Amplification-Attack

Die Attacke dient dazu, das Angriffsziel durch enormes IP-Verkehrsaufkommen zu überlasten. Dazu werden DNS-Anfragen (viele, bevorzugt klein und verteilt) mit gespoofter (gefälschter) Absenderadresse (der Adresse des Angriffsziels) an einen oder mehrere offene Resolver geschickt. Der Resolver speichert die gesuchten Einträge in seinem Cache und sendet sie als vermeintliche Antwort an das Angriffsziel. Diese (möglichst großen) Einträge können auf autoritativen Servern des Angreifers oder auf kompromittierten autoritativen Servern liegen, es können aber auch beliebige „normale“ Einträge (z.B. DNSKEY) sein, die der Angreifer vorher ausfindig gemacht hat. Sowohl große DNS-Records als auch viele Anfragen von einer Adresse (NAT) können legitim sein. Selbst wenn Heuristiken greifen, kann der Angreifer den Angriff verfeinern (mehr unterschiedliche Records, mehr offene Resolver...).

Solange IP-Spoofing nicht verhindert wird, gibt es keine grundsätzliche Lösung für das Problem, die Wirkung von Gegenmaßnahmen beschränkt sich darauf, den Angriff abzuschwächen oder den Aufwand für den Angreifer zu erhöhen. Verständlicherweise sind offene Resolver daher nicht gern gesehen.

Hinweise: Welche Informationen fehlen auf dieser Seite bzw. welche sollten ausführlicher dargestellt werden? Servicedesk-Portal