16 DNS (Domain Name System)

Transkript

1 DNS (Domain Name System) Seite DNS (Domain Name System) 16 DNS (Domain Name System) Aufbau der Namen Installation eines caching-only-nameservers named.conf root.hint Zonendatei resolv.conf nsswitch.conf host.conf Starten des Servers und erste Anfragen DNS für die eigene Domäne Aufbau der DNS-Datenbank und ihrer Einträge Resource Records Ein Beispiel für Start of Authority in einer Zonendatei Resource Records für unsere Zone Reverse Lookup nslookup Aufgaben In Abschnitt wurde beschrieben, wie eine einfache Namensauflösung durch das Erweitern der Datei /etc/hosts erreicht werden kann. Bei größeren Netzwerken ist dieser Ansatz nicht praktikabel, da bei jeder Änderung alle hosts-dateien auf den angeschlossenen Computern aktualisiert werden müssten. Zur Umwandlung der Namen in IP-Adressen in größeren Netzwerken wird daher ein Nameserver eingerichtet. Ein Serverprogramm, das diesen Dienst erledigt, ist der Berkeley Internet Name Domain Service (BIND). Die Konfiguration von BIND kann problematisch sein. Sofern sie jedoch erfolgreich erledigt wurde, sind Änderungen der Netzwerkstruktur unproblematisch. Unter Linux wird der Name-Service von dem Programm named bereitgestellt Aufbau der Namen Computer im Internet kommunizieren über das Internet Protocol. In diesem Protokoll haben Computer keine Namen, sondern nur Nummern, die IP-Adressen. Da sich

2 DNS (Domain Name System) Seite 16-2 Menschen aber Namen besser merken können, müssen diese in IP-Adressen umgewandelt werden. Diese Aufgabe übernimmt der Resolver. Der Resolver sieht dazu in der Regel zuerst in der bereits bekannten Datei /etc/hosts nach (die es übrigens auch unter Windows gibt) und befragt dann den DNS (Bind). Die Namen der Computer sind baumartig aufgebaut. Ein vollständiger Name, zum Beispiel horst.bbst.clp, wird auch als fully qualified domain name (FQDN) bezeichnet. Der Domänenteil setzt sich dabei aus weiteren Bestandteilen zusammen. Ganz oben im Baum steht die Wurzel, die root, für die das Nullzeichen reserviert ist. Als nächstes folgt die Top-Level-Domain (TLD, jeweils immer durch einen Punkt getrennt). Dies sind zum Beispiel com, org, net oder auch de. Nach der Top-Level- Domain folgt die Second-Level-Domain (SLD). Dies ist in der Regel die Domäne, die man sich registriert hat. Es können nun fast beliebig viele Subdomains gebildet werden, wie linux.bbst.clp oder auch linux.ist.toll.bbst.clp. Wenn der Resolver versucht, eine Domain aufzulösen, also die entsprechende IP- Adresse zu diesem Namen zu ermitteln, passiert folgendes: Zunächst wird bei dem zuständigen Nameserver angefragt. Der Nameserver kennt die Adressen der Root-Nameserver. Diese kennen wieder die Nameserver, die für die angefragte Top-Level-Domain zuständig sind. Nun befragt unser Nameserver diesen Nameserver zur Second-Level-Domain. Er erhält wiederum einen anderen Nameserver genannt, der dann z.b. die Subdomain www zu einer IP-Adresse auflösen kann. Die Namensauflösung erfolgt also schrittweise, indem nacheinander die jeweils in der Baumstruktur tiefer stehenden Nameserver kontaktiert werden, bis die Adresse gefunden wurde Installation eines caching-only-nameservers Wir werden zunächst nur einen sehr einfachen Nameserver einrichten, der lediglich die Ergebnisse von Anfragen an andere Nameserver zwischenspeichert. Wichtig ist bei den praktischen Übungen in der Schule, dass eine TLD gewählt wird, die mit keiner existierenden TLD übereinstimmt. Es darf also zum Beispiel keinesfalls de, sondern nur zum Beispiel clp eingerichtet werden 1. 1 Erlaubt sind alle Zeichen des englischen Alphabets, alle Ziffern und der Bindestrich, sonst nichts!

3 DNS (Domain Name System) Seite 16-3 Bei allen folgenden Beispielen wähle ich als Domäne clp und der Name des Computers ist horst. Das kann bei Bedarf über YaST/Netzwerkdienste/DNS- und Hostname eingestellt werden. Ein solcher caching-only-nameserver wird auf Namensanfragen antworten und sich bei der nächsten Anfrage an die alte Antwort erinnern. Dieses Vorgehen verkürzt vor allem die Wartezeit bei jeder weiteren Anfrage. Bind wird, wie bei SuSE üblich, über YaST installiert und ist weitgehend vorkonfiguriert. Die folgende Grafik soll die Bedeutung der Konfigurationsdateien verdeutlichen: named.conf Zuerst wird die Datei /etc/named.conf editiert. Sie wird bei jedem Start vom named eingelesen. Fürs erste enthält diese Datei die Zeilen: // Konfigurationsdatei für einen caching-only Nameserver options { directory "/var/lib/named"; // Wenn Verbindungen über eine Firewall gehen müssen und das nicht // so funktioniert, wie es sollte, hilft es vielleicht, die folgende // Zeile auszukommentieren. // query-source port 53; }; zone "." in { type hint; file "root.hint"; }; zone "localhost" in { type master; file "localhost.zone"; }; zone " in-addr.arpa" in { type master; file " zone"; Zwischen Groß- und Kleinschreibung wird nicht unterschieden.

4 DNS (Domain Name System) Seite 16-4 }; Die directory-zeile sagt dem named, wo er nach Dateien suchen soll. Alle noch folgenden Dateien gehören also in dieses Verzeichnis (oder ein Unterverzeichnis davon) root.hint Die Datei /var/lib/named/root.hint ist ungefähr wie folgt aufgebaut: ; ; einführende Kommentare ;. 6D IN NS G.ROOT-SERVERS.NET.. 6D IN NS J.ROOT-SERVERS.NET.. 6D IN NS K.ROOT-SERVERS.NET.. 6D IN NS L.ROOT-SERVERS.NET.. 6D IN NS M.ROOT-SERVERS.NET.. 6D IN NS A.ROOT-SERVERS.NET.. 6D IN NS H.ROOT-SERVERS.NET.. 6D IN NS B.ROOT-SERVERS.NET.. 6D IN NS C.ROOT-SERVERS.NET.. 6D IN NS D.ROOT-SERVERS.NET.. 6D IN NS E.ROOT-SERVERS.NET.. 6D IN NS I.ROOT-SERVERS.NET.. 6D IN NS F.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 5w6d16h IN A J.ROOT-SERVERS.NET. 5w6d16h IN A K.ROOT-SERVERS.NET. 5w6d16h IN A L.ROOT-SERVERS.NET. 5w6d16h IN A M.ROOT-SERVERS.NET. 5w6d16h IN A A.ROOT-SERVERS.NET. 5w6d16h IN A H.ROOT-SERVERS.NET. 5w6d16h IN A B.ROOT-SERVERS.NET. 5w6d16h IN A C.ROOT-SERVERS.NET. 5w6d16h IN A D.ROOT-SERVERS.NET. 5w6d16h IN A E.ROOT-SERVERS.NET. 5w6d16h IN A I.ROOT-SERVERS.NET. 5w6d16h IN A F.ROOT-SERVERS.NET. 5w6d16h IN A Diese Datei enthält die Haupt-Nameserver (root-nameserver) des Internet. Diese ändern sich gelegentlich, so dass diese Datei regelmäßig aktualisiert werden muss 2. 2 In der deutschsprachigen DNS-Howto findet sich ein Shell-Script, das diese Datei monatlich aktualisiert.

5 DNS (Domain Name System) Seite Zonendatei In der Konfigurationsdatei des Nameservers /etc/named.conf wird eine Zone beschrieben ( ), die in einer Zonen-Datei /var/lib/named/ zone konfiguriert werden muss: $TTL IN SOA horst.clp. dnsmaster.horst.clp. ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS localhost 1 IN PTR localhost Diese Datei besteht aus drei Blöcken (RR, recource records). Die Abkürzung IN steht für Internet. SOA ist die Abkürzung für start of authority zu Deutsch Anfang der Zuständigkeit. Hier wird beschrieben, für welchen Teil einer Domäne unserer Nameserver eigentlich zuständig sein soll. Im Block NS (nameserver) wird angegeben, auf welchem Computer aus dieser Zone der Nameserver läuft. Im Abschnitt PTR (pointer) steht schließlich, wie der Computer mit der Adresse 1 heißen soll. Eine Übersicht über die verschiedenen recource records zeigt die folgende Tabelle: SOA Start Of Authority markiert den Anfang der Daten und Parameter einer Zone NS Name Server legt den Nameserver einer Domain fest A Address wandelt Hostnamen in Adresse um PTR Pointer wandelt Adresse in Hostnamen um MX Mail Exchange legt fest, wohin eine Mail für diese Adresse ausgeliefert CNAME Canonical Name werden soll definiert Alias für einen Hostname HINFO Host Information beschreibt Hardware und Betriebssystem des Hosts WKS Well-Known Service bietet Netzwerkdienste an TXT Text speichert beliebige Zeichenketten ab resolv.conf Der nächste Schritt ist eventuell die Erstellung oder Anpassung einer /etc/resolv.conf-datei (direkt mit Editor oder über YaST/Netzwerkdienste/DNS- und Hostname, Eintrag bei Domain-Suche):

6 DNS (Domain Name System) Seite 16-6 nameserver Die /etc/resolv.conf ist die Konfigurationsdatei des resolvers. Die search-zeile definiert die Suchreihenfolge der Domains, zu denen ein Rechner gehören könnte, der eine Anfrage an den named durchführt. Die nameserver-zeilen enthalten die Adressen vom eigenen und übergeordneten Nameservern. In unserem Beispiel ist das jeweils der eigene Computer, da hier ja auch der named eingerichtet wird. Eine kleine Beschreibung, was diese Datei bewirkt: Wenn ein Client-Programm versucht, einen Computer namens horst zu finden, dann wird zuerst nach horst.unterdomain.eigene-domain.de gesucht, anschließend nach horst.eigenedomain.de und erst zuletzt nach horst. Das bedeutet: Wenn versucht wird, den Rechner bbst-clp.de zu finden, wird zuerst nach bbst-clp.de.unterdomain.eigenedomain.de (nicht sinnvoll, aber so funktioniert es nun mal), dann nach bbstclp.de.eigene-domain.de und erst zuletzt nach bbst-clp.de gesucht. Aus diesem Grund sollte man auch nicht zu viele Domains in die search-zeile schreiben, da es sonst sehr lange dauern kann bis alle durchsucht wurden. Das Beispiel geht davon aus, dass man zu der Domain unterdomain.eigenedomain.de gehört. Der eigene Rechner wird dann vermutlich eigener- Rechner.unterdomain.eigene-domain.de heißen. Den aktuellen Namen des Rechners und die Domäne findet man in YaST/Netzwerkdienste/DNS und Hostnamen. Auf keinen Fall sollte die search-zeile die eigene externe TLD (Top Level Domain, in unserem Fall de) enthalten. Wenn man regelmäßig Verbindungen zu Computern in anderen Domains aufbaut, dann wird diese wie folgt zusätzlich eingetragen: search unterdomain.eigene-domain.de eigene-domain.de andere-domain.com Und so weiter. Natürlich sollten existierende Domainnamen anstelle der hier nur ausgedachten benutzt werden. Außerdem sollte man darauf achten, dass am Ende der Domainnamen keine Punkte stehen! nsswitch.conf Der nächste Schritt ist die Anpassung von /etc/nsswitch.conf. In dieser etwas längeren Datei wird eingestellt, aus welcher Datei oder Datenbank Daten zu einem bestimmten Dienst geholt werden. Sie enthält normalerweise gleich am Anfang sehr

7 DNS (Domain Name System) Seite 16-7 hilfreiche Kommentare, die gelesen werden sollten. Die mit hosts: beginnende Zeile sollte ungefähr wie folgt lauten: hosts: files dns networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files nis aliases: files Wenn es noch keine Zeile mit hosts: am Anfang gibt, dann wird die oben gezeigte einfach hinzugefügt. Die Zeile besagt, dass Programme zuerst in der /etc/hosts-datei nachschauen sollen und erst dann das DNS nach den Vorgaben in der /etc/resolv.conf zur Aufschlüsselung von Rechnernamen genutzt wird host.conf Diese Datei (nicht zu verwechseln mit /etc/hosts) enthält vermutlich mehrere Zeilen. Eine davon lautet: order hosts,bind Wenn es keine order-zeile gibt, wird sie hinzugefügt. Sie bewirkt, dass die Routinen, die die Computernamen aufschlüsseln, zuerst in der /etc/hosts nachschauen und dann beim Nameserver anfragen, der laut /etc/resolv.conf der Rechner mit der IP ist Starten des Servers und erste Anfragen Der Name-Server wird jetzt mittels rcnamed start gestartet. Bei Problemen lohnt sich in der Regel ein Blick in das Systemlogbuch. Wenn alles läuft, ist jetzt der Zeitpunkt gekommen, die Einstellungen zu testen. Hierzu verwenden wir den Befehl nslookup 3 : Zuerst wollen wir die IP zur Adresse bbst-clp.de ermitteln: 3 Die Warnmeldung bedeutet, dass der Befehl nslookup künftig durch die Befehle host und dig ersetzt wird.

8 DNS (Domain Name System) Seite 16-8 # nslookup > bbst-clp.de Server: localhost Address: #53 Name: bbst-clp.de Address: nslookup hat jetzt den gerade konfigurierten named nach dem Rechner bbst-clp.de gefragt. Um darauf antworten zu können, fragt dieser einen der Nameserver aus der root.hints-datei und bahnt sich von dort aus seinen Weg zum vollen Namen des Rechners. Vielleicht dauert es ein wenig, bis das Ergebnis gezeigt wird, weil zuerst alle Domains aus der /etc/resolv.conf durchsucht werden. Wiederholt man die Anfrage, bekommt man dieses Ausgabe: > bbst-clp.de Server: localhost Address: #53 Non-authoritative answer: Name: bbst-clp.de Address: Man beachte die Non-authoritative answer:-zeile, die dieses mal zusätzlich erscheint. Sie bedeutet, dass der named dieses Mal nicht im Netz nachgefragt hat, sondern dass die Informationen aus seinem Cache stammen. Diese Meldung erscheint aber auch immer dann, wenn irgendein Zwischenspeicher (zum Beispiel ein anderes DNS) die Anfrage beantwortet hat. Durch die Non-authoritative answer: wird man über die (sehr kleine) Möglichkeit informiert, dass diese zwischengespeicherten Daten eventuell nicht mehr aktuell sind. Wenn nslookup diese Zeile bei der zweiten Anfrage ausgibt, ist das ein sicheres Zeichen dafür, dass die Daten zwischengespeichert werden und dass der named wie gewünscht funktioniert. Eine umgekehrte Anfrage, also der Name zu einer IP, ist ebenfalls mit nslookup möglich. Wird eine ausführlichere Antwort benötigt, so setzt man vor der Eingabe die Anfrage-Variable (querytype): set q = any Bei allen jetzt folgenden Anfragen wird zusätzlich der Name der zuständigen Nameserver ausgegeben. nslookup wird mit dem Befehl exit beendet. Mit dem host- Befehl wird ebenfalls die IP zu einem Namen ermittelt: #host bbst-clp.de

9 DNS (Domain Name System) Seite 16-9 ergibt zum Beispiel: Diese Information ist ebenfalls mit dem dig-befehl zu beschaffen, wobei dann allerdings zusätzliche Informationen des befragten DNS-Servers ausgegeben werden DNS für die eigene Domäne In diesem Abschnitt wollen wir ein richtiges DNS für eine Domäne einrichten. Zunächst müssen wir den Begriff Zone einführen. Dieser Begriff wird häufig mit Domäne verwechselt. Auf den Punkt gebracht: Eine Zone ist das, für das ein DNS- Server authoritativ (also zuständig ) ist. Ein DNS-Server ist immer für eine oder mehrere Zones zuständig (nämlich die, die zu ihm delegiert wurden). Umgekehrt gibt es zu jeder Zone einen DNS-Server, der für diese autoritativ ist. Sehr große Zonen werden weiter unterteilt (Subzonen) und dann von mehreren DNS versorgt Aufbau der DNS-Datenbank und ihrer Einträge Eine DNS-Datenbank besteht aus zwei wichtigen Typen von Einträgen: Zuordnung von Namen zu Adressen (Addressrecords "A"), und die Umkehrung, also Einträge, die einer Adresse einen Namen zuordnen (Reverserecords "PTR"). Darüber hinaus gibt es noch weitere Einträge. Diese Einträge liegen in einer Zone, die von einem Namensserver authoritativ verwaltet werden. Die Einträge in die Datenbank nennt man Resource Record, kurz RR. Neben Namen und IP-Adressen gibt es einen RR (also "Typ") für die Eigenschaften einer Zone. Es gibt RRs, die Textinformationen beinhalten, die geographische Position festlegen und weitere. Die DNS-Datenbank ist also eine verteilte Datenbank, die in Zonen unterteilt ist. Diese Zonen werden von DNS-Servern bedient. Eine Zone besteht aus Einträgen, die man Resource Records nennt. Der DNS-Server bestimmt auch einige Eigenschaften der Zone selbst, zum Beispiel wie lange die Zone zwischengespeichert werden darf. Diese Daten liegen in einem ganz speziellen

10 DNS (Domain Name System) Seite Record, dem Start of Authority, kurz SOA. Dieser legt den Beginn und die Eigenschaften einer Zone fest Resource Records Ein Record besteht aus mehreren Teilen: dem Objekt (Schlüsselfeld), der TTL (Time to live, die maximale Zeit, die es zwischengespeichert werden darf. Typisch sind Werte zwischen 3 und 8 Stunden), der Klasse, zu der der Record gehört, der Typ des Records (z.b. "A" für eine Namen-Address-Zuordnung) und dem Inhalt. Die Klasse gibt an, zu welcher Netzwerkarte der Name gehört. Das Internet heißt IN, das ist praktisch allen Fällen die verwendete Klasse. Der Typ wurde schon erwähnt: Es gibt Namen, Adressen, Texte (die wichtige Zusatzinformationen enthalten können), Aliasnamen, Hostinformationen, Mailserver und andere. Einige davon gibt es praktisch fast nur "auf dem Papier" Ein Beispiel für Start of Authority in einer Zonendatei Die folgende Datei ist eine Beispieldatei, an der lediglich der Aufbau der Zonendatei erklärt wird. Sie ist für die praktische Übung nicht erforderlich! Die Zonen-Datei /var/lib/named/eigene-domain.clp für unsere Domäne eigenedomain.clp. (wenn der volle Name gemeint ist, dann muss ein Punkt angehängt werden!) könnte so aussehen (nur der SOA RR; Kommentare werden durch ein Semikolon abgetrennt): eigene-domain.clp. IN SOA ns.eigene-domain.clp. admin.eigene-domain.clp. ( ; Serial (Seriennummer) ; Refresh (Aktualisierung) 3 Stunden 3600 ; Retry (neuer Versuch) ; Expire (ungültig nach 10 Tagen) ) ; min. TTL (Mindestgültigkeit) 1 Tag Das Objekt ist die Zone. Es gehört zur Klasse Internet, und es handelt sich um eine Zone, genauer gesagt, um den Start einer Autorität. Jetzt folgen die Informationen über die SOA:

11 DNS (Domain Name System) Seite Der Name des primären Nameservers (Ursprungsserver) Eine adresse, falls jemand mal eine Frage oder einen Hinweis hat. Hier wird anstatt des Zeichens ein "." verwendet (deswegen darf eine Mailadresse im ersten Teil auch keinen Punkt enthalten!) Dann in Klammern: Eine Seriennummer der Zonenversion, an der andere DNS erkennen, ob sich etwas geändert hat Informationen, wann die Secondaries diese Zonendaten aktualisieren sollen (refresh) Wie lange sie warten sollen, wenn das nicht klappt (retry) Nach welcher Zeit die Daten definitiv ungültig sind (expire) Wie lange ein RR mindestens gültig ist (min. TTL). Die Zeiten werden entweder in Sekunden angegeben oder es wird die Endung D, H, W für Tage, Stunden beziehungsweise Wochen angehängt. Da sich die Seriennummer stets erhöhen muss, hat es sich bewährt, das aktuelle Datum im Format JJJJMMTT und eine zweistellige tägliche laufende Nummer zu verwenden. So erkennt man auch gleich, wann die Zone zum letzten Mal verändert wurde. Diese Angaben eigentlich nur dann wichtig, wenn ein Slave-DNS auf unseren Server zugreift Resource Records für unsere Zone Wir erweitern jetzt den caching-only Nameserver aus Abschnitt 17.2, um eine Namensauflösung für unsere Domäne mit dem Namen clp umzusetzen. Zunächst erweitern wir /etc/named.conf um zwei neue Zonen: zone "clp" in { type master; file "clp.zone"; }; zone "0.10.in-addr.arpa" in { type master; file "10.0.zone"; }; Schließlich muss die Konfigurationsdatei des Resolvers (/etc/resolv.conf) angepasst werden, da ja jetzt auch in der Domäne clp gesucht werden soll:

12 DNS (Domain Name System) Seite nameserver search clp Jetzt müssen wir für unsere Zone noch eine entsprechende Zonen-Datei definieren: /var/lib/named/clp.zone clp. IN SOA horst.clp. root.horst.clp. ( 42 ; serial 60 ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum clp. IN NS horst.clp. horst.clp. IN A max.clp. IN A moritz IN A felix IN A Zunächst wird festgelegt, wofür der DNS-Server zuständig ist, hier: clp. Dann kommt der Name des primären Master-Nameservers, hier: horst.clp. Schließlich kommt noch eine Mailadresse für die Systemmeldungen von DNS-Server. Dazu muss der erste Punkt durch ersetzt werden, hier ist das also root@horst.clp. In den unteren Zeilen werden die Einträge für die Domänen-Mitglieder festgelegt. Zum Beispiel wird dem Computer mit der IP der Name max zugeordnet. Das muss nicht unbedingt stimmen, aber unser DNS-Server wird das auf Anfrage so behaupten! Der steht für den lokalen Computer. Die Zonendatei kann also auch so geschrieben IN root ( 42 ; serial.... IN NS horst.clp..... Die Zeile mit der TTL-Angabe (time to live) kann weggelassen werden. Es wird dann ein default-wert eingesetzt. Wenn vor dem IN NS-Eintrag nichts steht, wird der letzte Eintrag übernommen. In unserem Fall wird das clp. also automatisch vor IN NS gesetzt. Ein typischer Fehler bei der Erstellung dieser Dateien ist das Weglassen des Punktes nach den Hostnamen! Außerdem muss der Name-Server, der in den

13 DNS (Domain Name System) Seite Zonendateien benannt wird, auch tatsächlich einen gültigen A-Record haben! Ein Alias-Eintrag für den Nameserver ist im SOA-Eintrag nicht zulässig Reverse Lookup Jetzt fehlt nur noch die Namesauflösung in der anderen Richtung, also die Zuordnung eines Namens zu einer IP: IN root.horst.clp. ( 42 ; serial 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS horst.clp IN PTR horst.clp IN PTR max.clp IN PTR moritz Da unser Subnetz die Maske 16 hat, also die beiden letzten Zahlen den Computer identifizieren, müssen hier jeweils die vollständigen Hostanteile eingetragen werden. Bei einem Subnetz mit anderer Maske muss das dann entsprechend angepasst werden. Die Funktion unseres Servers kann ebenfalls mit nslookup getestet werden nslookup Der Befehl nslookup erlaubt Anfragen in zwei verschiedenen Modi: entweder interaktiv, wenn kein Argument übergeben wurde nslookup oder nicht-interaktiv, wenn mit dem Befehl ein Rechnername und optional ein Nameserver übergeben wurde. nslookup horst Bei interaktivem Modus kann mittels set-befehl das Ergebnis der Anfragen beeinflusst werden:

14 DNS (Domain Name System) Seite all ls type Ausgabe aller aktuellen Einstellungen Informationen über die Domäne (-a gibt die Aliasnamen, -h die Hardwareinformationen und -d den gesamten Inhalt des Zonentransfers aus.) Informationstyp, der zurückgegeben werden soll: A Internet-Adresse ANY alle verfügbaren Informationen HINFO CPU und Betriebssystemtyp MD Ziel einer SOA Kontaktinformationen einer Zone TXT Text-Informationen Das Programm nslookup wird nicht weiter gepflegt. Es sollte aus Sicherheitsgründen auch nicht mehr benutzt werden. Die Nachfolge-Programme sind host für einfache und dig für Abfragen, die zusätzliche Informationen liefern sollen Aufgaben 1. Was passiert, wenn einer IP in einer Zonendatei mehrere Namen zugewiesen werden? Für welche Anwendungssituationen ist das sinnvoll? 2. Was passiert, wenn einem Namen eine nicht existierende IP zugewiesen wird? 3. Ist es möglich, einem Namen eine IP zuzuordnen, in der Zonendatei für den reverse-lookup dieser IP aber einen anderen Namen zuzuordnen? 4. Welchen Effekt haben Leerzeichen in der Zonendatei: a) vor einer Adresse, b) vor einem IN A record, c) hinter einer IP. 5. Wie kann man sich (mit nslookup) den gesamten Inhalt einer Zonendatei auflisten lassen (und diesen dann in eine Datei übertragen)? 6. Erweitere die Zonendatei um einen sinnvollen Eintrag mit dem resource record CNAME.