  DNS HOWTO
  Nicolai Langfeldt (janl@math.uio.no) und 
  Thomas Balu Walter (dlhp@b-a-l-u.de)
  v2.2, 18. September 2000

  Dieses Dokument beschreibt, wie man mit wenig Aufwand ein DNS-Adminis
  trator wird.


  1.  Vorwort

  1.1.  Copyrightinformationen

  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright fr die
  englische DNS HOWTO, auf der dieses Dokument basiert, liegt bei
  Nikolai Langfeldt. Das Copyright fr die deutsche Version liegt bei
  Thomas Balu Walter.


  Das Dokument darf gemss der GNU General Public License verbreitet
  werden. Insbesondere bedeutet dieses, dass der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyrighthinweis
  nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt und
  ausdrcklich erwnscht. Bei einer Publikation in Papierform ist das
  Deutsche Linux HOWTO Projekt hierber zu informieren.


  1.2.  Danksagungen und die Bitte um Hilfe

  Ich mchte mich hier vor allem bei Nikolai Langfeldt bedanken, ohne
  dessen Version dieser Text niemals mglich gewesen wre.


  Dieser Text wird immer unvollstndig bleiben. Sollten Probleme oder
  Fragen beim Durcharbeiten dieses Textes auftreten, schreibt mir bitte.
  Dadurch helft Ihr mir diese HOWTO zu verbessern. Also schickt
  Vorschlge, Kommentare, Kritik, Pizza, Geld und/oder Fragen an mich.
  Sollten Eure Anregungen auch das englische Original betreffen, werde
  ich Nikolai darber informieren. Die bersetzung bringt es mit sich,
  dass einige Stze holprig oder unverstndlich klingen - wenn etwas
  berhaupt keinen Sinn macht, schreibt mir das bitte.


  Wenn Ihr Antwort von mir wollt, achtet bitte darauf, dass der Absender
  in Eurer E-Mail korrekt eingetragen ist. Ich bekomme sehr viele E-
  Mails.  Bitte lest auch den Abschnitt ``FAQ'', bevor Ihr mir schreibt.
  Achso - ich verstehe nur die deutsche und die englische Sprache.


  Sollte diese HOWTO in noch andere Sprachen bersetzt werden, wrde ich
  gerne davon erfahren, damit ich eine bersicht darber bekomme, in
  welchen Lndern meine Texte verbreitet werden :-) - auerdem kann ich
  Euch dann eine Nachricht zukommen lassen, wenn nderungen an der HOWTO
  gemacht wurden.


  So - jetzt lasse ich Nikolai nochmal zu Wort kommen:


       I want to thank Arnt Gulbrandsen whom I cause to suffer
       through the drafts to this work and whom provided many use
       ful suggestions.  I also want to thank the numerous people
       that have e-mailed suggestions and notes.



  1.3.  Widmung

  Hier noch eine Widmung von Nikolai - und dann geht's ab ins DNS-
  Getmmel:


       This HOWTO is dedicated to Anne Line Norheim Langfeldt.
       Though she will probably never read it since she's not that
       kind of girl.



  2.  Einleitung

  Worum es geht - und worum nicht.



  DNS steht fr Domain Name System. Das DNS wandelt einen Rechnernamen
  in die jeweils zugeordnete IP-Adresse um, die jeder Computer im Netz
  braucht.  Es wandelt Namen in IP-Adressen und umgekehrt und kann sogar
  noch ein wenig mehr. Diese HOWTO beschreibt, wie man einen DNS-Server
  auf einem Linuxsystem einrichtet und verwaltet.


  DNS ist fr den unerfahrenen Benutzer (Dich ;-)) eines der
  undurchsichtigeren Gebiete der Netzwerkadministration. Diese HOWTO
  versucht, alles etwas durchschaubarer zu machen. Sie beschreibt, wie
  ein einfacher DNS-Server aufgebaut wird. Zu Anfang wird ein caching-
  only Server eingerichtet, der dann zu einem primren DNS-Server fr
  eine Domain ausgebaut wird. Um kompliziertere DNS-Server einzurichten,
  sollte man einen Blick in den Abschnitt ``Fragen und Antworten''
  werfen. Falls das Problem dort nicht beschrieben wird, bleibt einem
  nichts anderes brig, als die original Dokumentation zu lesen. Im
  Abschnitt ``Wie man ein besserer DNS-Administrator wird'' habe ich
  aufgelistet, woraus die echte Dokumentation besteht und wo man sie
  finden kann.


  Bevor es nun endgltig losgeht, sollte der Computer so eingerichtet
  sein, dass man z.B. mit telnet Verbindungen zum und vom Rechner
  aufbauen kann und dass auch andere Netzwerkverbindungen funktionieren.
  Wichtig ist, dass ein



       telnet 127.0.0.1




  eine Verbindung zum eigenen Rechner aufbaut, was man jetzt testen
  sollte.  Als Ausgangspunkt braucht man ausserdem richtig konfigurierte
  /etc/nsswitch.conf- (bzw. /etc/host.conf), /etc/resolv.conf- und
  /etc/hosts-Dateien; da ich deren Funktion hier nicht erklren werde,
  empfehle ich die NET-3 HOWTO und/oder die PPP HOWTO, in denen
  beschrieben wird, was dort eingestellt werden muss.


  Wenn ich von dem eigenen Rechner spreche, meine ich den Computer,
  auf dem versucht wird, den Nameserver einzurichten und keinen anderen,
  der sich vielleicht im Netzwerk befindet.


  Ausserdem gehe ich davon aus, dass der Rechner nicht hinter
  irgendeinem Firewall hngt, der eventuell Nameserveranfragen
  verhindert. In diesem Fall braucht man eine spezielle Konfiguration,
  die im Abschnitt ``Fragen und Antworten'' beschrieben wird.


  Der Nameservice wird unter UNIX von einem Programm namens named
  bewerkstelligt. Dieses Programm ist Teil des bind-Paketes, das von
  Paul Vixie fr das Internet Software Consortium verwaltet wird. named
  ist in den meisten Linux-Distributionen enthalten und wird
  blicherweise als /usr/sbin/named installiert. Wenn bereits ein named
  vorhanden ist, kann er vermutlich auch genutzt werden; falls nicht,
  kann man ein Binrpaket von einem Linux-FTP-Server bekommen oder man
  holt sich den aktuellsten Source-Code von:

       ftp.isc.org:/isc/bind/src/cur/bind-8/


  Diese HOWTO beschreibt bind in der Version 8. Die alte Version fr
  bind Version 4 ist nicht ins Deutsche bersetzt worden - die englische
  Version ist unter

       http://www.math.uio.no/~janl/DNS/


  zu finden. Wenn in der Manual Page zum named (man named) am Ende im
  FILES-Abschnitt eine Datei namens named.conf aufgelistet wird, ist
  bind 8 installiert. Wenn es sich um die Datei named.boot handelt, ist
  es bind 4. Wenn nur bind 4 installiert wurde und man sich Gedanken
  ber die Sicherheit seines Computers macht - das sollte jeder -,
  sollte man auf jeden Fall auf bind 8 updaten.


  Das DNS ist eine netzweite Datenbank. Man sollte darauf achten, womit
  man sie fttert. Wenn man sie mit Mll fllt bekommt man selbst - und
  andere auch - nur Mll von ihr geliefert. Wer das eigene DNS
  ordentlich pflegt, wird von ihm auch sinnvolle Daten erhalten. Jeder,
  der lernt, das DNS zu benutzen, zu verwalten und Fehler zu beheben,
  darf sich in die Riege der guten Systemadministratoren aufgenommen
  fhlen und hilft dabei, das Netz vor einem Zusammenbruch zu bewahren.


  In diesem Dokument werde ich gelegentlich ein paar Dinge behaupten,
  die nicht unbedingt der Wahrheit entsprechen - obwohl sie mindestens
  die halbe Wahrheit darstellen -, um es etwas einfacher zu machen.
  Alles sollte funktionieren, wenn man meinen Ausfhrungen glaubt.


  Von allen bereits existierenden Dateien, die im Laufe dieses Textes
  gendert werden, sollten Sicherheitskopien erstellt werden, um im
  Notfall wieder zur alten - funktionierenden - Konfiguration
  zurckkehren zu knnen.


  3.  Ein caching-only-Nameserver

  Ein erster Ausblick auf die DNS-Konfiguration - sehr praktisch fr
  Benutzer, die sich ins Internet einwhlen.


  Ein caching-only Nameserver (ich werde den englischen Begriff
  weiterverwenden, weil sich nur-Zwischenspeicher nicht besonders
  schn anhrt) wird auf Namensanfragen antworten und sich bei der
  nchsten Anfrage an die alte Antwort erinnern. Dieses Vorgehen
  verkrzt vor allem die Wartezeit bei jeder weiteren Anfrage -
  besonders, wenn man nur eine langsame Verbindung hat.


  Zuerst wird eine Datei namens /etc/named.conf gebraucht. Sie wird bei
  jedem Start vom named eingelesen. Erstmal sollte sie einfach nur das
  folgende enthalten:















  // Konfigurationsdatei fr einen caching-only Nameserver

  options {
          directory "/var/named";

          // Wenn Verbindungen ber eine Firewall gehen mssen und das nicht
          // so funktioniert, wie es sollte, hilft es vielleicht, die folgende
          // Zeile auszukommentieren.

          // query-source port 53;
  };

  zone "." {
          type hint;
          file "root.hints";
  };

  zone "0.0.127.in-addr.arpa" {
          type master;
          file "pz/127.0.0";
  };





  Die directory-Zeile sagt dem named, wo er nach Dateien suchen soll.
  Alle noch folgenden Dateien gehren in dieses Verzeichnis (oder einem
  Unterverzeichnis relativ hierzu). Also ist pz ein Unterverzeichnis in
  /var/named: /var/named/pz. /var/named ist nach dem Linux File system
  Standard das fr den Nameserver vorgesehene Verzeichnis fr die
  Konfigurationsdateien eines Nameservers.


  Die Datei /var/named/root.hints sollte die folgenden Daten beinhalten:































  ;
  ; Wenn diese Datei bereits existiert, knnten hier
  ; einfhrende Kommentare stehen.
  ; Falls nicht - keine Panik ;-).
  ;
  .                     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    192.112.36.4
  J.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.10
  K.ROOT-SERVERS.NET.     5w6d16h IN A    193.0.14.129
  L.ROOT-SERVERS.NET.     5w6d16h IN A    198.32.64.12
  M.ROOT-SERVERS.NET.     5w6d16h IN A    202.12.27.33
  A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
  H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
  B.ROOT-SERVERS.NET.     5w6d16h IN A    128.9.0.107
  C.ROOT-SERVERS.NET.     5w6d16h IN A    192.33.4.12
  D.ROOT-SERVERS.NET.     5w6d16h IN A    128.8.10.90
  E.ROOT-SERVERS.NET.     5w6d16h IN A    192.203.230.10
  I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17
  F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241





  Diese Datei enthlt die Hauptnameserver des Internet; auch Root-
  Nameserver genannt. Da sich diese Daten gelegentlich ndern, muss sie
  regelmssig erneuert werden. Mehr darber gibt es im Abschnitt
  ``Wartung''.


  Der nchste zu erklrende Abschnitt in der named.conf-Datei ist die
  letzte Zone. Darauf werde ich aber erst spter zurckkommen. Erstmal
  wird jetzt eine Datei namens 127.0.0 im Unterverzeichnis pz erstellt:



       @               IN      SOA     ns.linux.test. hostmaster.linux.test. (
                                       1       ; Serial
                                       8H      ; Refresh
                                       2H      ; Retry
                                       1W      ; Expire
                                       1D)     ; Minimum TTL
                               NS      ns.linux.test.
       1                       PTR     localhost.





  Der nchste Schritt ist die Erstellung einer /etc/resolv.conf-Datei,
  die so aussehen sollte:


       search unterdomain.eigene-domain.de eigene-domain.de
       nameserver 127.0.0.1





  Die search-Zeile definiert die Suchreihenfolge der Domains, zu denen
  ein Rechner gehren knnte, der eine Anfrage an den named durchfhrt.
  Die nameserver-Zeile enthlt die Adresse vom eigenen Nameserver. In
  diesem Fall ist das der eigene Computer, da dass der Rechner sein
  wird, auf dem der named eingerichtet wird (127.0.0.1 ist richtig, ganz
  egal, was die Maschine sonst noch fr Adressen hat). Wenn man mehrere
  Nameserver auflisten mchte, macht man das, indem fr jeden Server
  eine eigene nameserver-Zeile eingefgt wird.  Der named selber wird
  diese Datei nie einlesen, sondern der resolver. Das ist ein Programm,
  welches die Anfragen an den named durchfhrt.


  Eine kleine Beschreibung, was diese Datei bewirkt: Wenn ein Client-
  Programm versucht, einen Computer namens bla zu finden, dann wird
  zuerst nach bla.unterdomain.eigene-domain.de gesucht, anschliessend
  nach bla.eigene-domain.de und erst zuletzt nach bla.  Wenn versucht
  wird, den Rechner sunsite.unc.edu zu finden, wird zuerst nach
  sunsite.unc.edu.unterdomain.eigene-domain.de (ja - das ist nicht
  sinnvoll, aber so funktioniert es nunmal...), dann nach
  sunsite.unc.edu.eigene-domain.de und erst zuletzt nach sunsite.unc.edu
  gesucht. Aus diesem Grund sollte man nicht zu viele Domains in die
  search-Zeile schreiben, da es lange dauern kann bis alle durchsucht
  wurden.


  Das Beispiel geht davon aus, dass man zu der Domain
  unterdomain.eigene-domain.de gehrt. Der eigene Rechner wird dann
  vermutlich eigener-Rechner.unterdomain.eigene-domain.de heissen. Auf
  keinen Fall sollte die search-Zeile die eigene TLD (Top Level Domain,
  in diesem Fall de) enthalten. Wenn man regelmssig Verbindungen zu
  Computern in anderen Domains aufbaut, dann wird diese wie folgt
  zustzlich eingetragen:



       search unterdomain.eigene-domain.de eigene-domain.de andere-domain.com




  Und so weiter. Natrlich sollten existierende Domainnamen anstelle
  meiner ausgedachten benutzt werden. Ausserdem sollte man darauf
  achten, dass am Ende der Domainnamen keine Punkte stehen - wieso das
  wichtig ist, wird spter erklrt.


  Der nchste Schritt hngt von der verwendeten libc-Version ab.
  Entweder muss man die Datei /etc/nsswitch.conf oder die Datei
  /etc/host.conf anpassen. Wenn bereits eine nsswitch.conf existiert,
  muss diese gendert werden - falls nicht, passt man die host.conf an.


  /etc/nsswitch.conf


  In dieser etwas lngeren Datei wird eingestellt, aus welcher Datei
  oder Datenbank Daten zu einem bestimmten Dienst geholt werden. Sie
  enthlt normalerweise gleich am Anfang sehr hilfreiche Kommentare, die
  gelesen werden sollten. Die mit hosts: beginnende Zeile sollte wie
  folgt lauten:



       hosts:      files dns




  Wenn es noch keine Zeile mit hosts: am Anfang gibt, dann wird die
  oben gezeigte einfach hinzugefgt. Die Zeile besagt, dass Programme
  zuerst in der /etc/hosts-Datei nachschauen sollen und erst dann das
  DNS nach den Vorgaben in der resolv.conf zur Aufschlsselung von
  Rechnernamen genutzt wird.


  /etc/host.conf


  Diese Datei enthlt vermutlich mehrere Zeilen. Eine davon msste mit
  order beginnen und sollte wie die folgende aussehen:



       order hosts,bind





  Wenn es keine order-Zeile gibt, wird sie hinzugefgt. Sie bewirkt,
  dass die Routinen, die die Computernamen aufschlsseln, zuerst in der
  /etc/hosts nachschauen und dann beim Nameserver anfragen, der laut
  resolv.conf der Rechner mit der IP 127.0.0.1 ist.



  3.1.  Starten des named

  Nachdem das alles erledigt ist, ist es an der Zeit, den named das
  erste Mal zu starten. Eventuell ist vorher noch die Verbindung ins
  Internet zu starten. Dann gibt man



       ndc start/




  ein. Sollte das nicht funktionieren, klappt statt dessen vielleicht
  der folgende Befehl:



       /usr/sbin/ndc start




  Wenn auch das nicht das gewnschte Ergebnis liefert, bleibt nur ein
  Blick in den Abschnitt ``Fragen und Antworten''. Ein Blick in die
  Datei, in der der syslog Nachrichten speichert (blicherweise heisst
  diese /var/adm/messages - sie kann aber auch im Verzeichnis /var/log
  gefunden werden oder nicht messages sondern syslog heissen...),
  whrend der named gestartet wird (tail -f /var/log/messages) sollte
  etwas hnliches wie das folgende zeigen:


  (Zeilen, die mit \ enden, werden in der nchsten Zeile fortgefhrt)



       Feb 15 01:26:17 roke named[6091]: starting.  named 8.1.1 Sat Feb 14 \
         00:18:20 MET 1998 janl@roke.uio.no:/var/tmp/bind-8.1.1/src/bin/named
       Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0)
       Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa" \
         (IN) loaded (serial 1)
       Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo)
       Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ippp0)
       Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040
       Feb 15 01:26:17 roke named[6092]: Ready to answer queries.





  Wenn der named Fehler in der Konfiguration findet, meldet er im
  Logfile unter anderem den Name der Datei, die den Fehler enthlt:
  entweder named.conf oder root.hints - hoffe ich :-). Dann wird der
  named beendet und die Datei muss berarbeitet werden.


  Ansonsten knnen die Einstellungen jetzt getestet werden. Mit nslookup
  kann man seine Arbeit kontrollieren.



       $ nslookup
       Default Server:  localhost
       Address:  127.0.0.1

       >





  Wenn dieses auf dem Bildschirm erscheint, luft es. Hoffentlich. Wenn
  etwas anderes auftaucht, mssen alle Einstellungen von Anfang an
  kontrolliert werden. Jedesmal, wenn die named.conf-Datei verndert
  wurde, muss der named mit dem Befehl



       named restart




  neu gestartet werden.


  Ansonsten kann jetzt eine erste Anfrage gemacht werden. Zuerst
  versucht man einen Rechner herauszufinden, der sich in der Nhe
  befindet.  pat.uio.no befindet sich in meiner Nhe - an der
  Universitt in Oslo:





  > pat.uio.no
  Server:  localhost
  Address:  127.0.0.1

  Name:    pat.uio.no
  Address:  129.240.130.16





  nslookup hat jetzt den gerade konfigurierten named nach dem Rechner
  pat.uio.no gefragt. Um darauf antworten zu knnen, 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.


  Macht man die gleiche Anfrage nochmal, bekommt man dieses Ergebnis:



       > pat.uio.no
       Server:  localhost
       Address:  127.0.0.1

       Non-authoritative answer:
       Name:    pat.uio.no
       Address:  129.240.2.50





  Man beachte die Non-authoritative answer:-Zeile, die dieses mal
  zustzlich erscheint. Sie bedeutet, dass der named dieses Mal nicht im
  Netz nachgefragt hat, sondern dass die Informationen aus seinem Cache
  stammen.  Durch die Non-authorative answer: wird man ber die (sehr
  kleine) Mglichkeit informiert, dass diese zwischengespeicherten Daten
  eventuell nicht mehr aktuell sind. Wenn nslookup diese Zeile bei der
  zweiten Anfrage ausgibt, ist das ein sicheres Zeichen dafr, dass die
  Daten zwischengespeichert werden und dass der named wie gewnscht
  funktioniert. nslookup wird beendet, indem man exit eingibt.


  3.2.  Was noch verbessert werden kann

  In grossen, gut organisierten wissenschaftlichen oder ISP (Internet
  Service Provider)-Netzen sieht man gelegentlich, dass die
  Netzwerkadministratoren sogenannte forwarder-DNS-Server eingerichtet
  haben, die dazu beitragen, dass die interne und externe
  Netzwerkbelastung klein bleibt. Es ist nicht leicht, herauszufinden,
  ob man sich in so einem Netz befindet - oder nicht. Es ist aber auch
  nicht wichtig und indem man den DNS-Server vom eigenen Provider als
  forwarder benutzt, kann man die Antwortzeiten auf Anfragen erheblich
  verkrzen und die Netzwerkbelastung sehr niedrig halten. Gerade fr
  Leute mit Modem ist das ein nicht unerheblicher Vorteil. Um ein
  Beispiel nennen zu knnen, gehe ich davon aus, dass der Netz-Provider
  zwei Nameserver hat, die man benutzen kann und die die IPs 10.0.0.1
  und 10.1.0.1 haben. Dann werden in die Datei named.conf in den
  Anfangsabschnitt options die folgenden Zeilen eingefgt:




             forward first;
             forwarders {
                  10.0.0.1;
                  10.1.0.1;
              };





  Jetzt den Nameserver neu starten und mit nslookup testen. Er sollte
  die gleichen Ergebnisse wie vorher liefern.


  3.3.  Gratulation

  Damit ist die Installation eines caching-only Nameservers beendet.
  Zeit fr ein Bier, eine Milch oder was auch immer man zur Feier des
  Tages trinken mchte.


  4.  Eine einfache Domain


  Dieser Abschnitt beschreibt, wie man seine eigene Domain einrichtet.


  4.1.  Aber zuerst etwas trockene Theorie

  Bevor es wirklich mit diesem Abschnitt losgehen kann, soll anhand
  eines Beispiels ein wenig auf die theoretische Funktionsweise des DNS
  eingegangen werden. Diese wichtigen und interessanten Informationen
  sollten auf jeden Fall gelesen werden. Wer nicht alles lesen mchte,
  kann es wenigstens einmal berfliegen - bis zu der Beschreibung des
  Inhalts der named.conf-Datei.


  Das DNS ist ein hierarchisches System, in der Form eines Baumes. Die
  Spitze wird als . geschrieben und wird root (Wurzel) genannt.
  Unter dem . existieren einige Top Level Domains (TLDs) - die
  bekanntesten sind ORG, COM, EDU, NET und natrlich DE - es gibt aber
  noch viele mehr. Wie bei einem Baum gibt es neben der Wurzel auch
  ste.  Jeder, der sich etwas in den Computerwissenschaften auskennt,
  erkennt im DNS einen Suchbaum, an dem sich Knoten, Verzweigungen und
  mehr befinden.


  Wenn nach einem Computernamen gesucht wird, taucht die Abfrage an der
  Spitze rekursiv nach unten wandernd in die Hierarchie ein. Wenn man
  die Adresse von prep.ai.mit.edu herausfinden will, muss der Nameserver
  erst einmal herausfinden, welcher Nameserver fr die Domain edu
  zustndig ist. Dazu befragt er einen .-Server, den er dank der
  root.hints-Datei kennt. Der root-Server listet dann die Server fr edu
  auf:



       $ nslookup
       Default Server:  localhost
       Address:  127.0.0.1




  Am Anfang wird ein root-Server befragt:



       > server c.root-servers.net.
       Default Server:  c.root-servers.net
       Address:  192.33.4.12




  Hierzu wird die Abfrageart auf NS gesetzt (Nameserver-Eintrge):



       > set q=ns




  Nach edu fragen:



       > edu.




  Der abschliessende . dieser Anfrage ist sehr wichtig. nslookup wei
  dadurch, dass edu direkt unter der Wurzel zu finden ist (und nicht
  unter irgendeiner search-Domain. So wird die Abfrage beschleunigt).



       edu     nameserver = A.ROOT-SERVERS.NET
       edu     nameserver = H.ROOT-SERVERS.NET
       edu     nameserver = B.ROOT-SERVERS.NET
       edu     nameserver = C.ROOT-SERVERS.NET
       edu     nameserver = D.ROOT-SERVERS.NET
       edu     nameserver = E.ROOT-SERVERS.NET
       edu     nameserver = I.ROOT-SERVERS.NET
       edu     nameserver = F.ROOT-SERVERS.NET
       edu     nameserver = G.ROOT-SERVERS.NET
       A.ROOT-SERVERS.NET      internet address = 198.41.0.4
       H.ROOT-SERVERS.NET      internet address = 128.63.2.53
       B.ROOT-SERVERS.NET      internet address = 128.9.0.107
       C.ROOT-SERVERS.NET      internet address = 192.33.4.12
       D.ROOT-SERVERS.NET      internet address = 128.8.10.90
       E.ROOT-SERVERS.NET      internet address = 192.203.230.10
       I.ROOT-SERVERS.NET      internet address = 192.36.148.17
       F.ROOT-SERVERS.NET      internet address = 192.5.5.241
       G.ROOT-SERVERS.NET      internet address = 192.112.36.4





  Diese Auflistung bedeutet, dass alle ROOT-SERVERS.NET-Server fr EDU.
  zustndig sind, also kann einer von denen befragt werden. Wir fragen
  bereits den C-Root-Nameserver. Dann kann die nchste Ebene des
  Domainnamens herausgefunden werden: mit.edu:




  > mit.edu.
  Server:  c.root-servers.net
  Address:  192.33.4.12

  Non-authoritative answer:
  mit.edu nameserver = W20NS.mit.edu
  mit.edu nameserver = BITSY.mit.edu
  mit.edu nameserver = STRAWB.mit.edu

  Authoritative answers can be found from:
  W20NS.mit.edu   internet address = 18.70.0.160
  BITSY.mit.edu   internet address = 18.72.0.3
  STRAWB.mit.edu  internet address = 18.71.0.151




  strawb, w20ns und bitsy sind alle fr mit.edu zustndig.  Einer davon
  wird ausgewhlt und es geht eine Ebene tiefer: ai.mit.edu:



       > server W20NS.mit.edu.




  Die Gross-/Kleinschrift ist bei Rechnernamen unwichtig, aber da ich
  die Daten per Maus kopiere und hier einfge, sieht die Ausgabe genau
  wie auf dem Bildschirm aus.




































  Server:  W20NS.mit.edu
  Address:  18.70.0.160

  > ai.mit.edu.
  Server:  W20NS.mit.edu
  Address:  18.70.0.160

  Non-authoritative answer:
  ai.mit.edu      nameserver = ALPHA-BITS.AI.MIT.EDU
  ai.mit.edu      nameserver = GRAPE-NUTS.AI.MIT.EDU
  ai.mit.edu      nameserver = TRIX.AI.MIT.EDU
  ai.mit.edu      nameserver = MUESLI.AI.MIT.EDU
  ai.mit.edu      nameserver = LIFE.AI.MIT.EDU
  ai.mit.edu      nameserver = BEET-CHEX.AI.MIT.EDU
  ai.mit.edu      nameserver = MINI-WHEATS.AI.MIT.EDU
  ai.mit.edu      nameserver = COUNT-CHOCULA.AI.MIT.EDU
  ai.mit.edu      nameserver = MINTAKA.LCS.MIT.EDU

  Authoritative answers can be found from:
  AI.MIT.EDU      nameserver = ALPHA-BITS.AI.MIT.EDU
  AI.MIT.EDU      nameserver = GRAPE-NUTS.AI.MIT.EDU
  AI.MIT.EDU      nameserver = TRIX.AI.MIT.EDU
  AI.MIT.EDU      nameserver = MUESLI.AI.MIT.EDU
  AI.MIT.EDU      nameserver = LIFE.AI.MIT.EDU
  AI.MIT.EDU      nameserver = BEET-CHEX.AI.MIT.EDU
  AI.MIT.EDU      nameserver = MINI-WHEATS.AI.MIT.EDU
  AI.MIT.EDU      nameserver = COUNT-CHOCULA.AI.MIT.EDU
  AI.MIT.EDU      nameserver = MINTAKA.LCS.MIT.EDU
  ALPHA-BITS.AI.MIT.EDU   internet address = 128.52.32.5
  GRAPE-NUTS.AI.MIT.EDU   internet address = 128.52.36.4
  TRIX.AI.MIT.EDU internet address = 128.52.37.6
  MUESLI.AI.MIT.EDU       internet address = 128.52.39.7
  LIFE.AI.MIT.EDU internet address = 128.52.32.80
  BEET-CHEX.AI.MIT.EDU    internet address = 128.52.32.22
  MINI-WHEATS.AI.MIT.EDU  internet address = 128.52.54.11
  COUNT-CHOCULA.AI.MIT.EDU        internet address = 128.52.38.22
  MINTAKA.LCS.MIT.EDU     internet address = 18.26.0.36





  Also ist museli.ai.mit.edu ein Nameserver fr ai.mit.edu:



       > server MUESLI.AI.MIT.EDU
       Default Server:  MUESLI.AI.MIT.EDU
       Address:  128.52.39.7





  Jetzt wird der Typ der Anfrage gewechselt. Der Nameserver wurde
  gefunden, also wird muesli gefragt, was er alles ber prep.ai.mit.edu
  weiss.









  > set q=any
  > prep.ai.mit.edu.
  Server:  MUESLI.AI.MIT.EDU
  Address:  128.52.39.7

  prep.ai.mit.edu CPU = dec/decstation-5000.25    OS = unix
  prep.ai.mit.edu
          inet address = 18.159.0.42, protocol = tcp
            ftp  telnet  smtp  finger
  prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
  prep.ai.mit.edu internet address = 18.159.0.42
  ai.mit.edu      nameserver = beet-chex.ai.mit.edu
  ai.mit.edu      nameserver = alpha-bits.ai.mit.edu
  ai.mit.edu      nameserver = mini-wheats.ai.mit.edu
  ai.mit.edu      nameserver = trix.ai.mit.edu
  ai.mit.edu      nameserver = muesli.ai.mit.edu
  ai.mit.edu      nameserver = count-chocula.ai.mit.edu
  ai.mit.edu      nameserver = mintaka.lcs.mit.edu
  ai.mit.edu      nameserver = life.ai.mit.edu
  gnu-life.ai.mit.edu     internet address = 128.52.32.60
  beet-chex.ai.mit.edu    internet address = 128.52.32.22
  alpha-bits.ai.mit.edu   internet address = 128.52.32.5
  mini-wheats.ai.mit.edu  internet address = 128.52.54.11
  trix.ai.mit.edu internet address = 128.52.37.6
  muesli.ai.mit.edu       internet address = 128.52.39.7
  count-chocula.ai.mit.edu        internet address = 128.52.38.22
  mintaka.lcs.mit.edu     internet address = 18.26.0.36
  life.ai.mit.edu internet address = 128.52.32.80





  Angefangen bei . wurden so der Reihe nach die Nameserver fr jede
  einzelne Ebene des Domainnamens gefunden. Wenn hierzu anstelle der
  vielen einzelnen Nameserver nur der eigene Nameserver benutzt worden
  wre, htte dieser natrlich alle Informationen zwischengespeichert,
  die auf der Suche nach dem Rechnernamen aufgetaucht wren; so bruchte
  er fr eine Weile nicht mehr im Netz nachfragen.


  Analog zu der Baumstruktur ist jeder . im Rechnername eine
  Verzweigung. Jeder Teil zwischen zwei Punkten ist der Name eines Astes
  im Baum.


  Man klettert auf den Baum, indem man den Rechnernamen nimmt
  (prep.ai.mit.edu) und bei der Wurzel (.) beginnend die Zweige
  hinabsteigt. Der nchste Zweig in diesem Beispiel wre edu. Die
  nchste Ebene erreicht man durch das Umschalten zu dem Nameserver, der
  diesen Teil des Namens kennt. Als nchstes folgt der mit-Zweig, der an
  den edu-Zweig anknpft (zusammen ergibt das mit.edu) und besteigt
  diesen Zweig wiederum durch Umschalten zu dem Server der die
  Informationen fr mit.edu bereitstellt. Der nchste Zweig lautet
  ai.mit.edu und erneut wird der Server gewechselt. Jetzt wurde der
  richtige Server an der richtigen Abzweigung erreicht. Die letzte
  Aufgabe ist die Abfrage der Informationen zu prep.ai.mit.edu -
  ziemlich einfach, oder?


  Eine Domain, ber die wenig gesprochen wird, die aber mindestens
  genauso wichtig wie alle anderen ist, ist in-addr.arpa. Sie ist wie
  die normalen Domains aufgebaut und erlaubt es uns, den Rechnernamen
  herauszufinden, wenn nur die IP-Adresse bekannt ist. Eine wichtige
  Eigenheit muss man allerdings kennen: Die IP-Adressen werden in der
  in-addr.arpa-Domain verkehrt herum aufgelistet. Wenn man die IP-
  Adresse 192.128.52.43 hat, arbeitete der named genauso wie im
  prep.ai.mit.edu-Beispiel: Er sucht nach den arpa.-Servern und dann
  nach in-addr.arpa.-Servern, 192.in-addr.arpa.-Servern, 128.192.in-
  addr.arpa.-Servern und nach 52.128.192.in-addr.arpa.  Servern.
  Letztendlich findet er dann die Eintrge fr 43.52.128.192.in-
  addr.arpa. Clever, oder? Die Antwort sollte ja lauten ;-). Trotzdem
  wird diese Umkehrung der IP-Nummern jahrelang fr Verwirrung sorgen.


  Ich habe gerade ein wenig geflunkert. Das DNS arbeitet nicht so wie
  ich es gerade erklrt habe. Aber die Beschreibung ist nahe genug an
  der Wahrheit.


  4.2.  Die eigene Domain

  Um eine eigene Domain zu erstellen, wird in dieser HOWTO als Beispiel
  der Domainname linux.test benutzt. Einzelne Rechner werden zu dieser
  Domain hinzugefgt. Es wird eine test-TLD benutzt, um
  sicherzustellen, dass niemand da draussen durch diese Domain gestrt
  wird.


  Eins noch, bevor es losgeht: Es sind nicht alle Zeichen in einem
  Rechnernamen erlaubt. Diese Einschrnkung beinhaltet, dass nur die
  Buchstaben des englischen Alphabets benutzt werden drfen: a-z,
  Ziffern (0-9) und der Bindestrich (-). Nochmal, es sollten und
  drfen keine anderen Zeichen benutzt werden. Im DNS gibt es keinen
  Unterschied zwischen Groos- und Kleinbuchstaben - pat.uio.no is
  identisch mit Pat.UiO.No.


  Die erste wichtige Einstellung wurde bereits durch die folgende Zeile
  in der named.conf gemacht:



       zone "0.0.127.in-addr.arpa" {
               type master;
               file "pz/127.0.0";
       };





  Zu beachten ist, dass der . am Ende der Domainnamen in dieser Datei
  fehlt. Die Einstellungen definieren die Zone 0.0.127.in-addr.arpa,
  dass unser Server der Haupt-(Master)Server dafr ist und dass die
  Daten in einer Datei mit dem Namen pz/127.0.0 gespeichert werden. Auch
  diese Datei existiert bereits:



       @       IN    SOA     ns.linux.test. hostmaster.linux.test. (
                             1       ; Serial
                             8H      ; Refresh
                             2H      ; Retry
                             1W      ; Expire
                             1D)     ; Minimum TTL
                             NS      ns.linux.test.
       1                     PTR     localhost.




  Wichtig ist der . am Ende von jedem kompletten Domainnamen in dieser
  Datei - im Gegensatz zu der named.conf-Datei von oben. Es gibt Leute,
  die jede Zonendatei mit einem $ORIGIN-Statement beginnen, aber das ist
  berflssig. Der Ursprung (origin) einer Zonendatei (der Punkt an dem
  sich die Domain in der DNS-Hierarchie befindet) wird durch den Zonen-
  Abschnitt in der named.conf-Datei definiert. In diesem Fall ist das
  0.0.127.in-addr.arpa.

  Die gerade erstellte Zonen-Datei enthlt 3 Eintragungen (resource
  records (RRs)). Einen NS RR und einen PTR RR. SOA ist die Abrzung
  fr Start Of Authority. Der Klammeraffe @ ist ein spezielles
  Zeichen und steht fr den Ursprung dieser Domain. Die domain-Zeile
  fr diese Datei definiert den Ursprung als 0.0.127.in-addr.arpa, also
  steht in der ersten Zeile ausgeschrieben:



       0.0.127.in-addr.arpa.   IN      SOA ...





  NS ist der Name-Server RR. Am Anfang der Zeile fehlt das @. Man kann
  sich diese Tipparbeit sparen, weil bereits die vorhergehende Zeile
  mit @ anfing. Die NS-Zeile knnte also auch so geschrieben werden:



       0.0.127.in-addr.arpa.   IN      NS      ns.linux.test





  Hierdurch erfrt das DNS den Rechner, der als Nameserver fr die
  Domain 0.0.127.in-addr.arpa fungiert: ns.linux.test. ns ist der
  bliche Name fr einen Nameserver - genauso wie Web-Server
  normalerweise www.irgendetwas heissen. Trotzdem kann natrlich auch
  jeder beliebige andere Name benutzt werden.


  Als letzter Eintrag bedeutet die PTR-Zeile, dass der Rechner mit der
  Adresse 1 im Subnetz 0.0.127.in-addr.arpa (also 127.0.0.1) localhost
  heisst.


  Der SOA-Eintrag steht am Anfang von jeder Zonendatei. Ihn sollte es in
  jeder Datei nur ein einziges mal geben. Dieser Eintrag beschreibt die
  Ursprungszone (linux.test), wer fr den Inhalt der Domaindaten dieser
  Zone verantwortlich ist (hostmaster@linux.test) - man sollte hier
  seine eigene E-Mail-Adresse einfgen oder besser den blichen Alias
  hostmaster erzeugen. Ausserdem ist die Versionsnummer dieser
  Zonendatei enthalten (Seriennummer: 1) und diverse weitere
  Einstellungen, die mit dem Caching und Secondary (Zweit-)Nameservern
  zu tun haben. Wenn die Einstellungen der Felder (refresh, retry,
  expire und minimum) aus der HOWTO bernommen werden, sollte man auf
  der sicheren Seite sein.


  Jetzt wird der named neu gestartet (der Befehl hierfr ist ndc
  restart) und die Einstellungen werden mit nslookup kontrolliert:




  $ nslookup

  Default Server:  localhost
  Address:  127.0.0.1

  > 127.0.0.1
  Server:  localhost
  Address:  127.0.0.1

  Name:    localhost
  Address:  127.0.0.1





  Also ist nslookup in der Lage, den Namen localhost mit der IP-Adresse
  127.0.0.1 herauszufinden - hervorragend.


  Um jetzt zurck zur Hauptsache - der linux.test-Domain zu kommen, wird
  ein neuer Zonen-Abschnitt in die named.conf eingefgt:



       zone "linux.test" {
               notify no;
               type master;
               file "pz/linux.test";
       };





  Am Ende des Domainnamens in der named.conf-Datei wird kein .
  geschrieben.


  In die linux.test-Zonendatei werden jetzt irgendwelche Testdaten
  eingefgt:



       ;
       ; Zonendatei fr linux.test
       ;
       ; Die komplette Zonendatei
       ;
       @       IN      SOA     ns.linux.test. hostmaster.linux.test. (
                               199802151       ; Datum + Seriennummer #
                               8H              ; refresh, Sekunden
                               2H              ; retry, Sekunden
                               1W              ; expire, Sekunden
                               1D )            ; minimum,
       ;
                       NS      ns              ; Rechnername des Nameserver
                       MX      10 mail.linux.test      ; erster Mailserver
                       MX      20 mail.friend.test.    ; zweiter Mailserver
       ;
       localhost       A       127.0.0.1
       ns              A       192.168.196.2
       mail            A       192.168.196.4



  Zwei Anmerkungen mssen ber den SOA-Eintrag gemacht werden.
  ns.linux.test muss ein Rechner mit einem gltigen A-Record sein.  Es
  ist nicht erlaubt, einen CNAME-Eintrag im SOA-Abschnitt zu benutzen.
  Der Name muss brigens nicht ns lauten, es kann auch jeder andere
  gltige Rechnername sein. Ausserdem liest sich hostmaster.linux.test
  als hostmaster@linux.test - dies sollte ein Alias oder eine Mailbox
  sein, die von den DNS-Administratoren regelmssig gelesen wird. Alle
  E-Mails, die sich auf das DNS beziehen, werden an diese Adresse
  geschickt. Genauso wie der Rechnername nicht unbedingt ns sein muss,
  kann auch hier eine andere gltige E-Mail-Adresse benutzt werden, aber
  oft wird davon ausgegangen, dass auch die hostmaster-Adresse
  existiert und gelesen wird.


  Es gibt in dieser Datei noch einen neuen RR-Typen - den MX oder Mail
  eXchanger. Dieser Eintrag liefert Mailservern die Adresse zurck, an
  die E-Mails geliefert werden sollen, die nach jemandem@linux.test
  geschickt werden. In diesem Fall nach mail.linux.test oder
  mail.friend.test.  Die Nummer vor den Mail-Eintrgen ist die
  Prioritt, mit der die Mailserver ausgewhlt werden. Der RR mit der
  kleinsten Nummer (10) ist der erste, an den versucht wird, E-Mails zu
  schicken. Wenn das nicht klappt, kann die E-Mail an einen Server mit
  einer hheren Priorittsnummer geschickt werden - zum Beispiel einen
  Not-Mailserver mail.friend.test, der hier die Prioritt 20 hat.


  Der named wird mit Hilfe von ndc restart neu gestartet und die
  Ergebnisse werden wie immer mit nslookup begutachtet:



       $ nslookup
       > set q=any
       > linux.test
       Server:  localhost
       Address:  127.0.0.1

       linux.test
               origin = ns.linux.test
               mail addr = hostmaster.linux.test
               serial = 199802151
               refresh = 28800 (8 hours)
               retry   = 7200 (2 hours)
               expire  = 604800 (7 days)
               minimum ttl = 86400 (1 day)
       linux.test     nameserver = ns.linux.test
       linux.test     preference = 10, mail exchanger = mail.linux.test.linux.test
       linux.test     preference = 20, mail exchanger = mail.friend.test
       linux.test     nameserver = ns.linux.test
       ns.linux.test  internet address = 192.168.196.2
       mail.linux.test        internet address = 192.168.196.4





  Bei genauerer Betrachtung sollte man einen Fehler entdecken. Die Zeile



       linux.test     preference = 10, mail exchanger = mail.linux.test.linux.test





  ist falsch. Sie sollte



       linux.test     preference = 10, mail exchanger = mail.linux.test




  lauten.


  Ich habe diesen Fehler mit Absicht eingebaut, um davon zu lernen :-).
  In der Zonendatei findet man den Fehler in der Zeile



                       MX      10 mail.linux.test      ; Erster Mailserver




  Es fehlt ein Punkt oder das linux.test ist zuviel. Wenn ein
  Rechnername in der Zonendatei nicht mit einem Punkt endet, wird die
  Ursprungszone an den Namen angehngt. Dadurch entsteht die
  Verdoppelung linux.test.linux.test. Also ist die richtige Schreibweise
  entweder



                       MX      10 mail.linux.test.     ; Erster Mailserver




  oder



                       MX      10 mail                 ; Erster Mailserver




  Ich benutze die zweite Variante - es ist weniger Tipparbeit. Es gibt
  einige Bind-Experten, denen diese Arbeitsweise nicht gefllt und
  andere, die es ebenso machen. Nochmal: In einer Zonendatei sollte die
  Domain entweder ausgeschrieben und mit einem Punkt beendet werden oder
  sie sollte komplett weggelassen werden - in diesem Fall wird der
  Ursprung angehngt.


  Ich muss noch einmal betonen, dass in der named.conf-Datei kein .
  hinter dem Domainnamen sein darf. Man glaubt garnicht, wie oft ein
  Punkt zuviel oder zuwenig Fehler verursacht und die Leute an den Rand
  des Wahnsinns bringt.


  Und jetzt folgt eine neue Zonendatei mit einigen zustzlichen
  Eintrgen:






  ;
  ; Zonendatei frlinux.test
  ;
  ; die komplette Zonendatei
  ;
  @       IN      SOA     ns.linux.test. hostmaster.linux.test. (
                          199802151       ; aktuelles Datum + Seriennummer
                          8H              ; refresh, Sekunden
                          2H              ; retry, Sekunden
                          1W              ; expire, Sekunden
                          1D )            ; minimum, Sekunden
  ;
                  TXT     "Linux.Test, die DNS-Einfhrung"
                  NS      ns              ; Rechnername des Nameservers
                  NS      ns.friend.test.
                  MX      10 mail         ; erster Mailserver
                  MX      20 mail.friend.test. ; zweiter Mailserver

  localhost       A       127.0.0.1

  gw              A       192.168.196.1
                  HINFO   "Cisco" "IOS"
                  TXT     "Der Router"

  ns              A       192.168.196.2
                  MX      10 mail
                  MX      20 mail.friend.test.
                  HINFO   "Pentium" "Linux 2.0"
  www             CNAME   ns

  donald          A       192.168.196.3
                  MX      10 mail
                  MX      20 mail.friend.test.
                  HINFO   "i486"      "Linux 2.0"
                  TXT     "DEK"

  mail            A       192.168.196.4
                  MX      10 mail
                  MX      20 mail.friend.test.
                  HINFO   "386sx" "Linux 1.2"

  ftp             A       192.168.196.5
                  MX      10 mail
                  MX      20 mail.friend.test.
                  HINFO   "P6" "Linux 2.1.86"





  Es gib hier wieder einige neue RRs: HINFO (Host INFOrmation -
  Rechnerinformation) besteht aus zwei Teilen - es gehrt zum guten Ton,
  beide Teile anzugeben. Der erste Teil ist die Hardare bzw. die CPU des
  Systems, der zweite Teil enthlt den Namen der Software oder des
  Betriebssystems des Rechners. Der Rechner mit dem Namen ns enthlt
  eine Pentium CPU und luft mit Linux 2.0. CNAME (Canonical Name) ist
  eine Mglichkeit, einem Rechner mehrere Namen zuzuweisen. Also ist www
  ein Alias fr ns.


  Die Benutzung von CNAME-Eintrgen ist ein wenig kontrovers. Unter
  Bercksichtigung der folgenden Regeln, sollte es keine Probleme geben.
  MX, CNAME oder SOA-Eintrge drfen niemals auf einen CNAME-Eintrag
  verweisen, sondern nur auf A-Records. Aus diesem Grund ist das
  folgende nicht erlaubt:

       blabar          CNAME   www                     ; NEIN!




  Die richtige Variante lautet:



       blabar          CNAME   ns                      ; JA!





  Man kann davon ausgehen, dass ein CNAME kein gltiger Rechnername fr
  eine E-Mail-Adresse ist: webmaster@www.linux.test ist nach den obigen
  Einstellungen eine ungltige Adresse. Auch wenn ein Test auf dem
  eigenen Rechner keine Schwierigkeiten macht, kann man mit Sicherheit
  erwarten, dass es immer ein paar Mail-Admins gibt, die diese Regel
  durchboxen. Ein Weg zur Vermeidung dieses Problems ist es, nur A-
  Eintrge zu benutzen (und natrlich andere wie zum Beispiel MX,...):



       www             A       192.168.196.2





  Eine Handvoll der alten Bind-Magier empfehlen ebenfalls, niemals CNAME
  zu benutzen. Die Grundsatzdiskussion warum oder warum nicht gehrt
  aber nicht in diese HOWTO.


  Was man aber auch sehen kann, ist dass diese HOWTO und viele andere
  Sites diese Regeln nicht befolgen.


  Die neuen Einstellungen der Bind-Datenbank werden mit ndc reload
  geladen - der named liest daraufhin seine Konfigurationsdateien neu
  ein.



       $ nslookup
       Default Server:  localhost
       Address:  127.0.0.1

       > ls -d linux.test





  Das bewirkt eine Auflistung aller Eintrge. Als Ergebnis erhlt man:









  [localhost]
  $ORIGIN linux.test.
  @                       1D IN SOA       ns hostmaster (
                                          199802151       ; Seriennummer
                                          8H              ; refresh
                                          2H              ; retry
                                          1W              ; expiry
                                          1D )            ; minimum

                          1D IN NS        ns
                          1D IN NS        ns.friend.test.
                          1D IN TXT       "Linux.Test, die DNS-Einfuehrung"
                          1D IN MX        10 mail
                          1D IN MX        20 mail.friend.test.
  gw                      1D IN A         192.168.196.1
                          1D IN HINFO     "Cisco" "IOS"
                          1D IN TXT       "The router"
  mail                    1D IN A         192.168.196.4
                          1D IN MX        10 mail
                          1D IN MX        20 mail.friend.test.
                          1D IN HINFO     "386sx" "Linux 1.0.9"
  localhost               1D IN A         127.0.0.1
  www                     1D IN CNAME     ns
  donald                  1D IN A         192.168.196.3
                          1D IN MX        10 mail
                          1D IN MX        20 mail.friend.test.
                          1D IN HINFO     "i486" "Linux 1.2"
                          1D IN TXT       "DEK"
  ftp                     1D IN A         192.168.196.5
                          1D IN MX        10 mail
                          1D IN MX        20 mail.friend.test.
                          1D IN HINFO     "P6" "Linux 1.3.59"
  ns                      1D IN A         192.168.196.2
                          1D IN MX        10 mail
                          1D IN MX        20 mail.friend.test.
                          1D IN HINFO     "Pentium" "Linux 1.2"





  Sehr schn - man erkennt sofort die hnlichkeit zu der Zonendatei
  selbst. Mal sehen, was nur fr www ausgegeben wird:



       > set q=any
       > www.linux.test.
       Server:  localhost
       Address:  127.0.0.1

       www.linux.test canonical name = ns.linux.test
       linux.test     nameserver = ns.linux.test
       linux.test     nameserver = ns.friend.test
       ns.linux.test  internet address = 192.168.196.2





  In anderen Worten: Der richtige Name von www.linux.test ist
  ns.linux.test. Auerdem werden zustzliche Informationen ber ns
  ausgegeben - genug um eine Verbindung aufzubauen, wenn man ein
  Programm wre.


  4.3.  Die umgekehrte Zone (Reverse Zone)

  Jetzt knnen Programme also die Rechnernamen der Domain linux.test in
  die fr sie ntigen IP-Adressen umwandeln. Zustzlich wird aber noch
  eine Zone bentigt, die die Umwandlung von IP-Adressen in Rechnernamen
  ermgicht - eine umgekehrte oder reverse Zone. Die Rechnernamen
  werden von vielen Programmen (z.B. FTP, IRC, WWW und anderen) zur
  Entscheidung darber herangezogen, ob sie mit einem reden wollen oder
  nicht - und falls sie es mchten, welche Prioritt man erhlt. Um
  vollen Zugang zu allen Internetdiensten zu bekommen ist eine
  umgekehrte Zone ntig.


  Hierzu wird noch etwas in die named.conf eingefgt:



       zone "196.168.192.in-addr.arpa" {
               notify no;
               type master;
               file "pz/192.168.196";
       };





  Dieser Eintrag ist dem 0.0.127.in-addr.arpa-Eintrag sehr hnlich -
  auch der Inhalt der Zonendatei ist gleich:



       @       IN      SOA     ns.linux.test. hostmaster.linux.test. (
                               199802151 ; Seriennummer, Datum + Seriennnummer
                               8H      ; Refresh
                               2H      ; Retry
                               1W      ; Expire
                               1D)     ; Minimum TTL
                       NS      ns.linux.test.

       1               PTR     gw.linux.test.
       2               PTR     ns.linux.test.
       3               PTR     donald.linux.test.
       4               PTR     mail.linux.test.
       5               PTR     ftp.linux.test.





  Jetzt wird der named neu gestartet (ndc restart) und die gerade
  gemachten Einstellungen werden mit nslookup berprft:



       > 192.168.196.4
       Server:  localhost
       Address:  127.0.0.1

       Name:    mail.linux.test
       Address:  192.168.196.4





  So, das sieht OK aus. Jetzt werden nochmal alle Einstellungen
  ausgegeben und gecheckt:



       > ls -d 196.168.192.in-addr.arpa
       [localhost]
       $ORIGIN 196.168.192.in-addr.arpa.
       @                       1D IN SOA       ns.linux.test. hostmaster.linux.test. (
                                               199802151       ; serial
                                               8H              ; refresh
                                               2H              ; retry
                                               1W              ; expiry
                                               1D )            ; minimum

                               1D IN NS        ns.linux.test.
       1                       1D IN PTR       gw.linux.test.
       2                       1D IN PTR       ns.linux.test.
       3                       1D IN PTR       donald.linux.test.
       4                       1D IN PTR       mail.linux.test.
       5                       1D IN PTR       ftp.linux.test.
       @                       1D IN SOA       ns.linux.test. hostmaster.linux.test. (
                                               199802151       ; serial
                                               8H              ; refresh
                                               2H              ; retry
                                               1W              ; expiry
                                               1D )            ; minimum





  Das sieht sehr gut aus. Wenn die Ausgabe allerdings nicht mit der
  obigen bereinstimmt, muss man in der syslog-Datei nach
  Fehlermeldungen suchen.  Wie das gemacht wird, habe ich ganz am Anfang
  dieses Abschnitts erklrt.


  4.4.  Warnungen

  Es gibt noch ein paar Dinge, die gesagt werden sollten. Die IP-
  Adressen, die in den obigen Beispielen benutzt wurden, stammen aus
  einem der privaten Netze. Sie drfen nicht ffentlich im Internet
  benutzt werden. Darum sind sie ideal fr die Benutzung in einer HOWTO.
  Der zweite Punkt ist die notify no;-Zeile. Sie veranlat den named
  dazu, seine Zweit-(Secondary)-Server nicht ber nderungen in den
  Zonendateien zu informieren. Denn der Bind Version 8 kann die anderen
  Server, die in den NS-Eintrgen einer Zonendatei stehen, ber
  Neuerungen in einer Zone informieren. Das ist fr den tglichen
  Gebrauch sehr praktisch, aber fr private Zonen-Experimente sollte
  diese Option abgeschaltet werden. Wir wollen doch nicht das Internet
  mit unserem Experiment belstigen, oder?


  Ausserdem ist die Domain natrlich nur ein Test - genauso wie alle
  Adressen, die sie beinhaltet. Ein reales Beispiel aus einer
  existierenden Domain ist im nchsten Kapitel zu sehen.


  4.5.  Warum Reverse Lookups nicht funktionieren.

  Es gibt ein paar Probleme mit Namensauflsungen, wenn die Adressen
  rckwrts aufgeschlsselt werden sollen, die zwar selten aber dennoch
  auftreten. Bevor ich darauf eingehe, sollte berprft werden, ob die
  Reverse Lookups auf dem eigenen Rechner funktionieren. Wenn nicht -
  zurck an den Anfang und den Fehler beheben.
  Ich werde hier im Detail auf zwei Probleme eingehen, wie sie auftreten
  knnen, wenn von ausserhalb des eigenen Netzes auf den Nameserver
  zugegriffen wird.


  4.5.1.  Die reverse-Zone wurde nicht delegiert.

  Wenn man von einen Serviceprovider einen Netzwerkbereich und einen
  Domainnamen bekommt, wird der Domainname normalerweise automatisch
  delegiert. Eine Delegierung ist der NS-Eintrag, der einen von einem
  Nameserver zum nchsten weiterleitet, wie es in dem oberen Theorie-
  Abschnitt erklrt wurde. Das wurde doch gelesen und verstanden? Wenn
  die reversen-Zonen noch nicht funktionieren, zurck an den Anfang und
  nochmals genau lesen.


  Die reverse Zone muss nmlich ebenfalls delegiert werden. Wenn man das
  192.168.196-Netz mit der Domain linux.test vom Provider zugeteilt
  bekommen hat, muss dieser auch NS-Eintrge fr die reversen-Zonen
  eintragen - genauso wie fr die normalen Zonen. Wenn man die Kette
  von in-addr.arpa zurck zum eigenen Netz verfolgt, wird man ansonsten
  ein Loch in der Kette finden. blicherweise ist diese Lcke beim
  eigenen Serviceprovider zu finden. Wenn dieses Loch gefunden wird,
  kontaktiert man am besten seinen Provider, damit dieser den Fehler
  behebt.


  4.5.2.  Man besitzt ein klassenloses Subnetz.

  Dieser Punkt ist ein etwas schwieriger Punkt, aber Subnetze ohne
  Klasse sind in der letzten Zeit sehr wichtig geworden und vermutlich
  hat man davon eins, es sei denn man gehrt zu einer mittelgrossen
  Firma.


  Klassenlose Subnetze halten das Internet in diesen Tagen berhaupt
  noch am Leben. Bereits vor einigen Jahren gab es viele Probleme damit,
  dass die IP-Adressen knapp wurden. Die netten Leute im IETF (der
  Internet Engineering Task Force, die das Internet verwalten")
  steckten Ihre Kpfe zusammen und lsten das Problem. Und mussten dafr
  einen Preis bezahlen - den Preis, dass man kleinere Netze als die der
  Klasse C bekommen kann - und dadurch kann einiges schiefgehen. Dazu
  kann ich nur raten unter


       http://www.acmebw.com/askmrdns/00007.htm


  nach einer guten Erklrung dieses Problems und wie man damit umgeht,
  zu fragen.


  Gelesen? Ich werde hier nicht weiter darauf eingehen.


  Der erste Teil des Problems ist, dass der eigene ISP die Techniken
  verstanden haben muss, die dort erklrt werden. Nicht alle kleinen
  ISPs verstehen es und setzen es auch um. Wenn dem so ist, muss man
  ihnen das eventuell erklren und vor allem sehr ausdauernd sein. Damit
  das funktioniert, sollte man allerdings sicher sein, dass man selber
  das Ganze verstanden hat ;-). Erst dann wird der Provider auch eine
  schne reverse Zone auf seinem Server einrichten, die man mit nslookup
  berprfen kann.



  Der zweite und letzte Teil dieses Problems ist, dass man die Technik,
  die dahinter steht, richtig verstehen muss. Jeder der noch unsicher
  ist, sollte auf die Seite zurckgehen und es noch einmal lesen. Dann
  kann man sich daran machen, die eigene Klassenlose reverse-Zone
  einzurichten, wie es dort beschrieben wird.


  Eine Falle wartet hier allerdings immernoch. Alte Resolver-Programme
  werden nicht in der Lage sein, dem CNAME-Trick in der resolve-Kette zu
  folgen und werden die Rechner nicht aufschlsseln knnen.  Das kann
  dann dazu fhren, dass der Dienst den Rechner in eine falsche
  Zugriffsklasse einordnet und einem den Zugriff verweigert oder
  hnliches.  Wenn man auf so einen Service stt, bleibt als einzige
  Mglichkeit (die ich kenne), dass der ISP einen PTR-Eintrag direkt in
  die klassenlose Zonen-Datei schreibt - als Ersatz fr den CNAME-Trick.


  Einige ISPs bieten andere Wege, um dieses Problem zu behandeln, an.
  Ein Beispiel knnen WWW-basierte Formulare sein, in die man seine
  reversen-Eintrge machen kann oder andere automatisierte Systeme.


  5.

  Eine existierendes Domainbeispiel

  Leser haben mir vorgeschlagen, dass ich ein existierendes Beispiel
  einer funktionierenden Domain zustzlich zu dem Lehrbeispiel
  hinzufge.


  Ich benutze dieses Beispiel mit Erlaubnis von David Bullock von
  LAND-5.  Diese Dateien stammen vom 24. September 1996 und sind
  nachtrglich von mir editiert worden, damit sie die
  Bind8-Restriktionen und Erweiterungen enthalten. Also unterscheiden
  sich diese Daten ein wenig von denen, die man erhlt, wenn einer der
  LAND-5 Nameserver befragt wird.


  5.1.  /etc/named.conf (bzw. /var/named/named.conf)

  Hier findet man die Zonenabschnitte, fr die zwei bentigten reversen
  Zonen: Das 127.0.0-Netz und auch das LAND-5 206.6.177-Subnetz.
  Ausserdem ist eine primary-Zeile fr die LAND-5-Forward-Zone
  land-5.com enthalten. Ausserdem ist zu beachten, dass David die
  Dateien nicht in ein Verzeichnis mit dem Namen pz legt, wie ich das in
  dieser HOWTO gemacht habe. Er benutzt ein Verzeichnis namens zone.



















  // Boot-Datei fuer den LAND-5 Nameserver

  options {
          directory "/var/named";
  };

  zone "." {
          type hint;
          file "root.hints";
  };

  zone "0.0.127.in-addr.arpa" {
          type master;
          file "zone/127.0.0";
  };

  zone "land-5.com" {
          type master;
          file "zone/land-5.com";
  };

  zone "177.6.206.in-addr.arpa" {
          type master;
          file "zone/206.6.177";
  };





  Sofern man dieses Beispiel in die eigene named.conf-Datei packt, wovon
  abzuraten ist, sollte man bitte auch noch ein notify no; in die
  Zonenabschnitte fr die zwei land-5-Zonen schreiben, um Konflikte zu
  vermeiden.


  5.2.  /var/named/root.hints

  Hierbei ist zu beachten, dass diese Datei relativ dynamisch ist. Die
  hier aufgelistete ist alt. Jetzt sollte besser eine mit dig neu
  erzeugte benutzt werden, wie bereits beschrieben wurde.

























  ; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET.
  ; (1 server found)
  ;; res options: init recurs defnam dnsrch
  ;; got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
  ;; QUERY SECTION:
  ;;      ., type = NS, class = IN

  ;; ANSWER SECTION:
  .                     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.

  ;; ADDITIONAL SECTION:
  G.ROOT-SERVERS.NET.     5w6d16h IN A    192.112.36.4
  J.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.10
  K.ROOT-SERVERS.NET.     5w6d16h IN A    193.0.14.129
  L.ROOT-SERVERS.NET.     5w6d16h IN A    198.32.64.12
  M.ROOT-SERVERS.NET.     5w6d16h IN A    202.12.27.33
  A.ROOT-SERVERS.NET.     5w6d16h IN A    198.41.0.4
  H.ROOT-SERVERS.NET.     5w6d16h IN A    128.63.2.53
  B.ROOT-SERVERS.NET.     5w6d16h IN A    128.9.0.107
  C.ROOT-SERVERS.NET.     5w6d16h IN A    192.33.4.12
  D.ROOT-SERVERS.NET.     5w6d16h IN A    128.8.10.90
  E.ROOT-SERVERS.NET.     5w6d16h IN A    192.203.230.10
  I.ROOT-SERVERS.NET.     5w6d16h IN A    192.36.148.17
  F.ROOT-SERVERS.NET.     5w6d16h IN A    192.5.5.241

  ;; Total query time: 215 msec
  ;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET.  198.41.0.4
  ;; WHEN: Sun Feb 15 01:22:51 1998
  ;; MSG SIZE  sent: 17  rcvd: 436





  5.3.  /var/named/zone/127.0.0

  Hier ist nur das Minimum enthalten: Der obligatorische SOA-Eintrag und
  ein Eintrag, der 127.0.0.1 in localhost umwandelt. Beide Eintrge sind
  ntig, allerdings sollte diese Datei nicht mehr enthalten. Sie wird
  vermutlich niemals mehr gendert werden mssen, es sei denn der
  Nameserver oder die hostmaster-Adresse ndert sich.











  @               IN      SOA     land-5.com. root.land-5.com. (
                                  199609203       ; Serial
                                  28800   ; Refresh
                                  7200    ; Retry
                                  604800  ; Expire
                                  86400)  ; Minimum TTL
                          NS      land-5.com.

  1                       PTR     localhost.





  5.4.  /var/named/zone/land-5.com

  Hier sieht man den notwendigen SOA-Eintrag und NS-Eintrge. Man kann
  erkennen, dass er einen Zweit (Secondary)-Nameserver mit der Adresse
  ns2.psi.net hat. Es sollte brigens immer ein zweiter Nameserver als
  Backup-Server zur Verfgung stehen. Auerdem kann man sehen, dass es
  einen Hauptrechner gibt, der land-5 heit und viele verschiedene
  Internetdienste anbietet - und dass dieser als Alternative zu A-
  Eintrgen mit CNAMEs realisiert wurde.


  Der SOA-Eintrag enthlt die Informationen ber den Ursprung der
  Zonendatei (land-5.com) und dass die Kontaktperson root@land-5.com
  ist. hostmaster ist die meistens benutzte Adresse fr die
  Kontaktperson. Die Seriennummer ist in dem Format jjjjmmtt, wobei noch
  die Seriennummer des laufenden Tages angehngt wird; vermutlich
  handelt es sich um die sechste Version der Zonendatei vom 20.
  September 1996. Man sollte immer daran denken, dass die Seriennummer
  monoton ansteigen muss. Da dieses Beispiel eine einstellige Nummer fr
  die Seriennnummer nutzt, knnen maximal neun nderungen an einem Tag
  gemacht werden knnen.  Darum empfehle ich die Verwendung von zwei
  Stellen fr die Seriennummer.






























  @       IN      SOA     land-5.com. root.land-5.com. (
                          199609206       ; serial, todays date + todays serial #
                          8H              ; refresh, seconds
                          2H              ; retry, seconds
                          1W              ; expire, seconds
                          1D )            ; minimum, seconds
                  NS      land-5.com.
                  NS      ns2.psi.net.
                  MX      10 land-5.com.  ; Primary Mail Exchanger
                  TXT     "LAND-5 Corporation"

  localhost       A       127.0.0.1

  router          A       206.6.177.1

  land-5.com.     A       206.6.177.2
  ns              A       206.6.177.3
  www             A       207.159.141.192

  ftp             CNAME   land-5.com.
  mail            CNAME   land-5.com.
  news            CNAME   land-5.com.

  funn            A       206.6.177.2

  ;
  ;       Workstations
  ;
  ws-177200       A       206.6.177.200
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177201       A       206.6.177.201
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177202       A       206.6.177.202
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177203       A       206.6.177.203
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177204       A       206.6.177.204
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177205       A       206.6.177.205
                  MX      10 land-5.com.   ; Primary Mail Host
  ; {Many repetitive definitions deleted - SNIP}
  ws-177250       A       206.6.177.250
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177251       A       206.6.177.251
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177252       A       206.6.177.252
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177253       A       206.6.177.253
                  MX      10 land-5.com.   ; Primary Mail Host
  ws-177254       A       206.6.177.254
                  MX      10 land-5.com.   ; Primary Mail Host





  Bei genauerer Betrachtung der Nameserver von LAND-5, fllt auf, dass
  die Rechnernamen immer die Form ws_nummer haben. Seit einer der
  letzten der Bind-4-Versionen achtet der named auf Einschrnkungen,
  welche Zeichen in einem Rechnernamen vorkommen drfen. Da die
  angegeben Namen mit Bind-8 auf keinen Fall funktionieren wrden, habe
  ich in der HOWTO die Unterstriche _ durch einen Bindestrich -
  ersetzt.



  Ich sollte noch darauf hinweisen, dass die Workstations keine
  individuellen Namen haben, sondern aus einem Prefix mit den
  angehngten letzten beiden Teilen der IP-Adresse bestehen. Das
  vereinfacht die Wartung zwar erheblich, es ist aber sehr unpersnlich.


  Man kann auerdem sehen, dass funn.land-5.com ein Alias fr land-5.com
  ist, dass aber ein A-Eintrag anstelle eines CNAME-Eintrages gewhlt
  wurde. Wie ich oben bereits sagte, ist diese Vorgehensweise der
  Nutzung von CNAMES vorzuziehen.


  5.5.  /var/named/zone/206.6.177

  Diese Datei wird weiter unten beschrieben.



       @               IN      SOA     land-5.com. root.land-5.com. (
                                       199609206       ; Serial
                                       28800   ; Refresh
                                       7200    ; Retry
                                       604800  ; Expire
                                       86400)  ; Minimum TTL
                               NS      land-5.com.
                               NS      ns2.psi.net.
       ;
       ;       Servers
       ;
       1       PTR     router.land-5.com.
       2       PTR     land-5.com.
       2       PTR     funn.land-5.com.
       ;
       ;       Workstations
       ;
       200     PTR     ws-177200.land-5.com.
       201     PTR     ws-177201.land-5.com.
       202     PTR     ws-177202.land-5.com.
       203     PTR     ws-177203.land-5.com.
       204     PTR     ws-177204.land-5.com.
       205     PTR     ws-177205.land-5.com.
       ; {Many repetitive definitions deleted - SNIP}
       250     PTR     ws-177250.land-5.com.
       251     PTR     ws-177251.land-5.com.
       252     PTR     ws-177252.land-5.com.
       253     PTR     ws-177253.land-5.com.
       254     PTR     ws-177254.land-5.com.





  Die reverse Zone ist der unbeliebteste Teil der Einrichtung eines
  Nameservers. Sie dient dazu, den Rechnernamen herauszufinden, wenn nur
  die IP-Adresse bekannt ist. Wenn man zum Beispiel einen IRC-Server in
  Norwegen betreibt und nur Clients aus Norwegen und anderen
  Skandinavischen Lndern zulassen mchte, hat man die Mglichkeit,
  durch eine C-Bibliothek die IP-Nummer der gerade verbundenen Maschine
  zu bekommen, da diese mit jedem Datenpaket ber das Netz geschickt
  wird. Jetzt kann man eine Funktion namens gethostbyaddr() aufrufen,
  die den Namen anhand einer bergebenen IP-Nummer herausfindet.
  gethostbyaddr() fragt dazu einen DNS-Server, der dann das DNS-System
  nach einem zu der IP-Nummer gehrigen Namen durchsucht. Wenn die
  Verbindung zum Beispiel von ws-177200.land-5.com ausgeht, liefert die
  C-Funktion die IP-Adresse 206.6.177.200. Um den Namen des Rechners
  herauszufinden, mssen wir 200.177.6.206.in-addr.arpa finden.  Der
  DNS-Server geht dann ber die arpa.-Server, dann findet er in-
  addr.arpa.-Server, folgt der Route ber 206, 6 und zum Schluss findet
  er den Server fr die 177.6.206.in-addr.arpa-Zone bei LAND-5. Dort
  wird er schlussendlich die Antwort bekommen, dass ein PTR
  ws-177200.land-5.com-Eintrag existiert. Das bedeutet, dass der zu der
  IP-Nummer 206.6.177.200 gehrende Name ws-177200.land-5.com ist. Genau
  wie die obige Beschreibung ist auch das ein wenig fiktiv - entspricht
  aber ungefhr dem tatschlichen Ablauf.


  Zurck zum IRC-Server-Beispiel. Der IRC-Server nimmt nur Verbindungen
  aus Skandinavischen Lndern wie *.no, *.se oder *.dk an. Der Rechner
  ws-177200.land-5.com passt zu keinem der genannten Lnder, darum wird
  der Server die Verbindung ablehnen. Wenn es keine reverse Umwandlung
  fr 206.6.177.200 durch die inn-addr.arpa-Zone gbe, wrde der Server
  den Rechnernamen nicht herausfinden knnen und msste die IP-Nummer
  206.6.177.200 mit *.no, *.se und *.dk vergleichen - keine Domain wrde
  zutreffen.


  Es gibt viele Leute, die behaupten, dass reverse Mappings nur fr
  Server wichtig sind oder berhaupt keinen Sinn haben. Das ist falsch:
  Viele FTP, News, IRC und sogar einige HTTP (WWW)-Server akzeptieren
  keine Verbindungen von Rechnern ohne Namen. Also sind reverse Mappings
  ein muss bei der Verwaltung eines eigenen Nameservers.


  6.  Wartung

  Es gibt einen Punkt, der bei der Administration von  Nameservern
  beachtet werden muss - wenn man mal davon absieht, dass der Nameserver
  funktionieren sollte - und das ist die Aktualisierung der root.hints-
  Datei. Der einfachste Weg hierfr ist die Benutzung von dig.  Zuerst
  startet man dig ohne Parameter, dann bekommt man die Datei root.hints,
  die zum eigenen Server gehrt. Dann wird einer der aufgelisteten root-
  Server mit dig @rootserver befragt. Die Ausgabe dieses Befehls sieht
  erstaunlicherweise nach einer root.hints-Datei aus. Die Ausgabe wird
  in einer Datei gespeichert (dig @e.root-servers.net . ns
  >root.hints.new) und ersetzt dann die alte root.hints-Datei.


  Nicht vergessen, im Anschluss an den Austausch der Cache-Datei den
  named neu zu laden.


  Al Longyear hat mir das folgende Skript geschickt, das automatisch die
  root.hints-Datei aktualisieren kann. Man erstellt einen Eintrag in die
  Crontab, um es einmal im Monat zu starten und kann es dann vergessen.
  Das Skript geht davon aus, dass der E-Mail-Versand funktioniert und
  dass es einen Alias namens hostmaster gibt. Es muss noch verndert
  werden, damit es mit dem eigenen Setup bereinstimmt.















  #!/bin/sh
  #
  # Dieses Skript aktualisiert einmal im Monat die Nameserver-Cache-Datei.
  # Es wird durch einen Cron-Eintrag gestartet.
  #
  # Original von Al Longyear
  # An bind8 angepasst von Nicolai Langfeldt
  # Verschiedene Problem-Reports durch David A. Ranch
  # Ping-Test vorgeschlagen von Martin Foster
  # bersetzung von Thomas "Balu" Walter
  #
  (
   echo "To: hostmaster <hostmaster>"
   echo "From: system <root>"
   echo "Subject: Automatisches Update der root.hints Datei"
   echo

   PATH=/sbin:/usr/sbin:/bin:/usr/bin:
   export PATH
   cd /var/named

   # Sind wir online? Ein Server beim Provider anpingen...
   case `ping -qnc some.machine.net` in
     *'100% packet loss'*)
          echo "Das Netz ist DOWN. root.hints wurde NICHT upgedated"
          echo
          exit 0
          ;;
   esac

   dig @rs.internic.net . ns >root.hints.new 2>&1

   case `cat root.hints.new` in
     *NOERROR*)
          # Funktioniert...
          :;;
     *)
          echo "Das Update der root.hints Datei ist FEHLGESCHLAGEN."
          echo "Dig hatte die folgende Ausgabe:"
          echo
          cat root.hints.new
          exit 0
          ;;
   esac

   echo "Die root.hints Datei wurde mit den folgenden Einstellungen aktualisiert:"
   echo
   cat root.hints.new

   chown root.root root.hints.new
   chmod 444 root.hints.new
   rm -f root.hints.old
   mv root.hints root.hints.old
   mv root.hints.new root.hints
   ndc restart
   echo
   echo "Der Nameserver wurde neu gestartet, um das Update abzuschliessen."
   echo "Die ursprngliche root.hints Datei heisst jetzt /var/named/root.hints.old."
  ) 2>&1 | /usr/lib/sendmail -t
  exit 0






  Einige Leser haben mir geschrieben, dass die root.hints-Datei auch per
  FTP von internic zu bekommen ist. Man sollte aber nicht FTP benutzen,
  um die Datei zu aktualisieren. Die oben gezeigte Version ist netter
  gegenber dem Netz und Internic.


  7.

  Umstieg von der Version 4 zu Version 8

  Dieser Abschnitt war ursprnglich eine Beschreibung, wie man bind 8
  benutzt. Er stammte von David E. Smith (dave@bureau42.ml.org). Ich
  habe ihn an die aktuellen Gegebenheiten angepasst.


  Es gibt hierzu nicht viel zu tun. Ausser dass die Datei named.boot
  jetzt named.conf heisst, hat sich  nichts gendert. Bind 8 beinhaltet
  ausserdem ein Perl-Skript, dass die Dateien alten Stils in den neuen
  Stil umwandelt.  Als Beispiel eine named.boot-Datei im alten Stil -
  geschrieben fr einen Caching-only Nameserver:



       directory /var/named
       cache   .                             root.hints
       primary 0.0.127.IN-ADDR.ARPA            127.0.0.zone
       primary localhost                       localhost.zone




  Man tippt in der Kommandozeile, im Verzeichnis bind8/src/bin/named (es
  wird davon ausgegangen, dass man einen bind8 im Quellcode hat. Im
  Falle eines Binrpaketes sollte das Skript irgendwo anders liegen -
  aber ich bin mir nicht sicher wo...):



       ./named-bootconf.pl < named.boot > named.conf




  Dieses erzeugt eine named.conf-Datei:






















  // generated by named-bootconf.pl

  options {
          directory "/var/named";
  };

  zone "." {
          type hint;
          file "root.hints";
  };

  zone "0.0.127.IN-ADDR.ARPA" {
          type master;
          file "127.0.0.zone";
  };

  zone "localhost" {
          type master;
          file "localhost.zone";
  };





  Dieses funktioniert fr alle Einstellungen, die in einer named.boot-
  Datei gemacht werden. Leider werden neue und verbesserte
  Konfigurationsoptionen von bind 8 nicht untersttzt. Hier ist eine
  erweiterte named.conf-Datei, die dasselbe macht, allerdings um ein
  paar Optionen erweitert wurde.



       // Dies ist eine Konfigurationsdatei fr den named
       // (fr BIND 8.1 oder spter). Sie sollte normalerweise
       // als /etc/named.conf installiert werden. Der einzige
       // Unterschied zu der einfachsten named.conf-Version
       // (zustzlich zu diesem Kommentar :) ist, dass der
       // Kommentar der directory-Zeile entfernt wurde, da
       // ich bereits die Zonendateien in /var/named hatte.

       options {
               directory "/var/named";
               datasize 20M;
       };

       zone "localhost" IN {
               type master;
               file "localhost.zone";
       };

       zone "0.0.127.in-addr.arpa" IN {
               type master;
               file "127.0.0.zone";
       };

       zone "." IN {
               type hint;
               file "root.hints";
       };






  In der Bind 8 Distribution findet man im Verzeichnis
  bind8/src/bin/named/test diese und andere Dateien, die die meisten
  Leute nur noch anpassen brauchen und die dann sofort benutzt werden
  knnen.


  Das Format fr die Zonendateien und die root.hints-Datei ist identisch
  zur alten Version. Genauso wie die Befehle um sie zu aktualisieren.


  8.

  Fragen und Antworten

  Lest bitte diesen Abschnitt, bevor Ihr mir mailt.


  1. Mein named verlangt eine named.boot-Datei


     Du liest die falsche HOWTO. Benutze den Bind Version 8 oder lies
     die alte englischsprachige HOWTO, die sich mit Bind 4 beschftigt
     unter folgender Adresse:


       http://www.mathh.uio.no/~janl/DNS/



  2. Wie benutze ich DNS aus einer Firewall-geschtzten Umgebung?


     Ein Tipp: forward only;, eventuell wird auch noch



         query-source port 53;





  innerhalb des Optionen-Teils der named.conf-Datei bentigt, wie
  bereits im Beispiel in dem ``Ein caching-only-Nameserver''-Abschnitt
  beschrieben wurde.


  3. Wie bringe ich den DNS dazu, durch eine Anzahl verfgbarer Adressen
     fr einen Service zu rotieren, um einen Load-Balancing-Effekt oder
     hnliches zu erzielen (zum Beispiel fr www.ausgelastete.site)?


     Hierzu macht man mehrere A-Eintrge fr www.ausgelastete.site und
     benutzt bind 4.9.3 oder spter. Dann wird der Nameserver
     automatisch durch die Adressen rotieren. Das funktioniert nicht mit
     lteren Versionen des Bind.


  4. Ich mchte DNS in einem (geschlossenen) Intranet benutzen. Wie
     macht man das?


     Man lt die root.hints-Datei weg und erstellt nur Zonendateien.
     Das bedeutet natrlich auch, dass man nicht andauernd eine neue
     hints-Datei besorgen muss.

  5. Wie erstelle ich einen Secondary (Slave) Nameserver?


     Wenn der primre (Master-)Server die Adresse 127.0.0.1 hat, fgt
     man eine Zeile wie die folgende in die named.conf-Datei des
     Secondary-Servers ein:



         zone "linux.test" {
               type slave;
               file "sz/linux.test";
               masters { 127.0.0.1; };
         };





  Man kann auch mehrere Master-Server fr die Zone angeben, indem die
  zustzlichen Server durch Semikolons getrennt zur masters-Liste
  hinzugefgt werden.


  6. Bind soll auch laufen, wenn keine Verbindung zum Netz besteht.


     Es gibt drei Antworten zu diesem Problem:


    Diese Mail stammt von Ian Clark (ic@deakin.edu.au); er beschreibt
     seine Vorgehensweise:


       Bei mir luft der named auf einer Masquerading-Maschine.
       Ich habe zwei root.hints-Dateien. Eine davon heisst
       root.hints.real und enthlt die richtigen root-Servernamen,
       whrend die zweite root.hints.fake heisst und wie folgt
       aussieht:



       ; root.hints.fake
       ; Diese Datei enthlt keine Informationen





  Wenn ich offline gehe, wird die root.hints.fake-Datei ber
  die Datei root.hints kopiert und der named neu gestartet.

  Sobald ich online bin, kopiere ich die Datei root.hints.real
  ber die Datei root.hints und starte den named neu.

  Dieses geschieht automatisch in den Dateien ip-down und ip-
  up.

  Bei der ersten Namensanfrage im offline-Modus zu einer
  Domain, zu der der named keine Daten hat, wird die folgende
  Nachricht in die messages geschrieben:



       Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN

  Aber damit kann ich leben.

  So funktioniert es bei mir. Ich kann den Nameserver fr
  lokale Rechner benutzen, wenn ich offline bin - ohne die
  timeout-Wartepause fr externe Domainnamen und wenn ich
  online gegangen bin, arbeitet die Auflsung der externen
  Domainnamen wie erwartet.



    Ausserdem habe ich von Karl-Max Waner Informationen darber
     erhalten, wie sich die Kombination aus Bind, NFS und dem Portmapper
     bei einem Rechner verhlt, der meistens offline ist:


       Ich benutze blicherweise einen eigenen named auf jeder Mas
       chine, die nicht durchgehend ber ein Modem mit dem Internet
       verbunden ist. Der Nameserver fungiert hierbei auss
       chliesslich als Cache, er besitzt keine area of authority
       und erfragt alle seine Informationen von den Servern aus der
       root.cache-Datei. Bei einer Slackware-Distribution wird er
       blicherweise vor dem nfsd und dem mountd gestartet.

       Auf einem meiner Computer (einem Libretto 30 Notebook) hatte
       ich das Problem, dass ein Mount-Versuch von einem anderen
       System in meinem lokalen Netz gelegentlich - aber meistens
       eher nicht funktionierte. Ganz egal, ob ich PLIP, eine PCM
       CIA-Ethernet-Karte oder PPP ber ein serielles Interface
       benutzte.

       Nach einiger Zeit des Ratens und Experimentierens fand ich
       heraus, dass der named in Kombination mit dem nfsd und dem
       mountd, die beim Hochfahren den Portmapper starten, Probleme
       erzeugte.  Als ich den named nach dem nfsd und dem mountd
       startete, trat dieser Fehler nicht wieder auf.

       Da keine Nachteile bei dieser vernderten Boot-Reihenfolge
       zu erwarten sind, empfehle ich jedem dasselbe zu machen, um
       eventuelle Schwierigkeiten zu vermeiden.



    Als Abschluss sollte noch gesagt werden, dass es hierber eine
     HOWTO unter der folgenden Adresse gibt:


       http://www.acmebw.com/askmrdns/#linux-ns



  Hier wird allerdings noch der Bind4 beschrieben; also sollte man das,
  was er dort schreibt, nach Bind8 bersetzen.


  7. Wo speichert der caching-Nameserver seine Daten? Gibt es eine
     Mglichkeit, die Gre dieses Caches zu verndern?


     Der Cache wird komplett im Speicher gehalten und niemals auf die
     Festplatte geschrieben. Jedesmal, wenn der named beendet wird,
     gehen auch die gecachten Daten verloren. Der Cache ist nicht
     steuerbar. Der named verwaltet ihn nach einigen einfachen Regeln -
     mehr nicht. Man kann den Cache oder dessen Gre in keinster Weise
     kontrollieren. Wer das dennoch mchte, kann diesen Fehler durch
     Handarbeit im named-Sourcecode ndern. Natrlich wird dieses nicht
     empfohlen.
  8. Speichert der named den Cache bei einem Neustart? Gibt es eine
     Mglichkeit, diese Option zu aktivieren?


     Nein, der named speichert den Cache nicht, wenn er beendet wird.
     Bei jedem Neustart muss der named daher den Cache von Grund auf neu
     aufbauen. Es gibt keine Mglichkeit, ihn zum Speichern seiner
     Cache-Daten in einer Datei zu bewegen.  Wer das mchte, kann diesen
     Fehler durch Handarbeit im named-Sourcecode ndern, was natrlich
     nicht empfohlen wird.


  9. Wie bekomme ich eine Domain? Ich mchte eine eigene Domain mit dem
     Namen (zum Beispiel) linux-ist-das-beste-betriebssystem.de
     erstellen.  Wie kann ich diese Domain fr mich registrieren lassen?


     Hierfr sollte man seinen Netzwerkprovider um Rat bitten. Er sollte
     in der Lage sein, hierbei zu helfen. Als Hinweis sei noch gesagt,
     dass in den meisten Teilen der Welt fr Domains Geld bezahlt werden
     muss.




  9.

  Wie man ein besserer DNS-Administrator wird.

  Es gibt richtige Dokumentation - sowohl online als auch gedruckt.
  Einige dieser Texte sollte man gelesen haben, um den Schritt von einem
  kleinen zu einem grossen DNS-Administrator machen zu knnen. Das
  gedruckte Standardwerk ist:


       DNS und BIND
       Paul Albitz, Cricket Liu
       O'Reilly
       ISBN 3-89721-160-2


  Ich habe es gelesen - es ist ausgezeichnet. Es beschreibt sowohl
  bind4.9 als auch bind9.

  Einen Abschnitt ber DNS gibt es auch in:


       TCP/IP Netzwerk-Administration
       Craig Hunt
       O'Reilly
       ISBN 3-89721-110-6


  Ein anderes Muss fr gute DNS-Administratoren ist


       Zen and the Art of Motorcycle Maintenance
       Robert M. Pirsig
       ISBN 0-68805-230-4




  Online wird man Informationen unter folgenden Adressen finden


    http://www.dns.net/dnsrd/ (DNS Quellen-Verzeichnis)

    http://www.isc.org/bind.html

  Hier findet man eine FAQ, das Referenzhandbuch Bind Operations Guide
  sowie viele Artikel, Protokolldefinitionen und DNS-Hacks.  Diese und
  die meisten anderen, der unten noch aufgelisteten RFCs, sind ausserdem
  im Bind-Paket enthalten. Ich habe die wenigsten von ihnen gelesen,
  aber ich bin auch kein grosser DNS-Admin. Arnt Gulbrandsen auf der
  anderen Seite hat den BOG gelesen und findet ihn atemberaubend :-).

  Die Newsgruppe

       comp.protocols.tcp-ip.domains

  enthlt Diskussionen ber das DNS.

  Ausserdem gibt es eine Reihe von RFCs, deren wichtigsten vermutlich
  die folgenden sind:



     RFC 2052
        A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location
        of services (DNS SRV), October 1996


     RFC 1918
        Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
        Address Allocation for Private Internets, 02/29/1996.


     RFC 1912
        D. Barr, Common DNS Operational and Configuration Errors,
        02/28/1996.


     RFC 1912 Errors
        B. Barr Errors in RFC 1912, verfgbar unter folgender Adresse:


          http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html



     RFC 1713
        A. Romao, Tools for DNS debugging, 11/03/1994.


     RFC 1712
        C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding of
        Geographical Location, 11/01/1994.


     RFC 1183
        R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, New DNS RR
        Definitions, 10/08/1990.


     RFC 1035
        P. Mockapetris, Domain names - implementation and specification,
        11/01/1987.


     RFC 1034
        P. Mockapetris, Domain names - concepts and facilities,
        11/01/1987.


     RFC 1033
        M. Lottor, Domain administrators operations guide, 11/01/1987.


     RFC 1032
        M. Stahl, Domain administrators guide, 11/01/1987.


     RFC 974
        C. Partridge, Mail routing and the domain system, 01/01/1986.





















































