Konzept und Implementierungsvorschläge eines redundanten Dual-Stack-Nameservers

Transkript

1 FH AACHEN University of Applied Sciences Medizintechnik und Technomathematik Scientic Programming Seminararbeit Konzept und Implementierungsvorschläge eines redundanten Dual-Stack-Nameservers Tobias Thieron 14. Dezember 2012 betreut durch Prof. Dipl.-Inf. Ulrich Stegelmann Dipl.-Phys. Frank Brüggemann

2 Inhaltsverzeichnis 1. Motivation 3 2. DNS Was ist DNS Aufbau und Funktionsweise Geschichte Nameserver und BIND Verfügbarkeit Aufbau innerhalb des RZ der RWTH Aachen Konzept und Implementierungsvorschläge Hardware Betriebssystem und benötigte Software Routing und Anycast Monitoring Ausblick 25 A. Eidesstattliche Erklärung 26 B. Abbildungsverzeichnis 27 C. Literatur 28 2

3 1. Motivation Das Ziel dieser Seminararbeit ist ein Konzept für einen redundanten Dual-Stack-Nameserver zu entwickeln. Ein redundanter Dual-Stack-Nameserver ist ein Nameserver, der sowohl IPv4-Clients als auch IPv6-Clients bedient. Auÿerdem ist dieser Nameserver durch einen anderen Nameserver redundant vertreten. Ziel der Umsetzung des Konzeptes ist eine deutliche Verbesserung der DNS-Infrastruktur des Rechen- und Kommunikationszentrums (RZ) der RWTH Aachen zu erreichen. Zuerst wird das DNS (Domain Name System) von Grund auf beschrieben und erklärt. Im 2. Teil der Seminararbeit wird das Konzept erläutert. 3

4 2. DNS 2.1. Was ist DNS Zur Adressierung im Internet werden eindeutige IP-Adressen benutzt. Menschen können sich IP-Adressen nicht merken, deshalb wurden Hostnamen entwickelt. Hostnamen sind Zeichenketten, deren Aufbau bestimmten Regeln folgt. 1 Die Verknüpfung von IP- Adressen und Hostnamen ist eine der Hauptaufgaben des DNS. Weitere Aufgaben sind unter anderem die Auösung von Hostnamen zu IP-Adressen, die Unterstützung des E- Mail-Dienstes und die Weiterleitung von Services. Diese verschiedenen Aufgaben werden durch Resource Records beschrieben Aufbau und Funktionsweise Das DNS ist eine verteilte Datenbank, die auf vielen verschiedenen Nameservern gespeichert wird. Als Nameserver wird sowohl der Server, auf dem die Software, die die DNS-Anfragen beantwortet, bezeichnet, als auch die eigentliche Software. Die am meisten verbreitete Software für Nameserver ist BIND. Das Schema der Hierarchie des DNS-Namensraumes ist wie folgt: Abbildung 2.1.: Die Top Level Domains im DNS-Namensraum 1 Mockapetris, RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES. 4

5 2.1. WAS IST DNS KAPITEL 2. DNS Die Zeichenketten, die sich in den Umrandungen von Abbildung 2.1 benden, werden als Tags bezeichnet und sind 0 bis 63 Zeichen lang 2. Eine Verbindung aus diesen Tags mit einem Punkt als Trenner bis zum obersten Tag, dem Root-Tag wird als Domain bezeichnet. Der Root-Tag besteht aus null(nichts) oder auch " ". Die Domain wird mit einem Punkt hinter dem Root-Tag abgeschlossen und ist dadurch ein Fully Qualied Domain Name (FQDN). Sollte sich kein. am Ende der Domain benden, ist diese Domain nicht abgeschlossen und dadurch relativ zu einer anderen Domain. In einer Zonendatei, also die Datei, wo die Informationen über die Adressen einer Zone vorhanden sind, können beide Notationen parallel verwendet werden. Ein Beispiel: Die Deutschland zugeordnete Top-Level-Domain DE beginnt bei dem "de" -Tag und führt bis zum Root-Tag nach oben. Das Ergebnis ist: de.. Die oberste Domain wird Root-Domain genannt. Domains, die sich hierarchisch unter anderen Domains benden, werden Subdomains genannt. Alle restlichen Domains sind unter der Root-Domain angesiedelt, damit sind alle Domains, auÿer die Root-Domain, Subdomains der Root-Domain. Subdomains, die hierarchisch eine Ebene unter der Root-Domain sind, werden als Top-Level-Domains bezeichnet (TLD). 23 Subdomains, die sich genau eine Ebene unter den TLD's benden, werden Second-Level-Domain bezeichnet. 23 Erlaubt ist nach dem Standard eine Tiefe von bis zu 127 Tags. 23 Jeder FQDN ist eindeutig. 23 Das folgende Beispiel zeigt einen DNS-Baum mit Domains unterhalb der TLD's. 2 Mockapetris, RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES 3 Mockapetris, RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 5

6 2.1. WAS IST DNS KAPITEL 2. DNS Abbildung 2.2.: Die RWTH Domain inklusive einer Subdomain Der Domainname bzw. der Hostname für den Server der Webseite der RWTH Aachen ist den Regeln entsprechend 45 Damit die RWTH Aachen die Subdomain rwth-aachen.de. der Domain de. verwenden und administrieren durfte, mussten die Zuständigen der RWTH Aachen einen Registrierungsantrag für die Domain rwth-aachen.de. an die zuständige Firma oder Institut der hierarchisch höher gestellten Domain stellen. Die zuständige Firma für die Domain de. ist DENIC. Bei der Firma DENIC wird nun eine Domain rwth-aachen.de. registriert und die Zuständigkeit für diese Domain wird an die RWTH Aachen delegiert. Die Delegierung erfolgt durch einen Eintrag eines NS-Resource-Records, der angibt, welcher Nameserver für die Domain rwth-aachen.de. zuständig ist. 4 Diese Webseite liegt in der Zone rwth-aachen.de. Angenommen der Fachbereich Physik möchte nun auch eine Domain physik.rwth-aachen.de bei der RWTH Aachen registrieren lassen. Dazu muss der Fachbereich Physik einen Registrierungsantrag für die Domain physik.rwth-aachen.de. an die RWTH Aachen stellen und die Zuständigkeit an den Fachbereich Physik delegieren lassen. Durch die Delegierung der Zuständigkeit ensteht die Zone physik.rwth-aachen.de., für die der Fachbereich Physik administrativ ist. Der Fachbereich Physik verwaltet nun alle Maschinen, die sich in der Domain bzw. Zone physik.rwth-aachen.de. benden. Die Zone physik.rwthaachen.de. liegt hierarchisch gesehen unterhalb der Zone rwth-aachen.de. 4 Mockapetris, RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES 5 Mockapetris, RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. 6

7 2.1. WAS IST DNS KAPITEL 2. DNS Sollte die Domain physik.rwth-aachen.de. registriert, aber nicht an den Fachbereich Physik delegiert worden sein, ist die RWTH Aachen zuständig für die Domain physik.rwthaachen.de. Dadurch existiert die Zone physik.rwth-aachen.de. nicht mehr und alle Maschinen, die zur Domain physik.rwth-aachen.de. gehören, werden nun von der RWTH Aachen administriert. Das Verfahren der Zuständigkeitsdelegierung dient zur Administrations- und Lastverteilung. Ein Nachteil ist, dass es keinerlei Kontrollmöglichkeiten von den Nameservern der Subdomains mehr gibt. Der Unterschied zwischen einer Domain und einer Zone liegt darin, dass eine Domain den Zuständigkeitsbereich deniert und eine Zone die physische Realisierung deniert. Nun muss der Vorgang einer DNS-Anfrage nicht von jedem Programm, das den DNS- Dienst benutzt, neu implementiert werden. Aus diesem Zweck sind Resolver entwickelt worden. Resolver übernehmen die in dem Programm eingegeben Domainnamen und erstellt aus ihnen FQDN. Dann erstellt der Resolver eine rekursive oder iterative DNS- Anfrage. Eine rekursive DNS-Anfrage verläuft wie folgt: 6 6 Mockapetris, RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. 7

8 2.1. WAS IST DNS KAPITEL 2. DNS Abbildung 2.3.: Der Beispielverlauf einer rekursiven Anfrage Eine iterative DNS-Anfrage ist zu Beginn identisch mit einer rekursiven. Nur falls der Nameserver nicht autoritativ für den FQDN sein sollte, gibt der Nameserver die IP- 8

9 2.1. WAS IST DNS KAPITEL 2. DNS Adresse der Root-Nameserver zurück. Der Resolver fragt nun anstelle der Nameserver nach dem autoritativen Nameserver für den FQDN. Der Resolver wird an den zuständigen Nameserver der Subdomain des FQDN der nächsten Hierarchieebene weitergeleitet. 7 Zusammengefasst erfüllt das DNS folgende Eigenschaften: Es ist hierarchisch Es wird dezentral administriert Es ist global verfügbar Geschichte Das ursprüngliche Internet, das ARPAnet begann 1969 mit 4 Groÿrechnern. Diese gehörten jeweils zu diesen Einrichtungen: Stanford Research Institute, University of Utah, University of California, Los Angeles und die University Santa Barbara. Damit sich die Mitarbeiter nicht alle IP-Adressen einprägen mussten, wurde die "hosts.txt" Datei entwickelt und wurde auf dem Rechner des SRI-NIC (Stanford Research Institute - Network Information Center) gelegt. In dieser Datei wurden pro Zeile die IP-Adressen und deren zugehöriger Hostname eingetragen, wie in dem nachfolgenden Beispiel gezeigt wird. 8 7 Mockapetris, RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. 8 Harrenstien, Stahl und Feinler, RFC 952 : DOD INTERNET HOST TABLE SPECIFICATION. 9

10 2.1. WAS IST DNS KAPITEL 2. DNS # Copyright (c) Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # rhino.acme.com # source server # x.acme.com # x client host # localhost name resolution is handled within DNS itself. # localhost # ::1 localhost # Testeingaben Abbildung 2.4.: Beispiel einer Hosts.txt-Datei auf einem Windows-Rechner Der Vorteil bei dieser Art der Verwaltung ist dass die Datei zentral liegt und nur im Rechner des SRI-NIC geändert werden muss. Aber mit der Zeit wurden immer mehr Rechner an das ARPAnet angeschlossen und die Verwaltung dieser Datei wurde erschwert. Denn mit der steigenden Anzahl Rechner, wurde die Datei gröÿer und die Leitungen zum Rechner des SRI-NIC wurden immer mehr belastet, sowie auch der Prozessor des Rechners. Auÿerdem konnten die Mitarbeiter des SRI-NIC nicht immer verhindern, dass Hostnamen doppelt eingetragen wurden, was zu Kollisionen führte. Der letzte Nachteil ist, dass die Aktualität der Datei nicht immer gegeben war, denn während der Übertragung der Datei vom Rechner des SRI-NIC bis zum anfordernden Rechner könnte sich die Datei schon wieder geändert haben. Da die Anzahl der neu hinzukommenden Rechner voraussichtlich eher zunehmen als 10

11 2.1. WAS IST DNS KAPITEL 2. DNS abnehmen würde, gaben die führenden Mitglieder des ARPAnets einen Auftrag, zur Entwicklung eines neuen Systems, was die "hosts.txt"datei ablösen sollte, in Kraft. Das neue System sollte die folgenden Bedingungen erfüllen: Es sollte global abrufbar sein Es sollte dezentral administriert werden Es sollte hierarchisch aufgebaut sein Die Dezentralisierung sollte den Ein-Host-Flaschenhals beheben sowie das Netzwerk entlasten. Auÿerdem würden die Daten durch die lokale Administration schneller aktualisiert werden. Zudem sorgt der hierarchische Aufbau für die Einzigartigkeit der Hostnamen. Paul Mockapetris, der Verantwortliche für dieses Projekt, veröentlichte im Jahre 1984 die RFC (Request for Comments) 882 und 883. Diese RFCs beschrieben das DNS. 910 Ebenfalls wurden diese RFCs wurden durch die RFCs mit den Nummern 1034, 1035 erweitert bzw. verbessert Seitdem hat es zahlreiche Erweiterungen, Ergänzungen und Verbesserungen gegeben, die jeweils in eigenen RFCs speziziert wurden Nameserver und BIND Als Nameserver wird sowohl der Rechner, auf dem die Nameserver-Software läuft, als auch die Software, die die Namensauösung anbietet, bezeichnet. Ein Nameserver wird als autoritativ für eine Zone bezeichnet, falls diese Zone an ihn delegiert wurde. Eine Zone kann mehrere autoritative Nameserver haben. Der Nameserver, der die Zonendateien beinhaltet, wird als Primary Nameserver bezeichnet. Zur Ausfallvorbeugung und Lastverteilung werden meistens weitere Secondary Nameserver zur Zone hinzugefügt. Die Secondary Nameserver sind auch autoritativ für die Zone und erhalten die Zonendateien über Zonentransfer als Kopie von dem Primary oder anderen Secondary Nameservern. Anstelle von Primary und Secondary ndet man in der Praxis auch häug Master und Slave. Der Zonentransfer ist die Bezeichnung für die Übertragung von Zonendateien zwischen verschiedenen Servern. Je nach Konguration des Primary Nameservers wird der 9 Mockapetris, RFC 882 : DOMAIN NAMES - CONCEPTS and FACILITIES. 10 Mockapetris, RFC 883 : DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION. 11 Mockapetris, RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES. 12 Mockapetris, RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. 11

12 2.1. WAS IST DNS KAPITEL 2. DNS Zonentransfer inkrementell oder vollständig durchgeführt. Beim inkrementellen Zonentransfer werden nur die geänderten Zeilen der Zonen übertragen. Beim vollständigen Zonentransfer werden alle Dateien vollständig übertragen. Die meistverbreiteste Nameserversoftware ist die Open-Source-Software BIND(Berkeley Internet Name Domain). 13 Der Grund für diese hohe Verbreitung liegt darin, dass neu hinzugefügte RFCs über das Thema DNS zeitnah in BIND umgesetzt wurden. Es existieren Portierungen für alle gängigen Betriebssysteme und somit gibt es kaum Einschränkungen bei der Wahl des Betriebssystems. Die erforderlichen Dateien für den Nameserverbetrieb sind einerseits die Kongurationsdateien für BIND und andererseits die Zonendateien. BIND liefert eine Reihe von nützlichen Tools bei der Installation mit. Darunter bendet sich das Tool RNCD. Es ermöglicht die Administration von mehreren Nameserver parallel über die Kommandozeile. BIND bietet eine Vielfalt von Kongurationsmöglichkeiten für die Nameserver. Im Nachfolgenden ist eine Beispielkongurationsdatei (named.conf) für einen Primary Nameserver mit BIND: Internet Systems Consortium, BIND. 14 Liu und Albitz, DNS and BIND. 12

13 2.1. WAS IST DNS KAPITEL 2. DNS options { directory "/var/named"; allow-transfer { (Zonentransfer erlaubte IP-Adressen) // Weitere Optionen möglich; zone "(Verantwortliche Zone)" in { type master; file "(Zonendateiname)"; // Weitere Optionen für diese Zone möglich zone "(Verantwortliche Zone als IP-Adresse)" in { type master; file "(Zonendateiname)"; // Weitere Optionen für diese Reverse-Zone möglich zone " in-addr.arpa" in { type master; file "db "; zone "." in { type hint; file "db.cache"; Abbildung 2.5.: Beispiel einer Kongurationsdatei für einen Primary Nameserver Zuerst werden die allgemeinen Optionen angegeben, die für alle Zonen gelten. In unserem Beispiel wird zuerst das Verzeichnis angegeben, wo alle Dateien liegen, die für den "Name-Deamon" benötigt werden. Der Name-Deamon ist die Programminstanz, die den Nameserver simuliert. Nun folgen die Optionen für die Zonen. Die erste Zone beschreibt die zuständige Hauptzone, im Falle der RWTH ist es "rwth-aachen.de". Dann folgen Optionen zu dieser Zone. Die erste Zeile beschreibt type master;. Dies bedeutet, dass dieser Nameserver Master (oder Primary) für diese Zone ist und die Zonendatei zu dieser Zone auf diesem Server als Datei liegt. Falls der Typ Slave sein sollte, wird die Zonendatei per Zonentransfer 13

14 2.1. WAS IST DNS KAPITEL 2. DNS vom Master übertragen. Dann folgt die Zonendateiadresse und weitere mögliche Optionen. Nun folgen eventuell weitere zuständige Zonen. Nach den Forward-Zonen, also Zonen, in denen IP-Adressen zu Hostnamen eingetragen sind, folgen die Reverse-Zonen. In einer Reverse-Zone werden Reverse-Lookup-Einträge verwaltet, also Einträge, die einen Hostnamen zu einer IP-Adresse auösen. Ein Reverse-Lookup-Eintrag besteht aus einer umgekehrten IP-Adresse mit ".in-addr.arpa.äls Abschluss. Die Syntax der Reverse-Zone entspricht die der Forward-Zonen. Dann folgt die in-addr.arpa Zone. Diese verhindert, dass Maschinen, die nicht als Localhost deniert haben, ihre Daten im Netzwerk verteilen. Schlussendlich folgt die ". " Zone. Diese beschreibt die Root-Zone. Die Adressen der Root-Server werden in der zugewiesenen Zonendatei angegeben. Die IP-Adressen der Root-Nameserver sind fest kodiert und werden zusammen mit BIND in dieser speziellen Zonendatei bereitgestellt. Nun folgt eine Beispielkongurationsdatei für einen Secondary Nameserver mit BIND: Liu und Albitz, DNS and BIND. 14

15 2.1. WAS IST DNS KAPITEL 2. DNS options { directory "/var/named"; // Weitere Optionen möglich; zone "(Verantwortliche Zone)" in { type slave; file "(Zonendateiname)"; masters { (IP-Adresse des Primary(oder Master) Nameservers); // Weitere Optionen für diese Zone möglich zone "(Verantwortliche Zone als IP-Adresse)" in { type slave; file "(Zonendateiname)"; masters { (IP-Adresse des Primary(oder Master) Nameservers); // Weitere Optionen für diese Reverse-Zone möglich zone " in-addr.arpa" in { type master; file "db "; zone "." in { type hint; file "db.cache"; Abbildung 2.6.: Beispiel einer Kongurationsdatei für einen Secondary Nameserver Die Kongurationsdatei ist nahezu identisch mit der Kongurationsdatei für den Primary Nameserver. Die Unterschiede liegen darin, dass dieser Nameserver nicht mehr Master für die zuständigen Zonendateien ist. Diese Dateien müssen nun über Zonentransfer von dem Master Nameserver mit der angegebenen IP-Adresse übertragen werden. Es können mehrere IP-Adressen angegeben werden, damit für Ausfallsicherheit gesorgt wird. Die Dateien werden auf dem Secondary Nameserver zwischengespeichert, damit eine Kopie der Dateien vorhanden ist, falls alle Master Nameserver ausfallen sollten. 15

16 2.1. WAS IST DNS KAPITEL 2. DNS Eine Zonendatei wird durch Resource Records aufgebaut. Jeder Resource Record enthält eine Information. Die Zonendatei enthält alle Resource Records, die Informationen für diese Zone beinhalten. Die wichtigsten Typen von Resource Records sind: 1617 SOA Record: Beschreibt den Anfang einer autoritativen Zone und muss in jeder Zonendatei vorhanden sein. NS Record: Weist einer Zone einen Nameserver zu. A Record: Weist einem Domainnamen eine IPv4-Adresse zu. AAAA Record: Weist einem Domainnamen eine IPv6-Adresse zu. PTR Record: Weist einer IPv4 oder IPv6-Adresse einen Domainnamen zu. CNAME Record: Weist einem Domainnamen einen Alias zu. SRV Record: Weist einem Domainnamen einen Service zu. MX Record: Weist einer Zone einen server zu. 16 Mockapetris, RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES. 17 Mockapetris, RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. 16

17 2.1. WAS IST DNS KAPITEL 2. DNS $ORIGIN rwth-aachen.de. $TTL 2D ; in soa zs1.rz.rwth-aachen.de. hostmaster.rwth-aachen.de. ( ; Serial 12H ; refresh 2H ; retry (falls refresh nicht klappt) 504H ; expire (nicht mehr authorative nach dieser Zeit) 3H ; minimum (wird mit jedem RR-Record exportiert) ) in ptr in-addr.arpa. in ptr in-addr.arpa. in ptr in-addr.arpa. in ns zs1.rz in ns zs2.rz in ns deneb.dfn.de. in ns ws-was.win-ip.dfn.de. in mx 10 mx1.rz in mx 10 mx2.rz in naptr "s" "x-eduroam:radius.tls" "" _radsec._tcp.eduroam.de. ; ; END OF SOA PARAMETERS - don't delete this line makerev uses it ; ; ; GLUE RECORDS ANFANG zs1.rz.rwth-aachen.de. in a zs2.rz.rwth-aachen.de. in a ; GLUE RECORDS ENDE Abbildung 2.7.: Beispiel einer Produktivzonendatei im Falle der RWTH Aachen Verfügbarkeit Das DNS muss stets erreichbar sein, da zahlreiche Dienste von DNS abhängen und bei Ausfall ist der DNS-Dienst nicht mehr benutzbar. Beispiele für Dienste, die vom Ausfall des DNS betroen sind, sind und Browser. Um das Ziel der Hochverfügbarkeit zu erreichen, müssen bei hoher Belastung mehrere Nameserver gleichzeitig in Betrieb sein. Dies wird mit dem Prinzip von Primary und Secondary Nameservern erreicht. Diese 17

18 2.2. AUFBAU INNERHALB DES RZ DER RWTH AACHEN KAPITEL 2. DNS Nameserver laufen auf unterschiedlichen Maschinen und haben generell unterschiedliche IP-Adressen. Die Resolver auf den anfragenden Rechnern fragen meistens den erst kon- gurierten Nameserver und wechseln diesen nicht automatisch. Bei Linux und Apple OS Rechnern wird die Reihenfolge der Nameserver in /etc/resolv.conf festgelegt. Bei Windows Rechnern geschieht dies meist automatisch, indem eine Anfrage an den zuständigen DHCP-Server geschickt wird. Nun bevorzugt Windows standardmäÿig den Nameserver mit der niedrigeren IP-Adresse. Bei manchen Betriebssystemen wird beim Ausfall des ersten kongurierten Nameservers erst nach einem festgelegten Timeout der zweite kongurierte Nameserver gefragt. Sobald nun eine neue DNS-Anfrage gestartet wird, wird zuerst der erste Nameserver gefragt und nach einem Timeout erst der zweite Nameserver. Dadurch verlängert sich die Zeit bis zum Eintreen der Antwort des Nameservers erheblich und verlangsamt die Dienste, die den DNS-Dienst nutzen. Mehr dazu unter dem Punkt 3.3 Routing und Anycast Aufbau innerhalb des RZ der RWTH Aachen Zurzeit gibt es 2 Maschinen in der Zone des RZ der RWTH Aachen, die für den DNS- Dienst zuständig sind. Auf den 2 Maschinen laufen jeweils 2 Nameserverinstanzen. Diese sind einerseits ein Zonenserver, auf dem die Zonendateien verwaltet werden und andererseits ein Caching-Only-Nameserver, der die Anfragen beantwortet. Ein Caching-Only- Nameserver ist für keine Zone autoritativ und fragt aus diesen Grund einen zuständigen Nameserver. Sobald er die Antwort erhalten hat, speichert er diese zusammen mit der ursprünglichen Frage für die Lebenszeit (TTL) der Antwort in seinem Zwischenspeicher (Cache). Dadurch können zukünftige DNS-Anfragen mit der gleichen Frage aus dem Zwischenspeicher schneller beantwortet werden. Die Caching-Only-Nameserver haben die IP-Adressen und Diese beantworten nur DNS-Anfragen aus dem rwth-internen Netzbereich. Die Zonenserver haben die IP-Adressen und Diese beantworten DNS-Anfragen aus dem rwth-externen und auch internen Bereich. Für die Caching-Only-Nameserver und für die Zonenserver existieren 2 verschiedene Kongurationsdateien. Für jede Kongurationsdatei ist jeweils 1 Prozess zuständig. Ab BIND 9.0 gibt es die Möglichkeit, diese 2 Kongurationsdateien durch verschiedene Views in einer Kongurationsdatei zusammenzufassen. Views ist ein Mechanismus, bei dem für eine Gruppe von Hosts ein bestimmter Teil der Kongurationsdatei sichtbar 18

19 2.2. AUFBAU INNERHALB DES RZ DER RWTH AACHEN KAPITEL 2. DNS und für eine andere Gruppe von Hosts ein anderer Teil der Kongurationsdatei sichtbar ist. 18 Dadurch existiert nur noch ein Prozess pro Nameserver und Kongurationsdatei. Die gröÿte Zahl an DNS-Anfragen geht an den Nameserver mit der IP-Adresse , da dieser die niedrigste IP-Adresse besitzt (Windows) und ebenfalls an erster Stelle in der /etc/resolv.conf eingetragen ist (Linux und Apple OS). 18 Liu und Albitz, DNS and BIND, S

20 3. Konzept und Implementierungsvorschläge 3.1. Hardware Eine grundlegende Frage für die Installation eines neuen Nameservers ist die Frage, ob eine dedizierte Maschine oder eine virtuelle Maschine für den Nameserverbetrieb genutzt werden soll. Typischerweise gibt es nach aktuellen Stand bei entsprechender Einrichtung eines dedizierten Servers eine bessere Performance als bei einer virtuellen Maschine. Durch den parallelen Betrieb mehrerer virtueller Maschinen auf einer Maschine werden Ressourcen gespart. Durch die Beschränkung der Ressourcen kann es vorkommen, dass betriebskritische virtuelle Maschinen in der Performance eingegrenzt werden. Durch die benötigte Hochperformance der DNS-Nameserver werden häuger dedizierte Maschinen für den Nameserverbetrieb eingesetzt. Für die neuen Nameserver des RZ der RWTH Aachen werden 2 dedizierte Maschinen verwendet werden Betriebssystem und benötigte Software Die von dem RZ der RWTH Aachen verwendete DNS-Software ist BIND. Diese ist auf vielen Betriebssysteme portiert. Linux CentOS hat sich aufgrund seiner Stabilität und Ausrichtung auf Serversysteme im RZ der RWTH Aachen als Betriebssystem für kritische Dienste bereits bewährt und wird deshalb auch Verwendung nden. Die neuen DNS-Nameserver werden nur noch eine Kongurationsdatei für BIND benötigen. Diese Datei erhält den Namen named.conf und enthält eine externe sowie eine interne Ansicht. Die benötigte Option dafür sind Views. Diese wurden mit BIND 9.0 eingeführt. Dadurch fallen die 2 ursprünglichen Kongurationsdateien für den Zonenserver und dem Caching-Only-Nameserver weg. Es folgt eine Beispielkongurationsdatei mit verschiedenen Ansichten für den Primary Nameserver: 20

21 3.2. BETRIEBSSYSTEM UND BENÖTIGTE SOFTWARE options { view "internal" { KAPITEL 3. KONZEPT UND IMPLEMENTIERUNGSVOR- SCHLÄGE directory "/var/named"; allow-transfer { (Zonentransfer erlaubte IP-Adressen) // Weitere Optionen möglich; match-clients { (Interne IP-Adressen oder Netzbereiche); // Weitere Optionen für diese Ansicht möglich zone "(Verantwortliche Zone)" in { type master; file "(Zonendateiname)"; view "external" { // Weitere Zonenkonfigurationen möglich match-clients { any; recursion no; // Weitere Optionen für diese Ansicht möglich zone "(Verantwortliche Zone)" in { type master; file "(Zonendateiname)"; // Weitere Zonenkonfigurationen möglich Abbildung 3.1.: Beispiel einer Primary Nameserver Kongurationsdatei inklusive Views Die Namen der Views im der Kongurationsdatei sind frei wählbar. Zum besseren Verständnis der Kongurationsdatei werden sie häug internal und external benannt. Die Option match-clients gibt an, welche IP-Adressen und Netzbereiche zu der aktuellen View gehören. Die Zonenkongurationen bleiben wie in den ursprünglichen Kongurationsdateien ohne Views. Die externe Ansicht darf von jedem Client, der nicht zu den IP-Adressen oder Adressbereichen, die in den vorigen Views angegeben wurden, angesprochen werden. Durch die Option recursion no wird die Rekursion deaktiviert, da 21

22 KAPITEL 3. KONZEPT UND 3.3. ROUTING UND ANY- IMPLEMENTIERUNGSVOR- CAST SCHLÄGE externe Anfragen keine Last im Nameserver erzeugen sollen. 1 Für die Nutzung von IPv6-Adressen müssen keine weiteren Kongurationen durchgeführt werden, da die IPv6-Adressen zusammen mit den IPv4-Adressen eingetragen werden können. Für IPv6-Reverse-Lookup-Adressen muss jedoch eine neue Zonendatei erstellt werden. Der Name dieser Datei wird aus der umgekehrten IPv6-Adresse zusammen mit ip6.arpa. als Zusatz am Ende zusammengestellt Routing und Anycast Eine Alternativlösung für das in erklärte DNS-Client-Server-Problem ist Anycast. Anycast ermöglicht die Zuweisung von gleichen IP-Adressen an unterschiedliche Maschinen. Die Router, die auf dem Weg zwischen dem anfragenden Rechner und den Nameservern liegen, weisen dem anfragenden Rechner die kürzeste Route zum Nameserver zu, falls in der Routing-Domain ein entsprechendes dynamisches Protokoll genutzt wird. Mit geeigneter Position der Nameserver kann die Last auf die Nameserver gleichmäÿig verteilt werden. Das dynamische Protokoll OSPF (Open Shortest Path First) berechnet bei einer DNS- Anfrage den günstigsten Weg vom Client zum nächsten Nameserver durch den Dijkstra- Algorithmus. Die Software, die auf den Nameservern mit dem nächstgelegenen Routern kommuniziert, ist Quagga. Quagga besteht aus dem Zebra-Daemon, der für die Kommunikation zwischen Kernel und den Routingprozessen sorgt. Die Routingprozesse kommunizieren mit den Routingprotokollen, u.a. OSPF. Nun folgt ein Beispiel für das Anycast-Prinzip: 1 Liu und Albitz, DNS and BIND. 22

23 3.3. ROUTING UND ANY- CAST KAPITEL 3. KONZEPT UND IMPLEMENTIERUNGSVOR- SCHLÄGE Abbildung 3.2.: Erklärung des Anycast-Prinzips Die beiden Nameserver haben jeweils 2 eindeutige Management-IP-Adressen, die sich auf den Interfaces eth0 und eth1 benden. Auÿerdem haben die beiden Nameserver 4 IP-Adressen, die sich auf den Interfaces lo 0 bis 3 benden und auf beiden Nameservern identisch sind. Davon sind 2 für externe DNS-Anfragen und 2 für interne DNS-Anfragen zuständig. Der 1. Client wird nun durch das dynamische Routing durch OSPF mit dem nächstgelegenen intakten Nameserver verbunden. Dieser Client bendet sich im RWTH-internen Bereich und wird aus diesem Grund mit eine der beiden internen IP-Adressen des 1. Nameservers verbunden. Falls der 1. Client eine IPv4-Adresse besitzt, wird er mit der internen IPv4-Adresse des Nameservers verbunden. Falls der 1. Client eine IPv6-Adresse besitzt, wird er mit der IPv6-Adresse des Nameservers verbunden. Der 2. Client liegt auch im RWTH-internen Bereich und wird entweder mit der IPv4- oder mit der IPv6- Adresse des Nameservers verbunden. Falls der Client aus dem RWTH-externen Bereich eine Anfrage an den Nameserver 23

24 KAPITEL 3. KONZEPT UND 3.4. MONITORING IMPLEMENTIERUNGSVOR- SCHLÄGE schickt, wird er mit eine der externen IP-Adressen verbunden Monitoring Damit das DNS stets erreichbar ist, werden Primary und Secondary Nameserver betrieben, sowie auch redundante Systeme durch Anycast. Nun kann ein DNS-Nameserver zwar durch ein Ping erreichbar sein, aber der named-daemon, der für die DNS-Anfragen zuständig ist, kann defekt sein. Um dieses Problem zu erkennen, werden an der RWTH Aachen 2 Tools eingesetzt. Zum einen Nagios und zum anderen SmokePing. 23 Nagios ist eine Open-Source-Software, die zur Überwachung zahlreicher Hosts und Dienste genutzt wird. Nagios testet in einem regelmäÿigen Intervall mit einer festgelegten DNS-Anfrage ob der DNS-Nameserver noch korrekte Antworten zurückgibt. Im Falle des Nagios des RZ der RWTH Aachen wird nach yahoo.com alle 5 Minuten gefragt. Das Problem bei dieser Art der Überprüfung ist, dass der DNS-Nameserver standardmäÿig eine Antwort eine bestimmte Lebenszeit lang zwischenspeichert. Somit kann Nagios erst nach dem Ablauf dieser Lebenszeit feststellen, dass der DNS-Nameserver defekt ist. Eine Lösung für dieses Problem ist, nach einem FQDN zu fragen, der eine niedrige Lebenszeit besitzt. Eine niedrige Lebenszeit besitzen u.a. DynDNS-Domainnamen. DynDNS bedeutet, dass die IP-Adresse dieses FQDN dynamisch ist und ständig wechselt. 4 Zu Testzwecken wird nun im Nagios regelmäÿig nach hektor.is-a-geek.org. nachgefragt. Dieser FQDN besitzt eine Lebenszeit von 60 Sekunden. Damit wird nach 60 Sekunden spätestens festgestellt, dass der DNS-Nameserver defekt arbeitet. Ein anderes Programm zur Überwachung von Hosts und Diensten ist das OPen-Source- Programm SmokePing. SmokePing schlägt keinen Alarm, falls der DNS-Nameserver defekt arbeitet, sondern dokumentiert das Verhalten des DNS-Nameservers in Graphen. SmokePing fragt nach dem FQDN Dieser besitzt eine Lebenszeit von 60 Sekunden. Falls der DNS-Nameserver nicht mehr erreichbar sein sollte, muss eine Alarmmeldung an den DNS-Administrator geschickt werden und automatisch der Routing-Daemon ausgeschaltet werden. Somit können die Router durch OSPF eine Umleitung der DNS- Anfragen generieren. 2 Nagios Enterprises, Nagios. 3 Oetiker+Partner AG, SmokePing. 4 Vixie u. a., RFC 2136 : Dynamic Updates in the Domain Name System (DNS UPDATE). 24

25 4. Ausblick Um zukünftig den DNS-Dienst des RZ der RWTH Aachen gewährleisten zu können, werden 2 redundante Nameserver mit jeweils 8 IP-Adressen eingesetzt. Jede Maschine kann die andere im Ausfall ersetzen. Jeder Nameserver ist auf einer dedizierten Maschine eingerichtet und läuft auf dem Betriebssystem Linux CentOS. Für den Nameserverdienst wird BIND verwendet. Zur Überwachung der Nameserver werden die Programme Nagios und SmokePing eingesetzt, wobei Nagios Alarm schlägt, sobald ein Nameserver nicht mehr ordnungsgemäÿ funktioniert. 25

26 26

27 B. Abbildungsverzeichnis 2.1. Die Top Level Domains im DNS-Namensraum Die RWTH Domain inklusive einer Subdomain Der Beispielverlauf einer rekursiven Anfrage Beispiel einer Hosts.txt-Datei auf einem Windows-Rechner Beispiel einer Kongurationsdatei für einen Primary Nameserver Beispiel einer Kongurationsdatei für einen Secondary Nameserver Beispiel einer Produktivzonendatei im Falle der RWTH Aachen Beispiel einer Primary Nameserver Kongurationsdatei inklusive Views Erklärung des Anycast-Prinzips

28 C. Literatur [1] K. Harrenstien, M. Stahl und E. Feinler. RFC 952 : DOD INTERNET HOST TABLE SPECIFICATION. [Online; Stand 11. Dezember 2012] url: http: //tools.ietf.org/html/rfc952. [2] Internet Systems Consortium. BIND. [Online; Stand 14. Dezember 2012] url: [3] Cricket Liu und Paul Albitz. DNS and BIND. O'Reilly, [4] Paul Mockapetris. RFC 1034 : DOMAIN NAMES - CONCEPTS AND FACILI- TIES. [Online; Stand 11. Dezember 2012] url: html/rfc1034. [5] Paul Mockapetris. RFC 1035 : DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. [Online; Stand 11. Dezember 2012] url: ietf.org/html/rfc1035. [6] Paul Mockapetris. RFC 882 : DOMAIN NAMES - CONCEPTS and FACILITIES. [Online; Stand 11. Dezember 2012] url: rfc882. [7] Paul Mockapetris. RFC 883 : DOMAIN NAMES - IMPLEMENTATION and SPE- CIFICATION. [Online; Stand 11. Dezember 2012] url: ietf.org/html/rfc883. [8] Nagios Enterprises. Nagios. [Online; Stand 14. Dezember 2012] url: http: // [9] Oetiker+Partner AG. SmokePing. [Online; Stand 14. Dezember 2012] url: [10] P. Vixie u. a. RFC 2136 : Dynamic Updates in the Domain Name System (DNS UPDATE). [Online; Stand 11. Dezember 2012] url: org/html/rfc2136. [11] Wikipedia. Domain Name System Wikipedia, Die freie Enzyklopädie. [Online; Stand 14. Dezember 2012] url: php?title=domain_name_system&oldid=