/usr/share/doc/HOWTO/de-html/DE-DNS-HOWTO-4.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.65">
 <TITLE>DNS HOWTO: Eine »einfache« Domain       </TITLE>
 <LINK HREF="DE-DNS-HOWTO-5.html" REL=next>
 <LINK HREF="DE-DNS-HOWTO-3.html" REL=previous>
 <LINK HREF="DE-DNS-HOWTO.html#toc4" REL=contents>
</HEAD>
<BODY>
<A HREF="DE-DNS-HOWTO-5.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-DNS-HOWTO-3.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-DNS-HOWTO.html#toc4"><IMG SRC="toc.png" ALT="Inhalt"></A>
<HR>
<H2><A NAME="DE-DNS-HOWTO-simple"></A> <A NAME="s4">4.</A> <A HREF="DE-DNS-HOWTO.html#toc4">Eine »einfache« Domain       </A></H2>


<P>Dieser Abschnitt beschreibt, wie man seine eigene Domain 
einrichtet.</P>

<H2><A NAME="ss4.1">4.1</A> <A HREF="DE-DNS-HOWTO.html#toc4.1">Aber zuerst etwas trockene Theorie</A>
</H2>

<P>Bevor es <EM>wirklich</EM> 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 m&ouml;chte, kann es
wenigstens einmal &uuml;berfliegen - bis zu der Beschreibung des Inhalts der
<CODE>named.conf</CODE>-Datei.</P>

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

<P>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 <CODE>prep.ai.mit.edu</CODE> herausfinden will, muss der Nameserver erst
einmal herausfinden, welcher Nameserver f&uuml;r die Domain <CODE>edu</CODE> zust&auml;ndig
ist. Dazu befragt er einen <CODE>.</CODE>-Server, den er dank der
<CODE>root.hints</CODE>-Datei kennt. Der root-Server listet dann die Server f&uuml;r
<CODE>edu</CODE> auf:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nslookup
Default Server:  localhost
Address:  127.0.0.1
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Am Anfang wird ein root-Server befragt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> server c.root-servers.net.
Default Server:  c.root-servers.net
Address:  192.33.4.12
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Hierzu wird die Abfrageart auf NS gesetzt (Nameserver-Eintr&auml;ge):</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> set q=ns
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Nach <CODE>edu</CODE> fragen:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> edu.
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Der abschliessende ».« dieser Anfrage ist sehr wichtig. <CODE>nslookup</CODE> wei&szlig;
dadurch, dass <CODE>edu</CODE> direkt unter der Wurzel zu finden ist (und nicht
unter irgendeiner <CODE>search</CODE>-Domain. So wird die Abfrage beschleunigt).</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Diese Auflistung bedeutet, dass alle <CODE>ROOT-SERVERS.NET</CODE>-Server f&uuml;r
<CODE>EDU.</CODE> zust&auml;ndig sind, also kann einer von denen befragt werden. Wir
fragen bereits den <CODE>C</CODE>-Root-Nameserver. Dann kann die n&auml;chste Ebene des
Domainnamens herausgefunden werden: <CODE>mit.edu</CODE>:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 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
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P><CODE>strawb</CODE>, <CODE>w20ns</CODE> und <CODE>bitsy</CODE> sind alle f&uuml;r <CODE>mit.edu</CODE> zust&auml;ndig.
Einer davon wird ausgew&auml;hlt und es geht eine Ebene tiefer: <CODE>ai.mit.edu</CODE>:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> server W20NS.mit.edu.
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Die Gross-/Kleinschrift ist bei Rechnernamen unwichtig, aber da ich die Daten
per Maus kopiere und hier einf&uuml;ge, sieht die Ausgabe genau wie auf dem
Bildschirm aus.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Also ist <CODE>museli.ai.mit.edu</CODE> ein Nameserver f&uuml;r <CODE>ai.mit.edu</CODE>:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> server MUESLI.AI.MIT.EDU
Default Server:  MUESLI.AI.MIT.EDU
Address:  128.52.39.7
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Jetzt wird der Typ der Anfrage gewechselt. Der Nameserver wurde gefunden,
also wird <CODE>muesli</CODE> gefragt, was er alles &uuml;ber <CODE>prep.ai.mit.edu</CODE>
weiss.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Angefangen bei »<CODE>.</CODE>« wurden so der Reihe nach die Nameserver f&uuml;r jede
einzelne Ebene des Domainnamens gefunden. Wenn hierzu anstelle der vielen
einzelnen Nameserver nur der eigene Nameserver benutzt worden w&auml;re, h&auml;tte
dieser nat&uuml;rlich alle Informationen zwischengespeichert, die auf der Suche
nach dem Rechnernamen aufgetaucht w&auml;ren; so br&auml;uchte er f&uuml;r eine Weile
nicht mehr im Netz nachfragen.</P>

<P>Analog zu der Baumstruktur ist jeder »<CODE>.</CODE>« im Rechnername eine
Verzweigung. Jeder Teil zwischen zwei Punkten ist der Name eines Astes im
Baum. </P>

<P>Man »klettert« auf den Baum, indem man den Rechnernamen nimmt
(<CODE>prep.ai.mit.edu</CODE>) und bei der Wurzel (<CODE>.</CODE>) beginnend die Zweige
hinabsteigt. Der n&auml;chste Zweig in diesem Beispiel w&auml;re <CODE>edu</CODE>. Die n&auml;chste
Ebene erreicht man durch das Umschalten zu dem Nameserver, der diesen Teil
des Namens kennt. Als n&auml;chstes folgt der <CODE>mit</CODE>-Zweig, der an den
<CODE>edu</CODE>-Zweig ankn&uuml;pft (zusammen ergibt das <CODE>mit.edu</CODE>) und besteigt
diesen Zweig wiederum durch Umschalten zu dem Server der die Informationen
f&uuml;r <CODE>mit.edu</CODE> bereitstellt. Der n&auml;chste Zweig lautet <CODE>ai.mit.edu</CODE> 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 <CODE>prep.ai.mit.edu</CODE> - ziemlich einfach, oder?</P>

<P>Eine Domain, &uuml;ber die wenig gesprochen wird, die aber mindestens genauso
wichtig wie alle anderen ist, ist <CODE>in-addr.arpa</CODE>. 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
<CODE>in-addr.arpa</CODE>-Domain verkehrt herum aufgelistet. Wenn man die IP-Adresse
<CODE>192.128.52.43</CODE> hat, arbeitete der named genauso wie im
<CODE>prep.ai.mit.edu</CODE>-Beispiel: Er sucht nach den <CODE>arpa.</CODE>-Servern und dann
nach <CODE>in-addr.arpa.</CODE>-Servern, <CODE>192.in-addr.arpa.</CODE>-Servern,
<CODE>128.192.in-addr.arpa.</CODE>-Servern und nach <CODE>52.128.192.in-addr.arpa.</CODE>
Servern.  Letztendlich findet er dann die Eintr&auml;ge f&uuml;r
<CODE>43.52.128.192.in-addr.arpa.</CODE> Clever, oder? Die Antwort sollte »ja«
lauten ;-). Trotzdem wird diese Umkehrung der IP-Nummern jahrelang f&uuml;r
Verwirrung sorgen.</P>

<P>Ich habe gerade ein wenig geflunkert. Das DNS arbeitet nicht so wie ich
es gerade erkl&auml;rt habe. Aber die Beschreibung ist nahe genug an der
Wahrheit.</P>

<H2><A NAME="ss4.2">4.2</A> <A HREF="DE-DNS-HOWTO.html#toc4.2">Die eigene Domain</A>
</H2>

<P>Um eine eigene Domain zu erstellen, wird in dieser HOWTO als Beispiel der
Domainname <CODE>linux.test</CODE> benutzt. Einzelne Rechner werden zu dieser Domain
hinzugef&uuml;gt. Es wird eine »test«-TLD benutzt, um sicherzustellen, dass
niemand »da draussen« durch diese Domain gest&ouml;rt wird.</P>

<P>Eins noch, bevor es losgeht: Es sind nicht alle Zeichen in einem
Rechnernamen erlaubt. Diese Einschr&auml;nkung beinhaltet, dass nur die
Buchstaben des englischen Alphabets benutzt werden d&uuml;rfen: a-z, Ziffern
(0-9) und der Bindestrich (»-«). Nochmal, es sollten und d&uuml;rfen keine
anderen Zeichen benutzt werden. Im DNS gibt es keinen Unterschied zwischen
Groos- und Kleinbuchstaben - <CODE>pat.uio.no</CODE> is identisch mit
<CODE>Pat.UiO.No</CODE>.</P>

<P>Die erste wichtige Einstellung wurde bereits durch die folgende Zeile in
der <CODE>named.conf</CODE> gemacht:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Zu beachten ist, dass der »<CODE>.</CODE>« am Ende der Domainnamen in dieser
Datei fehlt. Die Einstellungen definieren die Zone
<CODE>0.0.127.in-addr.arpa</CODE>, dass unser Server der Haupt-(Master)Server daf&uuml;r
ist und dass die Daten in einer Datei mit dem Namen <CODE>pz/127.0.0</CODE>
gespeichert werden. Auch diese Datei existiert bereits:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
@       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.
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Wichtig ist der »<CODE>.</CODE>« am Ende von jedem kompletten Domainnamen in
dieser Datei - im Gegensatz zu der <CODE>named.conf</CODE>-Datei von oben. Es gibt
Leute, die jede Zonendatei mit einem <CODE>$ORIGIN</CODE>-Statement beginnen,
aber das ist &uuml;berfl&uuml;ssig. Der Ursprung (origin) einer Zonendatei (der Punkt
an dem sich die Domain in der DNS-Hierarchie befindet) wird durch den
Zonen-Abschnitt in der <CODE>named.conf</CODE>-Datei definiert. In diesem Fall ist
das <CODE>0.0.127.in-addr.arpa</CODE>.</P>
<P>Die gerade erstellte Zonen-Datei enth&auml;lt 3 Eintragungen (»resource records«
(RRs)). Einen NS RR und einen PTR RR. SOA ist die Ab&uuml;rzung f&uuml;r »Start Of
Authority«. Der Klammeraffe »@« ist ein spezielles Zeichen und steht f&uuml;r den
Ursprung dieser Domain. Die »domain«-Zeile f&uuml;r diese Datei definiert den
Ursprung als 0.0.127.in-addr.arpa, also steht in der ersten Zeile
ausgeschrieben:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa.   IN      SOA ...
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>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 k&ouml;nnte also auch so geschrieben werden:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa.   IN      NS      ns.linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Hierdurch erf&auml;rt das DNS den Rechner, der als Nameserver f&uuml;r die Domain
<CODE>0.0.127.in-addr.arpa</CODE> fungiert: <CODE>ns.linux.test</CODE>. »ns« ist der &uuml;bliche
Name f&uuml;r einen Nameserver - genauso wie Web-Server normalerweise
<CODE>www.</CODE><EM>irgendetwas</EM> heissen. Trotzdem kann nat&uuml;rlich auch jeder
beliebige andere Name benutzt werden.</P>

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

<P>Der SOA-Eintrag steht am Anfang von <EM>jeder</EM> Zonendatei. Ihn sollte es
in jeder Datei nur ein einziges mal geben. Dieser Eintrag beschreibt die
Ursprungszone (<CODE>linux.test</CODE>), wer f&uuml;r den Inhalt der Domaindaten dieser
Zone verantwortlich ist (<CODE>hostmaster@linux.test</CODE>) - man sollte hier seine
eigene E-Mail-Adresse einf&uuml;gen oder besser den &uuml;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 &uuml;bernommen werden,
sollte man auf der sicheren Seite sein.</P>

<P>Jetzt wird der named neu gestartet (der Befehl hierf&uuml;r ist <CODE>ndc
restart</CODE>) und die Einstellungen werden mit <CODE>nslookup</CODE> kontrolliert:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ 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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Also ist <CODE>nslookup</CODE> in der Lage, den Namen <CODE>localhost</CODE> 
mit der IP-Adresse 127.0.0.1 herauszufinden - hervorragend.</P>

<P>Um jetzt zur&uuml;ck zur Hauptsache - der <CODE>linux.test</CODE>-Domain zu kommen,
wird ein neuer »Zonen«-Abschnitt in die <CODE>named.conf</CODE> eingef&uuml;gt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
zone "linux.test" {
        notify no;
        type master;
        file "pz/linux.test";
};
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Am Ende des Domainnamens in der <CODE>named.conf</CODE>-Datei wird kein
»<CODE>.</CODE>« geschrieben.</P>

<P>In die <CODE>linux.test</CODE>-Zonendatei werden jetzt irgendwelche Testdaten
eingef&uuml;gt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
;
; Zonendatei f&uuml;r 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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Zwei Anmerkungen m&uuml;ssen &uuml;ber den SOA-Eintrag gemacht werden.
<CODE>ns.linux.test</CODE> <EM>muss</EM> ein Rechner mit einem g&uuml;ltigen A-Record sein.
Es ist nicht erlaubt, einen CNAME-Eintrag im SOA-Abschnitt zu benutzen. Der
Name muss &uuml;brigens nicht »ns« lauten, es kann auch jeder andere g&uuml;ltige
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 regelm&auml;ssig gelesen wird. Alle E-Mails, die sich
auf das DNS beziehen, werden an diese Adresse geschickt. Genauso wie der
Rechnername nicht unbedingt <CODE>ns</CODE> sein muss, kann auch hier eine andere
g&uuml;ltige E-Mail-Adresse benutzt werden, aber oft wird davon ausgegangen,
dass auch die »hostmaster«-Adresse existiert und gelesen wird.</P>

<P>Es gibt in dieser Datei noch einen neuen RR-Typen - den MX oder Mail
eXchanger. Dieser Eintrag liefert Mailservern die Adresse zur&uuml;ck, an die
E-Mails geliefert werden sollen, die nach <CODE>jemandem@linux.test</CODE> geschickt
werden. In diesem Fall nach <CODE>mail.linux.test</CODE> oder <CODE>mail.friend.test</CODE>.
Die Nummer vor den Mail-Eintr&auml;gen ist die Priorit&auml;t, mit der die Mailserver
ausgew&auml;hlt 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 h&ouml;heren Priorit&auml;tsnummer geschickt werden - zum
Beispiel einen Not-Mailserver <CODE>mail.friend.test</CODE>, der hier die Priorit&auml;t
20 hat.</P>

<P>Der named wird mit Hilfe von <CODE>ndc restart</CODE> neu gestartet und die
Ergebnisse werden wie immer mit <CODE>nslookup</CODE> begutachtet:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ 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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Bei genauerer Betrachtung sollte man einen Fehler entdecken. Die Zeile</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.test     preference = 10, mail exchanger = mail.linux.test.linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>ist falsch. Sie sollte </P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.test     preference = 10, mail exchanger = mail.linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>lauten.</P>

<P>Ich habe diesen Fehler mit Absicht eingebaut, um davon zu lernen :-). In
der Zonendatei findet man den Fehler in der Zeile</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                MX      10 mail.linux.test      ; Erster Mailserver
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>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 angeh&auml;ngt. Dadurch entsteht die Verdoppelung
<CODE>linux.test.linux.test</CODE>. Also ist die richtige Schreibweise entweder</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                MX      10 mail.linux.test.     ; Erster Mailserver
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>oder</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
                MX      10 mail                 ; Erster Mailserver
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Ich benutze die zweite Variante - es ist weniger Tipparbeit. Es gibt einige
Bind-Experten, denen diese Arbeitsweise nicht gef&auml;llt 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 angeh&auml;ngt.</P>

<P>Ich muss noch einmal betonen, dass in der <CODE>named.conf</CODE>-Datei <EM>kein</EM>
»<CODE>.</CODE>« 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.</P>

<P>Und jetzt folgt eine neue Zonendatei mit einigen zus&auml;tzlichen Eintr&auml;gen:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
;
; Zonendatei f&uuml;rlinux.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-Einf&uuml;hrung"
                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"
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Es gib hier wieder einige neue RRs: HINFO (Host INFOrmation -
Rechnerinformation) besteht aus zwei Teilen - es geh&ouml;rt zum guten Ton, beide
Teile anzugeben. Der erste Teil ist die Hardare bzw. die CPU des Systems,
der zweite Teil enth&auml;lt den Namen der Software oder des Betriebssystems des
Rechners. Der Rechner mit dem Namen »ns« enth&auml;lt eine Pentium CPU und l&auml;uft
mit Linux 2.0. CNAME (Canonical Name) ist eine M&ouml;glichkeit, einem Rechner
mehrere Namen zuzuweisen. Also ist www ein Alias f&uuml;r ns.</P>

<P>Die Benutzung von CNAME-Eintr&auml;gen ist ein wenig kontrovers. Unter
Ber&uuml;cksichtigung der folgenden Regeln, sollte es keine Probleme geben. MX,
CNAME oder SOA-Eintr&auml;ge d&uuml;rfen <EM>niemals</EM> auf einen CNAME-Eintrag
verweisen, sondern nur auf A-Records. Aus diesem Grund ist das folgende
nicht erlaubt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
blabar          CNAME   www                     ; NEIN!
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Die richtige Variante lautet:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
blabar          CNAME   ns                      ; JA!
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Man kann davon ausgehen, dass ein CNAME kein g&uuml;ltiger Rechnername f&uuml;r
eine E-Mail-Adresse ist: <CODE>webmaster@www.linux.test</CODE> ist nach den obigen
Einstellungen eine ung&uuml;ltige 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-Eintr&auml;ge zu benutzen (und nat&uuml;rlich
andere wie zum Beispiel MX,...):</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
www             A       192.168.196.2
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Eine Handvoll der alten Bind-Magier empfehlen ebenfalls, <EM>niemals</EM>
CNAME zu benutzen. Die Grundsatzdiskussion »warum oder warum nicht« geh&ouml;rt
aber nicht in diese HOWTO.</P>

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

<P>Die neuen Einstellungen der Bind-Datenbank werden mit <CODE>ndc reload</CODE>
geladen - der named liest daraufhin seine Konfigurationsdateien neu ein.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nslookup
Default Server:  localhost
Address:  127.0.0.1

> ls -d linux.test
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Das bewirkt eine Auflistung aller Eintr&auml;ge. Als Ergebnis erh&auml;lt man:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
[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"
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Sehr sch&ouml;n - man erkennt sofort die &Auml;hnlichkeit zu der Zonendatei
selbst. Mal sehen, was nur f&uuml;r <CODE>www</CODE> ausgegeben wird:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>In anderen Worten: Der richtige Name von <CODE>www.linux.test</CODE> ist
<CODE>ns.linux.test</CODE>. Au&szlig;erdem werden zus&auml;tzliche Informationen &uuml;ber ns
ausgegeben - genug um eine Verbindung aufzubauen, wenn man ein Programm
w&auml;re.</P>

<H2><A NAME="ss4.3">4.3</A> <A HREF="DE-DNS-HOWTO.html#toc4.3">Die umgekehrte Zone (Reverse Zone)</A>
</H2>

<P>Jetzt k&ouml;nnen Programme also die Rechnernamen der Domain linux.test in
die f&uuml;r sie n&ouml;tigen IP-Adressen umwandeln. Zus&auml;tzlich wird aber noch eine
Zone ben&ouml;tigt, die die Umwandlung von IP-Adressen in Rechnernamen erm&ouml;gicht
- eine umgekehrte oder »reverse« Zone. Die Rechnernamen werden von vielen
Programmen (z.B. FTP, IRC, WWW und anderen) zur Entscheidung dar&uuml;ber
herangezogen, ob sie mit einem reden wollen oder nicht - und falls sie es
m&ouml;chten, welche Priorit&auml;t man erh&auml;lt. Um vollen Zugang zu allen
Internetdiensten zu bekommen ist eine umgekehrte Zone n&ouml;tig.</P>

<P>Hierzu wird noch etwas in die <CODE>named.conf</CODE> eingef&uuml;gt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
zone "196.168.192.in-addr.arpa" {
        notify no;
        type master;
        file "pz/192.168.196";
};
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Dieser Eintrag ist dem <CODE>0.0.127.in-addr.arpa</CODE>-Eintrag sehr &auml;hnlich -
auch der Inhalt der Zonendatei ist gleich:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
@       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.
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Jetzt wird der named neu gestartet (<CODE>ndc restart</CODE>) und die gerade
gemachten Einstellungen werden mit <CODE>nslookup</CODE> &uuml;berpr&uuml;ft:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 192.168.196.4
Server:  localhost
Address:  127.0.0.1

Name:    mail.linux.test
Address:  192.168.196.4
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>So, das sieht OK aus. Jetzt werden nochmal alle Einstellungen ausgegeben
und gecheckt:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 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
</PRE>
</CODE></BLOCKQUOTE>
</P>

<P>Das sieht sehr gut aus. Wenn die Ausgabe allerdings nicht mit der obigen
&uuml;bereinstimmt, muss man in der syslog-Datei nach Fehlermeldungen suchen.
Wie das gemacht wird, habe ich ganz am Anfang dieses Abschnitts erkl&auml;rt.</P>

<H2><A NAME="ss4.4">4.4</A> <A HREF="DE-DNS-HOWTO.html#toc4.4">Warnungen</A>
</H2>

<P>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 d&uuml;rfen nicht &ouml;ffentlich im Internet benutzt werden. Darum sind
sie ideal f&uuml;r die Benutzung in einer HOWTO. Der zweite Punkt ist die
<CODE>notify no;</CODE>-Zeile. Sie veranla&szlig;t den named dazu, seine
Zweit-(Secondary)-Server nicht &uuml;ber &Auml;nderungen in den Zonendateien zu
informieren. Denn der Bind Version 8 kann die anderen Server, die in den
NS-Eintr&auml;gen einer Zonendatei stehen, &uuml;ber Neuerungen in einer Zone
informieren. Das ist f&uuml;r den t&auml;glichen Gebrauch sehr praktisch, aber f&uuml;r
private Zonen-Experimente sollte diese Option abgeschaltet werden. Wir
wollen doch nicht das Internet mit unserem Experiment bel&auml;stigen, oder?</P>

<P>Ausserdem ist die Domain nat&uuml;rlich nur ein Test - genauso wie alle
Adressen, die sie beinhaltet. Ein reales Beispiel aus einer existierenden
Domain ist im n&auml;chsten Kapitel zu sehen.</P>

<H2><A NAME="ss4.5">4.5</A> <A HREF="DE-DNS-HOWTO.html#toc4.5">Warum Reverse Lookups nicht funktionieren.</A>
</H2>

<P>Es gibt ein paar Probleme mit Namensaufl&ouml;sungen, wenn die Adressen
r&uuml;ckw&auml;rts aufgeschl&uuml;sselt werden sollen, die zwar selten aber dennoch
auftreten. Bevor ich darauf eingehe, sollte &uuml;berpr&uuml;ft werden, ob die
Reverse Lookups auf dem eigenen Rechner funktionieren. Wenn nicht - zur&uuml;ck
an den Anfang und den Fehler beheben.</P>

<P>Ich werde hier im Detail auf zwei Probleme eingehen, wie sie auftreten
k&ouml;nnen, wenn von ausserhalb des eigenen Netzes auf den Nameserver zugegriffen
wird.</P>

<H3>Die reverse-Zone wurde nicht delegiert.</H3>

<P>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 n&auml;chsten weiterleitet, wie es in dem oberen Theorie-Abschnitt
erkl&auml;rt wurde. Das wurde doch gelesen und verstanden? Wenn die
reversen-Zonen noch nicht funktionieren, zur&uuml;ck an den Anfang und nochmals
genau lesen.</P>

<P>Die reverse Zone muss n&auml;mlich ebenfalls delegiert werden. Wenn man das
<CODE>192.168.196</CODE>-Netz mit der Domain <CODE>linux.test</CODE> vom Provider zugeteilt
bekommen hat, muss dieser auch <CODE>NS</CODE>-Eintr&auml;ge f&uuml;r die reversen-Zonen
eintragen - genauso wie f&uuml;r die »normalen« Zonen. Wenn man die Kette von
<CODE>in-addr.arpa</CODE> zur&uuml;ck zum eigenen Netz verfolgt, wird man ansonsten ein
Loch in der Kette finden. &Uuml;blicherweise ist diese L&uuml;cke beim eigenen
Serviceprovider zu finden. Wenn dieses Loch gefunden wird, kontaktiert man
am besten seinen Provider, damit dieser den Fehler behebt.</P>

<H3>Man besitzt ein klassenloses Subnetz.</H3>

<P>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 geh&ouml;rt zu einer mittelgrossen Firma.</P>

<P>Klassenlose Subnetze halten das Internet in diesen Tagen &uuml;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 K&ouml;pfe zusammen und
l&ouml;sten das Problem. Und mussten daf&uuml;r 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</P>
<P>
<BLOCKQUOTE><CODE>
<A HREF="http://www.acmebw.com/askmrdns/00007.htm">http://www.acmebw.com/askmrdns/00007.htm</A></CODE></BLOCKQUOTE>

nach einer guten Erkl&auml;rung dieses
Problems und wie man damit umgeht, zu fragen.</P>

<P>Gelesen? Ich werde hier nicht weiter darauf eingehen.</P>

<P>Der erste Teil des Problems ist, dass der eigene ISP die Techniken
verstanden haben muss, die dort erkl&auml;rt werden. Nicht alle kleinen ISPs
verstehen es und setzen es auch um. Wenn dem so ist, muss man ihnen das
eventuell erkl&auml;ren 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 sch&ouml;ne reverse
Zone auf seinem Server einrichten, die man mit <CODE>nslookup</CODE> &uuml;berpr&uuml;fen kann.</P>

<P>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 zur&uuml;ckgehen und es noch einmal lesen. Dann kann man sich daran
machen, die eigene Klassenlose reverse-Zone einzurichten, wie es dort
beschrieben wird.</P>

<P>Eine Falle wartet hier allerdings immernoch. Alte Resolver-Programme
werden <EM>nicht</EM> in der Lage sein, dem <CODE>CNAME</CODE>-Trick in der
resolve-Kette zu folgen und werden die Rechner nicht aufschl&uuml;sseln k&ouml;nnen.
Das kann dann dazu f&uuml;hren, dass der Dienst den Rechner in eine falsche
Zugriffsklasse einordnet und einem den Zugriff verweigert oder &auml;hnliches.
Wenn man auf so einen Service st&ouml;&szlig;t, bleibt als einzige M&ouml;glichkeit (die ich
kenne), dass der ISP einen PTR-Eintrag direkt in die klassenlose Zonen-Datei
schreibt - als Ersatz f&uuml;r den CNAME-Trick.</P>

<P>Einige ISPs bieten andere Wege, um dieses Problem zu behandeln, an. Ein
Beispiel k&ouml;nnen WWW-basierte Formulare sein, in die man seine
reversen-Eintr&auml;ge machen kann oder andere automatisierte Systeme.</P>

<HR>
<A HREF="DE-DNS-HOWTO-5.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-DNS-HOWTO-3.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-DNS-HOWTO.html#toc4"><IMG SRC="toc.png" ALT="Inhalt"></A>
</BODY>
</HTML>
doc-linux-de 2003.10-5 / usr / share / doc / HOWTO / de-html / DE-DNS-HOWTO-4.html
