DNS-Server: Aufbau und Konfigurationsdateien

Transkript

1 Seminararbeit in Wintersemester 2010/2011 DNS-Server: Aufbau und Konfigurationsdateien von Elena Kleineick 1. Betreuer: Prof. Dr. rer. nat. Volker Sander 2. Betreuer: Benedikt Magrean Abgabetermin:

2 Inhaltsverzeichnis 1. Einleitung Eidesstattliche Erklärung Motivation Aufbau der Seminararbeit Historische Entwicklung Was ist und wie funktioniert ein DNS-Server? Domain-Namensraum Hierarchie Top-Level-Domains Zonen und Delegation Nameserver Master and Slave Rootserver Auflösung eines DNS-Requests Konfiguration mit Hilfe von BIND Konfigurationsdatei Zonendateien Resource Records Zusammenfassung und Ausblick Literaturverzeichnis 25 2

3

4 Rootserver. Ich werde außerdem ein Beispiel anführen, wie der DNS-Request eines Clients von einem DNS-Server aufgelöst wird. Der dritte Abschnitt beschäftigt sich mit dem Aufbau der DNS-Server. Es wird auch erklärt, wie man sie unter Zuhilfenahme der Berkley Internet Name Domain-Software (im Folgenden als BIND bezeichnet) einfach konfigurieren und eigene Zonen verwalten kann. Zum Schluss wird im letzten Abschnitt noch einmal kurz zusammengefasst, was in dieser Arbeit behandelt wurde. 1.4 Historische Entwicklung Heutzutage lässt es sich das Internet aus dem alltäglichen Leben nicht mehr wegdenken, aber das war nicht immer so. Ursprünglich ging es aus dem ARPAnet hervor, das die Advanced Research Project Agency (ARPA) 1 in den sechziger Jahren für militärische Projekte finanzierte. Ziel dieses Wide Area Networks war es, eine sinnvolle Nutzung der knappen und teuren Rechnerkapazitäten und eine Möglichkeit zur Kommunikation im Kriegfall zu gewährleisten. Außerdem erleichterte das Netzwerk die Zusammenarbeit der Benutzer. Das ging vom Austausch von s bis hin zu gemeinsam benutzten Dateien. Damals war das ARPAnet noch nicht mehr als ein kleiner Zusammenschluss einiger hundert 2 Hosts und es gab eine einzige Datei mit dem sprechenden Namen HOSTS.TXT, die alle Informationen zu diesen Hosts enthielt. Diese Datei wurde vom Network Information Center (NIC) aktualisiert und über FTP konnte man sich die aktuelle Version von HOSTS.TXT von einem Host des NIC herunterladen. Solche Aktualisierungen fanden nur etwa ein- oder zweimal die Woche statt. Mit der Entwicklung der TCP/IP-Protokoll-Suite in den achtziger Jahren, die zum Standard der Hosts im ARPanet wurde, und deren Aufnahme in das für Universitäten praktisch 3 kostenlose BSD-Unix-Betriebssystem, wurde eine Anbindung an das ARPAnet für mehr Organisationen finanziell möglich. Von da an wuchs die Anzahl der mit dem Netz verbundenen Rechner stetig an. Damit war der Grundstein für das heute bekannte Internet gelegt. In Folge des Zuwachses nahm gleichzeitig auch die Größe der Datei HOSTS.TXT zu und die Aktualisierung sowie das Herunterladen der Datei produzierte immer mehr Datenverkehr. Der verursachte Traffic wurde zu hoch. Eine Alternative musste gefunden werden. 1 Die ARPA (inzwischen umbenannt in DARPA) ist eine Behörde des amerikanischen Verteidigungsministeriums. Weitere Informationen können auf der Website der DARPA eingesehen werden. [2] 2 Hosts: Rechnersysteme, die in einem Netzwerk erreichbar sind 3 BSD steht für Berkley Software Distribution, eine Version des Betriebsystems Unix, das an der Berkley Universität entstand. 4

5 1983 entwarf Paul Mockapetris die Grundzüge des Domain Name System, spezifiziert in den RFCs und 883. Diese RFCs sind inzwischen veraltet; heutzutage gelten stattdessen die RFCs 1034 und Die RFCs (Request for Comments) beschreiben Standards im Internet. Alle RFCs können problemlos auf der Website der IETF (Internet Engineering Task Force) eingesehen werden. [3] 5

6 2. Was ist und wie funktioniert ein DNS-Server? Man kann sich DNS-Server als eine Art Wegweiser vorstellen; sie weisen Rechnern den Weg durch den riesigen Domain-Namensraum. Als DNS-Server werden Programme bezeichnet, die in der Lage sind, Informationen des Domain Name Systems zu nutzen und Anfragen an den Domain-Namensraum zu beantworten, aber auch Rechner, auf denen diese Programme ausgeführt werden. Das DNS ist ein weltweites, hierarchisch organisiertes Datenbanksystem zur Namensauflösung von Hostnamen 5 in Netzwerken. Es zeichnet sich durch eine dezentrale Verwaltung über eine Vielzahl von DNS-Servern aus. Einzelne Abschnitte der Datenbank können lokal verwaltet werden; trotzdem stehen die Informationen jedes Abschnittes durch ein Client-Server-Schema jedem im Netzwerk zur Verfügung. Ein DNS-Server (auch als Nameserver bekannt) benutzt diese Informationen, die das DNS bereitstellt. Er hat eine Adresszuordnungstabelle, die er verwendet, um Hostnamen die für Computer verständliche IP-Adresse zuzuordnen. Andersherum ist es ebenfalls möglich, von einer IP-Adresse auf den zugehörigen Namen zurückzukommen. Jedes Gerät, das an ein Netzwerk angeschlossen ist, hat eine zugewiesene IP-Adresse 6, über die andere Geräte es ansprechen können. Diese IP-Adressen sind für Rechner leicht zu merken, Menschen allerdings würde es deutlich schwerer fallen. Daher hat auch jedes Gerät einen Hostnamen, den Menschen leichter im Gedächtnis behalten können. Mit diesem Hostnamen wiederum können Computer nichts anfangen. Jedes Mal, wenn jemand einen für Menschen verständlichen Hostnamen benutzt, wird deshalb ein DNS-Server die entsprechende, maschinenverständliche IP-Adresse herausfinden. DNS- Server wissen, welcher Hostname zu welcher IP-Adresse gehört, und sind daher in der Lage Anfragen zu beantworten, die eine IP-Adresse zu einem Hostnamen haben möchten oder umgekehrt. Ein einzelner DNS-Server besitzt aber nicht das Wissen über den kompletten Domain- Namensraum. Daher leiten DNS-Server Anfragen, die sie nicht beantworten können, an andere Nameserver weiter; doch dazu später mehr. 5 Der Hostname dient als eindeutige Bezeichnung eines Rechners in einem Netzwerk. Für Rechner im Internet wird für gewöhnlich ein Fully Qualified Domain Name (i. d. R. die Url einer Website, z.b. fhaachen.de.) als Hostname verwendet. Für Rechner im LAN reicht der lokale Teil; der Domain-Teil wird hier zur Identifizierung nicht gebraucht. 6 IP ist die Abkürzung für Internet Protocol. Eine IP-Adresse bezeichnet ein Gerät in einem Computernetzwerk eindeutig und macht es adressierbar, also für andere Rechner erreichbar. Eine IP- Adresse ist demnach vergleichbar mit einer Postanschrift für Computer. Es gibt verschiedene Versionen von IP-Adressen. Interessant sind heute nur noch die aktuell verwendete Version 4, IPv4, und deren Nachfolger Version 6, IPv6. IP-Adressen sind eigentlich 32-stellige (IPv4) oder 128-stellige (IPv6) Binärzahlen, die der Lesbarkeit halber in 4 (bzw. 8 Abschnitte bei IPv6) unterteilt wird, von denen jeder dezimal (bzw. hexadezimal) notiert und mit einem Punkt (bzw. Doppelpunkt) vom vorherigen Abschnitt getrennt wird. 6

7 2.1 Domain-Namensraum Um den Domain-Namensraum leichter verstehen zu können, ist es hilfreich, ihn mit einem System zu vergleichen, das jedem bereits bekannt ist: Unserem Postsystem. Wie das Postsystem umfasst auch der Domain-Namensraum eine große Anzahl von Namen und Adressen; Hostnamen und IP-Adressen, um genau zu sein. Es ist kein einfaches Problem eine so große Datenmenge geschickt zu verwalten, insbesondere da sich diese Namen und Adressen auch noch täglich ändern können. Ähnlich den Postleitzahlen, Stadt- und Straßennamen des Postsystems, um Adressen zu unterscheiden und in Kategorien einzuteilen, hat der Domain-Namensraum verschiedene Domänen. Zu jeder Domäne können Hostrecher gehören und auch weitere Sub-Domänen. (Ebenso wie zwischen einem Max Mustermann in Hamburg und einem Max Mustermann in Bremen keine Verwechslungsgefahr besteht, wird es zwischen beispiel.eins.de und beispiel.zwei.de keinen Konflikt geben, da beispiel einmal der Domäne eins.de und einmal der Domäne zwei.de zugeordnet ist.) Hier hört die Ähnlichkeit zum Postsystem aber auf. Der Domain-Namensraum ist nämlich noch viel hierarchischer aufgebaut. Es sind bis zu 127 Verschachtelungsebenen für Sub- Domänen möglich. 7

8 2.1.1 Hierarchie Der Domain-Namensraum weist die Struktur eines umgekehrten Baumes von gewaltigem Ausmaß auf. Er hat eine einzige Wurzel, die Root-Domain oder auch einfach nur die Root. Von der Root aus verzweigt der Baum sich in Knoten und Blätter und bildet viele verschiedene Pfade. Jeder Verzweigungsknoten kann beliebig viele Abzweigungen haben...org.com.de....hello....hello.example.beispiel.world....world.world Abbildung 8.1 Beispiel für die Hierarchie des Domain-Namensraumes Von den Blättern aus verzweigt sich der Baum nicht mehr weiter. Im Gegensatz zu Knoten haben sie keine Sub-Domänen mehr. Sowohl Blätter als auch Knoten bekommen ein Label, das eine Zeichenkette darstellt. Diese ist alphanummerisch (als einzige Sonderzeichen sind - und _ erlaubt), muss mindestens ein Zeichen lang sein und kann höchsten 63 Zeichen haben. Sie muss mit einem Buchstaben anfangen und darf nicht auf ein Sonderzeichen enden. [4] Die einzelnen Label eines Pfades werden durch Punkte voneinander getrennt und ergeben so den Domainnamen. Ein Fully Qualified Domain-Name (im Folgenden FQDN genannt) wird korrekterweise noch mit einem Punkt abgeschlossen, der manchmal aber auch einfach weggelassen wird. Domainnamen müssen eindeutig sein, während einzelne Label durchaus identische Zeichenketten aufweisen können, weil sie im Kontext ihres Baumpfades doch zu einem einzigartigen Domainnamen werden. 8

9 Ein FQDN wird immer von rechts nach links aufgelöst. Je weiter rechts ein Label im Domainnamen steht, desto höher steht es auch im DNS-Baum, desto ranghöher ist es. In der Hierarchie direkt unter der Root-Domain sind die Top-Level-Domains Top-Level-Domains An der Spitze eines Baumpfades steht ein Knoten, der Top-Level-Domain (im Folgenden TLD) genannt wird. Es gibt eine ganze Reihe von Top-Level-Domains, von denen.com,.org,.net,.uk,.info und.de wohl zu den bekanntesten gehören. Wurzellabel (Root-Domain). Label 1.Ebene (Top-Level-Domains).de.com.net... Label 2.Ebene (Sub-Domänen und Hostnamen direkt unter TDLs).example.yahoo.microsoft... Label 3. Ebene (Sub-Sub-Dömanen und Hostnamen unter Sub- Domänen).one.two Abbildung 9.1 Label 1.Ebene, die Top-Level-Domains Weit mehr als hundert TLD gibt es und zu jeder TLD kann es mehrere Millionen Sub- Domänen geben. IANA 7 unterteilt TLD in zwei Hauptgruppen und einige Sonderfälle: Die allgemeinen TLDs, bei denen wiederum zwischen sponsored (z.b..edu ) und unsponsored TLDs (z.b..com ) unterschieden wird Die länderspezifischen TLDs (z.b..de ) 8 Die Sonderfälle, von denen heute nur noch.arpa benutzt wird 7 IANA steht für Internet Assigned Numbers Authority, eine Organisation, die unter anderem die Vergabe von IP-Adressen und Top-Level-Domains vornimmt. 8 Länder, die eine TLD für sich registrieren lassen wollen, sollten diese nach dem zweibuchstabigem Code benennen, der in der ISO 3166 angegeben ist. 9

10 2.1.3 Zonen und Delegation Domänen, für die ein eigener Nameserver verantwortlich ist, werden Zonen genannt. Für diesen Teil des Domain-Namensraums besitzt dieser Nameserver dann Autorität. Zonen werden durch eine Zonendatei repräsentiert, in der viele Resource Records gespeichert werden, die alle grundlegenden Informationen zu den Hosts dieser Zone beinhalten. Es ist leicht, eine Domain mit einer Zone zu verwechseln, aber es gibt einen kleinen Unterschied zwischen diesen Begriffen. Wenn durch Delegation die Zuständigkeit für eine Subdomain an einen anderen Nameserver abgegeben wird, entsteht eine Zone. Eine Domain kann also leicht in viele Zonen aufgeteilt werden. Zonen, die die Autorität einer Subdomain an einen anderen Nameserver delegieren, werden Parent-Domain genannt, während die durch die Delegierung neu entstandene Zone eine Child-Domain ist. Die Zonendatei einer Parent-Domain enthält nach der Delegierung keine Informationen zur Child-Domain mehr, nur noch den Namen des jetzt für die Zone verantwortlichen DNS-Servers; an den Server werden fortan alle Anfragen verwiesen, die diese Zone betreffen. Alle TLDs delegieren ihre Sub-Domänen an andere Nameserver und viele dieser Sub- Domänen halten es wiederum genauso. Eine Zone, die für sehr viele Subdomains autoritativ ist, hat einen hohen Verwaltungsaufwand und ihre Zonendateien sind sehr groß, was dem Sinn der Dezentralität des DNS widerspricht. Um eine eigene Zone zu sein, reicht es für eine Subdomain nicht aus, dass sie einen eigenen DNS-Server hat. Sie muss von der Parent-Domain wirklich die Rechte zur eigenen Verwaltung delegiert bekommen; das ist entscheidend. Es ist möglich, dass ein Nameserver die Autorität für mehrere Zonen innehat. 2.2 Nameserver Nameserver bilden die Serverseite des Client-Server-Modells, mit dem das DNS arbeitet. Sie haben Zugriff auf Informationen zu Teilabschnitten des Domain-Namensraums, den Zonen. Sie bekommen Anfragen von Clients, den sogenannten Resolvern. Bekommt ein Nameserver einen Request von einem Resolver, dann kann er auf verschiedene Arten reagieren. Kennt der Nameserver die Antwort auf die Anfrage, wird er sie dem Resolver mitteilen; das wird immer der Fall sein, wenn der angefragte Host in der Zone liegt, für die der Nameserver autoritativ ist. Andernfalls wird er einen anderen, festkonfigurierten Nameserver fragen, ob er den Request beantworten kann. Das nennt sich Weiterleitung. Gibt es keinen Nameserver, an den weitergeleitet wird, oder antwortet 10

11 dieser nicht, geht der Request an einen Rootserver weiter, von wo aus er die Hierarchie des Domain-Namensraums durchläuft, bis der für den Host autoritative Nameserver gefunden ist. Damit dieser Prozess nicht mit jedem Aufruf eines Hosts von vorne beginnen muss, speichern Nameserver die Antworten auf Requests für eine bestimmte Zeit in ihrem Cache. Diese Daten sind dann aber nicht mehr validiert und können Fehler aufweisen, wenn sich Namen und Adressen ändern. Ein nicht-autoritativer Nameserver, der diese Daten nur im Cache hat, bekommt von diesen Änderungen erst einmal nichts mit und muss darauf vertrauen, dass die ihm bekannten Daten noch stimmen. Trotzdem hat Caching einen eindeutigen Nutzen. Die Wartezeit zwischen DNS-Anfrage und Antwort verringert sich signifikant, wenn die geforderte Information bereits im Cache liegt, und die Rootserver werden dadurch entlastet, dass sie weniger Anfragen erhalten. Außerdem kann ein Nameserver die Daten in seinem Cache nicht unbegrenzt aufbewahren. Wenn er diese Informationen von anderen Nameservern zugesandt bekommt, wird auch immer eine TTL, eine Time to live, mit übergeben. Die TTL ist eine natürliche Zahl, die für eine Anzahl an Sekunden steht. Die im Cache gespeicherten Daten sind nur solange gültig, bis die TTL abgelaufen ist Master and Slave Bei Nameservern, die Autorität über eine Zone haben, unterscheidet man zwischen zwei verschiedenen Arten: Dem Master (auch Primary genannt) und dem Slave (auch Secondary genannt). Beide sind verantwortlich für dieselbe Zone und haben Zugriff auf dieselben Daten. Sie können beide Anfragen zu den in der Zone liegenden Hosts beantworten. Der Unterschied besteht darin, dass einem Master-Nameserver die Daten für seine Zone in einer lokal gespeicherten Datei zur Verfügung stehen, während ein Slave- Server seine Daten von einem Master-Server bezieht. Wenn sich ein Slave-Nameserver Informationen von einem Master holt, nennt man diesen Vorgang Zonentransfer. Ein Slave-Server ist nicht weniger gut als ein Master. Die Unterteilung in diese beiden Arten von Nameservern dient ausschließlich zur leichteren Verwaltung und sorgt zudem dafür, dass man mehrere Nameserver für eine Zone haben kann; dadurch wird eine Redundanz erreicht und die Arbeit wird auf mehrere Server verteilt. Ein Nameserver kann autoritativ für verschiedene Zonen sein. Dabei ist es auch möglich, dass er für eine Zone Master und für eine andere Slave ist. 11

12 2.2.2 Rootserver Rootserver sind der erste Anlaufpunkt für Nameserver, die einen DNS-Request nicht selbst beantworten können. Weltweit gibt es 13 Instanzen dieser Rootserver (mit den Buchstaben A bis M gekennzeichnet), die auch noch mehrfach redundant und auf mehrere Rechner an verschiedenen Standorten überall auf der Welt verteilt sind. Per Anycast 9 sind sie alle mit derselben IP-Adresse ansprechbar. Die Rootserver kennen die verantwortlichen Nameserver für alle TDLs und besitzen in einigen Fällen sogar die Autorität über diese. Auf jeden Fall kann ein Rootserver zu jeder an ihn gestellten Frage zu einem Domainnamen mindestens mit dem Namen und der Adresse des Nameservers antworten, der die Autorität über die TLD hat, in der die angefragte Domäne liegt. Da die Auflösung einer Anfrage fast immer bei einem Rootserver beginnt, kann wohl behauptet werden, dass die Rootserver zu den wichtigsten Instrumenten gehören, mit denen DNS arbeitet. Daher ist es nicht verwunderlich, dass an Rootserver ganz besonders hohe Ansprüche gesetzt werden. In den RFCs ist festgelegt, dass ein Rootserver mit der dreifachen Belastung des ohnehin schon am stärksten belasteten Rootservers zurechtkommen muss. Zwei Drittel seiner Kapazität wird ein Rootserver im Normalbetrieb also niemals benutzen. Trotzdem kam es in der Vergangenheit bereits mehrfach zu gezielten Angriffen auf einige Rootserver[5][6], wobei es auch schon vorkam, dass diese dann für eine Weile nicht erreichbar waren. Die Namen und IP-Adressen der Rootserver werden allen Nameservern, fest in eine Textdatei geschrieben, bekannt gemacht IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A A.ROOT-SERVERS.NET AAAA 2001:503:BA3E::2:30 (Eintrag von A.ROOTS-SERVERS.NET. als autoritativen Nameserver für die Root mit IPv4 und IPv6 Adresse[7]) Auflösung eines DNS-Requests An einem Beispiel soll nun Schritt für Schritt erklärt werden, wie ein DNS-Server vorgeht, wenn er von einem Resolver die Anfrage erhält, zu einem Domainnamen die dazugehörige IP-Adresse herauszufinden. Die Grafik in Abbildung 12.1 soll das Verständnis der einzelnen Abläufe erleichtern. 9 Mit Anycast wird ein einzelner Rechner aus einer ganzen Gruppe adressiert. Aus der Gruppe wird derjenige Rechner angesprochen, zu dem die kürzeste Route besteht. 12

13 Nehmen wir an, User Mustermann möchte die Internetseite mein.beispiel.de besuchen und tippt den Namen in die Adresszeile seines Webbrowsers. Mustermanns Rechner wird jetzt versuchen eine Verbindung zum Rechner X aufzubauen, der hinter dem Namen mein.beispiel.de steckt. Dafür muss Mustermanns Rechner jedoch die IP-Adresse von Rechner X kennen. Zuerst wird Mustermanns Rechner nun einen Blick in seine eigene lokale Host-Datei werfen, ob dort nicht vielleicht die IP-Adresse zu diesem Namen zu finden ist. Ist der entsprechende Name nicht lokal hinterlegt, richtet er sich mit der Frage nach der IP- Adresse an den ihm bekannten DNS-Server. (Das kann entweder ein manuell eingetragener oder automatisch via DHCP 10 zugewiesener Server sein.) In der Grafik wird dieser Schritt unter 1) abgebildet. Dann gibt es zwei bzw. drei mögliche Fortgänge. Wenn der Nameserver selbst Informationen zum gesuchten Domainnamen besitzt, kann er auf die Anfrage sofort mit der entsprechenden IP-Adresse antworten. Ebenso kann es sein, dass er die gesuchten Informationen noch in seinem Cache hat, weil sie innerhalb eines begrenzten Zeitraumes in der Vergangenheit schon einmal angefragt wurden. Auch dann kann er sofort mit der IP-Adresse antworten. Hat der DNS-Server aber das Wissen über die gesuchte Adresse weder im Cache noch selbst, muss der Request an einen anderen Nameserver weitergeleitet werden; dann fällt dieser Schritt aus und der Nameserver bearbeitet den Request selbst weiter, indem er sich als nächstes an einen der Rootserver wendet (Schritt 2 in der Grafik). Abbildung 12.1 Ablauf eines DNS-Requests 10 Das DHCP (Dynamic Host Configuration Protocol) kann einen Host automatisch in ein Netzwerk einbinden, ohne dass eine manuelle Konfiguration nötig ist. 13

14 In unserem Beispiel kennt der Rootserver den gesuchten Domainnamen nicht, erkennt aber, dass er falls existent in der.de Zone liegen wird. Der Rootserver wird daher eine Liste mit für die.de Zone autoritativen Servern zurückgeben (Schritt 3). Dieselbe Frage, die auch schon an den Rootserver ging, stellt der Nameserver jetzt einem der Server, die ihm vom Rootserver genannt wurden: Kennst du die Adresse von mein.beispiel.de? (Schritt 4) Wieder lautet die Antwort Nein und wieder bekommt der Nameserver eine Empfehlung, an welchen Server er sich mit seinem DNS-Request als nächstes wenden soll, an den für die Zone beispiel zuständigen DNS-Server. (Schritt 5) Ein drittes und letztes Mal stellt der Nameserver seine Anfrage (Schritt 6) und bekommt endlich eine positive Antwort. Dieser Server kennt den Domainnamen und teilt dem Nameserver IP-Adresse, , des gesuchten Rechners X mit. (Schritt 7) Der Nameserver gibt dann nur noch die IP-Adresse an den Resolver weiter, von dem die Anfrage ursprünglich ausging (Schritt 8). Die mein.beispiel.de kann jetzt in Mustermanns Webbrowser aufgerufen werden. 14

15 3. Konfiguration mit Hilfe von BIND Bei BIND handelt es sich um eine Softwarelösung, die es einem Anwender erlaubt, auf einem Rechner einen DNS-Server aufzusetzen. BIND ist kostenlos und Open Source 11. BIND geht immer auf die aktuellen DNS-Spezifikationen ein und ist weit verbreitet. Die Abkürzung BIND steht für Berkley Internet Name Domain (teilweise wird auch noch Berkley Internet Name Daemon genannt). Die ursprüngliche Version von BIND entstand Anfang der achtziger Jahre als Studentenprojekt an der Universität Berkley in Kalifornien. Seit Version findet die Entwicklung und Aufrechterhaltung von BIND unter Aufsicht des ISCs (Internet Software Consortium) statt. Es wurde und wird auch heute immer noch kontinuierlich an neuen Versionen von BIND gearbeitet. Aktuell ist die Version 9; Version 10 befindet sich bereits in der Entwicklungsphase. Das ISC empfiehlt allen Usern auf Version 9 zu updaten. Alle vorherigen Versionen erhalten inzwischen keinen Support mehr und stellen ein erhöhtes Sicherheitsrisiko dar. [8] Um mit BIND einen eigenen Nameserver aufzusetzen, muss erst einmal nicht viel mehr getan werden, als das Softwarepaket von der Website des ISC herunterzuladen und zu installieren. Grundsätzlich ist der Nameserver dann lauffähig, muss aber noch konfiguriert werden. Dabei bedarf es einerseits einer Konfigurationsdatei und andererseits einer beliebigen Anzahl von Zonendateien. 3.1 Konfigurationsdatei Die Konfigurationsdatei eines Nameservers findet man häufig unter dem Namen named.conf. 12 Sie wird unter anderem benutzt, um Optionen für den Server anzugeben (z.b. die Möglichkeit des Cachings zu erlauben oder zu verbieten) und ihm seine Zonen bekannt zu machen. Die hier vorgestellte Syntax ist die einer BIND-Konfigurationsdatei. Für Konfigurationsdateien gibt es in den RFCs keine eigenen Standards. [9] In BIND Version 4 begannen Kommentarzeilen in der Konfigurationsdatei noch mit einem Semikolon. Bei BIND 8 und 9 ist ein solches Kommentar nicht mehr möglich, da Semikolon nun eine Konfigurationsanweisung abschließen. Dafür können bei diesen Versionen Kommentare im Stil von C, C++ und Shell-Skripten verwendet werden. 11 Eine Software ist Open Source, wenn ihr Quellcode für jedermann öffentlich zugänglich ist. 12 Auch wenn es nicht danach aussieht, das d von named wird als einzelner Buchstabe ausgesprochen. Es steht für Daemon. 15

16 ; So kommentierte man in Version 4 /* Ein Beispiel für ein Kommentar in C */ // Ein Beispiel für ein Kommentar in C++ # Ein Beispiel für ein Kommentar in einem Shell-Skript Die named.conf Datei ist eine Sammlung von Anweisungen (Statements), die verschiedene Optionen in Gruppen zusammenfassen. Geschweifte Klammern beginnen und beenden eine Anweisung. Die Syntax sieht wie folgt aus: <statement-1> ["<statement-1-name>"] [<statement-1-class>] { <option-1>; <option-2>; <option-n>; }; <statement-2> ["<statement-2-name>"] [<statement-2-class>] { <option-1>; <option-2>; <option-n>; }; <statement-n> ["<statement-n-name>"] [<statement-n-class>] { <option-1>; <option-2>; <option-n>; }; [e] Es gibt mehrere Arten von Statements, die unterschiedliche Zwecke erfüllen. Das acl Statement ermöglicht es, Hosts in Gruppen einzuteilen. Diesen Gruppen kann dann später in einem anderen Statement der Zugriff auf den Nameserver explizit erlaubt oder verboten werden. In den Optionen dieses Statements werden die IP-Adressen der Hosts aufgelistet, die in der Gruppe sein sollen. Es kann mehrere acl Statements in der Konfigurationsdatei geben. Das include Statement erlaubt das Einfügen einer Datei in named.conf. Dieses Statement kann benutzt werden, wenn man bestimmte Daten lieber an einem anderen Ort speichern will, weil sie zu wichtig sind, um sie in die named.conf zu schreiben. Das options Statement enthält eine Vielfalt an Optionen zur allgemeinen Konfiguration des Nameservers, wie z.b. die oben erwähnte Zugriffsbeschränkung für definierte Gruppen durch die blackhole- (kein Zugriff auf den Server) und allow-query-option (normaler Zugriff möglich). Mit der Option forwarders lassen sich Nameserver eintragen, an die DNS-Requests weitergeleitet werden sollen. Durch notify kann festgelegt werden, ob Slave-Server über ein Update der Zone informiert werden sollen und durch directory kann der Verzeichnispfad 16

17 angegeben werden, unter dem die Zonendateien zu finden sind, sollte dieser Pfad sich von der Standardbelegung unterscheiden. Weitere Optionen sind z.b.: Allow-recursion Dump-file Forward Listen-on Pid-file Root-delegation-only Statistics-file options { directory /dns/zone ; pid-file file.pid ; statistics-file file.stats ; dump-file file.dump ; recursion no; allow-query {any;} allow-transfer {eine_acl_gruppe;} blackhole {andere_acl_gruppe;} }; Beispiel eines options Statements Jede Konfigurationsdatei kann nur ein einziges option Statement haben. Das zone Statement legt einzelne Optionen für bestimmte Zonen fest und macht dem Nameserver deren Zonendatei bekannt. Optionen, die hier angegeben sind, fallen schwerer ins Gewicht als die globalen Konfigurationen aus dem option Statement und überschreiben dessen Werte für diese eine Zone. Die Syntax für ein Zone Statement sieht folgendermaßen aus: zone <zone-name> <zone-class> { <zone-option1>; <zone-option2>;... <zone-optionn>; }; Für <zone-class>, die Klasse der Zone, könnte z.b. IN eingesetzt werden, was dann für Internet stünde. Das ist auch der Defaultwert für die Klasse in BIND 8 und 9. Wichtiger ist der <zone-name>. Standardmäßig wird der Zonenname an jeden Domainnamen in der Zonendatei angehängt, die keine FQDN ist. Wie für das option Statement gibt es auch für zone Statements eine ganze Reihe von verschiedenen Optionen, viele von ihnen ähnlich oder identisch mit den Optionen des option Statements. Beispielsweise wird hier durch allow-query nicht der Zugriff auf den Nameserver sondern auf die Informationen der einzelnen Zone geregelt. Wichtig sind vor allen Dingen die type und file Optionen. Mit File wird angegeben, wie die Zonendatei zu dieser heißt, während über type bestimmt wird, wie der Nameserver die Zone handhabt. Typ master: Wie der Name vermuten lässt deutet dieser Typ darauf hin, dass der hier konfigurierte Nameserver Master über die Zone ist. Typ slave: Zonen dieses Typs brauchen eine weitere Option, die angibt zu welchem Master sie der Slave sind. 17

18 Typ hint: Dieser spezielle Typ von Zonen zeigt auf die Rootserver. Typ forward: Bekommt dieser Zonentyp einen Request wird er zu anderen Nameservern weitergeleitet. Typ delegation-only: TLDs benutzen diesen Typus. zone. { type hint; file root.zone ; }; zone beispiel.de { type master; file mas/beispiel.zone ; }; zone beispiel2.de { type slave; file sla/beispiel2.zone ; masters { ;} }; Beispiele für zone Statements 3.2 Zonendateien Für jede dem Nameserver in der Konfigurationsdatei durch ein zone Statement angegebene Zone, gibt es eine Zonendatei. In ihr werden alle Informationen gespeichert, die für diese Zone nötig sind. Das geschieht über eine Liste aus Resource Records. Jede Zonendatei muss genau einen Start of Authority (kurz SOA) Resource Record beinhalten, der auch meist am Anfang der Datei zu finden ist, und mindestens einen Name Server (kurz NS) Resource Record. Alle weiteren Resource Records sind optional. Die Formatierung für Daten in Zonendateien ist immer gleich. Sie richtet sich nach den Vorgaben der RFCs 1034[4] und 1035[11] und wird auch Master File Format genannt. Kommentierung in Zonendateien beginnen mit einem Semikolon und enden erst mit dem Zeilenende. Ein Kommentar muss nicht am Anfang einer Zeile beginnen, sondern können auch direkt hinter andere Anweisungen gesetzt werden. Leerzeilen werden ignoriert und dürfen wie Kommentare überall in der Datei vorkommen. Durch die $ORIGIN-Anweisung kann ein anderer Domainname angegeben werden, der an relative Domainnamen angehängt wird, die nicht mit einem Punkt abgeschlossen sind. Standardmäßig ist die Origin der Name, den die Zone in der Konfigurationsdatei trägt. kann als Stellvertreter für den Domainnamen der Zone benutzt werden. 18

19 Am Ende eines Domainnamens kann der Name der Zone weggelassen werden. Er wird automatisch durch die $ORIGIN-Anweisung ergänzt. Ein Resource Record, der mehrere Zeilen lang ist, muss in Klammern geschrieben werden. Gibt es zwei oder mehr Resource Records zu demselben Domainnamen darf der Name weggelassen werden. Ein Backslash wird als Escape-Sequenz benutzt. So stellt etwa \. einen Punkt darf. 8-Bit-Zeichenketten können durch einen Backslash und die dezimale Zahl, die diese Zeichenkette darstellt, geschrieben werden. Durch die $INCLUDE-Anweisung ist es möglich eine andere Datei in die Zonendatei einzufügen. In dieser Datei kann eine abweichende $ORIGIN-Anweisung für die darin enthaltenen Domainnamen stehen. Werden TTL- und Klassenanweisungen in Resource Records weggelassen, werden die Werte genommen, mit denen sie zuletzt in vorangegangenen Records belegt waren. 3.3 Resource Records Resource Records machen einen Großteil des Inhalts einer Zonendatei aus. Sie sagen alles aus, was es über die Zone zu wissen gibt. Es gibt verschiedene Klassen von Records: IN, CH, HS und CS. Mit Ausnahme von IN für das Internet werden sie aber heutzutage kaum noch benutzt. Sie stehen für Netzwerke, die es nicht mehr gibt oder die nicht mehr in Gebrauch sind. Abgesehen davon haben alle Records auch einen Typ. Unterschiedliche Typen erfüllen unterschiedliche Aufgaben und es gibt mehrere Dutzend, von denen manche mehr und manche weniger verbreitet, manche veraltet oder teilweise komplett durch andere abgelöst sind. Unabhängig von ihrem Typ werden Resource Records innerhalb ihrer Zonendatei immer in einem ASCII-Format mit der folgenden Syntax dargestellt: <name> [<ttl>] [<class>] <type> <rdata> Jede beliebige Kombination aus Leerstellen und Tabs wird als Trennung zwischen diesen fünf Feldern angesehen. Das Name-Feld gibt den Domainnamen an, für den der Resource Record Gültigkeit besitzt. Das TTL-Feld ist eine Nummer und gibt die Time to live in Sekunden für den Record an. Die Möglichkeiten für das Class-Feld habe ich bereits erklärt; meistens ist die Klasse IN. Im Type-Feld steht, um welche Art von Resource Record es sich handelt. Wie schon erwähnt gibt es eine Menge unterschiedlicher Typen. Einige davon werden gleich erklärt. Das letzte Feld rdata enthält die eigentlichen Informationen des Resource Records. Der Inhalt des Feldes variiert stark abhängig davon, um welchen Typ von Record es sich 19

20 handelt. Manche Resource Records haben weitere Felder, z.b. ein Length-Feld, das die Länge der Daten im Rdata-Feld angibt. Es gibt eine komprimierte Form der Darstellung von Resource Records, die man aber nur im Cache anderer Nameserver und in den Datenpaketen, die sie austauschen, vorfindet. Anstelle des Typen haben die Records in komprimierter Form eine Nummer. Der Typ SOA: SOA steht für Start of Authority. Es muss in jeder Zonendatei einen SOA-Record geben. Er steht am Anfang der Datei und legt grundsätzliche Konfigurationen für die Zone fest. Ein SOA-Record besteht aus folgenden Elementen: Name: Hier steht der Name der Zone. Klasse: IN Typ: SOA Primary: Hier steht der Masterserver dieser Zone. Mail-Adresse: Unter der hier angegebenen Mail-Adresse ist der Verantwortliche für diese Zone zu erreichen. in der Mail-Adresse wird durch einen Punkt ersetzt. Tatsächlich in der Adresse vorkommende Punkte müssen mit \. dargestellt werden. Seriennummer: Die Seriennummer dokumentiert Aktualisierungen. Nach jedem Update an der Zone wird sie erhöht und gibt damit einen Hinweis darauf, dass sie verändert wurde. Die Seriennummer hat oft das Format JJJJMMDDVV. Refresh: Hier steht die Zeit in Sekunden, die vergeht, bevor ein Slave-Server beim Master nachfragt, ob Änderungen stattgefunden haben. Retry: Hier steht die Zeit in Sekunden, die vergeht, bevor ein Slave erneut nachfragt, falls der Master auf seine letzte Anfrage nicht reagiert hat. Expire: Hier steht die Zeit in Sekunden, die vergeht, bevor ein Slave eine Zone deaktiviert, falls es ihm nicht gelingt einen Zonentransfer durchzuführen. Er ist dann nicht mehr autoritativ für diese Zone. TTL: Hier steht die Zeit in Sekunden, die vergeht, bevor ein Nameserver negative Antworten auf einen DNS-Request aus seinem Cache löschen muss. Diese Art von TTL wird auch negativ-caching-ttl genannt. Beispiel eines SOA-Records: beispiel.de. IN SOA mas.beispiel.de. hostmaster.beispiel.de. ( ; serial , 1.Änderung ; refresh 12 Stunden 7200 ; retry 2 Stunden ; expire 3 Tage 3600 ; negativ-caching-ttl 1 Stunde ) 20

21 Der Typ NS: NS steht für Name Server. NS Resource Records können zwei grundlegende Funktionen ausüben. Einerseits können sie definieren, welche oder welcher Nameserver für diese Zone zuständig ist. Andererseits kann er Informationen über Delegationen enthalten, in dem er die für eine Subdomäne zuständigen Nameserver auflistet. Ein NS-Record besteht aus folgenden Elementen: Domain: Hier steht der Name der Domäne, für welche der Eintrag gilt. TTL: TTL in Sekunden Klasse: IN Typ: NS Server: Hier steht der Name des autoritativen Nameservers für die Domäne. Beispiele für NS-Records: beispiel.de IN NS mas1.beispiel.de. z1.beispiel.de IN NS mas1.beispiel.de. z1.beispiel.de IN NS mas2.beispiel.de. z1.beispiel.de IN NS mas2.z1.beispiel.de. z2.beispiel.de IN NS mas1.beispiel.de. Der Typ A: A ist ein Adress-Record. Er weist einem Domainnamen eine IPv4-Adresse zu. Er besteht aus folgenden Elementen: Domainname: Hier steht der Name unter dem der Host bekannt ist. TTL: TTL in Sekunden Klasse: IN Typ: A Adresse: Hier steht eine IP-Adresse im IPv4-Format. Beispiele für A-Records: beispiel.de IN A z1.beispiel.de IN A z2.beispiel.de IN A Der Typ AAAA: Der AAAA ( quad-a ) Resource Record ist das IPv6-Äquivalent zum A-Record. Er weist einem Domainnamen eine IPv6-Adresse zu. Es kann sowohl A- als auch AAAA-Records für denselben Domainnamen geben. Ein AAAA-Record besteht aus folgenden Elementen: Domainname: Hier steht der Name unter dem der Host bekannt ist. TTL: TTL in Sekunden 21

22 Klasse: IN Typ: AAAA Adresse: Hier steht eine IP-Adresse im IPv6-Format. Beispiel für AAAA-Records: beispiel.de IN AAAA 2001:db8::1 Der Typ CNAME: CNAME steht für canonical name. Dieser Resource Record legt zu einem bestehenden Domainnamen, dem kanonischen Namen, einen Aliasnamen fest, mit dem er ebenso angesprochen werden kann wie mit seinem richtigen Namen. Möglich sind beliebig viele Aliase für einen Namen. Ein CNAME-Record besteht aus folgenden Elementen: Name: Hier steht der Aliasname. TTL: TTL in Sekunden Klasse: IN Typ: CNAME Ziel: Hier steht der kanonische Name, der durch den Aliasnamen angesprochen wird. Das muss ein existierender Domainname sein. Der Aliasname darf auf keinen anderen Aliasnamen zeigen. Beispiel für CNAME-Records: meinbeispiel.de IN CNAME beispiel.de. lisasbeispiel.de IN CNAME beispiel.de. beispiel.org IN CNAME beispiel.de. Der Typ MX: MX steht für Mail Exchange. Dieser Resource Record ist speziell für die Angabe von Mailservern gedacht. Um für Redundanz zu sorgen, werden für eine Dömane meistens mehrere Mailserver und MX-Records mit unterschiedlichen Prioritäten benutzt. Ein MX- Record besteht aus folgenden Elementen: Domainname: Hier steht der Name der Domäne, für welche der Eintrag gilt. TTL: TTL in Sekunden Klasse: IN Typ: MX Präferenz: Hier steht eine Zahl. Sind einer Domain mehrere Mailserver bekannt wird der mit der niedrigeren Präferenz benutzt. Erst wenn dieser Server nicht antwortet, wird der Mailserver mit der nächsthöheren Präferenz genommen. Server: Hier steht der Name des Mailservers. 22

23 Beispiel für MX-Records: beispiel.de IN MX 10 mail1.beispiel.de. beispiel.de IN MX 20 mail2.beispiel.de. beispiel2.de IN MX 10 mail.beispiel2.de Der Typ PTR: PTR steht für Pointer. Ein PTR-Record ist das Gegenteil zu den A- und AAAA-Records; er weist IP-Adressen die Hostnamen zu und wird für den Reverse-Lookup 13 benutzt. Ein PTR- Record besteht aus folgenden Elementen: IP-Adresse: Hier steht die IP-Adresse, jedoch in umgekehrter Reihenfolge der Abschnitte, ergänzt mit den Zonen in-addr.arpa für IPv4-Adressen oder ip6.arpa für IPv6. TTL: TTL in Sekunden Klasse: IN Typ: PTR Hostname: Hier steht der Name des Host mit dieser IP-Adresse. Beispiel für PTR-Records: ; IPv in-adr.arpa IN PTR beispiel.de. ; IPv b.d ip6.arpa IN PTR beispiel.de. Das waren nur einige von über 100 verschiedenen Typen. Weitere wichtige Resource Record Typen sind: Typ Nummer RCF Erklärung DNSKEY / 3755 Enthält einen öffentlichen Schlüssel für diesen Hostnamen (von DNSSEC benutzt) DS / 3658 Verkettet mit DNSSEC signierte Zonen HINFO Enthält Informationen über den Host LOC Enthält Informationen über den Standort MINFO Enthält Informationen zur Mailbox- oder list NAPTR / 2168 / 3403 Erweiterung des A-Records, enthält zusätzliche Informationen wie z.b. das Serverprotokoll RP Enthält Informationen über eine verantwortliche Person SRV Dienste, die in der Zone verfügbar sind TXT Enthält einen Textstring [12] 13 Als Reverse-Lookup wird der Vorgang bezeichnet, beim dem ein Nameserver eine DNS-Anfrage mit einer IP- Adresse stellt, um den Hostnamen zu dieser Adresse herauszufinden. 23

24 4. Zusammenfassung und Ausblick Zusammenfassend lässt sich zum Thema DNS-Server sagen, dass das DNS als Infrastruktur für die Namensauflösung und die dezentrale Verwaltung der Domain-Datenbank über viele DNS-Server von deutlichem Vorteil ist. Der hierarchische Aufbau des Domain-Namensraums ermöglicht nicht nur eine leichte Übersicht, sondern macht es für DNS-Server auch sehr einfach die Informationen zu finden, die sie suchen. Nicht umsonst hat sich dieses System seit seiner Einführung 1983 nicht mehr großartig verändert. In Kombination mit BIND lassen sich DNS-Server einfach aufsetzen und fortlaufend verwalten. Die klare Struktur seiner Konfigurations- und Zonendateien erhöht die Übersichtlichkeit; man kann von Beispielen leicht lernen und sie auf ein Livesystem anwenden. Wenn man den Einstieg einmal geschafft hat, wiederholen sich die Abläufe bei der Konfiguration eines Nameservers, was es auch wieder leichter macht. Trotzdem hat das DNS auch seine Nachteile. Ein aktuell wichtiges Thema ist die DNS-Sicherheit. Das DNS ist leider anfällig für Verfälschungen und Denial-of-Service-Angriffe. Durch DNS- Spoofing kann z.b. eine falsche IP-Adresse auf einen DNS-Request zurückgegeben werden, wodurch der Nutzer Verbindung zu einem gänzlich anderen Host herstellt als gewollt. Um diesen Problemen von DNS entgegenzuwirken, wird seit Jahren an Erweiterungen gearbeitet, welche die Sicherheit von Datentransfer übers DNS verbessern sollen. Zu diesen gehören auch die Domain Name System Security Extensions (kur DNSSEC), die mit einem asymmetrischen Kryptosystem arbeiten, bei dem Daten ein privater Schlüssel mitgegeben wird, der mit einem öffentlichen Schlüssel verglichen werden kann, um die Authentizität der Daten sicherzustellen. Zum Schluss sei noch einmal erwähnt, dass viele in unserer heutigen Gesellschaft ganz alltägliche Dienste wie -Forwarding ohne das DNS nicht funktionieren. DNS lässt sich aus unserem Leben kaum noch wegdenken. Trotz einiger Sicherheitsbedenken ist es ein sehr gutes System, das sich über Jahrzehnte halten konnte und das vermutlich auch noch viele weitere Jahre tun wird. 24

25 5. Literaturverzeichnis [1] [2] [3] [4] [5] [6] [7] ftp://ftp.rs.internic.net/domain/named.root [8] [9] Paul Albitz, Cricket Liu. DNS und BIND. O Reilly Verlag (S. 77) [10] [11] [12] 25