1. Einleitung
In dieser Anleitung wird anhand eines konkreten Beispiels gezeigt, wie Sie in einem Heimnetz einen Nameserver unter SuSE 8.0 betreiben. Man erspart sich dadurch die Pflege der host-Dateien auf den angeschlossenen Rechnern. 
Der Nameserver kann Rechnernamen für das interne Netzwerk verwalten, die aber im Internet nicht sichtbar sind. Außerdem kann dieser Nameserver auch ganz normal die Namen von Rechnern im Internet auflösen und entsprechende Anfragen der Rechner im Heimnetzwerk beantworten. Er kann somit anstelle des Nameservers des Providers auf den Clients eingetragen werden
Vorteilhaft ist so ein eigener Nameserver zum Beispiel, wenn man Software programmiert oder einsetzt (zum Beispiel einen Kerberos-Server), die einen funktionierenden Namensservice benötigt. Ein weiterer Anwendungsfall wäre dann gegeben, wenn man in der Firma einen Nameserver betreut, und zuhause verschiedene Dinge ausprobieren möchte, bevor man sie auf einem Produktionssystem einsetzt.
Hauptsächlich geht es in dieser Anleitung um das Erstellen der Konfigurationsdateien. Nebenbei wird einiges an Information zum DNS-System mitgeliefert.

2. Hintergründe
Die folgende Anleitung geht davon aus, daß Sie wissen was ein Nameserver macht und wie das DNS System grob in der Anwendung funktioniert. Wenn dem so ist, überspringen Sie einfach diesen Abschnitt. Andernfalls lesen Sie weiter :)

Computer im Internet kommunizieren über das Internet Protocol. In diesem Protokoll haben Computer keine Namen, sondern nur Nummern, die IP-Adressen. Als das Internet erfunden wurde und noch Arpanet hieß, konnte man sich die Nummern der drei Rechner noch merken, die da kommuniziert haben.Aber Nummern sind trotzdem unpraktisch. Also hat man den Computern Namen gegeben. Da das Internet Protocol aber nicht mit Namen umgehen kann, mussten diese Namen in IP-Adressen umgewandelt werden. Dies macht der Resolver.
Er sieht dazu in der Datei hosts nach (die es auch unter Windows gibt). Wurden neue Computer an das Internet angeschlossen, so mussten diese in die hosts-Datei eingetragen werden. Schon bald wurde diese Datei zentral gepflegt und an alle angeschlossenen Rechner regelmäßig verteilt. Irgendwann waren es aber zuviele Rechner in dieser Textdatei und auch die Netzbelastung durch die Übertragung der Datei war unbefriedigend. Daher wurde das DNS System erfunden. Ziel war es, die Pflege der Namenszuordnung zu dezentralisieren und die Netzlast zu verringern. Dies wurde durch die Organisation des DNS in einem hierarchischen Baum gelöst. 
Ganz oben im Baum steht die Wurzel, die root. Für Sie ist das Nullzeichen reserviert. Als nächstes folgt die Top-Level-Domain (immer getrennt durch einen Punkt). Dies sind zum Beispiel .com,.org, .netoder auch .de, .fr oder ähnliches. Nach der Top-Level-Domain folgt die Second-Level-Domain. Dies ist die Domain, die Sie zB. üblicherweise für sich als Domainnamen bei einem Registrar registrieren können. Hier auf dieser Seite istag-intra die Second-Level-Domain. Es können nun fast beliebig viele Subdomains gebildet werden, wie zB.webserver.ag-intra.netoder auch meine.domain.heisst.ag-intra.net. 

Wenn nun Ihr Resolver versucht eine Domain aufzulösen, also die entsprechende IP-Adresse zu erfahren, geht er folgendermaßen vor: Erst fragt er bei seinem zuständigen Nameserver mit der gewünschten Domain an. Der Nameserver kennt die Adressen der Root-Nameserver. Diese kennen wieder die Nameserver, die für die angefragte Top-Level-Domain zuständig sind. Nun befragt unser Nameserver diesen Nameserver zur Second-Level-Domain. Er erhält wiederum einen anderen Nameserver genannt, der dann zB. die Subdomain www zu einer IP-Adresse auflösen kann. Diese teilt unser Nameserver dem Resolver mit, und der kann dafür sorgen, daß die eigentliche Kommunikation im Internet beginnt.

3. Szenario
Folgendes Netz soll nun auf dem PC 3 mit einem Nameserver versehen werden:

Auf dem PC 3 soll der Nameserver installiert werden. Der Rechner bietet sich an, da er als Router ja immer an ist. Zum Testen läuft dort auch der Webserver. Der Rechner besitzt zwei Netzwerkkarten. Eine für das interne Netz und eine für den DSL-Zugang (siehe: Konfiguration von DSL als Router mit SuSE 8.0). Die IP-Adresse des DSL-Anschlusses spielt dabei keine Rolle, sondern nur die der Netzwerkkarte im internen Netz. Die PC 1 und 2 sind mehr oder weniger nur Workstations, die den Namerserver für lokale Anfragen im eigenen Netz und auch für alle anderen DNS-Anfragen nutzen.

4. Domains und andere Namen
Bevor wir an die eigentliche Arbeit gehen, müssen wir uns Gedanken über die zu verwendenen Namen machen. Die Namen der Rechner sollten ja bereits feststehen. Nun braucht das Netz jedoch noch eine Domain. Auch die Top-Level-Domain (TLD) verdient Beachtung.
Bei der Top Level Domain ist zu beachten, daß diese nicht mit den definierten TLD's wie zB. .de, .net oder .comin Konflikt gerät. Dies ist eigentlich nur zu gewährleisten, wenn die im RFC 2606 definierten Top-Level-Domains verwendet werden (zB. .test). Es ist jedoch auch möglich, sich selbst eine TLD wie zB. .geek,.netzoder .sumpf auszudenken. Der Konfliktfall macht sich in der Praxis dann bemerkbar, wenn die IANA die selbst ausgedachte TLD offiziell als TLD einführt. 
Dies hätte zB. mit.info passieren können. Wer sich zB. vor 10 Jahren ein Netzwerk mit dieser TLD eingerichtet hat, der wird jetzt die offiziellen.info Rechner im Internet nicht ansprechen können. Sein Nameserver nimmt die Anfragen für .infoentgegen, und beantwortet sie selbst, anstatt bei den Root-Servern nachzufragen, welcher Rechner im Internet zu der entsprechenden Domain gehört. 
Für dieses Beispiel werde ich trotzdem eine selbst ausgedachte TLD verwenden: '.netz' Unser Nameserver behandelt also aus Sicht des Clients die Endung .netz genauso wie er die Endung .debehandeln würde. Mit dem Unterschied, daß er Anfragen zu .netzselbst beantwortet, und bei Anfragen zu .de erst im Internet nachfragt.
Als Second-Level-Domain für dieses Beispiel verwende ich heim. Dies entspricht in der 'Internetwelt' zum Beispiel dem ag-intravon ag-intra.net.
Der vollständige Domainname für unser Beispiel lautet alsoheim.netz.

5. Beteiligte und Auszug aus demnamed.conf File
Wer ist eigentlich bei der Nameservergeschichte beteiligt ? bind8 steht für 'Berkley Internet Name Domain' Version 8. Es handelt sich dabei um ein Programmpaket mit allen möglichen Tools zum Thema DNS (Domain Name Service). Dazu gehört unter anderem auch der Nameservernamed. 
Dieser Nameserver liest beim Start seine Konfigurationsdatei/etc/named.conf ein. In dieser Datei können einige Einstellungen zur Funktionsweise gemacht werden. Außerdem befinden sich dort Einträge für die Zonefiles. Unter anderem ist der Dateiname für die jeweiligen Zonefiles dort eingetragen. Diese Zonefiles liegen im allgemeinen und unter SuSE 8.0 in dem Verzeichnis/var/named/. Die Dateinamen sind frei wählbar, da sie ja in der Konfigurationsdatei genannt werden. Beim Aufbau der Zonefiles ist der Zonenname unter Umständen wichtig. Daher hier ein Auszug zu einem Zonefile aus der /etc/named.conf:

zone "heim.netz" in {
    type master;
    file "/var/named/db.heim.netz";
};

Das Wichtige ist, daß die Bezeichnung der Zone aus Zeile 1 direkte Auswirkung auf den Aufbau des Zonefiles haben kann. Überall dort im Zonefile, wo das @ Zeichen steht, wird automatisch im Nameserver internheim.netz.ergänzt. Dies wird als Ursprung bezeichnet. Ausserdem wird bei jedem Rechnernamen, der nicht mit einem Punkt endet automatisch heim.netz.ergänzt. 
Der abschließende Punkt bezeichnet übrigens die Root des DNS Systems (eigentlich ist die root das reservierte Nullzeichen ' ', welches durch den Punkt vom Rest der Domain getrennt wird). Nur mit dem Punkt wird ein Domainname zu einem Full Qualified Domain Name (FQDN). Dies ergibt sich aus der baumartig aufgebauten Struktur des DNS-Systems und der darauf aufbauenden Suchstrategie. Auf die Besonderheit mit dem @ wird unter Abkürzungen noch einmal näher eingegangen.

6. Zonefiles (Forward Mapping)
Fangen wir sinnvollerweise hinten mit der Konfiguration des Nameservers an, bei den Zonefiles. Nun beginnt die eigentliche Arbeit. Für jede Zone sind zwei Zonefiles einzurichten. Eine für das sogenannte Forward-Mapping, also die Auflösung von Namen in IP-Adressen und eines für das Reverse-Mapping, das Auflösen von IP-Adressen zu Namen. Kommentare in Zonefiles werden immer mit dem Semikolon ';' eingeleitet und sind bis ans Ende der Zeile gültig. 

Das Zonefile beginnt in der Regel mit Kontrollinformationen (eigentlich ist die Reihenfolge der Einträge egal, aber eine gewisse Ordnung erleichtert die Übersicht). In der Praxis ist das meist nur die TTL (Time to live) als globale Einstellung für das Zonefile. Sie beschreibt, wie lange die Einträge gültig bleiben, bis sie verfallen. Im wesentlichen handelt es sich dabei um eine Information für einen Slave-Server, der seine Daten nach dem Verfall automatisch aktualisieren würde. Die Zeit wird normalerweise in Sekunden angegeben, neuerdings sind aber auch Abkürzungen für Stunden, Tage, Wochen etc. erlaubt. Das sieht dann so aus:

; Zonefile für heim.netz. (eine Kommentarzeile)
$TTL 3h

Dies bedeutet, solange nichts anderes angegeben ist, sind alle Einträge drei Stunden gültig. Die Angabe der globalen TTL ist ab bind8Pflicht.

Nun folgen im allgemeinen die sogenannten Ressource-Records (RR). Davon gibt es verschiedene Typen. In fast jedem Zonefile für Forward Mapping tauchen die Typen SOA, A und ggf. CNAME auf. Weitere Typen werden unten beschrieben.
Der SOA (State of Authority) Eintrag existiert in jedem Zonefile. Dieser Eintrag gibt der Welt bekannt, daß unser Nameserver die Autorität für die Zone heim.netz besitzt, und somit der Nameserver ist, der die Original-Informationen zu unserer Zone besitzt. Der SOA-Record kommt nur einmal in einem Zonefile vor und steht meist am Anfang nach den Kontrollinformationen. In unserem Fall sieht er so aus:

heim.netz.  IN SOA lago.heim.netz. root.lago.heim.netz. (
               200207241 ; Seriennummer
               10800     ; Refresh Zeit
               3600      ; Retry Zeit
               604800    ; Expire
               38400 )   ; negative Caching TTL

Die Reihenfolge der Einträge ist die Domain des Ursprungsrechners, <optional die TTL dieses Records - fehlt hier>, Klasse des Records, Typ des Records, Name des primären Master-Namesservers, eMail-Adresse des verantwortlichen Administrators, Parameter für Slave-Nameserver in den Klammern.
Die Domain des Urspungsrechners ist einfach mal der Name der Zone. In unserem Fall heim.netz. Dabei bitte nicht den Punkt am Ende vergessen. Nun gibt es die Möglichkeit (wie bei jedem Ressource Record) die TTL für genau diesen Eintrag festzulegen. Darauf wird oft verzichtet. Wie auch hier.
Nun kommt die Klasse des Eintrags. Da gibt es wohl einige, aber im Internet kommt immer nur die Klasse IN (=Internet) vor. In Intranets ist es prinzipbedingt genauso.

Der nächste Eintrag ist immer der Typ des Record. In diesem Fall eben SOA. Je nach Typ des Records bestimmen sich dann die nachfolgenden Parameter. In diesem hier sind es einige Zeiten. Diese werden althergebracht in Sekunden angegeben. Eine Ausnahme, und in vielen Fällen die wichtigste Angabe, ist die Seriennummer. Diese trägt man immer als erstes ein. Sie kann bei 1 starten. Oder auch bei dem oben gezeigten Wert. Diese Nummer soll nach jeder Änderung der Datei um einen Wert erhöht werden. Das kann ein beliebiger Wert sein. Wer will, kann von 1 hochzählen. Wie im Beispiel gezeigt, hat es sich durchgesetzt, das Datum zu verwenden, da es in den Wertebereich gut reinpasst. Ergänzt wird das Datum noch durch einen ein- oder zweistelligen Wert. Mir reicht eine Stelle, da ich sicher nicht mehr als 10 mal am Tag die Werte in dieser Datei ändern werde. Wer auf Nummer sicher gehen will, nimmt einen zweistelligen Wert und kann dann bis zu hundert mal am Tag die Werte der Datei ändern. Nach jeder Änderung muss der Wert der Seriennummer höher liegen als vorher. Um wieviel höher spielt dabei keine Rolle (übrigens einer der häufigsten Fehler bei der Wartung des Nameservers: Nach der Änderung zu vergessen die Seriennummer zu erhöhen).

Als nächstes folgt der FQDN des primären Masterservers der Zone. In unserem Fall betreiben wir (entgegen allen Empfehlungen (aber bei nur drei Rechnern im Netz lohnt das nicht anders)) nur einen Nameserver. Daher folgt sein voll aufgelöster Domainname mit dem abschließenden Punkt. Das muss der echte Name (siehe unten) unseres Nameservers sein.
Danach folgt die eMail-Adresse des Administrators. Das ist technisch nicht so wichtig, sollte aber stimmen, da es viel Stunk geben kann, wenn ein Admin nicht erreichbar ist. In unserem Heimnetz spielt es aber kaum eine Rolle. Eine Besonderheit bei dem Parameter ist, daß das übliche @-Zeichen als Punkt notiert wird.

Nach diesen Parametern folgen die Zahlen. Die Klammern sind nur dazu da, um zu signalisieren, daß der Eintrag in mehreren Zeilen umgebrochen ist. Sonst wird der Eintrag für Konsolen unangenehm lang. Wofür sind diese Zahlen nun bestimmt ? Man benötigt sie für den Betrieb von einem oder mehrern Slave Nameservern. Das ist wirklich notwendig, wenn sie einen Nameserver im Internet betreiben. In unserem Heimnetzwerk ist das aber nicht wirklich entscheidend. Trotzdem erklären wir kurz die Bedeutung der Zahlen.

Die Seriennummer muss wie oben erwähnt nach jeder Änderung erhöht werden. Wenn ein Slave sich beim Master meldet fragt er zunächst nach der Seriennummer. Nur wenn diese höher ist als die alte Seriennummer leitet er eine Übertragung der neuen Daten ein.

Darauf folgt die Refresh Zeit. Damit ist geregelt, wie oft die Slave Server die Master Daten prüfen sollen. In der eingestellten Zeit fragen sie bei dem Master Server an, laden den SOA-Record, und schauen ob es eine Veränderung der Seriennummer gibt.

Retry ist der Wert, den der Slave Server verstreichen lässt, bevor er eine erneute Abfrage an den Master Server stellt, wenn er diesen einmal nicht erreichen konnte.

Nun folgt die Expire Zeit. Sollte ihr Slave-Server den Master-Server innerhalb des Expire-Zeitraums nicht erreichen können, wird auch der Slave-Server keine Anfragen zu der entsprechenden Zone mehr beantworten. Die Zone ist dann für ihn ungültig.

Der letzte Wert ist die negative Caching Time. Dies war früher der Minimumwert auf den alle Zone-Einträge ohne TTL automatisch gesetzt wurden. Bei bind8 bedeutet er, das Einträge, die mal gültig waren, maximal diesen Zeitraum lang gecacht werden, und beantwortet werden, sollte es keine positiven Updates des Slave-Servers geben.

Soviel zum SOA-Record. Wie gesagt ist dieser eher von Bedeutung im Betrieb mit Slave-Servern, was aber hier nicht behandelt wird. Dies wäre ein typisches Internet (und nicht Intranet) Praxisbeispiel. Da es aber nunmal ein relativ großer Record ist (optisch) hoffe ich, Ihnen diesen Eintrag mal klar gemacht zu haben.

Konzentrieren wir uns auf den nächsten Eintrag. Dieser ist vom Typ NS. NS steht für Nameserver. In unserem Fall notieren wir ihn einfach so:

heim.netz.  IN NS lago.heim.netz.

Auch hier haben wir wieder den typischen Aufbau eines Ressource-Records. Zunächst kommt der neu bekanntzumachende Name im DNS System, dann fehlt wieder die RR spezifische TTL, es folgt die Klasse IN und der Typ des Record: NS. Soweit sollte uns fast alles bekannt vorkommen. Die Parameter sind wiedertypspezifisch und in diesem Fall handelt es sich um den FQDN (Full Qulaified Domain Name) des Nameservers. Mit diesem Eintrag machen sie der Welt bekannt, wer Ihr primärer Nameserver ist. Im Gegensatz zu dem SOA-Record ist dieser Eintrag eigentlich recht einfach aufgebaut, wie auch alle weiteren Einträge. Unserer Domain wird der als Rechner benannte Nameserver fest zugeordnet.

Als nächstes kommt das, worum es eigentlich geht. Es wird jedem am Netz befindlichen Rechner ein Name zugeordnet. Mit diesem Namen sind dann ale Rechner jeweils auch ansprechbar. Der zugehörige Record-Typ lautet A wie Address.

localhost.           IN A 127.0.0.1
blofeld.heim.netz.   IN A 192.168.100.101
bond.heim.netz.      IN A 192.168.100.102
lago.heim.netz.      IN A 192.168.100.103

Der Aufbau dieser vier Records ist offensichtlich. Bekanntzumachender Name im DNS-System, Klasse, Typ und Parameter. Der Parameter ist hier endlich die IP-Adresse. Hier werden die IP-Adressen tatsächlich den Namen zugeordnet. 
Der erste Eintrag könnte noch verwundern, hat aber nichts magisches an sich. Spricht zB. auf dem Rechner bond ein Nutzer den Host 'localhost' an, dann will er ja auf seinen eigenen Rechner zugreifen. Wenn ich aber dem Client (sieht man unten) gesagt habe, daß er bei Namen immer den Nameserver befragen soll, dann schickt der Client die Frage an den Nameserver 'Wer ist localhost?'. Wenn der Nameserver nun die 127.0.0.1 zurückgibt, greift der Client danach auf diese Adresse zu, und die ist per Definition der eigene Rechner.
Sehr wichtig ist es bei dem localhost-Eintrag auf den Punkt zu achten !! Sonst löst der Name nicht nach localhost sondern nach localhost.heim.netz auf. Und dann bekommen Sie mächtig Probleme wenn Sie sich zB in MySQL einloggen wollen.
 

Bei allen anderen Rechnern werden nun tatsächlich einfach die Namen der IP zugeordnet. Mit dem A-Record wird übrigens der kanonische Name (links) in der Zeile definiert. Dies ist eine echte Namenszuordnung einer Schnittstelle auf einem Rechner zu einer IP-Adresse.

Damit wären wir fast durch das Forward-Zonefile durch, wenn da nicht noch die CNAME-Records wären. Wir haben die folgenden in unserem Zonefile:

www.heim.netz.   IN CNAME lago.heim.netz.
irc.heim.netz.   IN CNAME lago.heim.netz.

Wir wissen, daß auf lago auch ein Webserver läuft. Nun sind wir es nicht gerade gewohnt im Internet als URL 'http://lago.heim.netz' einzutippen. Intuitiv würden wir einen Webserver in unserer Zone lieber mit 'http://www.heim.netz' ansprechen. Wir haben aber keinen dedizierten Rechner der www heisst, sondern nur den Rechner lagomit dem Webserver. Ein Nameserver bekommt es aber trotzdem hin, daß wir mit den gewohnten URL's arbeiten können. Wir können dazu einfach Aliase definieren, die Rechner bezeichnen, die es eigentlich gar nicht gibt, und die der Nameserver quasi umleitet, wenn sie doch angesprochen werden :)

Auch bei den CNAME-Records sollten wir uns den Aufbau gleich denken können. Hier in den Zeilen habe ich offenbar einen IRC- und einen WWW-Server auf lago laufen. Beide können aber mit individuellen Namen angesprochen werden (zB. www.heim.netz). Auf diese Art und Weise können Sie auch Aliase für Mailserver (mail.*, smtp.*, pop.* etc) und ähnliches anlegen. Auch mein demnächst anlaufender Kerberos-Server kann so ein schickes Alias bekommen. 

Es gibt nur ein Problem mit Aliasen: Sie sollten die Alias-Namen niemals auf der rechten Seite derartiger Zonefiles eintragen. Dies führt zu Problemen. Bei den oben genannten zwei Zeilen könnten Sie zB. in der zweiten Zeile auch schreibenirc.heim.netz. IN CNAME www.heim.netz. Das klingt auf den ersten Blick logisch, weil ja www.heim.netz.das gleiche sein sollte wie lago.heim.netz. Ist es aber so nicht. Auf der rechten Seite sollten also nur echte Address-Records stehen. Ansonsten sind sie völlig frei in der Anlage von Aliasen. 
CNAME steht übrigens für canonical-name. Das ist etwas verwirrend, weil man auf die Idee kommen könnte, der Eintrag links in der Zeile wäre der canonical-name. Dort steht aber tatsächlich das Alias. Der canonical-name wird immer hinter dem Record Type aufgeführt und steht somit rechts. 

Hier noch einmal das komplette Zonefile des Beispiels für das Forward Mapping, welches unter /var/named/db.heim.netz abgelegt ist:

; Zonefile (Forward Mapping) für heim.netz.
;
$TTL 3h
heim.netz.  IN SOA lago.heim.netz. root.lago.heim.netz. (
   200207241 ; Seriennummer
   10800     ; Refresh Zeit
   3600      ; Retry Zeit
   604800    ; Expire
   38400 )   ; negative Caching TTL
;
; Nameserver
;
heim.netz.           IN NS lago.heim.netz.
;
; Hosts (kanonisch)
;
localhost.           IN A 127.0.0.1
blofeld.heim.netz.   IN A 192.168.100.101
bond.heim.netz.      IN A 192.168.100.102
lago.heim.netz.      IN A 192.168.100.103
;
; Aliase
;
www.heim.netz.       IN CNAME lago.heim.netz.
irc.heim.netz.       IN CNAME lago.heim.netz.

Damit haben wir das Forwarding Zonefile eigentlich erst einmal erschlagen. Feinheiten lesen Sie etwas später.

7. Zonefiles (Reverse Lookup)
Mit dem ersten Zonefile haben wir jetzt die Fälle abgedeckt, in denen jemand auf dem Client einen Host eingibt, und der Rechner die IP-Adresse zurückbekommt, damit er das Ziel ansprechen kann. Es gibt aber für jede Zone ein weiteres Zonefile für das sogenannte Reverse-Mapping oder auch den Reverse Lookup. Hierbei können Rechner die IP-Adresse an den Nameserver schicken um zu erfahren, wie der entsprechende Host heißt. Dies ist oft für Authentifizierung notwendig. 

Der Aufbau des Reverse Files ist ähnlich wie das Forward File, nur stehen hier die IP-Adressen im Mittelpunkt. Zunächst wird auch wieder wie oben die globale TTL definiert und danach folgt der SOA-Record:

$TTL 3h
100.168.192.in-addr.arpa. IN SOA lago.heim.netz. root.lago.heim.netz. (
   200207241 ; Seriennummer
   10800     ; Refresh Zeit
   3600      ; Retry Zeit
   604800    ; Expire
   38400 )   ; negative Caching TTL

Hier wird die Zeile mit den IP-Adressen unserer Zone begonnen. 192'er IP-Adressen stammen aus dem Bereich der Klasse-C Netze. Durch 192.168.100 ist somit ein komplettes C-Netz beschrieben (maximal 256 Hosts bei Standardnetzmaske 255.255.255.0). 
Die Auflösung der IP's erfolgt über die Nameserver immer rekursiv in umgekehrter Reihenfolge.Da die Auflösung ähnlich wie beim Forward Mapping von hinten beginnt werden die IP-Adressen in diesem Zonefile rückwärts geschrieben. 
Die Verwaltung der IP-Adressen unterliegt ARIN (American Registry for Internet Numbers). Diese verwenden für die Rootserver die Domain in-addr.arpa, wobei das in-addr für Internet Adressen steht (wen wundert es). Eine IP in diesem Zonefile setzt sich also immer aus der umgekehrten IP, der Domain in-addr.arpa und dem Punkt für 'root' zusammen (auch hier wieder: bitte nicht den Punkt vergessen). 
Dementsprechend ähnlich sieht auch der Nameserver Record in dem Zonefile aus:

100.168.192.in-addr.arpa. IN NS lago.heim.netz.

Hier steht wieder die Adresse des Netzes, und der Rest entspicht genau dem NS-Record im Forward-Mapping File. 

Für die folgenden Einträge lernen wir einen neuen Ressource-Record vom Typ PTR (Pointer). So ein Pointer Eintrag löst für jede Netzwerkschnittstelle in unserem Netz einen Namen auf. Dabei darf es sich ausschließlich um die kanonischen Namen handeln, also die links stehenden Namen von A-Records im Forward-Mapping File. CNAME Einträge werden nicht zurückgegeben. Das würde bei uns also so aussehen:

101.100.168.192.in-addr.arpa. IN PTR blofeld.heim.netz.
102.100.168.192.in-addr.arpa. IN PTR bond.heim.netz.
103.100.168.192.in-addr.arpa. IN PTR lago.heim.netz.

Damit ist unser Reverse Mapping File schon zuende. Spezialitäten wie Aliase gibt es hier nicht. Mehrere Namen zu einer IP werden auch nicht zurückgegeben, denn wozu sollte das gut sein ? Der Dateiname für das Reverse-Mapping Zonefile lautet in unserem Beispiel übrigens db.192.168.100. Und der Inhalt des Files sieht dann in der Praxis komplett so aus:

; Zonefile für heim.netz. (Reverse Mapping)
;
$TTL 3h
100.168.192.in-addr.arpa.     IN SOA lago.heim.netz. root.lago.heim.netz. (
   200207241 ; Seriennummer
   10800     ; Refresh Zeit
   3600      ; Retry Zeit
   604800    ; Expire
   38400 )   ; negative Caching TTL
;
; Nameserver
;

100.168.192.in-addr.arpa.     IN NS lago.heim.netz.
;
; Hosts Adressen zeigen auf kanonische Namen
;
101.100.168.192.in-addr.arpa. IN PTR blofeld.heim.netz.
102.100.168.192.in-addr.arpa. IN PTR bond.heim.netz.
103.100.168.192.in-addr.arpa. IN PTR lago.heim.netz.

Es sind noch einige andere Zonefiles in /var/named/ erforderlich. Wir haben aber Glück gehabt. Diese sind bei der Installation durch SuSE netterweise schon angelegt worden. Es handelt sich dabei noch einmal um die Zone für den localhost und seine IP 127.0.0.1, sowie um die Datei root.hints. 
An den Zonefiles für localhost müssen wir nichts verändern. Wenn Sie sich diese mal ansehen, werden Sie den Aufbau anhand der Erklärungen oben schon nachvollziehen können. 

Bei der Datei root.hint, sollte aber sichergestellt sein, daß diese aktuell ist. Eigentlich sollte sie auch etwa alle zwei Monate aktualisiert werden (machen Sie einfach mal man cron :)). Zum Glück gibt es eine feine Methode, um die Datei root.hint up-zu-daten. Sie können dazu den neuen NS-Client dig benutzen. Gehen Sie in das Verzeichnis /var/named/ und geben Sie ein:

> dig @a.root-servers.net . ns > root.hint

Die Ausgabe ist netterweise so formattiert, daß alle Informationen, die nicht der Syntax des root.hint Files entsprechen würden mit Semikolons auskommentiert sind. Die Ausgabe des Befehles, der hier entsprechend umgeleitet wird, entspricht also genau der Syntax der root.hint Datei. Deswegen könnte man den auch als cron-job starten.
Damit sind dann für unser Beispiel alle Dateien in /var/named/ auf dem aktuellen Stand der Dinge. Wir begeben uns jetzt eine Ebene höher.

8. Konfigurationsdatei /etc/named.conf
In dieser Datei können wir sehr viel Eigenschaften des Nameservers einstellen und entsprechend viel Optionen benennen. Unter anderem werden dem Nameserver hier die Dateinamen der Zonefiles benannt. Wir werden hier nur einige der Optionen kennenlernen, die für unseren Anwendungsfall interessant sind. Zunächst eiunmal ist die Datei schon recht nett von SuSE vorkonfiguriert. Eigentlich fehlen nur die Verweise auf unsere beiden neuen Zonefiles. Diese fügen Sie am Ende der Datei ein. Sie lauten:

zone "heim.netz" in {
   type master;
   file "db.heim.netz";
};
zone "100.168.192.in-addr.arpa" in {
   type master;
   file "db.192.168.100";
};

Sie erklären sich nun inzwischen ganz schnell. Wie schon oben unterAuszugaus dem 'named.conf' File geschildert, ist die Bezeichnung der Zone schon wichtig. Im Abschnitt Abkürzungen erkläre ich nochmal genau wieso. Abgesehen von den Abkürzungen muss die Zone dort sowieso genau angegeben werden. Das ist dann die für unser Forward-Mapping und einmal die für das Reverse-Mapping. 
Mit dem type-Eintrag wird signalisiert, daß wir einen primären Master-Server für die Zone betreiben. Andernfalls würden wir dort eben dem Nameserver sagen, daß er zB. als Slave agieren soll. 
Die folgende Zeile ist auch klar, sie gibt den Dateinamen an, unter der der Server die Zonefiles für die Zone findet. Deswegen ist der Name des Zonefiles auch beliebig wählbar. 
Wenn Sie sich in den ganzen DNS HowTo's umsehen, sehen sie die verschiedensten Bezeichnungen. Es gibt noch einige andere Einstellungen, die wir in dem Config-File vornehmen können. Sehen wir uns zuerst die in der SuSE Installation aktiven Einträge an:

options {
   directory "/var/named/";
   cleaning intervall 120;
   statistics-interval 0;
   notify no;
};

Vier Einstellungen hat SuSE aktiv. Die erste betrifft den Speicherort der Zonefiles. Dadurch, das dieser am Anfang festgelegt wird, könnten wir weiter unten, bei der Benennung der Zonefiles auch mit relativen Pfadnamen arbeiten, und könnten /var/named immer weglassen. Diese Einstellung dient dem Komort :)

Das Cleaning Intervall ist der nächste Parameter und betrifft das Caching. Netterweise cacht unser Nameserver Informationen, die er im Internet anfragen muss. Beim der nächsten Anfrage zum gleichen Rechner kann unser Nameserver sich die Zeit für die Anfrage sparen und liefert uns die Information aus seinem Cache. Der Vorteil ist die Geschwindigkeit sowie die Verringerung der Netzlast. Der Nachteil besteht darin, daß die Information veraltet sein kann, und nicht mehr auf den richtigen Rechner verweist. Deswegen räumt bind8 seinen Cache regelmäßig auf, was auch Ressourcen auf unserem Router spart. Das Aufräumen benötigt etwas Rechenzeit. Ein sinnvoller Wert für das Aufräumen dürfte so etwa zwischen 1 Stunde und 12 Stunden liegen. Die Zeit wird hier in Minuten angegeben.

Die nächste Einstellung bestimmt, wieoft named seine Statistiken an den Syslog Daemon ausgibt. Um ehrlich zu sein habe ich mir diese Statistiken noch nie angesehen. Der voreingestellte Wert von 0 verhindert, daß diese Meldung überhaupt ausgegeben wird. Ansonsten könnten Sie hier eine Zeit in Minuten festlegen.

Mit der letzten Einstellung notify können Sie steuern, ob unser Nameserver andere Nameserver benachrichtigt, wenn sich seine Zonendaten ändern. Da unsere Zonendaten aber im Internet nichts zu suchen haben, und wir auch keinen Slave-Server betreiben, stellen wir das notifyfolgerichtig ab.

Dies waren die SuSE Vorgaben. Es findet sich jedoch auch noch eine Zeile in der Datei, die auskommentiert ist. Ich finde, daß sie in unserem Beispiel aber sinnvoll ist. Es handelt sich dabei um die Einstellung allow-query. Mit diesem Parameter können wir steuern, welche Rechner unseren Nameserver überhaupt befragen dürfen. Oder anders herum gesagt, er ignoriert Rechner, die hier nicht aufgeführt sind. Da unser Nameserver ja gar keine Dienste für das Internet anbietet, sondern nur für unser kleines Netzwerk arbeitet, können wir unser Netzwerk hier fest einstellen, und haben wenigstens etwas für die Sicherheit getan :). Wir kommentieren die Zeile also aus und ändern sie für unser Beispiel so ab:

   allow query {127.0.0.1; 192.168.100/24;}

Jetzt dürfen nur der localhost und unser kleines C-Netz Anfragen an den Nameserver stellen. Richtig sicher wäre es gewesen, wenn wir anstelle der Netzbezeichnung alle wirklich existierenden Hosts einzeln aufgezählt hättten, was bei unserem kleinen Netz noch möglich ist. Wird das Netz jedoch größer, dürfen wir nicht vergessen hier entsprechend nachzubessern. Und ich garantiere Ihnen jetzt schon, daß Sie diese Zeile vergessen würden, und nicht wüssten warum ihr neu angeschlossener Rechner den Nameserver nicht nutzen kann.

Nach den Options folgen die Zonendateien. In der named.conf werden bereits drei referenziert, die auch tatsächlich nach der Installation von bind8 unter /var/named/ liegen. Es handelt sich dabei um die root.hints Datei, die man wie oben vorgeschlagen aktualisieren sollte, sowie um die Zonefiles für den localhost, die ja unverändert bleiben dürfen. Und dann folgen die o.g. Zonefiles für unsere neue Zone 'heim.netz'. 

Die ganze named.conf sieht dann so aus (freilich ohne die ganzen Kommentare):

options {
   directory "/var/named/";
   allow query {127.0.0.1; 192.168.100/24;}
   cleaning intervall 120;
   statistics-interval 0;
   notify no;
};

# Standard Zonen
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";
};

#Unsere Zonen
zone "heim.netz" in {
   type master;
   file "db.heim.netz";
};
zone "100.168.192.in-addr.arpa" in {
   type master;
   file "db.192.168.100";
};

Mit dieser Konfiguration sind wir durch die ganzen Einstellungen erstmal durch.

9. DNS starten
Dies ist vergleichsweise einfach, weil wir einfach ein SuSE Tool benutzen. Starten Sie das YaST2 Control Center. Wählen Sie System, und dort den Runlevel Editor. Dort in die Liste der ganzen Dienste gehen, und bei named die Runlevel 3 und 5 einschalten (oder wie es eben beliebt). Dazu noch mit dem entsprechenden Kombobox-Dingens auswählen, daß man den jetzt auch starten möchte. SuSE macht das dann und der Nameserver läuft nun perfekt. Und bei den nächsten reboots wird er auch automatisch gestartet. Soweit so fein.

Bind8 bringt auch noch ein Programm mit, welches den Nameserver händisch starten kann, oder ihm Signale senden kann (was auch mit einem kill -SIGNAL * machbar wäre). Damit kann man ihn neustarten, oder eben auch einfach veranlassen seine named.conf, bzw seine Zonefiles neu einzulesen. Es heisst ndc. Ndclässt sich sowohl interaktiv als auch als Kommando nutzen. Das Komanndo zum Neueinlesen der Zonefiles würde zB.

>ndc reload

heißen. Das gleiche leistet auch ein Signal wie kill -HUP <pid>, was sich vergleichsweise einfach merken lässt, weil derinetd auch auf diese Art und Weise zum Neueinlesen seiner Konfigurationsdateien veranlasst wird..
Die nächste interessante Variante ist das Neustarten des Nameservers, wenn man das Gefühl hat, irgendwie tut er es nicht so richtig (sollte eigentlich kaum möglich sein). Sie lautet

>ndc restart

Jetzt hat diese Variante aber ein arges Problem. In den Runleveln wird der named von SuSE ziemlich vernünftig so gestartet, daß er als Nutzer named und in der Gruppe named startet. Einen ndc restart kann ich aber nur als root durchführen. Anschließend läuft der Nameserver unter der Kennung des Nutzers root. Das ist aus Sicherheitsgründen nicht wirklich gewollt. 
In einer Dokumentation zu ndc habe ich gelesen, daß man dem ndc auch Parameter mit auf den Weg geben kann, die der namedversteht. Hat aber nicht geklappt. Ich habe mich daher dafür entschieden den named so zu starten, wie SuSE es auch tut. Also mache ich einen Neustart mit den beiden folgenden Kommandos:

>ndc stop
>/usr/sbin/named -u named -g named

Damit läuft der named vernünftig unter der Kennungnamed. Die Parameter für den User und die Gruppe konnte ichndcleider nicht einfach so mit an den start geben. Nuja, das Ziel wird trotzdem erreicht.

10. Resolver und Clients konfigurieren
Resolver sind eigentlich keine eigentlichen Programme, sondern Funktionsbibliotheken, die dann von beliebigen Programmen genutzt werden können, um die Dienste eines Nameservers in Anspruch zu nehmen. Unter SuSE 8.0 zB. werden diese Bibliotheken von bind8 mitgeliefert (wenn man diesen denn installiert hat). 
Unter Windows 9x sind diese, soweit ich weiß, im IP-Stack mit enthalten, der dort ziemlich monopolithisch alle Angelegenheiten zum Thema Internet auf TCP/IP Ebene behandelt. Daher die Unterscheidung in Resolver und Client. Drei Sorten von Rechnern werde ich hier kurz behandeln.

Der erste ist der, auf dem unser Nameserver selbst läuft, alsolago. Zumindest bei mir war ja dieser Rechner schon vorher mit dem Internet über DSL verbunden und hatte auch die entsprechenden Nameserver eingetragen. Dies schlägt sich insbesondere in der Datei/etc/resolv.conf nieder, über die die Resolver-Bibliotheken konfiguriert werden. 

Hier gibt es auch einen Stolperstein. Ich hatte die schon einmal passend geändert. Als ich einen Tag später kontrolliert habe, hatte sie einen komplett neuen Inhalt. Es gibt hier eine Einstellung, bei der derpppddiese Datei immer dynamisch neu schreibt, wenn eine Neueinwahl über TDSL erfolgte und dem Rechner eine neue IP zugewiesen wurde. Um diese Konfiguration auszuschalten, ändert man in /etc/sysconfig/network/in der Datei configfolgendermassen (entsprechende Zeile bitte selbst raussuchen):

MODIFY_RESOLV_CONF_DYNAMICALLY="no"

Zurück zur resolv.conf von lago. Insgesamt gibt es fünf verschiedene mögliche Anweisungen in der Konfigurationsdatei. Die erste wäre zB. der lokale Domainname. Der Resolver verwendet den lokalen Domainnamen dann, wenn er einen Namen interpretieren soll, der nicht vollqualifiziert ist. Er probiert also den eingegebenen Namen zuerst mit dem Wert von domain aus, bevor er die Suchliste durchprobiert. Ein Resolver wird immer alle ihm zur Verfügung stehenden Möglichkeiten durchprobieren (einen Namen zu einer IP aufzulösen) bis er entweder den Namen gar nicht auflösen kann, oder bei der ersten erfolgreichen Auflösung eine IP zurückgibt. Dummerweise schließen sichdomainund search (list) Anweisung gegenseitig aus. Aus diesem Grund verzichten wir in diesem Fall auf die domain Anweisung.

Wenn Sie in unserem Netz zB. den Rechner bond anpingen wollen, müssten Sie ja immer schreiben ping bond.heim.netzDurch die Suchliste können Sie aber auch schreiben ping bond. Der Resolver wird dann immer das in der Suchliste genannte Argument an den Hostnamen anhängen, fall der Hostname allein nicht auflöst. Dies klappt auch mit mehreren Domains. Ein Eintrag für unsere Suchliste würde also 

search heim.netz

lauten. Die nächste interessante Anweisung ist die nameserver Anweisung. Mit ihr teilen wir dem Resolver mit, welchen Nameserver er befragen soll. Das ist in unserem Fall der neu Eingerichtete. Als Argument geben wir eine IP-Adresse an, welches die tatsächliche ist, oder auch die 0.0.0.0, die meist als lokaler Host interpretiert wird. Der entsprechende Eintrag lautet

nameserver 0.0.0.0

Was nun aber, wenn unser Nameserver nicht läuft (was in unserem Beispiel fast Quatsch ist, weil es ja auch der Immer-An-Router ist)? Für diesen Fall können wir einen weiteren Nameserver eintragen, der als Reserve angesprochen wird, wenn unser Nameserver gerade nicht kann. In unserem Beispiel bietet es sich an, einen Nameserver des Providers zu verwenden. Bei T-Online wäre das zum Beispiel der von T-Online selbst benannte 194.25.2.129. Eine Folgeanweisung würde also lauten:

nameserver 194.25.2.129

Damit sind dann zwar unsere lokalen Domainnamen nicht mehr auflösbar, aber der Rest des Internet bleibt uns im Falle eines Ausfalls von named erhalten (wie tröstlich).
Nun wäre noch die sortlist Anweisung nützlich, wenn Sie mehrere Netze verwalten, und Antworten aus einem Netz bevorzugen möchten, was hier aber keine Rolle spielt. Auch die options Anweisung macht in unserer Konfiguration keinen Sinn, weshalb wir sie weglassen. 
Sie sollten also dafür sorgen, daß Ihre /etc/resolv.conf etwa folgendes enthält:

nameserver 0.0.0.0
nameserver 194.25.2.129
search heim.netz

Nachdem sie die resolv.conf gespeichert haben, können Sie die Funktion testen, indem Sie

>ping bond

eingeben. Wenn der entsprechende Rechner eingeschaltet ist, und die richtigen Antworten auf das Ping kommen, ist Ihr Router/Nameserver Rechner schon einmal richtig konfiguriert und greift auch selbst auf den Nameserver zu, der auf ihm läuft.

Als nächstes werden wir den Resolver von moneypenny konfigurieren. Sie vermissen den Rechner in der Grafik oben? Korrekt! Er soll nur als Beispiel für einen Linux Client in unserem Netz dienen. Es dürfte nicht sehr überraschen, daß die /etc/resolv.confvonmoneypennygenauso aussieht wie die von lago. Mit einer kleinen Änderung:

nameserver 192.168.100.103
nameserver 194.25.2.129
search heim.netz

Hier können wir ja nicht faul die 0.0.0.0 als IP für unseren eigenen Nameserver angeben. Hier muss die IP des eigenen Nameservers auflago explizit angegeben werden. Damit ist moneypenny auch schon fertig konfiguriert.

Die Konfiguration von Windows Rechnern im Netz ist auch nicht so aufwendig. Gehen Sie in den Dialog Netzwerkeigenschaften (Rechtsklick aufs Netzwerksymbol und Eigenschaften wählen). Wählen Sie dort TCP/IP und Eigenschaften. Wie die IP-Adresse des Rechners einzustellen ist, ist wohl klar. Bei der DNS Einstellung geben Sie praktisch folgendes an:

Das wars eigentlich. Nach dem üblichen Neustart (unter Windows 98) sollte alles mit unserem Nameserver funktionieren. Auch ein ping lago in der DOS-Box sollte klappen. Bei anderen Windows Versionen als 98 ist analog nach den entsprechenden Dialogen vorzugehen.
Damit sind alle beteiligten Resolver konfiguriert.

11. Abkürzungen
Angeblich sind alle Programmierer und Admins faul und wollen nicht soviel tippen. Daher gibt es angeblich auch C. Um ehrlich zu sein glaube ich, daß es C nicht deswegen gibt, um sich viel Tipparbeit zu sparen, sondern eher, um eine Sprache zu haben, die so Scheisse auf den ersten Blick aussieht, daß Aussenstehende keinen Bock auf C haben und so das Herrschaftswissen den wenigen Willigen und Coolen erhalten bleibt, die dann einen Harten machen können *g*.
Um auch unsere Nameserver Zonefiles nicht so schön lesbar wie oben beschrieben aufzusetzen, und etwas kryptischer zu machen, können wir einige Dinge dort kürzen und ersetzen.

Spaß beiseite, es gibt tatsächlich auch einige Abkürzungen, die das Zonefile für uns leichter wartbar und administrierbar machen. Ich hatte ja bereits weiter oben schon einmal erwähnt, daß der Name der Zone in der Datei /etc/named.conf wichtig ist. Dieser Name wird als sogenannter Ursprung betrachtet. Dieser Zonenname wird (intern) automatisch an jeden Namen im Zonefile angehängt, der nicht auf einen Punkt endet.. Statt bond.heim.netz. könnten Sie im Zonefile auch nur bondschreiben. Deswegen dürfen Sie bei den langen Namen auch nie den Punkt vergessen. Der Zonenname wird sonst noch einmal an den Namen angehangen.

Sind Domainname und Zonenname identisch, kann im Zonefile statt des Domainnames auch einfach kurz das @ Zeichen geschrieben werden.

Sollten Sie für einen Rechner mehrere Ressource-Records haben (das sehen wir nachher auch bei den Spielereien) und diese folgen aufeinander, dann reicht es den Namen bei dem ersten Ressource-Record anzugeben. Beginnt nämlich eine Zeile mit einem White Space (Leerzeichen, Tab, etc.) wird automatisch angenommen, daß sich dieser Ressource-Record auf den zuvor genannten Namen bezieht.

Diese Regeln kann man selbstverständlich auch auf das Reverse Mapping File anwenden. Hier unsere beiden Zonefiles mit den abgekürzten Fassungen:

Forward-Mapping File (Zonenname heim.netz):

; Zonefile (Forward Mapping) für heim.netz.
;
$TTL 3h
@          IN SOA lago.heim.netz. root.lago.heim.netz. (
   200207241 ; Seriennummer
   10800     ; Refresh Zeit
   3600      ; Retry Zeit
   604800    ; Expire
   38400 )   ; negative Caching TTL
;
; Nameserver
;
           IN NS lago.heim.netz.
;
; Hosts 
;
localhost. IN A 127.0.0.1
blofeld    IN A 192.168.100.101
bond       IN A 192.168.100.102
lago       IN A 192.168.100.103
;
; Aliase
;
www        IN CNAME lago
irc        IN CNAME lago

Lediglich beim SOA-Record kürze ich die Namen nicht ab. Man könnte es in diesem Fall machen, aber in anderen Konfigurationen kann es da zu Fehlern kommen. Beim NS-Record fehlt der Name, da dieser bereits im Record davor, dem SOA-Record genannt wurde.

Reverse Mapping File (Zonenname 100.168.192.in-addr.arpa):

; Zonefile für heim.netz. (Reverse Mapping)
;
$TTL 3h
@    IN SOA lago.heim.netz. root.lago.heim.netz. (
   200207241 ; Seriennummer
   10800     ; Refresh Zeit
   3600      ; Retry Zeit
   604800    ; Expire
   38400 )   ; negative Caching TTL
;
; Nameserver
;
     IN NS lago.heim.netz.
;
; Hosts Adressen zeigen auf kanonische Namen
;
101  IN PTR blofeld.heim.netz.
102  IN PTR bond.heim.netz.
103  IN PTR lago.heim.netz.

Wenn Sie regelmäßig einen Rechner hinzufügen oder entfernen ist diese Art der Notation sicherlich einfacher zu warten.

12. MX-Records
Nun ein Thema, welches in der aktuellen Konfiguration eigentlich keine Rolle spielt, aber so häufig bei Nameservern vorkommt, daß es kurz in einem eigenen Abschnitt behandelt wird. Wie beeinflusst das DNS-System den eMail-Verkehr ? Ein wenig, da das DNS das Mail-Routing mit ändert. Wir erweitern unser oben gezeigtes Szenario, und nehmen an, daß auflago unser Mailserver für das Netzwerk läuft, und ein weiterer aufbond, falls lago ausfällt. Wir würden dann folgende MX-Records mit in das Forward Mapping Zonefile aufnehmen:

heim.netz.   IN  MX   10  lago.heim.netz.
heim.netz.   IN  MX   20  bond.heim.netz.

Zunächst einmal sorgt der Name heim.netz. dafür, daß man (wie im Internet üblich) eMails an die Domain adressiert und nicht an die einzelnen Rechner (peter@heim.netz). Als nächstes folgt die Klasse und der Typ MX. MX steht für Mail Exchanger und bezeichnet einen Rechner, der in der Lage ist die Mail für die domain entweder zu verarbeiten oder weiterzuleiten (alles über SMTP).

Der folgende Wert ist der Präferenzwert (ein Wert zwischen 0 und ca. 65.000). Fragt ein Mailer bei unserem Server nach dem MX-Record werden ihm beide Einträge zurückgeliefert. Dabei soll der Mailer jedoch versuchen seine Mail zuerst bei dem Server abzuliefern, der den niedrigeren Präferenzwert hat. Das wäre lago und macht auch Sinn weil lago immer an ist. Sollte es nicht möglich sein Mail an lago auszuliefern (der Rechner/Router ist zwar an, aber der Mail-Daemon abgestürzt), dann soll versucht werden an den Rechner mit dem nächsthöheren Präferenzwert abzuliefern. Das wäre in unserem Fall bond.
Würde man beiden Einträgen den gleichen Präferenzwert, zB. 10, geben, könnte der Mailer sich aussuchen an wen er die Mail ausliefern will. Durch einen geschickten Algorithmus lässt sich dabei ein einfaches Loadbalancing realisieren. Wieviel Mailserver benötige ich? Nun T-Online betreibt 8 SMTP-Mailserver mit gleichem Präferenzwert. Vielleicht hilft Ihnen das beim Abschätzen :)

Sollten Sie keinen Mailserver betreiben, brauchen Sie keine MX-Records. Betreiben Sie einen Mailserver (zB. im Büro-Intranet) dann tragen Sie eben Ihren Mailserver hier ein. Betreiben Sie einen Mailserver im Internet, dann tragen Sie Ihn auch hier ein. Achten Sie dann aber streng darauf das er auch erreichbar ist.
Soviel dazu.

13. Schnick Schnack Spielereien
Das ist ein netter Abschnitt, denn er behandelt Ressource-Records, die nicht notwendig, aber lustig sind/sein können. Fangen wir mit einem einfachen Record an. Er liefert Texte zurück und ist daher von Typ TXT. Sie können dort beliebige Informationen für jeden Host unterbringen. Interessant wäre zB.

lago  IN  TXT   "Super Maschine. Kann alles." "Standort: Wohnzimmer"

Man kann mehrere Strings angeben, wie man sieht. Der erste ist eben, wie gesagt lustig, aber nutzlos. Der zweite könnte für den einen oder anderen schon interessant werden. Wenn man ein Firmennetzwerk mit einer Menge Rechnern in einer Menge Räumen zu verwalten hat, ist es relativ einfach den Standort eines Rechners zu bestimmen, der Probleme macht. Siehe aber den Hinweis unten.

Ein weiterer interessanter Record ist der RP-Record. Das steht für Responsible Person. Damit kann die verantwortliche Person für einen Rechner angegeben werden. Als Nameserver Administrator können Sie so schnell abfragen, wie der Kontakt für einen Verantwortlichen ist. Es können aber auch Nutzer Ihres Netzwerkes abfragen, wer zB. für den Nameserver verantwortlich ist :) So ein Eintrag würde so aussehen:

lago  IN   RP    root.lago.heim.netz.    lago.heim.netz.
lago  IN   TXT   "Namerserver Hotline: (555) 33080"

Der RP-Record hat, wie man sieht, zwei Argumente. Das erste ist die eMail-Adresse des Verantwortlichen, in der Notation, die wir schon aus den SOA-Record kennen, also mit dem durch einen Punkt ersetzten @-Zeichen. Das zweite ist einfach ein Domain Name, der weitere Informationen zum Kontakt preisgeben kann. Zu diesem Namen muss es dann aber auch einen TXT-Record geben, der formolse Informationen zu der verantwortlichen Person enthält. Dies kann der Klarname sein, die Adresse oder eben auch die Telefonnummer.

Eine weitere nette Spielerei ist der HINFO-Record. Mit diesem können Sie für jeden Rechner angeben, auf welcher Hardware er basiert und welches Betreibssystem auf ihm läuft. Der Aufbau ist einfach:

lago    IN   HINFO   "VIA C3 566 Mhz x486 System" "SuSE Linux 8.0"

Da der Wahrheitsgehalt nicht überprüft wird, kann man ebensogut schreiben:

lago    IN   HINFO   "Commodore C64" "Basic V2.0"

Dieser Eintrag ist meist dann gut zu gebrauchen, wenn es in die 'Wer hat den längsten?'-Diskussion geht. Eigentlich sollten die Informationen aus RFC 1700entnommen werden. Das ist aber nicht immer aktuell :)

In RFC 1876ist ein weiterer Ressource-Record definiert, der eigentlich interessant ist. Es handelt sich dabei um den Location-Record LOC. Damit lässt sich der geografische Standort eines Rechner eintragen. Wer schon mal ein Tool wie VisualRoutebenutzt hat, weiß was daran interessant ist. Dieser Record wird aber kaum in Nameserver eingetragen. Das Projekt sieht, auch aus Sicherheitsgründen, relativ gescheitert aus. Weil er aber nett ist, hier ein Beispiel für lago, der in Berlin steht:

lago IN LOC 52 31 0.12 N 13 24 0.36 E 34m

Die Parameter bedeuten dabei nacheinander die geographische Länge, Breite und die Höhe in Metern über dem Meeresspiegel.

Eine modifizierte Version unseres Forward Mapping Zonefiles würde mit den zusätzlichen Einträgen etwa so aussehen:

; Zonefile (Forward Mapping) für heim.netz.
;
$TTL 3h
@          IN  SOA lago.heim.netz. root.lago.heim.netz. (
   200207241 ; Seriennummer
   10800     ; Refresh Zeit
   3600      ; Retry Zeit
   604800    ; Expire
   38400 )   ; negative Caching TTL
;
; Nameserver
;
           IN  NS lago.heim.netz.
;
; Hosts (kanonisch)
;
localhost. IN  A     127.0.0.1
blofeld    IN  A     192.168.100.101
           IN  LOC   52 31 0.12 N 13 24 0.36 E 34m
           IN  HINFO "Fujitsu Siemens P I 75 Mhz" "SuSE Linux 6.4"
           IN  RP    root.blofeld.heim.netz.    lago.heim.netz.
           IN  TXT   "Linux Konsolenrechner" "Standort: Arbeitszimmer"
bond       IN  A     192.168.100.102
           IN  LOC   52 31 0.12 N 13 24 0.36 E 34m
           IN  HINFO "AMD K7 2400+" "Windows 98"
           IN  RP    webmaster.ag-intra.net.    lago.heim.netz.
           IN  TXT   "Workstation" "Standort: Arbeitszimmer"
lago       IN  A     192.168.100.103
           IN  LOC   52 31 0.12 N 13 24 0.36 E 34m
           IN  HINFO "VIA C3 566 Mhz Spacewalker" "SuSE Linux 8.0"
           IN  RP    root.lago.heim.netz.    lago.heim.netz.
           IN  TXT   "Server und Router" "Standort: Arbeitszimmer"
;
; Aliase
;
www        IN  CNAME lago
irc        IN  CNAME lago

Hier sieht man auch noch einmal sehr schön, daß Ressource Records, die mit Whitespace beginnen, sich immer auf den letztgenannten Domainnamen beziehen, bzw. auf den entsprechenden Host.

Wichtiger Hinweis zu den Spielereien: Wenn Sie einen Nameserver im Internet betreiben, sollten Sie sich gut überlegen, welche Informationen Sie wirklich preisgeben wollen. Potentielle Blackhats haben es jedenfalls leichter in Ihre Systeme einzudringen, wenn Sie vorher schon wissen womit sie es zu tun haben.

14. Unterschied zu anderen Nameserver Konfigurationen
Welche anderen Konfigurationen sind gemeint? 

Stellen Sie sich vor, Sie haben zwei Netze zuhause. Ihr Nameserver hat noch eine weitere Netzwerkkarte, die an das zweite Netz angeschlossen ist. Sie können dann den Nameserver geanu wie hier gezeigt konfigurieren. Für das Zweite Netz müssen Sie dann aber eine weitere Reverse-Zone einrichten. Dies machen Sie genauso wie für das erste Netz, nur das Sie die andere Netzwerkadresse verwenden. Die Domainnamen können Netzwerk-übergreifend sein. Das hier gezeigte Forward Mapping File müsste also nur ergänzt werden

Beispielsweise könnten Sie auch einen Nameserver für eine echte Domain im Internet betreiben. In diesem Fall können Sie praktisch nicht darauf verzichten einen Secondary Nameserver zu betreiben, also einen Slave. Die Konfiguration des primären Nameservers weicht eigentlich nicht von der hier gezeigten ab. Sie sollten sich dann nur ernsthaft mit den TTL's im SOA-Record befassen und sinnvolle Werte einsetzen. 

Die Slave Konfiguration ist um einiges einfacher, da der Slave die Zonendaten schließlich vom primären Nameserver bezieht. Bei einem Slave würde in der /etc/named.conf einfach der Typ 'slave' bei unseren Zoneneinträgen angegeben, sowie eine weitere Zeile mit dem Inhalt

masters { 192.168.100.103; };

(bezogen auf unser Beispiel) einfügen. Die Zonendateien kopieren Sie einfch vom Masternameserver. Hat beim Start des Slaves die Seriennummer im SOA des Masters einen höheren Wert als die des Slaves bezieht der Slave die Zonendateien vom Master neu. Achten Sie darauf, daß Sie in der Master-Konfigurationsdatei nicht den oben gezeigeten Eintrag vornehmen, der Zonentransfers verbietet (sie können den Transfer auch auf die konkreten Slaves beschränken).

Schließlich haben Sie ausserdem auch die Möglichkeit einen eigenen Rootserver zu betreiben. Machen Sie das aber bitte nicht im Internet. Da dieses Thema etwas komplexer ist, wird es hier nicht behandelt.

Sie sehen also, es gibt keine wirklich großen Unterschiede zwischen dem gezeigten Beispielnameserver der nun für unser lokales Netz zuständig ist, und anderen Konfigurationen.

15. Sicherheit
Noch ein abschließendes Wort zur Sicherheit. Schon aus Sicherheitsgründen sollte niemand Zugriff auf den hier beschriebenen Nameserver erhalten. Wenn Sie die Firewall wie im DSL-Artikel gezeigt konfiguriert haben kann eigentlich auch niemand auf den Nameserver zugreifen. Der Nameserver selbst kann aber in das Internet kommunizieren. 

Es gibt auch eine Möglichkeit den Nameserver selbst ein wenig abzusichern. Dazu gehört unter anderem die option allow-query, die wirobenbei der Konfigurationsdatei named.conf schon gezeigt haben. Sie sorgt dafür, daß nur Rechner aus unserem privaten Netz Anfragen an den Nameserver stellen können.

Eine weiter interessante Einstellung ist die Beschränkung der Rechner, die einen Zonetransfer von unserem Nameserver durchführen dürfen. Dies sollten normalerweise nur die Slaves sein. Ansonsten kann jedermann Informationen über Ihre gesamte Netzwerkstruktur abfragen. Man kann entweder Zonentransfers auf bestimmte IP's beschränken, oder den Transfer ganz verbieten. In dernamed.conf würden wir zum Verbieten von Zonetransfers folgendes in unserer Zone ergänzen:

zone "heim.netz" in {
   type master;
   file "db.heim.netz";
   allow-transfer { none; };
}

Es gibt auch noch die Möglichkeit Zonentransfers verschlüsselt durchzuführen, Rekursion abzuschalten und vieles mehr. Die hier gezeigten Einstellungen sollten für den Anfang jedoch reichen.

16. Links
 

DNS HowTo	Das HowTo des Linux Documentation Projects
bind8	Die Homepage zu Bind der isc. Es findet sich die aktuellste Version und weitere Informationen
Bind Buch	Das O'Reilly Buch zu Bind

Danke an Christian, der mir sehr bei der Zonefile-Konfiguration und der Erklärung des Grundprinzips geholfen hat.